一定要先谈下接口在测试领域的地位：
且接口测试在测试领域地位非常高，是软件测试工程师初级和中级分界线。所以测试人员只要懂得接口测试，就能找到薪资很不错的工作。
所以测试工作者（也就是提问者眼中的QA），一定要尽最大努力去提高自己的接口测试实力。
如果想提高接口测试的代码覆盖率。首先要知道代码覆盖率低的原因，才能更好的采取措施来提高代码的覆盖率。仔细分析题主补充的应用场景后，题主的问题我分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.测试人员依据对业务实现的掌握，来设计测试用例，覆盖接口的实现业务场景。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
