作為最受歡迎的開源代碼倉庫,GitHub以其特有的“社交編程”方式極大地促進了軟件生態(tài)系統(tǒng)的發(fā)展。在GitHub軟件生態(tài)系統(tǒng)中,下游項目依賴于上游項目提供的基礎設施或功能組件,形成了復雜的項目間依賴關系。通過這些依賴關系,上游項目中的缺陷將其影響傳遞到下游項目中,形成軟件生態(tài)系統(tǒng)中獨有的跨項目缺陷。相比于項目內(nèi)缺陷,跨項目缺陷影響范圍更大,危害整個生態(tài)系統(tǒng)的健康;其處理過程更復雜,涉及多個項目開發(fā)者的協(xié)作;且由于一些影響僅暴露在下游,上游測試集無法捕獲,導致其檢測難度更高。隨著GitHub的愈加流行和軟件生態(tài)系統(tǒng)的高速發(fā)展,此類缺陷數(shù)量不斷增加,其有別于項目內(nèi)缺陷的特點導致已有的缺陷理解和分析結論以及檢測修復等技術不再適用。然而當前軟件生態(tài)系統(tǒng)和缺陷的相關工作仍缺少對該類缺陷的關注,尤其缺乏對其檢測、診斷和修復過程的理解和特征總結,缺少適用于軟件生態(tài)系統(tǒng)的跨項目缺陷檢測和修復的支持技術與工具。因此,本文圍繞GitHub軟件生態(tài)系統(tǒng)中的跨項目缺陷理解和分析技術展開研究。具體而言,本文的第一項工作關注程序員處理跨項目缺陷時的應對措施,著重研究跨項目缺陷帶來的兩個難點:跨項目缺陷的根本原因追蹤...

【文章頁數(shù)】：163 頁

【學位級別】：博士

【部分圖文】：

圖1:1:論文組織結構

并使跨項目測試在合理時間內(nèi)完成。同時，本文的實證評估是第一個針??對跨項目回歸測試的可重復實驗，為后續(xù)相關工作提供自動化工具和基準數(shù)據(jù)??集。??１．４論文結構??本文共分為六章，各章節(jié)間的關系如圖１．１所示。首先，本章介紹了本文??的選題背景、研宄內(nèi)容、主要貢獻和論文結構。后續(xù)....

圖2.1:回歸測試技術

因此，各種技術方法被提出以降低回歸測試的成本，提高回歸測試??。其中主要的三類技術是：測試集最小化、測試用例選擇和測試用例排序。??２．丨所示，Ｐ為給定的待測項目，Ｐ’為修改后的版本，：Ｔ為Ｐ的測試集。測??最小化（ＴＳＭ）意圖通過去除冗余測試用例以減小測試集規(guī)模［１４２】；測試....

圖3.1:跨項目關聯(lián)缺陷的修復過程

ｎｕｍｐｙ／ｎｕｍｐｙ＃６４６７）可能與之相關。接下來兩位開發(fā)者直接參與到該Ｍ＜ｍｐ＿ｙ缺??陷的討論之中，并向Ｍ／ｍｐｙ提供了?一個測試用例。在開發(fā)者的幫助下，??這一?ｉＶｗｍ／？；ｙ缺陷被修復，且在確認Ａｓｆｒａｐｙ的測試用例通過、ａｓｔｒｏｐｙ／ａｓｔｒｏｐｙ＃４２５９?....

圖３．２：問題關聯(lián)的自動提示??題可能是缺陷、特征請求、任務、文檔缺失或僅僅是一個疑問

?“?我猜這次性能降低與?入?７０?中?ｒｅｒａｒｒａ．ｖ?的??性能問題相關�！保┑诙�，如果一個問題在另一個問題報告或??評論中被提及，那么在該問題報告中會自動出現(xiàn)一條提示。圖３．２為ｒｍｍｐｙ／ｎｕ－??ｍｐｙ＃６４６７問題報告頁面的一個片段，它表不該問題被ａｓｔｒｏｐｙ／ａ....

本文編號：4030076