㈠ 編程實現代碼覆蓋率及路徑分析檢測，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. 估計修改已有代碼所需的時間
對一個開發團隊而言，針對代碼編寫測試案例自然可以增加集體的信心。與沒有相應測試案例的代碼相比，經過測試的代碼更容易重構、維護和增強。測試案例因為暗示了代碼在測試工作中是如何工作的，所以還可以充當內行的文檔。在另一方面，沒有經過相應測試的代碼更難於理解和安全地修改。因此，知道代碼有沒有被測試，並看看實際的測試覆蓋數值，可以讓開發人員和管理人員更准確地預知修改已有代碼所需的時間。
當然，這樣的理解還是比較淺層的，我想實際應用中除了以上三點之外，還有一個很重要的工作就是提高測試代碼的質量來更好的體現代碼覆蓋率的價值。