新功能自动化测试策略的调整
　　我们一般会以测试金字塔作为自动化测试的指导策略，下图是我们项目的测试金字塔。

　　为了避免新功能步旧功能的后尘，我们对自动化测试策略进行了调整。除去以不同层的数量分布来判定策略是否合理外，我们也更看重在这个数量下关键业务场景是否能被有效地覆盖，主要通过下面两种方式来保证：
　　（1）QA及早介入自动化测试
　　质量是需要内建的，不是测出来的。QA从一开始介入整个流程之中，在story启动的时候会和DEV一起准备任务拆分。在后期验收story的同时也会验收单元测试，确保能在UT/API/Contract层实现的测试都在这些层面覆盖，不仅保证了底层测试的数量要够多，也确保了这么多测试覆盖的点都是合理有效的。在这个过程中，QA把更多的测试思路传递给团队成员，引发大家更多的从质量角度去思考。
　　（2）QA与DEV结对写UI测试
　　后在整个功能做完的时候，QA也会和DEV结对实现UI测试，涉及到现有测试场景的维护与更新。基于前面对底层测试的review，大家对于整个功能的测试覆盖都有了一定程度的了解，对于UI测试要测得点也会较快的达成一致。另外，QA在与DEV结对实现UI测试的时候，编码能力也得到了提高。
　　在推动QA更多参与底层测试的过程中，我们更多的从测试角度去影响团队，增加了团队的质量意识。QA的时间被释放出来了，去做了更多有价值的事，比如探索性测试，Log监控与分析，安全测试，产品环境下用户行为分析等。这一些列活动的影响是产品的质量顺便得到了提升。
　　总结
　　等我们把已有功能UI测试优化完，新功能的自动化测试策略开始落实到全组，已经是半年以后的事了。我们慢慢的感受到一切都在回归正轨，之前的痛点在逐步消去，团队交付的节奏也越来越顺畅，对发布产品的信心也更强了。
　　回顾这个遗留系统的自动化测试优化过程，我们有一些收获：
　　（1）大家说到UI测试往往更倾向于如何编码实现，但我们希望开始UI测试的时候能多关注下测试用例的设计是否合理，是不是能够体现出业务价值
　　（2）UI测试的用例和代码都是测试资产，需要跟产品代码等同对待，不能写出来不管不顾，没有维护是不可取的
　　（3）自动化测试不仅仅是UI测试，需要和UT/API等其他底层测试一起分工合作，作为测试策略的一部分来为产品质量保驾护航