嵌入式程序跑通以后，测试做没做到位，光看几次正常运行很难判断。有些异常分支平时根本进不去，有些函数只在特定输入下才会执行，这时就要借助代码覆盖率去看哪些基本块和源码行真正跑过。Green Hills MULTI提供了覆盖率和Profiler相关功能，但采集方式会受到工具链版本、目标环境以及调试连接方式影响。碰到结果里少了几个函数、某些文件没有数据，也不能直接认定测试没跑到，编译选项和数据回传同样值得检查。

　　一、Green Hills怎么查看代码覆盖率

　　Green Hills的覆盖率分析可以基于编译插桩数据，也可以结合支持跟踪的目标环境使用Profiler查看执行情况。平时只想确认代码有没有执行过，Block Coverage是比较直接的入口。

　　1、给工程打开Block Coverage

　　准备采集覆盖率时，要让参与测试的代码按覆盖率方式重新编译，旧目标文件不要继续混用。

　　①、在【MULTI Project Manager】中找到需要测试的【.gpj】工程。

　　②、右键工程并打开【Set Build Options】。

　　③、进入【Debugging】相关选项。

　　④、找到【Profiling-Block Coverage】。

　　⑤、只记录是否执行时选择【Flag】。

　　⑥、需要统计基本块执行次数时选择【Count】或当前版本提供的计数模式。

　　⑦、保存设置后执行【Clean】并重新【Build】工程。

　　2、运行测试并取得覆盖率数据

　　①、使用重新构建的【Program】启动调试。

　　②、连接当前【Target】并运行待测程序。

　　③、按测试用例执行需要验证的功能路径。

　　④、在【Debugger】中打开【View】→【Profile】。

　　⑤、程序不会自行退出时，停止目标并执行【Dump Profiling Info】。

　　⑥、点击【Process Data】处理本次采集结果。

　　测试结束后，如果数据已经正确送回主机，Profile窗口才能把执行记录和当前程序对应起来。只运行程序但没有完成数据转储，结果里就可能只有一部分信息。

　　3、查看没有执行到的代码

　　①、在【Profile】窗口切换到【Coverage】页。

　　②、查看各函数和基本块的执行情况。

　　③、进入【Block Detailed】检查更细的覆盖信息。

　　④、点击【Coverage View】把未执行内容显示到源码区域。

　　⑤、需要查看次数时切换【Count View】。

　　⑥、结合当前测试用例记录未覆盖的位置。

　　二、Green Hills代码覆盖率数据不完整如何检查

　　“覆盖率低”和“覆盖率数据没采全”是两回事。某段代码显示没有执行，可能只是测试没走到；整个文件或一批函数根本不出现在结果中，就要把编译和采集环节重新核对。

　　1、检查相关源码有没有启用覆盖率

　　如果只有部分文件有结果，先看出问题的源文件是否和其他代码使用了相同构建配置。

　　①、在【Project Manager】中找到缺少数据的【Source File】。

　　②、打开该文件所属工程的【Build Options】。

　　③、核对【Profiling-Block Coverage】状态。

　　④、查看单个文件是否存在独立的编译选项。

　　⑤、执行【Clean】清除旧目标文件。

　　⑥、重新【Build】整个测试程序。

　　2、查看代码是否被排除在采集范围外

　　①、打开缺少覆盖率信息的【源文件】。

　　②、搜索【#pragma ghs startnocoverage】。

　　③、继续检查对应的【#pragma ghs endnocoverage】。

　　④、确认目标函数是否处于排除区间。

　　⑤、按项目要求调整后重新构建。

　　Green Hills允许按函数关闭覆盖率插桩，所以源码正常执行，并不代表Profiler一定会留下这部分记录。库代码也不能简单按照应用源码的覆盖方式来判断。

　　3、确认覆盖数据已经完整转储

　　①、运行完整的【测试用例】。

　　②、回到【MULTI Debugger】。

　　③、停止当前被测【Task】。

　　④、打开【Profile】窗口。

　　⑤、执行【Dump Profiling Info】。

　　⑥、完成后点击【Process Data】。

　　⑦、重新查看【Coverage】结果。

　　目标程序长期运行、不调用正常退出流程时，采集缓冲区里的数据可能还停留在目标端。这类情况看上去像“缺数据”，其实是本次记录还没有完整送出来。

　　4、检查目标Task或AddressSpace是否选错

　　Profiler查看的对象如果和测试时运行的任务不一致，结果也会显得残缺。

　　①、在【Debugger Target】中查看当前任务列表。

　　②、找到本次测试实际运行的【Task】或【AddressSpace】。

　　③、关闭之前打开的【Profile】窗口。

　　④、重新选择正确的调试对象。

　　⑤、再次打开【View】→【Profile】。

　　⑥、载入并处理对应的覆盖率数据。

　　5、排除构建版本和测试程序不一致

　　①、确认Debugger当前加载的【Program】路径。

　　②、查看刚刚生成的【可执行文件】时间和工程位置。

　　③、核对测试板上运行的程序版本。

　　④、删除旧的【Profile Data】或弃用本次无效记录。

　　⑤、重新下载当前【Program】。

　　⑥、重新执行测试并采集数据。

　　三、Green Hills代码覆盖率结果怎么复核

　　覆盖率报告出来以后，还要分清“没有数据”和“确实没有执行”。如果只盯着百分比，很容易错过编译排除、测试范围不同这些情况。

　　1、把未覆盖代码和测试场景对起来

　　先看未执行位置属于什么逻辑，再判断是否需要补测试。有些错误处理、超时和异常分支本来就需要单独构造条件才能进入。

　　①、在【Coverage View】中定位未覆盖源码。

　　②、查看所属【Function】和判断分支。

　　③、找到对应的【Test Case】。

　　④、补充能够触发该路径的输入条件。

　　⑤、重新运行测试并处理【Profile Data】。

　　⑥、再次查看【Coverage】变化。

　　2、保存能够重复核对的数据

　　①、保留当前测试使用的【Program】。

　　②、保存对应的【Profile Data】。

　　③、记录【Block Coverage】模式。

　　④、整理本轮使用的【Test Case】。

　　⑤、保存覆盖率结果或相关报告。

　　同一个工程后面改过代码再重新测试时，这些记录能把两轮结果对应起来，也能判断覆盖变化究竟来自代码修改，还是采集条件发生了变化。

　　总结

　　Green Hills代码覆盖率比较适合拿来检查测试路径有没有遗漏，但看到数据少了一块时，不能马上把问题归到测试用例上。工程有没有打开覆盖率、源码有没有被排除、目标数据有没有完整转储，以及Profiler选中的任务对不对，都会改变看到的结果。把这些环节核清楚以后，再去补没有走到的分支，覆盖率数据才更有参考意义。平时把测试程序、采集模式和对应结果一起留档，后面比较不同版本时也省得重新猜当时的测试条件。