从一次线上故障聊聊接口自动化测试-技术圈

关注上方“测试开发技术”，选择星标，

干货技术，第一时间送达！

3月初平台活动期间，运营同事配置了个还未上线的页面到网站首页 banner，导致用户点了报错。尽管这次很明确是运营人为操作失误引起的故障，但过往此类核心页面的访问异常，我们已不是第一次遇见。

从平台整体利益触发，我们各方制定了对应的后续处理方案。

关于测试端的自动化检测，我们采用的是UI自动化+接口自动化并行的方式。而且相较UI来说，接口可以更高效灵活的实现持续检测。

所有可以替代人工行为，产生数据交互的行为，都叫自动化。

直观来看，大家很容易理解端到端的UI自动化，它模拟的是用户可视化的页面操作行为。

而接口自动化则是对这些UI操作行为触发的数据传输行为，更为直接的模拟发送。

行业内按照层级分类的方式对测试进行分类，分为单元、接口和UI三个层级，而各层的产出/投入比可以形象的表述为测试金字塔，越往上层，其维护成本越高收益越小。

单元测试自不必说，需要我们深入了解代码实现，具备熟练的开发能力。因此考虑到产出和投入成本，接口测试才是整个自动化层级中，测试人员最应该优先推动实践的测试类型，再由此不断深入到单元测试，实现 DevOps。

可以根据自身需求，结合数据驱动、关键词驱动进行深度的自定义。适合不是接口不大，无需多人协同的非常规型接口测试。

常见的框架如下：

所有的工具型软件，最终的执行部分都是通过对应语言的网络请求库、或者其它基础请求工具，去模拟发请求，只不过是前端的数据组织形式存在差别。

其中，除了metersphere、interface auto test这样平台化的工具，其它工具对于团队协作和持续测试的支持力度很低，需要结合jenkins等CI工具进一步定制。

单个接口或者基于接口编排的场景执行，不人为限速的话，执行速度可以以毫秒为计。且执行过程无需渲染页面，不依赖执行设备的性能，可更快的反馈测试结果。

通过模板化数据流量或者基于标准的swagger接口文档，可快捷生成基础用例，维护人员只需关注与业务测试点关联的请求参数设计。

得益于大部分应用系统都会保持接口向前兼容的特性，实践过程中也不难发现，接口测试的稳定性是有保障的。

经过合理调教的接口测试系统，结合良好的用例设计规范，加上天然自带的精确的时间点、请求参数和返回值，能够做到精准定位问题场景和原因，再也不用听上游说“你复现下试试”。

这是我们正在做的，基于流量录制系统和现有的接口文档，对现有接口进行测试用例设计、实现和持续执行。实现多机房点的每日巡检，以及上线前的beta版本的全量接口测试，并反馈回归结果。

当前开发中的版本接口，结合开发文档和测试环境，进行前置的接口用例设计、调试。通过接口自动化测试反向驱动开发业务开发过程中的质量保障，推动开发自测，实现集成测试前的“测试驱动开发”。

结合接口参数的可遍历性，可以设计开发能自动生成批量接口测试的用例。拆分用户的实际使用场景，重新组合接口编排，发掘出更大量的场景接口测试用例。

转载自：https://www.jianshu.com/p/9d6848e20dea