规模化软件开发中如何治愈自动化测试不稳定的顽疾？

菏泽炫佑科技

规模化软件开发中如何治愈自动化测试不稳定的顽疾？

上一篇：如何治愈大规模软件开发中自动化测试不稳定的老大难问题？ （第1部分），我们介绍了Slack对于自动化测试不稳定性的思考。 今天，让我们继续了解团队的具体解决方案。

关于软件测试学习、offer选择等，可以通过后台私信进行交流。 如果您需要学习资料或者帮忙修改简历，也可以私信！ ！ 您也可以在百度搜索“软件测试腾讯课堂”或关注公众号“软件测试”，里面涵盖了许多精彩的免费视频或有用的知识。

成功不是一朝一夕的事，我们必须经过多次尝试才能找到自己的优势。 让我们回顾一下：它是如何开始的，我们在哪里挣扎，以及*终如何解决。

我们启动了一个名为“ ”的项目，其目标是自动检测和隔离不稳定的测试。

首先，您需要弄清楚不稳定的测试和失败的测试之间的关系。

**个解决方案是当测试用例的不稳定率达到一定阈值时，自动过滤不稳定测试用例的结果。

我们打算开发一个系统，可以自动检测不稳定的测试用例，并根据历史记录计算测试用例的不稳定概率。 如果某个测试用例超过了可容忍的阈值，则将该测试用例从测试结果中过滤掉，从而将其隔离开来，测试任务不会因为该测试用例执行失败而失败。

测试失败率因不同的测试类型而异。 例如，单元测试比功能测试更不容易出错，功能测试比E2E测试更不容易出错。 考虑到这一点，我们决定构建一个基于不同测试类型的解决方案：为每种测试类型定义不同的容错能力。

一、具体实施方案

对于 CI 管道中每个失败的测试任务，我们执行了以下操作：

图1 方案一：触发阈值时自动隔离不稳定测试用例的结果

二、实施效果

我们观察到，项目上线以来，PR分支和主干分支测试任务的稳定性得到了快速提升。 一周后，PR 分支构建的稳定性从 71% 提高到 88%（如图 2 所示）。 主干分支的构建稳定性在一周内从 61% 提高到 90%（如图 3 所示）。

图2 iOS PR分支上的单元测试稳定性

图3 iOS trunk分支测试稳定性

3、该方案的缺点

虽然该解决方案*初推出时效果很好，但我们逐渐发现了越来越多的问题：如果测试任务失败，则很难调查。 我们决定放弃这个计划。 主要原因是在这个计划中，不稳定的用例会流向主干分支。

缺点一：不稳定的测试会变成失败的测试并流入主分支。

我们来看看下面的情况。

在分支上，如果测试用例运行失败，但由于缺乏足够的测试执行历史记录，虽然它会一直在trunk分支上运行，但会从CI上的测试结果中过滤掉。 如果这个测试用例在开发者本地执行时失败，但是包含这个测试用例的 CI 构建任务却通过了，那么会让开发者感到困惑。 一旦该用例积累了足够的执行数据并超过了容忍阈值规模化软件开发中如何治愈自动化测试不稳定的顽疾？，CI 中的测试任务就开始被标记为失败。 此时，开发人员或故障排除人员必须开始调查*初的故障，这违背了改进项目的目的。

缺点2：不稳定的测试用例会被追加到测试集中。

考虑以下情况。

缺点三：依赖背景。

本地开发：测试执行记录存储在系统后台，这意味着本地开发人员在运行测试时有不同的体验。 将系统同步到本地开发者环境是一项艰巨的工作。 如果后台出现故障，CI测试任务将会中止。 测试任务将失败并显示“无法计算不稳定测试”。 这将导致开发人员无法合并他们的代码，或者主要构建任务无法更新到后台。

4. 得到的启示

因此，我们决定采用第二种方案：停止执行不稳定的测试用例，而不是对执行后的结果进行过滤。 只要执行失败自动化软件开发，相应的测试用例就会被禁用（无论是否重新运行），每个开发团队都需要分配资源来调查测试失败的真实性质，以便做出相应的修复。

第二个选项：停用不稳定的测试用例

我们将测试失败的处理分为3个关键部分。

1. 成功指标

将主干分支任务的通过率提高到95%，将测试任务的失败率降低到5%以下。

2、具体需求

选项 2：禁用不稳定的测试用例

三、具体实施方案

检测不稳定测试用例的代码如下所示：

停用不稳定测试用例、创建Jira和PR的代码如下：

根据操作系统类型停用测试用例的代码如下所示：

四、实施结果

方案2实施后，我们看一下我们在指标上的表现：

主干分支的稳定性提高到96%。 从2020年7月27日的19.82%上升到2021年2月22日的96%。对稳定性产生负面影响的领域主要是第三方服务和合并冲突。

测试任务失败率降低至3.85%。 从 2020 年 7 月 27 日的 56.76% 上升到 2021 年 2 月 22 日的 3.85%。受到负面影响的领域包括第三方服务、基础设施停机和 CI。

节省了 553 小时的手动故障排除时间。 对不稳定测试进行手动故障排除大约需要 28 分钟/PR。 通过自动化，我们已经为 创建了 693 个 PR，为 iOS 创建了 492 个 PR，到目前为止总共节省了 553 小时（或 23 天的开发时间）。

开发者心情和体验得到改善。 一位开发者这样说道：“我感觉iOS CI比以前更稳定、更快了，谢谢你们的辛劳！极大地提高了我们的工作效率，真的很感谢！”

此外，开发人员的信心也大大提高。 我们联系开发商进行了调查，从结果中我们可以看到信心正在向积极的方向增强。

自该计划启动近一年以来，自动检测和隔离系统持续运行，几乎没有维护成本。

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等