接口测试常见问题及用例设计
1 接口测试常见问题
链接：https://pan.baidu.com/s/1-XdsbGHdTWytuqhNvvc15A?pwd=8888
提取码：8888
（1）传入参数处理不当，导致程序crash；
（2）类型溢出，导致数据读出和写入不一致；
（3）因对象权限未进行校验，可以访问其他用户敏感信息；
（4）状态处理不当，导致逻辑出现错乱；
（5）逻辑校验不完善，可利用漏洞获取非正当利益等。
1、接口测试从状态级别做起，做到最基本的覆盖
1、1xx: 信息
100 Continue 服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。
101 Switching Protocols 服务器转换协议：服务器将遵从客户的请求转换到另外一种协议
2、2xx: 成功
200 OK 请求成功（其后是对GET和POST请求的应答文档。）
201 Created 请求被创建完成，同时新的资源被创建。
202 Accepted 供处理的请求已被接受，但是处理未完成。
203 Non-authoritative Information 文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝。
204 No Content 没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。
205 Reset Content 没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。
206 Partial Content 客户发送了一个带有Range头的GET请求，服务器完成了它。
3、3xx: 重定向
300 Multiple Choices 多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。
301 Moved Permanently 所请求的页面已经转移至新的url。
302 Found 所请求的页面已经临时转移至新的url。
303 See Other 所请求的页面可在别的url下被找到。
304 Not Modified 未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
305 Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取。
306 Unused 此代码被用于前一版本。目前已不再使用，但是代码依然被保留。
307 Temporary Redirect 被请求的页面已经临时移至新的url
4、4xx: 客户端错误
400 Bad Request 服务器未能理解请求。
401 Unauthorized 被请求的页面需要用户名和密码。
402 Payment Required 此代码尚无法使用。
403 Forbidden 对被请求页面的访问被禁止。
404 Not Found 服务器无法找到被请求的页面。
405 Method Not Allowed 请求中指定的方法不被允许。
406 Not Acceptable 服务器生成的响应无法被客户端所接受。
407 Proxy Authentication Required 用户必须首先使用代理服务器进行验证，这样请求才会被处理。
408 Request Timeout 请求超出了服务器的等待时间。
409 Conflict 由于冲突，请求无法被完成。
410 Gone 被请求的页面不可用。
411 Length Required "Content-Length" 未被定义。如果无此内容，服务器不会接受请求。
412 Precondition Failed 请求中的前提条件被服务器评估为失败。
413 Request Entity Too Large 由于所请求的实体的太大，服务器不会接受请求。
414 Request-url Too Long 由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。
415 Unsupported Media Type 由于媒介类型不被支持，服务器不会接受请求。
416 服务器不能满足客户在请求中指定的Range头。
417 Expectation Failed
5、5xx: 服务器错误
500 Internal Server Error 请求未完成。服务器遇到不可预知的情况。
501 Not Implemented 请求未完成。服务器不支持所请求的功能。
502 Bad Gateway 请求未完成。服务器从上游服务器收到一个无效的响应。
503 Service Unavailable 请求未完成。服务器临时过载或当机。
504 Gateway Timeout 网关超时。
505 HTTP Version Not Supported 服务器不支持请求中指明的HTTP协议版本。
500 Internal Server Error 请求未完成。服务器遇到不可预知的情况。
501 Not Implemented 请求未完成。服务器不支持所请求的功能。
502 Bad Gateway 请求未完成。服务器从上游服务器收到一个无效的响应。
503 Service Unavailable 请求未完成。服务器临时过载或当机。
504 Gateway Timeout 网关超时。
505 HTTP Version Not Supported 服务器不支持请求中指明的HTTP协议版本。
2、参数级验证，入参及出参的验证
1、入参和出参的类型、范围、是否必填、默认值、参数间的关联性，参数格式等进行验证
2、与接口文档一致
3、安全级验证
1、篡改参数的校验，如面值、规格、价格等重要数据的篡改，是否校验不让提交数据
2、接口请求限制校验，如某活动限参与一次，重复请求接口校验
3、并发请求是否写入多条数据，数据库是否唯一索引
2 接口测试用例设计
一个接口通常是有输入输出的，输入就是我们常见的入参，输出有时有，有时没有。调用相关接口，接口会执行相关处理逻辑。
接口测试的用例设计，主要从输入和接口处理两方面考虑：
1）针对输入，可按照参数类型进行设计；
2）针对接口处理，可按照逻辑进行用例设计；
3）针对输出，可根据结果进行分析设计。
2.1 针对输入设计
对于接口来说，输入就是入参。常见参数类型有:
（1）数值型(int,long,float,double等）
（2）字符串类型
（3）数组或链表
（4）结构体
结构体(struct)是一些元素的结合，元素实际也是数值型，字符串型，数组或链表。
下面详细说明数值型、字符串型、数组或链表三种参数类型用例设计。
2.1.1 数值型
数值型的参数主要考虑以下几个方面设计：
如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。
例如检查权限的接口：TaskChecker.checkTask(int taskID) taskID的取值范围是1-35，那么设计时考虑：
-
1-35范围内和范围外的值；
-
1-35的边界：0，1,35,36；
-
类型的特殊值：-1,0
-
数据类型的边界值：int的最小值最大值；
-
因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。
常见问题和风险：
-
特殊值处理不当导致程序异常退出；
-
类型边界溢出
-
取值范围外值未返回正确的错误信息等
2.1.2 字符串型
字符串型的参数，主要考虑字符串的长度和内容：
例如接口转换设置闹钟的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考虑：
-
长度为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(int taskID)接口完成清理任务获得积分。
因此新版本在考虑兼容旧版本的同时，还应做好相关废弃接口的检查，避免用户获得额外利益。
2.4.2 接口设计合理性分析
接口定义是否合理可以从以下几个方面分析：
（1）接口字段是否冗余；
（2）接口是否冗余；
（3）接口是否返回了调用方期望得到的信息；
（4）接口定义是否可满足所有调用需求；
（5）接口定义调用是否方便。
----------------------------------------标准接口测试的理由--------------------------------------------
2、为什么要做接口测试
a)互联网的快速发展，公司内部系统或与外部系统的关联越来越多，一个业务流程关联多个后端系统，它们的关联都是基于接口来实现，接口测试可以将复杂的系统关联进行简化，只要做好每个接口的测试就能够较好的保证系统质量。
b)单个系统的变更，是否会影响到关联业务系统，比较难用常规的测试方面来覆盖相关的应用系统（例如使用此接口的外部 系统有N个，不可能每个做功能兼容性测试），但可以通过对接口功能的覆盖来验证是否影响它人对接口的调用。
c)接口功能比较单一，能够比较好的进行测试覆盖，也相对容易实现自动化持续集成，，可以减少人工回归成本与时间，缩短测试周期。
d)接口相对于界面功能，会更底层一些，测试覆盖会更容易（如业务在调用接口时做了判断，当不满足条件时链接就不显示，此时从界面无法测试相关功能是否做好判断，通过接口就比较容易）
3、接口测试范围
a)业务功能（包括正常、异常场景是否实现）
b)业务规则（覆盖度是否全面）
c)参数验证（边界、业务规则是否达到要求）
d)异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
e)性能测试（响应时间、吞吐量、并发数、资源要求）
f)安全测试（权限验证、SQL注入等）
4、接口测试的重点
1、检查接口返回的数据是否与预期结果一致。
2、检查接口的容错性，假如传递数据的类型错误时是否可以处理。
3、接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
4、接口的性能，http请求接口大多与后端执行的SQL语句性能、算法等比较相关。
5、接口的安全性，外部调用的接口尤为重要。
二、做好接口测试的前提
1、系统化的接口文档
传统的接口文档，一般采用word或wiki等系统来记录，从单次使用上似乎比较简单，因为大家会更习惯这样的操作，但这种形式存在比较大的问题：
a、接口文档非标准化，无法直接与接口测试工具接口使用
b、接口维护困难，接口有变化时比较难标识清楚，沟通成本很高
系统化接口文档，例如rap（淘宝分源的一个系统），具备接口维护标准化、版本化管理、MOCK测试等功能；对标准化的接口内容做二次开发，可以直接导出Soapui等工具使用的格式，直接导入工具中使用，有以下好处：
A、接口测试时不再需要手工输入相关字段，节省时间成本
B、版本化管理，能够清晰的知道哪些接口有变化
2、标准化的接口规范
接口管理是做好接口测试很重要的前提，如果一个系统有哪些接口都不太清楚，测试就很难覆盖到，接口管理建议采用以下方式：
A、按接口提供方为单位进行首次划分，按接口使用方进行二次划分，再按业务模块进行细分，分类原则根据内容多少进行优化，不需要固定，如本身接口较少就没有必要分得过细，较多时就需要多划分模块
如：系统A，提供有 1、2、3、4、5、6、7、8、9 这9个接口，接口分别给B系统、C系统使用，其中1、2为公用接口，3、4、5为B专用，6、7、8、9为C系统专用
B、按接口链接URL做为唯一，不同的接口参数做为接口变量，接口有参数变更时在原来接口上进行维护，而不是新增加接口
C、为接口增加版本号，方便清楚哪些接口本次有变更，易于维护用例
