接口测试的测试用例应该怎么写？
🍅 点击文末小卡片 ，免费获取软件测试全套资料，资料在手，涨薪更快
一、用例设计1
1、接口测试概念
接口测试：测试系统间接口的一种测试，测试的对象主要是接口，主要是测试外部系统与所测系统之间以及内部系统之间的交互点
2、接口测试方法
a、可以通过开发脚本代码进行测试
b、可以通过开源免费的接口调用调试工具测试，如：Postman等。
c、可以通过App手动测试，结合抓包工具分析，如：Fillder/Charles等
3、接口测试范围
接口范围包括：
一、被测项目中同层之间的接口（如DAO层、Service层），一个接口调用了其他的接口。
二、外部系统与系统之间的交互点（如一个App调用了第三方支付宝的API）
三、各个子系统之间的交互点（如App客户端调用了服务端的Http接口）
被测接口范围：
通常接口会很多，接口测试范围的筛选，参考测试人力资源、项目特点、接口重要性与优先级来进行。其中第一种属内部接口，构造测试稍复杂需开发配合实施，通常优先覆盖第二、三种接口
接口测试的重点测试范围：
优先测试覆盖核心业务，复杂业务的接口
4、如何设计接口测试用例
接口测试出发点是被测接口逻辑存在错误，参考这个为出发点，更容易发现问题
设计接口测试用例，我们可简单的考虑两个基本要素，即：入参、出参，正确/错误的入参，逻辑判断后，接口是否做出正确的处理，返回正确的出参
接口测试用例有3类（逻辑测试，异常测试，路径测试）：
1）逻辑测试：主要是根据开发提供的接口文档来设计测试用例，接口文档包含的要素（前提条件，输入参数，参数类型，业务逻辑，返回输出描述等），此类主要测试在正常输入的情况下，是否能得出正确的输出结果。主要使用的用例设计方法是等价类划分，边界值等
2）异常测试：接口逻辑的测试中主要测试接口正常逻辑，即对外提供的接口服务是基本可用的，但仅逻辑测试不能保证数据的安全及程序接口在异常情况下的逻辑处理的正确性
(a) 空值,null;
(b) 参数属性(如：未赋值的参数)
(c) 异常业务参数(如：构造不满足业务异常业务参数)
(d) 参数个数、参数类型错误(如：接口文档中定义必填参数2个int,输入参数仅1个,类型非int)
3）路径测试：当被测接口的实现方法中，判断逻辑复杂分支多，且判断中又调用了其他的接口，此时必须要进行路径覆盖测试
5、接口测试关注点
6、接口自动化测试工具
1）Java(HttpClient) + Junit/TestNG;
2）Jmeter
3）SoapUI
4）Python requests/urllib 库;
......
二、用例设计2
1、优先级--针对所有接口
1.暴露在外面的接口，因为通常该接口会给第三方调用
2.供系统内部调用的核心功能接口
3.供系统内部调用非核心功能接口
2、优先级--针对单个接口
1.正向用例优先测试,逆向用例次之(通常情况，非绝对)
2.是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制
3、设计分析
通常，设计接口测试用例需要考虑以下几个方面：
1.是否满足前提条件
有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token；
逆向用例：针对是否满足前置条件(假设为n个条件)，设计0~n条用例
2.是否携带默认值参数
正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例
3.业务规则、功能需求
这里根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例
4.参数是否必填
逆向用例：针对每个必填参数，都设计1条参数值为空的逆向用例
5.参数之间是否存在关联
有些参数彼此之间存在相互制约的关系；
逆向用例：根据实际情况，可能需要设计0~n条用例
6.参数数据类型限制
逆向用例：针对每个参数都设计1条参数值类型不符的逆向用例
7.参数数据类型自身的数据范围值限制
正向用例：针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
逆向用例：针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例；针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。
