测试用例的评审和变更

  测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。

   首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。

   如果是测试组内部的评审，应该着重于：

   1.测试用例本身的描述是否清晰，是否存在二义性；

   2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

   3.是否针对需求跟踪矩阵，覆盖了所有的软件需求；

   4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

   如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如收集客户需求的人员注重你的业务逻辑是否正确，分析软件需求规格的人注重你的用例是否跟规格要求一致，开发负责人会注重你的用例中对程序的要求是否合理。

   测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面对于测试工程师来说也是一个提高用例设计能力的过程。

   1、需要评审的原因

   测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。

   2、进行评审的时机

   一般会有两个时间点。，是在用例的初步设计完成之后进行评审第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能增加对用例设计进行评审，提前发现其中的不足之处。

   3、参与评审人员

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

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

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

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

   4、评审内容

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

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

   2)极安排是否合理。

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

   4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。

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

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

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

   8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

温馨提示：为了不影响您的时间，来校区前或者遇到不明白的问题请先电话咨询，方便我校安排相关课程的专业老师为您解答，选取适合您的课程。以上是秦皇岛达内教育的小编为您分享的关于测试用例的评审和变更的内容,希望可以为同学们提供帮助，更多软件测试资讯请持续关注秦皇岛达内教育。（来自51testing网）