全国咨询热线：136-9172-9932
当需求基线确定后，测试工程师即开始设计测试计划、测试方案和编写测试用例，测试用例设 计完成后，是否代表该测试用例已经达到要求了呢？不管从研发流程还是从软件质量控制角度来 说，此时的测试用例都不能归档，必须进行测试用例评审，只有评审后的测试用例才能归档。 从研发流程角度来说，在整个研发过程中要求每个过程必须有相应的检查点，这样才能确保软 件质量可控制。从质量保证角度来说，也要求测试用例进行评审，因为测试是验证系统需求是否被 实现的过程，提高测试的覆盖率显然可以更好地保证软件的质量，测试用例的评审更像是集多人的 思想来提高测试的覆盖率。因此，从这两个角度来说，测试用例设计完成后都必须进行评审。 测试用例的评审形式一般有两种：一种是正式会议评审，另一种是非正式会议评审。正式会议 评审要求必须执行同行评审的流程，评审的专家主要是项目组的相关成员，即测试工程师、开发工 程师、需求工程师、项目经理、QA 工程师等。对于非正式会议评审则可以不必那么正式，可以是 项目组中的测试工程师对彼此的用例进行检查，或者组织一个非正式的会议。 测试用例评审的目的有以下几个方面：
（1）提高测试覆盖率。 通过对测试用例评审，完善测试的覆盖率。因为在评审过程中，不同评审专家看待问题的角度 不完全一致，所以可以更充分地考虑测试的方法，扩充测试用例的全面性，这样可以更好地确保基 本功能和核心功能的测试覆盖率，进而提高软件质量。 （2）确保需求的可追溯性，复审需求。 通过测试用例的评审，可以确定每个需求是否都有测试用例与之对应，只有每个需求都是相应 的测试用例与之对应才能保证测试的全面性，同时也相当于对需求进行了一次复审，通过评审测试 用例可以反过来验证需求设计是否合理、是否存在遗漏等情况。 （3）开发工程师可带入新的测试角度。 由于开发工程师对业务的处理流程很清楚，这样在评审测试用例时，可以对设置的参数和流程 提出新的测试用例，进而从逻辑角度来改善测试用例覆盖的情况。 （4）预防缺陷，改善开发质量。 在对测试用例的评审过程中，可以开拓开发工程师对代码逻辑的思维，弥补以前设计过程中存 在的缺陷，将潜在的缺陷挖掘出来，这样可以进一步预防缺陷的发生，进而改善软件质量。 在评审测试用例时主要关注规范性规则、内容符合性、质量目标和其他方面，具体的检查点如下：
（1）规范性规则。 1）用例是否按照公司规定的模板进行编写。 2）用例的编号是否符合规范命名要求（项目缩写－子特性－ST－测试类型－编号，如 HaiDaTicket-Login-ST-Func-001）。 3）用例与方案中的用例是否一致，或者是否完全覆盖方案中描述的所有系统测试项。 4）是否更新了需求跟踪矩阵，用例编号和需求跟踪矩阵中的用例编号是否一一对应。 5）用例是否覆盖了基线化后的 SRS。 6）用例设计是否按照测试计划安排的时间完成。 7）用例对新增或者变更的需求是否做了相应的调整。 （2）内容符合性。 1）用例设计是否考虑了正向和反向两方面的情况。 2）用例是否可测试。 3）用例的重要级别和优先级是否定义合理。 4）用例是否清晰地描述了测试用例的标题。 5）用例是否清晰地描述了预置条件。 6）用例是否清晰无二义地描述了操作步骤。 7）用例是否清晰描述了用例的输入且输入（测试数据）的准备是否有相关的描述。 8）用例是否清晰地描述了预期结果以及预期结果是否可以验证。 9）用例设计是否使用了等价类分析、边界值、因果图、判定表、错误推测、正交分析、流程 分析、状态迁移分析、输入域覆盖、输出域覆盖等测试用例设计方法？是否针对不同的测试特性设 计使用合适的设计方法。 10）重点特性用例设计是否结合了多种方法来设计，是否过滤掉了重复的测试用例。 11）用例中需要进行打印输出（如报表）、表格的导入、导出是否说明了打印位置、表格名称、 指定数据库表名或文件位置；表格和数据格式是否有说明或附件。 12）测试用例的预期结果是否唯一，即一个测试用例不可能出现多种测试结果。 13）预置条件是否正确。 14）测试用例中数据输入是一个固定值还是一类值（一般输入应为一类值，如输入用户名为 test，这样可以引导测试执行工程师进行思考，从而发现更多的缺陷）。 15）测试用例是否存在冗余。 16）业务流程的路径是否全部覆盖。 17）每个测试用例的步骤不应该超过 12 步。 18）对于核心和基本功能，每条基本路径应该覆盖到。 19）对升级的功能，在评审时需要重点关注。 （3）质量目标。 1）用例覆盖率（如用例个数/KLOC）是否达到相应质量目标。
2）用例评审发现的缺陷率（缺陷总数/用例总数）是否达到了相应的质量目标。 3）用例的粒度是否合理和统一，是否均匀覆盖了测试需求。 4）用例发现的问题是否占整个测试执行发现问题的 80%（当然越高越好）以上（事后验证）。 5）测试用例设计的时间占整个系统测试过程的时间是否合理（一般在 30%～40%，这里排除 一些专项测试，如稳定性测试、长时间测试等）。 （4）其他方面： 1）测试执行过程中发现用例不完善时是否做相应的调整。 2）由于软件版本的升级，用例是否做相应的调整。 由于一个完整的项目测试用例数量比较多，如果每个测试用例都评审，那么将花费很大的工作 量，一般情况下测试用例评审的策略分以下三种： （1）完全评审。 完全评审是指对整个项目中的所有测试用例进行评审。这种评审方式的优点是可以对所有的用 例都进行评审，进而完善测试用例质量；但同样缺点也很明显，完全评审需要更多的时间和精力， 那么在工作中可能很难有充裕的时间进行完全评审。这种评审方式适用于新的项目，对于一个新的 项目来说，为了保证软件质量，必须对所有的测试用例进行充分的评审。 （2）有选择性的评审。 有选择性的评审，即不对所有的测试用例进行评审，只对部分测试用例进行评审。该方法的优点 是使用最少的时间对最重要功能的测试用例进行评审；缺点是未评审的测试用例无法完全保证质量。 该方法更适用于维护产品，假设当前的版本是升级的版本，只修改了部分功能，那么评审测试用例的 时候可以将重点转向这些新添加的用例，以前评审过的测试用例则可以不用花费过多的时间进行评审。 （3）指标评审法。 指标评审法是指研发流程中规定每个项目测试用例的评审覆盖率需要达到多少（如 60%等）。 指标评审法使用较少，因为指标评审法很容易导致为了达到指标而评审，并不一定能真正提高测试 用例质量，所以经常将指标评审法与有选择的评审合并使用。 不管使用哪种方法进行评审，对于客户经常使用到的功能和业务流程一定要详细地评审，一定 要将所有可能的路径全部覆盖，因为这类功能如果存在缺陷，被投诉的概率就很大。
