本文共 3895 字，大约阅读时间需要 12 分钟。
解读 Flaky Test
Flaky Tests是一种不可靠的测试现象：即在同样的软件代码和配置环境下，得不到确定(有时成功、有时失败)的测试结果。
从逻辑上讲，当一遍又一遍地进行相同的测试时，代码将产生相同的结果——应用程序要么每次都能正常工作，从而通过测试，要么每次都不能正常工作，从而导致测试失败。测试结果应该是一致的(Consistent)，即一段代码要么符合预期的运行结果，通过测试；要么与预期结果不符，测试失败。
然而，实际中执行测试时会出现完全相同的代码和配置，但是出现不一致的测试结果，那么这种现象被称为 Flaky Test。
Flaky ['fleɪki] 的英文意思是：易碎成小薄片的；易剥落的；行为古怪的；好忘事的
Flaky Test 是表达一种不可靠的测试现象。
在 Regression Test 时，尤其是采用自动化的方式执行测试时，测试者编写了自动化测试Scripts执行测试，一些 Test Scripts 有时候执行成功，有时候执行失败了，这时就产生了 Flaky Test的现象。
Regression Test 是敏捷开发过程中非常重要的一种测试，当发生了功能变更，或者开发团队修复了缺陷之后，为了确保产品功能正常，通常需要执行Regression Test，能够采用自动化方式执行时，最后执行自动化回归测试。
在回归测试中，如果所有测试都通过了，开发人员和测试人员通常不会进一步检查测试运行。如果测试中有失败的测试用例或者自动化测试Scripts时，开发者和测试者就需要引起关注，查明失败的原因。
查找出现 Flaky 的原因
在查找失败测试的原因时，开发人员需要收集数据，试图发现看似随机的结果之间的差异，以便找出失败测试的原因。
代码应该被重新检查，测试本身也应该被重新检查，如果没有发现问题，那么就需要检查外部因素，看看它们是否是问题的核心。
开发人员可能会查看通过的测试是否在一天中的某个时间运行，而失败的测试是否在一天中的不同时间运行，某些程序是否在测试通过时没有运行的失败测试的同时在开发人员的计算机上运行，或者失败的测试是在测试的同一点运行还是在测试的不同时间运行。
有时，Flaky Test 的原因很容易诊断，而且可以很快确定。这是最好的情况。其他时候，没有简单的fix，虽然可能会花费大量的时间和成本，但是开发人员可能需要删除测试并从头开始重写，以确保测试结果的准确性。
现实情况中，Flaky Test 并不少见。例如，谷歌（Google）报告称，其16%的测试显示出某种程度的 Flaky。它们可以导致软件系统暂时停顿，但这些问题和缺陷可以被发现和解决。
1. 测试实施
- 测试是否仅以特定的顺序一致地执行（按照预期）？
- 如果顺序错误，测试是否会间歇性失败，或者与其他测试同时失败？
- 测试是否在特定浏览器/设备上间歇性失败？
- 在特定环境中测试是否会间歇性失败？
- 测试数据是否改变/无效？
- 间歇性故障是否与时间/等待条件有关
2. 测试环境/被测系统（SUT）的稳定性
- 测试失败时是否有任何部署/维护活动？
- 当故障更频繁出现时，任何特定的时间趋势
- 当测试失败时，环境中是否有异常负载？
- 服务器资源使用情况是否有异常统计？
3. 网络分析
- 与Infrastructure团队合作确定
- 测试失败时，网络连接是否出现任何故障
- 测试失败时网络上的负载是多少
由于我们无法很容易地复制故障，因此需要多个团队来帮助进行此类问题的调查，需要收集广泛的日志记录来寻找问题。这一点是至关重要的！
为什么会产生 Flaky Test？
在间歇性故障发生时尝试找出一种模式，然后深入研究RCA以获得相同的结果。很多时候，原因可能是一个糟糕的测试实现本身。一旦排除了这一点，原因可能是在特定情况下暴露的被测应用程序中的错误/缺陷、数据相关问题或环境/网络问题。
我们来分析一下常见的一些原因：
1. 同步/定时相关问题
例子：
- 由于前端处理，页面加载需要时间，
- 异步处理
- 加载后端API/服务器导致响应延迟，
- 在测试实现中没有使用正确的“等待”策略，
- 装载框架/重元素/内容等。
2. 日期/时间相关
例子：
- 基于时区的错误时间计算，午夜
- 基于月/年的日期计算不正确
- 根据每个特定服务呼叫的要求使用不正确的日期时间格式/时区
3. 网络问题
例子：
- 在网络中丢弃数据包，
- 网络连接不稳定，
- 网络负载过大导致连接速度慢，
- 模拟慢速网络条件（例如2G速度）时产品行为不一致等。
4. 浏览器相关问题
例子：
- 每个浏览器的行为不同，使用的资源也不同。
- 浏览器中安装的插件/扩展可能会增加渲染速度、内存使用等方面的波动。
- 根据浏览器及其视口大小需要不同的定位器识别策略。
5. 设备相关问题
例子：
- 设备硬件规格会影响设备性能，因此也会影响测试的执行
6. 测试数据的依赖性
- 动态数据、可用数据的可用性或有效性的变化（由于其他同事/测试使用它/更改它/使用它）
- 缓存策略可能不正确
- 测试开始运行时，被测应用程序的状态不正确
7. 定位器策略
例子：
- 奇怪的和硬连接的xpath定位器，由于UI中的数据（不相关的）变化而改变
- 定位器根据被测应用程序的响应性呈现而改变
8. 应用程序测试环境问题
例子：
- 不稳定的组件，组件的持续部署
- 环境中集成的三方组件/系统的不稳定性
- 其他正在进行的环境使用（可能是其他类型的测试、性能测试等）会使环境变慢，从而影响测试执行
-
测试环境考虑不充足导致了问题发生。
由于当前的技术导致了大量的计算设备和移动设备的选择，如果在UI层进行测试，那么测试过程中必须考虑大量的参数。不同的操作系统、屏幕大小、分辨率、不同的可用浏览器都是必须处理的参数。
考虑到软件的后端部分，软件有多个部分与设备中提供的服务进行交互，例如一些传感器或有线网络，对于这样一个复杂的软件，需要更广泛的范围来全面地包括所有内容。
9. 测试执行机器问题
例子：
- 在并行/后台运行的其他进程/应用程序/浏览器会话将最终竞争和共享设备/浏览器资源，从而影响测试执行
- 运行测试的机器的限制（处理速度、内存等）
- 执行测试所需的软件版本不一致/不正确会导致某些机器上的测试失败
10. 测试执行顺序问题
当顺序改变时，测试是否间歇性失败？
例子：
- 测试依赖于其他测试（用于设置被测试应用程序的数据/状态）
11. 并行执行问题
例子：
- 并行运行时，测试会间歇性失败
12. 测试应用程序中的实际问题/缺陷
例子：
- 加载应用程序
- 竟态条件
- 与其他系统/服务/DBs的间歇性连接
13. 代码变更了
这个原因显而易见，由于修改了程序代码，导致测试变得不稳定了。
14. UI测试
UI测试其实是最复杂的测试。每一次UI的变更，除了做好UI测试之外，功能测试和回归测试也是需要执行的。
为获得成功的测试结果，构建的每个测试都应该是稳定的、可伸缩的和可重用的。使用UI测试，这些目标无法实现，测试很容易被破坏。测试应该与除了UI之外的后端程序进行交互而不是只和操作界面上的UI元素交互。
15. 测试数据的问题
有时，测试数据不能覆盖所有的功能，也不能捕捉到软件可能由于特殊情况而失败的场景。通常情况下，数据涵盖了Positive和Negative的情况，但特殊的情况可能会丢失。在一个成功的开发过程中，特殊测试数据是至关重要的。
测试数据不应成为测试设计的问题，这意味着当有测试彼此独立工作时，测试数据必须单独存储，以便数据不会损坏。
当某些测试依赖于其他测试的数据时，必须采取预防措施，以便在测试运行期间测试数据不会损坏，并且下一个测试可以正常工作。在测试运行期间，测试数据必须在每个点都是正确的。
在测试中减少Flaky Test的技巧
既然开发团队或者测试团队（包括质量管理团队）已经采取步骤进行适当的调查和Root Cause Analyze（RCA）以找到间歇性故障的原因，那么请查看应用程序的上下文、团队技能、基础设施等，以找到“便于从源头解决问题的正确解决方案”。
作为修复程序，最糟糕的做法是盲目地增加等待时间或重新运行测试以希望它通过。请永远别那么做！
修复Flaky Test的“正确”方法可能意味着以下任何一项或多项，甚至更多-
- 架构（Architecture）评审和更改
- 基础设施设置和管理
- 服务/数据库/硬件的配置
- 实现快速反馈的实践
- 促进合作的过程
- 监控和可观察性，以实时了解部署系统的环境和状态
- 在较低的环境中为外部系统提供智能服务虚拟化，使您能够更好地控制、预测和测试正面、负面和边缘案例场景和工作流w.r.t.外部系统
- 日志记录—为了防止/减少重新运行测试以重现间歇性问题，在默认情况下启用大量日志记录是至关重要的。
以下各种形式和类型的日志很有价值，因此需要：
- 测试执行日志
- 网络日志–即作为功能测试的一部分捕获网络流量，以了解特定网络调用中的任何丢弃/问题。例如：HAR（HTTP存档格式）捕获可以给您提供很多见解
- 设备日志（如果适用）
- 屏幕截图（如果测试失败的视频记录不可用）
- 对应的应用程序日志
- 系统运行状况日志–即服务器端内存/cpu使用情况和响应时间
在许多情况下，上述调查需要不同角色之间的协作，因为任何一个角色都可能不具备整个系统的完整背景。
结论
- 认识到测试可能出现Flaky的原因
- 通过仔细深入的调查寻找产生Flaky的原因
- 讨论确定产生 Flaky原因的技术
- 修复根本原因，而不是症状，以使得测试稳定、健壮和可扩展！
转载地址：http://ytvdi.baihongyu.com/