Test-mall 基础功能测试

📅 2026/7/22 0:57:22
Test-mall 基础功能测试
1、功能模块B端后台管理系统看商品模块、用户权限模块C端前台商城系统看会员认证模块、商品与营销模块、订单与分布式事务模块方法1、看Controller 这里有前端所有调用的URL测接口入参是否需要token2、看Servicelmpl 业务心脏业务逻辑在这里编写测试脚本的业务逻辑3、看Mapper.xml数据落地这里有SOL语句可以发现数据库问题4、工具安装RestFulToolkit插件可以列出所有URL2、核心模块测试点拆解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已上架。只有上架的商品在前台才能被查到用HomeControllerGET /home/productCateList/{parentId}获取首页商品分类接口parentId填0检查返回的分类列表里是否包含你在后台看到的那几个一级分类使用PmsPortalProductController展开GET /product/searchproductCatagory填刚才测试的ID如1pageNum:1,pageSize:10,查看Body数据和后台数据一致若前台输入ID等数据后查不到数据检查后端数据库商品状态是否上架或库存剩余2.匿名用户前台页面不点击Authorize调用GET /product/search接口能够查到商品后台页面不给token返回401未授权或403找不到匿名用户无法修改数据3.空分类测试在后台PmsProductCategoryController里随便找一个没有任何商品的空分类 ID或者直接在输入框里传一个不存在的分类 ID调用前台PmsPortalProductController的查询接口系统应该返回结构正常的 JSON状态码2004商品下架测试在后台PmsProductController中找一个原本在前台能看见的商品调用修改接口将其状态改为下架或者直接去虚拟机 MySQL 的pms_product表里把该商品的publishStatus改为0再次调用前台PmsPortalProductController的查询接口或者直接调用商品详情接口。如果通过商品 ID 查询详情应该提示“该商品已下架或不存在”。等价类和边界值的补充1.pageSize每页显示条数的边界值测试测试类型输入参数值 (pageSize)预期结果如何算断言通过有效边界值1下限边界成功返回200Body 的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成功返回200list: []。无效非法格式等价类abc故意输入英文字母后端在框架层Spring MVC 参数解析就应该拦截返回400 Bad Request提示参数类型不匹配。