很多小伙伴都比较关心如何构建一个接口自动化平台，笔者恰好有从零开始搭建自动化测试平台直到产品商业化的过程经验，可以和大家分享下。由于企业性质的问题，无法分享过多的代码，本文旨在分享个人在构建整个平台变化过程中的思考和总结，给想往这方面发展的小伙伴们一些借鉴，也算是自己的一个阶段性总结。本文主要总结了以下几个问题：

1. 如何针对团队现状做技术型

2. 平台演进过挰中会经历的阶段有哪些，需要分别注意什么

3. 区分平台能力和个人能力，不要被表象迷惑

NO.1 关于技术选型的问题

万事开头难，现在世面上关于接口自动化平台的资料，不管是开源的 (虽然很多都是 Demo 级别的），还是商用的，都非常的多。也有一些比较被业内认可的专业化工具，如 Pytest，PostMan，Jmeter 等等，但具体到自己的团队，应该如何选择一个好的框架做为底层基础呢？（不需要自己再造轮子，也不一定会比别人造的好）？个人认为，至少要从以下几个方面考虑。

1.1 团队的现状是什么？
如果当前团队已经有了部分接口测试的工作在开展，只是没有形成标准化、持续化，那么尽可能就以现有的工具为底层基础，进行开发，培养用户习惯的成本是很高的，别人也不一定乐意，还涉及到迁移成本的问题。如果当前团队还没进行过多的接口测试，那么就可以慎重的进行技术选型

1.2 团队的资源有哪些？
这里指的资源其实就是研发能力，会有几个人一起研发，还是你自己一个人？大家擅长的开发语言是什么？是否有能力做前端页面？是否有时间投入（很多时候并不一定会给工时）。对于开发语言而言，不需要纠结是 Java 还是 Python，擅长哪个就用哪个。能和开发团队保持一致最好，不能也关系不大（如果你真的熟悉了一款语言，那么转换到其它语言上也不是什么难事。笔者从 C 切换到 Java，再到现在的 Python，适应过程并不会太长）

1.3 为什么要选它？
在确定完开发语言之后，就可以对应的去做选型了，各语言都有大量的开源框架可以使用（Java 的 JunitTest，TestNg 等，Python 的 Pytest，HttpRunner 等），本质上没有太大的区别，只要你选的框架文档齐全，还在持续更新，问题就不大。没人维护的框架不要选（特别要注意 GIT 上那些 Demo 类的框架，很容易误导人）

小结：技术问题一定要从团队的实际情况出发来实践，因为做出来的东西，不管是平台还是框架，都是要给到具体的人去落地使用的，所以要尊重你的用户，纯粹 show 代码能力的事少做（如果真想，去 GIT 上面提交代码，在公司，还是以解决问题为主）。

在确认完技术选型后，接下来就可以进入研发阶段了。此时千万不要想着要规划一个大而全的平台，而做过多技术设想，应当围绕当下团队最迫切的需求来做，按敏捷的说法，要先交付 MVP 版本，让团队认可你的平台，真正帮助他们解决问题。后期才会有推动别人使用的空间（这里会涉及到一个问题，那就是个人与平台的关系，很多会觉的如果平台化了，那测试人员的能力如何提升？这个问题放到最后讲，希望你能意识到这个问题，很重要）。当然，如果你有几十人的团队，那另说。

NO.2 第一阶段核心问题：能用
笔者所在的团队当时并不具备进行接口测试的能力，测试人员没有接口测试意识，且无代码能力，需要开展接口测试时，无从下手。分析当时的情况后，制定了本阶段需要解决的痛点。

痛点 1：能够通过页面配置，快速生成接口及其用例。
解决方案：基于 HTTP 协议（集团内部基本上都是基于此协议交互），在页面上配置相关信息，就可以生成对应的接口，并支持直接调试，避免出现接口不可用的情况。同时，对于 HTTP 的 body 内容做了丰富的支持，以便适应不同的参数类型。

痛点 2：能够支持接口参数传递。

解决方案：HttrRunner 本身就支持参数传递，也支持快速运行用例（框架的好处），所以这个痛点可以很方便的得到解决：

痛点 3：产出报告对于测试人员更友好些。

解决方案：HttpRunner 原生的报告比较不友好，所以自己解析原报告数据，做了聚合，让测试人员可以更直观的查看结果，同时可以让测试人员看到参数化或者数据驱动后，发出去的真实请求是什么，方便测试和开发定位问题（遇到报错的接口，如果确认是 BUG，直接复制丢给开发，省事省心）。

小结：在此阶段，其实需要磨合的时间是最长的，团队的磨合、架构的磨合、业务的磨合等等，最重要的是把团队顺利的运转起来。技术上基本没什么大问题，都是基于底层框架原生的能力，做了前端的封装，降低测试人员的使用门槛，让测试人员理解、接受接口测试思想，并指导他们使用平台，设计接口测试用例，让接口测试真正落地并产生效果。

NO.3 第二阶段核心问题：好用

在完成第一阶段的内容后，进入第二阶段，这个阶段最核心的思路是推广 + 优化，目标是让平台好用，我们处于并将长期处于这个阶段！！。什么是好用，用户说了算，所以团队花了比较多的时间去落地平台，去分析测试人员的痛点和难点，结合自身的经验和能力，一点点的补充平台功能。简单结总下这个阶段解决的几个典型痛点：

痛点 1：分析接口太麻烦了，需要一个个手动录。

解决方案：通过对接 Swagger 平台、Fiddler 工具等，让测试人员不再纠结接口维护，可以更专注于用例的设计。

痛点 2：部分接口开发未完成，或者一些外部接口如何处理？

解决方案：集成 Mock 服务，针对已经定义好的接口，可以自定义返回结果，同时生成一个只是域名不同的 URL，这样在写测试用例时，想要调用 Mock 的接口或者真实接口时，，就只需要换个域名即可，其它都不用变，非常灵活。

痛点 3：当开发的接口发生变化时，测试人员如何第一时间获知呢？

解决方案：提供契约功能，通过算法匹配运行结果与最近一次运行成功的结果做 diff,获取接口结构的变更，提醒测试人员。（现在对于 Spring 框架，有专门的契约测试服务可以使用，笔者当时没有注意到，所以采用了另一种思路）

痛点 4：让测试执行前置，提高测试准入门槛。

解决方案：随着公司 CICD 的完善，可以让开发人员在合并代码时，自动触发接口测试，验证主流程不受影响。把平台用例对接到公司的流水线上，成为质量门禁的一环，确保新代码不会影响核心功能。

痛点 5：如何解决业务个性化需求？

解决方案：随着服务的团队越来越多，我们需要对应的场景也千奇百怪，如何在标准化的平台上应对一些个性化的需求通过在接口用例中引入前后置函数的功能，让一些个性化的需求，业务团队可以自己编写部分代码去做处理，同时，这部分代码还可以保存成模板，方便复用。

还有一些如：公共登录、环境区分、数据驱动、数据生成、定时任务、文件管理 等等功能点，不再一一列举，主要还是根据团队实际需要来完善功能点，最怕的是测试开发人员自嗨，写一些测试人员不太用或者不是痛点的功能，让平台沦落成样子工程。一定是要结合测试人员的需求来开发功能点。我们处于并将长期处于这个阶段！！平台使用的技术不是业内最好的，但一定是团队当下的最优解。

小结：在此阶段，我们获得了很多团队和客户的认可，例如在集团多个 BU 的落地实践，协助外部客户完成测试价值提升。平台本身也通过了信通院的 DevOps 三级认证（先进级），证明了平台的价值，不至于变成样子工程，这是笔者认为得到的最大的收获和认可。

NO.4 第三阶段：未来规划

平台功能需要不断演进，不断满足更多的需求。目前平台也没有停止探索更多的需求，在未来的规划中，我们希望解决以下问题：

问题 1：测试仓库的搭建，让创建测试数据不再成为难点

问题 2：接口测试与代码覆盖的对应关系，为精准测试提供数据支撑

问题 3：逆向用例（混沌测试）的自动化生成

问题 4：。。。。。。

NO.5 个人与平台

我们回到最初的那个话题，当我们采用平台化来做专项测试时，封装好功能，降低对测试人员的要求，只要通过页面编排就能够执行相关的测试。那么，测试人员如何提升自己呢？这里涉及到的角色有两个：个人与组织，这两个角色对平台的诉求是不一样的。

组织：从组织的角度来说，希望的是有统一规划和管理，同时能够有效降低准入门槛，通过简单的培训，让更多的测试人员能够开展专项测试，所以更需要平台化的管理方式，能够提供标准化的、可视化的、操作方便的服务 。

个人：当你进入到一个团队中，有现成的平台给你使用时，一定不能满足于使用平台，而是应该抓住机会去了解平台的具体实现，甚至参与到平台的研发过程中，把别人的开发设计和解决问题的思路变成自己的心得体会。如果只会依赖公司平台开展专项测试，那是平台的能力，而不是个人的能力。这也是为什么很多面试官不太喜欢大厂出来的同学，因为离开了平台，个人的能力有可能出现断崖式的下跌，切记（其实很多岗位都会有类似的问题，要学会区分哪些是自己的能力，哪些是平台给你的加成）。