回归测试 缺陷管理流程 冒烟测试 什么是回归测试？ 回归测试是一种黑盒测试技术。它用于验证软件中的代码更改不会影响产品的现有功能。回归测试确保产品在新功能、错误修复或现有功能的任何更改下都能正常工作。 回归测试是一种软件测试。重新执行测试用例以检查应用程序以前的功能是否正常工作，并且新的更改没有产生任何错误。 当原始功能发生重大变化时，可以对新构建执行回归测试。它确保即使发生更改，代码仍然有效。回归意味着重新测试应用程序中未更改的那些部分。 回归测试也称为验证方法。测试用例通常是自动化的。测试用例需要多次执行，并且手动一遍又一遍地运行相同的测试用例，既费时又乏味。 回归测试示例 这里我们将通过一个案例来有效地定义回归测试： 考虑一个产品 Y，其中一个功能是触发确认、接受和发送电子邮件。它还需要进行测试以确保代码中的更改不会影响它们。回归测试不依赖于任何编程语言，如Java、C++、C#等。此方法用于测试产品的修改或任何更新。它确保产品的任何更改都不会影响产品的现有模块。验证修复的错误和新添加的功能在软件的先前工作版本中没有造成任何问题。 我们什么时候可以进行回归测试？ 每当修改生产代码时，我们都会进行回归测试。 我们可以在以下场景中执行回归测试，它们是： 1. 当新功能添加到应用程序时。 例子： 网站具有登录功能，允许用户仅使用电子邮件登录。现在提供使用 Facebook 登录的新功能。 2. 当有变更需求时。 3. 缺陷修复时 例子： 假设登录按钮在登录页面中不起作用，并且测试人员报告了一个错误，指出登录按钮已损坏。一旦开发人员修复了错误，测试人员就会对其进行测试以确保登录按钮按预期结果工作。同时，测试人员测试与登录按钮相关的其他功能。 4. 出现性能问题时修复 例子： 加载一个主页需要 5 秒，将加载时间减少到 2 秒。 5. 当环境发生变化时 例子： 当我们将数据库从 MySql 更新到 Oracle 时。 如何进行回归测试？ 当软件维护包括增强、纠错、优化和删除现有功能时，就需要进行回归测试。这些修改可能会影响系统功能。在这种情况下，回归测试变得必要。 可以使用以下技术进行回归测试： 1.重新测试所有： 重新测试是进行回归测试的方法之一。在这种方法中，所有的测试用例都应该重新执行。在这里，我们可以将重新测试定义为测试失败时，我们确定失败的原因是软件故障。报告了故障，我们可以期待修复缺陷的新版本软件。在这种情况下，我们需要再次执行测试以确认故障已修复。这称为重新测试。有些人将此称为确认测试。 重新测试非常昂贵，因为它需要大量的时间和资源。 2.回归测试选择： 在这种技术中，将执行选定的测试用例套件而不是整个测试用例套件。 所选的测试用例套装分为两种情况 可重用的测试用例。 过时的测试用例。 可重用的测试用例可用于后续的回归周期。 过时的测试用例不能用于后续的回归周期。 3. 测试用例的优先级： 根据业务影响、关键和经常使用的功能对测试用例进行优先级排序。测试用例的选择将减少回归测试套件。 什么是回归测试工具？ 回归测试是 QA 流程的重要组成部分；在执行回归时，我们可能会面临以下挑战： 耗时的 回归测试消耗了大量的时间来完成。回归测试再次涉及现有测试，因此测试人员不会兴奋地重新运行测试。 当需要更新任何产品时，复杂回归测试也很复杂；测试的名单也在增加。 沟通业务规则 回归测试可确保现有产品功能仍处于工作状态。与非技术领导者就回归测试进行沟通可能是一项艰巨的任务。高管希望看到产品向前发展，并在回归测试中投入大量时间以确保现有功能正常工作。 确定影响区域 测试用例逐个增加发布 更少的资源 不准确 重复任务 单调的工作 回归测试过程 回归测试过程可以跨构建和发布执行。 跨构建的回归测试 每当错误修复时，我们重新测试错误，如果有任何依赖模块，我们进行回归测试。 例如，如果我们有不同的构建，如构建 1、构建 2 和构建 3，我们如何执行回归测试，它们具有不同的场景。 构建 1 首先，客户将提供业务需求。 然后开发团队开始开发功能。 之后，测试团队将开始编写测试用例；例如，他们为产品的第 1 版发布了 900 个测试用例。 然后，他们将开始实施测试用例。 产品发布后，客户进行一轮验收测试。 最后，产品被移动到生产服务器。 构建 2 现在，客户要求添加 3-4 个额外（新）功能，并提供新功能的要求。 开发团队开始开发新功能。 之后，测试团队将开始为新功能编写测试用例，他们编写了大约 150 个新的测试用例。因此，两个版本的测试用例总数均为 1050 个。 现在，测试团队开始使用 150 个新测试用例来测试新功能。 完成后，他们将在 900 个测试用例的帮助下开始测试旧功能，以验证添加新功能是否损坏了旧功能。 在这里，测试旧功能称为回归测试。 一旦所有功能（新旧）都经过测试，产品就会交给客户，然后客户将进行验收测试。 验收测试完成后，产品将移至生产服务器。 构建 3 在第二次发布后，客户想要删除销售等功能之一。 然后他/她将删除所有属于销售模块的测试用例（大约 120 个测试用例）。 然后，测试其他功能，以验证在删除销售模块测试用例后所有其他功能是否正常工作，并且此过程在回归测试下完成。 笔记： 测试稳定功能以确保它因更改而被破坏。这里的更改意味着修改、添加、错误修复或删除。 在不同的构建或版本中重新执行相同的测试用例是为了确保更改（修改、添加、错误修复或删除）不会在稳定功能中引入错误。 整个版本的回归测试 每当同一项目有新版本时，就会开始回归测试过程，因为新功能可能会影响以前版本中的旧元素。 要了解回归测试过程，我们将遵循以下步骤： Step1 Release#1 中没有回归测试，因为Release#1中没有发生任何修改，因为版本本身是新的。 Step2 当客户提出一些新要求时，回归测试的概念从Release#2开始。 Step3 在首先获得新需求（修改功能）后，他们（开发人员和测试工程师）会在进行影响分析之前了解需求。 Step4 了解新需求后，我们将进行一轮影响分析，以避免重大风险，但问题来了，谁来做影响分析？ Step5 影响分析由客户根据业务知识进行，开发人员根据编码知识进行，最重要的是由测试工程师进行，因为他们具有产品知识。 注意：如果一个人这样做，他/她可能无法覆盖所有影响区域，因此我们将所有人包括在内，以便我们可以覆盖最大影响区域，并且应在发布的早期阶段进行影响分析。 Step6 一旦我们完成了影响区域，那么开发者就会准备影响区域（文件），客户也会准备影响区域文件，这样我们就可以实现影响分析的最大覆盖范围。 Step7 完成影响分析后，开发人员、客户和测试工程师将影响区域文档的Reports#发送给测试主管。与此同时，测试工程师和开发人员正忙于处理新的测试用例。 Step8 一旦测试负责人获得报告#，他/她将合并报告并存储在版本#1的测试用例需求存储库中。 注意：Test case Repository：在这里，我们将保存所有发布的测试用例。 Step9 之后，Test Lead 将借助 RTM从测试用例库中挑选必要的回归测试用例，并将这些文件放置在Regression Test Suite 中。 笔记： 测试负责人会将回归测试用例存储在回归测试套件中，以免进一步混淆。 回归测试套件：这里，我们将保存所有影响区域的测试文档。 回归测试用例：这些是旧版本文本文档的测试用例，需要重新执行，如下图所示： Step10 之后，当测试工程师完成新测试用例的工作时，测试负责人会将回归测试用例分配给测试工程师。 Step11 当所有的回归测试用例和新特性都稳定并通过后，再使用测试用例检查影响区域，直到旧特性加上新特性都耐用，然后才交给客户。 回归测试的类型 不同类型的回归测试如下： 单元回归测试 [URT] 区域回归测试[RRT] 完全或完全回归测试 [FRT] 单元回归测试 [URT] 在此，我们将仅测试更改的单元，而不是影响区域，因为它可能会影响同一模块的组件。 示例 1 在下面的应用程序和第一个构建中，开发人员开发了接受1-15 个字符的搜索按钮。然后测试工程师在测试用例设计技术的帮助下测试搜索按钮。 现在，客户端对需求做了一些修改，并要求搜索按钮可以接受1-35 个字符。测试工程师将仅测试“搜索”按钮以验证它是否需要 1-35 个字符，并且不会检查第一个构建的任何其他功能。 例2 在这里，我们有Build B001，并确定了一个缺陷，并将报告交付给开发人员。开发人员将修复该错误并发送一些在第二个Build B002中开发的新功能。之后，测试工程师只有在修复缺陷后才会进行测试。 测试工程师将识别单击 提交 按钮会转到空白页面。 它是一个缺陷，它被发送给开发人员进行修复。 当新版本与错误修复一起出现时，测试工程师将只测试提交按钮。 在这里，我们不会检查第一个构建的其他功能，而是测试新功能并在第二个构建中发送。 我们确信修复提交按钮不会影响其他功能，因此我们只测试修复的错误。 因此，我们可以说，仅通过测试更改的功能称为单元回归测试。 区域回归测试 [RRT] 在此，我们将与影响区域或区域一起测试修改，称为区域回归测试。在这里，我们正在测试影响区域，因为如果有可靠的模块，它也会影响其他模块。 例如： 在下图中，我们可以看到我们有四个不同的模块，例如Module A、Module B、Module C 和 Module D，它们是由开发人员在第一次构建期间提供用于测试的。现在，测试工程师将识别模块 D 中的错误。错误报告发送给开发人员，开发团队修复这些缺陷并发送第二个版本。 在第二次构建中，先前的缺陷已修复。现在测试工程师明白模块 D 中的错误修复已经影响了模块 A 和模块 C 中的一些特性。因此，测试工程师首先测试已修复错误的模块 D，然后检查模块 A 和模块 C 中的影响区域。因此，这种测试称为区域回归测试。 在进行区域回归测试时，我们可能会面临以下问题： 问题： 在第一个构建中，客户发送了一些需求修改，并希望在产品中添加新功能。需求被发送给两个团队，即开发团队和测试团队。 得到需求后，开发团队开始进行修改，并根据需求开发新功能。 现在，测试负责人向客户发送邮件，并询问他们在进行必要的修改后所有将受到影响的影响区域。因此，客户会得到一个想法，即所有功能都需要再次测试。并且他/她还将向开发团队发送邮件，以了解应用程序中的哪些区域将因新功能的更改和添加而受到影响。 同样，客户向测试团队发送一封邮件，以获取影响区域的列表。因此，测试负责人也会从客户、开发团队和测试团队那里收集影响列表。 这个影响列表发送给所有查看列表并检查他们的功能是否被修改的测试工程师，如果是，则他们进行区域回归测试。影响区域和修改区域均由各自的工程师进行测试。每个测试工程师只测试他们可能因修改而受到影响的功能。 上述方法的问题在于，测试负责人可能无法了解影响区域的全部概念，因为开发团队和客户可能没有太多时间来回复他/她的邮件。 解决方案 为了解决上述问题，我们将按照以下流程进行： 当新版本带有最新的功能和错误修复时，测试团队将安排会议，他们将讨论他们的功能是否因上述修改而受到影响。因此，他们将进行一轮影响分析并生成影响列表。在此特定列表中，测试工程师尝试包含最大可能的影响区域，这也降低了出现缺陷的机会。 当新版本到来时，测试团队将遵循以下程序： 他们将进行冒烟测试以检查应用程序的基本功能。 然后他们将测试新功能。 之后，他们将检查更改的功能。 一旦他们检查完更改的功能，测试工程师将重新测试错误。 然后他们将通过执行区域回归测试来检查影响区域。 使用单元和区域回归测试的缺点 以下是使用单元和区域回归测试的一些缺点： 我们可能会错过一些影响区域。 我们可能会识别错误的影响区域。 注意：我们可以说我们在区域回归测试上所做的主要工作会导致我们得到更多的缺陷。但是，如果我们对完全回归测试进行同样的工作，我们将得到更少的缺陷。因此，我们可以在此确定测试工作的增强不会帮助我们获得更多缺陷。 完全回归测试 [FRT] 在产品的第二个和第三个版本中，客户要求添加 3-4 个新功能，并且还需要修复上一个版本的一些缺陷。然后测试团队会进行影响分析，并确定上述修改将导致我们对整个产品进行测试。 因此，我们可以说测试修改后的特征和所有剩余（旧）特征称为完全回归测试。 当我们执行完全回归测试时？ 当我们有以下条件时，我们将执行 FRT： 当产品的源文件中发生修改时。例如，JVM 是 JAVA 应用程序的根文件，如果 JVM 中将发生任何变化，那么将测试整个 JAVA 程序。 当我们必须执行 n 次更改时。 笔记： 区域回归测试是回归测试的理想方法，但问题是，我们在执行区域回归测试时可能会遗漏很多缺陷。 在这里，我们将借助以下方法解决此问题： 当申请测试时，测试工程师会测试前10-14个周期，并做RRT。 然后在第 15 个周期，我们做 FRT。再次，对于接下来的 10-15 个周期，我们进行区域回归测试，对于第 31 个周期，我们进行完整的回归测试，我们将继续这样。 但是对于发布的最后十个周期，我们将只进行完整的回归测试。 因此，如果我们按照上面的方法，我们可以得到更多的缺陷。 反复手动进行回归测试的缺点： 生产力会下降。 这是一项艰巨的工作。 测试执行没有一致性。 并且测试执行时间也增加了。 因此，我们将采用自动化来解决这些问题；当我们有 n 个回归测试周期时，我们将进行自动化回归测试过程。 自动回归测试过程 通常，每当有多个版本或多个回归周期或存在重复性任务时，我们都会选择自动化。 自动化回归测试过程可以通过以下步骤完成： 注1： 使用某些工具测试应用程序的过程称为自动化测试。 假设如果我们采用Login 模块的一个示例示例，那么我们如何执行回归测试。 在这里，可以通过两种方式进行登录，如下所示： 手动：在这里，我们将只执行一次和两次回归。 自动化：在这里，我们将多次进行自动化，因为我们必须编写测试脚本并执行。 注2：实时，如果我们遇到了一些问题，例如： 问题 处理方式 新的功能 人工测试工程师 回归测试功能 自动化测试工程师 剩余（110 功能 + 版本#1） 人工测试工程师 步骤1 当新版本开始时，我们不去自动化，因为没有我们在上面的过程中理解的回归测试和回归测试用例的概念。 Step1 当新版本和增强开始时，我们有两个团队，即手动团队和自动化团队。 Step3 手动团队将检查需求并确定影响区域并将需求测试套件移交给自动化团队。 Step4 现在，手动团队开始研究新功能，自动化团队将开始开发测试脚本并开始自动化测试用例，这意味着回归测试用例将转换为测试脚本。 Step5 在他们（自动化团队）开始自动化测试用例之前，他们还将分析哪些所有用例都可以自动化。 Step6 基于分析，他们将开始自动化，即将每个回归测试用例转换为测试脚本。 Step7 在此过程中，他们将借助Regression 案例，因为他们没有产品知识以及工具和应用程序。 Step8 测试脚本准备就绪后，他们将开始在新应用程序 [旧功能] 上执行这些脚本。因为，测试脚本是在回归功能或旧功能的帮助下编写的。 Step9 执行完成后，我们会得到不同的状态，如Pass/fail。 Step10 如果状态为失败，则意味着需要手动重新确认，如果存在Bug，则将报告给相关开发人员。当开发者修复那个 bug 时，Bug 需要和影响区域一起由手动测试工程师重新测试，脚本也需要由自动化测试工程师重新执行。 Step11 这个过程一直持续到所有的新特征，并且回归特征将通过。 通过自动化测试进行回归测试的好处： 准确性始终存在，因为任务是由工具完成的，工具永远不会感到无聊或疲倦。 测试脚本可以在多个版本中重复使用。 使用自动化可以批量执行，即；所有编写的测试脚本可以并行或同时执行。 即使回归测试用例的数量增加了每个版本的发布，我们也不必增加自动化资源，因为一些回归案例已经从前一个版本自动化了。 这是一个节省时间的过程，因为执行总是比手动方法快。 如何选择测试用例进行回归测试？ 这是通过行业检查发现的。客户报告的几个缺陷是由于最后一刻修复了错误。这些会产生副作用并因此为回归测试选择测试用例是一门艺术，而不是一项容易的任务。 回归测试可以通过以下方式完成： 一个经常出现缺陷的测试用例 用户更容易看到的功能。 测试用例验证产品的核心功能。 所有集成测试用例 所有复杂的测试用例 边界值测试用例 成功的测试用例示例 测试用例失败 回归测试工具 如果软件频繁更改，回归测试成本也会增加。在这些情况下，手动执行测试用例会增加测试执行时间和成本。在这种情况下，自动化测试是最好的选择。自动化的持续时间取决于在连续回归周期中保持可重用的测试用例的数量。 以下是用于回归测试的基本工具： 硒 Selenium 是一个开源工具。此工具用于自动测试 Web 应用程序。对于基于浏览器的回归测试，使用了 selenium。Selenium 用于基于 Web 的应用程序的 UI 级别回归测试。 Ranorex 工作室 具有内置 Selenium Web 驱动程序的桌面、Web 和移动应用程序的多合一回归测试自动化。Ranorex Studio 包括完整的 IDE 和用于无代码自动化的工具。 快速测试专家 (QTP) QTP 是一种用于回归和功能测试的自动化测试工具。它是一个数据驱动的、基于关键字的工具。它使用 VBScript 语言进行自动化。如果我们打开 QTP 工具，我们会看到三个按钮，分别是Record、Play 和 Stop。这些按钮有助于记录在计算机系统上执行的每一次点击和操作。它记录动作并回放。 Rational 功能测试器 (RTF) Rational 功能测试器是一种 Java 工具，用于自动化软件应用程序的测试用例。RTF 用于自动化回归测试用例，它还与理性功能测试器集成。 什么是回归测试和配置管理？ 在代码不断修改的敏捷环境中，回归测试中的配置管理变得势在必行。为了确保有效的回归测试，我们必须遵循以下步骤： 在回归测试阶段不允许更改代码。 回归测试用例必须是未受影响的开发人员更改。 用于回归测试的数据库必须是隔离的；数据库中不允许更改。 重新测试和回归测试有什么区别？ 重新测试 测试意味着再次测试功能或错误以确保代码得到修复。如果未设置，则不需要重新打开缺陷。如果修复，则缺陷关闭。 重新测试是一种测试，用于检查在最终执行中不成功的测试用例在缺陷修复后是否成功通过。 回归测试是指在软件应用程序发生代码更改时对其进行测试，以确保新代码不会影响软件的其他部分。 回归测试是一种测试，用于检查代码是否没有改变应用程序的现有功能。 重新测试和回归测试的区别如下： 重新测试 回归测试 执行重新测试以确保在最终执行中失败的测试用例在缺陷修复后通过。 进行回归测试以确认代码更改是否未影响现有功能。 重新测试适用于缺陷修复。 回归测试的目的是确保代码更改不会对现有功能产生不利影响。 缺陷验证是重新测试的一部分。 回归测试不包括缺陷验证 Retesting的优先级高于Regression Testing，所以在Regression Testing之前完成。 根据项目类型和资源的可用性，回归测试可以与重新测试并行。 重新测试是有计划的测试。 回归测试是一种通用测试。 我们无法自动化重新测试的测试用例。 我们可以为回归测试做自动化；手动测试可能既昂贵又耗时。 重新测试是针对失败的测试用例。 回归测试用于通过的测试用例。 重新测试确保原来的故障得到纠正。 回归测试检查意外的副作用。 重新测试使用相同的数据和相同的环境以不同的输入和新的构建来执行缺陷。 回归测试是指现有项目中的修改或更改成为强制性的。 在开始测试之前不能进行重新测试。 回归测试可以从功能规范、用户教程和手册以及关于更正问题的缺陷报告中获取测试用例。 回归测试的优点是什么？ 回归测试的优点是： 回归测试提高了产品的质量。 它确保任何错误修复或更改都不会影响产品的现有功能。 自动化工具可用于回归测试。 它确保已修复的问题不会再次发生。 回归测试的缺点是什么？ 回归测试有几个优点，但也有缺点。 应该对代码中的微小更改进行回归测试，因为即使代码中的微小更改也会在现有功能中产生问题。 如果项目中没有使用自动化进行测试，那么一遍又一遍地执行测试将是一项耗时且乏味的任务。 结论 回归测试是必不可少的方面之一，因为它有助于交付高质量的产品，从而节省组织的时间和金钱。通过确保代码中的任何更改不会影响现有功能，它有助于提供高质量的产品。 为了自动化回归测试用例，有几种自动化工具可用。工具应该能够更新测试套件，\因为回归测试套件需要经常更新。 缺陷管理流程 冒烟测试
