我在一家做微信营销的公司干技术 leader，带 40 多个人，公司名就不说了。在这个位置上做了好几年，把团队从小带大，公司虽然不算风口浪尖上的高增长业务，但技术这块儿也从来没出过什么问题，我还是蛮自豪的。

带团队时间久了，就能发现整个 Team 都渐渐疲了。前两年老板还专门买了个系统搞 OKR，现在也不大提了；Scrum 我们也搞了，用起来也就那样；项目管理工具试了好几个，禅道、Worktile、现在用 Coding，反正有一个能用的就行；微服务化改造从去年开始在吭哧吭哧搞，我们自己搞得觉得很厉害，但业务部门那边就觉得没啥差别，搞不懂你们研发部门每天在弄些什么，赶紧做我们提的需求要紧。

时间一久，很多原本不是问题的问题也会浮现出来。业务越做越复杂，一层层往上叠，迭代速度就越来越慢，感觉啥都没干呢一个 Q 唰的就过去了。有核心老员工离职，很多东西只有他熟，他一两天就能做出来的东西，新补上的人一两周也弄不出来。新员工进来也很懵逼，那么多业务那么多接口，学上一年也未必学得清楚。

我也三十多了，就感觉自己懂的招儿都用得差不多了。毕竟自己早就离开一线，多年不写代码了，真的要我去给他们解决那些代码层面的问题，也有些力不从心。现在经济形势不好，业务也不是高速发展期，也没法挖一个大牛带进来一些先进生产力。而且要是真的挖了大牛进来，我自己往哪儿放呢。 测试团队的突破

突破最开始来自测试团队，这是我万万没想到的。

测试组的组长是个 93 年的小姑娘，人很踏实能干，最开始团队还很小的时候她就在，后面研发团队扩大，就让她带测试组了。这么多年下来，公司业务那么多细节可能没人比她更懂。不过她在来我们公司之前只有一份小公司的工作经验，没见过什么大厂的世面。

去年搞微服务化的时候，当时几个组长讨论，就说可能对测试的要求会更高，得把自动化测试搞起来。后面测试组长就开始自己吭哧吭哧啃 Selenium，自己一个人折腾了好久，终于把 Selenium 架起来了。

测试这块我不懂，帮不上什么忙，看她一个人弄也有点心疼。终于把框架搭好了，实际用起来的时候我就有点心凉。

干啥都要写代码，她自己学得还行，别的测试根本帮不上忙。这些国外的工具连中文资料都很少，没有技术支持简直都不算问题了。可是连个自动生成的测试报告都没有，这真的不能忍。

测试团队试了一两个迭代，渐渐地就不提了，我也觉得没必要。毕竟引入一个新工具，大家为的都是提效。弄一个只有高级人才才玩得转的工具进来，真的能者多劳了，劳久了对谁都没好处。

有一天，测试组长发我一个文件。我打开一看，是个测试报告，长这样儿。

测试报告

一看到这个测试报告我眼就亮了。所有接口运行状况一目了然，有问题的接口具体是什么问题都清清楚楚。我就回她消息：“真不错👍最近又在用心研究自动化测试工具了？这个测试报告挺好的，花了很多心思吧。”

她很快就回了：“没有😂昨天才发现的这个工具，还挺好用。好像还能做性能测试，我还在研究。”

我兴趣就起来了。没过多久，她又发了一个报告过来。我一看，好家伙，100 个线程同时跑！

性能测试

我问她：“这个怎么跑的多线程？是那种要租客户端的吗？怎么收费啊？”

她回：“免费的😂”

我就叫上后端组长前端组长，跟测试组长一块儿去会议室讨论了一下她用的这个叫 Apifox 的工具。后端组长说：“哦我知道这个玩意儿，不是跟 Postman 差不多吗，怎么还能做自动化测试？”

测试组长说，她就是把我们做的接口文档导进去 Apifox 了，也就花了二十分钟配置，自动化接口测试就跑起来了。

后端组长问：“那这玩意儿能不能做接口监控呢？定时跑一下？”测试组长说：“好像也可以。这边帮助文档里写可以做持续集成。”

后端组长跟测试组长一块儿又花了二十分钟研究，然后就把我们的 Jenkins 和 Apifox 上写好的自动化测试用例打通了，自动化测试每小时跑一次，自动就会生成一个测试报告。

我就很感慨。去年搞微服务的时候也学了不少大公司的微服务架构，看他们搞高大上的微服务治理，每个服务的业务量和响应速度监控，真是让人眼馋。没想到我们一家小公司，接口监控、性能测试，一个小时就搞出来了？

这个 Apifox，有点东西。 这真的是联调吗

我对自己的评价，还是一个有追求的技术人。前几年我就要求开发团队必须把接口文档写好，毕竟公司业务很复杂，开发的人不写清楚，后面的新人更加搞不清楚。

我们的工作流，产品需求出来之后，前后端会先开个会，讨论清楚有哪些接口和输入输出，然后同步进开发。后端写接口的时候，Swagger 自动就把接口文档生成了，就还挺方便的。

自动化测试这个事情之后，后端组长就对这个 Apifox 很有好感。他研究了一下发现 Apifox 可以定时导入 Swagger，不但测试可以直接用来测接口，后端也可以把 Apifox 当 Postman 用，省得自己拼参数写请求了，直接填参数值就能自测，就让后端开发都用起来了。

我们三周一个迭代，一般都会留一周做测试，第二周的周三就得进联调，周五下班提测。前几年还可以，可最近一年问题越来越多。联调往往三四天还弄不完，迟迟没办法提测，就只能往后拖，周末加班还不一定搞完。进到测试环节，还会不断有低级 bug 出来，修 bug 时间也越来越长，每个迭代都要延期。

问题大家也都清楚。无非就是我前面说的几个情况，架构越来越复杂，牵一发动全身，很多新人又不了解业务，做事慢不说，还总是会踩坑。很多问题自己写代码的时候发现不了，等到联调的时候就全暴露出来了。后端组长也跟开发们反复强调要自测，可业务压力又大，写代码都写不完，哪有工夫自测得那么仔细呢。

我记得很清楚，那天是个周五，早上晨会的时候，我心想不知道今天能不能提测啊，这个需求老板盯得挺紧，可别延期了。结果测试组那边说，昨天就已经提测了！已经测了一下午了！

什么情况！？联调可以这么快的吗？

到周一开周会的时候，测试组长说，测得比较顺利，估计明天能测完。

我就憋不住了，问前端和后端组长，是这个迭代的需求特别简单吗？

后端组长说，也不是需求简单，就……这次的接口质量特别好，一调就过了，我们也很纳闷。

前端组长也说，以往前端写的请求接口跟后端经常对不上，就要花很多时间调，这次也不知道怎么回事，基本上都是一两遍就过了。

后端骨干说，我觉得……可能是因为我们用了那个 Apifox……

我：？？？

不就一个调接口的工具吗，还能让人写的代码质量提升了？作为一个十几年的技术人，我觉得这根本没啥关联啊。

我就让他们给我演示一下到底这个 Apifox 是怎么用的。我们讨论了整整两个小时，我总算是搞明白了。

这里面有几个关键点。

第一，后端虽然定义好了接口的输入输出，也有文档，但是写出来的代码未必符合文档里的定义。这里少个字段，那里把 integer 输出成了 string，都是很经常发生的情况。很多问题让后端自测，他们自己根本看不出来。

而后端用了这个 Apifox 之后，有一个特别好用的功能叫数据结构校验，自动就可以判断接口出参跟文档定义是不是一致。很多问题，后端一发送请求就自己发现了，根本不会到联调的时候才暴露出来。

数据结构校验

第二，Apifox 还有一个“动态值”的功能，可以随机生成一系列不同的参数值，数据结构定义起来也很方便。后端就用这个功能，把一个接口自动跑上 10000 遍，连边界值都测出来了，啥问题都自己发现了。

动态值

第三，后端把 Apifox 也推荐给了前端，前端拿这个当 Postman 用的时候，意外发现还能做 Mock 数据。最离谱的是，Mock 规则根本不用写，根据字段名称就能智能 Mock 出很合理的数据，比之前用的 Mock.js 方便多了。

前端直接就拿 Apifox Mock 出来的数据放到界面里用，不但省了自己做数据的时间，最重要是跟接口文档是完全一致的，就算后端中途改了接口定义，虽然接口还没做出来，但 Mock 数据已经自动就变了，前端立刻就发现了，就赶紧去问后端怎么回事。

智能 Mock 数据

咱们做软件的都知道，问题越早发现，修复的成本就越低。前端和后端都能在最早的环节就发现问题，效率可不就上来了吗！

为什么联调每次都那么耗时间？最主要的原因就是因为前端要的数据跟后端给的数据对不上。而用了这个 Apifox 之后，前端跟后端的数据自然而然就对上了！还能自动检查数据格式！

半天就联调通过了，这还是联调吗！？

我就……又很感慨。很多事情是我们习以为常的，觉得联调肯定是痛苦的，就从来没想过为什么这个环节会存在问题，如何去解决这里面的问题。

这个 Apifox，真是牛逼。

我又让几个技术骨干都试一下功能，确认一下符合我们的研发流程。到第二周部门周会的时候，我就跟大家说，全部门都把 Apifox 用起来。 如何搞定合作方

又过了些日子，有一天后端组长嘿嘿笑着来找我，说发现了一个牛逼的东西。

我们的业务性质，经常需要跟银行、运营商之类的合作，就会用到他们提供的 API。银行的研发人员，技术未必好，做出来的文档也不咋地，更不会提供测试环境。每次要用真实数据的时候，我们都是战战兢兢地，就怕出了问题，那损失就大了。

后端组长说，先前说的那个 Apifox 的 Mock 功能，我最近又研究了一下，发现除了能 Mock 前端用的数据，还有另外一种用法。

我们手里不是有银行提供的 API 文档嘛，我们就把这套 API 维护到 Apifox 里面去，做成一个项目。他们有一个“云端 Mock”的功能，可以直接访问服务端接口获取 Mock 数据。我们可以把这个数据当作银行服务器的测试环境来用，每个后端都能访问，也没有次数限制，随便怎么测都行！

我点点头就让他赶紧去搞了。这个 Apifox，能玩出什么花来我都不奇怪了。

过了两天后端组长又嘿嘿笑着来了，说 Apifox 能生成 API 文档，想把我们官网上对外的接口文档换成 Apifox 生成的文档。

我们业务会对接不少公司客户，他们要把自己的业务系统跟我们的营销工具做对接，所以我们专门有一个组是对接客户的，主要就是教他们怎么调我们的接口。

这些客户的开发人员，水平更加一言难尽。毕竟大都是小公司，很多连专职的开发都没有，都是外包的。很多客户嚷嚷着我们接口有问题，远程一看，接口参数根本就没拼对。

我想着 Apifox 那个接口文档我见过，做得还可以，好处是能实时更新，不用专门维护，就同意后端组长把官网上的文档换掉了。

文档换掉之后，过了两周，周会的时候我就发现，客户支持组那边，事情好像少了很多。

我问客户支持组长，最近是新客户变少了吗？感觉你这边以往加班不少，最近都不需要加班了。

客户支持组长说，最近新客户还有变多呢。可客户的问题就变少了很多。我感觉应该是新版的 API 文档的缘故。

怎么回事？换个文档页面，还能让人智商提升了？作为一个十几年的技术人，我觉得这不科学啊！

我会后拉着客户支持组长聊了一个小时，算是搞明白了到底发生了什么。

以往，之所以客户问题多，很大原因是我们的接口比较复杂，参数很多，客户需要照着抄一遍到 Postman 里调好，再到自己代码里拼接，就很容易出问题。

而 Apifox 生成的接口文档，有一个“在线运行”的功能，点开就是一个发送接口的界面，长得跟 Postman 差不多。客户根本不用自己去拼接参数，直接在页面上就把接口给调通了。

而且，这个在线运行还能设不同的环境，后端组长直接搞了一个测试环境开放出去，客户随便调都不会出问题。

在线运行

最离谱的是，这个接口文档还能生成代码？接口调好了，直接就能一键生成请求代码和数据结构代码，客户复制一下就能直接用了。这个生成代码还支持二十多种语言，啥框架都能用。

我算是明白了，容易出问题的环节都被工具解决了，客户可不就没问题了嘛。

这个 Apifox……前途无量啊。 提升了多少效率

我算了一下。

后端，写接口文档的时间能省 80%，自测和改 bug 的时间能省 50%，质量能提升30%。用到第三方接口的话，调接口的时间能省 60%。

前端，Mock 数据花的时间能省 100%，调接口的时间能省 40%。

联调时间能省 80%。

接口测试时间能省 60%，回归测试时间能省90%。还能实现接口自动化监控和性能测试。

客户服务对接的时间能省 70%。

还是那么多人，整个迭代还是三周，但是效率高了，能做的需求比以往更多，质量也更好了，大家也不用苦逼逼地晚上周末加班了。加在一起，Apifox 对我们团队，真的能提升 100% 的效率。

尤其难得的是，我们好像也没经历什么转型的阵痛，内部团队的阻力，似乎一切顺理成章地就下来了。明明引入了一个新工具，开发效率也大幅提升了，可是工作流程还是先前的流程，都不需要做什么专门的调整。

我以前跟一位前辈聊，他说了一句让我印象深刻的话：“产品是最佳实践的载体。”以前我不懂，现在我好像懂一些了。

上个月开上半年总结会，老板狠狠夸了一顿研发团队，说最近的开发效率超出预期，系统稳定性也一直很不错。业务部门的老大也说，之前提了很久的一些需求，近期哗哗地都实现了，一线业务同事们都很满意。

还是挺爽的。

而且，公司一分钱都没花呀。

Apifox 还是个中国团队做的，真心希望他们越做越好，把整个中国的研发团队的效率都提升一大截。

中国该有个厉害的研发工具出来了。

官网地址：