软件测试——测试用例审查

当测试工程师准备测试用例时，他或她可能会跳过一些场景，例如输入错误的数据，编写错误的导航步骤，所有这些都可能对整个测试执行过程产生影响。为避免这种情况，在开始测试之前将进行一轮评估和批准。如果遗漏了一些测试用例并且没有完成审查程序，那么测试用例文档的准确性就会降低。只有在编写完测试用例之后，才必须将所有用例发送给另一个测试工程师（称为审查员）进行审查。在软件测试中，测试用例的检查是一个关键步骤。软件需求规范中列出的每个功能都由测试用例解决。测试用例应该是有效的，并且要遵守测试用例编写指南。应对每个测试用例进行检查，以确保测试的成功和彻底性。在这里，我们将讨论以下几点：

为什么要审查测试用例？
什么是测试用例存储库？
测试用例存储库的好处。
测试用例审查过程。
测试用例审查技术。
查看测试用例时的提示。
测试用例审查期间要考虑的因素。
测试用例审查期间的常见错误。
在审查测试用例时对缺陷进行分类。

为什么要审查测试用例？

任何被视为可交付成果的工作产品都应进行同行评审。测试用例是测试团队的重要可交付成果，包含在此类别中。编写有效的测试用例以在测试过程中成功发现尽可能多的故障至关重要。因此，需要检查以确定是否：

开发测试用例的目的是检测故障，并正确理解需求。
确定潜在影响的领域并进行测试。
测试数据是准确的，涵盖了所有可能的领域类别。有有利和不利的情况。
预期的行为被准确记录。
测试覆盖率足够。

什么是测试用例存储库？

保持测试用例井井有条会带来丰厚的回报，尤其是在大中型项目中。此外，测试是一个可以重复的过程。每个人都可以从重用测试用例中受益，因为它可以节省时间。项目的大元素可以重复进行测试。维护测试用例存储库允许人们根据需要重用过去的测试资源，这有助于节省时间。好消息是，保持一个组织良好的测试用例存储库一点也不难。构成测试周期基础的测试用例的数量和种类通常与软件测试团队的成功有关。测试用例的同化可能需要大量的时间和精力，主要重点是为每个应用程序创建一个完整的测试用例存储库。存储库中的测试用例涵盖工作流执行和事务中的所有基本排列和组合，确保涵盖所有系统和用户交互。

测试用例存储库是所有基线测试用例（创作、审查和授权）的集中存储区域。
当客户提供需求时，开发人员开始构建模块，测试工程师开始编写测试用例。
授权的测试用例存储在测试用例存储库中。
如果测试工程师希望测试应用程序，他或她必须使用测试用例存储库来获取测试用例。
如果我们不需要测试用例，我们可以从测试用例存储库中删除它们。
我们为每个版本都有一个单独的测试用例存储库。
没有测试主管的授权，一旦测试用例被基线化或保存在测试用例存储库中，就不能修改或更改测试用例。
如果发生影响软件的崩溃，测试团队始终拥有测试用例存储库的完整备份。

此外，由于测试用例存储库会随着时间的推移而增加，因此测试人员应使其与业务应用程序或软件产品的每个新版本保持同步。如果不这样做，它将随着时间的推移与软件的实际函数和行为失去同步。因此，后续 QA 周期的结果将受到影响。

测试用例存储库的好处

以下是测试用例存储库的一些好处：

如果出现新内容，可以更新存储库。
节省时间。
测试人员的测试用例编写技能是基于性能评估的。
覆盖范围。
协助报告。
可追溯性。
可以创建图表来显示测试用例的状态（通过、失败、未测试）。
可以协助开发新的类似项目。
更少的数据从一名测试人员传递到另一名测试人员。

测试用例审查过程

以下是审查过程中涉及的活动列表：

1. 计划：这是第一阶段，从作者请求审核过程的主持人开始。版主负责安排评审的日期、时间、地点和邀请。进行条目检查以确保文档已准备好进行审核并且没有大量缺陷。一旦文档清除条目检查，作者和主持人决定要审查文档的哪个部分。

2. 启动：这是审查过程中的一个可选步骤。目的是向会议中的每个人简要介绍审查和文件的目标。

3. 准备：审阅者使用提供的相关文件、程序、规则和清单来审阅文件。每个参与者在审查时根据他们对文档的理解识别缺陷、问题和评论。

4. 评审会议：评审会议由三个阶段组成——

记录阶段：在准备阶段发现的问题和缺陷逐页记录。记录由作者或抄写员完成，其中抄写员是进行记录的人。应记录每个缺陷及其严重性。
讨论阶段：如果有任何缺陷需要讨论，那么它们将在此阶段记录和处理。讨论的结果被记录下来以供将来使用。
决策阶段：参与者必须对正在审查的文件做出决定。

5. 返工：如果每页发现的缺陷数量超过一定水平，则必须对文档进行返工。

6. 跟进：版主检查以确保作者已对所有已知缺陷采取措施。

测试用例审查过程

测试用例评审技术

进行测试用例审查的三种技术：

自检：由编写测试用例的测试人员进行。通过查看 SRS/FRD，他可以查看是否满足所有要求。
同行评审：这是由另一位不熟悉被测系统但尚未开发测试用例的测试人员完成的。 Maker 和 Checker 是同一事物的另外两个名称。
监督审查：这是由比编写测试用例的测试人员级别更高的团队负责人或经理完成的，并且对测试的需求和系统有广泛的了解。

查看测试用例时的提示

以下是在查看测试用例时要牢记的一些提示：

在审核过程中，最好坚持版本号。例如，如果第一次查看测试用例计划，请将其设为 v.1。测试人员完成所有更改后，重新审核并使其成为 v.1.1。通过这种方式，人们将能够分辨出哪一个是最新的，并且会完整记录计划的变化。
始终最好与测试人员面对面会面，以确保他完全理解所有评论输入。
如果可能，请在 SUT（被测系统）上运行测试用例，以更好地了解执行过程中涉及的结果和操作。
在阅读测试用例以供参考时，最好随身携带一份 SRS/FRD 副本。
如果您不确定测试用例或预期结果，请在做出决定之前咨询客户或您的主管。

测试用例审查期间要考虑的因素

在审阅期间，审阅者在测试用例中查找以下内容：

1. 模板：审核者确定模板是否符合产品的要求。

2、表头：表头会检查以下几个方面：

是否所有的品质都被捕获是有争议的。
是否所有特征都相关是值得商榷的。
是否满足所有特征取决于您。

3.正文：查看测试用例正文中的以下组件：

测试用例的编写方式应使执行过程花费尽可能少的时间。
是否涵盖所有可行的情况是有争议的。
寻找具有最大测试覆盖率的流程。
是否使用测试用例设计技术。
测试用例应该易于理解。

TestCaseName	Step No	Reviewer		Author Comments	Comments
		Comments	Severity
ST100 CNNB-ET001	7	Module Not Linked	Critical		Precondition is Required
ST200 SNNC-XD007	45	Invalid Parameter	Major	Fixed	——–
NJ120 BKKL-PP330	18	Unused Variable	Minor	Fixed	———
	07	Need more input value	Major	Not Fixed	——–

4.文本执行报告：

它是测试负责人在完成所有测试后生成的最后一份文档。
测试执行报告定义了应用程序的稳定性，并包括诸如编写、运行、通过和失败的案例数量以及它们的百分比等数据。
测试执行报告是最终的总结报告，它定义了应用程序的质量并帮助确定程序是否可以移交给客户。
每个模块都有自己的电子表格来跟踪其进度。

Module Name	Total Test Cases	Total Test Cases Executed	Total Test Case Passed	Total Test Case Failed	Pass%	Fail%
Marketing	110	110	100	10	90%	10%
Payment	200	200	150	50	75%	25%
Production	70	70	70	0	100%	0%
Sales	100	90	45	45	50%	50%
Loans	120	120	100	20	80%	20%
Total =	600	590	465	125	65%	35%

该报告由测试负责人编写，测试工程师提交了他或她测试和实现的特定功能。

此报告由测试负责人发送到以下地址：

开发团队。
管理。
测试经理。
顾客。

开发团队需要失败的测试用例列表。有一个测试用例名称、相关状态和注释的列表，如下表所示。销售测试用例的数据如下表所示——

Step Number	Test Case Name	Test Case Status	Comments
1	ST100 CNNB-ET001	Pass	–
2	ST200 SNNC-XD007	Pass	–
3	ST200 SNNC-XD007	Failed	Bug
.
.
.
.
98
99
100

测试用例评审过程中的常见错误

以下是在测试用例审查过程中检查的一些常见错误：

拼写错误：拼写错误有时会引起很多混乱或使陈述难以理解。
测试用例的复制：它涉及减少冗余测试用例。两个或多个测试用例可能正在测试同一个项目，并且可以合并为一个，从而节省时间和空间。
标准/指南：在审查过程中检查是否所有的标准和指南都得到了正确的遵守，这一点至关重要。
冗余：当测试用例由于需求变化或某些调整而过时时，称为冗余。必须消除这些类型的测试场景。
使用方式：测试用例应该用基本的、易于理解的语言编写。
语法：如果语法不正确，测试用例可能会被误解，从而导致错误的发现。
模板格式：遵循合适的模板，以后可以简单的添加/修改测试用例，测试用例计划呈现井然有序。

审查测试用例时对缺陷进行分类

当这些检查表被一致使用并发现问题时，建议将缺陷分类为以下类别之一：

不完整的测试用例。
缺少负面测试用例。
没有测试数据。
不适当/不正确的测试数据。
不正确的预期行为。
语法问题。
错别字。
不一致的时态/声音。
不完整的结果/测试运行次数。
测试用例中没有记录缺陷信息。

如果没有彻底审查测试用例，缺陷可能会潜入生产环境。因此，可能会报告生产问题，从而影响软件的质量。如果在测试阶段发现问题，此时解决问题将比修复问题要昂贵得多。