（特斯汀软件测试）自动化测试失败率居高不下
发表时间：2023-10-30 09:01:32
文章来源：炫佑科技
浏览次数：137
菏泽炫佑科技
（特斯汀软件测试）自动化测试失败率居高不下
虽然我们希望自动化测试任务执行中的每一次失败都是由于真正的软件缺陷造成的，但事实上，自动化测试的失败往往是由于自动化测试本身的不稳定性，即Flaky Test。 Flaky Test是指在同一测试环境中多次执行但得到不同结果，有时成功有时失败的自动化测试用例。 Flaky是影响研发效率的一大因素，研发团队不得不花时间分析测试失败的原因。 这个问题在引入持续集成的大规模开发活动中尤为严重，因为自动化测试的数量巨大，并且由于测试不稳定而导致构建失败的比例很高。 】
我所在的团队是移动开发者体验团队（Team，DevXp）。 该团队的目标是让全公司的开发人员能够自信地发布代码，同时获得愉快且高效的工程体验。 我们使用一些指标和调查来衡量研发效率和开发人员经验。 这些指标包括：开发人员情绪、持续集成（CI）稳定性、代码集成时间（TTM）和自动化测试失败率。
DevXp团队致力于不断完善测试基础设施和持续集成，但由于测试不稳定导致的测试失败率始终居高不下。 这是我们遇到的*大挑战之一。 在我们找到解决方案之前，代码主分支上的 CI 构建通过率一直徘徊在 20% 左右。 我们仔细分析了所有失败的构建并发现：
使用Flaky Test自动隔离系统替代手动处理失败测试用例后，测试任务的失败率从57%下降到5%以下。 本文介绍如何通过自动检测和隔离失败案例来*大程度地减少不稳定测试案例的数量。 我们试图解决的问题并不是一个新问题；而是一个新问题。 许多公司都介绍了如何应对不稳定的测试和构建的系统。 Flaky Test 已成为大规模开发活动中日益严重的问题。 接下来我们就来看看在大规模的开发活动中如何才能有效的消除Flaky Test。
1、规模化发展
对于移动应用程序的代码库，我们有超过 120 名开发人员每周创建超过 550 个拉取 (PR)。 App上有超过16,000个自动化测试，iOS App上有超过11,000个自动化测试。 测试金字塔由端到端测试、（组件）功能测试和单元测试组成。 每当开发人员提交代码并将其合并到主干分支时，就会触发自动化测试。 此外，每个开发团队的开发人员负责编写和维护与其相关的所有自动化测试。
随着我们的开发规模不断扩大，我们经常问自己：我们能否确保将代码更改可靠且高性能地合并到主干分支中？ 为了保证测试的可靠性，我们从一开始就进行了大量的投资。 然而，当开发规模越来越大时，依赖测试用例的开发人员不可能**时间就把事情做对，从而杜绝测试不稳定问题的发生。 早期，我们依靠集体意识，即当开发人员意识到某个测试用例不稳定时，他们会主动进行调查。 在小型团队（大约 10 名开发人员）中，这种方法效果很好，但在较大的团队中，就会出现旁观者效应。 例如，如果让一个人独自完成一项任务，他的责任感就会很强，他会积极响应。 但如果一个小组一起完成任务（特斯汀软件测试）自动化测试失败率居高不下，小组中每个人的责任感就会变弱。）*终，开发人员希望他们的 Pull 能够合并到主干分支中，而不必花时间调查一个不相关的不稳定测试。 对开发人员和 DevXp 故障排除成员的调查显示，每个测试用例执行失败需要 28 分钟进行手动故障排除。 在我们的系统中自动化软件开发，不可避免地存在测试不稳定、测试任务失败率高、手动排查时间长等问题。 因此，我们必须努力以自动化的方式解决测试的不稳定性。
2. 不稳定测试的分类
任何软件错误都可以分为致命错误和非致命错误。 致命的软件错误会影响软件的基本使用并导致糟糕的用户体验。 非致命错误可能会影响软件使用并降低用户体验，但影响较小。 开发人员可能不会立即修复非致命错误，但仍然需要关注。
同样，对于足够大的测试集，测试不稳定是不可避免的。 不稳定的测试破坏了开发过程和软件质量之间脆弱的平衡。 不稳定的测试有可能掩盖真正的产品缺陷。 如果开发人员因为测试结果不稳定而忽视软件的失败行为，那么测试的目的就失去了。 不稳定的测试还会占用宝贵的运行资源并增加执行成本 - 特别是当 CI 依赖于 AWS 或测试实验室 (FTL) 等第三方服务时。 *终会降低CI的稳定性，增加TTM（上市时间），影响开发者对测试的信任和体验。
我们将不稳定测试分为两种类型。
在我们的初步调查中，开发人员对不稳定的测试有以下看法：
“关于 CI，我必须感谢 DevXp 团队提供了如此多类型的测试来运行。虽然我希望能够以现在一半的时间运行这些测试，但我更喜欢端到端测试和 FTL 测试不稳定问题较少。几乎所有与设备相关的 CI 错误都是由不稳定的测试引起的。”
一开始我们的主要目的是解决系统性问题导致的测试不稳定。 我们的方法的具体细节将在下面讨论。
3、人工检查方法
当测试任务在开发者Pull分支或trunk分支上运行失败时，开发者需要执行以下操作：
开发人员会收到通知，由于构建任务失败，代码合并请求被标记为 ❌。
在多次尝试失败后，开发人员联系 DevXp 团队，他们的故障排除人员进一步调试失败的测试任务。
我们的数据表明，手动故障排除和隔离不稳定的测试用例可以提高测试稳定性并减少测试任务失败，因此我们决定自动化此过程。
