自動完成 Android 應用程式的 Bug 報告

摘要

隨著平板電腦和智慧手機的普及，現代軟體開發領域的焦點已轉向移動應用程式。由於這一趨勢，這些“應用程式”的複雜性不斷增加，使得開發和維護變得更具挑戰性。此外，當前的 bug 跟蹤系統無法有效地支援構建包含可操作資訊的報告，這些報告是可以用來直接解決 bug 的資訊。為了滿足對改進報告系統的需求，我們引入了一種稱為 FUSION 的解決方案，它可以幫助使用者自動完成移動應用程式錯誤報告中的復現步驟。FUSION 將使用者提供的資訊與程式工件融合，其中程式工件是在測試和釋出前從靜態與動態分析中提取出來的。FUSION 所採用的方法可以推廣到其他現有的移動軟體平臺上，為移動軟體專案的離線 bug 報告提供了一種新的方法。在一項涉及 28 名參與者的研究中，我們應用 FUSION 來支援維護任務，即報告和再現 14 個開源 Android 應用程式中發現的 15 個真實世界 bug，同時定性地衡量系統的使用者體驗。我們的結果表明，與傳統的問題跟蹤系統相比，透過提供更詳細的上下文應用程式資訊，融合不僅有效地促進了報告，而且允許從報告中更可靠地再現 bug。

關鍵詞

錯誤報告，android，復現步驟，自動完成

I 簡介

近年來，智慧手機和移動計算的普及率直線上升，2014 年，智慧手機使用者超過 27 億，採用率幾乎達到無處不在的水平。越來越多的使用者在“智慧”裝置上執行越來越多的計算任務，這推動了對高質量、健壯的移動應用程式需求的增長。由於這種需求，移動應用的複雜性不斷增加，使得開發和維護變得非常困難。谷歌 Play 和蘋果 App Store 等移動應用市場的激烈競爭意味著，如果某個應用程式由於漏洞或缺少所需功能而無法按預期執行，那麼 48%的使用者就不太可能再次使用該應用程式，他們會放棄該應用程式，轉而使用另一個具有類似功能的應用程式。

眾所周知，軟體維護活動通常是昂貴且具有挑戰性的。最重要的維護任務之一是錯誤報告解決。然而，Bugzilla、Mantis、Google 程式碼問題跟蹤器、GitHub 問題跟蹤器等現有缺陷跟蹤系統以及 JIRA 等商業解決方案大多依賴於非結構化的自然語言缺陷描述。這些描述可以透過記者上傳的檔案（如截圖）加以補充。作為缺陷報告的一個重要組成部分，複製步驟應以結構化和描述性的方式報告，但描述的質量主要取決於報告者提供足夠資訊的經驗和態度。因此，報告過程可能很麻煩，額外的工作意味著許多使用者不太可能用額外的資訊來增強他們的報告。

Koru 等人過去對開放原始碼開發人員進行的一項調查顯示，只有大約 50%的開發人員認為 bug 報告總是完整的。先前的研究也表明，對開發者最有用的資訊往往是記者最難提供的，而缺乏這些資訊是不可複製的 bug 報告背後的一個主要原因。由於其複雜的事件驅動和基於 GUI 的特性，在移動應用程式的上下文中，提供此類資訊（尤其是複製步驟）的困難更加複雜。此外，許多 bug 報告是根據使用者評論中問題的文字描述建立的。根據 Chen 等人最近的一項研究，只有少量的使用者評論才被認為是有用和/或有用的。此外，與問題報告不同，評論並不涉及應用程式的實現細節。

上述問題指出了 bug 跟蹤系統的一個更突出的問題：bug 報告者（例如測試人員、beta 使用者）和開發人員之間通常存在的詞彙差距。記者通常只掌握應用程式的功能性知識，即使他們自己也有開發經驗，而開發應用程式的開發人員往往擁有親密的程式碼級知識。事實上，hoo 等人最近進行的一項研究證實了這種知識差距的存在，因為他們發現專家和非專家編寫 bug 報告的方式存在差異，這是透過文字相似性度量來衡量的。當開發人員閱讀並試圖理解（或再現）一個 bug 報告時，她必須彌合這一鴻溝，從 bug 報告中的高階功能描述中推理程式碼級問題。如果詞法差距太大，開發人員可能無法重現和/或隨後解決 bug 報告。

為了解決讓錯誤報告對開發人員更有用（和可複製）這一基本問題，我們引入了一種新的方法，我們稱之為 FUSION，它依賴於一種新的分析 → 生成正規化，以實現 Android 錯誤報告的自動完成，從而為開發人員提供更多可操作的資訊。在本文的上下文中，我們將自動完成定義為向用戶建議特定 GUI 元件的相關操作、螢幕截圖和影象，以便於報告重現 bug 的步驟。FUSION 首先使用全自動靜態和動態分析技術，在應用程式釋出測試之前，收集應用程式的螢幕截圖和其他相關資訊。然後，報告員使用自動完成功能與基於 web 的報告生成器互動，以提供錯誤再現步驟。透過將使用者提供的資訊與透過靜態和動態分析提取的特徵聯絡起來，FUSION 向開發人員提供了一個增強的 bug 報告，其中包含立即可操作的資訊，並有明確的步驟來重現 bug。

我們在一項研究中對 FUSION 進行了評估，該研究將使用我們的系統提交的 bug 報告與使用 Google 程式碼問題跟蹤器生成的 bug 報告進行了比較，共有 28 名參與者報告了來自 14 個開源 Android 應用程式的 15 個實際故障的 bug。

我們的論文做出了以下值得注意的貢獻：

1。

我們設計並實現了一種自動完成和擴充 Android 錯誤報告的新方法，稱為 FUSION， 它利用靜態和動態分析，併為開發人員提供可操作的資訊。該工具有助於報告、複製和 後續解決 Android 錯誤。應用程式的程式分析技術可以在物理裝置和模擬器上執行；

2。

我們設計並進行了一項全面的使用者研究，以評估我們的方法的使用者體驗和使用 FUSION 生成的 bug 報告的質量，並與 Google 程式碼問題跟蹤器進行比較。這項研究的結 果表明，與完全編寫的報告相比，融合使開發人員能夠提交更可能重複的 bug 報告；

3。

我們將融合和實驗中的所有資料提供給研究人員，希望這項工作能夠促進與改進 缺陷報告和缺陷報告系統質量相關的新研究。

II 研究和實踐狀況

Bug 和錯誤報告一直是軟體工程界研究的一個活躍領域。然而，已經開展了一些工作，以改善進入複製步驟的報告機制中缺乏結構的問題，並在缺陷跟蹤系統中添加了相應的支援。因此，在本節中，我們將簡要介紹當前缺陷報告系統的特點以及推動這項工作的研究。然後，我們將我們的工作與現場故障再現方法區分開來，並解釋我們的工作是如何對現有的缺陷報告研究進行補充的。

2.1 現有缺陷報告系統

當前大多數問題跟蹤系統都依賴於報告中未經修飾的自然語言描述。然而，有些系統確實提供了更多的功能。例如，Google 程式碼問題跟蹤器（GCIT）提供了一個半結構化的區域，在這裡，記者可以以自然語言的形式輸入再現步驟和預期的輸入/輸出（即，線上表單詢問：“哪些步驟會再現問題？”）。 幾乎所有當前問題跟蹤程式都提供結構化欄位來輸入資訊，如標記、嚴重性級別、簽名者、修復時間和產品/程式規範。一些基於 web 的 bug 報告系統（例如 Bugzilla、Jira、Mantis、UserSnap、BugDigger）有助於包括螢幕截圖在內的報告。然而，目前的缺陷跟蹤系統並沒有像 FUSION 那樣將相關複製步驟的線上建議與螢幕截圖結合起來。

2.2 缺陷報告研究

當前許多 bug 報告系統面臨的問題是，典型的自然語言報告捕獲了粗粒度的細節級別，這使得開發人員很難對缺陷進行推理。這突出了 bug 報告系統必須完成的基本任務：彌合 bug 的典型報告者和必須解決 bug 的開發人員之間的法律知識鴻溝。以前關於 bug 報告質量和開發人員資訊需求的研究強調了幾個可能影響 bug 報告質量的因素：

•

除了“外掛間依賴關係”（即，在以前的補丁中修復了一個 bug）之外，資訊不足是導 致不可複製 bug 報告的主要原因之一；

•

開發人員認為（i）複製步驟，（ii）堆疊跟蹤，以及（iii）測試用例/場景是 bug 報告中 最有用的資訊源；

•

資訊需求在 bug 生命週期的早期是最大的，因此，在 bug 報告建立期間，輕鬆新增上 述功能的方法非常重要。

利用這些問題作為動機，我們開發了融合，並考慮了兩個主要目標：（i）向開發人員提供具有立即可操作知識的 bug 報告（可靠的複製步驟）和（ii）透過自動完成機制提供這些資訊來促進報告。

值得注意的是，Bhattacharya 等人之前進行的一項研究得出的結論是，大多數針對開源應用程式的 Android 錯誤報告都是高質量的，但是在他們的研究中，只有大約 46%的錯誤報告包含了複製的步驟，甚至更少（≈20%）包含額外的資訊（例如，bug 觸發輸入，甚至是應用程式版本）。因此，在開源 Android bug 報告中包含的資訊型別方面，顯然還有改進的空間。

2.3 現場故障再現

一系列被稱為現場故障再現的工作與我們的方法有相似的目標。這些技術從插入指令的程式收集執行時資訊（例如，執行跟蹤），使開發人員能夠更好地瞭解現場故障的原因，這將有助於加快這些故障的修復。然而，有幾個關鍵的不同之處使我們的工作與眾不同，並說明了融合是如何改善研究狀況的。

首先，關於現場故障再現的技術依賴於潛在的昂貴的程式工具，這需要開發人員修改程式碼並引入開銷。FUSION 是完全自動的；我們的靜態和動態分析技術只需要在釋出測試的程式版本中應用一次。此外，分析過程可以在不需要對現場程式進行說明的情況下完成。第二，當前的現場故障再現技術要求甲骨文表示故障發生的時間（例如，崩潰）。FUSION 不是一種用於崩潰或故障檢測的方法；它是為在錯誤報告過程中支援測試人員而設計的。第三，這些技術尚未應用於移動應用程式，很可能需要進一步最佳化，以適用於相應的資源受限環境。

2.4 錯誤和錯誤報告研究

先前工作的一個子集集中在 bug 和崩潰分類上。與本主題相關的技術通常採用不同的程式分析和機器學習或自然語言處理技術，將錯誤報告與適當的開發人員相匹配。我們提出的研究是對開發人員推薦框架的一種補充，因為 FUSION 可以為這些框架工作提供比當前實踐狀態錯誤報告系統更詳細的“知識”。

在總結、故障定位、重複錯誤報告的分類和檢測方面進行了大量的研究。同樣，本文中的工作是對這些研究類別的補充，因為透過融合生成的 bug 報告可以提供更詳細的資訊，很容易將 bug 連結回原始碼，從而可以進行更精確的定位、總結，並可能進行重複檢測。值得注意的是，Bettenburg 等人在從錯誤報告中提取結構化資訊方面的工作也有關聯；然而，我們的目標是幫助在建立報告時自動完成結構化複製步驟，而不是事後提取。

III 融合方法

融合的分析 → 生成工作流主要分為兩個階段。在分析階段，FUSION 透過靜態和動態分析的結合，收集與 GUI 元件和應用程式事件流相關的資訊。然後，在報告生成階段，FUSION 利用移動應用程式以 GUI 為中心的特性，自動完成重現 bug 的步驟，並使用上下文應用程式資訊增強每個步驟。FUSION 的總體設計如圖 1 所示。我們鼓勵讀者觀看我們正在使用的工具的影片，並附上評論，可在第 9 節概述的複製包中獲得。

3.1 分析階段

分析階段收集報告生成階段操作所需的所有資訊。第一階段有兩個主要部分：1）靜態分析（初級），2）目標應用程式的動態程式分析（引擎）。分析階段必須在應用程式的每個版本釋出測試之前或釋出給終端使用者之前執行。分析階段的兩個元件都將提取的資料儲存在融合資料庫中（圖 1-3）。

3。1。1 靜態分析（底漆）

入門（圖 1-1）的目標是從應用程式原始碼中提取所有 GUI 元件和相關資訊。對於每個 GUI 元件，Primer 提取：（i）該元件上可能的操作，（ii）元件的型別（例如，按鈕、微調器），（iii）元件包含在其中的活動，以及（iv）例項化元件的類檔案。因此，這一階段為我們提供了應用程式域中可能的元件，並建立了可追溯性連結，將報告者操作的 GUI 元件連線到特定於程式碼的資訊，例如它們所在的類或活動。

初級讀本由幾個步驟組成，用於提取上述資訊。首先，它使用 dex2jar 和 jdcmd 工具進行反編譯；然後，它使用 srcML 將原始檔轉換為基於 XML

的

表示。我們還使用 apktool 從應用程式的 APK 中提取資原始檔。GUI 元件的 id 和型別是從位於應用程式資原始檔夾（即反編譯應用程式或 src 的/res/layout 和/res/menu）中的 xml 檔案中提取的。使用原始碼的 srcML 表示，我們能夠解析 GUI 元件資訊並將其連結到提取的應用程式原始檔。

3。1。2 動態分析（發動機）

引擎（圖 1-2）用於收集動態上下文的實際資訊，例如螢幕上 GUI 元件的位置，並使用執行時 GUI 和應用程式事件流資訊增強資料庫。該引擎的目標是以系統的方式探索一個應用程式，在執行過程中剝離和提取與 GUI 元件相關的執行時資訊，包括：（i）與不同 GUI 元件相關的文字（例如，傳送電子郵件訊息的按鈕上的“傳送”文字），（ii）GUI 元件是否觸發到應用程式的轉換不同的活動，（iii）系統執行期間對 GUI 元件執行的操作，（iv）執行每個操作前後的全屏截圖，（v）GUI 元件物件在測試裝置螢幕上的位置，（vi）每個步驟的當前活動和視窗，（vii）特定 GUI 元件的螢幕截圖，以及（viii）GUI 元件的物件索引（允許在一個螢幕上區分相同 GUI 元件的不同例項）。

該引擎使用 android sdk 中包含的 UIAutomator 框架對應用程式進行系統的探索。這個應用程式的系統化執行與現有的 GUI 翻錄方法非常相似。透過使用 UIAutomator 框架，我們可以捕獲以前的工具中沒有捕獲到的情況，例如存在於選單、內部視窗和螢幕鍵盤中的彈出選單。為了有效地探索應用程式，我們為應用程式遍歷實現了我們自己版本的系統深度優先搜尋（DFS）演算法，該演算法在 GUI 層次結構中的所有可單擊元件上執行單擊事件，這些元件可以使用 DFS 啟發式方法訪問。

圖 1 FUSION 工作流概覽

在翻錄過程中，在 GUI 上執行每個步驟之前，引擎呼叫 UIAutomator 子例程，以提取上述關於當前顯示的每個 GUI 元件的上下文資訊。然後在當前螢幕上以深度優先的方式執行與每個 GUI 元件相關聯的操作。我們當前的 DFS 實現只處理 click/tap 操作；然而，由於這是最常見的操作，它仍然能夠探索應用程式的大量功能。

在 DFS 演算法中，如果單擊一個連結，該連結通常會轉換到外部活動中的螢幕（例如，單擊一個 web 連結，該連結將啟動 Chrome web 瀏覽器應用程式），我們將執行 back 命令以保持在當前應用程式中。如果 DFS 探索出於任何原因將應用程式退出到裝置/模擬器的主螢幕，我們只需重新啟動應用程式並繼續 GUI 遍歷。在 DFS 探索過程中，引擎捕獲在執行每個操作後發生的每個活動轉換（例如，在啟動選單的操作後是否啟動/恢復新活動）。這允許 FUSION 構建應用程式執行的模型，我們稍後將使用該模型來幫助跟蹤報告者在應用程式中的相對位置，當他們使用系統記錄複製錯誤的步驟時。

3.2 報告生成階段

在設計 FUSION 的報告生成階段元件時，我們有兩個主要目標：

1 允許傳統的自然語言輸入，以便對 bug 進行高階概述。

2 透過跟蹤報告者的步驟條目在應用程式事件流中的位置，自動完成 bug 的複製步驟。

圖 2 FUSION 報告介面

在報告生成階段，FUSION 透過根據宣告的步驟達到的“潛在”GUI 狀態提出建議，幫助報告者構建重新建立 bug 所需的步驟。這意味著，對於每個步驟，FUSION 都會透過考慮步驟的歷史，線上推斷目標應用程式應處於的 GUI 狀態 GUI。對於每個步驟，FUSION 透過向報告者呈現上下文相關的螢幕截圖來驗證向報告者提出的建議是正確的，其中報告者選擇與報告者想要描述的當前動作相對應的螢幕截圖。

3。2。1 報表生成器使用者介面

在第一次選擇要報告問題的應用程式之後，報告員透過在 UI 的上半部分填寫一些識別資訊（例如，名稱、裝置、標題）和有關 bug 的簡短文字描述，與 FUSION 進行互動。接下來，報告者使用自動完成框以逐步的方式輸入重現 bug 的步驟，從冷應用程式啟動 1 的初始螢幕開始，並繼續進行，直到重現 bug 的步驟列表用盡為止。讓我們考慮一個正在執行的示例，其中使用者正在為表 2 中的文件檢視器錯誤填寫報告。根據圖 2 中的各個欄位，報告者將首先填寫他們的（i）名稱（欄位 1），（ii）裝置（欄位 2），（iii）螢幕方向（欄位 3），（iv）錯誤報告標題（欄位 4），（v）錯誤的簡要描述（欄位 5）。

3。2。2 自動完成錯誤複製步驟

為了方便報告者輸入複製步驟，我們將複製過程中的每個步驟建模為action，component元組，對應於報告者在每個步驟中要描述的動作（例如，輕觸、長輕觸、輕掃、鍵入）和應用程式 GUI 中與之互動的元件（例如，“Name”textview，“確定”按鈕，“天”微調器）。由於報告者通常知道與之互動的動作和 GUI 元素，因此這是他們構建複製步驟的直觀方式。FUSION 根據決策樹將自動完成建議分配到下拉列表中，同時考慮報告者在應用程式執行中的位置（從應用程式冷啟動開始）。

第一個下拉列表（見圖 3-A）對應於使用者在應用程式執行中的給定點可以執行的可能操作。在我們的文件檢視器 bug 示例中，假設報告者在圖 3-A 所示的步驟序列中選擇 click 作為第一個動作。在 FUSION 中考慮的可能動作有 click（點選）、long click（長觸控）、type 和 swipe。型別操作對應於使用者從裝置按鍵板輸入資訊。當記者選擇 type 選項時，我們還會給他們一個文字框來收集她在 Android 應用程式中輸入的資訊。

圖 3 自動填充下拉按鈕

第二個下拉列表（見圖 3-B）對應於與步驟中的操作相關聯的元件。FUSION 提供以下資訊，如圖 3 所示：（i）元件型別：這是正在操作的元件型別，例如按鈕、微調器、複選框；（ii）元件文字：與元件相關或位於元件上的文字，（iii）相對位置：根據圖 5 中的引數，元件在螢幕上的相對位置；（iv）元件影象：元件例項的原位（即嵌入下拉列表）影象。這裡顯示的相對位置使記者更容易推斷螢幕上的位置，而不是推斷畫素值。在我們正在執行的示例中，FUSION 將在 component 下拉列表中填充 Main 活動中所有可單擊的元件，因為這是第一步，選中的操作是 click。然後使用者將選擇他們所操作的元件，在這種情況下，是列表中的第一個選項：位於螢幕中心的“OK”按鈕（參見圖 3-B）。

從自動完成下拉列表中選擇元件的一個潛在問題是，應用程式中的同一螢幕上可能有重複的元件。融合從兩個方面解決了這個問題。首先，它透過指定文字“Option#”，區分列表中的每個重複的元件。第二個 FUSION 嘗試透過從 FUSION 資料庫中獲取代表整個裝置螢幕的螢幕快照來確認報告者在每個步驟中輸入的元件。這些螢幕截圖中的每一個都突出顯示了圖 5 所示的代表性 GUI 元件。要完成步驟輸入，報告者只需選擇對應於應用程式狀態和 GUI 元件的螢幕快照。在我們正在執行的示例中，報告者將選擇與他們從下拉列表中選擇的元件相對應的完整增強螢幕截圖。在我們的例子中，“OK”按鈕的螢幕截圖的示例部分如圖 5 所示。

在報告者從下拉列表中進行選擇之後，他們有機會在自然語言文字輸入欄位中輸入每個步驟的附加資訊（例如，按鈕具有意外行為）。例如，在我們正在執行的示例中，報告者可能會指出，在按下“OK”按鈕之後，彈出視窗消失的時間比預期的要長。

3。2。3 報表生成器自動完成引擎

基於 web 的報表生成器的自動完成引擎（圖 1-4）使用在分析階段預先收集的資訊。當 FUSION 為下拉選單建議選項時，它會查詢資料庫中應用程式事件流的相應狀態，並根據報告者輸入的過去步驟建議資訊。因為我們總是假設應用程式啟動是“冷”的，所以自動完成引擎從應用程式的主要活動開始複製步驟輸入過程。然後，我們使用基於過去步驟的預測度量，透過應用程式跟蹤報告者的進度。

自動完成引擎使用多個不同的資訊作為輸入，對應用程式步驟進行操作。它將報告者的再現步驟建模為步驟 s 的有序流，其中每個步驟 si 可以是空的或滿的。每個步驟都可以建模為一個五元組，由{step num，action，comp name，activity，history}組成。動作是報告者在第一個下拉選單中提供的手勢。元件名稱是 UIautomator 介面在引擎階段報告的單個元件名稱。活動是元件所在的 Android 螢幕。歷史記錄是當前步驟之前的步驟的歷史記錄。自動完成引擎使用決策樹邏輯預測建議資訊，如圖 4 所示。

FUSION 在活動或應用程式螢幕的常規位置向報告者展示元件。為了總結建議過程，FUSION 回顧了過去幾個步驟的歷史，並根據與之互動的元件尋找從以前步驟到將來步驟的可能過渡。如果 FUSION 由於前面提到的應用程式執行模型不完整而無法從報告程式捕獲最後幾個步驟，那麼 FUSION 將從應用程式的所有已知螢幕中呈現可能性。在我們正在執行的示例中，讓我們考慮報告第二個複製步驟的報告員。在這種情況下，FUSION 將查詢歷史以查詢“確定”按鈕所在的上一個活動，然後在使用者停留在同一個活動中的情況下提供來自該活動的元件建議，在使用者轉換到不同活動的情況下提供來自可能的轉換活動的元件建議。

圖 4 決策樹在自動完成引擎中的應用

圖 5 相對位置列舉和示例增強螢幕截圖

3。2。4 處理 FUSION 的應用模型差距

由於基於 DFS 的探索並非詳盡無遺，FUSION 的可能應用程式螢幕資料庫中可能存在漏洞（例如，未對觸發活動轉換的動態生成元件採取行動）。因此，搬運工可能無法在下拉列表中找到合適的建議。為了優雅地處理這些情況，我們允許報告者在“自動完成”下拉列表中找不到與之互動的元件時選擇一個特殊選項。在我們正在執行的示例中，假設搬運工希望指示他們單擊了標記為“開啟文件”的按鈕，但該選項在“自動完成元件”下拉列表中不可用。在這種情況下，報告者將選擇“不在此列表中…”選項並手動填寫（i）元件的型別（為了限制混淆，我們將此選項顯示為一個下拉框，僅自動填寫應用程式中存在的 GUI 元件型別，如 Primer 提取的，在我們的情況下，使用者將選擇“按鈕”），（ii）與 GUI 元件相關的任何文字（在本例中為“Open Document”），以及（iii）GUI 元件的相對位置，如圖 5 所示（在本例中為“Top Center”）。

3。2。5 報表結構

當報告者完成錯誤報告時，自動完成引擎會將每個步驟儲存到資料庫中。一旦報告者完成了這些步驟並完成了資料輸入過程，一個包含最終報告的螢幕（帶有一個自動分配的唯一 ID）就會顯示給報告者，並儲存到資料庫中，供開發人員稍後檢視（參見圖 6 中的 Document Viewer 報告示例）。該報告以三個主要部分向開發人員提供資訊：第一，初步資訊，包括報告標題、裝置和簡短描述（如圖 6 中的藍色部分所示）。其次，將顯示一個步驟列表，其中包含有關每個步驟的以下資訊（在圖 6 中以藍色突出顯示）：（i）每個步驟的操作，（ii）元件的型別，（iii）元件的相對位置，（iv）在原始碼中例項化元件的 activity Java 類，以及（v）特定於元件的螢幕截圖。第三，與每個步驟相對應的全屏快照列表顯示在頁面底部，這樣開發人員就可以透過每個應用程式螢幕跟蹤這些步驟（圖 6 中以綠色突出顯示了該部分）。

IV 實驗設計

FUSION 背後的兩個主要設計目標是：1）簡化並鼓勵報告者為 Android 應用程式提交有用的 bug 報告；2）為開發者提供關於這些報告中所包含 bug 的更多可操作資訊。為了衡量 FUSION 在實現這些目標方面的有效性，我們評估了我們方法的兩個主要方面：1）系統生成的 bug 報告的質量，2）使用 FUSION 的報告者和開發人員的使用者體驗。為此，我們調查了以下研究問題：

•

RQ1：在 Android 應用程式中報告 bug 時，bug 報告中的哪些資訊欄位是有用的？

•

RQ2：FUSION 比傳統的 bug 跟蹤系統更容易報告 bug 嗎？

•

RQ3：融合報告是否比傳統的錯誤報告更容易用於重現錯誤？

•

RQ4：與使用傳統錯誤跟蹤系統提交的報告相比，使用 FUSION 生成的錯誤報告是否允 許更快的錯誤複製？

•

RQ5：與傳統的錯誤跟蹤系統相比，使用 FUSION 的開發人員是否會複製更多的錯誤？

對這五個 RQ 進行了調查，並進行了實證研究，其中包括兩項維護活動，涉及報告和複製開放原始碼應用程式中的真實 bug。在下面的小節中，我們將描述這兩項研究的背景（即 Android 應用程式和 bug 報告）以及每項研究的細節。

4.1 背景：研究中使用的缺陷報告

為了在報告和複製來自真實世界 bug 的 bug 報告時正確地評估融合，我們在 FDroid 中手動選擇了來自 Android 開源應用程式的 bug 報告。我們對應用程式的問題跟蹤系統的連結進行了爬網，然後手動檢查了 F-droid 擁有連結問題跟蹤器的每個專案的 bug 報告。選擇缺陷報告的標準如下：1）考慮到我們的融合實現的技術限制，可重複出現的缺陷；2）複雜程度不同的缺陷，需要至少三個使用者互動步驟才能表現出來；3）用於使用者研究的 Nexus 7 平板電腦上可重複出現的缺陷。這些 bug 報告的詳細資訊可以在表 2 中找到。

FUSION 的目標是 bug 報告，這些 bug 報告可以用 GUI 事件來描述，並且不依賴於上下文。例如，當改變裝置的方位時會觸發一些錯誤，或者與上下文有關（即，錯誤取決於網路訊號質量、GPS 位置等）。我們並不聲稱融合方法適用於所有型別的 Android bug。

4.2 評估使用者體驗、偏好和程式設計背景

對於這兩項研究，除了收集建立和複製錯誤報告的時間資訊外，我們還收集了對一組問題的回答，如表 1 所示。這些問題集中在三個不同的方面：1）使用者偏好，2）使用者體驗和 3）人口背景，包括程式設計體驗。與使用者偏好相關的問題（表 1 中的 UP 問題）是基於 Peter Morville 最初開發的使用者體驗蜂巢（UserExperience honeycomb）編制的，並作為自由形式的文字輸入欄位提交給參與者。可用性是透過使用 johnbrooke 基於 SUS 可用性量表的語句來評估的。這些語句在表 1 中用 UX 標記。程式設計經驗由參與者在擴充套件的 Likert 量表上評分（1 代表強烈的不同意，10 代表強烈的同意）。背景資訊問題基於 Feigenspan 等人開發的程式設計經驗問卷。對於自由式問題的分析，其中一位作者對答案進行了手動分析和分類。由於篇幅有限，表 1 列出了向研究參與者提出的問題的子集。這項工作的完整問題集可以線上在複製包中找到。

表 1 用於評估缺陷跟蹤系統的使用者體驗的問題和陳述，以及使用分析的系統生成的缺陷報告。

4.3 研究 1：使用 FUSION 報告 Bug

第一項研究的目標是評估 FUSION 的功能在報告 Android 應用程式的 bug 時是否有用，該應用程式旨在回答 RQ1 和 RQ2。特別是，我們想確定自動完成步驟和現場螢幕截圖功能在報告 bug 時是否有用。為了完成這一點，我們在威廉和瑪麗學院招募了 8 名學生（4 名本科生或非專家，4 名研究生或專家），用 FUSION 和 Google Code Issue Tracker（GCIT）構建 bug reports，作為傳統 bug 跟蹤系統的代表，用於表 2 所示報告中的真實世界 bug。這四名研究生參與者有著廣泛的程式設計背景。四名參與者使用 FUSION prototype 為表 2 中的 15 個 bug 中的每一個構建了一個 bug 報告，四名參與者使用 Google Code Issue Tracker 介面報告了 bug。參與者被分配到系統中，兩個非專家和兩個專案人員對這兩個系統進行評估。參與者總共構建了 120 個 bug 報告，其中 60 個使用 FUSION，60 個使用 GCIT。參與者使用安裝了 android4。4。3kitkat 的 nexus7 平板電腦來重現這些漏洞。

進行第一項研究的一個挑戰是向參與者說明缺陷，而不引入來自原始缺陷報告的偏見。為了實現這一點，我們建立了一些簡短的影片，介紹了使用盡可能少的操作來重現每個 bug 的步驟。觀看影片後，要求每位參與者在 Nexus7 平板電腦上覆制病毒，並由研究監護儀確認複製。然後參與者為分配給他們的系統的 15 個 bug 中的每一個都填寫一份 bug 報告。在報告收集過程中，錯誤報告系統的名稱被匿名化為“系統 A”用於 FUSION，而“系統 B”用於 GCIT。向用戶提供了一個簡短的教程，介紹如何為每個系統輸入 bug，以免給任何報告系統帶來偏見。在建立 bug 報告之後，使用者被要求在一次線上調查中回答表 1 中列出的問題。

4.4 研究 2：缺陷報告的再現性

研究 2 的目標是評估開發人員使用 FUSION 報告 bug 的可用性和偏好，以及我們提出的方法提高 bug 報告可重用性的能力，從而回答 RQ3-RQ5。特別是，我們評估了 FUSION 和傳統問題跟蹤器的以下方面：1）使用 bug 跟蹤系統的 GUI 讀取 bug 報告時的可用性，2）使用 bug 報告複製 reals bug 所需的時間，以及 3）成功複製的 bug 數量。研究 1 期間使用 FUSION 和 GCIT 生成的報告以及原始錯誤報告（表 2）均

由

一組新的 20 名參與者透過嘗試在物理裝置上覆制錯誤來評估。

參與者是威廉和瑪麗學院計算機科學系的研究生，他們都熟悉 Android 平臺，都是經驗豐富的程式設計師。所有參與者的努力都得到了 15 美元的補償。每個使用者評估了 15 個 bug 報告，6 個來自 FUSION，6 個來自 GCIT，還有 3 個原始的。對 135 份報告進行了評估（120 份來自研究 1 加上 15 份原始缺陷報告），並以這樣的方式分發給 20 名參與者，即每個缺陷報告由兩名不同的參與者進行評估（完整的設計矩陣可在我們的複製包中找到）。每個參與者只評估一個給定 bug 的 bug 報告的一個版本，因為學習效果表明，在使用者複製一次 bug 之後，他們將能夠在隨後的嘗試中輕鬆地複製其他 bug 報告。

表 2 用於實證研究的錯誤報告摘要。GDE=Gui 顯示錯誤，C=崩潰，DIC=資料輸入/計算錯誤，NE=導航錯誤。

在研究過程中，研究人員向參與者傳送了與報告相對應的連結，要求他們複製錯誤。每位參與者都被租借了一臺安裝了安卓 4。4。3kitkat 的 nexus7 平板電腦；這些應用程式是預先安裝在裝置中的。對於每個 bug 報告，使用者都試圖僅使用報告中包含的資訊在平板電腦上重新建立 bug。使用者為每一個 bug 的複製進行計時，時間限制為 10 分鐘。如果一個參與者在十分鐘後不能複製一個錯誤，那麼這個錯誤會被標記為未複製。一名監考員監測研究，判斷參與者是否成功複製了一個給定的錯誤。在使用者試圖重現分配給他們的所有 15 個 bug 之後，他們被要求為他們使用的每種 bug 報告型別填寫一份匿名線上調查，包含使用者體驗和表 1 中列出的問題。在分析中，我們使用描述性統計來分析 UX 語句的響應、重現 bug 的時間以及成功重現的次數。

V 結論和今後的工作

先前的研究強調了缺陷報告者和開發人員之間固有的詞彙差異。為了幫助解決這個問題，我們引入了 FUSION，一種新的 bug 報告方法，它利用了程式分析技術和 Android 應用程式的事件驅動特性，以幫助自動完成 bug 的複製步驟。我們的綜合評估結果表明，FU SION 比傳統的問題跟蹤系統能夠生成更多可重複的錯誤報告。我們希望我們在融合方面的工作能夠鼓勵一個旨在改進報告系統的新的研究方向。在未來的工作中，我們的目標是透過支援更多的手勢來改進我們的 DFS 引擎，探索在報告中新增更具體的程式資訊，以便更快/自動地定位故障，並使用 FUSION 作為報告功能請求的工具。

致謝

本文

有

南京大學軟體學院 2020 級碩士研究生王旭翻譯轉述。