也许是因为统计质量管理中发现了需求的问题占到整个软件缺陷50%-60%的原因，大家都习惯性的把焦点放在评审SRS这个重要的静态测试活动上面了。然而测试用例才是我们测试执行的最终依据——需求写的再好，测试用例没有写好，一切都是白搭！

　　而这，恰恰是流程改进中必须浓墨重彩的一笔！下文同样取自一网友博文，并适当做了补充和修润（粗体部分）：

　　测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面，测试验证的更充分（特别是对于潜藏的业务规则变化和后台数据变化等用户角度难以观测到的悄无声息的改变）；对于测试工程师来说，这也是一个快速提高用例设计能力的过程。

　　1、需要评审的原因

　　测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例编写人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。此外，测试用例涉及大量对业务规则的验证，对后台数据变化的验证（甚至要精确到关联到哪些数据库表，修改了哪些数据库表的字段，字段值被改为什么），而这些单凭一份需求规格说明书（SRS或PRD）或是验收合同根本无法满足我们的“测试需求”。

　　2、进行评审的时机

　　一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审（有些公司实际上以“验证点”或“测试点”的形式出现，也可能会出现在测试方案评审中）；第二是在整个详细用例全部完成之后（也就是包含具体的预置条件、步骤、预期结果等内容）进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。再次要强调的是此时的关注点除了传统的对需求覆盖的校验之外，还要集中火力评审每一个验证细则，即我们前面提到的业务规则变化、后台数据变化等“用户看不见”容易被忽略的部分。

　　3、参与评审人员

　　这里会分为多个级别进行评审。

　　1) 部门评审，测试部门全体成员参与的评审。

　　2) 公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。

　　3) 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

　　4、评审内容

　　评审的内容有以下几个方面：

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

　　2) 优先级安排是否合理。

　　3) 是否覆盖测试需求上的所有功能点。

　　4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和预期结果是否清晰、正确；预期结果是否有明显的验证过程（比如对于业务规则变化的具体陈述，或是对于数据库表验证的具体SQL语句，或是后台日志的生成内容的具体描述）。

　　5) 是否已经删除了冗余的用例。

　　6) 是否包含充分的负面测试用例。充分的定义，如果在这里使用二八法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。

　　7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。

　　8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。或将重复度高的用例抽取出来定义为一些可复用的用例模板（参照HP Quality Center的template概念）。

　　个人认为，一个“健康”的测试用例至少要通过前5个标准。

　　5、评审的方式

　　1) 召开评审会议（通常建议采用正规检视方式）。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。

　　2) 通过邮件与相关人员沟通

　　3) 通过IM工具直接与相关人员交流

　　4)通过缺陷管理工具与项目成员沟通（目前不少企业开始采用TD/QC之类的测试管理平台将评审这一静态测试活动发现的bug同样汇总在BUG管理系统中）

　　方式只是手段，得到其它人员对于用例的反馈信息才是目的。

　　无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

　　6、评审结束标准

　　在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。

版权声明：本文出自songfun的51Testing软件测试博客：http://www.51testing.com/?35

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。