眾測已經成為傳統測試的有效替代，尤其是對於移動應用。然而，眾測在本質上很難管理。考慮到移動應用程式的複雜性和分散式眾測過程的不可預測性，很難估計尚未檢測到的剩餘 bug 數量或查詢這些 bug 所需的成本。基於經驗的決策可能會導致無效的眾測過程，例如，在當前的眾測實踐中，平均有 32%的浪費支出。
本文旨在探索自動化決策支援來有效管理眾測過程。提出了一種 ISENSE 方法，該方法應用增量抽樣技術對按時間順序到達的眾包測試報告進行處理，將其組織成固定大小的組作為動態輸入，並以增量方式預測兩個測試完成指標。這兩個指標是：1）捕獲-再捕獲模型預測的 bug 總數；2）自迴歸綜合移動平均模型預測的達到一定測試目標所需的測試成本。iSENSE 對來自中國最大的眾測平臺之一的 218 項眾測任務的 46434 份報告進行了評估。透過兩個自動化眾測管理和半自動化任務結束權衡分析的應用研究，證明了該方法的有效性。結果表明，ISENSE 可以讓管理者對測試進度有更高的認識，從而實現眾測的成本效益收益。具體來說，基於自動關閉預測，可以檢測到 100%bug 的中位數，節省 30%的成本。
1 導言眾測是一種新興的正規化，它可以提高軟體測試的成本效益，加速軟體測試的程序，特別是對於移動應用程式。它將測試任務委託給線上工人，這些工人的不同測試環境、背景和技能可以顯著提高測試結果的可靠性、成本效益和效率。眾測已經被許多軟體組織採用。在軟體工程中，諸如“多少測試就足夠了”這樣的權衡是至關重要的，但同時也是具有挑戰性的專案決策。測試不足會導致軟體質量不令人滿意，而過度測試會導致潛在的進度延遲和低成本效益。考慮到移動應用程式的複雜性和分散式眾測過程的不可預測性，這對於眾測尤其如此。
在實踐中，專案經理通常只根據他們的個人經驗來計劃眾測任務的結束。例如，他們通常採用基於持續時間或基於參與者的條件，透過固定期限或固定數量的參與者來完成眾測任務。如果先滿足任一條件，任務將自動關閉。然而，我們對現實中眾測資料的調查顯示，眾測任務的 bug 到達率、任務的持續時間和為達到相同的質量水平而消耗的成本存在很大的差異。對管理者來說，做出合理的決定是非常具有挑戰性的。這些基於經驗的決策可能會導致無效的眾測過程，此外，眾測通常被視為一個黑匣子過程，管理者的決策對其實際進展仍然不敏感。這表明了改進當前眾測實踐的實際需要和潛在機會。
本文旨在探索自動化決策支援，以提高眾測過程的完成意識，並更有效地管理眾測實踐。特別地，我們利用與眾測報告相關聯的動態 bug 到達資料，並且調查是否有可能確定在某個時間點，一個任務已經獲得令人滿意的 bug 檢測水平。
本文提出的完成感知眾測管理方法 ISENSE 應用增量抽樣技術處理按時間順序到達的眾測報告，將其組織成固定大小的組作為動態輸入，並結合捕獲-再捕獲（CRC）模型和自迴歸綜合移動平均（ARIMA）模型，提高對眾測進展的認識。ISENSE 以增量的方式預測兩個測試完成指標，包括：1）CRC 模型預測的 bug 總數，2）ARIMA 模型預測的實現某些測試目標所需的測試成本。
ISENSE 使用中國最大的眾測平臺之一的 218 個任務進行評估。結果表明，預測的最大似然比（總 bug 數和所需成本）均低於 6%，標準差約為 10%。我們透過兩個典型的決策場景，一個用於任務關閉決策的自動化，另一個用於任務關閉權衡分析的半自動化，進一步證明了該方法的有效性。結果表明，使用 ISENSE 的決策自動化將為管理者提供更大的機會實現眾測的成本效益收益。具體來說，基於自動關閉預測，可以檢測到 100%bug 的中位數，節省 30%的成本。
2 動機為了瞭解眾測的 bug 到達模式，我們進行了一項初步研究，分析了三個指標，即 bug 檢測速度、bug 檢測成本和 bug 檢測率。對於每個任務，我們首先確定檢測到 K%bug 的時間，其中 K 的範圍為 10 到 100。然後，可以使用任務的開啟時間和接收 K%bug 的時間之間的持續時間（小時）來計算任務的 bug 檢測速度。bug 檢測成本可以透過達到 K%bug 的提交報告的數量來計算。
為了檢查 bug 檢測率，我們將每個任務的眾測報告按時間順序分成 10 個大小相等的組。每個組的比率是使用唯一 bug 數和報告數之間的比率得出的。此外，對於每個眾測任務，我們還檢查了前 X 個報告中累積 bug 的百分比（表示為 bug 到達曲線），其中 X 的範圍從 1 到報告總數。
我們觀察到以下 bug 到達模式：1）bug 檢測速度和成本差異較大：圖 1a 和 1b 展示了所有任務的 bug 檢測速度和成本的分佈。一般來說，缺陷檢測的速度和成本有很大的差異。2）隨著時間的推移，bug 檢測率不斷降低：圖 1c 顯示了所有任務中 10 個細分組的 bug 檢測率。我們可以看到，在眾包測試過程中，bug 檢測率急劇下降。這意味著在流程的後期，眾測的成本效益正在急劇下降。3）bug 到達曲線的平臺效應：圖 2 顯示了四個眾包測試任務的典型 bug 到達曲線。儘管它們有些不同，但請注意，它們都表現出相同的“平臺效應”，之後（即圖 2 中的紅點）新的報告沒有發現新的 bug。我們假設在紅點之後花費在這些報告上的成本是浪費性的支出。在 218 個實驗任務中，平均有 32%浪費。缺陷到達曲線平臺效應以及大量浪費性支出進一步表明，引入提前關閉機制（基於對該平臺的認識）以提高成本效益的潛在機會和實際需要。4)自動化決策支援需求。
總之，由於缺陷到達速度和成本有很大差異，當前的決策主要是透過猜測來完成的。這導致了眾包測試的低成本效益。管理眾測的一個更有效的替代方法是動態監控眾測過程，併為任務結束提供可操作的決策支援，以避免不必要的成本浪費在稍後到達的報告上。此外，目前的實踐表明，實際需要增強管理者對眾測過程的可見性，並在理想情況下提高他們對任務進展的認識，從而促進他們的決策。
3 方法圖 3 顯示了 ISENSE 的概述。它包括三個主要步驟。首先，ISENSE 採用增量抽樣方法對眾包測試報告進行建模。在此過程中，ISENSE 將按時間順序到達的原始眾測報告轉換為組，並生成一個 bug 到達查詢表來描述 bug 到達資訊。然後，ISENSE 集成了 CRC 和 ARIMA 兩個模型，分別預測軟體中包含的缺陷總數和實現特定測試目標所需的成本。最後，ISENSE 應用這些估計來支援兩種典型的眾測決策場景，即自動任務結束決策和半自動任務結束權衡分析。
3.1 增量取樣技術在資料預處理中的應用增量取樣技術是一種複合取樣和處理協議。它的目標是獲得一個單一的樣品進行分析，其分析濃度代表決策單位。與傳統的離散抽樣策略相比，它透過減少變異性提高了抽樣資料的可靠性和可防禦性。
考慮到提交的按時間順序排列的眾測報告，當收到 smpSize（smpSize 是一個輸入引數）報告時，ISENSE 將其作為一個代表組來反映多個並行眾測會話。我們提到，每個報告的特徵是：1）它是否包含錯誤；2）它是否與以前提交的報告重複；如果不是，則用新標籤標記；如果是，則用與重複報告相同的標籤標記。在眾測過程中，我們動態地維護一個二維 bug 到達查詢表來記錄這些資訊。
表一提供了一個示例。在收到每個樣本之後，我們首先在查詢表中新增一個新行（假設它是第 i 行）。然後，我們檢查這個示例中包含的每個報告。對於不包含 bug 的報告，我們忽略它。否則，如果它被標記為與現有唯一 bug 相同的標記（假設它是第 j 列），則在第 i 行第 j 列中記錄 1。如果它被標記為新標記，則在查詢表中新增一個新列（假設它是第 k 列），並在第 i 行第 k 列中記錄 1。對於第 i 行中的空單元格，則用 0 填充。
3.2 使用 CRC 預測總錯誤數現有的 CRC 模型可以根據 bug 檢測機率分為四種類型(即。相同與不同)和眾包工人的檢測能力(即相同與不同)，如表二所示。M0 模型假設所有不同的 bug 和眾包工人具有相同的檢測機率。Mh 模型假設缺陷被檢測到的機率不同。Mt 模型假設眾包工人具有不同的檢測能力。模型 Mth 假設對不同的 bug 和眾包工人有不同的檢測機率。
ISENSE 將每個樣本視為捕獲（或再捕獲）。每次捕獲結束時，在更新 bug 到達查詢表之後，ISENSE 會根據當前的查詢表預測軟體中的 bug 總數。由於空間的限制，我們只演示瞭如何使用 Mth 估計。對於其他四個估計器，可以用類似的方法獲得估計的錯誤。
基於公式 1 和公式 2，Mth 估計器預測了 bug 的總數。表三顯示了每個變數的含義，以及如何根據表一中的 bug 到達查詢表計算其值。
3.3 使用 ARIMA 預測所需成本圖 4 展示了 ARIMA 如何應用於預測未來 bug 到達的趨勢。我們將每個樣本的報告視為一個視窗，從 bug 到達查詢表中獲取每個樣本中提交的唯一 bug 的數量（即行中值為 1 且相應列沒有其他 1 的單元格的數量）。然後利用前一個 trainSize 視窗對 ARIMA 模型進行擬合，預測後一個 predictSize 視窗的 bug 數量。當新到達的報告形成新的視窗時，我們將視窗移動 1，得到新的預測結果。
假設一個人想知道實現某些測試目標，即 X% bug 需要多少額外成本。由於我們已經知道了預測的 bug 總數，我們可以計算出應該檢測到多少 bug 以滿足測試目標；假設它是 Y bug。根據 ARIMA 的預測，我們得到了當可以接收到 Y bug 的數量時，假設它需要額外的 Ki 報告。這樣，我們假設 Ki 是滿足測試目標所需的成本。
3.4 將 ISENSE 應用於兩個決策場景為了證明 ISENSE 的有效性，我們歸納了眾測管理中兩個典型的決策場景，並舉例說明了 ISENSE 在每個場景中的應用。
1）自動化任務關閉決策：第一個可以受益於 ISENSE 總 bug 預測的場景是動態任務關閉的決策自動化。
一旦一個眾測任務開始，ISENSE 就可以應用於監控實際的 bug 到達，不斷更新 bug 到達查詢表，以及跟蹤檢測到的 bug 的百分比（即，到目前為止提交的 bug 數量與預測的 bug 總數的比率）。在這種情況下，可以在 ISENSE 中自定義不同的任務關閉條件，以便在滿足指定條件時自動關閉任務。例如，一個簡單的標準是在提交的報告中檢測到 100%的 bug 時關閉任務。在這個標準下，當 ISENSE 監控到 100%的 Bug 已經收到並且連續兩次捕獲的預測保持不變時，它將最後一次報告收到的時間確定為關閉時間；並在執行時自動關閉 crowdtesting 任務。注意，兩次連續捕獲的限制是為了確保預測的穩定性。
ISENSE 支援關閉條件的靈活定製。例如，任務管理器可以設定為在檢測到 80%的錯誤時關閉其任務。因此，ISENSE 將透過對這些定製的關閉標準作出反應，幫助監控和關閉任務。
2）任務結束權衡分析的半自動化：第二種情況得益於 ISENSE 所需成本的預測，即任務結束權衡分析的決策支援。例如，假設在某個時間報告了 90%的 bug，ISENSE 可以同時顯示檢測額外 X% bug 所需的估計成本（即 5%），以實現更高的 bug 檢測級別。如果所需成本太高，不值得額外的 X%檢測到的缺陷；或者，如果所需成本可以接受，並且需要額外的 X%檢測到的缺陷，那麼這些與成本效益相關的見解可以為管理者提供更多的信心，使他們能夠做出明智的、可操作的決定，即是否立即關閉。
4 結果與分析RQ1：ISENSE 能在多大程度上準確預測總 bug 數量？
表四顯示了所有五個 CRC 估計器預測的總錯誤的 MRE 的中位數和標準差。列對應不同的檢查點，並且突出顯示每個檢查點下表現最好的兩個（斜體字型和紅色）。我們還在圖 5 中給出了 Mth（最佳估計器）的詳細效能。
從表四和圖五中，我們可以看到，在任務結束時，預測的 bug 總數變得更接近實際的 bug 總數（即 MRE 減少）。在五個估計量中，M0 和 Mth 對大多數檢查點的 MRE 中位數最小。但 M0 的方差遠大於 Mth。因此，Mth 估計器因其相對較高的穩定性和對缺陷總數的準確預測而更受青睞。表五比較了 ISENSE 和兩條基線在 MRE 的中位數和標準差方面的預測精度。表六總結了 Mann-Whitney U 檢驗在兩種方法之間預測的總缺陷的 MRE 的結果。結果表明，ISENSE 在 p<0.05 和 Cliff's delta 較大時顯著優於兩條基線，尤其是在眾測任務的後期（即 40%檢查點之後）。
ISENSE 和最佳估計器 Mth 能夠準確預測眾測中的總 bug，並且顯著優於兩個基線。具體來說，預測的總缺陷的中位數幾乎等於基本真實值（即 MRE<0.06），在過程的後半部分，標準偏差小於 10%。
RQ2：ISENSE 能在多大程度上準確地預測實現某些測試目標所需的成本？
表七總結了 ISENSE 和兩條基線預測所需成本 MRE 的中位數和標準差的比較，列對應不同的檢查點。我們強調在每個檢查點下具有最佳效能的方法。表八給出了每對之間的 Mann-Whitney U 檢驗結果。
如表七中 MRE 中值的下降所示，對所需成本的預測對於以後的檢查點變得越來越準確。例如，50%檢查點後，預測成本的平均 MRE 低於 6%，標準差約為 13%。這意味著 ISENSE 可以有效地預測目標測試所需的成本。我們可以看到，在任務過程的後半部分，兩條基線的 MRE 的中位數和標準差都比 ISENSE 差。從表八中觀察到，在眾測過程的後半部分，擬議的 ISENSE 和兩條基線之間的差異是顯著的（p<0.05）和實質性的（Cliff 的增量不可忽略）。這進一步說明了所提出的 ISENSE 的優點。
ISENSE 可以在眾包測試後期平均 6%MRE 範圍內預測所需的測試成本。
RQ3：ISENSE 能在多大程度上透過決策自動化幫助提高眾測的有效性？
圖 6 顯示了五個自定義關閉標準的%bug、%ReductionCost 和 F1 的分佈。圖 6 中的最後三個框，它反映了檢測到 100%bug 的一個接近標準（即最常用的設定）。結果表明，在平均成本降低 30%的情況下，可以檢測到 100%的錯誤。這意味著，如果配備像 ISENSE 這樣的決策自動化工具，在執行時自動監視和關閉任務，管理者的成本效益將提高 30%。當考慮到在一個眾測平臺中交付的大量任務時，降低的成本是一個巨大的數字。另外，標準差相對較低，進一步說明了 ISENSE 的穩定性。
然後，我們將重點轉移到其他四個定製的關閉標準（即 80%、85%、90%和 95%的檢測到的 bug 百分比）。我們可以觀察到每個關閉標準，ISENSE 生成的中間%bug 非常接近目標關閉標準，標準差很小。在這些接近的標準中，可以節省 36%到 52%的成本，這進一步說明了 ISENSE 的有效性。
我們還注意到，中值%bug 比定製的關閉標準稍微大一點。這意味著，在大多數情況下，由 ISENSE 產生的密切預測不存在測試不足的風險。我們分析了產生這種現象的原因。這主要是因為，在建議關閉之前，我們的方法要求兩次連續捕獲的預測總錯誤保持不變。這種限制是為了減輕測試不足的風險。這也是因為在預測過程中，我們將報表樣本視為單位，這也可能導致關閉時間比定製的關閉時間晚一點。
ISENSE 的任務結束自動化可以使眾包測試更具成本效益，即可以用 30%的節省成本檢測到 100%的 bug。
RQ4：如何應用 ISENSE 來促進關於成本效益的權衡決策？
圖 7 展示了跨 6 個任務（即 P1-P6）的 4 個權衡分析示例，這些示例是在 4 個不同的時間點（即按順序對應於 time1 到 time4）重複上述分析生成的。y 軸表示要實現的下一個測試目標，而 x 軸表示實現該目標所需的預計成本。
一般來說，在四個框中的每一個框中，右邊的眾測任務都比左邊的任務低成本效益。例如，在時間 3，P6 估計需要額外的 14 個成本來實現 100%的測試目標。如果經理面臨預算限制或試圖提高成本效益，他/她可以選擇在時間 3 關閉 P6，因為它是所有任務中效率最低的一個。
為了便於對關閉哪個任務和何時關閉進行這種權衡分析，我們設計了兩個決策引數作為決策者的輸入：1）質量基準，它設定了 bug 檢測級別的最小閾值，如圖 7 中的水平紅線；2） 為實現下一個目標設定所需成本的最大閾值的成本基準，如圖 7 中的垂直藍線。這兩個基準在每個切片時間將任務劃分為四個區域（如圖 7 的每個子圖中的四個框所示）。每個區域都對測試的充分性和成本效益提出了不同的見解，這些見解可以作為啟發式方法來指導執行時的可操作決策。更具體地說：
左下角（稍後關閉）：建議稍後關閉此象限中的任務，並且繼續測試會產生低掛起的結果。對於這些任務，它們的質量水平還不可接受，它只需要相對較少的成本來提高質量（即，實現下一個測試目標）。這表明最具成本效益的選擇和測試肯定應該繼續。
右下角（繼續管理）：此象限中的任務未達到質量基準，因此繼續測試是首選，即使它們需要更大的成本才能實現質量目標。這也表明，這項任務要麼難以測試，要麼目前的眾工參與不夠。因此，建議管理者採取行動，深入研究特定任務，看看是否需要更多的測試指南或員工激勵措施。
左上角（計劃結束）：這個象限中的任務已經達到了它們的質量基準，但是，要達到下一個更高的質量級別，也就是說，幾乎沒有額外的成本，這是非常具有成本效益的。管理者可能計劃結束所有這些任務，或者確定一些高優先順序的任務，以便進行進一步的測試和質量改進。
右上角（立即關閉）：此象限中的任務是立即關閉的候選任務，因為它們已達到預先指定的質量目標，並且需要相對較大的成本才能達到下一個質量級別。考慮到成本效益，繼續測試是不實際的。
ISENSE 提供了實用的見解，幫助管理者根據兩個基準引數和一組決策啟發法，對要結束的任務或何時結束任務進行權衡分析。
5 討論5.1 在眾測決策支援中進行更具時間敏感性分析的必要性與眾測管理相關的挑戰主要存在於兩個方面：眾測工作者績效的不確定性和缺乏對眾測進度的可見性。我們相信，在眾測過程中，越來越需要引入更多對時間敏感的分析，以支援更好的決策。
ISENSE 可以生成基於時間的資訊，揭示動態眾測過程，併為權衡分析提供實用的指導。此外，ISENSE 還提供了對測試進度的額外可見性，以及對有效任務管理和眾測過程的見解。實驗結果表明，該方法可以節省大量的眾測成本。這是非常令人鼓舞的，我們期待著在這方面進行更多的討論和創新的決策支援技術。
5.2 有效性威脅首先，本文將眾測報告的數量作為衡量降低成本的成本量。這適用於按報表付費模式（即提交報表的眾包工人可以獲得報酬），這是一種常用的支付模式。對於第二種流行的由 bug 付費的模式（即報告 bug 的眾包工人可以獲得報酬），ISENSE 還可以透過正確關閉任務來降低成本（即更少的 bug 報告意味著更少的成本）。我們相信 ISENSE 可以獲得相當的效能，因為在整個眾測過程中，報告中的 bug 比例幾乎保持不變。對於第三種流行模式，由第一個 bug 付費（即報告第一個 bug 的眾包工人可以獲得報酬）。此模式對自動任務關閉決策不太敏感，因為在此模式下，向眾包工人支付的款項是恆定的（即提交的唯一錯誤數）。然而，透過在適當的時間關閉任務，該平臺可以潛在地降低管理重複報告的成本，以及縮短眾測任務的持續時間。
第二，我們設計的方法是基於報表的屬性（即它是否包含 bug；以及它是否與以前的方法重複）。在眾測過程中，每一個報告都會被檢查並用這兩個屬性進行分類，以便更好地管理報告的 bug，並便於 bug 修復。這可以手動完成或使用自動工具支援。因此，我們假設我們所設計的方法可以很容易地應用於眾測平臺。