广东建设监理协会网站题库,自己怎么样做网站,产品类网站,免费的黄冈网站代码编写测试用例是在实际测试执行开始之前进行的软件测试活动的重要组成部分。因此#xff0c;在编写测试用例时必须头脑清晰地理解需求。测试执行阶段的顺利程度主要取决于测试用例的编写质量#xff0c;还取决于对需求的理解程度。理论上来讲应避免在测试用例中放入不必要或不…编写测试用例是在实际测试执行开始之前进行的软件测试活动的重要组成部分。因此在编写测试用例时必须头脑清晰地理解需求。测试执行阶段的顺利程度主要取决于测试用例的编写质量还取决于对需求的理解程度。理论上来讲应避免在测试用例中放入不必要或不需要的细节但放入必需和重要的细节反而又会起着重要的作用。具有所需详细细节的测试用例优点良好的测试用例可以减少对测试人员的依赖想象一下这样的情况编写测试用例的人在完整的测试执行阶段或部分测试执行阶段都不可用。在这种情况下如果测试用例本质上是独立的并且包含成功完成测试执行所需的所有相关测试详细信息那么很容易让其他测试人员参与执行活动。另外当其他团队成员直接参与执行阶段时可以帮助您编写良好的测试用例从而减少对主测试人员的依赖。查看编写良好的测试用例要容易得多在理想的测试环境中所有测试用例都必须由利益相关者进行评审以防止最终出现测试用例遗漏的情况。如果用简单的语言编写测试用例而不跳过任何步骤那么它们将易于理解并提供反馈。详细的测试用例有助于开发重现缺陷如果一个测试用例执行失败并引发缺陷则将编写良好的测试用例与缺陷ID链接也可以帮助开发人员重现缺陷并了解问题所在。这将缩短解决BUG的时间从而加快总体测试速度。良好的测试用例可以作为培训资源如果没有足够的培训材料来培训新的团队成员并使他们更快地入职那么具有适当详细信息的测试用例将有助于新测试人员轻松浏览应用程序并获得所需的资料。这再次减轻了高级测试人员的负担可以培训新成员接受有关正在测试的应用程序的次要主题的培训。良好的测试用例中应包括的相关细节精确的测试用例名称–测试用例名称不应太长但应简要定义和说明测试用例的用途测试ID –应该为测试用例分配唯一的测试ID先决条件–如果在开始执行测试用例之前需要满足任何先决条件则应提及测试步骤–应编写清晰明了的测试步骤因为这些步骤类似于测试人员需要遵循的命令。对于需要做什么应该清楚地遵循。测试数据–如果有任何特定的测试数据应作为应用程序的输入提供。它可能用于边界值分析也可能用于测试某些计算是否由应用程序正确完成。预期结果–完成测试步骤并提供所需的测试数据后应清楚说明应用程序的期望值或应用程序应如何响应。实际结果–实际结果是执行测试步骤时观察到的行为。应该对此进行记录并与预期结果进行比较。最终结果–根据实际结果是否与预期结果相符应将测试步骤标记为通过/失败缺陷ID –如果测试步骤失败则应针对该缺陷提出缺陷并在测试步骤中注明缺陷ID。这对跟踪缺陷很有帮助。注释–如果在特定测试步骤中有任何后续项目可用则可以输入注释需求ID –在适用的情况下应在测试步骤/案例中放置需求ID这也有助于确保测试案例涵盖了所有需求。更有利于自动化如果需要将应用程序的某些或大部分部分自动化则带有详细细节的测试用例将非常有用。自动化团队通常在组织中的不同测试团队之间共享。因此与手动系统测试员不同自动化测试员对被测试的应用程序没有深入的了解。因此需要对它们进行指导或者必须将足够的详细信息传递给它们以便他们能够成功创建自动化脚本。编写良好的测试用例有助于指导自动化测试人员并节省大量时间和沟通成本。测试用例可作为证据测试用例不仅在测试执行阶段被编写为指导而且具有长期服务的目的。最重要的目的之一是充当测试人员进行的测试的证据。如果在生产环境或更高的测试环境中遇到过缺陷它还有助于追溯缺陷。测试人员还可以通过找出导致产品缺陷的真正原因。虽然写下具有适当数量的详细信息的测试用例具有许多长期利益但是在某些情况下在测试用例中放置过多的详细信息可能会产生不利影响例如时间紧迫的情况在实际测试时并非所有情况都是理想的。因此可能存在这样的情况即测试人员没有足够的时间来记录粒度的测试用例。可能是因为时间紧迫。在这种情况下一旦理解了需求测试人员就必须立即执行。因为只有在执行过程中才会发现缺陷。临时或一次性测试如果必须以最少的预算进行一次性测试或临时测试则主要重点应放在测试执行上。重要的是不要失去对不必要细节的关注具有不必要细节的测试用例往往失去对测试用例主要目标的关注。无论在测试用例中输入的详细信息如何都应始终与测试用例的主要目标相关联。总结编写测试用例的行为应该是一个平衡的活动并且应该牢记重要点例如可以写下测试用例的时间需要重用测试用例利益相关者的期望以及其他可用文档与项目等。郑重声明文章首发于公众号“FunTester”禁止第三方(腾讯云除外)转载、发表。技术类文章精选非技术文章精选
