看完秒懂原来接口测试用例设计这么简单

什么是接口

接口：服务端程序对外提供的一种统一的访问方式，通常采用 HTTP协议，通过 不同的url，不同的请求类型（GET、POST）， 不同的参数，来执行不同的业务逻辑。

客户端大多数的业务操作，都是需要 调用 服务端接口来获取一些数据， 或者触发某些业务，然后客户端拿到接口返回的数据后，会根据数据内容做不同的处理和展示。

为什么要做接口测试

A、在公司里，客户端和服务端通常是由不同的团队开发的，在项目开发过程中，客户端和服务端开发的进度不一致，比如服务端先开发完了，这个时候可以先对服务端进行接口测试，确保服务端逻辑和返 回数据是正确的，然后再测试客户端。或者是某些测试部门，专门测试服务端开发团队，因此，他们的 测试对象就是接口。

B、在测试某些业务时，不能仅仅通过前端来测试，比如用户注册，前端限制了用户名不能为空，但是有些人可能通过工具绕过前端直接调用服务端接口，如果服务端没有做相关的逻辑判断，就会造成数据 错误。包括接口数据传输过程中是否对关键信息加密等。所以必须 针对服务端接口单独做测试。

C、在开发提测后，可以先通过工具把服务端的接口测试跑一遍，确保接口测试用例都是通过的，快速判断服务端接口是否符合预期。然后 再通过UI界面进行测试。否则接口有bug，前端页面必定有bug。

接口测试的意义

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

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

接口用例设计方法

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

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

1 2 3 4 5 6 7 8

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

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

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

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

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

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

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

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

接口用例设计举例

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

1 2 3 4 5

接口名称：获取用户订单 请求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数据的准确性；

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

---

学习资源分享

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….