三、为方便理解提高代码覆盖率的方法，举例说明
示例1. 异步任务_以批量删除为例
项目中为了给用户好的体验，一些删除类的接口存在异步删除任务是很常见的。
例如：订单批量删除（某电商），文件批量删除（某盘）等等这些数据的批量删除业务很多都是通过异步任务来实现的。
下面粗略的写一下删除数据的假定逻辑：
批量删除
分析：
常规的接口测试用例覆盖，容易忽略这些异步任务其他分支。原因也很简单，QA不知道还有这些逻辑。调用接口时，这些场景也不容易触发。
如果开发人员提供了这个流程图，测试人员完全可以根据流程图来设计测试用例，覆盖所有的分支。
场景举例：
·异步任务写入失败
- 可以通过提前写入固定用户的固定数据，阻止数据写入（主键冲突之类的处理）
- 修改数据库连接数，批量执行删除接口
· 异步任务执行失败
- 可以提前预置错误数据，导致执行失败（缺少某些字段，某些字段值是错误数据）
示例2. 事务
项目中，有一些接口的实现，涉及一些事务，这也是非常常见的。
事务
分析：
接口测试用例设计过程中，考虑在整个业务流程中，尽量覆盖每一步出现异常，设计不同的测试场景，来覆盖整个业务流程。
场景举例：
· 事务内出现异常，回滚成功。
示例3. 锁
项目中，多端操作也是比较常见，web端，App端，小程序等。那就会存在一些接口操作同一部分数据的场景。
锁
分析：
在设计接口测试用例时，要考虑锁相关的场景，提高代码覆盖率。
场景举例：
· 获取锁
- 无锁
- 获取写锁
- 获取读锁
- 写锁存在
- 获取读锁
- 获取写锁
- 读锁存在
- 获取读锁
- 获取写锁
· 释放锁
- 读锁
- 释放锁成功
- 释放锁失败
- 写锁
- 释放锁成功
- 释放锁失败
示例4. 定时任务
项目如果存在需要批量处理数据时，一般 都会选择在低峰期，通过定时任务来实现。
例如：数据版本迁移，清理过期数据等。
定时任务
分析：
针对服务器接口测试时，这些定时任务也要去验证。可以有效提高 代码覆盖率。
在这主要强调一下任务执行的数据状态，要保证数据全面性，整个生命周期的数据代表均要存在，并且要有一定的量级，这样才能覆盖任务的处理逻辑。
场景举例：
·定时任务是否拉起
· 定时任务是否执行
· 任务执行前，数据是否全面（覆盖整个生命周期的所有类型数）
四、保证接口测试覆盖率可能会遇到的难点分析
难点1. 开发提供的接口实现文档不规范
开发实现文档要有一定的模版和编写规范，严格要求开发人员输出文档。要有把控措施。
难点2.测试人员理解困难
· 文档要注重流程描述，少代码。
· 这个是可以培养的，难点并不会特别大。除非这个测试人员不想进步。
难点3.设计的用例无法实施测试
· 存在一些异常场景，实施测试确实有难度，可以求助。
· 我现在越来越觉得作为测试人员，在设计用例的时候，是不需要考虑能不能实现测试的。没法测试，多半是因为自己技能不足。所以用例正常设计，用例执行可以找大佬辅助。
五、最后总结
具体的实现要求
· 开发人员，将接口实现逻辑，从代码思想转化为文档描述。这是让无代码基础理解项目业务的前提。文档要规范，评审要清晰，变更及时同步。
· 测试人员需要加强学习，通过文档阅读，评审学习，请教开发，理解业务实现。
· 测试人员深入理解业务，然后设计更全面的测试场景并实施测试。
意义
· 提高了代码覆盖率，项目自然测试的更加充分。能够发现更多隐藏的问题。
· 能够让没有代码能力的测试人员快速成长，做好测试。
· 规范化了开发实现流程，对项目的开发管理也很一定促进作用。
缺点
· 刚开始实施起来会吃力一些，尤其是跨部门操作。
· 测试和开发会有更多的沟通成本。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
