起始：
2017 年 6 月，从上家公司离职到现在的公司，然后开始做接口自动化测试框架，用 Jenkins 来调度脚本，然后搭个服务弄个报告平台。此时就我一个人，即维护框架也写用例外加基础的性能测试工作。流程上就是：找业务线 QA 核对自动化需求，商讨用例，编写用例，然后验收，发布交付部署。效果嘛，其实大家都猜的到，效果不是很好，使用率不高，而且大家基本不是很 care 结果，在加上当时项目比较少活不多，人员也少，所以后来就不了了之。
2018 年后经给领导授权和组内讨论（其实也就三四个人），决定把接口自动化平台化以应对即将到来的项目扩张和人员扩张（2018 年从原来的 3-4 个人，迅速扩张到了 90+）。经过多次设计和架构调整，最终在 2018 上线一个版本，基本可以完成接口测试线上完成，线上逻辑组织，报告在线查看，在线造数据，mock，在线调试等等的功能。但是在使用上还是存在一些不变，这也为后面的推广埋下了第一颗失败的种子。
经过 2018 年的工具打磨，2019 年我们进行了改版，在上半年完成了版本更新，然后进行所谓的大规模使用。但是推行效果很差，基本上大家都不愿意去使用。幸运的是在众多的产品线中，有一个产品线对我们的工具进行了深度使用，也取得了一些显著的效果，让我们还是看到了一丝希望的。后来以此最佳实践为表率，开始了第 N 次全员推广，从管理层面也施加了一些压力，但结果往往是与预期有所差距的。推广了几个月，效果可以说有，但是基本上都是以完成政治任务为主，真正去深度使用的极少极少。培训做了 N 次，但是基本上大家都是来走走过场，需求也收集了 N 次，基本上完成开发后大家也就弃之不用了。有时候真的想到自己和团队小伙伴的付出不能得到大家的认可，很难受，很伤心。
眨眼 2020 年，我抽空看了下平台的使用情况，目前大概周活用户 10+，月活用户 40+，从这个数据上看可能还过的去，但是细数里面的收益可能也是差强人意吧，我看了所有的项目，所有的测试计划，我认为真正在发挥价值的可能不到 30%，其余的或许我不明白业务吧。所以我也不敢过多评论。
再来说说我所见和我所闻吧。我知道除了我们团队和深度使用我们产品的个别团队外，其他团队可能对我们还是深有误解的吧。我也收到过很多背后的吐槽。“这个平台真的不好用，用户体验太差”，“功能上使用复杂，不止从何下手” 等云云，甚至，有一个我们团队的小伙伴，之后去了业务线，也不再继续使用，而且在一次管理会议上说到。“其实我们不建议用界面化的工具，我建议还是以 coding 为主，这样能很快提升团队的能力，我们组就是，我现在留足够的时间给大家 coding”。当然我当时听到很震惊，毕竟此前他也是我们的核心成员，平台部分核心功能也是由他来完成。当然我也很失落，觉得自己很失败。
最近我有时间静下心来好好回顾自己的过去的两年，有收获，收获了一帮志同道合的朋友，收获了一起与平台成长的伙伴，也收到过鼓励和肯定。有失落，失落来自方方面面吧。
反思自动化平台的整个过程，也来小小总结下：平台化需要理性，平台化成功与否，平台本身占 30%，平台使用者是否认同占 40%，领导是否有决心统一化 30%。此是我本次实践含泪总结的三点，想要成功，需要领导极力配合，需要全员有决心，当然需要照顾到平台使用这个的感受，能否成功，绝大原因看平台使用者是否接纳支持这样的模式，毕竟 coding 对自己的找下家有很大帮助，对自己代码提升有很大帮助。界面化的工具之能在当前公司适用，而框架可以轻易的复制。另外平台化之前还是需要慎重考虑自己团队的现状和情绪，毕竟并不是所有人都那么容易接受新的工具，就算被动接受，后期效果也不会太好。所以还是得视团队，视公司情况而定。
平台化过程中还是需要不断与一线使用的小伙伴保持沟通，加强参与感，平台需要与使用者一起成长。这点也很重要，推广一个平台是需要很长实践，毕竟改变一个人的习惯需要时间去慢慢影响。只有当平台成为习惯，大家才能接纳，使用，喜欢，再到不断去提需求，平台才能不断的进化。
以上都是自己的视角，有什么不对，还请大家轻喷。