项目从2009年开始启动，采用的是TDD的开发方式。在这之后的过程中，团队做过各种尝试去调整自动化测试的策略去更好的适应不同阶段项目的特征，比如调整不同类型测试的比例，引入新的测试类型等。
七年之痒 - 痛点
随着项目走到了第七个年头，一系列的变化在不断发生，比如技术上引入了微服务、EventStore等，业务变得越来越复杂，子系统变得更多，更多的人员加入，开始实施按月发布等，这些因素交织在一起凸显出自动化测试的滞后。首先是从团队成员感知到的一些痛点开始的：
- 质量下降 - 这个体现在部署到测试环境的代码质量较差，常常就是新版本部署上去之后某个核心功能被破坏，要么是新功能破坏了老功能，要么是bug的修复把其他功能破坏。
- 测试不稳定 - QA有很长的时间在等待修复或新功能提交出包，而这个等待可能是几个小时也有可能是几天。除去网络问题、部署流水线的复杂性等因素，自动化测试的不稳定性也导致出包的速度也受到了影响。大家往往更关注于怎么能把测试通过了能够出一个包，而却忽略了我们该怎么去处理一个不稳定的测试。下图的run2, run3正是大家在不断的尝试去rerun挂掉的测试。
- 团队越来越忙，开始陷入恶性循环 - 随着功能的逐渐增多，每个月上线的回归测试列表越来越长，QA需要花更多的时间去做重复的回归测试，新功能的测试和回归测试的压力都很大，甚至有的时候根本都没有时间去review下一个阶段的需求，更别提其他一些更有价值的事情。往往回归测试做不完就不得不往下一个阶段推，这种不断往复导致大家对发布的产品信心严重不足。
在这种情况下，自动化测试的有效性和完备性都受到了质疑。本来期望自动化测试能够帮助我们构建一张安全的防护网，保证主干业务不被破坏；随着pipeline频繁的去执行，及时反馈问题，不要等到测试环境才暴露出来；同时能够把QA重复的手工测试时间释放出来，去做一些更有价值的事。可是根据团队所感受到的痛点，我们觉得自动化测试已经不仅没有帮助我们，反而却在一定程度上给团队带来了干扰。
问题分析
自动化测试到底出了什么问题？我们从现有UI测试入手开始分析，发现了以下典型现象：
最有价值的场景没有被覆盖
虽然有较多的测试场景，但是体现出核心业务价值的场景却稀少。我们都知道80/20原则，用户80%的时间在使用系统中20%的功能，如果大部分的UI测试是在测另外那80%的功能，这样一个覆盖给团队带来的安全指数是很低的。
失效的场景
相关厂商内容
《不一样的技术创新》-阿里巴巴双11背后的技术
杭州免费沙龙：从技术实践看如何提升企业研发效能
阿里专家现场分享如何提升企业研发效能？
看明略任鑫琦如何谈关系挖掘算法
如何通过使用 AWS对IT资源实现高级别管控，并大规模实现更高级别的安全性？
功能已经发生了变化，可是对应的UI测试并没有变，至于它为什么没有挂掉，可能有一些侥幸的因素。比如现在点了确认按钮之后新增了弹窗，而测试并没有关掉弹窗，而是通过URL跳转到了别的页面，也没有验证弹窗的新功能是否工作，既有的实现方式确实会使得测试一直通过，但是没有真的验证到正确的点。
重复的测试
同样的测试在UI层跟API层的重合度较高，有的甚至是100%。比如搜索用户的功能，分别去按照姓、名、姓的一部分、名的一部分、姓➕名等等各种组合去验证。我们不太清楚在当时是基于怎样的考虑留下了这么多跟UT/API测试重复的用例，但是在现阶段分析之后我们觉得这是一种没必要的浪费。
另外，不同的测试数据准备都是UI测试执行出来的，很多场景都用到了相同的步骤，我们觉得这也是一种重复，可以通过其他方式来实现。
解决问题
这些问题从某种角度上都暴露出了UI测试年久失修，没有得到好的维护，而新功能的自动化测试又在不断重蹈覆辙，问题积攒到一起暴发出来使得大家开始重视自动化测试。