【品控体系】用例覆盖、敏捷执行、效率提升、持续跟踪

【品控体系】用例覆盖、敏捷执行、效率提升、持续跟踪

1.明确工作职责

a.用例编写/维护

i.版本冒烟用例：需求确认期完成冒烟用例，包含前端冒烟、服务端接口冒烟
ii.版本系统用例：敏捷测试过程中不断完善系统用例，并在提测前完成用例编写
iii.用例汇总：在提测前完成汇总用例的维护

b.敏捷测试（具体见4敏捷测试过程）

i.对需求、业务逻辑、技术方案等相关内容进行反讲及确认
ii.敏捷版本准备
iii.敏捷版本测试

c.日常跑测/持续跟踪

i.以系统汇总用例为依据，进行定期系统跑测
ii.使用自动化工具及脚本，进行定期自动化跑测
iii.以品控指标为依据，定期提出优化功能点（待定）

d.版本测试

i.版本提测验收（以冒烟为依据）
ii.测试服部署及维护
iii.版本测试/回归
iv.编写测试报告

2.明确工作内容

a.用例覆盖

i.完善用例（主要是汇总用例、版本系统用例）
ii.规则及梳理（主要是汇总规则、版本规则，从功能出发的正向梳理，从UI出发的反向梳理）
iii.规则传达及确认（用例透明化、通知到位，开发人员自行确认），目前面临的问题：
1.开发人员无视规则
2.开发人员不确认规则

b.敏捷测试执行（开发环境）

i.约定敏捷测试版本时间节点（测试人员与开发人员进行碰头约定）
ii.开发人员对敏捷测试进行配合
1.根据测试要求及敏捷版本约定出敏捷版本/敏捷包
2.不断确认测试梳理项（具体见4敏捷测试过程）
iii.工作流程
1.测试人员根据版本列出需要敏捷测试的内容，并评估确认（评估确认的标准是构成0.1跑通），敏捷测试内容提交到TB
2.测试人员与开发人员进行提前沟通，约定同步及告知敏捷测试内容及具体时间点
3.过程中的变更，测试人员进行提醒，开发人员确认接收提醒，并自行查看TB文档进行确认
4.在约定的时间点，开发人员给出敏捷测试版本
5.根据约定进行敏捷测试，并给出问题反馈，并将结果提交到TB
6.开发人员确认问题反馈，约定时间复查

c.测试过程效率可提升点

i.对冒烟过程进行严格把控
1.冒烟用例在需求确认期结束后需要进行评审及确认
2.开发人员严格按照根据冒烟用例进行自测，并以此作为验收的基本标准
3.提测前，测试人员进行冒烟测试，以确定是否可以提测，完成后记录提测时间点
ii.约定时间统一进行回归（目前bug回归结果和跟踪效率较低，反复沟通成本较大）
1.测试人员根据bug量，与开发人员约定统一回归时间点
iii.对代码逻辑进行确认及跟踪（参考敏捷过程，需开发人员配合）
iv.完善测试环境配套（相关脚本，部署规范等，需开发人员配合）
1.重新安装脚本
2.反复单点测试脚本
3.等等其他

d.结果及复查环节（先列举要复查的项目，然后配套）

i.接口复查（接口自动化工具及脚本）
ii.服务端日志复查（服务端日志复查工具及脚本）
iii.数据复查（数据复查工具及脚本）
iv.常用sql（测试自查常用sql梳理）

3.子任务分解（xxx）

a.测试环境部署

i.资源文件同步【命令/脚本】（xx）
ii.数据库数据同步【命令/脚本】（xx）
iii.测试环境发布流程【文档】（xx）

b.测试服本地搭建

i.安装搭建文档【文档】（John）
ii.搭建脚本【命令/脚本】（John）
iii.测试环境相关代码文件【工具/脚本/命令】（John）
iv.相关工具【工具】（John）

c.测试用例

i.系统用例【需要列出有几条】（John）
ii.汇总用例【需要列出有几条】（John）
iii.规则整理【需要列出有几条】（John）
1.正向规则梳理
2.反向规则梳理
iv.用例转换脚本（md<->xlsx）（Luke）80%
v.测试报告生成脚本（Luke）0%

d.自动化

i.测试工具（John）80%
ii.基础文档（Luke）20%

4.敏捷测试过程

a.确认项（需求确认期）

i.确认功能分解估时表
ii.确认数据库表版本相关内容
iii.确认协议文档
iv.确认相关技术方案实现逻辑

b.敏捷准备（小范围碰头会进行确认）

i.列举该版本需要参与敏捷测试的内容，可能包含以下内容【列表】
1.需要测试的业务流程
2.需要测试的模块
3.需要测试的功能点
4.需要测试的交互步骤
5.需要测试的单点/单步
6.需要测试的脚本
7.其他…
ii.确定敏捷版本时间节点【时间节点】

c.敏捷版本

i.发布敏捷版本，构建敏捷包【版本/安装包】
ii.准备敏捷数据及资源文件【脚本/命令/工具】

d.敏捷测试过程（测试人员定时间节奏，开发人员配合）

i.内部演示的方式【演示会】
ii.测试回归的方式【问题列表/提醒列表/相关记录等】

e.测试方法及执行（按优先级降序）

i.系统性测试（以系统用例为依据）
ii.整体性跑通测试（以冒烟用例为依据）
iii.功能性跑通测试（以功能用例/模块用例为依据）
iv.单点测试/单元测试/单步测试（如有必要需开发人员主动暴露内部实现过程，如有必要需提供工具/脚本）
f.具体检查项（小范围碰头会形式进行确认）
i.数据检查【相关sql】
ii.资源文件检查【相关脚本】
iii.逻辑实现二次确认（业务实现反讲）