代码覆盖度-NCover监控IIS和exe，结果分析

1.监控发布在IIS中的程序

1.1使用注意事项

1）在监控发布在IIS中的应用程序，即监控IIS服务时需要注意停止监控，程序会将IIS服务停止，为了减少IIS频繁启动对于他人的影响，建议在无人使用的时间段或者独立的服务器上进行。

2）对监控结果分析时，只需要保证你发布产物用于编译的代码在NCover服务器上存在即可，例如个性化彩铃铃音设置工具DiyRingSetTool是从路径” E:\Project\CTI_DiyRing2.0\11.Tags\Build1389\工具\Diy铃音设置工具”下获取代码编译的，那么NCover所在服务器的相同路径下存在代码，监控完成后工具会自动加载出代码进行分析。

1.2监控发布在IIS中的流程

安装完成后，运行NCoverExplorer，本次实践选择的为个性化彩铃的用户流程DiyFlow，首先将DiyFlow在IIS中发布，然后建立监控工程并开始监控

 

1.3对监控结果进行分析

目前测试用例共264条，但是监控的覆盖度仅仅只有37%，详细监控结果见下图。

 

上图可以看出，流程中接口相关的操作，监控的覆盖度为65%

1.3.1分析用例存在的问题：

（1）、用例中缺少对接口返回码的覆盖

（2）、用例混淆了接口正确返回但是返回码为失败与接口未给出任何返回的情况

（3）、用例缺少接口返回成功但是返回结果为Null的情况

（4）、用例缺少部分模块的测试用例（后续做需求才整理的用例，前期功能的用例未整理）

（5）、用例缺少极值的情况，例如只有一个栏目、1首资源或者大于9首资源

（6）、用例是否存在冗余，将部分测试用例简化

（7）、分析页面中针对接口没有覆盖的页面处理逻辑也全部没有覆盖，用例补充接口部分即可

（8）、页面获取失败的异常没有覆盖

1.3.2代码存在的问题：

（1）、部分模块对于接口异常没有处理，只处理了接口返回失败的情况

（2）、代码冗余，有些功能可以共用代码，但是写了多个方法

（3）、下线的代码没有屏蔽

1.3.3其它问题

（1）、文本日志记录失败的异常没有覆盖

（2）、FTP操作异常没有覆盖

（3）、缓存处理失败没有覆盖

1.4用例优化后的测试结果

针对上诉分析的结果，对接口调用部分的用例进行补充，测试后的结果见下图，将接口覆盖度由原来的65%提高到74%。但是整个覆盖度还是偏低，分析了，很多功能下线的代码还保存在，导致用例测试不到，覆盖度偏低。

 

2.监控发布在IIS中的程序

2.1使用注意事项

1）使用NCover工具进行代码覆盖度的监控。（代码均使用C#开发）

2）使用Ncover监控发布在IIS下的某个组件的代码覆盖度时，可以先将业务发布在IIS中，然后将你编译用的代码拷贝到Ncover所在服务器上，注意：NCover中的代码所在路径与你编译时取得路径保持一致，这样，监控结束后软件可以成功找到代码，利于分析

3）发布完成后启动NCover直接监控IIS服务即可，但是监控关闭时会关闭服务器的IIS服务，所以为了避免你被围攻，建议选择测试业务较少的服务器或者开展测试任务较少的时间段内进行监控服务。

2.2监控发布在IIS中组件

安装完成后，运行NCoverExplorer，本次实践选择的为个性化彩铃的联通中音全网UniComProxy接口，首先将UniComProxy在IIS中发布，然后建立监控工程并开始监控

2.2对监控结果进行分析

目前测试用例共11条，但是监控的覆盖度达到91%，详细监控结果见下图。

结果分析：

（1）接口方法较简单，只是简单的封装平台的删除方法，接口只负责参数的传递操作，所有功能逻辑较简单

（2）接口处理的逻辑是通用的，之前已经测试很多次

（3）和开发人员进行了确认，本次没有执行到的代码不涉及到此接口，是通用部分

 

3.监控exe工具

3.1使用注意事项

1）使用NCover工具进行代码覆盖度的监控。（代码均使用C#开发）

2）使用Ncover监控某个exe程序

3）工具编译成exe工具即可

4）使用Ncover监控exe应用程序。

3.2监控exe工具

安装完成后，运行NCoverExplorer，本次实践选择的为个性化彩铃的铃音设置工具DiyRingSetTool，建立监控工程并开始监控

 

3.3对监控结果进行分析

目前测试用例共51条，监控的覆盖度为46%，详细监控结果见下图。

结果分析：

（1）工具部分逻辑在插件中，但是插件并未包含在工具的工程中，此部分代码并未监控到

（2）工具主题框架并未做改动，测试过程中未针对工具异常运行或者配置不正确等情况做测试