一、测试目标
以需求目标为导向，实现业务功能；保障产品质量达到交付标准；不同程度上预防问题，开展更有效的测试方式。
二、测试分析
🍎需求层
1、需求背景
2、需求文档
3、需求范围
| 应用 | 需求覆盖 | 需求不覆盖（本期确定不做） |
|---|---|---|
3、各评审会议记录
- 会议遗留问题
4、模块拆分
1、 按照功能模块拆分测试点
🍉接口层
0、技术文档
1、系统交互逻辑
2、新增/修改接口逻辑
3、接口校验
接口数据交换01-新增店铺
| 应用 | 方法名 | 功能 | 出入参 |
|---|---|---|---|
数据库校验
该接口涉及数据表校验
接口数据交换02-修改店铺
🍇UI层
0、UI文档
1、走单截图/视频
三、测试策略
1、重点难点
通过测试分析层得出本次测试的重点与难点，需要得到哪些支持，提前给出解决方案。
重点难点
✏️ 控件、跳转、模拟用户异常交互
✏️ 组合流程中，关闭流程、克隆流程等逆向场景
✏️ 店铺列表，派单，各页面之间的联动关系
✏️ 依赖上下游，mock方案
✏️ 是否需要涉及新的测试技术/工具
✏️ 逆向场景，探索性测试
2、风险评估
评估有哪些潜在风险，尤其可能造成延期上线的卡点，确定哪些指标是用户最关心的。功能、性能、安全、兼容性、易用性、稳定性等，在成本和风险之间找到平衡点。
风险识别
| 节点 | 风险点checklist | 记录&解决 |
|---|---|---|
| 需求评审 | - [x] 需求是否还有未确定的内容 - [x] 需求设计是否合理，产研团队对需求理解是否一致 - [x] 梳理对老功能的影响 - [x] 是否需要回归其他业务线 - [x] 是否涉及到上下游修改 - [ ] 依赖上下游是否需求同步 - [x] 在途订单的影响 - [ ] 其他风险 - [ ] 金额资损 - [ ] 法律合规性 - [ ] 敏感信息泄露 |
|
| 技术评审 | - [x] 确认新增/修改接口的接口定义是否列出 - [x] 确认技术文档是否给出开发排期，分布提测方案 - [ ] 若本次需求需要开发给出时序图，则需要确认技术文档是否包含时序图 |
|
| 用例评审 | - [x] 是否还有存疑的地方 - [x] 是否有冒烟用例 - [x] 接口脚本编写，接口文档是否定义完全或更新 - [x] 接口用例与功能用例分离，功能用例关注前端组件的交互测试 |
|
| 开发提测 | - [x] 是否执行冒烟用例 - [ ] 是否延期提测/提测版本质量较低 - [ ] 前后端联调,上下游联调是否到位 |
|
| 测试中 | - [x] 测试环境问题，如ES索引问题是否解决 - [x] 测试数据问题 - [x] 是否需要测试标：预发定时任务会扫描线上数据 - [ ] 是否有专门的测试店铺，如巴音郭楞 - [ ] 是否需要申请测试生活号 - [x] 上下游配合是否到位，mock方案 - [x] 测试进度、卡点、风险点日报、站会同步团队，推动解决 |
|
| 产品&业务验收 | - [x] 是否需要提前配置测试/线上业务数据 - [x] 是否有不符合业务诉求或需要修改的点：若有需要记录并确认是否本次需要修改 - [ ] 是否涉及前端，若涉及需要交互设计师验收 |
|
| 上线 | - [x] 发布计划check - 发布依赖顺序 - 配置、表结构、定时任务等 - [ ] 是否要走真人假业务 - [ ] 是否发布后进行线上数据观察 - [ ] 是否存在遗留问题 |
3、测试安排
资源投入
- 测试时长、人员安排、子任务拆分、优先级确定（产品需求主流程保障顺畅） | 模块 | 功能 | 测试时长 | 人员安排 | 提测时间 | 优先级 | 实际提测 | | —- | —- | —- | —- | —- | —- | —- | | 店铺信息 | 创建店铺信息 | 1 | 艾素珍 | 0815 | p0 | | | | 修改店铺信息 | | | | | 0819 | | | 查询店铺详情 | | | | | | | 店铺列表 | 列表查询 | 0.5 | 艾素珍 | 0815 | p2 | | | | 启用/禁用/编辑/操作记录 | | | | | | | 合计 | | 13天/人 | | | | |
进度跟进
| 发布顺序 | 应用名称 | 模块 | 开发负责 | 进度 | 预发时间 | 上线时间 |
|---|---|---|---|---|---|---|
| 1 | 店铺管理 | 总体延期一天 |
4、测试方案
接口测试
选用的框架及工具，测试左移的方式
- 选择RF框架
兼容性测试
- web端等采用手工测试。客户端、浏览器兼容
- 客户端关注联动交互，组件
-
系统测试
[x] 确保本系统各模块的集成测试完成后，测试一笔由系统真实走单数据，系统自动流转不介入人工接口调用或者mock消息。
- 前期测试中，查询外部服务商接口被mock,导致城市透传错误也能够返回查询结果，真实联调后发现问题，因此需要关注接口之间数据交换的问题，尤其是部分数据透传错误也不影响状态流转，但造成数据内容错误。
性能测试
协助工具模拟并发情况下服务的处理能力，含响应时间和吞吐量。（本期暂无❌）回归测试
梳理对老流程的影响点：
线上流程现有流程梳理：
现上流程流量分析：
验收测试
[ ] 组织产品、业务方参与验收测试，满足各方预期 | 验收待优化 | 跟进人
| 原因 | 完成情况 | 补充说明 | | —- | —- | —- | —- | —- | | | | | | | | | | | | | | | | | | | |
| | | | |
探索性测试
通过探索更多场景增加覆盖率
- 逆向场景
逆向/异常场景：
- 多业务入口覆盖
多入口覆盖，如：【事件监听】【定时任务】【后台页面】等入口均需要覆盖开启流程。多业务线调用同一个接口，评估其他业务线是否需要覆盖。
- 多因素组合
场景受多因素共同作用使用正交组合测试法，如四要素校验，四要素交叉组合通过/不通过的场景。
- 外部依赖
依赖外部的三个dubbo接口异常，钉钉告警抛出
- 多对多场景
当数据存在一对多，多对多的关系，重点关注路由规则。如一个城市多个服务商，一个服务商同时在多个城市展业。一台车vin码维度，只能出库一次。
- 多期次场景
如账单系统部分还款，部分成功，部分失败等
- 未完待续…
若有收获，就点个赞吧
0 人点赞
