目录
目的
- 保证QA在人力比过大资源不足的时候上线最核心功能的基本保证;
- 对产品功能的重要性进行梳理,保证按计划上线;
- 对项目的测试风险进行控制和预警;
- 避免delay和长期加班;
- 回归时有重点有优先级的回归;
- 提高开发提测质量;
范围
针对新项目、迭代增量需求、插入需求、系统重构等内容,BUG紧急修复类问题无需按本规范执行。
质量分级如何实施
质量分级分为3步实施。
- 模块功能点划分。拿到一个完整的系统需求,先按照功能点划分模块和功能点(即迭代中的Story)。
- 模块优先级确认。将各个模块划分为1、2、3、4种质量等级。
- 编写在线Case并执行。
模块划分
QA根据需求文档和原型进行模块划分。
模块划分需要遵循MECE划分原则。功能模块之间相互独立、没有遗漏。针对页面一般为二级菜单功能,比如知识管理、分类管理。
功能点以业务逻辑为story,尽量细分,以测试时间<=2小时为标准。务必可测,拿到story可以写出验收标准。
功能细项列表(QA) |
|
模块 |
功能点(story) |
后台轨迹配置 |
新增轨迹 |
|
删除 |
|
启用/停止 |
质量分级
PM根据细分后的功能点,预估各个功能点的重要程度和使用人数,得出功能点的质量等级。
重要程度:高、中、低。
使用人数:很多>80%、较多(30%-80%)、一般(5%-30%)、少<5%。功能点使用人数=使用功能点人数/使用系统人数。
质量等级分为1-4级,对应的测试范围如下:
1级:功能性测试、外部接口测试、边界值、等价类、所有异常分支.
2级:功能性测试、外部接口测试、边界值、等价类、部分异常分支
3级:功能性测试、等价类
4级:不测试
示例图
功能细项列表(QA) |
功能点业务影响面评估(PM) |
质量等级(QA+PM) |
||
模块 |
功能点(story) |
功能点重要度 |
使用人数预估 |
质量等级 |
后台轨迹配置 |
新增轨迹 |
高 |
很多 |
1级 |
删除 |
低 |
少 |
4级 |
|
启用/停止 |
中 |
一般 |
3级 |
在线case
- 设计
测试用例由测试编写,至少在开发提测前1天完成,设计遵循下表的测试范围与测试优先级对应关系。
用例设计需要考虑DB、缓存其他第三方存储系统的数据落地正确性。
测试范围与测试优先级对应关系 |
|||
1 |
2 |
3 |
|
功能-流程相关 |
周边流程及其分支覆盖 |
周边流程回归覆盖 |
保证当前功能点 |
功能-逻辑实现 |
逻辑分支覆盖、边界条件 |
逻辑分支覆盖 |
保证主要逻辑 |
功能-WEB展现 |
正反用例、边界条件 |
正反用例 |
保证当前WEB展现 |
性能效率 |
极限条件测试、压力测试 |
极限条件测试 |
保证常规响应时间15s |
与其他系统交互 |
与其他系统联调、异常测试 |
与其他系统联调 |
模拟其他系统操作 |
测试根据质量分级标记用例为1,2,3,4个等级。
- 评审
针对复杂业务逻辑需要涉及的开发、产品、测试人员一起以讲解的形式评审用例的合理性、完备性。
针对新人编写的用例,需要由导师或其他高级测试人员评审。
评审后修改的用例在评审后第二天发给评审人员二次确认。
- 执行
开发(前端+后端)执行:开发提测前执行标记为1的用例,执行通过的用例打上签名。标记>50%后方可提测。
产品执行
测试执行
资料地址
百度脑图:http://naotu.baidu.com (可用同一用户多点登陆同步编辑,但一份文档不可多用户共享编辑)