有痛点并且找到问题了，下一步就是解决问题。我们分了两步来走，第一个就是对已有UI测试的优化，第二个是对新功能的自动化测试策略的调整。
已有UI测试的优化
针对已有的自动化测试，再回过头逐个去审查UT/API/UI测试代价太高，我们只能是从UI测试优化入手。针对前面提到的3个问题我们逐一去攻克：
- 识别系统关键业务场景
我们首先挖掘出系统中用户要达到的各个业务目标，根据不同的业务目标梳理出不同的业务场景，然后将这些发给客户去评审。客户对我们总结出的这些场景很认可，只是把每个业务目标都赋予了一个优先级，为后续的编码实现给予了参考。
- 重新设计测试场景
UI测试不是着重去测试某个功能是否工作，而更关注的是用户在使用系统时能否顺利实现某个业务目标，因此我们需要知道用户是怎么使用系统的。同样的目标，可能会有多个途径来完成，通过跟客户的访谈以及观察产品环境下页面的访问频度，我们重新规划了测试场景，期待能更贴近用户的真实行为，及时防御可能会导致用户不能顺利完成业务目标的问题。
- 优化测试数据准备，删除重复的测试
对于UI层的过度测试，直接删除和API/UT层重复的测试，保留一条主干路径用来测试系统连通性。
对于不同的业务场景可能需要准备的数据，我们舍弃了之前通过UI执行测试这种成本高的方式，转而以发API请求的方式来准备，这样降低了测试执行的时间，也使得测试更加的稳定。
重新梳理的测试场景帮我们构建了一张较为全面的安全防护网，覆盖了绝大部分的用户使用场景，大家的信心显著提高。如果核心业务受到破坏，立马就可以通过UI测试反馈给相关的人。执行更加稳定的测试也减少了大家对UI测试是否能真的发现问题的质疑，因为随机挂的频率大大的降低，一旦挂可能就是真的有bug了。
新功能自动化测试策略的调整
我们一般会以测试金字塔作为自动化测试的指导策略，下图是我们项目的测试金字塔。
为了避免新功能步旧功能的后尘，我们对自动化测试策略进行了调整。除去以不同层的数量分布来判定策略是否合理外，我们也更看重在这个数量下关键业务场景是否能被有效地覆盖，主要通过下面两种方式来保证：
- QA及早介入自动化测试
质量是需要内建的，不是测出来的。QA从一开始就介入整个流程之中，在story启动的时候会和DEV一起准备任务拆分。在后期验收story的同时也会验收单元测试，确保能在UT/API/Contract层实现的测试都在这些层面覆盖，不仅保证了底层测试的数量要够多，也确保了这么多测试覆盖的点都是合理有效的。在这个过程中，QA把更多的测试思路传递给团队成员，引发大家更多的从质量角度去思考。
- QA与DEV结对写UI测试
最后在整个功能做完的时候，QA也会和DEV结对实现UI测试，涉及到现有测试场景的维护与更新。基于前面对底层测试的review，大家对于整个功能的测试覆盖都有了一定程度的了解，对于UI测试要测得点也会较快的达成一致。另外，QA在与DEV结对实现UI测试的时候，编码能力也得到了提高。
在推动QA更多参与底层测试的过程中，我们更多的从测试角度去影响团队，增加了团队的质量意识。QA的时间被释放出来了，去做了更多有价值的事，比如探索性测试，Log监控与分析，安全测试，产品环境下用户行为分析等。这一些列活动的影响就是产品的质量顺便得到了提升。
总结
等我们把已有功能UI测试优化完，新功能的自动化测试策略开始落实到全组，已经是半年以后的事了。我们慢慢的感受到一切都在回归正轨，之前的痛点在逐步消去，团队交付的节奏也越来越顺畅，对发布产品的信心也更强了。
回顾这个遗留系统的自动化测试优化过程，我们有一些收获：