自动化软件测试策略

作为一名软件开发人员，我在不同的公司工作过，具有不同的软件测试流程。在大多数情况下，没有特定/记录的测试方法......因此该过程的内容/方式取决于各个开发人员。与大多数情况一样，当没有强制执行或至少记录在案的政策时，事情会在一段时间后开始脱轨。

在糟糕的测试堆栈中，您会看到类似以下内容：

• 重复或半重复测试。在没有计划的情况下盲目地到处添加测试用例可能会导致重复测试的结果。您可能会说这至少比没有测试要好，但我们肯定可以做得更好。
• 不同类型的测试，塞在同一个 TestClass 中。测试单元和集成案例或系统和单元案例。是的，在所有这些测试中，您正在测试同一类，但级别不同。
• 由于整个套件（甚至已知的慢速类型测试）一起运行，测试花费了太长的时间。这会使本地开发变得非常缓慢和无聊。快速测试和慢速测试之间的微小分离可能会大有帮助，但是您需要将这些类型的测试分开才能单独运行它们（提示上一点！！）
• 测试必须按特定顺序运行。因此，添加新的测试就像玩倒置的 Jenga，如果没有仔细地将测试添加到与其余测试相匹配的位置，那么整个测试就会崩溃，您将必须调试测试并找到正确的测试顺序。
• 对我们的测试套件没有信心，或者它实际上意味着测试正在通过。这是作为软件开发人员最糟糕的感觉。当它应该是相反的时候，它会带来压力和焦虑。您的测试应该给您信心，最大限度地减少部署的风险和恐惧，从而实现更连续的部署设置。您可能听说过类似“周五不部署”之类的话！
• 由于前面几点的混乱，人们会灰心丧气并停止编写质量测试或任何测试。这就是当狗屎遇到麻烦的时候，没有意愿改进测试阶段，整个事情只是漫无目的地进行，直到所有开发人员精疲力尽并中止这艘船。

那么我们应该如何测试呢？

免责声明！！！

• 根据我之前的经验，这个示例测试策略主要集中在普通的 SaaS 类商业软件上。任何其他更利基或特殊的产品很可能会偏离这一点。但您可以根据基本想法进行推断并制定自己的策略。
• 遗憾的是，我还没有成功地将这个策略应用到实际的生产产品中。因此，对我来说，讨论将是有理论基础的。希望在某个时候，我可能足够幸运将其付诸实践，然后我可以让你知道它是如何进行的：P
• 显然，划分测试类型的想法并不是您以前从未听说过的新的突破性想法。我只是想简化这个想法，希望它可以更容易地向非技术人员解释（或销售）为什么这是我们成功产品所需要的东西。此外，对于我们作为开发人员来说，实际实现这样的测试堆栈具有相当的成功率，因为​很容易被压力和截止日期冲昏头脑，并退回到不良的测试实践。

介绍

该策略的整体思想是根据以下条件拆分测试

• 它们的水平有多 低或多高。例子：单元测试是低级测试系统测试，是更高的测试
• 它们在 技术或业务上的相关程度如何。集成测试是技术性的BDD 测试是业务测试

通过这种方式，我们希望在不同的层面上并基于不同的价值结果来测试我们的软件。同时，这些价值结果甚至可能有不同的利益相关者负责（或更关心）以改进该阶段的测试结果。例子：

• 程序员可能会更关心单元系统测试
• 产品人员会更关心BDD测试
• 基础设施人员会更关心性能测试

再次强调，这只是一个例子。根据您的情况，您可能有 3 名开发人员负责整个测试堆栈，或者每个阶段都有一个团队。以下测试堆栈是我希望在我过去工作过的一些项目中看到的示例堆栈。

测试堆栈

正如您从楼梯图中看到的，您从低级测试到高级测试，从技术测试到更多业务相关类型的测试。

让我们看看每种类型/步骤代表什么：

单元测试

单元测试是一种软件测试，其中测试软件的各个单元或组件。目的是验证软件代码的每个单元是否按预期执行。测试隔离一段代码并验证其正确性。单元可以是单独的功能、方法、过程、模块或对象。

用法：

• 开发人员通过定期执行单元测试获得有关代码质量的快速反馈。
• 单元测试迫使开发人员处理代码而不仅仅是编写代码。也就是说，开发人员在收到单元测试的反馈后，必须不断重新思考自己的方法论，优化编写的代码。
• 以隔离的方式运行每个测试用例，并使用“存根”或“模拟”来模拟外部依赖关系。这确保单元测试仅考虑当前被测单元的功能。
• 单元测试可实现高测试覆盖率。
• 在开发生命周期的早期频繁运行。

集成测试

集成测试被定义​​为一种测试类型，其中软件模块被逻辑地集成并作为一个组进行测试。典型的软件项目由多个软件模块组成，由不同的程序员编码。此级别测试的目的是暴露这些软件模块集成时交互中的缺陷。此外，还测试与依赖项的交互（数据库、文件、api 等）。

用法：

• 确保每个集成模块/依赖项正常运行
• 集成时使用“真实”数据（数据固定装置、测试文件、模拟或开发 API 等）

冒烟测试

冒烟测试是系统测试用例的一个子集，涵盖组件或系统最重要的功能，
用于帮助评估软件的主要功能是否正常工作。我称其为“优化”，因为它们也用作故障保护，如果这些测试失败，那么我们就不会继续运行完整的系统测试，这可能会是一个较慢的过程。由于此阶段测试最重要的功能，我还看到这些测试在每次部署之后或以 cron 方式针对生产环境运行。当以这种方式使用时，它们也可能被称为“实时测试”。

用法：

• 确定计算机程序是否应该接受进一步、更细粒度的测试，例如系统/bdd/性能测试，这些测试通常是更耗时的测试。
• 通过定期运行这些测试（实时测试）来确定生产时的计算机程序状态是否仍符合预期。

系统测试

系统测试测试整个系统，看看系统是否与所有集成模块和组件协调工作。在我的“书中”，您以“黑盒”方式执行这些测试，从外部向内进行测试，而无需真正使用内部工作原理的知识。测试阶段属于技术测试领域，这意味着您应该尝试坚持技术测试（例如身份验证、验证、CRUD 请求、错误处理等）

注意：系统测试对于不同的团队来说可能意味着很多很多的事情。正如前面的免责声明中提到的，我主要关注普通的 SaaS 类商业软件。因此，在这种情况下，这些测试意味着通过 API 交互来测试功能。

用法：

• 验证对应用程序中每个输入的彻底测试，以检查所需的输出。
• 在集成测试中使用“类似真实”的数据（数据固定装置、测试文件、模拟或开发 API 等）

业务驱动开发测试

BDD 使用人类可读的软件用户需求描述作为软件测试的基础。
每个测试都基于一个用户故事。系统测试更高一级，因为在这些 BDD 测试中，我们将以
与系统测试（API 调用）相同的方式进行测试，但采用用户故事（场景）的格式来断言幕后故事/流程按预期工作。

用法：

• 使用 BDD 的团队应该能够以用户故事的形式提供大部分“功能文档”，并补充可执行场景或示例。
• 它巧妙地帮助非技术人员轻松理解自动化测试（人类可读的描述）。
• 与领域驱动设计 (DDD) 一样，BDD 的早期步骤是定义利益相关者、领域专家和工程师之间的共享词汇表。

性能测试

到目前为止，我们测试了一切在技术和功能方面都运行正常。事情看起来很棒，我们很高兴！但是，这些正确的回答是否及时返回？！如果还有 5 个以上的用户使用我们的服务，或者 10 个用户怎么办？在我们开始注意到响应时间延迟之前，我们可以处理多少个并发用户或请求。因此，这就是我们试图通过这些测试来涵盖的内容，即使我们返回正确的结果，我们也会以预期的响应时间返回它们

用法：

• 一些要测试的指标是：响应时间：API返回响应所花费的时间吞吐量：单位时间内处理的请求数。并发性：API 可以处理的并发用户数或请求数。

结论

我们在这篇简短的文章中介绍的是在不同级别（低 - 高）和不同价值结果（技术 - 业务）上测试软件的示例策略/管道/流程（随你怎么称呼），以及一些关于事情如何进行的示例当没有定义好的测试堆栈过程时就会结束。显然，这是测试堆栈的 10k 英尺视图！每个单独的步骤都需要更多的工作、文档和规划才能在测试堆栈中实际正确实施。然而，心中有一个初步计划可能会给你带来比即兴发挥更好的结果！