接口测试用例设计
随着测试分析和分层测试的深化，“接口测试”出现在我们视野的频次越来越高。那么接口测的用例设计常用哪些方法呢？本文将详细描述。
1接口测试
1.1接口测试
接口：主要是子模块或者子系统间交互并相互作用的部分。
这里说的接口是广义的，客户端与后台服务间的协议；插件间通信的接口；模块间的接口；再小到一个类提供的方法；都可以理解为接口。
接口测试：是指针对模块或系统间接口进行的测试。
1.2接口测试发现的典型问题
接口测试经常遇到的bug和问题，如下：
（1）传入参数处理不当，导致程序crash；
（2）类型溢出，导致数据读出和写入不一致；
（3）因对象权限未进行校验，可以访问其他用户敏感信息；
（4）状态处理不当，导致逻辑出现错乱；
（5）逻辑校验不完善，可利用漏洞获取非正当利益等。
2接口测试用例设计
上图为一个典型的接口。一个接口通常是有输入输出的，输入就是我们常见的入参，输出有时有，有时没有。调用相关接口，接口会执行相关处理逻辑。
接口测试的用例设计，主要从输入和接口处理两方面考虑：
（1）针对输入，可按照参数类型进行设计；
（2）针对接口处理，可按照逻辑进行用例设计；
（3）针对输出，可根据结果进行分析设计。
2.1针对输入设计
对于接口来说，输入就是入参。常见参数类型有:
（1）数值型(int,long,float,double等）
（2）字符串类型
（3）数组或链表
（4）结构体
结构体(struct)是一些元素的结合，元素实际也是数值型，字符串型，数组或链表。
下面详细说明数值型、字符串型、数组或链表三种参数类型用例设计。
2.1.1数值型
数值型的参数主要考虑以下几个方面设计：
如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。
例如检查权限的接口：TaskChecker.checkTask(inttaskID)taskID的取值范围是1-35，那么设计时考虑：
1-35范围内和范围外的值；
1-35的边界：0，1,35,36；
类型的特殊值：-1,0
数据类型的边界值：int的最小值最大值；
因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。
常见问题和风险：
特殊值处理不当导致程序异常退出；
类型边界溢出
取值范围外值未返回正确的错误信息等
2.1.2字符串型
字符串型的参数，主要考虑字符串的长度和内容：
例如接口转换设置闹钟的接口DateUtil.getDayOfDDHH(Stringddhh)，用例可以考虑：
长度为4位，比4位少，比4位多；
边界值：String的最大长度；
特殊值：空字符；
字符串内容可考虑类型：数字，非数字；
特殊字符。
如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。
可能出现的问题和风险：
传入非特定类型程序异常退出
超长字符未进行处理，导致存储、显示等异常
其他用户可见设置的敏感字
2.1.3数组或链表类型
参数类型为数组或链表时，用例可以考虑：
例如批量提交任务的接口submitTask(int[]taskID)，参数用例设计考虑：
正常取值：1-5个权限，范围外：6个权限；边界值：1-35的边界值，请求允许最大最小值；特殊值：0个；合法ID和不合法的；重复的ID等。可能存在的问题和风险：
0个item时程序异常退出；重复的item处理时未去重导致结果异常等。2.2针对逻辑设计
接口需要进行一些逻辑处理的，那么按逻辑设计用例可以从以下几个角度分析。
2.2.1约束条件分析
（1）数值限制：分数限制、金币限制、等级限制等等。
例如：兑换Q币活动要求积分>50才可参与。
（2）状态限制：登录状态等。
例如：同步用户信息需要先登录账号。
（3）关系限制：绑定的关系，好友关系等。
例如：帮家人防骗功能只能查询绑定家人的来电信息。
（4）权限限制：管理员等。
约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。它的意义在于：用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。但是实际上，如果有其他手段：例如UI有bug或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。
例如常见的例子：要兑换5Q币需要200积分，但是我积分不足，所以兑换按钮是灰色无法点击的状态：
正常用户是无法操作的，但是兑换其实是调后台的一个接口，如果绕过页面按钮的限制，直接调用后台接口兑换呢？是否可以兑换？预期当然是不能兑换的。因此积分这个数值限制就需要针对接口进行测试，并且非常重要。
其他约束条件类似：
时间约束：22：00之前；数值约束：积分200；限量5个；状态约束：登录手机管家；等等约束条件类似。常见的问题和风险：
约束条件判断不足，导致用户可通过特殊手段获取利益
2.2.2操作对象分析
操作通常是针对对象的，例如用户绑定电话号码，电话号码就是操作对象，而这个电话号码的话费、流量也是对象。
对象分析主要是针对合法和不合法对象进行操作。例如下述用例子:
用户A查询电话P1话费：用户A查询电话P1流量；用户A查询电话P2话费；用户A查询电话P2流量。后台的逻辑处理，如果一个电话已经被绑定过，从后台的角度是可以查询到该电话的话费和流量的。但是在用户侧，应该是A绑定了的电话，才能让A查询到该电话的话费。故类似对象的测试也必不可少。
常见的问题和风险：
用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益。
2.2.3状态转换分析
被测逻辑可以抽象成状态机，各个状态之间根据功能逻辑从一个状态切换到另一个状态。如果我们打乱了这个次序，从一个状态切换到另一个不在它下一状态集中的状态，那么逻辑将会打乱，就会出现逻辑问题。
如上图所示，从某状态改变到新的状态，依赖于转换接口。而对于某转换接口，其输入状态是确定的，比如Fun23,这个函数只能把状态2转换为状态3，而不能把状态1转换为状态3。那么测试点就可以是：
（1）状态为状态2，调用接口Fun23（），状态切换到状态23；
（2）状态为1,3等，调用接口Fun23（），状态不能切换。
例如在做任务的时候，任务有三种状态：未领取，已领取未提交，已完成三种状态。
那么可以这样设计：
（1）正常的状态切换：未领取状态，领取任务后变为已领取状态；已领取满足任务条件提交后，变成已完成状态；完成后可以再次领取任务。
（2）非正常的状态切换：未领取任务满足任务条件直接提交任务；已领取时再次领取任务等等。
常见的问题和风险：
可通过特殊手段达到原本不能的状态，从而谋取利益。
2.2.4时序分析
在一些复杂的活动中，一个活动是由一系列动作按照指定顺序进行的，这些动作形成一个动作流，只有按照这个顺序依次执行，才能得到预期结果。
在正常的流程里，这些动作是根据程序调用依次进行的，并不会打乱，在接口测试时，需要考虑如果不安装时序执行，是否会出现问题。
例如，客户端数据同步是由客户端触发进行的，期间的同步用户无法干预。功能测试的时候可见的就是是否能正常进行同步，而进一步分析，同步流程实际涉及了一组动作：
从时序图可以看出，后台有3个接口：登陆获取用户ID，上报本地数据，上报本地冲突。三个接口需要依次调用执行，才能完成同步。那么在接口测试就可以考虑打乱上述接口的执行顺序去执行，会有怎样的结果，是否会出现异常。例如：获取用户ID后不上报本地数据而直接上报本地冲突。
常见的问题和风险：
非顺序执行后，数据出现异常，可能还会出现程序其他异常
通过打乱顺序获取利益
2.3针对输出设计
针对输出设计其实是针对接口返回的结果进行分析。
2.3.1针对输出结果
接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。例如提交积分任务的时候我们通常能想到的是返回正确和错误，错误可能想到：无效任务，无效登录态，但是不一定能否完全覆盖所有错误码，而接口返回定义的返回码可以设计更多用例：
覆盖返回码也是用例设计的一种思路。
常见问题和风险：
（1）错误前端处理不足，导致前端异常；
（2）错误提示处理不当，导致用户看到晦涩的错误码；
（3）错误提示不当，导致用户不知道哪里出了问题，如何解决。
2.3.2接口超时
接口正常情况下是有返回的，那么如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。如果超时处理不当，可能会引起以下问题：
（1）未进行超时处理，导致整个流程阻塞
（2）超时后又收到接口返回，导致逻辑出现错乱
2.4其他测试设计
2.4.1已废弃接口测试
已废弃协议，是指之前有定义，但是因为需求变更或其他原因，目前版本不用。这些接口虽然不再使用，但有可能代码并没有及时删除。如果利用技术手段调用这些接口，可能获取额外利益。
例如，任务之前有个清理任务，在一个版本需求里将清理任务替换为下载任务。在新版本客户端已不再调用完成清理任务的接口；但是如果该接口未关闭，用户就可以继续请求submitTask(inttaskID)接口完成清理任务获得积分。
因此新版本在考虑兼容旧版本的同时，还应做好相关废弃接口的检查，避免用户获得额外利益。
2.4.2接口设计合理性分析
接口定义是否合理可以从以下几个方面分析：
（1）接口字段是否冗余；
（2）接口是否冗余；
（3）接口是否返回了调用方期望得到的信息；
（4）接口定义是否可满足所有调用需求；
（5）接口定义调用是否方便。
2.5一个完整的例子
下面举一个完整例子，通过上述方法来分析如何对接口进行用例设计。
某模块提供了一个接口给其他模块，用户请求任务，接口定义如下：
2.5.1针对输入设计
dialogDetailText（dialogButtonText类似）
长度
（1）正常：请安装提示进行操作；
（2）边界：一个字：请；长度非常长：无悬浮窗权限，可能影响XX功能无法使用，请开始悬浮窗权限，以便获得更好的用户体验；甚至更长；
（3）特殊：空字符串。
内容
（1）特定类型：中文，英文，数字等；
（2）特殊字符：/n/r/t,.>
接口测试用例设计
接口测试接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试的意义按照分层测试模型，处于中间层的接口测试，在稳定性，效率，成本，技术，实施难度上综合来讲，是收益最大的。相较于传统的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数据的准确性；
通过评估，可以得到接口测试的一些结果数据，对下一阶段接口测试的进行有参考意义，也有助于不断提高测试的质量和效益。
胡乱写了一些，有不足之处，请指正。
单接口测试用例设计方法
背景
最近项目中也一直在推动接口测试，中途也遇到很多的问题；从最开始的接口文档管理，接口测试框架的选型，到后续接口测试用例的维护问题。最近在想接口测试的一个覆盖度问题。谈到覆盖度，又得回到接口测试的用例设计上面；网络上又很多接口测试用例的设计资料，无非是罗列一些维度，e.g.参数组合，业务场景等，但都不够系统和结构化,没法快速做到用例有效却不冗余，尤其是在接口参数较多的情况下。
接口测试用例设计关注点
前提条件：比如一个发帖接口，前提是需要登陆参数是否必填参数间是否存在关联参数取值范围业务规则单接口用例设计方法
接口测试其实可以等同于功能测试，只是被测对象是接口，无界面交互而已；所以用例设计的方法是通用的。
等价类划分法边界值分析因果图判定法场景分析法具体示例
一个简单的登陆接口为例，文档如下：
首先对请求参数组合进行分析： phoneNumber参数可分为如下几种情况： 1.类型为String,且长度不超过11位 2.类型为String,且长度超过11位 3.类型不为String 4.不带参数
password参数可分为如下几种情况： 1.类型为String 2.类型不为String 3.不带参数
4*3组合总共会有12种情况，得到判定表如下：
根据等价类划分的原则，一个参数错误和两个参数错误是等价的，所以把两个参数错误的去掉，精简后的判定表如下：
综合判定表，我们进行用例转换得到如下用例： 1.phoneNumber和password参数正确，登陆成功 2.phoneNumber参数正确，password类型不为String,登陆失败 3.phoneNumber参数正确，password参数缺失,登陆失败 4.password参数正确，phoneNumber超过11位，登陆失败 5.password参数正确，phoneNumber不为String，登陆失败 6.password参数正确，phoneNumber参数缺失，登陆失败
参数组合的情况考虑完后，我们结合业务场景和接口返回码进行分析，比如，可得到如下几种情况： 1.用户名密码正确，返回登陆成功 2.用户未注册，返回登陆失败 3.密码错误，返回登陆失败
目前通过参数组合和场景分析的情况，可得到9条用例；由于参数组合第一条和场景分析第一条是同一个情况，去重后，我们得到实际有效的8条用例：
备注
在实际接口测试中，在传参方面有时候还需要考虑以下两种情况，e.g. 1.参数故意传入空字符串或null,可看是否有进行处理？ 2.参数故意传入超过取值类型的最大值，如int,传入2147483647+的情况，看是否有进行处理？
最后
通过结合以上的方法进行接口测试用例设计，即使参数组合再多，也能够条理很清晰地罗列出测试用例，而不缺乏覆盖度。
转载https://blog.csdn.net/swordgirl2011/article/details/78587674
如何设计接口测试用例（文末送接口测试用例模板）
接口测试是项目测试的一部分，正如其名，它测试的主要对象是接口，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。
如何设计接口测试用例？首先，明确出发点。和所有的测试一样，接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向，你的设计行为就会尽量朝这个方向发展，更易发现问题，不会出现大方向的偏差。
其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口，每个接口如果分别测试，那将是很痛苦的一件事情，不光繁琐浪费，而且任何一个内部接口的变动，都将导致我们用例的不可用。
这里推荐把整个系统作为一个整体，选择整个系统提供给外部使用、交互的最外层接口作为你的测试对象，以此为测试对象的用例将有很好的健壮性，并且更高效。
另外，根据数据的流向，又可将这些最外层的接口分为两类：一类是数据进入系统的接口；一类是数据流出系统的接口。
进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。
数据从哪里流出，流出时的状态如何，此时系统又是什么状态都是我们所应该验证的。
然后，确认完整的测试对象的功能：确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。
最后当出发点、对象、功能都确定了，就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。
接口测试用例设计和其他测试用例设计一样，都应该本着尽可能的发现bug的目标。用例设计的内容应该包括：主要测试功能点、测试环境、测试数据、执行操作以及预期结果。
1）接口测试环境分为两种:一种是程序内部的环境，一种是程序的所调用外部接口的环境。
用例在设计环境上有一个原则即：设计真实而危险的环境，不忽视偶发环境。
真实，即你的用例在测试某种功能时，应该去思考这种情况发生时内部、外部环境是什么，通过各种手段将最准确的环境模拟出来。
危险，即在这种环境下系统出问题的概率会很大。在设计用例环境时，如果两种环境都能达到你本用例的要求，更推荐选择更危险的环境。
所谓偶发，即这种环境出现的概率很小。不要因为这种环境很少出现就无视它，开发很可能也是这种想法，此处很有可能隐藏着问题。
2）接口测试测试数据分为接口参数数据和用例执行所需系统数据。
数据的设计学问大，不要在设计、准备测试用例的数据上偷懒。要通过好的测试数据使用例查错的功能充分发挥。
接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据，使用例更容易发现问题。
3）测试功能点，
如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。
同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。
4）接口测试用例执行操作非常简单，就是所测接口的调用。
5）预期结果验证，
这也是接口用例设计的很关键的一步，应该细而不冗余。所谓细，用例中应详细列出应该验证的点。
每个用例均需验证，不要因为前几个用例有验证就认为全部是正确的。避免一个用例中重复做相同的验证，提高测试用例的效率。
当今在测试领域，接⼝测试已经越来越多的被提及，被重视。
区别于传统意义上的系统级别测试，很多测试⼈员在接触到接⼝测试的时候，也许对测试执⾏还可以⽐较顺利的上⼿，但⼀提到相关的归档，⽐如测试⽤例和报告，就有些不知所措了。
今天就送你们一套实用的接口测试用例模板，