产品的复杂程度，项目组规模，自动化测试跑的时间，发布的频率等都会不同程度的影响自动化测跑的频率。下面将分析不同情况下哪种策略比较合适。
1 每晚运行
尽量错开产品高峰期，在没什么用户使用产品的时候跑，是一个通用的简单的解决方案，适用于大多数情况
好处是每天早上都能得到一份自动化测试的报告，如果有问题则能一天内发现和解决
可是如果一天之内有10-20个merges， 依然nightly run，则你无法知道具体是哪个merge引起问题，我们可能需要花费额外的时间去定位问题，因为这个问题可能是其他team的改动引起的。
2 每次发布之前运行
当你的产品功能很简单，大多数情况下手动测试已经足够，这种情况每个release 运行一次自动化测试就能满足需求。
另一种情况正好相反，如果你的产品功能复杂，自动化测试量很大，需要花费你几天的时间跑自动化测试和分析测试结果。这种情况如果自动化测试运行的频率高的话，则会需要大量的时间。此时选择每个release运行一次自动化测试会相对合适。
3 需要的时候手动运行
如果你的项目release的频率很低，产品功能简单，则可以考虑在需要的时候手动的触发自动化测试。
4.每次PR 的时候运行
当产品是由多个项目组组成，大家协同开发，这样会导致自动化测试非常脆弱，比如一天10-20次的code merge或者在code freeze之前的大量代码的merge，都会使你的自动化测试挂掉，需要花费大量的时间去定位导致自动化测试失败的原因。
这种情况下，选择每次PR的时候都触发下自动化测试，一旦某个code merge产生问题就能立刻感知到。
需要注意的是，如果要每个PR跑的话，你的自动化测试运行的时间不能太长，自动化测试稳定性要好，否则会影响正常的开发速度。
5.混合
根据需要，多种策略混合。
