重新测试教程：包含示例与最佳实践的综合指南

重新测试是对先前测试中功能失效的特定特性进行验证的过程。其目的是确认在执行期间报告存在某些缺陷的测试用例是否已得到修复。

在软件开发生命周期中，关键要素包括测试软件的功能、性能、安全性及其他方面，这涉及到检查软件是否存在任何错误。然而，主要挑战在于验证软件是否符合目标用户群体的运行需求。确保开发软件的有效性和可靠性至关重要，而重新测试在此扮演了救星的角色。

软件测试的首要目标是发现软件应用程序中的错误或缺陷。测试工程师负责识别这些问题并向开发团队报告，以便进一步评估。随后，这些问题得到解决，并交由测试工程师进行重新验证。

重新测试确保软件发布过程中不会出现新的问题。该过程可以通过手动执行特定的测试用例集来完成。尽管重新测试涉及的复杂性，我们应将其视为软件测试的基础部分，以交付高质量的产品。

什么是重新测试？

您必须习惯于这样一个事实：在测试软件时发现bug是测试工程师的职责。在执行此类任务时，他们负责修复并将错误或问题发送回开发人员，确保他们修复此类错误或问题。这里就涉及到了重新测试。让我们更清楚地理解这一点。

在软件开发中，回归测试是验证开发者提供的构建是否已修复错误的过程。简而言之，假设你正在测试某个软件的“版本号1”，若遇到任何错误，例如错误ID为A1，那么测试此错误的版本则被称为“版本号2”。

换言之，版本号1中发现的错误将在版本号2中再次进行测试，以检查开发者是否已修复该错误。这里的测试者会重新测试失败的案例，以验证开发者所做的修复。

这是缺陷生命周期的一部分，即对之前测试时未通过、现已由开发者修复的测试案例进行测试。

以下几点有助于深入了解回归测试流程：

• 对应报告的缺陷，重新测试失败的测试案例。
• 回归测试的另一个名称是确认测试。
• 对于新构建中报告的错误，应使用类似的测试数据和流程来验证其可重现性。

A comprehensive example of the retest process will help you get a clearer picture.

为何回归测试如此重要？

作为软件测试生命周期的一部分，回归测试围绕着与产品有效交付相关的多个重要性。无疑，它是标准软件测试过程的主要部分。此外，它为产品提供了额外的保障层，在向最终用户发布前，对其技术和功能性能进行筛查。

在竞争激烈的软件开发市场中，企业应确保提供高质量的数字应用。这要求最终产品的质量不容妥协。

自动化测试平台常能助您为发布的产品获得更佳的投资回报率。然而，通过验证每个漏洞的复测，能给予更多信心。与初次测试过程相比，它既不增加测试资源的额外成本，也不耗费大量时间。众所周知，复测在相同环境下执行，使用与失败测试案例相关的类似数据。

此外，复测过程针对特定应用模块中记录的具体问题或漏洞。因此，无需搭建新的测试环境，也无需投入更多精力通过端到端测试来验证产品质量。

复测示例

尽管上述解释的例子能助您获得初步了解，接下来，我们将深入探讨一个类似案例，以更细致地观察其过程。

场景

作为软件开发流程的一部分，版本2.0已发布。在测试过程中，团队发现并记录了一个缺陷（例如，缺陷2.0.1）。在版本2.1中，需对类似的缺陷2.0.1进行测试（前提是该缺陷在版本2.1的发布说明中被提及），以确保缺陷已被修复。

执行流程

根据Bug生命周期，当Bug被记录后，它会立即被共享或报告给开发团队。随后，其状态标记为“新建”。此时，开发团队将决定接受或拒绝该Bug。

一旦Bug被接受，开发者将修复它，并在下一阶段发布，其状态标记为“准备QA”。目前，测试人员会验证Bug以确定其解决方案。因此，可以说回归测试是一种计划内的测试。

测试人员使用之前构建中的相同测试案例和测试数据。如果没有发现Bug，其状态将被标记为“已修复”。相反，如果Bug未修复，则状态保持为“未修复”。然后，缺陷回归测试文档会与开发团队共享。

为了深入了解回归测试，必须了解其关键特征。这不仅有助于多样化测试，还能扩大软件质量构建的维度。

回归测试的特征

在软件测试中，一流的用户体验遵循迭代过程。为此，保留对回归测试过程关键方面的信息，有助于更优质的应用交付。

以下是其关键特征：

• 它在新构建中实施，使用与之前相同的文档和流程。
• 当特定的测试案例被认为失败时，执行回归测试。
• 当整个软件需要通过回归测试来验证其质量时，回归测试就会发生。
• 自动化重新测试的用例是不可能的。
• 重新测试过程依赖于开发团队，他们负责接受或拒绝缺陷。
• 测试人员会针对功能变更的细微之处进行考量。

何时应执行重新测试？

作为测试人员，决定何时进行重新测试至关重要。答案很简单：首先，你需要考虑项目的规模和特性，这些都需要测试。

例如，如果一个组织拥有广泛的产品线，分布在多个产品中，重新测试就变得很常见。这是因为需要及时发布软件应用，这可能会以多种方式影响系统的其他部分。

在不同情况下，我们可以将重新测试作为流程使用。以下是一些解释：

发现被拒绝的缺陷时

测试人员报告的缺陷多次被开发者拒绝，并标记为“无法重现”。在这种情况下，需要对同一缺陷进行重新测试，以告知开发者该问题是可重现且有效的。

发布说明中强调的缺陷修复需求

在软件开发过程中，当开发团队发布新版本时，重新测试随之进行。此时，测试人员会测试之前报告的缺陷，确保它们已被修复。

客户请求

软件质量是每个组织关注的重要问题。为此，客户可能会要求针对特定用例重新测试，以确保产品质量。

其他场景

值得注意的是，每当修复一个错误时，开发者会创建额外的测试用例。这意味着应该花费更多时间编写测试用例，而非修复它们。尽管你对代码库充满信心，但在每次发布时重新测试应用程序的关键部分仍然至关重要。

例如，新功能可能引发意外行为，且在初次检测中难以发现错误。这种情况只有在测试过程中或根据用户反馈问题显现时才可能被发现。此时，进行“重新测试”以消除对新发现错误的疑虑变得必要。

重新测试的好处

软件应用程序的质量取决于重新测试过程的成功与否。它确保了软件开发生命周期中的应用程序稳定性。

以下是其主要好处：

• 确认错误是否已修复。
• 提升产品和应用程序的开发质量。
• 确保应用程序或产品的运行符合用户期望。
• 由于针对特定问题进行修复，减少了修复错误所需的时间。
• 使用新构建的工作版本，与相同数据和流程配合。
• 无需设置新的测试环境。

尽管重新测试过程具有多项优势，但也存在一些缺陷。让我们从以下章节中了解这一点。

重新测试的缺点

A retest process also has some drawbacks, which can hamper or create challenges in the testing process. Knowing such limitations will help you address those while retesting to avoid any issues.

让我们来看看它们是什么：

• 需要新的构建来验证缺陷。
• 重新测试的测试用例只有在开始时才能获取。
• 无法自动化重新测试的测试用例。
• 重新测试失败的测试用例需要额外的时间和精力。
• 除非发现或修复了错误，否则不能保证重新测试作为测试过程的一部分。

针对重新测试的缺点，可以说对一些测试人员来说，重新测试可能是一个挑战。特别是新测试人员往往会试图寻找替代方法来解决问题。这里，让他们感到困惑的是回归测试这个术语。然而，回归测试和重新测试有着显著的区别。

回归测试与重新测试的区别是什么？

如果你是软件测试领域的新手，你可能会认为“重新测试”和“回归测试”这两个术语相似。然而，事实上它们虽然相关，但各有不同。本节我们将探讨重新测试过程与回归测试的不同之处。

首先，回归测试和重新测试是软件开发过程中软件验证的一部分。重新测试主要在开发特定阶段的末尾进行。换句话说，当你想要确保一个已可运行的产品没有被之前的测试中的错误所困扰时，你会进行重新测试。相比之下，回归测试可以在任何开发阶段执行，以确保特定代码部分的正确运行。

在某些情况下，测试人员可以通过简单地阅读早期的测试输出或报告来运行重新测试，以检查任何问题及其修复情况。也可以通过单独检查早期案例来确保它们得到处理，从而进行全面的调查。然而，回归测试主要是通过制定测试计划并在每个应用程序版本上执行，从最新的版本开始。在这种方法中，必须确保每个应用程序的更改都经过了适当的测试。

以下是关于回归测试和重新测试过程之间差异的一些关键点：

通过一个例子理解回归测试和重新测试

回归测试和重新测试之间的区别可以通过下面的例子来解释。

假设，在银行网络应用程序的登录页面上存在一个问题，客户无法访问他们的账户详细信息。尽管他们被要求再次尝试登录，但他们未能登录到他们的账户。支持团队调查了这个问题，并确保此类事件不再发生。

开发团队对代码进行了调整，以确保在所有浏览器中都能成功登录账户页面。然而，这里的测试不仅涉及登录页面，还要确保代码变更不会影响银行网络应用的其他功能。这种针对修改进行的测试称为回归测试。

再次检查与所做修改相关的问题时，测试团队尝试登录页面，但失败了。支持团队与相关开发人员沟通并说明了问题。然而，开发人员告诉我们问题已经修复。质量保证团队测试网络应用程序以检查问题是否已解决，这称为重新测试。

因此，重新测试在软件测试过程中至关重要，是确保其正常运行的先决条件。

我们强调了重新测试过程的重要性，这让我们了解了它与软件测试的关系。首先，让我们了解一些它在软件测试中的典型应用。以下是重新测试在软件测试中的一些应用：

• 用于纠正需要验证的任何特定错误或缺陷。
• 检查整个系统的运行以验证最终功能。
• 检查系统特定部分的质量。

重新测试的阶段

重新测试过程涉及手动方法，并考虑了测试软件应用程序的主要阶段。

以下是重新测试过程所涉及的阶段：

1. 测试用例的选择 

测试用例选择是一种方法，通过执行测试套件中的特定测试用例来检查软件中的错误是否已被修正。通常，测试用例分为可重复使用和废弃两类，其中可重复使用的测试用例用于进行回归测试。

2. 测试用例的应用

回归测试过程的主要焦点是比较测试用例的预期输出。因此，必须应用具有标准预执行结果表的测试用例。

3. 时间估算

在确定测试用例时，测试人员应考虑回归测试中涉及的总执行时间。诸如测试用例评估等因素可能会增加额外时间。

4. 模块追踪

在测试用例失败的情况下，识别对应错误模块是一个重大挑战。因此，软件部分被划分为不同的独立模块。

为此，针对特定独立模块实施小型测试用例。未显示预期结果的模块被标记为缺陷模块。通过这种方式，实现了缺陷模块的追踪。

5. 模块的回归测试

对缺陷模块进行回归测试，直至其修复。

6. 模块的重新集成

在缺陷模块修复后，将完整的测试用例集成应用于软件。进一步检查软件的工作情况。

如何进行回归测试？

软件应用的回归测试只能通过手动方式进行。如前文所述，主要原因是它仅关注特定缺陷。因此，手动测试方法更为合适，因为它能更准确地执行，而非自动化方法。

要执行回归测试，测试团队应对软件应用的当前状态有深入了解。了解软件的工作原理及如何通过修复错误使其更有效，这有助于简化手动测试过程。

测试人员手动执行测试用例，以验证应用中的更改。这样做是为了确保这些更改不会引入新的缺陷，并且已识别的失败案例在新版本中得到消除。在修改软件、修复缺陷并完成软件测试周期后，可以进行手动回归测试。

以下是手动执行回归测试的步骤：

1. 确定软件应用的更改及需要进行回归测试的区域。
2. 根据更改内容，审查并更新需要回归测试的测试用例。
3. 手动执行已开发的测试用例。
4. 分析实际输出与预期结果，评估更改是否引入了新缺陷。
5. 若发现缺陷，应记录并报告给开发团队。
6. 重复手动回归测试过程，直至所有缺陷得到修复。

然而，你或许会疑惑为何回归测试不能通过自动化方式进行。这其中有多方面原因。让我们从以下内容中获得一些启示：

回归测试能否自动化？

对应用程序进行回归测试无法完全依赖自动化方法，以下是一些常见原因：

• 复杂性：部分失败案例可能源于软件的复杂性，因此这类失败案例难以自动化处理。
• 预期外结果：软件变更可能带来非预期结果，此时失败案例需通过手动测试来验证结果。
• 成本与资源：自动化回归测试流程可能成本高昂，因为它涉及到使用额外的硬件和软件。对于软件中微小变更的成本投入难以合理化。
• 时间限制：自动化回归测试过程耗时巨大，在面临及时发布压力的情况下，手动方法是最佳选择。

进行回归测试时的考量

至此，我们已经理解了回归测试的重要性及其实施方式。然而，在回归测试中存在一些需要关注的有效考量点。以下是需要考虑的几个要点：

• 回归测试过程要求在首次报告的问题修复后，构建新的软件版本。
• 软件送交复测时可能经历代码级变更，因此，在应用发布前进行回归测试至关重要。
• 问题修复后才能确定复测的覆盖范围和范围，因此自动化无法像回归测试那样执行复测。
• 如果在复测中发现的问题依旧存在，应用的开发时间可能会延长。需要进行更全面和策略性的评估来探究根本原因。

尽管复测过程中会遇到挑战，组织仍需专注于测试方法的审慎执行。在云上进行复测能更有效地实现这一点。接下来详细探讨。

如何在云上执行复测？

自动化复测过程并非总是可行，有时需要手动测试以确保软件质量。然而，这在某些情况下可能耗时且不具备扩展性。云测试平台有助于克服与测试基础设施相关的挑战。