提升代码覆盖率是非常有意义的,主要作用是:
- 保证基本逻辑的正确性(要结合有效的校验,这点很容易在实际中变形)
- 引入对未覆盖代码的思考,分析是编码本身逻辑混乱,还是需求实现有问题
- 促进代码重构,得到更优的代码
代码覆盖率做为指标其实是不合适的,每个组件其实有其自身特点和历史原因,往往需要在成本和收益之间做平衡。但是做长期小步提升的实践还是必要的。
提升代码覆盖率的方式有很多,最主要的方式还是增加用例,和优化代码。
1. 构造场景用例
根据业务流程规划测试用例,这是最主要的提升覆盖率的手段。最好由专人设计用例场景、提供校验准则,保证用例的有效性,同时可以大幅度的提升覆盖率。
2. 构造异常用例
正常流程是最容易被覆盖的,异常流程是最容易被遗忘的,常常也最难构造。但是异常用例却往往非常重要,不管是对业务逻辑还是对分支覆盖率都是如此。最好由业务专家分析必须首先覆盖的异常场景,再逐步对其他异常场景补充用例。
3. 剔除不需计算覆盖率的代码
例如UT/FT自身的代码、基本库代码、第三方库等,都是可以不计入覆盖率的。可以在统计时剔除掉。
4. 增加UT用例
对于FT比较难覆盖、逻辑比较复杂的函数,增加UT用例,对函数内各分支做覆盖,成本要比构造复杂的FT用例低得多。
5. 减少不必要的判断
比如用new分配内存的失败,会抛出异常。此时可以在程序外层捕捉异常,或者静态分配内存/池。不论哪种方式,都不必要在每次new之后都做指针判空。
6. 指针传参优化
对C++ 代码,函数参数可以传递引用,这样函数中就省去了对空指针的校验,即简化了代码,也增加了代码的健壮性。
7、简化逻辑
反思代码复杂度是否与业务复杂度正相关?代码是否容易理解?是否因历史原因,不敢重构代码,只敢增加分支?很多逻辑复杂的代码,往往只是没有理清业务本质。
8、消除重复代码
显而易见,相同逻辑如果散落在各处,对于提升覆盖率的明显会有更多的重复工作。