测试评审

一、评审目的

1、提高测试覆盖率

2、确保需求的可追溯性，复审需求

3、预防缺陷，改善开发质量

4、降低返工成本

向产品、开发阐述测试人员对需求的理解，如理解不一致，可提前发现，避免在进入测试阶段后才发现，降低返工成本

二、评审流程

①用例评审→②问题跟踪→③结束评审（如评审不通过，重新评审）

三、用例评审

1、开始

（1）测试人员根据测试思路和用例结合需求原型和设计文档进行测试策略的讲解，评审人员进行评审；

（2）过程中提出当前功能的所有疑问点，相关评审人员进行回复。

2、评审内容

（1）测试思路是否合理，对于不合理，指出不合理的地方并提出意见

（2）测试是否有缺失点，有，有哪些，明确指出具体位置和功能

（3）测试提出的疑问是否为有效问题，有，是什么问题，如何解决

（4）参审人员是否有自己需要补充的地方，有，补充问题

（5）测试用例是否有结构性，流程性，比如根据用户的操作流程，或者测试整体的构思

（6）当前测试人员和研发人员随时做好所有争论问题记录和解决方案，后续对功能进行拓展和删减；

（7）用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖；

（8）优先极安排是否合理；

（9）是否覆盖测试需求上的所有功能点以及用户的交互流程；

（10）用例是否具有很好可执行性。

例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法；

（11）是否有无效冗余的用例。有哪些，此处研发需要注意；

（12）是否包含充分的负面测试用例。

（13）是否简洁，复用性强。

例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤；

（14）是否能够形成有效的：冒烟测试（门槛用例冒烟），回归测试，系统测试。

3、结束

（1）评审内容进行评审完毕

（2）对测试用例无争论存在

（3）有争论考虑是否给出二次评审计划和时间

（4）功能预期实现定义，按照此次沟通实现，或者需要重新考虑和设计处理（可分为一期，二期，三期后续加强）

（5）测试，项目经理和对应开发人员做好信息记录。

四、问题跟踪

评审会议后，针对用例评审问题清单，需及时修改测试用例。

完成修改后，发给评审成员确认，评审结束。否则采取二次甚至多次评审。

五、结束评审

评审结束后，测试经理整理测试用例评审报告、并发给项目总监，同步至协作中心。

六、评审标准