大家好，我是CC，这是第100篇原创。
最近看关于接口测试框架平台的文章蛮多的，但普遍是大而化之的介绍，具体有哪些特色可能需要读者进一步的去摸索才能发现，或者就是在重复造轮子并没有什么特色。今天我带来一个小角度实践，如何通过接口测试平台降低技术团队之间沟通的信息差。
你要解决什么问题？那先聊聊核心痛点
1.开发不维护接口文档
2.维护质量很低，接口改动也不会及时改文档。
3.信息阻塞，改了文档也不一定及时通知测试。
4.就算有通知这个过程总有时间差，或者信息直接被淹没。
5.即使文档维护的很好，测试数据这块前期还有大量沟通。
其他周边痛点：
1.自动化这块对于测试代码编写时间较长，对测试case的设计思考不充分，而且测试自己写的代码容易出bug，测试圈也需要低代码自动化平台。
2.公司安全合规性要求高，工具需要私有化部署，最好可以支持离线脱机使用。
3.没钱，如果有工具，我要免费的，用性价比最高的方式解决问题。
要解决我说的问题和痛点，咱们还是基于解决方案 工具辅助的思路来进行，如果说开发改变了接口规则能够自动同步到我的测试用例，这样子的话将会极大的增加效率，也降低了大部分的沟通时间，相当于搭建了开发和测试之间的快车道，对于执行团队来说，往往沟通壁垒是最容易身心俱疲，内耗很大。
那我刚刚说过的接口的自动同步，有什么具体的解决方案呢？其中一条思路是，我们是可以通过开发接口自动生成的swagger文档，解析swagger生成接口测试case，每次变更可以通过swagger去更新case，同时开发可以完成基本的接口自测，测试也可以知道基本的数据规则，并把精力聚焦于更深层次的接口场景设计和编排。
那有了解决思路，是自研还是选择相应的平台工具支持呢？
自研是时间和成本的计算，但其实能够做到swagger解析的免费工具平台还蛮多的，无需重复造轮子，但基于上述的痛点，我更加注重是否能够私有化部署以及接口场景后续编排的易用性，最终选择了itestwork这个平台进行尝试，这个平台安装一键安装就行，所以上手很快。我演示下如何进行swagger接口文档的导入，这是itestwork主页面，还是比较简洁明了的。
在测试准备中接口用例维护点击导入，就看到了swagger导入的入口
选择相应的swagger文件或者链接，这个平台支持的文件类型还是蛮多的，包括jmeter、postman、httpruner相关的脚本支持，导入后可以在平台中看到接口的case。
导入成功之后，可以看到接口列表页，这些case的录入后，研发可以进行自测，测试也可以根据这些case进行复制、修改编排，不用像一些测试平台去录入case吧？
平台还可以生成接口文档描述：
为什么要写这个?
无论从功能和技术层面来看，能够实现解析swagger的办法都很多，并不是业内创新，但是如果你作为方案解决者，除了技术之外你还需要考虑什么问题？
1.做这件事情的成本，比如让团队成员实现，加上调试还有各类数据的兼容问题，十天半个月是很正常的，如果我能选择合适的工具，10分钟搞定，快速实现业务价值是最重要的。
2.有人问难道价值就是用外来工具吗？必然不是，你工作环境出现的问题最重要的是你的解决思路，不会有外部工具能解决你所有问题，方案整合能力很重要。
3.对于快速选择适配的工具这是一个经验问题，经验来自于你实践，尤其是对于细小的差别，不会有工具介绍的文章上来会描述自身的局限性，能不能用、怎么用需要你自己实践。比如说，对于swagger 中接口的数据对象很复杂，存在深层次的嵌套，有没有能够一一分解出来，这些肯定不会有人主动告诉你，你必须要去尝试，才知道哪些工具是可以的。
所以通过这个小角度实践，我想表达的是做解决方案不仅仅是技术问题，而是对人力成本、时间成本，公司数据安全以及落地细节等你都需要做综合考量，并不是用一个纯技术观点说这个实现起来没什么，这句话没有价值。
这个工具平台目前还没有看到广告，网站是www.itest.work，可以自行了解，也可以和我一起探讨，也欢迎点赞关注分享。
CC简介：
目前在近70人测试团队担任质量委员会负责人，曾就职于一线互联网公司，在知名App上发布过测试专栏，付费订阅人数10000
