4

不稳定的测试是自动化测试的主要挑战之一(第二部分)

 2 years ago
source link: https://www.continuousdelivery20.com/blog/tatg-test-flakiness-one-of-main-challenges-part-2/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

乔梁 | 2021-03-11

这是关于测试脆弱性的系列文章的第二部分。第一篇文章讨论了运行测试用例的四个组件,以及测试脆弱的可能原因。本文将针对这些可能的原因讨论的测试脆弱的分类技巧和诊断方法。

回顾一下,可能出现脆弱性的四个组成部分包括:

  • 测试运行框架
  • 被测应用程序或系统(SUT)以及SUT和测试框架所依赖的服务和库
  • SUT和测试框架所依赖的操作系统、硬件和网络

下面的图表捕捉并总结了这一点。

The reasons, triage tips, and remedies for flakiness are discussed below, by component.

测试用例本身

The tests themselves can introduce flakiness. This can include test data, test workflows, initial setup of test prerequisites, and initial state of other dependencies.

脆弱的原因分析技巧提示补救的类开不适当的初始化或Clean up找“未初始化变量”的编译告警。检查初始化和Clean up 代码。检查所用环境被正确初始化和清理。验证所用的测试数据是否正确。在使用变量之前,使用正确的值显式初始化所有变量。正确设置和清理测试环境。考虑使用验证环境状态的初始化测试。对测试数据的状态有无效的假设重新独立地运行失败的测试。让本测试与其它测试的任何状态和执行结果相隔离关于系统状态的无效假设,例如系统时间。明确检查系统依赖性假设。删除或隔离那些 SUT 依赖但你又无法控制的环境方面关系依赖于执行时间,期望异步事件以特定顺序发生,在没有超时的情况下等待,或者测试和应用程序之间存在竞争条件。记录访问应用程序的时间。作为调试的一部分,在应用程序中引入延迟以检查测试结果的差异。将同步元素添加到测试中,以便它们等待特定的应用程序状态发生。禁用不必要的缓存,以便为应用程序响应提供可预测的时间线。注意:不要添加任意延迟,因为这些延迟可能会随着时间的推移再次变得不稳定,从而不必要地减慢测试。依赖于测试运行的顺序。(与上述第二种情况类似。)独立地重新执行测试。使测试相互独立,并且不受以前运行的任何状态的影响。

执行测试的框架

不可靠的测试执行框架可能会引入脆弱性。

脆弱的原因分析技巧提示补救的类开未能为SUT分配足够的资源,从而使其无法运行。查看日志,看看SUT是否启动了。分配足够的资源。导致“不恰当的测试计划”相互冲突。以不同的顺序显式地独立运行测试。使测试用例彼此独立运行。系统资源不足,无法满足测试要求。(与第一种情况类似,但在这里,运行工作流时会消耗资源。)检查系统日志,查看SUT是否耗尽了资源。修复内存泄漏或类似的资源“出血”。分配足够的资源来运行测试。

应用程序或 SUT,以及 SUT 和测试框架依赖的服务或库文件

当然,应用程序本身(或SUT)可能是脆弱性的来源。

一个应用程序也可能对其他服务有许多依赖关系,而这些服务中的每一个都可以有自己的依赖关系。在这条链中,每项服务都可能引入脆弱性。

脆弱的原因分析技巧提示补救的类开竞争条件对共享资源的访问写日志。将同步元素添加到测试中,以便它们等待特定的应用程序状态。注意:不要随意添加延迟,因为随着时间的推移,这些延迟可能会再次变得不稳定。未初始化的变量。查找有关未初始化变量的编译器警告。在使用变量之前,使用正确的值显式初始化所有变量。对测试发现的调用反应迟钝或无反应。记录发出请求和响应的时间。检查并排除延误的任何原因。内存泄漏。查看测试运行期间的内存消耗。使用Valgrind等工具进行检测。修复导致内存泄漏的编程错误。这篇维基百科文章对这些类型的错误进行了极好的讨论。超额认购资源。检查系统日志,查看SUT是否耗尽了资源。分配足够的资源来运行测试。对应用程序(或相关服务)的更改与相应的测试不同步。检查修订历史记录。制定一项政策,要求代码变更要有测试用例伴随。

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

最后,底层硬件和操作系统可能是测试脆弱性的来源。

脆弱的原因分析技巧提示补救的类开网络故障或不稳定。检查系统日志中的硬件错误。修复硬件错误或在不同硬件上运行测试。磁盘错误。检查系统日志中的硬件错误。修复硬件错误或在不同硬件上运行测试。与正在运行的测试无关的其他任务/服务占用的资源。检查系统进程活动。减少测试系统上其他流程的活动。

从各种各样的失败中可以看出,在自动化测试的脆弱性是一个相当大的挑战。本文概述了运行测试的组件和可能出现的脆弱性类型,因此可以作为测试和修复脆弱测试用例时的备忘单。


原文作者: George Pirocanac

原文链接Test Flakiness - One of the main challenges of automated testing (Part II)

发表时间:March 24, 2021


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK