提升测试效率：深入解析三种测试自动化类型_汽车之家客户端前端团队-CSDN博客

本文链接：https://blog.csdn.net/G_yws233/article/details/131901829

我们都经历过这样的情况：现实生活中经常出现的重复编码模因是什么？

请添加图片描述

这个模因总结得很好：每个抽屉单独工作都很好，但与另一个抽屉结合使用时，它们会互相阻挡，从而无法发挥作用。我们希望两个抽屉能够很好地配合，能够同时操作。

请添加图片描述

将其应用到 Web 开发中：我们编写了一些测试，甚至可能实现了 100% 的测试覆盖率，但我们的应用程序仍然需要在其他部分到位后立即执行。这些单元工作得很好，但彼此之间没有关系。因此，编写一些测试至关重要，但这只是为您的项目找到理想测试设置的一部分。作为第一步，我们需要确定应用程序质量的哪些部分需要得到保证，以及我们希望如何实现这一点。

简而言之，我们希望在开始编写实际的测试代码之前有一个计划。因此，我们将在讨论如何实际测试的主题时回答两个基本问题：

我们想要如何测试？
我们想测试什么？

这篇文章重点讨论第一个问题。我们的主要目标是规划正确的测试策略，但我们将在这里介绍最初的步骤：让我们发现哪些测试类型可用于从共同点开始。在后面的文章中，我们将结合它们，从而根据我们在这里学到的基础工作找到最适合我们项目的测试策略。

让我们从基础开始：常规测试模式

在回答如何测试的问题时需要澄清的第一点非常抽象。我们需要粗略地定义我们想要的测试方式——我们应该自己做还是应该由计算机接管？小剧透警告：我们需要避免陷入二元思维。但是，让我们先深入了解基础知识。

手动测试与自动化测试

如果你要求人们定义测试，你可能会遇到两个答案：

手动测试。这是典型的测试方法，由真人完成。这意味着测试人员将单击该应用程序并检查它是否有效，同时尝试破坏它。探索性测试是最常见的方式：顾名思义，测试人员探索应用程序，利用自己的知识使用预定路径或任何清单调查被测应用程序。
自动化测试。这是您可能从开发人员和测试人员那里得到的答案。单调的清单测试尤其适用于自动化。因此，计算机将为我们进行测试。

本系列指南将主要关注自动化测试。然而，一个小但重要的免责声明：您不应该只关注一种测试方式！即使自动化节省了大量时间和精力，人类和手动测试仍将始终发挥至关重要的作用。相反，测试自动化应该确保人们可以专注于手动测试中重要的事情，即对最重要功能的探索性测试；例如，在用户体验或测试涉及高风险的业务逻辑方面。换句话说，自动化是我们的后盾。❤️

不透明盒子与透明盒子

因此，我们定义了测试的一般方式。然而，这还不够——我们现在需要更深入地了解细节。为了更彻底地规划您的测试策略，让我们看一下测试程序或模式。在这两种情况下，无论您进行手动测试还是自动测试，都还需要回答一个问题。您是否应该知道您的应用程序在幕后如何工作，或者在没有这些知识的情况下进行测试（基本上是从头开始）是否更有帮助？

推导和选择测试用例的一种过程称为不透明盒测试（也称为黑盒测试）。它基于分析组件或系统的功能或非功能需求（规范），而不考虑其内部结构。
第二种方法相反：明盒测试（也称为白盒测试）是一种在考虑所述盒的内部结构的同时派生和选择测试用例的过程，换句话说，考虑应用程序在幕后的工作方式。

这两个过程都可以应用于手动和自动测试。然而，某些测试类型将更多地关注两者之一——我们也会介绍这一点。但在此之前，我们应该快速定义确切的测试自动化类型。

测试自动化类型：我们要如何测试？

当我们更接近于回答我们想要如何测试时，让我们将测试类型作为我们项目中的度量。我们已经决定进行一些手动测试，但致力于测试自动化类型更具挑战性。因此，让我们仔细看看最重要的几个。

正如前面提到的模因所示，我们已经遇到过两种类型——单元测试和集成测试。还有更重要的类型需要考虑，所以让我们简要概述一下。

单元测试

单元测试是一种测试类型，其中较小的可测试部分或应用程序的单元(称为单元)被单独和独立地测试以确保正常运行。这些单元的范围可能有所不同，从功能、类或接口到服务或完整组件。它们的主要属性是执行速度、隔离性和舒适的可维护性。如果您想深入了解单元测试，请参阅本单元测试指南。
请添加图片描述

可能的工具包括但不限于Vitest和Jest。

集成测试

集成测试侧重于组件或系统之间的交互。这种测试意味着我们正在检查单元的相互作用以及它们如何协同工作。集成测试的典型示例是 API 测试或组件测试。
请添加图片描述

您可能考虑使用的工具通常与单元测试部分中提到的工具相同，并且还可以包括提供组件测试的框架，例如WebdriverIO和Cypress。

端到端测试

这些测试通常称为 UI 测试，这个名称更好地解释了它们的功能。这些测试与应用程序的 UI（包括完整的应用程序堆栈）交互，并从头到尾测试您的应用程序。
请添加图片描述
如果您参考质量保证理论，它们类似于系统测试。因此，这些测试模拟了真实的用户及其交互。这些测试需要更多时间，因为它们涉及整个系统。更多的运行时间还意味着需要更多的计算能力，并且开发人员需要花费更多的时间来等待管道完成。因此，这种额外的努力会导致更高的维护成本。

可能的工具包括但不限于： * WebdriverIO * Cypress * Playwright * Selenium

视觉用户界面测试

UI 测试的一个有趣的子类别是视觉测试。这些测试是扩展的端到端测试，提供了通过屏幕截图比较来检查应用程序可见输出的过程：将更改的屏幕截图与包含“现状”的另一个屏幕截图（换句话说，一个黄金屏幕截图）进行比较。文件，并将这些结果提供给人工审核员进行检查和检查。换句话说：它有助于发现页面外观中的“视觉错误”，超越纯粹的功能性错误和概念之外，没有明确写成断言。