接口测试总结

从0到1，认识和熟悉接口测试。

1.接口

接口泛指实体把自己提供给外界的一种抽象化物（可以化另一实体），用以由内部操作分离出外部沟通方法，使其能被内部修改而不影响外界其他实体与其交互的方式。

人类与电脑等信息机器或程序之间的接口称为用户界面；电脑等信息机器硬件组件间的接口叫硬件接口；电脑等信息机器软件组件间的接口叫软件接口。这里主要讨论的也是和我们软件测试工程师最密切的软件接口。

2.接口分类

分类方式	接口类别	描述	主要关注点
按功能	程序内部接口	方法与方法之间、模块与模块之间的交互，是程序内部抛出的接口。这类接口平常接触得可能相对更多一些，不同的模块部署在同一套服务器上并使用同样的数据库。	接口间的逻辑控制关系
	系统对外接口	不同系统之间的接口。比如有时候想要从别的服务器上获取资源，目标服务器提供对外的接口，我们可以通过调用这个接口来访问对方的数据。各个系统是部署在不同服务器上，使用不同的数据库	系统间接口的实现方式，例如接口文件类型、文件格式
按类型	业务接口	业务逻辑存在上下游关系。可能设计跨系统跨模块的逻辑控制以及方向操作	测试难点是业务逻辑的分析，推荐使用路径覆盖的方式进行，同时要注意不同业务流下的正向、方向操作的测试
	数据接口	接口中存在数据上下游的关系	测试重点在于数据本身，例如数据的准确性和安全性
按数据方向	单向接口	根据实现方式分为单向推和单向取两种，这两种方式都存在一个数据地址和相关的存取策略	数据的文件格式和存取策略
	双向接口	系统或模块之间的数据双向流动。比如报文处理系统需要接收核心系统发来的数据，又要将处理结果返回给核心系统	来往数据的关联性
按数据读写方式	单独读写接口	数据在接口中不仅是单向流动而且都是读或写的单独操作。例如模块与数据库之间的接口，属于单向接口的一种特殊方式	接口的读写权限以及对冲突等异常的处理机制
	既读又写接口	此类一般是业务类接口，存在业务逻辑控制的要求	业务逻辑以及读写数据的正确性和写入数据的正确性
按接口层级	直接（联机）接口	系统或者模块间的接口是直接联通的模式	直接根据接口的特征进行分析
	间接（非联机）接口	系统间接口需要第三方中转后才会进行连接。比如综合报文系统和核心系统中间隔着一个ESB，第三方一般不会涉及到业务逻辑，经常是进行一些数据格式的转换操作	需要分析中间层的处理方式是否合理，以及中间层异常时，系统的处理方式是否合理

3.接口测试

这里按照5W1H的分析方法来作说明。

1.定义与分类（what）

1.1 定义

接口测试是属于功能测试范畴，不同于界面上的手动测试，但只是测试对象不是界面元素而是接口，本质上也还是输入数据，发送请求，输出结果，检查结果的过程，也是通过不同的输入数据组合来实现的。

1.2 分类

根据测试的内容可以分为：

模块接口测试——也就是常说的集成测试；

数据库接口测试——数据交换的准确性和安全性测试；

web接口测试——webservice接口测试和http api接口测试，webservice走http协议，请求报文和返回报文都是xml格式；http api接口走http协议，返回报文一般为json格式。

2.为什么做接口测试（why)

• 弥补传统UI测试的不足

很多系统没有界面，只有接口功能，不能进行UI测试；

有些服务端的功能在UI上没有覆盖到；

UI上不能直接看出是否做了有些必要的异常处理。

• 保证安全性

只依赖前端进行限制不足以满足系统的安全需求，需要在后端也加以控制，于是就要对接口进行验证；

前后端传输、日志打印等信息是否加密也需要验证

• 提高投入产出比

相对单元测试比较稳定、可靠、快速，相对UI自动化变更少，用例易于维护。较容易实现自动化持续集成，可以降低人工回归测试的人力和时间成本，有助于版本快速迭代；

降低构造异常场景的人力和时间成本，方便快速检查系统的安全性、稳定性以及对异常的处理能力

• 提高团队工作效率

由于在接口功能代码搞定之后就可以测试，不需要等前端页面完全写好，因此测试工作能够早点介入，能节省工作时间

3.接口测试的执行者（who）

通常开发人员将接口文档写好后，由测试人员来对接口进行测试。有些团队里接口的性能测试可能会是开发人员自测，毕竟开发对自己写的接口比较熟悉，而且优化起来会更直接方便。

4.接口测试的时间段（when）

4.1 前期准备

主要是使测试所需的条件尽可能充分：

• 了解系统以及内部各个组件之间的业务逻辑交互，了解接口的I/O；

• 选择好合适的测试手段：是采用postman、jmeter等工具，还是编写测试代码，亦或结合进行；

• 了解协议的基本内容：常用的协议类型、请求和响应的构成等；

• 熟悉接口关联的数据在数据库中的位置，能用基础数据库操作命令获取相关数据；

• 知悉一些接口相关的典型问题，如：传入参数处理不当，导致程序crash类型溢出，导致数据读出和写入不一致；状态处理不当，导致逻辑出现混乱，逻辑校验不完善。

4.2 常见场景

接口测试活动常常在这些场景中发生：

• 测试或开发定位问题时，想要调用某个接口查看响应是否正常；
• 手工测试某个功能点时，需要一个订单号（或者其他类型数据），可以通过顺序调用多个接口实现下单流程；
• 开始上线测试之前，可以先检测一下系统的所有接口是否工作正常，确认正常后再开始手工测试；
• 开发提交代码前检测新的代码对系统已有接口是否产生影响；

5.接口测试在哪测哪些（where）

5.1 在哪进行

接口测试的载体很多，包括各式各样的工具、框架、平台等，具体如何选择需要考虑测试周期、学习成本、后续用例或脚本维护等实际情况。

• 轻量级工具：postman、jmeter、soupUI等，简单实用；
• 高级工具：jmeter、python的request库、TestNG等，功能强大，拓展丰富，包括但不限于多种协议支持、前置条件、后置条件、文件读取、检查点、结果报告；
• 框架：jmeter+Ant+Jenkins 或 TestNG+Maven 或 request+HTMLreport+Jenkins等比较流行的框架；
• 平台：涉及到执行代理、执行引擎、协议支持、数据读写、任务分发调度、结果收集、集成CI/CD等功能，实现的技术要求较高；

5.2 测试范围

包括但不限于：

• 业务功能测试：正常场景+异常场景
• 边界分析测试：业务边界值分析、输入输出参数边界值分析
• 参数组合测试
• 安全测试：敏感信息加密、SQL注入等
• 性能测试：响应时间、吞吐量、并发数、占用资源率
• 异常情况测试：并发测试、分布式测试、事务测试、环境异常、大数据量测试

6.如何进行接口测试（how）

6.1 流程步骤

在需求评审阶段要熟悉业务和具体的测试需求；

开发提供相关接口文档或者测试人员自己抓包分析，根据接口信息和接口测试范围设计并编写测试用例（方法也是UI功能测试的那些：等价类划分、边界值划分、错误推断等），理论上对于单个接口需要覆盖到所有正常和异常分支；

用例评审；

转测后执行测试用例，验证响应结果（查看状态码、响应报文是否含有关键信息、响应报文关键字段是否存在且值正确、结合数据库进行比对正误），涉及中间件处接口的测试，还需关注系统日志中有无错误；

追踪bug，输出测试报告

6.2 测试的原则

• 要明确接口实现的是什么功能，实际实现的功能与之是否一致；
• 测试数据量较多的情况下，采取数据驱动模式较为合适，后续沿用方便点；
• 先单接口测试，再多接口测试；
• 测试完成后，需对脏数据处理