从一次线上故障聊聊接口自动化测试
共 1961字,需浏览 4分钟
·
2021-05-10 22:22
关注上方“测试开发技术”,选择星标,
干货技术,第一时间送达!
01 背景
从平台整体利益触发,我们各方制定了对应的后续处理方案。
运营端:加强后台操作的规范监督,运营人员操作添加宣传链接后,需二次确认对应位置的内容显示正常。
研发端:对添加进去的链接进行访问检查,保证其可用性。
测试端:采用自动化手段,持续检测核心页面的访问可用性和功能。
关于测试端的自动化检测,我们采用的是UI自动化+接口自动化并行的方式。而且相较UI来说,接口可以更高效灵活的实现持续检测。
02 什么是接口自动化
所有可以替代人工行为,产生数据交互的行为,都叫自动化。
直观来看,大家很容易理解端到端的UI自动化,它模拟的是用户可视化的页面操作行为。
而接口自动化则是对这些UI操作行为触发的数据传输行为,更为直接的模拟发送。
行业内按照层级分类的方式对测试进行分类,分为单元、接口和UI三个层级,而各层的产出/投入比可以形象的表述为测试金字塔,越往上层,其维护成本越高收益越小。
单元测试:关注代码的实现逻辑,比如一个if分支或者一个for循环的实现; 接口测试:关注的代码所提供的接口是否可靠; UI测试:关注的是系统集成后的界面显示层测试;
单元测试自不必说,需要我们深入了解代码实现,具备熟练的开发能力。因此考虑到产出和投入成本,接口测试才是整个自动化层级中,测试人员最应该优先推动实践的测试类型,再由此不断深入到单元测试,实现 DevOps。
03 接口自动化框架浅析
脚本型
可以根据自身需求,结合数据驱动、关键词驱动进行深度的自定义。适合不是接口不大,无需多人协同的非常规型接口测试。
常见的框架如下:
Python+Requests+unittest+HTMLTestRunner
Maven+testng+httpclient+jenkins+allure
工具型
Jmeter
Postman
sopui
loadrunner
metersphere
interface auto test
RobotFramework + HttpLibrary
…
所有的工具型软件,最终的执行部分都是通过对应语言的网络请求库、或者其它基础请求工具,去模拟发请求,只不过是前端的数据组织形式存在差别。
其中,除了metersphere、interface auto test这样平台化的工具,其它工具对于团队协作和持续测试的支持力度很低,需要结合jenkins等CI工具进一步定制。
04 接口自动化的价值
执行效率高
单个接口或者基于接口编排的场景执行,不人为限速的话,执行速度可以以毫秒为计。且执行过程无需渲染页面,不依赖执行设备的性能,可更快的反馈测试结果。
实现难度低
通过模板化数据流量或者基于标准的swagger接口文档,可快捷生成基础用例,维护人员只需关注与业务测试点关联的请求参数设计。
执行稳定可靠
得益于大部分应用系统都会保持接口向前兼容的特性,实践过程中也不难发现,接口测试的稳定性是有保障的。
发现问题有效性高
经过合理调教的接口测试系统,结合良好的用例设计规范,加上天然自带的精确的时间点、请求参数和返回值,能够做到精准定位问题场景和原因,再也不用听上游说“你复现下试试”。
05 实践中的计划
面向存量系统接口进行测试
这是我们正在做的,基于流量录制系统和现有的接口文档,对现有接口进行测试用例设计、实现和持续执行。实现多机房点的每日巡检,以及上线前的beta版本的全量接口测试,并反馈回归结果。
新接口的测试前置
当前开发中的版本接口,结合开发文档和测试环境,进行前置的接口用例设计、调试。通过接口自动化测试反向驱动开发业务开发过程中的质量保障,推动开发自测,实现集成测试前的“测试驱动开发”。
接口用例设计扩展
结合接口参数的可遍历性,可以设计开发能自动生成批量接口测试的用例。拆分用户的实际使用场景,重新组合接口编排,发掘出更大量的场景接口测试用例。
转载自:https://www.jianshu.com/p/9d6848e20dea
推荐阅读:
END
长按二维码/微信扫码 添加作者