目录
目的
- 保证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 （可用同一用户多点登陆同步编辑，但一份文档不可多用户共享编辑）