编写测试用例是在实际测试执行开始之前进行的软件测试活动的重要组成部分。因此，在编写测试用例时必须头脑清晰地理解需求。测试执行阶段的顺利程度主要取决于测试用例的编写质量，还取决于对需求的理解程度。理论上来讲应避免在测试用例中放入不必要或不需要的细节，但放入必需和重要的细节反而又会起着重要的作用。

具有所需详细细节的测试用例优点：

良好的测试用例可以减少对测试人员的依赖

想象一下这样的情况，编写测试用例的人在完整的测试执行阶段或部分测试执行阶段都不可用。在这种情况下，如果测试用例本质上是独立的，并且包含成功完成测试执行所需的所有相关测试详细信息，那么很容易让其他测试人员参与执行活动。另外，当其他团队成员直接参与执行阶段时，可以帮助您编写良好的测试用例，从而减少对主测试人员的依赖。

查看编写良好的测试用例要容易得多

在理想的测试环境中，所有测试用例都必须由利益相关者进行评审，以防止最终出现测试用例遗漏的情况。如果用简单的语言编写测试用例而不跳过任何步骤，那么它们将易于理解并提供反馈。

详细的测试用例有助于开发重现缺陷

如果一个测试用例执行失败并引发缺陷，则将编写良好的测试用例与缺陷ID链接也可以帮助开发人员重现缺陷并了解问题所在。这将缩短解决BUG的时间，从而加快总体测试速度。

良好的测试用例可以作为培训资源

如果没有足够的培训材料来培训新的团队成员，并使他们更快地入职，那么具有适当详细信息的测试用例将有助于新测试人员轻松浏览应用程序并获得所需的资料。这再次减轻了高级测试人员的负担，可以培训新成员接受有关正在测试的应用程序的次要主题的培训。

良好的测试用例中应包括的相关细节：

  • 精确的测试用例名称–测试用例名称不应太长，但应简要定义和说明测试用例的用途
  • 测试ID –应该为测试用例分配唯一的测试ID
  • 先决条件–如果在开始执行测试用例之前需要满足任何先决条件，则应提及
  • 测试步骤–应编写清晰明了的测试步骤，因为这些步骤类似于测试人员需要遵循的命令。对于需要做什么，应该清楚地遵循。
  • 测试数据–如果有任何特定的测试数据应作为应用程序的输入提供。它可能用于边界值分析，也可能用于测试某些计算是否由应用程序正确完成。
  • 预期结果–完成测试步骤并提供所需的测试数据后，应清楚说明应用程序的期望值或应用程序应如何响应。
  • 实际结果–实际结果是执行测试步骤时观察到的行为。应该对此进行记录并与预期结果进行比较。
  • 最终结果–根据实际结果是否与预期结果相符，应将测试步骤标记为通过/失败
  • 缺陷ID –如果测试步骤失败，则应针对该缺陷提出缺陷，并在测试步骤中注明缺陷ID。这对跟踪缺陷很有帮助。
  • 注释–如果在特定测试步骤中有任何后续项目可用，则可以输入注释
  • 需求ID –在适用的情况下，应在测试步骤/案例中放置需求ID，这也有助于确保测试案例涵盖了所有需求。

更有利于自动化

如果需要将应用程序的某些或大部分部分自动化，则带有详细细节的测试用例将非常有用。自动化团队通常在组织中的不同测试团队之间共享。因此，与手动系统测试员不同，自动化测试员对被测试的应用程序没有深入的了解。因此，需要对它们进行指导，或者必须将足够的详细信息传递给它们，以便他们能够成功创建自动化脚本。编写良好的测试用例有助于指导自动化测试人员，并节省大量时间和沟通成本。

测试用例可作为证据

测试用例不仅在测试执行阶段被编写为指导，而且具有长期服务的目的。最重要的目的之一是充当测试人员进行的测试的证据。如果在生产环境或更高的测试环境中遇到过缺陷，它还有助于追溯缺陷。测试人员还可以通过找出导致产品缺陷的真正原因。

虽然写下具有适当数量的详细信息的测试用例具有许多长期利益，但是在某些情况下，在测试用例中放置过多的详细信息可能会产生不利影响，例如：

时间紧迫的情况

在实际测试时，并非所有情况都是理想的。因此，可能存在这样的情况，即测试人员没有足够的时间来记录粒度的测试用例。可能是因为时间紧迫。在这种情况下，一旦理解了需求，测试人员就必须立即执行。因为只有在执行过程中才会发现缺陷。

临时或一次性测试

如果必须以最少的预算进行一次性测试或临时测试，则主要重点应放在测试执行上。

重要的是不要失去对不必要细节的关注

具有不必要细节的测试用例往往失去对测试用例主要目标的关注。无论在测试用例中输入的详细信息如何，都应始终与测试用例的主要目标相关联。

总结

编写测试用例的行为应该是一个平衡的活动，并且应该牢记重要点，例如可以写下测试用例的时间，需要重用测试用例，利益相关者的期望以及其他可用文档与项目等。