㈠ 编程实现代码覆盖率及路径分析检测，C++, C#, Java, JavaScript（任选一种程序语言）
如果你采用源码插装的方式来做的话，需要对输入程序进行词法，语法分析建立语法分析树（有一些现成的工具如bison, antlr可以借助），通过语分析法分析树获取程序控制流关系，然后就可以对程序的基本块进行分析了。要考虑获取覆盖率和程序执行路径，需要对基本块做插装，利用插入的探针来对它们的执行情况做记录。
㈡ 为什么用例跑的越多,代码覆盖率反而越低
每个人都认为更高的覆盖率总是最好的。然而,我相信很多情况下代码覆盖率与好坏是不相关的。
人们想要高代码覆盖率…但是,为了达到80%或更高的代码覆盖率,结果经常是盲目地执行代码。这就像要求一个钢琴家100%地敲击每个琴键而不是按照一段音乐的需要合适地进行弹奏。当音乐家弹奏音乐的时候,无论琴键的覆盖率是多少,都是有意义的。
另一个问题是,当代码覆盖率超过一定水平(约70%以上),测试套件的维护变得越来越困难。你经常会有非常精细粒度的断言,而且这些断言对于代码的改变非常敏感。因此,每天将会报告出许多需要处理的断言失败——但是这些断言失败通常不会提醒任何重大的改变。
许多人问我,能否得到100%的代码覆盖率。答案是肯定的…不过不用担心代码覆盖率,除非你被要求演示100%的代码覆盖率。
回到前面的比喻,当曲谱里所有的音符都覆盖到了,钢琴协奏曲才算是完整的。当每一个用例都被覆盖到,测试套件才算是完整的。
㈢ web前端方向的同僚们来看看javascript css覆盖率测试问题
1.启用gzip压缩盯着先；
2.压缩代码，如利用jsmin等工具压缩这些文本文件；
3.对于你说的，应该是你整站只用一个css文件一个js文件造成的，你可以利用其它方式来加载代码，如：
每个页面都是 一个公用的css代码文件+一个针对当前页面的css代码，这样可以将代码高效利用起来；
如果你是用jquery库或者其它着名的JS库的话，你可以考虑CDN。
㈣ 代码覆盖率应该达到多少为好
代码覆盖率代表你给的激励将所有的条件组合都触发了一遍，并不检查功能。所有即时100%代码覆盖率，也不能保证代码没有问题，这这测试只能是参考。假设你的条件写得不完整，即使代码覆盖率100%，也还是有功能问题
㈤ java web怎么用emma进行代码覆盖率测试
使用 emma 2.1 (emma-stable-2.1.5320-lib) 1. 新建 /home/q/java/emmalib 目录， 将emma.jar 与 emma_ant.jar 放入 2. 复制 /server/bin/mobileserver/runServer.sh 到 runServer_emma.sh 修改启动语句。
使用 emma 2.1 (emma-stable-2.1.5320-lib)
1. 新建 /home/q/java/emmalib 目录， 将emma.jar 与 emma_ant.jar 放入
2. 复制 /server/bin/mobileserver/runServer.sh 到 runServer_emma.sh
修改启动语句
nohup java -Xmx1800M -Xms800m -Xbootclasspath/p:/home/q/java/emmalib/emma.jar -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider -XX:+AggressiveOpts -XX:+UseParallelGC -server -classpath "$jarFile" com.qunar.common.mobileArc.MobileServer conf/TaLog.property conf/TripServer.property >> $LOG_HOME/error.log 2>&1 &
复制 /server/bin/mobileserver/stopServer.sh 到 stopServer_emma.sh
添加覆盖率导出命令
插入 emma 统计代码
使用root账号
1. 备份mobileserver.jar
cp /server/TripAssistant/mobile-server.jar $MOB_JAR_BAK/mobile-server.jar.{$timestamp}
2. 执行插入命令
java -cp /home/q/java/emmalib/emma.jar emma instr -m overwrite -cp mobile-server.jar -out coverage.em
输出如下：
EMMA: processing instrumentation path ...
EMMA: instrumentation path processed in 3117 ms
EMMA: [1000 class(es) instrumented, 126 resource(s) copied]
EMMA: metadata merged into [/server/TripAssistant/coverage.em]
3. 运行mobileserver runServer_emma.sh
sudo sh /server/bin/mobileserver/stopServer.sh && sudo sh /server/bin/mobileserver/runServer_emma.sh
在 /server/mobileserverlog/error.log中可见：
EMMA: collecting runtime coverage data ...
EMMA: runtime controller started on port [47653]
emma control 进程已启动
[[email protected] /server/mobileserverlog]# netstat -na | grep 47653
tcp 0 0 0.0.0.0:47653 0.0.0.0:* LISTEN 20926/java
4. 执行 覆盖率文件导出命令
java -cp /home/q/java/emmalib/emma.jar emma ctl -connect localhost:47653 -command coverage.get,coverage.ec
可见输出：
EMMA: processing control command sequence ...
EMMA: executing [coverage.get (coverage.ec,true,true)] ...
EMMA: coverage.get: local of coverage data merged into [/server/TripAssistant/coverage.ec]
EMMA: coverage.get: command completed in 79 ms
EMMA: control command sequence complete
并且当前目录生成文件 coverage.ec
5. 生成报告
java -cp /home/q/java/emmalib/emma.jar emma report -r html -in coverage.em,coverage.ec
指定源代码生产覆盖率报告(需先上传源码)
java -cp /home/q/java/emmalib/emma.jar emma report -r html -in /server/TripAssistant/coverage.em,/server/TripAssistant/coverage.ec -Dreport.html.out.file=mycoverage/coverage.html -sp /home/liang.zhou/mob_code_dir/mobs_trunk/src/main/java
emma 方式启动 mobserver
==================================
1. 判断mobserver.jar size， 大于5M 为已插入过， 小于5M为未插入(需要执行插入)
2. 执行插入
3. 启动
4. 检查启动状态
47653 端口打开
mobileserver 进程打开
emma 方式停止 mobserver
==================================
1. 检查47653端口打开状态, 检查coverage.em是否存在
2. 导出覆盖率文件 coverage.ec, 备份coverage.em (加上时间戳)
3. 导出覆盖率HTML report (加上对应时间戳)
4. kill mobserver 进程
ls -lt mobile-server.jar
判断 $? == 0
判断mobile-server.jar size是否大于 5M
#!/bin/bash
function stop_mob_server(){
#!/bin/bash
function stop_mob_server(){
pid=`ps aux | grep MobileServer | grep -v grep | awk '
Unknown macro: {print $2}
'`
` kill -9 $
Unknown macro: {pid}
`
sleep 1
echo "Stop mobileserver success."
}
#判断 emma ctl 是否启动
port_check_result=`netstat -na | grep 47653 | awk '
Unknown macro: {print $1}
'`
if [ -z $
Unknown macro: {port_check_result}
]; then
echo "Emma ctl port 47653 is not LISTEN. Coverage.ec export operation aborted."
else
#emma ctl 为启动状态，导出 coverage.ec, 并备份至 /home/q/mobsrv_cov
if []
fi
㈥ 如何：获取代码覆盖率数据
可以按逐行代码甚或逐个代码块的形式衡量测试的有效性。可以通过配置测试运行以产生代码覆盖率数据来做到这一点。得到的数据显示在“代码覆盖率结果”窗口和源代码文件中。
当对项目（通常为二进制文件）进行了检测，并在测试运行期间将其加载到了内存中时，就会收集代码覆盖率数据。获取代码覆盖率数据过程介绍了如何选择要检测的文件。
注意默认情况下，在运行单元测试时测量代码覆盖率。因此，在运行单元测试时，只有在已关闭代码覆盖率数据收集功能，或者当您希望对其他项目进行检测以收集它们的代码覆盖率数据时，才需要执行获取代码覆盖率数据中的步骤。测试运行完成后，即可查看代码覆盖率数据；有关更多信息，请参见查看代码覆盖率数据。
还可以合并多组代码覆盖率数据，如如何：合并代码覆盖率数据中所述。有关与合并代码覆盖率数据有关的各种情况的信息，请参见使用合并的代码覆盖率数据。如对程序集进行检测和重新签名中所述，必须对经过检测的具有强名称的程序集进行重新签名。指定密钥文件即可启用重新签名。有关更多信息，请参见重新签名程序集。
必须显式地对项目进行检测，只有这样，才能在您运行单元测试之外的其他测试时获取代码覆盖率数据。例如，某个运行手动测试的测试人员可能会启动一个特殊的程序。如果这个程序的二进制文件经过了检测，则将收集代码覆盖率数据。有关更多信息，请参见手动测试概述。
获取代码覆盖率数据获取代码覆盖率数据创建代码测试。这些测试既可以是单元测试，也可以是其他测试类型（它们执行您已为其设置了符号并且已为其选择了要检测的适当二进制文件的代码）。有关如何创建单元测试的信息，请参见
如何：生成单元测试。
打开将用于单元测试的测试运行配置。
有关更多信息，请参见如何：指定测试运行配置。单击“代码覆盖率”。在“选择要检测的项目”下，选择解决方案的
DLL、可执行文件或目录。例如，如果解决方案的名称为
ClassLibrary1，则选择名为
ClassLibrary1.dll、路径为
<Solution
Directory>\ClassLibrary1\bin\Debug
的程序集所对应的复选框。注意也可以选择包含测试项目文件的
DLL。这将为测试项目中的方法（而不仅仅是生产代码中的方法）生成代码覆盖率数据。
单击“应用”，再单击“关闭”。运行一个或多个测试。
有关更多信息，请参见如何：运行选定的测试。在运行测试时，会收集代码覆盖率数据。有关查看数据的更多信息，请参见查看代码覆盖率数据。
注意运行VSPerfMon.exe
可以与代码覆盖率数据的集合进行交互。有关更多信息，请参见
Team
Edition
for
Testers
疑难解答中的“代码覆盖率数据和
VSPerfMon.exe”部分。无法为运行在
64
位进程中的应用程序收集代码覆盖率数据。因此，如果您在测试此类应用程序时请求了代码覆盖率数据，则测试引擎会在要检测的程序集的可移植可执行
(PE)
标头中设置“32BIT”标志。测试运行完成后，程序集会恢复到其原始状态。重新签名程序集重新签名程序集打开将用于单元测试的测试运行配置。
有关更多信息，请参见如何：指定测试运行配置。单击“代码覆盖率”。单击“用于重新签名的密钥文件”文本框旁边的省略号
(…)。将显示“选择一个密钥文件”对话框。选择一个密钥文件，然后单击“打开”。在测试运行配置编辑器中，单击“应用”，再单击“关闭”。
如果您要测试多个已签名的程序集，Visual
Studio
会尝试重新签名使用您指定的密钥文件签名的所有具有强名称的程序集。有关更多信息，请参见对程序集进行检测和重新签名中的“重新签名程序集”。
查看代码覆盖率数据先决条件：已经运行已生成代码覆盖率数据的测试，如获取代码覆盖率数据中所述。
查看代码覆盖率数据在“测试结果”工具栏上，单击“代码覆盖率结果”。或者，也可以单击“测试”菜单上的“窗口”，然后单击“代码覆盖率结果”。
将打开“代码覆盖率结果”窗口。
在“代码覆盖率结果”窗口中，“层次结构”列显示一个节点，其中包含有在上一次测试运行中获取的所有代码覆盖率数据。如果发生了错误，则在此位置（而非根节点中）显示错误信息。如果显示有节点，请将其展开。注意默认情况下，该测试运行节点采用
<用户名>@<计算机名>
<日期>
<时间>
的格式命名。可以在“选项”对话框的“常规”页上更改默认命名方案。有关更多信息，请参见如何：指定测试运行配置。依次展开程序集、命名空间和成品代码中某个类的节点。
类中的各行表示类的方法。此表中的列显示了各个方法、类和整个命名空间的覆盖率统计数据。
双击类中的一个方法所对应的行。
将打开源代码文件并转到您选择的方法。在此文件中，可以看到代码突出显示效果。通过滚动，可以看到此文件中其他方法的覆盖率。要更改代码行的突出显示颜色，请参见更改代码覆盖率数据的显示。注意可以单击“测试工具”工具栏上的按钮以切换文件中代码覆盖率的显示，以及导航到文件中前面的或后面的代码行。
（可选）如果选中了测试项目的
DLL
所对应的复选框，则可以打开包含单元测试的源代码文件，以查看执行了哪些测试方法。
更改代码覆盖率数据的显示默认情况下，将使用特定的颜色来指示代码是否被已运行的测试覆盖了。用浅蓝色突出显示的代码行已在测试运行中执行过，而用红褐色突出显示的代码行则还没有执行过。在用米色突出显示的代码行内，有些代码已执行过，有些代码则还没有。
更改代码覆盖率数据的显示单击“工具”，然后单击“选项”。将显示“选项”对话框。
展开“环境”。单击“字体和颜色”。
在“显示其设置”下，选择“文本编辑器”。在“显示项”下，选择要更改其显示颜色的代码覆盖率区域。可用的选项有“覆盖率未涉及的区域”、“覆盖率部分涉及的区域”和“覆盖率涉及的区域”。更改此代码覆盖率区域的设置。可以更改前景色和背景色、字体、字号和文本的粗体设置。（可选）更改其他代码覆盖率区域的设置。
完成上述操作后，单击“确定”。
㈦ 代码覆盖率是个什么概念
代码覆盖率是软件测试中的描述程序中源代码被测试的比例和程度。代码覆盖是由系统化软件测试所衍生的方式，是飞行设备进行安全认证中的考量项目之一。
基本的代码覆盖率准则有函式覆盖率、指令覆盖率、判断覆盖率、条件覆盖率、条件/判断覆盖率。函式覆盖率呼叫到程式中的每一个函式；指令覆盖率用控制流图表示程式，执行到控制流图中的每一个节点；判断覆盖率用控制流图表示程式，执行到控制流图中逻辑运算式成立及不成立的情形。
(7)h5前端代码覆盖率扩展阅读：
代码覆盖的测试
基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。
控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。
㈧ 覆盖率结果显示为html源码，怎么解决
关于代码覆盖率，之前6年的工作经历中，只是依稀听闻过。之前的组织里，从未关注过这个指标，只是有一段时间用NUnit做了单元测试，主要是测试一些关键类关键方法是否正常，对代码覆盖率的印象就真的一直是停留在听闻的程度。汗一个!
前些时日，关于自动测试的讨论中有人提及到代码覆盖率，激发了我的好奇，到底什么是代码覆盖率?最重要的是于测试工作而言有怎样的价值呢?今天花了一点时间查了一下，有了初步的认识。大致归纳如下：
一、基本概念
代码覆盖率是单元测试活动任务之一;
覆盖率分语句覆盖率(即通常所说的行覆盖率)和分支覆盖率。
二、价值
代码覆盖率的分析能在一定程度上评判代码质量，一般覆盖率高的代码出错的几率会相对低一些。但是高覆盖率只是表示执行了很多的代码，并不意味着这些代码被很好地执行了。所以，似乎覆盖率测试结果出来并不能帮我准确的评价代码质量。那么我们为什么要做覆盖率测试呢?如何让它给我们带来价值呢?
1. 尽早评估代码质量
比如在开发的过程中，定时的去看整个项目的代码覆盖率，监控覆盖报告可以帮助开发团队迅速找出不断增长的但是没有相应测试的代码。例如，在一周开始时运行覆盖报告，显示项目中一个关键的软件包的覆盖率是 70%。如果几天后，覆盖率下降到了 60%，那么您可以推断：软件包的代码行增加了，但是没有为新代码编写相应的测试(或者是新增加的测试不能有效地覆盖新代码)。能够监控事情的发展，无疑是件好事。定期地查阅报告使得设定目标(例如获得覆盖率、维护代码行的测试案例的比例等)并监控事情的发展变得更为容易。如果您发现测试没有如期编写，您可以提前采取一些行动，例如对开发人员进行培训、指导或帮助。
2. 为功能测试关注点提供情报
假设覆盖报告在指出没有经过足够测试的代码部分方面非常有效，那么质量保证人员可以使用这些数据来评定与功能测试有关的关注区域，可以更有针对性地加强这些区域的测试，因为没有被测试代码覆盖到的区域，出错的几率应该相对更高。
3. 估计修改已有代码所需的时间
对一个开发团队而言，针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比，经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何工作的，所以还可以充当内行的文档。在另一方面，没有经过相应测试的代码更难于理解和安全地修改。因此，知道代码有没有被测试，并看看实际的测试覆盖数值，可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。
当然，这样的理解还是比较浅层的，我想实际应用中除了以上三点之外，还有一个很重要的工作就是提高测试代码的质量来更好的体现代码覆盖率的价值。