自动化的几条定律

几个经验定律，未必是对的，但通常是对的

• 一个workflow， 经过的节点越多，出现预期意外情况的可能性就越多。 举例来说，我们对系统发出一个请求，系统回应一个response，这是一个工作流，这里可能存在很多节点，系统在回应我们response之前，可能进行了代理转发，负载分流，查询数据库，可能还去第三方的服务校验了一些什么东西，最后才回应客户端。

基于以上定律，搭建测试系统，尽量不要额外增加节点, 被测系统的依赖组件足够稳定可靠

• 一般单元测试会比集成测试更加快速和稳定
  因为单元测试依赖的组件很少，而后者不然

• 集成测试和单元测试的稳定性理论上都不能真正达到 100% ，无论采用哪种实践中的稳定性定义
  一般我们会用运行 n次 产生预期结果的次数m，计算来表示用例的稳定性

• 不稳定的用例在早期大多数原因是来自编码的错误
  这一条可能很多人会质疑，但是我的经验确实如此，早期以下的一些想法和做法可能会导致写出来的用例缺少稳定性

1. 只追求一次性跑通测试 ok，不考虑重复运行，其他环境下运行
2. 对测试前置条件漠不关心，或者关心得太少
3. 不注意前置条件的恢复。通常一组用例在工作队列中运行时，犯此错误会导致不稳定的现象频发，而且难以定位，我们只能归因于网络抖动，系统不稳定。

• 只有在因系统，网络延迟，或基础组件等因素导致的不稳定才应该使用 rerun 策略。
  实践中，一般在用例开发的晚期才把 rerun策略加上，因为rerun一般增加耗时，如果不排除编码层面的错误，增加这条无异于雪上加霜。

• 怎么分辨那种偶然失败就是bug的情况
  这里搬一搬这个回答
  <>