接口测试的套路，没那么深

Posted 2021-04-24 京东成都研究院

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了接口测试的套路，没那么深相关的知识，希望对你有一定的参考价值。

杰夫(JSF:JD Service Framework)接口在京东无处不在，可以说有系统必然有杰夫接口。京东系统成千上万,接口琳琅满目,方法入参结构更是变化多样,然而：

a. 你是通过阅读SDK代码来了解接口入参结构吗？

b. 你是通过SDK调用方式来开展接口自动化测试吗？

c. 你是一个场景一个场景来设计测试用例吗？

d. 你是一个测试脚本一个测试脚本编写自动化测试脚本吗？

如果是，那测试手段太low了。这次分享从以下5方面为你介绍更高效、更便捷的方式，让你以更优雅的方式开展杰夫接口功能测试：

1) 解析杰夫接口入参结构;

2) 数据类型VS测试场景库;

3) 二种自动生成测试用例的方式;

4) 接口通用(统一)自动化测试框架;

5) 杰夫接口端到端的测试解决方案。

首先，我们先举几个身边的接口例子，通俗易懂的认识一下什么是接口，接口是如何工作的：

【从广义上来讲】接口是二个相对独立的部件进行信息交换的介质/方式。例如：

1.电脑和移动设备(手机、平板)通过USB (接)口拷贝文件；

2.水桶插到饮水机上方的凹槽(接口)，可以将桶里的水通过出水口放出来；

3.通过有线或蓝牙耳机听音乐；

【从狭义上来讲】接口是二个子模块或子系统间负责交换或传输(单向:进、出)数据的部分，无官方定义的分为4类：

1.函数级别,类提供的方法，是常见的最小粒度接口

2.模块级别

3.服务级别

4.网络级别

结合上面的介绍和举例，很容易理解接口工作流图(如图所示)。给定一个接口，我们该如何着手开展测试呢？

首先，”输入”是接口测试的入口、切入点。输入不同信息，”接口处理逻辑”中代码执行的路径可能不同(同一等价类的数据，执行代码路径一样)。输入的信息必须按要求的结构来组织，结构必须完整、准确无误；

其次，结合业务知识和测试理论 (等价类划分、边界值分析、特殊值等)，进行用例设计、评审并确定用例优先级；

再次，根据测试用例的测试场景要求，构造合适的测试数据，通过编写代码或者工具将测试数据”输入”给”接口处理逻辑”，即调用接口；

最后，对接口的返回值以及持久层(数据库、redis缓存等)情况等进行校验，评估是否符合”接口处理逻辑”的预期结果；

解析杰夫接口入参结构

要掌握如何测试一个接口方法，首当其冲是梳理方法的所有入参，并保证其结构正确与完整，否则方法调用时会出错，不会返回执行结果。二种分析方式：

1.人工分析法，阅读SDK接口定义的代码，逐层梳理。遇到：

a)Set、List类型，使用[ ]括起来；

b)Map类型，格式为 key:value；

c)字符串类型，使用双引号 “”括起来；

d)自定义对象，使用{ }括起来，并重复上面的情况

e)……

缺点：技能依赖、效率低、易出错等

2.工具分析法: 通过自研工具逐层解析每个参数，直到解析为原生数据类型，并给字段(属性)赋予默认值。如下：

从图中可以看出，只要选择接口名称、方法名称，就可以快速生成该方法的入参结构。经过格式化后，不仅输出了方法的完整入参结构，还给每个成员(参数、对象属性)赋了默认值。使用人员只需修改并确认参数值无误后，即可点击”执行”按钮调用接口方法，执行结果会直接呈现在当前界面。

由此可见，通过工具自动解析入参结构的方法，大大提高了测试人员、开发人员调用接口的效率，杜绝了人为犯错的可能，尤其是当需求联调要临时调用接口方法的时候。

数据类型VS测试场景库

设计接口测试用例时，必须考虑接口入参中每个字段(属性)可能变化情况(变化因子)和对应的值。变化因子考虑是否齐全直接决定测试覆盖程度，这个不仅依赖业务知识，对测试理论和编程基础知识也需要有深入的了解，下面的"数据类型VS测试场景库"是在日常测试过程中总结出来的，遇到某种数据类型，对应的场景应该都需要考虑。

二种自动生成测试用例的方式

对于接口测试，可以简单理解：

a)入参赋予不同的值——不同的测试用例

b)不同的测试用例——不同的业务场景

可以设想一下，我们是否可以给入参结构的每个字段赋予不同的值，然后自动批量生成测试用例呢？

当然可以。我们可以结合业务知识+"数据类型VS测试场景库"，在入参结构基础上，给每个变量赋予多个不同的值，然后通过一定的算法批量自动生成不同的参数组合，每种组合是一个测试用例。支持二种方式：

笛卡尔积法：每个变量的每个值都必须与其他变量的所有值进行组合，产生的测试用例个数为：所有变量可选值个数的乘积。如果被测接口有10个入参且每个入参都有10个值，所有组合情况将导致存在10的10次方=10 000 000 000个测试用例。这个数字太庞大，假设自动化用例执行速度是10000条/秒，大约需要11.5天才能执行完。所以如果变量或者变量候选值较多时，不推荐使用。

全对偶组合测试法：全对偶(两因素)组合测试生成一组测试用例集，可以覆盖任意两个因素的所有取值组合，在理论上可以暴露所有由两个因素共同作用而产生的缺陷。业界支持这种算法的工具有Pairwise、PICT等。缺点：过滤掉了大部分测试用例，存在漏测风险，但是测试本身就是一种自带风险的测试保障工作，所以测试工作是允许风险存在的，我们需要做的是通过业务知识、测试设计理论以及其他质量保障活动来减低风险发生的概率以及发生后的影响。