接口测试策略(一、概念&流程&范围)

接口测试概要

接口测试概念

什么是接口测试？

维基百科对接口测试的定义如下：

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security.[1] Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps).

翻译过来就是：

接口测试是软件测试类型中的一种，通过直接检测被测应用的接口（API）来确定接口是否在功能、可靠性、性能和安全方面达到预期的软件测试活动。[1] 由于 API 都没有 GUI 界面，API 测试都是在通讯层进行的。[2] 现在 API 测试在自动化测试中有着很重要的地位，因为 API 一般是应用逻辑的主要接口，同时 GUI 测试在敏捷开发和 DevOps 的快速迭代和频繁变更中很难维护。

接口测试好处

1.可以发现很多在页面上操作发现不了的bug

2.检查系统的异常处理能力

3.检查系统的安全性、稳定性

4.提高回归测试效率，保证质量，缩短测试周期

5.发现更底层的问题，更早的发现问题

6.通过适当的验证来获得控制反馈，对系统变更有把握

接口测试流程

接口上的测试左移

向左扩展，就是让测试介入开发提测之前的部分测试工作。比如，扩展到开发阶段，在架构设计时就考虑产品的可测试性，并管理开发自测等。另外，测试可以更进一步扩展到需求评审阶段，让测试人员不只是了解需求，更要评估需求的质量。

接口上的测试右移

测试右移，是让测试介入服务或应用上线之后的部分。比如，测试人员在产品上线过程中，利用线上的真实环境测试，或者开展线上巡检。另外产品上线之后，测试人员依然关注，通过线上监控和预警，及时发现问题并跟进，将影响范围降到最低。这样一来，测试人员不但有更多的时间进行测试，还能发现在生产环境中难以发现的问题。

正常研发流程下的接口测试：

接口功能测试

概念

功能测试：对产品的各功能进行验证，根据功能测试用例逐项测试，检查产品是否达到用户要求的功能。

接口测试：指针对模块或系统间接口进行的测试。测试的重点是要检查数的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

接口功能用例设计

接口测试用例设计的重点，在于功能性的业务逻辑检查和参数检查。接口的测试遵从输入---接口逻辑---输出的方式，所以接口测试用例分为两种类型：业务功能、单接口的数据校验，一般来说，业务功能涉及到多接口协同调用组合成多个场景，可以用场景法去编写用例，单接口的数据校验可以用等价类+边界值的方法去设计用例。

接口异常测试

1.幂等测试

2.并发测试

3.事务测试

4.分布式测试

5.环境异常测试

6.大数据测试

幂等测试

概念：一个HTTP方法是幂等的，指的是同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。换句话说就是，幂等方法不应该具有副作用（统计用途除外）。在正确实现的条件下，GET，HEAD，PUT和DELETE 等方法都是幂等的，而 POST 方法不是。所有的 safe 方法也都是幂等的。幂等性只与后端服务器的实际状态有关，而每一次请求接收到的状态码不一定相同。例如，第一次调用DELETE 方法有可能返回 200，但是后续的请求可能会返回404。DELETE 的言外之意是，开发者不应该使用DELETE方法实现具有删除最后条目功能的 RESTful API。需要注意的是，服务器不一定会确保请求方法的幂等性，有些应用可能会错误地打破幂等性约束。

幂等就是一个操作或者接口，不管你调多少次，每次执行的结果都跟第一次一样。

试想这样的一种场景：在电商平台上支付后，因为网络原因导致系统提示你支付失败，于是你又重新付款了一次，等完成后检查网银发现被系统扣了两次款，这是一种什么样的体验？

造成上述问题的原因可能有很多，比如第一次付款时实际支付成功，但是信息返回时网络中断导致系统误判；又比如第一次付款的确失败了，但第二次付款时发生意外，导致支付请求被重复发送等等。在一次支付的过程中，每个环节都有可能会发生问题。

接口安全测试

1.失效的对象级别授权

失效的对象级别授权是指：用户与服务器使用API进行通信时，服务器端未进行对象级别的权限控制或限制不严格。攻击者可以通过修改请求数据中的对象ID等信息，实现未授权获取或修改敏感信息。

案例：在使用某个功能时通过用户提交的对象ID如订单号、记录号）来访问或操作对应的数据，且未进行严格的权限限制。

2.失效的用户身份验证

失效的用户身份验证是指：API在访问时未对请求方进行身份验证或身份验证存在问题导致易被破解，那么攻击者可以实现未授权对API进行操作。

3.过度敏感数据暴露

4.资源缺乏和速率限制

5.批量分配

后端应用对象可能包含许多属性，其中一些属性可以由客户端直接更新（如，ser.firstname或user.address，而某些属性则不应该更新（如，user.isvip标志）

PS：我记得以前见过一个关于登录接口的Bug，输入正确的账号密码后，接口返回有个登陆成功标记字段：1，结果输入错误的账号密码，再把接口返回加以拦截，修改返回报文，把登录失败标记字段改成表示成功的1，结果居然绕过账号密码登录成功了！

6.失效的功能级授权

7.注入

8.安全配置

9.资产管理不当

不当的资产管理缺陷是现代的产物，以业务速度前进的组织有时每天都能旋转出成百上千的服务和微服务。这通常是快速完成的，而且没有创建任何的附带文档，也没有解释相关的API是用来做什么的，需要多长时间或其重要性。这可能会快速产生API蔓延，随着时间的推移可能会变得无法控制，特别是如果没有全面的政策来定义API可以存在多久。这种环境下，很有可能一些API会丢失、被遗忘或者未销毁。

10.日志和监控缺失

参考资料：《接口测试白皮书》