1 引用

Tomassi D A, Dmeiri N, Wang Y, et al. Bugswarm: mining and continuously growing a dataset of reproducible failures and fixes[C]//2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019: 339-349.

2. 摘要

錯誤檢測，定位和修復技術對軟件質量保障來說至關重要，但是目前很難評估它們的擴展性、適用性以及有效性。大型、多樣化、真實的數據集上持久且可復現的缺陷與修復，對軟件質量技術的實驗評估來說至關重要，但是收集和維護它們往往非常困難且代價高昂。這樣的現代持續集成(Continuous Integration，CI)方法(如 TRAVIS-CI)被廣泛使用，它們是高度可配置的并且可以在定制容器內執行，使得我們有望向更大的缺陷數據集邁進。如果我們能夠識別并存檔相關失敗和隨后成功的測試，這些容器將為構建和測試的可復現提供保證。但是上述技術還需要克服一些局限性才能具有一定的實際價值。針對真實開源的軟件系統，我們提出了工具 BUGSWARM，它可以創建一系列可擴展的，多樣化的，真實的，持續增長的一組可復現的失敗和成功版本。BUGSWARM 已經為 Java 和 Python 語言收集了 3,091 個失敗-通過版本對，同時均包裝在完全可復現的容器中。此外，該工具可以定期運行以檢測失敗-通過活動，從而不斷增擴增們的數據集。

3 引言

軟件缺陷對社會經濟，出行安全和生活質量具有重要的影響。缺陷的識別和修復則會耗費大量時間和經濟成本；而通過研究已有的缺陷及其修復方法，可以在新版本中更有效地處理甚至避免缺陷。一些軟件工程子領域(如程序分析，測試和自動程序修復)專用于開發工具、模型以及方法來尋找并修復缺陷。理想情況下這些技術應在真實的最新缺陷數據集上評估，以便用戶更好地了解其運行表現。這些數據集應包含失敗通過對，具體分為失敗的版本(可能包括觸發程序失效的測試集)和通過的版本(包括修復缺陷的修改)。以此研究人員可以深入地評估缺陷檢測技術，缺陷定位(靜態或動態)技術以及缺陷修復技術的有效性。因此研究進展與包含失敗成功對的高質量數據集密切相關。

對于那些包含失敗成功對的數據集有以下幾種可取的屬性。(1)可擴展性：需要足夠的數據以支撐工具評估統計意義；(2)多樣性：數據的可變性足以控制諸如項目規模、成熟度、領域、語言、缺陷嚴重性、年齡等因素，同時仍保留足夠的樣本量進行充分的實驗；(3)真實性：能反映程序員修復實際錯誤的真實修復操作。(4)實時性：不斷更新的缺陷數據集，與語言、平臺、庫、軟件功能等方面的變更保持同步，以便根據當前關注的領域和相關的缺陷來評估工具。(5)可復現性，缺陷數據應具有持久的可復現性：應以支持持久構建和行為復現的方式保存缺陷數據。

一些人工匯總的數據集(如西門子測試集、SIR 存儲庫、Defects4J)提供了軟件制品集合，以支持程序分析和測試技術的受控實驗。但是這些數據是人工分析策劃的，而且在規模和多樣性上都非常有限；而另外一些小型的學生作業，可能無法反映真實的技術表現。其中一些存儲庫通常通過手動植入缺陷來生成故障，而來自現實程序員的程序錯誤會提供更加真實的表現。但是除非通過持續不斷且昂貴的人工勞動來保持數據集的擴增，否則難以保證實時性。最后如果它們依賴于特定版本的庫和操作系統，則它們之后的可復現性無法保證。

上述討論的數據集極大地促進了軟件工程的研究進展，在數據的收集、分析和處理方面具有一系列的創新。但是，我們認為規模更大，多樣性，真實性，實時性和持久性更高的數據集將帶來更大的進步。在不犧牲實驗效力的情況下控制協變量將幫助工具構建者和實證研究人員以更高的洞察力，外部有效性和時間穩定性獲得結果。但是在無需大量人工勞動的情況下，構建更大的缺陷數據集；查找特定的缺陷；并創建可復現的和可運行的失敗和成功軟件版本是很困難的。因為除了分析源代碼，還可能需要收集特定版本的庫，依賴項，操作系統，編譯器和其他工具，這個過程需要較高程度的人工介入。除非以某種方式使這種手動工作自動化，否則我們將無法建立可復現的大規模，多樣化，真實的以及實時的數據集。

我們認為基于云的持續集成(Continuous Integration，CI)中 DevOps 和 OSS 主導的創新是解決上述問題的關鍵。CI 服務(如 TRAVIS-CI)允許將開源項目中的集成測試外包。由于各種原因，OSS 項目則需要進行連續的自動化集成測試。此外如測試驅動開發之類的現代實踐方法導致了自動化測試的大量增加。項目的每項更改都可以在基于云的服務上進行集中且自動的異地測試。這可以跨語言，依賴關系和運行時平臺連續進行。例如，典型的 GitHub 項目要求在審核或合并之前，對每個拉取請求(PR)進行集成測試，并修復缺陷。在進行中的項目中，PR 貢獻者和項目維護者之間的來回協作會在拉取請求歷史記錄和整個項目歷史記錄中創建許多失敗成功對記錄。

完成此功能需要兩項關鍵的技術：高效的、可自定義的基于容器的虛擬化簡化了對復雜依賴性的處理，而腳本化 CI 服務器允許自動化的構建和測試過程。項目維護者創建腳本來定義其項目的測試環境(平臺，依賴項等)；基于云的 CI 服務可以使用這些腳本構建虛擬化的運行時(通常是 Docker 容器)以構建和運行測試。之后對 CI 結果進行存檔以便后期挖掘和分析。我們正是利用這些 CI 數據和技術創建一個自動化的，持續增長的，大規模的，多樣化的，真實且持久的可復現缺陷數據集。

本文我們介紹了 CI 收集工具 BUGSWARM，以及一個持續增長的可復現的大型缺陷數據集。該工具使實時更新性和增加多樣性成為可能。BUGSWARM 利用已歸檔的 CI 日志記錄來創建詳細的工件，包括錯誤代碼版本，失敗的回歸測試集和缺陷修復操作。當找到一對連續的提交時，第一個提交中 CI 日志顯示運行失敗，第二個提交則通過運行，則 BUGSWARM 使用項目的 CI 定制腳本創建制品：完全容器化的虛擬環境，包括版本和腳本，以收集所有必需的工具、依賴項、平臺和操作系統等。BUGSWARM 構件允許完整構建和測試成對的失敗/通過運行。容器化可以持久地復現這些制品。使用 CI 服務的相關項目的規模和多樣性使 BUGSWARM 也可以捕獲大規模的、持續增長的、多樣化且最新的制品。

具體地，我們的貢獻如下：

(1)我們提出一種利用 CI 的方法，該方法可以挖掘開源項目中失敗成功對并嘗試在 DOCKER 容器中自動重現這些對。

(2)我們展示了這些失敗-成功對在開源項目中是常見的，并且討論了復現這些失敗-成功對的挑戰性。

(3)我們提供了 BUGSWARM 數據集，它為 Java 和 Python 提供了 3091 個制品，據我們所知它是最大的，連續擴增的，可持久復現的缺陷數據集。

4. 背景與動機

帶有 CI 服務的現代 OSS 開發提供了一個支持工具和數據支持的生態系統，可以支持 BUGSWARM 的創建。本節我們描述了這個生態系統的相關組成部分，并給出了一個示例。

4.1 開源 CI 生態系統

(1)Git 和 GitHub。Git 對現代軟件開發至關重要。每個項目都有一個存儲庫，其每次更改均通過提交進行，每個提交均具有一個通過具有 SHA-1 哈希派生的唯一標識符。項目歷史記錄是一系列提交。Git 支持分支，主要的開發則通常維護在一個稱為 master 的分支中。GitHub 是托管 Git 存儲庫的基于 Web 的服務。

(2)Travis-CI 持續集成。Travis-CI 是與 Github 集成的、最流行的、基于云的托管 CI 服務。它可以通過自動構建和自動測試自行管理提交。用戶可以通過項目存儲中.travis.yml 文件來配置 Travis，并指定測試項目的所有環境。

(3)Docker。Docker 是一種輕量級虛擬機服務，可提供應用程序隔離、不變性和自定義。用戶可以將應用程序與代碼、運行時、系統工具、庫和 OS 打包成一個不變的、獨立的、定制的、持久的 Docker 映像，并在任何支持的平臺上隨時隨地運行 Docker。2014 年底，Travis-CI 開始在 Docker 容器內運行構建和測試，每次運行都通過 Travis-CI 中的.travis.yml 文件進行自定義。

圖 1 BUGSWARM 生命周期

4.2 挖掘與復現

我們利用 TRAVIS-CI 創建 BUGSWARM。圖 1 描述了 TRAVIS-CI 構建和測試 PR 的生命周期。一個貢獻者復制該存儲庫并進行了三個提交，直到 prV1；然后貢獻者打開 PR，要求將所做的更改合并到原始存儲庫中。PR 的創建會觸發 TRAVIS-CI，同時在打開 PR(prV1 和 baseV1)時檢查 PR 分支和主分支之間是否存在合并沖突。如果沒有，則 TRAVIS-CI 會從基礎分支創建一個臨時分支，PR 分支合并到該分支中以產生 temp1。TRAVIS-CI 然后從.travis.yml 文件生成構建腳本并啟動構建，即運行腳本進行編譯，構建和測試項目。

在我們的示例中，測試失敗會導致第一個構建失敗。TRAVIS-CI 則通知貢獻者和項目維護者，如圖 1 中的虛線箭頭所示。貢獻者進行了修復，并使用新的提交更新 PR。同樣 TRAVIS-CI 在 PR 分支(prV2)和基礎分支(于 baseV1)之間創建合并，以生成 temp2。構建再次失敗，顯然修復失敗。因此貢獻者通過添加新的提交 prV3 來更新 PR。觸發 ATRAVISCI 構建，其中將測試 PR 分支(prV3)和基礎分支(baseV2)之間的合并(temp3)。最終構建通過，PR 被接受并合并到基礎分支中。

5 方法介紹

5.1 術語

項目的構建歷史記錄是指先前觸發的所有 TRAVIS-CI 構建。一個構建可能包含許多工作；例如 Python 項目的構建可能包含單獨的作業，并使用 2.6、2.7、3.0 等版本進行測試。

提交對是一個二元組的 GIT 提交 SHA，每個 SHA 在相同的構建歷史中觸發了 TRAVIS-CI 構建。規范的提交對包括一個無法通過測試的提交，以及一個通過測試的修訂提交。術語構建和作業對分別是指來自項目構建歷史的一個二元組的 TRAVIS-CI 構建或作業。對于給定的構建，觸發器提交是提交到遠程存儲庫后導致 TRAVIS-CI 開始構建的提交。

BUGSWARM 具有四個組件：PAIRMINER、PAIRFILTER、REPRODUCER 和 ANALYZER。這些組件形成管理 BUGSWARM 制品的管道，并且相對獨立和一般性。本節描述了每個組件的職責和實現，以及一組有助于使用數據集的支持工具。

5.2 設計挑戰

在用戶試圖連續自動地挖掘 TRAVIS-CI 時過程中會出現一些挑戰，該工具基礎架構旨在處理以這些的某些特定挑戰。我們將對每種情況均列出實際解決挑戰的工具。

(1)提交恢復：現構建需要找到觸發時的提交；(2)鏡像恢復：原則上 TRAVIS-CI 會創建并保留 DOCKER 圖像，以此重新創建構建和測試事件；(3)運行時恢復：構建特定的項目版本通常需要滿足對工具、庫和框架的大量軟件依賴；(4)日志分析：一旦運行對被恢復完成，BUGSWARM 就會嘗試從日志中確定缺陷的確切性質，這些日志的結構不完善，每種語言、構建系統和測試工具集組合的格式也不同。

5.3 挖掘失敗成功對

PAIRMINER 從項目的 GIT 中提取并建立歷史記錄，以獲取一組失敗成功作業對(如算法 1 所示)。PAIRMINER 將 GITHUB 塊作為輸入，并為每個作業的父版本生成一組故障傳遞作業對，并用觸發提交信息進行注釋。PAIRMINER 算法涉及(1)將項目的構建歷史線性化；(2)提取失敗成功構建對；(3)將提交分配給每個對；(4)從每個失敗成功構建對中提取作業對。

算法 1 PAIRMINER 算法

5.4 查詢復現信息

PAIRMINER 鑒定的相關對必須組裝到可復制容器中。對于管道中的每個作業，PAIRFILTER 都會檢查是否可以獲取這些必需信息。如果 PAIRMINER 認為項目狀態可恢復，則 PAIRFILTER 會檢索作業的原始 TRAVISCI 日志并提取有關執行環境信息。PAIRFILTER 使用日志中的時間戳和實例名稱，以確定作業是否在 DOCKER 容器中執行。

5.5 復現失敗成功對

REPRODUCER 首先需要檢查每個工作是否可以持久復現，這需要以下幾個步驟。(1)生成工作腳本，travis-build 從.travis.yml 文件生成 Shell 腳本，以運行 TRAVIS-CI 作業；(2)匹配環境，為了匹配原始作業的運行時環境，REPRODUCER 從 TRAVIS-CI 公開可用的 DOCKER 圖像集中進行選擇；(3)還原項目，對于項目歷史記錄還原，REPRODUCER 提交克隆項目并重置其狀態；(4)復現工作，REPRODUCER 創建一個新的 DOCKER 映像，運行生成的作業腳本，并將生成的輸出流保存在日志文件中。

5****.6** **結果分析****

ANALYZER 解析 TRAVIS-CI 構建日志以了解構建狀態以及回歸測試用例集的運行結果。如果測試失敗，則 ANALYZER 還將檢索其名稱。而構建日志的格式隨特定的構建系統和測試框架而有很大不同；因此解析器必須與每個構建和測試框架對應。對于 Java，我們支持最流行的構建系統 Maven、Gradle 和 Ant 以及測試框架 JUnit 和 TestNG。對于 Python，我們支持最受歡迎的測試框架 unittest、unittest2、nose 和 pytest。

7 總結與展望

本文介紹了 BUGSWARM，一種利用 CI 來挖掘和復現實際開發中真實的失敗-成功對方法。同時我們描述了一些具有意義的未來工作方向，以進一步完善數據集。我們希望 BUGSWARM 將盡可能地減少復現錯誤時的重復工作，并為評估軟件工具和進行大規模軟件研究提供新的研究機會。

致謝

本文由南京大學軟件學院 2020 級博士張犬俊翻譯轉述。

總結

以上是生活随笔為你收集整理的oss生成唯一文件名_根据结构化自然语言规范自动生成精确预言的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。