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