代码安全检视方法有_代码覆盖率测试-分析未被覆盖的几种情况

最近刚完成了B项目的接口自动化脚本开发。但是发现跑完脚本，覆盖度并未达到100%，为啥呢？明明所有接口都覆盖了呀。所以查一下原因。

一 先简要说一下测试步骤

1 修改项目底包（openjdk8-apm / jdk8-apm, tomcat8.5-openjdk8-apm/ tomcat8.5-jdk8-apm）-为插桩服务

2 PAAS上配置B项目环境变量CCT（CCT不为空），相当于启动覆盖测试。

3 在Jenkins上配置cct项目（导出报告用）。

4 被测应用发版（发版时自动插桩）

Paas上发版

5 Jenkins上执行cct项目，导出覆盖度测试报告（此时覆盖度很低）

跑脚本前的覆盖率

5 执行自动化脚本

6 再次执行cct项目，导出报告，会看到覆盖度增加，最重要的两个包，websitesystem，能够节省人力70%的回归工作量。重点关注指令覆盖，这个比较准。

跑脚本后的覆盖率

二 未覆盖到的代码找原因

7.1 exception异常代码。

7.2 部分业务逻辑脚本没覆盖。如 api下的CommonControler下的短信验证码，未测试图形验证码为空、图形验证码token为空、验证码类型为空的情况-------------需要维护脚本，把未覆盖的场景覆盖

业务逻辑未覆盖全

7.3 有的是代码没有调用到。如Util 类如下图

工具类代码未调用

7.4 有些是由于业务变更接口已废弃，但代码未删除。

接口已废弃代码未删除

7.5 有些代码是在数据库中数据有变动才会执行，无变化不执行。 -------------需要维护脚本，入参采用随机数

特定场景执行的代码

三 脚本优化后的显差

优化“提交接口”脚本，使入参为随机数，这样calculationMiddleIdi方法被调用（此方法代码行非常多），最后覆盖率达到88%（优化前13%）如图

总结：

代码覆盖率测试有其积极意义：

1 它能够帮助检视自动化脚本的成效，脚本开发人员测试点是否设计的足够全？一测便知

2 没被覆盖到的代码是哪些？脚本是否有改进空间？ 一测便知