如何有效的开展接口测试

Posted 2021-04-24 米么骚客

概述

移动互联网领域，用户群体庞大，需求瞬息万变，应用系统的复杂度逐渐上升。传统的测试方法更多地依赖页面，从UI层面来保证业务逻辑，需要等到所有系统组件以及前后端联调完成后才能介入，测试工作滞后，项目后期的成本和风险都急剧增加。分层测试是一个很好的解决方案，根据系统结构，从不同层面进行适当而有效地测试，极大的提高了测试效率，并且由于测试前移，项目发布风险也相应降低。下图是典型的分层测试模型：

引入服务层接口测试后，不同子系统之间的数据交换、传递、落地都有了保障，本文将围绕接口测试，对实施过程中的一些关键点、操作方法进行总结。

01

为什么要进行接口测试

提到接口测试，通常大家会有这样的疑问：前端测试不是已经覆盖到各种业务逻辑了吗？为什么还要做接口测试，接口测试和前端测试是不是重复了？。对于这个问题，可以从下面几个方面来解释：

• 根据分层测试理念，不同层次关注的内容是有差异的，接口层更关注服务端逻辑的验证，而前端偏向于展示逻辑及前端和服务端集成部分；

• 接口相对于前端变化较少，更加稳定，容易通过自动化实现持续集成，在后期可以减少人工回归的测试成本，缩短测试周期，而且相较于前端自动化，维护成本更低；

• 微服务架构下，很多系统组件都只有后台服务，通过健全地接口测试，可以实现后端快速发版需求；

• 接口层面的部分健壮性测试，如超长字符、特殊字符等，前端一般做了输入限制，没有办法测试，需要直接从接口层面模拟；

• 大部分应用系统，前后端架构是分离的，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端实在太容易），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证；

• 接口测试在服务端开发完成后就能介入，比前端测试更早，有助于提早发现业务逻辑上的问题，减少后期修复成本，同时从整个项目来看，测试前移也能有效的降低发布风险。

通过一张表格总结一下前端测试和接口测试的差异点。

注意

不可否认，接口测试和前端测试确实有重合的地方，所以在实际项目中，要根据系统特点，从整个项目的质量出发，采取适当的测试策略，尽量减少重复工作，优化资源配置。

02

接口测试的前提

弄清接口类型

做接口测试之前，首先我们要弄清楚服务端整体架构，系统组件之间、前后端之间、同第三方之间都是采用什么类型的接口，使用什么协议。常见的接口有基于Restful设计风格的Http/Https接口（一般用于前后端交互以及外部第三方交互），Dubbo接口（一般用于系统组件之间交互），WebService接口（一般用于系统之间交互以及外部第三方交互），还有一些基于异步考虑的消息队列，如MQ等。不同类型的接口，数据格式、交互方式存在差异，选择的测试方法和测试工具也会不同。

规范化的接口文档

接口文档用于明确接口定义，入参和出参、数据类型、数据结构、错误逻辑等。传统的文档大多采用word等文本方式，这种方式难以标准化，并且集成一些测试工具，如mock，文档后期维护困难，沟通成本增加。

目前我们针对Http/Https接口，使用RAP系统管理；针对Dubbo接口，采用Javadoc插件自动生成，确保接口文档的标准化，不管是接口调用方还是接口测试人员，通过阅读接口文档，就能完成后续工作，减少沟通成本。

参与接口评审

开发在完成接口设计后，一般会组织接口评审，参会人员有接口提供方、接口调用方等，双方在会上，对接口文档进行评审，主要是接口定义是否合理、接口数据是否齐全、交互逻辑是否正确等，最终达成一致。

作为接口测试人员，接口评审会也必须参加，在会上可以详细了解接口定义，熟悉开发设计思路，从测试角度提出一些安全性、健壮性、业务逻辑上的见解，加强测试开发沟通，后期对照接口文档，能更加有效地开展接口测试。

完善接口管理

接口文档中只有接口定义部分，接口上下游数据流转等都无法体现，所以结合业务逻辑，梳理出每个接口的使用场景非常重要。一方面可以帮助我们管理当前系统有哪些在用接口；另一方面，基于接口业务逻辑，设计出更多的测试场景，保证最大化覆盖，健全接口测试，提升测试覆盖率。

如何管理接口，需要根据实际业务情况来定，可以从下面几个角度考虑：

1. 接口上下游系统

2. 数据流转逻辑

3. 同数据库交互

4. 区分公共接口

5. 结合交互和业务流程图

6. 持续维护更新

03

接口测试的范围

常见的接口测试范围如图，其中每一项对应的考察点，仅列举了部分作为参考，需要根据项目实际情况进行增减。

04

接口测试设计

针对上述测试范围，做接口测试还是我们常见的设计思路。正向功能，边界值校验，异常和极端情况下的处理，上下游交互，安全，性能，易用性&可移植性和扩展性（譬如接口需要包含哪些逻辑，从整体业务上考量，是否会产生接口冗余的情况）。

常见场景

【文档测试】

是否与设计评审结果符合，有需求变更是否及时更新。

【参数校验】

入参和出参校验，包括数据类型，格式，必填非必填。请求头域，是否有从cookie或session里存取数据，参数的容错性和边界值等，参数组合测试。

【业务功能】

包含正常和异常场景，以及结合上下游系统相关的组合场景，所有业务逻辑分支都要覆盖到，1. 业务处理是否正确，数据落地是否正确，2. 是否有功能逻辑未实现；3. 代码实现是否有冗余，是否有优化的空间；4. 异常场景模拟：错误的业务数据，某些业务数据缺失，调用外部超时，各种异常抛出和抓取处理，日志处理，埋点；5. 同调用方联调，需要协调资源，是否兼容老接口，接入新接口，调用方需要做哪些改动，联调有哪些注意事项等。

【异常测试】

接口超时后续处理；并发提交下数据是否正确，特别是极限情况下，如库存不足时多笔订单的处理；对接口的幂等性测试，即相同数据重复提交；事务处理是否正确，异常报错同一事务内数据是否回滚正确；分布式环境下，多个节点获取和处理的数据是否同步；接口是否涉及缓存，缓存失效时间以及失效后的处理逻辑等。

【性能测试】

首先评估是否需要压测，思路：该接口是否有大量的数据存取,I/O操作是否频繁，是否业务关键路径，线程池，是否有大对象的处理。压测时，需要考虑接口的并发数据、TPS、响应时间关键指标以及服务器自身性能，包括CPU占用率、内存使用率、IO情况、网络使用率等。模拟大数量测试，包括存量数据准备，瞬时压力等，考虑缓存失效瞬间加压后接口的处理能力。

【安全测试】

接口是否有鉴权机制，是否对传输加密，URL拼接字段是否有信息泄露，接口响应核心敏感信息是否加密处理，是否存在sql注入风险等。

05

接口测试工具

根据接口类型以及测试类型不同，常用的测试工具有Jmeter、PostMan、SoapUI、LoadRunner等，每个工具都有各自的特点，根据自身需要挑选合适的工具，下表对常用测试工具的特点进行了简单对比。

由于接口测试需要考虑自动化、性能，所以在挑选测试工具时，要综合考虑，有些工具适用人工测试，但是并不具备自动化能力，或者没有提供一套完善的自动化框架支持。目前我们使用RobotFramework做接口自动化测试，使用Jmeter做接口性能测试，部分情况下也会使用例如PostMan做一些简单接口的人工测试。

06

接口测试流程

• 第一步：分析业务需求，整理出测试需求，即得到测试点；

• 第二步：参加接口评审，根据接口文档、测试范围以及测试设计方法，输出接口测试案例；

• 第三步：发起测试案例评审，需要项目组成员一起参与，会上就各测试场景达成一致，保证产品、开发和测试理解一致；

• 第四步：准备测试数据，包括系统内部数据以及外部依赖，必要时对外部依赖进行mock处理，测试数据需要考虑复用，同时进行自动化脚本开发；

• 第五步：准备测试环境，实施测试，对测试结果进行总结，完善补充测试案例和自动化脚本；

• 第六步：将自动化脚本规范化，提交入库，并纳入持续集成环境。

持续集成

对接口测试而言，持续集成自动化是核心内容，通过引入自动化框架，将接口测试案例转化为自动化脚本，持续维护更新，提高接口测试的价值。在日常测试过程中，可以对构建版本的稳定性以及回归测试带来便利，比如：

【冒烟测试】

加入持续集成工作流中，为每次构建的版本提供最基础的测试保障，同时作为版本是否可以进入系统测试的入口条件。加入接口自动化测试的持续集成工作流。

开发人员提交代码，Jenkins检测到代码变更，构建新版本并发布到SIT环境，运行冒烟测试（接口自动化脚本），如果测试通过，允许发布到UAT环境，继续后续的系统验收测试；如果测试不通过，禁止发布到UAT环境。分析定位自动化失败原因，如果是代码问题，通知开发人员进行修复，等待下次构建。如果是自动化脚本或测试环境问题，修改错误脚本或环境问题，重新触发冒烟测试运行，流程继续。

在此工作流当中，对于冒烟测试的案例，需要有针对性的进行筛选，比如挑选基本功能案例，正向流程案例等，确保发布到UAT环境的版本是可测的，不会出现基本功能或流程上的错误，导致测试阻塞。特别地要考虑对周边上下游系统的关联影响。

【回归测试】

在系统测试过程中，通过自动化快速回归，减少人工成本，缩短测试周期。

系统测试中一大部分工作来源于回归测试，需要在新增功能正常的前提下，确保老功能不会出现异常。因为在开发新功能的时候，不可避免的去添加或者修改原有方法中的逻辑，特别是一些公共代码，这样就会对老功能产生潜在的影响。

针对回归测试，一般测试策略是评估新增功能的可能影响范围，有针对性的挑选被影响模块的测试案例，再加上基本流程的测试案例，组合成回归测试案例。

在引入接口自动化之前，回归测试案例需要分配给测试人员人工执行，测试时间和人力消耗都是非常大的。而实现接口自动化之后，在制定回归测试策略时，可以结合接口测试覆盖的范围，将部分人工执行的工作交由自动化完成，节省了人力投入。同时由于自动化执行速度快，测试效率也得到了显著提高，回归测试时间大幅缩短，一些潜在的问题可以尽早地被发现。

总结

接口测试作为后端业务逻辑最基本的保障，起到了至关重要的作用。我们不仅要坚持做，还要持续改进，从加强异常场景覆盖、建立质量统计和分析模型、提升代码覆盖率、完善性能测试体系等多角度思考，在总结中不断前行。本文总结的相关内容并不一定适合所有场景，测试思想和测试方法可以互通，根据业务系统和项目特点，找到最实用的，更适合自己的才是更好的。现如今，随着应用系统复杂度提升，传统的测试方法已经远远不能满足，追求更加高效的测试方法，是我们每一位测试共同的目标。

作者介绍