不稳定的测试，是自动化测试的主要挑战之一

处理测试用例的不稳定是测试中的一项关键技能，因为不提供一致信号的自动化测试会减慢整个开发过程。

如果你还没有遇到过不可靠的测试用例，这篇文章是必读的，因为它首先试图系统地概述不可靠测试的原因。

如果你已遇到了不稳定的测试，看看有多少是属于我们列出的范畴。

下面的文章会讨论如何处理每一种原因。

这些年来，我们已经见过很多关于不稳定测试的原因，但与其逐一回顾，不如让我们根据运行测试的组件对不稳定测试的来源进行分组：

• 测试用例本身
• 测试运行所用的框架
• 被测系统 ( SUT )本身 ，以及被测系统及测试框架所依赖的服务或框架
• 被测系统和测试框架所依赖的操作系统和硬件

如下所示。

图 1 首先显示了支持被测应用程序或系统的硬件/软件堆栈。最底层是硬件。然后是操作系统，上面是提供系统接口的库。在最高层是中间件，该层提供特定于应用程序的接口。

然而，在分布式系统中，应用程序的每个服务及其依赖的服务都可以驻留在不同的硬件/软件堆栈上，测试运行服务也是如此。图 2 显示了完整的测试运行环境。

如上所述，这些成分中的每一种都是不稳定因素的潜在原因。

测试用例本身

测试本身可能会带来稳定，典型原因包括：

• Setup 或 Cleanup 不当。
• 测试数据状态的无效假设。
• 系统状态的无效假设。典型的例子是测试用例中使用了系统时间。
• 依赖于应用程序的某个特定时机（timing）。
• 依赖于测试用例运行的顺序。（与上面的第一个案例类似。）

执行测试用例所用的框架

不可靠的测试运行框架可能会引入不稳定。典型原因包括：

• 未能为被测系统分配足够的资源，从而导致其出现故障。
• 测试计划不当，导致测试用例「冲突」，并导致彼此失败。
• 系统资源不足，无法满足测试要求。

被测系统本身及它与测试框架所依赖的服务或框架

当然，应用程序本身（或正在被测试的系统）可能是不稳定的来源。一个应用程序也可以对其他服务有许多依赖关系，而这些服务中的每一个都可以有自己的依赖关系。在这条链中，每项服务都可以引入不稳定。典型原因包括：

• 竞争条件（ Racing ）。
• 有未初始化的变量。
• 对测试的调用响应迟钝或无反应。
• 内存泄漏。
• 超额认购资源。
• 应用程序（或相关服务）的变化速度与相应测试用例所预期的变化速度不同。

如果一个测试环境包含了它运行测试用例所需要的所有东西（没有任何外部依赖，包括运行在生产环境的服务）时，这样的测试环境就被称作密闭环境（ hermetic environment） 。

一般来说，使用这种自包含的密闭环境，很少会导致测试不稳定。

被测系统和测试框架所依赖的操作系统和硬件

最后，底层的硬件与操作系统也可能是不稳定的来源。典型的原因包括：

• 网络的失败或不稳定。
• 磁盘错误。
• 与正在运行的测试用例无关的其他任务/服务占用的资源。

从上面各种各样的失败中可以看出，要让自动化测试用例不稳定率一直保持在较低水平上，是一个相当大的挑战。本文简单地罗列了可能出现的不稳定源它可以作为对不稳定测试进行分类备忘。

在下一篇文章中，我们我们将进一步探讨解决这些不稳定性的方法。

原文作者： George Pirocanac

原文链接：Test Flakiness - One of the main challenges of automated testing（Part 1）

发表时间：December 16, 2020