1、功能模块
B端：后台管理系统看商品模块、用户权限模块
C端：前台商城系统看会员认证模块、商品与营销模块、订单与分布式事务模块
方法：
1、看Controller 这里有前端所有调用的URL，测接口入参，是否需要token
2、看Servicelmpl （业务心脏）：业务逻辑在这里，编写测试脚本的业务逻辑
3、看Mapper.xml（数据落地）：这里有SOL语句，可以发现数据库问题
4、工具：安装RestFulToolkit插件，可以列出所有URL
2、核心模块测试点拆解
1.PMS（商品管理模块）
商品是整个电商的基石，主要测试数据的准确性与上下架状态机流转。
基本核心：商品列表与分类查询
测试普通用户、匿名用户能否正常拉取商品列表、搜索商品、按分类筛选。
检查商品详情页的数据（价格、库存、图片、描述）是否与数据库一致。
状态流转：商品上下架状态
正常场景：商品上架后，前台可以搜索并购买；商品下架后，前台不可见或提示已下架，且无法下单。
边界与异常：商品未到定时上架时间时，前台是否隐藏。
关键要素：库存校验（联动 OMS）
商品单次限购、购买量超过当前库存时的拦截逻辑（不能卖出不存在的货）。
2. OMS（订单管理模块）
订单模块是电商里逻辑最复杂的模块，涉及分布式事务和状态机的严格流转。
核心闭环：正向提单流转
创建订单：选择商品 -> 提单 -> 扣减库存 -> 生成待支付订单（状态：待支付）。
订单支付：模拟调用支付宝沙箱（对应你配置里的
alipay） -> 支付成功 -> 回调通知 -> 订单状态变更为（待发货）。
核心闭环：反向超时与取消
超时自动取消（重点测 RabbitMQ 延迟队列）：下单后故意不支付，到达设定时间（例如 30 分钟）后，系统是否触发自动取消，订单状态变为（已关闭），且被扣减的商品库存必须自动原路加回。
异常场景（你的规划重点）：
库存为 0 下单：当商品库存为 0 时，点击下单是否能被完美拦截，并返回清晰的报错提示。
高并发下的超卖现象：同一件商品库存仅剩 1 件，多名用户同时抢购，是否能保证只有 1 人成功，且库存不为负数。
3.PMS模块测试
前台系统：MallAdminApplication：主要做数据展示和读取
后台系统：MallPortalApplication：主要做数据维护和CRUD
一个完整的核心业务测试闭环，应该是“从后台上架/修改分类 -> 去前台验证数据同步与呈现”
1.普通用户：
使用PmsProductCategoryController，展开其中的GET /productCategory/list/{parentId}，输入 关键数据运行，在后端数据根据ID查到数据，确认数据信息无
使用PmsProductController，展开GET /product/list，将productCategoryId填入你刚才查到的分类 ID，确认返回的数据里，商品的publishStatus（上架状态）是否为1（已上架）。只有上架的商品在前台才能被查到
用HomeController，GET /home/productCateList/{parentId}（获取首页商品分类）接口，parentId填0，检查返回的分类列表里，是否包含你在后台看到的那几个一级分类
使用PmsPortalProductController，展开GET /product/search，productCatagory填刚才测试的ID（如1），pageNum:1,pageSize:10,查看Body数据和后台数据一致
若：前台输入ID等数据后查不到数据，检查后端数据库商品状态是否上架或库存剩余
2.匿名用户：前台页面不点击Authorize调用GET /product/search接口，能够查到商品
后台页面不给token，返回401（未授权）或403（找不到），匿名用户无法修改数据
3.空分类测试：在后台PmsProductCategoryController里随便找一个没有任何商品的空分类 ID，或者直接在输入框里传一个不存在的分类 ID，调用前台PmsPortalProductController的查询接口，系统应该返回结构正常的 JSON，状态码200
4，商品下架测试：在后台PmsProductController中，找一个原本在前台能看见的商品，调用修改接口将其状态改为下架（或者直接去虚拟机 MySQL 的pms_product表里把该商品的publishStatus改为0），再次调用前台PmsPortalProductController的查询接口，或者直接调用商品详情接口。如果通过商品 ID 查询详情，应该提示“该商品已下架或不存在”。
等价类和边界值的补充：
1.pageSize（每页显示条数）的边界值测试
| 测试类型 | 输入参数值 (pageSize) | 预期结果（如何算断言通过） |
| 有效边界值 | 1（下限边界） | 成功返回200，Body 的list数组里有且仅有 1 条数据。 |
| 有效边界值 | 5/10（正常值） | 成功返回200，正常分页。 |
| 无效边界值 | 0（非法下限） | 应该由后端代码拦截，通常系统会自动将其**重置为默认值（如 10）**或报错，绝不能让程序崩溃。 |
| 无效边界值 | -1（负数边界） | 必须被拦截，返回业务错误码，不能传入数据库执行 SQL（防止 SQL 报错）。 |
| 超大边界值 | 999999（超上限） | 后端应该有最大限制（比如限制死最多只返回 100 条），防止一次性查出几十万条数据导致内存溢出（OOM）。 |
测试发现该项目在pageSize=-1时依旧返回值200，没有出现报错，证明该项目没有做负数拦截
影响：SQL资源浪费，黑客利用负数注入数据赞成大量日志报错导致CPU飙升
前端分页组件代码计算时出现错误造成页面卡死或白屏
2.pageNum（页码）的等价类测试
| 等价类划分 | 输入参数值 (pageNum) | 预期结果 |
| 有效等价类 | 1（第一页） | 正常返回第一页数据。 |
| 有效等价类 | 2（假设总共只有一页） | 返回200，但list: []（因为后面没数据了），这也是正常的行为。 |
| 无效等价类 | 0或-5（零或负数） | 属于无效输入。后端必须兜底拦截，要么报错提示“页码不合法”，要么自动将其修正为1。 |
3.productCategoryId（分类ID）的等价类测试
| 等价类划分 | 输入参数值 (productCategoryId) | 预期结果 |
| 有效有数据等价类 | 1（服装类，里面有货） | 成功返回200，且list里面能看到衣服。 |
| 有效无数据等价类 | 找一个空分类的 ID（比如2） | 成功返回200，但list: []，total: 0。 |
| 无效不存在等价类 | 999999（数据库根本没有这个ID） | 成功返回200，list: []。 |
| 无效非法格式等价类 | abc（故意输入英文字母） | 后端在框架层（Spring MVC 参数解析）就应该拦截，返回400 Bad Request，提示参数类型不匹配。 |
