如何处理不稳定的自动化测试？

一、文章来源: mp.weixin.qq.com
忘记原文链接了

abluecolor
在解决这个问题之前，请停止编写更多测试，因为这将花费你较高的测试维护成本。你需要尽快行动起来对不稳定的原因进行深入研究，找到不稳定的根因，并且尝试在流程、环境和代码方面做一些优化工作解决它。
MasterKindew
如果你还没有在测试里增加测试日志记录，那么专门花时间补充日志会对你大有帮助，让框架抛出错误并明确测试的错误。如果你的用例通过使用前端自动化框架开发，那么在发生故障时截图的内容将会很有帮助。
hitchdev
这是一个非常普遍的问题，也是一个很难解决的问题。
我的解决方案：1 使测试完全闭环。测试是否有通过网络发起对外请求？如果有的话请使用模拟 API 代替。是否使用数据库？使用固定数据在本地设置数据库，并在每次测试后将其清除。在实践中，我认为几乎没有人使端到端测试是密封的。这非常非常难。不过，这是一个值得实现的目标，原因不仅仅是脆弱。2 删除测试中所有类似于 sleep 的内容并用显式等待代替。3 识别代码中不稳定因素并修复或消除它们。4 这个问题确实很棘手，因为你要么需要成为开发人员，要么需要开发人员的支持来解决这些问题。问题如下：

• 循环访问没有确定顺序的数据结构（如哈希图）。
• SELECT 查询嵌套在代码中。
• 使用随机数（这可以通过修复测试运行中的种子或模拟 RNG 来解决）。 ToddBradley 我最近一份工作的公司有遇到这个问题。当我加入时，我们遇到了测试结果不稳定的大问题。工程主管总是指责测试同学，而质量主管则不太确定这个锅该不该背。所以我的工作就是把这一切问题都解决掉。这是一项巨大的工程，但最终我们发现该产品不稳定，而开发人员从未意识到这一点，整个过程蛮好玩的。因此，这里的教训是，“不稳定的自动化测试环境” 可能有很多原因：
• 测试用例设计不当
• 有缺陷的测试基础设施（服务器等）
• 被测系统不稳定，至少在测试环境中是如此 重试只是把问题掩盖起来，所以我的建议是避免重试，除非问题出在产品方面并且没有人愿意修复它（在这种情况下，你需要首先询问是否值得测试）。 Rough-Supermarket-97 你可以使用一些统计模型来量化这一点，但从我的角度来看，依赖点与满足通过定义所需的测试步骤之间存在关系。对于依赖于穿过多个接缝的每个测试步骤结果（将 API -> 队列 -> DB 视为 3 个独立的接缝），失败的可能性随着接缝的数量呈指数级增加，并乘以依赖于的步骤数那些接缝。您可以想象，这种可能性可能会变得相当高，尤其是当您根据 I/O 瓶颈和其他更多基于基础设施的故障点等因素考虑接缝发生一般故障的概率时。那么如何稳定集成测试呢？其一，让它们尽可能小。这将是我考虑的第一阶段。其次，问问自己，“我真的关心测试基础设施吗？或者我更关心应用程序如何响应其依赖项？” - 这个问题应该引导您确定模拟在哪里有用以及您可能仍然想在哪里使用该依赖项。 Yogurt8
• 测试环境总是不稳定的。
• 良好的日志记录对于任何自动化项目都至关重要。 Ikeeki 我认为不稳定的测试代码是写的质量差，如何处理质量不佳的代码？ 你会发现有时这是一个不稳定的测试，但有时它是一个真正的应用程序错误。我们越减少脆弱性，后者就越开始发生。但 IMO 的关键是测试指标、测试仪表板以及解决任何未达到 90% 以上成功率的测试。作为 SDET，我会第一个排查报错问题，但如果我能证明测试代码之外存在某些问题，那么我会找一个该领域测试专家一起解决这个问题。有一次，我编写了一个 Slack 机器人，当新测试不稳定或在所有分支上开始失败时，它会向我们发出警报，这个机器人对我们非常有用。 wegotallthetoys 显示每个测试执行步骤的测试报告。我曾经处理过一组每天运行的 2000 个测试，每次运行可能会出现 60-70 个失败测试，我们的测试报告意味着可以在几个小时内 review 这些失败。该套件测试报告包含：
• 每个执行动作的屏幕截图
• 利用查询来选择要使用的测试数据
• 输入任何操作的所有数据
• fwk 抛出的任何异常 根据我在该测试集中的经验，失败的最常见原因是与测试数据相关，例如，测试正在尝试完成某数据的操作，而该某数据未处于当前操作能处理的状态。 Brankksss 我认为你可以使测试尽可能更加密封。模拟一些依赖项，在 Docker 容器上设置 SUT，并仅对 “不稳定” 环境进行测试。我不知道你的测试环境是如何构建的，我猜测你的依赖项每次都不会更新版本，所以这就是我对你的情况的看法。看了上述的回答，大家也许有体感了。针对不稳定的测试处理方法，可以归结为以下几种：
• 用例开发角度：适当记录用例执行日志；用例编写自闭环，多使用 Mock。
• 识别并消除测试中不稳定因素，例如 sleep。
• 建议消除重试机制。
• 增加测试不稳定告警机器人。 今天为什么分享这个问题，主要是团队也面临相似的问题。我们团队自动化用例数量将近有 1w，因此排查不稳定测试用例耗费的大量人力。团队处理这个问题也专门作为一个专项来处理。下面我分享一下我们团队处理不稳定测试的经验。处理这个难题的第一个问题就是 如何定义不稳定测试？我相信针对这个问题，每个团队会基于自己的实际情况可能会有不同的定义。我们团队的自动化用例 每天会运行 12 次。我们定义的不稳定的测试是每天运行成功率为 0 的用例，即 0 成功率用例。OK，问题已经定义，那么如何处理不稳定测试？我们的处理方式分三步：
• 搜集问题用例，分析报错原因，对问题进行归类。
• 针对已知问题进行优先修复。
• 增加 0 成功率机器人，用例每日告警。

针对前两步我这里分享一下解决方法。我们的不稳定用例主要有以下几类：

1. 用例不闭环，调下游的服务不稳定导致用例频繁失败。
2. 用例有查询 DB 的模块，因为经常出现慢查询的情况。
3. 测试环境服务器不稳定，这里表现为与线上环境相比，配置不一致甚至缺失。
   1. 这里的配置有 DB 的表结构、参数中心等 那么对应的解决方法：
4. 对依赖下游的服务进行 mock。
5. 慢查询 SQL 进行优化，实现基于索引查询数据。如果无法实现基于索引查询，就对查询 DB 的 SQL 增大 timeout。 解决不稳定用例是一个持久仗。问题的关键在于 如何做到用例的保鲜？ 目前我们用例保鲜的方法就是 通过增加 0 成功率机器人，每日更新 0 通过率用例，频繁处理不稳定用例。当然这个方案仍不是治本的最终策略，但是在一定程度上能解决了回归耗时较长的问题。

*以上文字均来源前面链接的文章 && 下面为个人简短思考 *

二、个人思考
Author：xxx
今天在公众号看到上面这篇文章，有感而发，对上面文章及思考， 针对不稳定的因素有部分补充及同感，
一句话：没有解决不了的稳定性因素，如果有那就是处理不够好

1. 用例设计不当，(用例设计不当分好几种)
   1. 编写的代码逻辑不够严谨，代码本身不够稳定，
   2. 等待获取数据， sleep 过多，
   3. 用例不够独立，依赖上游数据导致失败，或者依赖太多，
   4. 用例和测试数据不够独立，
   5. 慢查询

总结：个人认为 这种均可以解决，且也好解决，但是这也是目前遇到的不稳定因素中比较多的，
解决：需要详细分析不稳定的因素 - 需要对日志分级，对不稳定的因素分类，给出详细的解决方案，

1. 测试环境服务器的不稳定，

   1. 这种需要运维和研发，测试 共建稳定的测试环境，这是做好自动化的前提，不细说；
   2. 当然存在测试环境不稳定的情况 (只是相对 online 环境)， 需要有部分重试的机制，得需要根据场景来细说；

2. 自动化用例都有，但是没有发现问题

   1. 遇到过很多人写的脚本执行就是发现不了问题，有的人写的能够发现一些问题，
   2. 用例设计的场景是关键，好的用例可节约很多的回归时间！
   3. 用例效验的数据，

================ 针对上文原作者内容评论 ======================

• 测试用例设计不当 -> 大部分都是这个因素导致 ！
• 有缺陷的测试基础设施（服务器等） -> 我认为自动化正好可以检测一套新的环境部署是否 ok
• 被测系统不稳定，至少在测试环境中是如此 -> 应该是相对而言，所以需要有对应的自动化策略；
• 测试环境总是不稳定的。 -> 存在，需要有对应的策略来应对，例如获取数据可以动态等待，如果经常如此，则需要共建环境了；
• 良好的日志记录对于任何自动化项目都至关重要。 ->Important

测试报告包含：

• 每个执行动作的屏幕截图 -> 建议针对报错才截屏，否则占用资源，
• 利用查询来选择要使用的测试数据 -> 如果查询没有怎么办 ？ 建议数据最好闭环，
• 输入任何操作的所有数据 -> 赞同
• fwk 抛出的任何异常 -> 赞同

不稳定的测试处理方法，可以归结为以下几种：

1. 用例开发角度：适当记录用例执行日志；用例编写自闭环，多使用 Mock。 -> 用例闭环很重要，很多人没意识到！ 数据的独立性 ！
2. 识别并消除测试中不稳定因素，例如 sleep。 -> 赞同
3. 建议消除重试机制。 -> 赞同，我这指的是单个用例的赞同，整个工程可定制配置重试机制，可排除部分环境因素导致的失败！
   1. 重试机制有个作用就是排除环境因素，不好的地方稳定性问题可能没有暴露，但是如果每天都执行，不稳定因素迟早会暴露的，
   2. 重试机制 - 会增大用例执行时间，
4. 增加测试不稳定告警机器人。 -> 赞同，可脚本可平台查看用例执行的历史记录，

那么如何处理不稳定测试？我们的处理方式分三步：

1. 搜集问题用例，分析报错原因，对问题进行归类。 -> 赞同
2. 针对已知问题进行优先修复。 -> 赞同
3. 增加 0 成功率机器人，用例每日告警。 -> 赞同

建议增加代码评审环节，排除代码本身不够严谨导致的问题或者其他问题，集思广益，一起探讨思考不足之处；

针对前两步我这里分享一下解决方法。我们的不稳定用例主要有以下几类：

1. 用例不闭环，调下游的服务不稳定导致用例频繁失败。-> 用例不闭环，数据不闭环导致！
2. 用例有查询 DB 的模块，因为经常出现慢查询的情况。 -> 分场景处理
3. 测试环境服务器不稳定，这里表现为与线上环境相比，配置不一致甚至缺失。-> 建议执行之前先 setup，初始化或者自动化检查配置信息即可，没有就创建 (均自动化流程实现)

解决不稳定用例是一个持久仗。问题的关键在于 如何做到用例的保鲜？
目前我们用例保鲜的方法就是 通过增加 0 成功率机器人，每日更新 0 通过率用例，频繁处理不稳定用例。当然这个方案仍不是治本的最终策略，但是在一定程度上能解决了回归耗时较长的问题。
用例不稳定主要还是人为因素导致，建议 框架清晰，用例及数据独立，增加代码 review 环节，排查代码本身存在的处理逻辑，设计等等不合理的场景，可以解决 97% 以上的不稳定因素；

需求变动或者接口变动导致的用例修改的场景，怎么样才能更快更好的重构相关用例的场景，主要是高质量的用例，这是需要思考和探究的地方 ？
监控变动记录均已实现，简单的重构用例也可以实现，重在高质量 ！

• END -