如何让自动化测试框架更自动化？

news2024/11/24 0:02:46

一、引言

对于大厂的同学来说，接口自动化是个老生常谈的话题了，毕竟每年的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测试平台。