尊敬的读者您好。 今天，我们想与课程“ Python QA Engineer”的发布恰逢。 在预见可能出现的问题时，我们警告说本文中没有关于Python的字眼，但是尽管如此，我们发现该材料对测试人员很有用，因此我们决定与您分享。
测试代码的每个最小细节都是不可行的，因此，回归测试应进行全面的验证，并着重于整个特定区域。 主要目标是确保没有一个回归错误会损害关键业务流程。 正是这种努力使利用自动化成为可能。 旨在减少回归误差的自动化测试方法将有助于建立良好的客户关系和增加品牌价值。
我的团队负责测试使用复杂计算并在会计系统中记录帐簿条目的会计应用程序。 所有这些都是工作流程，最重要的是每个月都要结帐。
每次下达时，计算中都会发生一些变化，例如，对于该帐户，可能有必要增加借方或贷方，或者可以在两个帐户之间分配现有的价值。 在具有许多内部和外部依赖性的复杂应用程序中，此类更改通常会在意外的和看似无关的位置导致不可预测的行为，包括回归错误。
让我们处理一个回归错误，它有时被称为关键事件或生产问题。 在软件行业工作了数年之后，您意识到泄漏到生产环境中的回归错误比不正确工作的新功能重要得多。 事实是，新功能仍处于隐藏状态，因此，当新功能崩溃时，对业务组件的影响很小，而由于存在回归错误，用户依赖于工作功能，并且很可能没有工作系统的备份版本。
回归错误是由验收测试期间项目经理或产品所有者未考虑的更改引起的； 在设计或实施阶段进行代码审查的架构师，开发人员； 或由QA分析人员和测试人员进行测试。 所有安全网络都错过了一个错误，用户发现了这个错误。 如果在上述任何一个阶段检测到最近更新中的错误，即 团队，相关方或组织中存在的任何其他链接，然后在发布之前对其进行检查，或者至少对其重要性进行评估。
回归错误会带来若干成本：紧急纠正，可能违反服务水平协议的惩罚，最重要的是，它们会破坏用户对产品的信任。 他们可能会决定一个新版本会破坏已经起作用的内容。
对我的团队来说，绝对检查所有东西变得很重要。
但是，众所周知这是不可能的，或者至少太昂贵和耗时。 因此，“测试所有内容”集中于以下两件事：关键业务流程以及对主要关键业务流程中的行为与更改之前的最新版本相同的信念。 通常，我们要确保在最新版本中，关键业务流程中没有出现回归错误。
我们评估了自动化测试的典型方法，以验证计算结果并验证所有逻辑均已在自动化测试代码中进行了描述。 这种方法提出了一个经典的问题：“谁在测试测试人员代码？” 如果测试用例不成功，则问题出在测试器代码中的可能性也相同。 此外，随着应用程序中的每个更改，测试代码也需要更新，并且此类更改经常发生。
同样，由于自动化测试，我们确保了我们有固定的一组输入和一组众所周知的输出。 由于应用程序的复杂性，不可能一次提交所有可能的输入数据集。 月底，季度，年末还需要各种数据集。 计划表是一个严重的问题，因为生成大量输入数据和相应的脚本需要花费大量时间。
还有另一个变量：用户数据。 我们享有特殊特权：我们每个月都会收到用户数据的备份副本。 测试的质量直接取决于用于测试的数据，而生产数据总是比生成的数据更好，因此我们的特权是我们不容错过的巨大优势。
回归测试的识别和实施
我们的想法是使用自动化测试，该测试需要最少的必要维护，并增强了利益相关者对发布将具有适当质量的信心。
因此，我们需要针对关键业务案例的测试策略，该策略应确保不存在回归错误，并且当然可以将其快速付诸实践。
我们的准备过程如下所示：
- 从生产数据库备份，还原两次；
- 已安装两个并行工作的测试系统：
- 一个带有生产代码的代码；
- 另一个正在测试的应用程序的当前版本。
这种方法提供了两个相同的系统，只是一个版本的代码有所不同：
具有两个系统非常重要，因为它有助于理解任何问题仅是由于最新的代码更改而引起的。
测试是分开的，因此从标准过程“执行一个动作并获得反应”开始，我们继续以下事实：在保持工作流程的同时，从一个点到另一个执行了动作，然后比较错误报告。 这是检测意外错误的关键。
当测试人员将重点放在新功能或某种更改上时，测试就将重点放在新功能上，即 检查特定更改的相关性 回归测试的不同之处在于，它必须验证没有其他变化。 这种差异反映在自动化方案中。 它使特定的功能测试脚本不适合搜索回归错误，因此这里需要一种不同的方法。
例如，如果您使用的是订单管理系统，则需要一个脚本来下达具有大量输入数据的订单，以下达两个已安装的测试系统（最好是并行工作）的订单，然后才能获得过去一天的订单报告并进行比较价值。 然后确认或批准所有订单（此操作），并生成报告，例如每日确认的订单，库存订单，仓库报告，来自每个承运人的订单，装运类型，付款类型等。 将在两个系统中进行比较。 这将贯穿整个工作流程。 您可以组合操作，例如下订单和确认订单，然后在不同的阶段比较报告。
另一个示例是酒店管理系统，其中将各个操作定义为关键业务流程，例如签到，在餐厅开账单和接收库存。 所有这些过程都将分配有自己的动作和报告。 与上一个示例相比，该系统的不同之处在于测试套件可以并行运行，并且无需在开始下一个测试套件之前完成该步骤。
对这两个报告进行比较是一个关键时刻，从某种意义上来说，任何有关方面都不应对报告的正确性产生怀疑，这应该是无可挑剔的。 报告中的差异是真正的差异。
对于此操作，我们使用Web服务界面。 所有报告在两个系统上并行发送，因此，将比较接收到的JSON格式的响应。
比较发生在三个方面：
- 来源（生产）减去目标（正在测试的应用）；
- 目标减去源；
- 比较值以获得交集。
此方法适用于XML，XLS，CSV固定宽度或任何其他格式。 我们需要确保没有不必要的记录，没有丢失的记录，并且记录的所有值都匹配。
这是我们正在谈论的方法的本质。 所有这些信息在应用程序中都是可读的，可以作为报告发布，或者在某些情况下用作与其他应用程序的接口。
这种方法的成功在于比较工具或实用程序，该工具或实用程序可以处理与您的应用程序相关的案例。 如果您发现“开箱即用”的合适东西，就可以认为自己很幸运，否则，重要的是要了解对这种工具进行投资是值得的，因为它将带来良好的结果。
在讨论完自动化之后，您需要添加一个备注。 由于预计报告中会存在一些差异，因此必须按要求存在这些差异，因此还必须手动分析所有结果。 通过测试用例应该有明确的成功结果，但是，也必须分析不成功的结果，并且必须确认其有效性。 由于我们正在谈论回归测试错误，因此应在发布之前修复它们。 当然，根据应用程序可以处理一些例外情况。
程序设定
所有应用程序均不同，并且安装和配置它们的方式也不同。 为了准备测试应用程序，可能需要一些其他步骤，因此，必须在正确的时间和正确的位置将它们考虑在内以运行测试。 这是一组典型步骤：
通过删除电子邮件标识符或其他机密信息来“混淆”生产中的数据，或将其替换为虚拟数据；
以正确的形式获取数据以运行测试；
例如，通过更改集成关系来调整质量检查环境的设置。
唯一需要记住的是，两个安装都必须执行上述步骤。 请记住，在启动测试套件之前，设置必须相同。
通常，除请求报告外的其他操作都可以返回对象，例如，创建或修改订单之类的操作可以返回新的订单对象。 在这种情况下，您需要比较两个对象，而不必等待报表的比较。 这可以帮助在根源的早期阶段识别错误。
还建议您将整个集合分成较小的集合，例如，通过将事务和相关报告分组在一起。 集合可以并行运行以节省运行时间。 但是，对于具有典型工作流程的应用程序，这仅在您可以垂直和水平拆分案例的情况下才有效，反之亦然。
变体可以从技术开始-JSON，XML或缩放器（int / string / float），然后扩展直到被测试和生产的应用程序对不同的结构做出反应，但仍遵循体系结构。 例如，生产版本可能使用以特定格式运行的旧JAR文件，而在新版本中，JAR文件已经更新，现在响应格式已更改，因此它们的比较将显示出不一致之处。 为了正确比较它们，您需要一个临时插件。
这样的情况可能很少。 在这种情况下，有时可以更容易地调整设计或在变通办法的背景下考虑它们。
有几种处理这种比较的选项：
忽略一些字段，例如标识符和日期；
忽略小于0.0001的数值差；
忽略大小写；
结构变化有两个答案。
改善回归测试
回归测试应该是整体的，并且应该集中在整个领域。 这种平衡将有助于利用自动化。 自动化的测试方法将有助于减少回归错误的数量，并有助于建立良好的客户关系并增加品牌价值。
现在，以不断前进的节奏，我们的团队希望放弃我们现在使用的两个相同的系统安装，并在一个安装上实施相同的策略。 我们希望保留过去成就的答案，并将其用于比较。 测试方法总是可以改进的。 祝我们好运！
翻译是专门为“ Python QA Engineer”课程的学生准备的。