接口测试用例设计

接口测试

接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

接口测试的意义

按照分层测试模型，处于中间层的接口测试，在稳定性，效率，成本，技术，实施难度上综合来讲，是收益最大的。相较于传统的UI层次的测试，接口测试把测试提前了（时间上，架构上），并且能够覆盖到一些UI测试无法触及的功能点，提高了测试的覆盖率，对质量控制提升了信心。接口测试也更容易实现自动化持续集成，支持后端快速发版需求，利于CT（持续测试）的开展。

 

（分层测试模型 - 图片摘自 51testing 网站）

接口用例设计方法

接口测试用例设计的重点，在于功能性的业务逻辑检查和参数检查。

1.功能：检查接口基础功能，是否完成了业务逻辑要求。此处的用例设计方法，和普通的测试用例设计方法一样。可以把接口当作一个待测模块，分析接口功能需求，利用常规用例方法设计测试用例。可供参考的用例设计方法如下：

1.等价类划分法
2.边界值分析法
3.错误推测法
4.因果图法
5.判定表驱动法
6.正交试验法
7.功能图法
8.场景图法

2.数据：分析接口的输入参数，覆盖各种可能的场景。

（1）检查接口的输入，数据格式、数据类型、数据范围等

（2）检查接口的参数边界（传递的参数足够大或者为负、空值时）

（3）检查接口的参数的组合，可选、必选等

（4）检查接口的约束条件，不符合约束条件的，不需要设计用例

3.性能：接口是否造成性能瓶颈，能承受的压力范围

4. 安全：接口是否涉及安全性

 

接口用例设计举例

下面以一个web接口作为案例，接口说明文档如下：

接口名称：获取用户订单
请求URL：{$url}/getUserOrder
请求方式：POST
返回举例：
略

 

请求参数：

名称	必填	类型	说明
uid	Y	String	用户id
orderNum	N	Int	订单数量

根据（1）业务流程（2）输入参数（3）输出返回（4）性能（5）安全 5块内容对接口进行用例设计。用例参考如下：

业务流程用例
	获取用户订单成功
	用户订单不存在
	用户不存在
	获取用户订单异常
输入参数用例
	uid不为空，orderNum不为空
	uid为空，orderNum为空
	uid为空，orderNum不为空
	uid不为空，orderNum为空
	uid正确，orderNum不为空
	uid正确，orderNum为空
	uid错误，orderNum不为空
	uid错误，orderNum为空
	orderNum=-1
	orderNum=0
	orderNum=1
	orderNum=5
	orderNum=100000
	orderNum
	uid数据格式错误
	orderNum数据格式错误
输出结果用例
	返回空值
	返回有效订单
	返回错误信息
	返回超时信息
性能用例
	…
安全用例
	…

 

用例筛选：

此接口，接近30个用例，已经比较全面了，但实际上有点冗余。比如，如果调用接口的界面是个用户选择界面，那么参数上，会受到约束，uid/orderNum都从前端传入，是一些固定的值，那么就不会产生一些特殊情况。类似以下情况，就不会在实际中遇到，因此这些用例的价值趋于0，完全可以在用例文档中去除。

uid为空，orderNum为空

uid为空，orderNum为空

orderNum=-1

orderNum=0

orderNum=100000

orderNum数据格式错误

uid数据格式错误

uid错误，orderNum不为空

uid错误，orderNum为空

设计的用例在考虑全面之后，需要再做一次减法，保证用例的实效性。对无法出现的场景设计出来的用例，毫无价值，只会增加我们的工作量，对产品质量提升没有帮助。因此，测试用例并不是越多越好，在于该用例是否能真正预防bug。

接口测试质量评估

接口测试用例在执行了一段时间后，需要对用例进行质量评估，即是对用例进行维护和优化。评估的内容可以参考如下几条：

（1）业务功能需求覆盖率；

（2）异常场景覆盖是否完整；

（3）代码覆盖率；

（4）用例的有效性，检查出bug的概率；

（5）用例的错误率，bug误报指数；

（6）测试数据维护成本，mock数据的准确性；

通过评估，可以得到接口测试的一些结果数据，对下一阶段接口测试的进行有参考意义，也有助于不断提高测试的质量和效益。

 

 

胡乱写了一些，有不足之处，请指正。