背景
当前市面上存在的接口测试工具已经非常多，常见的如Postman、JMeter、RobotFramework等，相信大多数测试人员都有使用过，至少从接触到的大多数简历的描述上看是这样的。除了这些成熟的工具，也有很多有一定技术能力的测试（开发）人员自行开发了一些接口测试框架，质量也是参差不齐。
但是，当我打算在项目组中推行接口自动化测试时，搜罗了一圈，也没有找到一款特别满意的工具或框架，总是与理想中的构想存在一定的差距。
那么理想中的接口自动化测试框架应该是怎样的呢？
测试工具（框架）脱离业务使用场景都是耍流氓！所以我们不妨先来看下日常工作中的一些常见场景。
测试或开发人员在定位问题的时候，想要调用某个接口查看其是否响应正常； 测试人员在手工测试某个功能点的时候，需要一个订单号，而这个订单号可以通过顺序调用多个接口实现下单流程； 测试人员在开始版本功能测试之前，可以先检测下系统的所有接口是否工作正常，确保接口正常后再开始手工测试； 开发人员在提交代码前需要检测下新代码是否对系统的已有接口产生影响； 项目组需要每天定时检测下测试环境所有接口的工作情况，确保当天的提交代码没有对主干分支的代码造成破坏； 项目组需要定时（30 分钟）检测下生产环境所有接口的工作情况，以便及时发现生产环境服务不可用的情况； 项目组需要不定期对核心业务场景进行性能测试，期望能减少人力投入，直接复用接口测试中的工作成果。
可以看到，以上罗列的场景大家应该都很熟悉，这都是我们在日常工作中经常需要去做的事情。但是在没有一款合适工具的情况下，效率往往十分低下，或者就是某些重要工作压根就没有开展，例如接口回归测试、线上接口监控等。
四种接口测试工具做个简单对比，详细内容见下图:
痛点
提到接口自动化测试,回忆一下是否有如下场景:
场景1:
如果负责一个新业务接口测试,测试基础建设为零、测试人员能力参差不齐。此时你需要在一段时间内保障需求正常上线,对于接口测试这块,此时急需一个接口自动化测试工具能解燃眉之急,让不会代码的同学也能快速做接口自动化测试。
场景2:
公司内接口测试框架,百花齐放、功能大同小异,基本思路都用通过java或者python语言写的自动化框架。自动化框架维护成本高、接口测试自动化框架和其他内部平台相互独立。此时急需要,统一接口自动化测试工具、让接口测试成体系化,各个平台互相打通。
上面两个问题,可以概括为:
1、同质化验证,缺乏工具统一。
2、接口测试不仅是工具,而是整体套解决方案。
3、降低用户的使用门槛,让所有人都能迅速掌握。
你有没有想过拥有一个,能满足你所有的愿望。
- 与 API 文档关联与自动同步
- 0代码，拖拉拽完成测试流程编排
- 定时自动测试
- 测试报告自动推送
初探
我们使用一个真实的商城后端服务,来验证如何让接口自动化测试,简单、高效起来。
场景梳理
首先我们需要对测试的场景进行抽离,明确场景的接口、参数等。
根据测试需求梳理出需要测试的接口,需要测试一个功能模块,接口会提供新增、查询、修改、删除等接口。
测试用例
一般接口测试有两种测试方法,单接口测试和场景化测试。
- 单接口:验证某个单独的接口是否正常,如果接口参数有上下文关联,单接口测试是有局限性的。
- 场景化:基于用户真实场景,比如创建广告 => 再查询 => 再删除,这要点好处是接口之前的参数是有关联的。通过一个场景,串联多个接口,验证整条链路上的功能是否正常。
前置依赖:需要登录后,把token放到全局环境变量中,其他接口在请求头中引入token参数,否则会报token失效。
测试步骤
测试步骤的的核心是把单接口串联起来,涉及前后参数传递。如果链路中所有接口都测试通过,整个测试链路才证明测试成功。
点击"添加测试步骤",选择"从API文档添加到API请求",从接口测试用例库导入已有的接口用例。
根据场景化需要,点击"导入API用例",如果出现API用例是灰度并且不能点击,需要在单接口处创建接口用例,否则不能导入。上面内容有问题，不一定要导入用例，直接勾选 api 也可以导入 api。
导入接口后,可以根据业务逻辑上下移动接口顺序。
为了解决业务接口有"鉴权的"限制,可以在自动化测试环境里的配置全局前置脚本，或者直接把登录接口加到用例前面，然后使用绑定参数的功能。
在测试界面的各个输入框中，如URL、请求参数名、参数值等，使用 {{全局变量名}} 即可引用相应的全局变量值。
如下图使用 {{token}} 即可引用全局变量 token 的值。
动态参数
因为服务端对创建商品的商品名字字段有唯一性要求。所以需要每次执行创建商品接口,请求参数中的的商品名字、商品描述等字段需要不重复。
保证字段不重复,可以使用"自定义函数",可以理解为根据业务需求编写一个函数,"自定义函数"的编写基于js语法来编写。
下面这段代码的意思是,根据时间戳创建一个商品名字的字符串,这样就可以保障每次创建的商品名字都不重复,如果测试用例出现问题,还可以根据时间戳回溯测试用例详情。
代码语言：javascript复制function get_shop_name(){
var timestamp = Date.parse(new Date());
var shopName = "测试商品名字字段" timestamp; // 根据时间戳动态创建商品名称
eo.info(shopName);
return shopName
}
函数调试完成后, 使用"get_shop_name"调用函数即可。
在接口编辑页面中,"前置脚本中",调用"get_shop_name"函数。
代码语言：javascript复制var shop_name = eo.userFunction.get_shop_name() /*动态创建商品名称*/
eo.info(shop_name);
eo.globals.set("shop_name",shop_name) // 设置全量变量
在请求体中,使用{{shop_name}}引用变量。可以在"测试报告"的请求体看到引用函数成功的输出预期字符串。
执行测试
当所有接口都调试完成后,需要验证该场景是否测试通过。点击测试方案,选择"订单接口自动化测试"方案并且执行"测试"操作。
可以看到会串行执行接口,如果出现如下图,说明该场景化接口测试用例测试通过。
总结
在接口自动化测试工具,无论自研框架还是工具,都是百花齐放,没有系统化、轻量化、低成本,解决测试人员对接口自动化测试本身的测试诉求,不应该让接口自动化测试,止步于工具,而是应该应该更好的利用工具保障业务需求的质量。
