摘要
測試和調試是軟件開發生命週期中最昂貴也最容易出錯的階段。自動化軟件測試以及軟件診斷技術可以大大提高測試和調試階段的工作效率，從而提高軟件的整體質量。在本文中，作者提供了一個可以進行自動測試和故障定位的工具集，稱為 GZoltar。該工具集包含了最小化（迴歸）測試套件和自動故障診斷（即基於頻譜的缺陷定位）的相關技術，提供了能夠對軟件程序源代碼進行自動插樁、並生成運行時數據的基礎結構。這些數據將在隨後的工作階段中被分析，主要用於最小化測試套件和返回診斷候選者的排名列表。為了方便全世界的使用者，該工具集被實現為一個可以即插即用的 Eclipse IDE 插件，
關鍵詞：Eclipse 插件；自動化測試；自動化調試；GZOLTAR；RZOLTAR
1 測試與調試
測試和調試是軟件開發生命週期中一個重要而又最昂貴且乏味的階段。儘管簡化測試和調試任務的框架已經出現，但這些框架往往不能提供足夠的功能以支持測試和調試階段的完全自動化。廣為人知的（單元）測試框架——如 JUnit，TestNG 和 JTest——雖然可以自動地執行測試，但並不能利用某些指標（例如覆蓋率）最小化測試套件；現存的幾種調試工具則大都在程序單步走查（例如，GDB 和 DDD）的基礎上進行程序調試，而這些傳統的手工缺陷定位技術往往存在著諸多限制。設置輸出語句，並審查對應的輸出，這些調試手段都屬於非結構化的臨時性操作，通常需要依賴開發人員自身的直覺；此外，軟件開發人員通常只關注那些能夠暴露軟件錯誤的測試用例，因而往往會忽略測試通過的測試用例反饋的有價值的信息。
近年來，科研人員在開發自動化測試或自動化缺陷定位技術和工具方面投入了大量精力，其主要目標為了大幅度降低測試和調試的成本。就軟件測試來說，幾項相關的軟件測試技術已經出現。這些技術可以在保證原有代碼覆蓋率不變的情況下，對已有的測試用例進行最小化或優先排序操作，以減少測試套件執行時間，同時提高錯誤檢測效果。本文提出了一個名為 GZoltar 的工具集，該工具集提供了一種可以縮減測試套件、確定測試優先級的技術。該技術採用了一種基於約束的新穎方法，能夠在保證代碼覆蓋率不變的情況下實現原始測試套件最小化。此外，該技術允許用戶通過基數和計算得出的測試執行時間來考慮如何對測試套件進行優先排序或最小化。至於軟件調試，基於黑盒統計的方法是目前最為主流的方法之一。該方法主要利用了待測程序和可用測試用例，通過分析測試用例的執行結果，返回待測程序中最有可能出錯的位置（組件），並進一步找出測試用例未通過的原因。
GZoltar 工具集實現了一種基於頻譜的缺陷定位的技術 (SFL, Spectrum-based Fault Localization)。SFL 能夠通過插樁技術來對程序中正在運行的部分進行追蹤。工具集將分析插樁信息，並生成一個包含源代碼位置的列表。該列表按照源代碼中出現問題的可能性大小對代碼行進行從高到低的排序。此外，GZoltar 工具集還可以設置程序的預期行為的方式來對程序進行訓練，從而能夠在工具觀察到非預期行為時自動進行錯誤檢測。由於不需要預先掃描程序以獲取可能的錯誤位置，現存的軟件測試工具和軟件調試工具可以有效地將 GZoltar 工具集拓展到自身的工作流程中。
2 GZOLTAR 工具套件
GZoltar 是一個 Eclipse 插件，它使用最新的基於頻譜的缺陷定位算法生成準確的缺陷定位信息，並提供迴歸測試領域的最新技術。GZoltar 還可以創建可視化的交互式診斷報告，例如 Treemap 圖和 Sunburst 圖（如 2.3 節圖 3 所示）。
GZoltar 與 Eclipse（最受歡迎的 IDE 之一）的集成非常實用。GZoltar 使用 Eclipse 的標準功能（例如 Eclipse 檢測工作區中的項目結構的功能）來構建被測系統(SUT, System Under Test)的結構，以供可視化視圖使用的。 此外，GZoltar 還將良好的代碼編輯器和標準的 Eclipse 警告生成機制與可視化診斷報告集成在一起，大大簡化了整個調試過程。
GZoltar 可以幫助開發人員更快地發現故障，從而減少了測試和調試階段所需時間和資源。這在提高了的軟件的可靠性等級的同時可能縮短一定的軟件測試周期，從而能夠顯著降低軟件開發的成本。
2.1 GZoltar 架構
圖 1：GZoltar 圖層；GZoltar 與其他技術之間的集成關係。
GZoltar 主要用 Java 編寫，同時也使用了一些第三方開源程序。 在 GZoltar 架構體系中，Eclipse 的 Workspace 組件用於整合工具所需信息，例如打開項目並從項目目錄下類和 JUnit 測試中搜集信息；ASM 是一個 Java 字節碼工程庫，用來掃描 SUT 以便 GZoltar 能夠在項目使用 JUnit 執行單元測試時跟蹤到測試覆蓋率；Eclipse 的 Workbench 組件用於生成 Eclipse 用戶界面（UI），包含了用於創建 GZoltar 視圖的標準窗口部件工具集(SWT, Standard Widget Toolkit)，並提供了與抽象窗體工具集(AWT, Abstract Windows Toolkit)關聯的橋樑；JOGL(Java OpenGL)則用於生成基於 OpenGL 的可視化信息，並展示在 GZoltar 視圖中。
集成在 GZoltar 插件中的 MINION 約束求解器是由 C 編寫的；同時 TRIE 結構也是由 C 語言實現，但是具備一個 Java 編寫的接口。這樣做的是為了提高組件的工作效率。關於這些技術層的組織層次及相互作用關係請參見圖 1。
2.2 Gzoltar 工作流
GZoltar 工作流程可以分為八個主要階段（參見圖 2）：
圖 2：信息流
Eclipse 的初始化集成：Eclipse 幫助 GZoltar 檢測 IDE 中所有打開的項目。一旦在 IDE 中打開項目，GZoltar 就會掃描項目，併為其所有類和 JUnit 測試類（具有用 JUnit 語法編寫的測試方法的類，這些類會在後面的階段執行）建立索引。為了避免源文件和編譯產生的字節碼存在差異，GZoltar 這時會強制 Eclipse 再次對打開的項目進行構建，以確保字節碼文件與當前源文件語義一致。
JUnit 和 ASM：每個項目有一個記錄了所有測試類的列表。對於項目中的每個類，工具將對類的代碼進行插樁以方便代碼覆蓋流程。該過程的主要目的是要判定類中某一行代碼是否已被執行。GZoltar 使用 ASM 對所有打開的項目進行插樁，從而能夠通過調試得知有哪些項目調用了其他項目的方法。隨後，工具將自動執行以 JUnit 語法實現的測試類。
測試用例的執行情況也將被工具保存下來，以供 RZoltar（顯示測試是否失敗的視圖）和 GZoltar（計算並顯示診斷報告的視圖）使用。測試用例的執行結果將保存到一個二維覆蓋矩陣(Coverage Martrix)中。假設覆蓋矩陣 A 是一個 N×M 的二維矩陣，那麼 N 代表的就是測試用例的執行個數，M 則對應（被測）軟件程序中的若干組件，那麼 aij 則表示組件 j 在執行測試用例 i 時的覆蓋率。覆蓋矩陣收集完畢後，RZoltar 會對矩陣進行分析，以進行測試套件的最小化。
關於 SUT 中每個測試用例代碼覆蓋信息的蒐集過程分為以下三步：（1）插樁代碼，用於記錄執行測試用例時到達的語句（2）執行測試並（3）計算覆蓋軌跡（即哪些語句在本次測試中被執行到了），並將覆蓋軌跡添加到覆蓋矩陣中去。
總的來說，在本階段工具將對 IDE 中打開的所有項目進行插樁和構建；項目中的所有測試類也將被執行；覆蓋矩陣（以及其他相關信息）將會被存儲以服務之後的工作。
MINION：將 SUT 的覆蓋信息收集到之前提到的覆蓋矩陣之後，工具將會把覆蓋信息傳遞給約束求解器，並最終返回至少一個——能夠像原始測試集一樣——覆蓋整個軟件程序的最小測試集。
篩選解決方案：利用 TRIE 數據結構，約束求解提供的結果會在這個階段得到篩選。此階段本質上是將獲取的非最小測試集合從結果集中剔除。
顯示解決方案：在此階段，用戶可以選擇一個約簡後的測試集並重新執行測試；也可以通過基數和執行時間對所有測試子集進行排序。
運行 Ochiai：在此階段，GZoltar 執行 SFL 算法 Ochiai（該算法被認為是性能最好的缺陷定位技術之一）進行缺陷定位。 基於所有 JUnit 測試結果，GZoltar 將為系統的每個元素計算 Ochiai 相似係數。
圖形可視化：為了執行 SUT 的可視化清晰而有效，GZoltar 使用 OpenGL 技術以更好地利用圖形處理單元（GPU）。
警告生成和 Eclipse 收尾集成：GZoltar 插件還將生成警告信息，以告知用戶哪些代碼行存在潛在的錯誤。GZoltar 將警告生成器與代碼編輯器集成在一起，從而可以直接標記可能出現錯誤的代碼行。
在經歷以上所有階段之後，用戶可以對運行失敗的單元測試和以及出錯的代碼行（如果存在的話）進行審查。由於 GZoltar 工作流程是一個遞歸過程，因此在未解決所有故障之前，用戶都可以從運行結果中選取最小測試集並重新進行測試（這樣可以節省測試時間），並在修復部分錯誤並再次重複相同的操作。
2.3 Eclipse 視圖
默認情況下，GZoltar 提供了兩個集成到 Eclipse IDE 中的視圖：GZoltar（圖 3）和 RZoltar（圖 4）。
圖 3：GZoltar 的可視化效果：Treemap 和 Sunburst
圖 4：RZoltar 界面
在分析 SUT 時，用戶只需單擊 GZoltar 視圖上的可視化代碼行，便可直接跳轉到 Eclipse 代碼編輯器中該行對應的位置。此外，GZoltar 還會在代碼編輯器的垂直標尺上生成標記列表。當鼠標在標記上懸停時，界面會顯示出對應的出錯概率。根據顏色不同，這些標記分為三種類型：（1）紅色代表該語句包含錯誤的概率排在前三；（2）黃色代表錯誤概率排在中間的三條語句；（3）綠色代表概率最小的第三條語句。此外，每個標記還內置了 ColorADD2 符號，可以幫助色盲人員區分標記。這些註釋標記也會顯示在 Eclipse“問題”視圖中。
GZoltar 視圖還提供了 Treemap 和 Sunburst 兩種可視化形式，如圖 3 所示。通過這種無縫集成，用戶可以輕鬆分析 SUT 結構，並快速定位軟件錯誤的源頭。GZoltar 提供了一種可以使開發人員直接訪問源代碼並修復錯誤的簡便技術。
RZoltar 視圖（圖 4）分為兩層。在左側視圖中，用戶可以看到 RZoltar 提供的最小覆蓋範圍列表（這個列表也包括原生測試套件，考慮到用戶可能需要重新執行所有測試）並且可以生茶測試用例的執行結果（通過，失敗或錯誤）。如果測試失敗或返回錯誤，RZoltar 則會在右側“跟蹤”窗口中將錯誤消息顯示出來。用戶可以在任意圖層中雙擊測試用例以跳轉至對應測試用例文件，也可以在“跟蹤”窗口處雙擊跟蹤鏈以進入對應的行。這項功能有些類似於 JUnit 提供的功能。RZoltar 視圖給出了用於對測試進行優先排序的兩個指標：基數和運行時間。後者按照再運行的時間由短到長對所有最小化測試集合進行排序；前者則通過測試集中包含的測試用例個數進行從小到大排序。
致謝
本文由南京大學軟件學院 2020 級碩士生錢瑞祥翻譯轉述。
感謝國家重點研發計劃（2018YFB1003900）和國家自然科學基金（61832009，61932012）支持！
閱讀更多 慕測科技 的文章
