如何保证接口测试的覆盖率？

喜欢ヅ旅行 2024-03-24 23:16 29阅读 0赞

**写在前面\_一定要先谈下接口在测试领域的地位：**

在当前企业实际测试技能应用中，功能测试和[接口测试][Link 1]应用最广泛。但相比功能测试，**接口测试缺口却非常大。**

**且接口测试在测试领域地位非常高，是软件测试工程师初级和中级分界线**。所以测试人员只要懂得接口测试，就能找到薪资很不错的工作。  
![在这里插入图片描述][d10f4cae83ed4ebd98fbef52415da482.jpeg]

所以测试工作者（也就是提问者眼中的QA），一定要尽最大努力去提高自己的接口测试实力。

如果想提高接口测试的代码覆盖率。首先要知道代码覆盖率低的原因，才能更好的采取措施来提高代码的覆盖率。仔细分析题主补充的应用场景后，题主的问题我分4部分来阐述。

1、为什么常规接口测试，代码覆盖率低呢？  
2、如何提高代码覆盖率呢？  
3、为便于理解接口测试用例方法，举例说明。  
4、保证接口测试覆盖率可能会遇到的难点分析。

### 一、为什么常规接口测试，代码覆盖率低呢？ ###

接口QA还是黑盒的。QA们并不关注接口的内部逻辑。只是按自己的理解去设计不同的参数组合当做用例。

其实题主已经揭露了代码覆盖率低的根源。针对接口测试，这种黑盒测试用例设计思维还是比较普遍的。

我们以一个简单的接口场景为例，来看看黑盒测试人员的测试用例设计：

**以http协议为例**

单接口：

验证 URL  
\* 针对URL 路径上存在一些特殊的path需要验证

验证 查询参数，请求头、请求体参数  
\* 针对参数：正则类的参数校验（正常和异常数据）  
\* 针对业务：单接口功能覆盖（正向需求和反向需求）

验证 响应数据  
\* 正常接口响应覆盖  
\* 异常接口响应覆盖（错误信息）

验证 业务场景：  
\* 覆盖应用的业务场景  
\* 通过接口，模拟用户可能的操作流程

**这种黑盒设计应对接口测试，往往会遗漏下面4个分类：**

**遗漏分类1、测试不清晰或不规范导致的场景遗漏**

如果接口测试用例设计思路不清晰或者不规范，是很容易遗漏场景的。也就是上面所提到的，黑盒测试用例设计思维应该覆盖的场景存在遗漏，肯定会降低代码的覆盖率。

**遗漏分类2、涉及不容易覆盖的分支**

接口的实现逻辑多种多样，涉及很多分支，下面列举一些常见的点。希望大家多多补充。

**1.接口涉及异步任务**

当接口涉及异步任务时。常规的接口测试用例设计思路，一般只会触发异步任务正常执行的场景。而异步任务失败，重试，定时被拉起这些异步流程，有可能会被遗漏掉。因此会降低代码覆盖率。

**2.接口涉及事务**

当某个接口涉及事务，常规的接口测试用例设计，一般只会触发正常的事务流程。而实际开发人员是对具体哪一步回滚，回滚后需要的处理，都是做了一些特殊的业务实现的。这些场景容易被遗漏，也会影响代码覆盖率。

**3.接口涉及锁**

当某个接口涉及到锁，也会有容易遗漏一些测试场景。以读写锁为例（读-读共存，读-写不共存，写-写不共存）。常规的接口测试用例设计，很可能会遗漏一些 读-读共存，读-写不共存，写-写不共存的场景。就算这些场景被覆盖了，关于锁过期，获取锁失败后等待的场景很难被覆盖到。很明显这会降低代码覆盖率。

**4.接口涉及缓存**

接口中利用缓存技术是比较常见的，尤其是查询类接口。比如批量查询。如果接口涉及了缓存，常规的接口测试用例设计很容易忽略缓存的影响，而没有针对性对接口缓存相关的验证。这也会降低代码覆盖率。

**遗漏分类3.异常场景忽略**

理论上讲，每一个接口都可能存在异常场景

当接口存在一些异常场景，抛出了框架的报错，一般是不允许的。换句话讲，程序员一般要对接口可能出现的异常场景 进行处理。有一些场景比较苛刻，不易出现，测试人员也容易忽略。一旦没有覆盖，肯定会降低代码的覆盖率。比如：

**场景1: 下游接口返回超时**

上游服务调用本服务对外提供的某个接口时，本服务在处理此接口业务需要访问其他服务，其他服务返回可能会超时，本服务一般也不会一直等待。

**场景2：数据库连接超时**

当某个接口需要操作数据时，数据库服务器的性能是一定的，肯定会存在一些数据库异常的场景。针对这些场景，开发一般都做一些代码处理。

**场景3：缓存服务器异常**

用户的一些登录状态，如果保存在缓存服务中。如果缓存服务异常或重启，很多接口都会受到影响。这些场景也需要去覆盖。

**遗漏分类4.其他相关-项目配置**

很多项目的业务逻辑，是可以通过配置来进行控制的，这也是很普遍的。有些功能是否开启，开始的模式，以及具体业务内容的控制，都可以使用配置项来进行处理。  
比如：

**功能开启开关配置**

如果开关关闭，此功能业务代码肯定是没法覆盖了，需要开启并测试相关业务员，这也才能覆盖这类代码。

**定时任务配置**

根据配置设置定时任务执行策略。一些定时任务会处理不同状态的数据。如果某种任务模式没有测试，或者某个模式下数据状态覆盖不全，都会漏侧场景。降低代码覆盖率。

### 二、那如何提高代码覆盖率呢？ ###

整体思路：针对第一部分分析的原因，采取一些措施，尽量让咱们不懂代码的测试人员能够更好的测试接口，覆盖这些场景。最终提高代码的覆盖率。

**解决1. 黑盒测试场景遗漏**

这种场景遗漏，是比较好解决的。具体措施：规范用例设计方法和流程，基本的测试人员都能够胜任。

**解决2. 覆盖接口中的特殊分支分、异常场景和项目配置相关场景**

想从接口设计用例去覆盖这些场景，前提，是必须得知道这些业务逻辑并理解。为了达到这一目标，可以从以下4步来保障。

1、开发除了提供接口文档，还要提供接口实现文档，在文档中要描述清楚接口的实现流程。比如接口涉及的配置项、异步任务、事务、锁、缓存等等，都要明确说明。最好能够输出流程图或时序图。这一点很关键，这可以大大帮助无代码基础的测试人员理解接口业务和实现细节。

2、测试人员除了参加需求评审，掌握项目需求。还需要参加开发的需求设计评审会议，加深对接口的具体业务理解。由于测试人员单独去阅读学习是有一定难度的，测试人员可以多找对应开发人员了解业务实现。

3、如果需求发生变更，或者业务实现发生变更，及时沟通并更新相关文档。

4、测试人员依据对业务实现的掌握，来设计测试用例，覆盖接口的实现业务场景。

### 三、为方便理解提高代码覆盖率的方法，举例说明 ###

**示例1. 异步任务\_以批量删除为例**

项目中为了给用户好的体验，一些删除类的接口存在异步删除任务是很常见的。

例如：订单批量删除（某电商），文件批量删除（某盘）等等这些数据的批量删除业务很多都是通过异步任务来实现的。

下面粗略的写一下删除数据的假定逻辑  
![在这里插入图片描述][d4c704ed675f43299839987b8d6d6c8d.png]

**分析：**

常规的接口测试用例覆盖，容易忽略这些异步任务其他分支。原因也很简单，QA不知道还有这些逻辑。调用接口时，这些场景也不容易触发。

如果开发人员提供了这个流程图，测试人员完全可以根据流程图来设计测试用例，覆盖所有的分支。  
场景举例：

异步任务写入失败

可以通过提前写入固定用户的固定数据，阻止数据写入（主键冲突之类的处理）

修改数据库连接数，批量执行删除接口

异步任务执行失败

可以提前预置错误数据，导致执行失败（缺少某些字段，某些字段值是错误数据）

**示例2. 事务**

项目中，有一些接口的实现，涉及一些事务，这也是非常常见的。  
![在这里插入图片描述][9f8ef289cea141728e1c8ed706e18048.png]

**分析：**

接口测试用例设计过程中，考虑在整个业务流程中，尽量覆盖每一步出现异常，设计不同的测试场景，来覆盖整个业务流程。

**场景举例：**

事务内出现异常，回滚成功。

**示例3. 锁**

项目中，多端操作也是比较常见，web端，App端，小程序等。那就会存在一些接口操作同一部分数据的场景。

![在这里插入图片描述][afa2a3f6fdf843d888955f1f943d7bd1.png]

分析：  
在设计接口测试用例时，要考虑锁相关的场景，提高代码覆盖率。  
场景举例：  
获取锁

无锁

获取写锁

获取读锁

写锁存在

获取读锁

获取写锁

读锁存在

获取读锁

获取写锁

释放锁

读锁

释放锁成功

释放锁失败

写锁

释放锁成功

释放锁失败

**示例4. 定时任务**

项目如果存在需要批量处理数据时，一般 都会选择在低峰期，通过定时任务来实现。  
例如：数据版本迁移，清理过期数据等。

![在这里插入图片描述][0702f2a200ee41e8912cf243e3739e84.png]

分析：

针对服务器接口测试时，这些定时任务也要去验证。可以有效提高 代码覆盖率。  
在这主要强调一下任务执行的数据状态，要保证数据全面性，整个生命周期的数据代表均要存在，并且要有一定的量级，这样才能覆盖任务的处理逻辑。

场景举例：

定时任务是否拉起

定时任务是否执行

任务执行前，数据是否全面（覆盖整个生命周期的所有类型数）

### 四、保证接口测试覆盖率可能会遇到的难点分析 ###

**难点1. 开发提供的接口实现文档不规范**

开发实现文档要有一定的模版和编写规范，严格要求开发人员输出文档。要有把控措施。

**难点2.测试人员理解困难**

文档要注重流程描述，少代码。

这个是可以培养的，难点并不会特别大。除非这个测试人员不想进步。

难点3.设计的用例无法实施测试

存在一些异常场景，实施测试确实有难度，可以求助。

我现在越来越觉得作为测试人员，在设计用例的时候，是不需要考虑能不能实现测试的。没法测试，多半是因为自己技能不足。所以用例正常设计，用例执行可以找大佬辅助。

### 五、最后总结 ###

具体的实现要求

开发人员，将接口实现逻辑，从代码思想转化为文档描述。这是让无代码基础理解项目业务的前提。文档要规范，评审要清晰，变更及时同步。

测试人员需要加强学习，通过文档阅读，评审学习，请教开发，理解业务实现。

测试人员深入理解业务，然后设计更全面的测试场景并实施测试。

**意义**

提高了代码覆盖率，项目自然测试的更加充分。能够发现更多隐藏的问题。

能够让没有代码能力的测试人员快速成长，做好测试。

规范化了开发实现流程，对项目的开发管理也很一定促进作用。

**缺点**

刚开始实施起来会吃力一些，尤其是跨部门操作。

测试和开发会有更多的沟通成本。

**最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：**

#### ![在这里插入图片描述][492d7612ecf9402ca45f3dad0b4d69e3.png_pic_center] ####

**软件测试面试小程序**

被百万人刷爆的软件测试题库！！！谁用谁知道！！！全网最全面试刷题小程序，手机就可以刷题，地铁上公交上，卷起来！

**涵盖以下这些面试题板块：**

> 1、软件测试基础理论 ，2、web,app，接口功能测试 ，3、网络 ，4、数据库 ，5、linux
> 
> 6、web,app，接口自动化 ，7、性能测试 ，8、编程基础，9、hr面试题 ，10、开放性测试题，11、安全测试，12、计算机基础

![a04a286764814986a179a6ea4a30b0cb.png][]

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！

[Link 1]: https://so.csdn.net/so/search?q=%E6%8E%A5%E5%8F%A3%E6%B5%8B%E8%AF%95&spm=1001.2101.3001.7020
[d10f4cae83ed4ebd98fbef52415da482.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/5ccb82de6f484997bb6bf95eabf333e9.png
[d4c704ed675f43299839987b8d6d6c8d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/3df2093819ec403b94ad88fa8a5b2ffb.png
[9f8ef289cea141728e1c8ed706e18048.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/d113e2fa728044a6bae299216f5f5675.png
[afa2a3f6fdf843d888955f1f943d7bd1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/aaea37dfcbcf4d89ba9e950690d67aee.png
[0702f2a200ee41e8912cf243e3739e84.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/821984f237a44a9890fa90e1c16723bf.png
[492d7612ecf9402ca45f3dad0b4d69e3.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/53cbe8f5404445298bc1360b6d64b478.png
[a04a286764814986a179a6ea4a30b0cb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/a4d94bf435d643f4a0f3f74ae57484fe.png