abluecolor
在解决这个问题之前，请停止编写更多测试，因为这将花费你较高的测试维护成本。你需要尽快行动起来对不稳定的原因进行深入研究，找到不稳定的根因，并且尝试在流程、环境和代码方面做一些优化工作解决它。
MasterKindew
如果你还没有在测试里增加测试日志记录，那么专门花时间补充日志会对你大有帮助，让框架抛出错误并明确测试的错误。
如果你的用例通过使用前端自动化框架开发，那么在发生故障时截图的内容将会很有帮助。
hitchdev
这是一个非常普遍的问题，也是一个很难解决的问题。
我的解决方案：
1 使测试完全闭环。测试是否有通过网络发起对外请求？如果有的话请使用模拟 API 代替。是否使用数据库？使用固定数据在本地设置数据库，并在每次测试后将其清除。
在实践中，我认为几乎没有人使端到端测试是密封的。这非常非常难。不过，这是一个值得实现的目标，原因不仅仅是脆弱。
2 删除测试中所有类似于sleep的内容并用显式等待代替。
3 识别代码中不稳定因素并修复或消除它们。
3 这个问题确实很棘手，因为你要么需要成为开发人员，要么需要开发人员的支持来解决这些问题。问题如下：
- 循环访问没有确定顺序的数据结构（如哈希图）。
- 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成功率机器人，用例每日告警。
针对前两步我这里分享一下解决方法。
我们的不稳定用例主要有以下几类：
- 用例不闭环，调下游的服务不稳定导致用例频繁失败。
- 用例有查询DB的模块，因为经常出现慢查询的情况。
- 测试环境服务器不稳定，这里表现为与线上环境相比，配置不一致甚至缺失。
-
- 这里的配置有DB的表结构、参数中心等
那么对应的解决方法：
- 对依赖下游的服务进行mock。
- 慢查询SQL进行优化，实现基于索引查询数据。如果无法实现基于索引查询，就对查询DB的SQL增大timeout。
解决不稳定用例是一个持久仗。问题的关键在于 如何做到用例的保鲜？
目前我们用例保鲜的方法就是 通过增加0成功率机器人，每日更新0通过率用例，频繁处理不稳定用例。当然这个方案仍不是治本的最终策略，但是在一定程度上能解决了回归耗时较长的问题。
