【技术干货】软件测试用例管理（下）_用例图的变更原因

 

4.1.2 测试用例评审管理

测试用例评审目的是为了确保测试工程师与产品团队其他成员对需求的理解保持一致，不存在二义性，减少测试过程中无效用例、无效缺陷的产生。

 

大部分情况下，每条用例都由测试或开发工程师独自完成，对于需求、技术的理解与掌握程度不同，可能导致用例质量不同。

 

因此，需要进行有效的评审。敏捷测试过程中，项目团队所有成员都应该参与用例评审活动，并且时间控制在30分钟左右。

 

01.评审内容

 

测试用例评审内容，应当关注以下方面：

 

（1） 产品、开发、测试确认用例是否符合产品需求设计；

 

（2） 确认测试用例逻辑是否正确；

 

（3） 确认测试用例期望结果对产品实现的要求是否合理；

 

（4） 用例优先级设置是否合理；

 

（5） 测试用例是否根据测试规范设计，用例描述是否清晰，是否存在二义性；

 

（6） 敏捷用例每条步骤是否有明确的预期结果，是否关注用户的期望价值。

 

02.评审时机

 

因敏捷开发中每个项目的周期相对较短，版本迭代快，因此建议测试用例评审活动定在每天完成。

 

评审前，测试工程师应当根据任务分配及时间节点规划完成相关用例设计。如果项目时间紧迫，可将当前项目的所有用例设计完成后再开展用例评审活动。

 

03.评审步骤

 

测试用例设计完成，项目经理或测试工程师组织评审会议。其常用流程如下：

 

（1） 项目经理提前2小时与测试工程师确认待评审用例全部完成，如未完成，则取消本次评审活动，且当天不得再提出评审会议，除非项目经理批准；

 

（2） 项目经理通知项目团队成员参加评审会议；

 

（3） 测试工程师根据测试用例优先级逐条讲解测试用例；

 

（4） 记录员记录评审过程中出现的问题；

 

（5） 过程中产生的问题讨论超过3分钟，则项目经理中断讨论，另行处理；

 

（6） 会议结束后测试工程师确认问题解决工时以及第二次评审会议时间；

 

（7） 会议结束后记录员整理问题并邮件发送问题；

 

（8） 问题责任人解决问题；

 

（9） 测试工程师确认问题修复，发起第二次评审。

 

用例评审活动，与同行评审活动类似，会议上只发现问题，不解决问题。

 

4.1.3 测试用例变更管理

 

测试用例设计完成经过评审后，可根据Sprint计划实施执行，但随着需求变化、设计变更或者测试工程师的思维变化，需要做出变更，测试工程师应当制定用例变更规则。

 

通常引起测试用例更新的原因有如下几点：

 

01. 需求变动

 

产品团队可能在产品开发过程中，提出了新的需求，或者对已经存在的需求提出变更。

 

02.用例完善

 

可能由于刚开始的考虑不周，导致一些用例的设计并不是很妥当，经过对需求的再次详细理解及询问开发、业务人员，对需求有了新的认识，认为有必要再添加新的用例来进行测试，增加测试用例的覆盖度，此时也可以进行用例的更新。

 

03.缺陷引起用例更新

 

测试用例执行过程中，可能发现了一些缺陷，通过最后对缺陷的分析，发现之所以出现这些缺陷，是因为测试用例的设计缺陷造成的。

 

所以，反过来需要重新设计测试用例，避免缺陷的误提。当然，软件版本的更新也可能引起用例的更新。

 

04.设计文档变更

 

开发工程师设计文档的变更，往往会带来测试用例的变更，比如第三点，如果“商品类别名称”的字段大小改成了“Varchar（100）”，那么对应的用例就应该改为“输入类别名称超过100个字符，进行商品类别添加操作”。

 

测试用例评审前，测试工程师可随时变更自己所设计的测试用例，一旦评审通过，因某种原因需变更测试用例时，测试用例设计者应向开发团队提出变更申请，并告知变更原因，由项目经理确认变更，不得随意变更。如果变更用例数量超过总用例数的15%时，需重新发起测试用例评审流程。