一、引言
对于大厂的同学来说，接口自动化是个老生常谈的话题了，毕竟每年的MTSC大会议题都已经能佐证了，不是大数据测试，就是AI测试等等（越来越高大上了）。不可否认这些专项的方向是质量智能化发展的方向，但是凡事都遵循2/8定律，80%的从事软件测试的同学或许对这些并不感冒，因为大部分测试同学分布于中小厂，而他们大多停留在如何更好更快地进行接口自动化的阶段。
小厂质量团队地位低，在团队中发言分量轻，项目中往往处于劣势，项目的测试时间不能保证，更别提搞什么高大上的质量专项了，能把接口自动化测试做好就是大事一件，节省不少时间了。
因此，聊聊接口自动化还是非常有必要的。
二、“JMeter式”的自动化设计思路
毫无疑问，聊起接口自动化，大家可能第一时间联想的就是自动化工具、自动化框架，例如JMeter、Postman等。这些工具学习成本小，掌握这些工具用法算是一条腿迈进了自动化测试大门。当然我建议大多数测试菜鸟先从工具的使用学起，话说“读书百遍，其义自见”，用多了你也就理解了工具本身的设计（模式）精髓，为将来自己动手设计工具打好基础。
我也曾设计过接口测试工具（参考文章），但是现在回过头再看看开发出来的东西，或多或少有些JMeter的影子！是的比葫芦画瓢，JMeter已经在你脑海里先入为主了，你开发的接口测试工具有它的影子也不足为怪。换句话说，这或许是JMeter式的重复造轮子。
以我之前设计的测试工具为例，使用它就要动手搜集接口信息，动手组装入参，动手写断言。。这TM就是和使用JMeter写用例要做的事情一样的嘛！
JMeter式的自动化测试，我认为是“高级”的手工测试。自研的测试框架写用例往往需要代码基础，但是写过的都知道，业务用例代码重复度挺高的。而更重的在于用例的维护，毕竟大家写的代码风格迥异，维护的难度更大，甚至不如JMeter的用例维护来的方便。
意识到这个问题后，我也尝试在github上搜索stars比较多的开源自动化工具，遗憾的是这些框架始终摆脱不了这个“设计套路”。例如
当然，说上面这些并非不建议大家开发接口自动化测试框架，自研的接口测试框架同样有很多优点。
测试工具开发的测试用例往往不易于维护，试想一下当你维护JMeter生成的各种JMX文件场景。
大量的测试用例可重用性差，例如登陆模块，每个接口调用前都要获取cookie，而登陆则是前置模块，使用JMeter开发用例需要每个JMX文件都要包含登陆，重复度太高。
无法满足自动化平台诉求，短期内确实可以快速实现自动化，但是这些工具对于平台非自动化能力的拓展成本较高，毕竟改动开源工具的成本比自研高很多。
使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升，使用开源工具能提升工具学习使用能力，最终你的成长无外乎又掌握了一个测试工具的使用。
那么，如何摆脱JMeter式的传统思路，用更多的自动化代替手工？？
三、让自动化框架更自动化
接口自动化的核心是什么？接口、数据、断言。
正如上文说的，这也是我们手工重复度比较高的工作内容，也是痛点所在。
传统的自动化用例设计，往往需要人工采集接口信息（例如抓包，然后写脚本提取接口信息HTTP Type、Method、Request等），人工造入参数据等，这些重复度是极高的。更进一步来说，人工造入参数据更是痛中之痛，毕竟不同的业务需要构造的request内容是不同的。
那么如何自动化实现呢？
不妨大家先考虑我们是在哪里获取的这些信息。例如接口信息，你是否有过通过开发者工具提取接口信息？是否有过解析Charles工具har文件提取接口信息？以及解析swagger等接口文档工具。。。。然后通过提取的接口信息生成自动化框架所需的接口请求service。
但是，接口信息就在那里，为什么还要将其从一种载体中提取出来再转化为另一种类型的接口信息。难道直接使用类似har文件、swagger的接口信息就不行吗？当然是可以的。例如美团的Lego测试平台。
可以直接解析其他接口测试工具文件里的接口信息，以下拉列表的方式供测试使用者选择要写用例的接口，当然该接口request、Method等信息要同步填充到对应的输入框。这样就省去手工输入接口信息的时间。
刚刚说了，构造入参数据是痛中之痛？这部分如何自动化？
我的答案，入参数据从线上服务器日志里去取。试问，我们构造的数据难道有线上业务真实跑出来的数据更贴合我们要测试的业务吗？当然没有。
so，线上服务器的日志格式务必要规范化，这样可以方便我们提取xx接口的请求数据。有条件的公司可能会有自己的分布式链路追踪，这样可以基于trace提取出某个接口的请求和响应的所有信息。
断言怎么自动化？
其实这个的解法和第2个问题一样，我们在从日志中提取接口信息的同时，肯定也是有xx request参数下的xx response相应信息，我们可以将此次的响应信息作为基准，下次相同的request再次请求的时候，得到的响应和基准响应做比较就行了。当然，这个其实也是流量回放的思路。
四、总结
本文是我对此前设计的一个测试框架的反思，当时设计框架的“上下文”（即团队基建能力、以及自身的设计水平和负责的项目的业务架构等背景）和现如今所在的公司质量基建是有很大差别的（有时候很多想法的实现是需要一定基建能力支撑的）。在一定程度上，也算是站的更高，看的更远吧。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
