第一次的过程是非常漫长且痛苦的，我最经常看到的就是她在加班写代码。她用了很大的力气希望能够把这个平台应用到更多的系统上去，但是平台本身的缺陷导致引入一个新的系统就要花费极大的力气。每个系统都有自己的复杂性，而平台既缺少相关的驱动，又没有管理，还需要测试人员自己写代码。
第一次就这么漫长的失败了，年中组织调整，我们深入的讨论了一下，认为这个平台本身缺少的内容太多了，并且使用的groovy脚本看起来虽然很方便，但是实际上和开发团队的框架结合得并不好。
有了第一次的经验，我建议她是否可以考虑使用界面化的方式，规避测试人员学习代码。她对此的看法是，一方面界面化的工作量非常大，她等不起；另一方面，测试人员事实上非常喜欢学习代码和数据库，他们很开心自己能参与到开发工作中来。
2017年下半年，她换了个支持更给力的平台（这公司就是自动化测试平台多，我听说的就有四个），再一次开始一个系统一个系统的引入。
她依然选择一个人战斗，每天加班写代码。关于为什么她要写代码，我和她聊过一次。我认为，你只要把需求提给平台开发团队，让他们实现就好了。她告诉我，平台开发团队并不关心前场在应用的时候到底遇到了什么困难，他们有自己的节奏，因此平台缺失而我们又有需要的功能，我们只能自己干。
你可以想象，一个测试人员，一个人孤军奋战，攻克一个个技术难题，完善这个平台；而平台开发团队则醉心于提供一个大而全的平台，让你在上面“干什么都行”。
我跟她表示，如果有需要，我可以带领我的开发团队来加班帮你——然而还没等我们帮忙，她自己干完了。
这一次，她们是从一个系统开始的，将这个系统100%的测试用例全部自动化。在这个过程，她培养出来了一个测试小伙伴，这个小伙伴帮助她来将更多的用例自动化，她则添加更多的功能，例如数据库检查工具、用例管理、数据初始化工具等等。每开发出一个新的工具，这些培养出来的小伙伴们就会更新自己的自动化测试用例库。
这样做的好处是：
- 每个测试人员都会逐步的参与进来，这个过程不快也不慢，大家都参与，于是每个人的需要都被考虑到了，所以大家都认可。
- 测试工具的开发者是资深测试人员，她清楚自己目前最需要的是什么，她提供的功能让所有的测试人员都用得舒服，她的代码解决的是最实际的一线问题。
- 从业务用例着手，拒绝理论正确。还记得之前我的总结，测试人员的业务远远优于技术。所以让她们挑选那些最频繁被使用的、最重要最核心的业务用例，把好钢用在刀刃上。
- 小步快跑的结果就是，你可以亲眼见到她们的成果，这些成果会给整个团队极强的信心，让她们继续搞下去。每个人（包括领导）都会有这样的信念，我要提高，我要参与，我们能行！
这就是价值驱动的自动化测试平台建设思路，2018年她继续拓展她的平台，现在又在一家新的公司建设自动化测试平台了。
价值驱动的自动化测试平台建设
如果你问我，自动化测试平台建设的目的是什么，我可能说不出来，但是我知道一个不会错的答案，那就是：产出价值。
这个价值一定是客户导向的。我们之前说过，测试团队的客户有：
- 产品的最终用户
- 项目负责人以及更高层次的领导们
- 开发团队
- 其他相关的团队成员
而自动化测试平台的客户就是测试团队本身，这个平台通过服务测试团队来服务测试团队的客户们。
所以，这个平台要能够帮助测试团队完成他们的使命，要能够达成下面这两点：
- 用户的关键业务
- 严重的生产事故
额外的，平台还能通过自动化来提升测试团队的工作效率。
所以，自动化测试平台最重要的场景，就是针对这些核心业务用例的回归测试。
假如你是平台建设者，你只有一个月的时间，只有一名开发人员，你到底应该做点儿什么？
我认为，你至少要把冒烟测试给自动化了，就这一条就足以产生肉眼可见的价值。如果你的动作足够快，你甚至可以把核心业务用例的回归测试全给做了，哪怕你只验证了响应报文不管数据库。
围绕着产品质量和团队效率两个价值核心不断丰富你的自动化平台，能够帮助你更容易地推销你的平台，领导会对你更有信心，测试团队会更爱你。这样，你应该不会像我一样遇到资金链断裂的问题，你想要推动测试团队改革他们的流程也会遇到更小的阻碍，因为他们相信你能给他们带来价值。
是的，自动化测试平台一直是各个企业技术资源的黑洞，很多公司建设自动化测试平台的初衷往往是希望有一个高大上的解决方案让自己的测试水平起来没那么Low。很多测试总监也出于提升自己团队地位的考虑希望能够通过这样的平台来获得更多的权力。而测试平台的设计师则往往是严重脱离生产实际的技术人员，他们会醉心于大而全的设计，高大上的功能，最前沿的技术，把他们认为最美好的东西疯狂的堆砌到自己的框架里。
而这种思维造就的结果就是，这个平台会成为一个黑洞，疯狂的吞噬掉大量的技术资源，然而你几乎见不到它发出什么光来。