圖 6. 測試用例跟蹤的框架圖
從上圖我們可以看出，測試人員觸發 Trigger 之后，會啟動 Agent Controller 。 Agent Controller 一直對 JVM 中的 JVMTI 進行監聽，以獲取部署在 JVM 上的被測應用程序。這些 Agent Controller 還負責將收集到的數據傳輸給 Data Collector 。又 Data Collector 將這些 Runtime Trace 寫入如下表所示的數據庫表中。
| Case ID | Package | Class | Method | Signature |
| 001 | com.ibm.crl.orts.action | DeleteCommodityAction | Delete | ([Ljava/lang/String;)V |
| 001 | com.ibm.crl.orts.action | DeleteOrderAction | Delete | |
| 002 | ...... | |||
| 003 | ...... | ...... | ...... | ...... |
注意：函數的 Signature 信息作為函數的參數標識也需要記錄下來。以區別同名不同參數的函數
步驟二， Change Analysis 用于將新舊兩個版本作比較，得到 Change Report，即程序變更報告，可以精確到 Method 粒度。一般來說代碼變更有 4 種級別，分別為包級別 (Package)，類級別 (Class)，函數級別 (Method) 及語句級別 (Statement) 。
對于包級別和類級別來說，比較的力度過粗，會影響到回歸測試優化的質量。而函數級別和語句級別都能起到很好的回歸測試的作用。其中語句級別因為粒度最細，等到的分析結果也最精確，回歸測試質量最高。但與函數級別的變更分析相比，回歸測試的質量相差很有限，但造成了過多的執行時間代價，影響了回歸分析的效率。因此我們采用函數級別的變更分析作為回歸測試的變更粒度。
確定比較粒度之后，可以選擇分析比較的方法。最簡單的常用比較方法就是文本比較。包括源代碼和可執行文件 (binary code) 的文本比較。根據 Java 語言面向對象的特點，還可以采用基于面向對象分析的比較方法。后者得到的分析粒度更細，但是所花的代價也越高。
步驟三， 在通過測試用例錄制得到測試用例具體的 Runtime Trace 信息，以及通過 Change 分析得到新舊兩個版本的變更信息之后，我們可以對測試用例優化問題及覆蓋率分析問題進行求解。
Test Case Prioritization 中，通過測試用例與運行的 Runtime Trace 進行匹配得到相關的測試用例。并利用測試用例優化排序算法對相關的測試用例進行排序，得到優化結果�，F在的優化排序算法有多種，這里不對優化排序算法進行討論。
Coverage Analysis 中，通過對已被相關測試用例覆蓋的 Method 數量，及未被測試用例覆蓋到的 Method 數量的分析，可以得到基于代碼更新的覆蓋率報告。測試人員得到這份報告之后，可以找到未被覆蓋到的 Method，并對其進行針對性的開發新的測試用例。以完成對新功能的覆蓋。
我們可以看到步驟一，二共同服務于測試用例優化選擇和覆蓋率分析兩個模塊。有了測試用例的 Runtime Trace 和 Change Report. 我們可以將 Change 結果與 Runtime Trace 進行匹配，找出能覆蓋程序更改的測試用例。同樣，對于沒有被測試用例覆蓋到的 Change 部分。由于沒有相關測試用例被找出，我們現有的測試用例是不足的，需要針對未被覆蓋到的 Change 部分開發新的測試用例。
而覆蓋率作為軟件測試的一項重要指標，可以根據已經得到覆蓋和未被覆蓋的 method 進行求解，即已得到覆蓋的 change method 數與總的 change method 之比。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
