常德城乡和住房建设局网站,做运营那些无版权图片网站,建设企业网站企业网上银行登录官网,注册新公司网上怎么核名一、引言 对于大厂的同学来说#xff0c;接口自动化是个老生常谈的话题了#xff0c;毕竟每年的MTSC大会议题都已经能佐证了#xff0c;不是大数据测试#xff0c;就是AI测试等等#xff08;越来越高大上了#xff09;。不可否认这些专项的方向是质量智能化发展的方向接口自动化是个老生常谈的话题了毕竟每年的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再次请求的时候得到的响应和基准响应做比较就行了。当然这个其实也是流量回放的思路。
四、总结 本文是我对此前设计的一个测试框架的反思当时设计框架的“上下文”即团队基建能力、以及自身的设计水平和负责的项目的业务架构等背景和现如今所在的公司质量基建是有很大差别的有时候很多想法的实现是需要一定基建能力支撑的。在一定程度上也算是站的更高看的更远吧。 最后:【可能给你带来帮助的教程】 如果这篇文章对你有帮助请给小编点个赞这样我才有动力继续更新下去
今天的小知识学会了么
欢迎在留言区跟我们互动噢~
觉得有所帮助的话点个赞呗
最后是小编自己整理的一些学习资料、测试工具、课件、笔记相关资料点击下方小卡片
