眾包測試是一種新興的測試趨勢，將測試任務委託給線上眾包工作者。通常，眾包測試任務的目標是在有限的預算內檢測儘可能多的 bug。然而，並不是所有的眾包工作人員都同樣擅長髮現錯誤；不合適的眾包工作人員可能會漏掉錯誤，或者報告重複的錯誤，而僱用他們需要大量的預算。因此，為測試任務推薦一組合適的眾包工作人員是非常有價值的，這樣可以用較少的工作人員檢測更多的軟體錯誤。
本文首先介紹了眾包工人的三個新特徵，並用測試環境、能力和領域來描述這些特徵知識。基於這些特徵，我們提出了多目標眾包工人推薦方法（MOCOM），該方法旨在推薦最少數量的眾包工人，這些工人能夠檢測到最大數量的眾包測試任務中的錯誤。具體而言，MOCOM 透過最大化工作人員的錯誤檢測機率、與測試任務的相關性、工作人員的差異以及最小化測試成本來推薦眾包工作人員。我們透過實驗評估了 MOCOM 532 測試任務，結果表明 MOCOM 顯著優於五種常用和最先進的基線。此外，MOCOM 可以減少重複報告，並推薦相關性高、錯誤檢測機率大的工作人員；因此，它可以用較少的工作人員發現更多的錯誤。
指標項：眾包測試，眾工推薦，多目標最佳化
I 介紹測試是昂貴的。Brooks 說測試一個軟體系統將消耗所有軟體專案一半的資源。軟體工程的許多工作都集中在降低這一重大成本上。新的軟體開發方法已經被開發出來，以鼓勵更多和更快的測試。在其他工作中，研究人員提出了令人印象深刻但複雜的形式化方法，以便更好地表達需求，然後是自動化生成最新案例。Suchtools 只是在自己的領域獲得成功，它還需要非常熟練和非常稀缺的人力操作員。
眾包測試的問題是最佳化眾包工人（簡稱“眾工”）的參與度。人群資源雖然便宜，但不是免費的。因此，在擴充套件眾包測試時，有必要最大限度地提高來自群中每個成員的資訊增益。此外，如下圖所示，並非所有的人群工作者在發現蟲子方面都同樣熟練。不合適的員工可能會錯過錯誤，或報告重複的錯誤，而僱用他們需要不平凡的預算。此外，由於眾包工作人員的不可知性、廣泛性和不確定性，我們不應該讓所有的工作人員都參與眾包測試任務。因此，為測試任務推薦一組合適的群組工作人員是非常有價值的，這樣可以用較少的工作人員檢測更多的軟體錯誤。
長期以來，為特定的軟體工程任務尋找合適的工作人員被認為是非常重要和寶貴的。關於員工推薦的相關研究有很多，如 bug 分類、導師推薦和專家推薦。隨著眾包的出現，有一些研究集中在開發人員對眾包軟體開發的推薦。上述研究要麼推薦一個工人，要麼假設推薦的工人是相互獨立的。然而，在眾包測試中，需要推薦一組工作人員來完成測試一起工作。而且因此，推薦的一組工作人員相互依賴，因為他們的表現可以共同影響最終的測試結果。
我們之前的工作提出了三種不同的方法來推薦一組眾包測試任務的眾包工作者。然而，他們中的每一個都只是部分地探討了眾包工作者的特徵以及眾包測試中 bug 檢測的影響因素。如我們的實驗所示，充分探索人群工作者的特點和影響因素將帶來以往工作中所見的更好結果。
為了改進群體工作者推薦的實踐，我們首先提出了一種新的群體工作者特徵，它可以支援更有效的群體工作者建議。詳細說明我們從三個維度來刻畫眾工，即測試情境、能力、能力，和域知識。測試上下文包含裝置人群工作者的典範，她/他的裝置的作業系統和 ROM，以及網路環境。能力代表從眾工的歷史測試中抽象出來的能力行為。它包含提交的報告的數量，檢測到的錯誤的數量和百分比。領域知識表示群組工作人員透過執行過去的測試任務而獲得的領域經驗。我們使用從她/他的歷史提交報告中提取的描述性術語來表示她/他的領域知識。
基於群組工作者的特點，提出了多目標群組工作者推薦方法（MOCOM），該方法的目標是推薦一組最小的群組工作者來幫助檢測一個群組測試任務中最大數量的 bug。具體而言，MOCOM 透過最大限度地提高所選工作人員的缺陷檢測機率、與特定測試任務的相關性、工作人員的多樣性以及最小化測試成本來推薦群組工作人員。在這四個目標中，我們建立了一個機器學習模型來學習每個工人的錯誤檢測機率。學習者使用的特徵是群體工作者的能力，其中我們還考慮了與時間相關的因素來更好地模擬錯誤探測機率。對於與特定測試任務的相關性，我們計算工作人員的領域知識和測試任務要求之間的餘弦距離。人群工作人員的多樣性是根據他們的測試背景和領域知識的差異來衡量的。測試成本主要包括對群組工作人員的獎勵，並根據推薦工作人員的數量來衡量，這是現實群組測試平臺中的常見做法。
基於搜尋的軟體工程（SBSE）是軟體工程中解決多目標最佳化問題最常用的技術之一。因此，我們利用一個廣泛使用的基於搜尋的演算法，即 NSGA-II，來最佳化推薦群組工作者時的四個目標。
II 背景與動機2.1 背景圖 1 眾包測試流程
本節簡要介紹了眾包測試的背景，以幫助更好地理解我們在實際工業眾包測試實踐中遇到的挑戰。圖 1 展示了眾包的整體流程測試專案經理為眾包測試提供測試任務，包括測試下的軟體和測試需求。眾包測試任務通常採用開放呼叫和激勵條款的格式，因此大量眾包工作人員可以根據其測試需求登入執行任務，並要求提交眾包測試報告。專案經理檢查提交的測試報告，確認是否進行除錯和退出。請注意，並非每個測試報告都涉及一個 bug，不同的報告可能描述同一個 bug（即重複的報告）。
為了吸引員工，眾包測試任務通常經濟補償常用的支付模式包括按參與支付、按錯誤支付和按第一個錯誤支付。這項工作是基於付費參與模式，在這個模式中，參與測試任務的工人得到同等的報酬。它是一種常用的支付模式，特別是對於新推出的平臺，因為它可以鼓勵人群工作者的參與。在第 7.3 節中，我們將從其他支付模式的角度討論建議的方法的有用性。
表 1 眾包測試任務、測試報告和眾包工作者的示例
目前，在大多數眾包測試平臺中，在參與眾包測試之前，工作人員需要從大量釋出的測試任務中搜索合適的測試任務來執行。這種模式對於錯誤檢測是無效的，原因有兩個：第一，工作人員可能會選擇自己不擅長的測試任務，這不能保證測試的質量；第二，一個測試任務可能會被許多經驗或專業知識相同的工作人員執行，這會導致許多重複的錯誤和資源浪費。
2.2 重要概念我們介紹了眾包測試中的三個重要概念：測試任務、測試報告和眾包工作者。
測試任務是由任務釋出者提供的對測試平臺的輸入。它包含任務 ID、任務名稱、測試需求（主要是用自然語言編寫的）和被測軟體（本工作中未考慮）。表 1 顯示了一個測試任務的示例。
測試報告是群組工作人員在測試任務完成後提交的測試結果。它包含報告 ID、工作人員 ID（即提交報告的人）、任務 ID（即執行哪個任務）、如何執行測試以及測試期間發生了什麼的描述、錯誤標籤和重複標籤。表 1 顯示了一個測試報告的示例。具體而言，標籤由專案經理指定，以指示報告是否包含“錯誤”1（即錯誤標籤），以及報告是否“重複”（即重複標籤）。需要注意的是，在下面的文章中，由於報告中包含 bug，我們稱之為“bug 報告”（也簡稱“bug”），而在測試任務中提交的任何報告（包括 bug 報告和沒有 bug 的報告）都稱之為“測試報告”（也簡稱“報告”）。
群組工作者是在眾包測試平臺中註冊的工作者，透過工作者 ID、她/他的上下文屬性（例如，裝置模型）進行描述。平臺還記錄工作者的歷史測試報告。一項測試任務可以由成百上千的群眾工作者來完成。
圖 2 百度眾測資料集統計
2.3 百度眾測資料集我們從一個行業眾包測試平臺，即百度眾包測試收集眾包測試資料。百度眾測成立於 2011 年，已成為中國最大的眾測平臺之一。
我們收集了 2015 年 1 月 1 日至 2016 年 8 月 1 日期間結束的測試任務。當人群工作者在平臺上註冊時，他/她會被要求籤署一份保密協議。這意味著所有提交和生成的資料都可以應用於科學研究。此外，當我們從這個平臺收集資料時，所有與個人隱私有關的資訊（如姓名、年齡、電話號碼、職業）都被加密。
總共分析了 562 項測試任務，涉及 2405 名擁擠的工人和 78738 份測試報告。對於每個測試任務，我們收集了它的任務相關資訊和所有提交的測試報告（見表 1 中的示例）。我們還收集了所有相關的人群工作者和相關資訊（見表 1 中的示例）。
圖 2 顯示了每個測試任務的參與人員、提交的報告和唯一的 bug（即，不重複的 bug 報告）的統計資訊。
為了瞭解真實的眾包測試實踐，我們對收集的資料集進行了分析，觀察結果將在下一小節中顯示。
III 相關工作3.1 眾包測試眾源測試，作為軟體開發的一種新實踐，已經被應用於生成測試用例，測量軟體產品的真實效能，幫助可用性測試，檢測和重現與上下文相關的 bug。以上研究都是利用眾包測試來解決傳統軟體測試活動中存在的問題。然而，我們的方法是解決眾包測試實踐中遇到的新問題，即眾包測試任務的工作人員推薦問題。
其他一些研究側重於解決眾包測試實踐中遇到的新問題。Feng 等人提出了眾包測試的測試報告優先排序方法。他們設計了策略，動態地選擇風險最大且多樣化的測試報告，以便在每次迭代中進行檢查。Wang 等人提出透過從訓練集中選擇相似的資料例項來構建一個分類器，用於識別實際揭示錯誤的測試報告，從而緩解眾包報告分類中的分佈差異問題。後來，DARS 被提議利用深度學習技術來克服眾包報告分類中跨領域的資料分佈差異。
圖 3 基於百度眾測資料集的觀測
我們之前的工作提出了三種不同的方法來推薦一組眾包測試任務的眾包工作者。具體地說，Xie 等人建議 Cocoon 為測試任務推薦一組人群工作者。它是一種鴿貪心方法，能夠在上下文約束下達到預期的測試上下文覆蓋率和最大的測試質量。Cui 等人提出了 ExReDiv，一種群體工作者選擇的混合方法，它透過平衡工作者的測試經驗、測試任務的專業知識以及他們的專業知識多樣性來推薦群體工作者。同時，Cui 等人提出了 MOOSE，它透過最大限度地覆蓋測試需求和所選工人的測試經驗，並最小化成本，來推薦擁擠工人。
以上三種方法中的每一種都只是部分地探討了眾包工作者的特徵以及眾包測試中 bug 檢測的影響因素。首先，Cocoon 更多地關注測試環境，而較少關注對測試效能至關重要的員工特徵（如能力、過去的經驗）。其次，ExReDiv 和 MOOSE 都沒有考慮人群工作人員的測試環境（例如，裝置模型），這已被證明對測試結果有影響。第三，ExReDiv 和 MOOSE 將檢測到的 bug 數量視為員工的經驗；然而，員工的經驗也可以與其他屬性相關聯，例如他提交的報告、參與專案的數量、檢測到的 bug 的百分比。第四，這三種方法都沒有考慮時間對員工缺陷檢測績效的影響（例如，員工過去 2 個月的經驗與員工過去 12 個月的經驗）。然而，先前的研究表明，線上開發者最近的活動對其未來行為的指示作用要比很久以前發生的活動更大。因此，考慮這些與時間相關的因素可以潛在地提高工作者推薦的效能。
綜上所述，本研究與現有研究的不同之處在於：
•
本研究提出了一種新的群體工作者特徵，它考慮了群體工作者的背景、能力和領域知識，而以往的研究只考慮其中的一個或兩個。
•
這項工作提出了一種新的多目標工人推薦方法，該方法基於人群工人的新特徵，可以產生以前工作中見過的更好的結果。
•
這項工作基於多種特徵對人群工作者的經驗進行建模，並考慮時間對其經驗的影響，這被證明是有效的。
3.2 員工推薦軟體開發已經成為一項越來越開放的活動，利益相關者通常來自不確定的公眾。為一個特定的軟體工程任務尋找合適的員工變得非常重要和寶貴。有許多相關的研究可以為各種軟體工程任務推薦工作人員，例如 bug 分類、導師建議和專家建議。
隨著眾包的出現，有一些研究集中在眾包軟體開發的開發者推薦上。Yang 等人提出了一種新的方法，即 PSF 博士，透過利用個性化的原始碼檔案來增強開發人員的推薦。Mao 等人採用基於內容的推薦技術，在眾包軟體開發過程中自動匹配任務和開發人員。Yang 等人提出了一種基於分析的決策支援方法來指導員工推薦眾包開發。
上述研究要麼推薦一個工人，要麼假設推薦的工人是相互獨立的。然而，我們的工作推薦了一組相互依賴的員工，因為他們的表現會共同影響最終的測試結果。
3.3 測試用例選擇和優先順序排序在軟體測試領域，先前的另一系列研究集中在測試用例的選擇和優先順序劃分，這也涉及到用較少的測試成本發現更多的 bug。然而，由於以下原因，這些方法很難應用於群體工作者推薦。首先，現有研究大多提出了白盒方法，這種方法依賴於結構化覆蓋資訊原始碼（如方法覆蓋、語句覆蓋或分支覆蓋），但由於業務的機密性，眾包測試平臺無法獲取被測應用的原始碼，更別說報道了。
其次，最近的一些研究提出了只使用測試用例而不需要測試程式的黑盒選擇方法，他們利用測試用例的語言資料（例如他們的內部名、註釋、字串），選擇了不同語言表示的測試用例。這樣的處理方法不能很好地捕捉群體工作者的整體特徵，很難達到良好的 bug 檢測效果。
另一種黑盒選擇方法是學習測試用例的 bug 暴露機率，並選擇這些觸發 bug 的機率更高的測試用例。然而，機器學習學習者使用的特徵是從測試用例程式碼中提取出來的。在眾包測試中，我們需要處理的是眾包工作人員而不是程式碼。
儘管上述方法很難解決群體工作者推薦問題，但它們激勵我們設計群體工作者推薦方法，即選擇具有較大缺陷檢測機率和不同特徵的工作者。此外，我們還選擇了兩種最先進的方法作為評價 MOCOM 的基線。
IV 多目標人群工作者推薦方法（MOCOM）4.1 人群特徵在這項工作中，我們從三個維度來描述群體工作者，即測試上下文、能力和領域知識。以下小節說明了這三個維度的細節。
4.1.1 測試環境
測試上下文表示群組工作者擁有的硬體（例如，裝置模型）、軟體（例如，裝置的作業系統）和環境（例如，網路環境）。我們之所以將測試情境視為群體工作者的一個特徵，是因為群體工作者通常在其特定情境下執行測試任務，這會影響測試結果。
我們使用四個屬性來描述測試上下文一個擁擠的工人。他們是擁擠的工人用於執行測試任務的裝置模型、裝置模型的作業系統、裝置模型的 ROM 型別以及執行測試任務的網路環境。這些屬性是百度眾測平臺記錄的測試內容的完整集。因此，我們利用它們來刻畫群體工作者的特徵，並在工作者推薦過程中加以考慮。請注意，這些屬性由其他流行的眾測平臺共享，因為這些平臺需要這些屬性來重現被測應用程式的 bug。即使對於不具備所有四個屬性的眾測平臺，他們也會呼叫其他類似的測試上下文來構建 bug 機率預測模型，並將模型應用到自己的案例中。
4.1.2 能力
能力代表人群工作者從其歷史測試結果中提取的能力。人群工作者過去的表現可以在很大程度上反映其能力，並對其未來的錯誤檢測表現有很大的指示作用。因此，我們認為能力是表徵人群工作者的一個基本維度。
我們使用以下屬性來描述人群工作者的能力，即：
•1）工人參與的專案數量
•2）工人提交的測試報告數量
•3）工人提交的缺陷報告數量
•4）審查工人提交的缺陷報告百分比計算為工人提交的缺陷報告數量除以提交的測試報告數量由工人負責。
•5）檢查工作人員 IT 計算機上重複錯誤報告的程度，重複索引由工作人員提交的錯誤報告數量劃分。其中，
其中 r 是工人提交的 bug 報告，r 的 duplicates 是測試任務中報告 r 的個數。例如，表 1 中的 worker W5124983210 提交了兩個 bug 報告 R1002948308 和 R1037948352，其中 R1002948308 有 2 個副本，R1037948352 有 6 個副本。則 worker W5124983210 的重複 bug 百分比為（1/2+1/6）/2。我們之所以不直接使用重複數除以錯誤報告數，是因為我們不僅要表示重複數，還要區分重複程度（即使用重複索引）。
4.1.3 領域知識
表 2 眾包工人特徵
領域知識表示群組工作人員透過執行測試任務獲得的領域經驗。被測試的應用程式通常來自不同的領域，他們要求具有特定領域知識的人群工作者更好地探索其功能。我們還觀察到，群組工作人員在執行他們熟悉的任務時更容易發現 bug。這就是為什麼我們把領域知識作為描述群體工作者的另一個重要標準。
我們使用從一個工人的歷史提交的報告中提取的“描述性術語”來表示他/他的領域知識和表示儲存。下面我們對如何獲得描述性術語進行詳細的描述。
我們首先根據培訓資料集中的所有任務構建一個描述性術語列表（見第 5.2 節）。我們進行分詞並去除停止詞（即，on，the）以減少噪聲。除此之外，我們發現一些術語可能出現在大量的報告中，而另一些術語可能只出現在很少的文件中。這兩種方法都不太具有預測性，並且在人群建模中貢獻較少。因此，我們根據出現術語的報告數量（即文件頻率，也稱為 df）對術語進行排序，然後過濾 5%文件頻率最高的術語和 5%文件頻率最低的術語。注意，我們在閾值為 2%到 20%的情況下進行了實驗，結果表明，在閾值為 5%的情況下，worker 推薦效能（即 k 處的 bug 檢測率）可以達到一個相對較高且穩定的值。另一個需要注意的是，由於測試報告通常很短，資訊檢索中另一個常用的度量術語 frequency（也稱為 tf）沒有區分性，因此我們只使用文件頻率對術語進行排序。這樣，就形成了最後的描述性術語表 V。
其次，我們從一個群體工作者的歷史報告中提取詞彙，並將這些詞彙與描述性詞彙表進行對映，得到表徵其領域知識的描述性詞彙。
在表 2 中，我們總結了上面提到的所有屬性。我們還提供了一個基於群組 worker W5124983210 的每個屬性的示例（在表 1 中）。我們將使用這些屬性來描述群組工作人員的特徵並度量目標。
4.2 四個目標的衡量由於群組工作者推薦的目的是幫助用較少的群組工作者發現更多的 bug，因此 MOCOM 的設計考慮了四個目標。
首先，我們應該推薦具有最大錯誤檢測機率的群組工作人員，因為他們可以潛在地提高錯誤檢測效能。
第二，我們應該為那些在測試任務中擁有最大相關專業知識的員工尋找合適的人選，因為他們有更多的背景知識，並且可以提高 bug 檢測的可能性。這也是因為眾包任務具有複雜性和使用者驅動性，因此我們應該考慮工作人員與任務的相關性，從而提高 bug 檢測效能。
第三，我們應該選擇具有不同特徵的工作人員，因為不同的工作人員可能會探索被測試應用程式的不同領域，這將有助於檢測更多的錯誤並減少重複報告。
最後但並非最不重要的是，我們應該考慮測試成本，這是眾包領域的一個重要考慮因素。
以下小節將詳細說明這四個目標。
4.2.1 目標 1：最大化人群工作人員的錯誤檢測機率
我們建立了一個機器學習模型來學習每個工人的錯誤檢測機率。建立模型的主要目的是確定哪些特徵可以用來學習 bug 檢測機率。
表 3 機器學習模型特徵
基於第 2.4 節的發現，我們假設人群工作者的能力與缺陷檢測機率密切相關。因此，我們將群體工作者的所有能力相關屬性作為機器學習模型的特徵。
除此之外，以前的工作證明了開源開發人員最近的活動對其未來行為的指示作用要比早在之前發生的活動更大。因此，我們進一步考慮與時間相關的因素，更好地模擬人群工作者的過往經驗。以其中一個提交報告的能力屬性數為例，我們還提取了過去 2 周提交的報告數、過去 1 個月提交的報告數和過去 2 個月提交的報告數。我們之所以使用這三個時間間隔，是因為我們的資料集顯示，超過 75%的人群工作者過去的活動發生在過去 2 個月。
這樣，原來的一個屬性（即提交的報告數量）可以在機器學習模型中產生四個特徵，而原來的能力屬性表 2 可以在我們的學習模型中產生 20 個特徵（如表 3 所示）。
此外，我們在機器學習模型中採用了另一種與時間相關的特徵。它是群組工作人員在這個平臺上的最後一次提交和測試任務的開始時間之間的時間間隔，以天數度量。直觀地說，這個時間間隔越長，群組工作人員參與這個任務的可能性就越小。
總之，我們在表 3 中列出了機器學習模型中使用的所有上述 21 個特徵。我們採用 Logistic 迴歸作為我們的機器學習模型，這在軟體工程的許多不同類別的任務中被廣泛報道為有效的。基於在訓練資料集上訓練的 logistic 迴歸模型，在測試資料集中給定一個任務，可以得到其對所有候選工作人員的 bug 檢測機率。具體而言，對於一組候選群組工作人員，我們將其在給定測試任務上的錯誤檢測機率相加，並將其總和視為測試任務的錯誤檢測機率。
4.2.2 目標 2：最大化人群工作者與測試任務的相關性
為了達到相關性目標，我們需要測量候選人群與測試任務之間的相關性。
我們使用工作人員的知識和測試任務之間的相似性來表示相關性。它是根據人群工作者領域知識的描述和測試任務需求的描述術語之間的相似性來計算的。相似度越大，表示工作人員的領域知識與測試任務的相關性越強。我們之所以使用餘弦相似度，是因為過去的研究已經證明了它在高維文字資料中的有效性，這正是我們的情況。
給定一個特定的測試任務，為了獲得一組候選人群工作人員的相關性（即第 4.3 節中的一個解決方案），我們首先將所有選定工作人員的領域知識作為一個統一的向量，然後計算兩個向量和測試任務要求之間的相似度。
4.2.3 目標 3：最大化人群工作者的多樣性
為了不同的目標，我們需要測量一組選定人群工人的不同程度。回顧 4-h 目標 2（即最大化相關性）旨在找到熟悉測試任務的員工。除此之外，軟體測試的性質要求不同的工作人員能夠幫助探索應用程式的各個部分並減少重複報告。因此，目標 3（即最大化多樣性）旨在發現工人這是個大背景。注意儘管這兩個目標似乎相互矛盾，但本文所採用的多目標最佳化框架有助於在相關性最大化和多樣性最大化之間達成平衡。
任何多目標最佳化器的一個重要目標都是多樣性，即生成跨越機率空間的解，這被公認為。因此，許多最佳化演算法都內建了專門的多樣性運算元以核心行動為例,然後，在這項工作中使用的 SGAII 最佳化器採用了一種新的空間剪枝運算元，該運算元努力分散它生成的答案。請注意，NSGA-II 的多樣性是目標空間中的多樣性。
除了輸出空間中的目標多樣性（即探索不同的解決方案）之外，輸入空間中的屬性多樣性（即在解決方案中尋找不同的工作者）。我們之所以需要屬性多樣性，是因為 NSGAII 的客觀多樣性運算元對於我們來說是不完整的，因為第 2.4 節中的觀察激勵我們推薦一組不同的員工（即屬性多樣性）。此外，實驗結果（第 6.3 節）表明，如果禁用屬性多樣性，則效能將急劇下降。
為了探索屬性的多樣性，我們使用基於計數的方法來測量它，並計算在所選的一組工作人員中有多少不同的屬性值（即第 4.3 節中的一個解決方案）。
請記住，群組工作人員具有三個維度的特徵：測試上下文、能力和領域知識。在能力維度上，考慮多樣性是不合理的，因為我們要求所有被選中的工人都有能力，而不是一部分人有能力而另一部分人沒有能力。因此，我們基於群體工作者的測試情境和領域知識兩個維度來計算多樣性。
具體來說，為了測試上下文，我們計算了一組 worker 中包含了多少不同的電話型別、作業系統、ROM 型別和網路環境。對於領域知識，我們統計在工作者的領域知識中出現了多少不同的術語。
請注意，測試上下文只有四個屬性，而領域知識有數千個屬性（即唯一描述性術語的數量）。為了消除不同數量的屬性對多樣性度量的影響，我們分別計算測試上下文和領域知識的多樣性，然後使用權重引數獲得最終的多樣性值。我們用不同的權重進行了實驗，它的權重不超過 0.5（即測試上下文和領域知識同等對待）就可以得到相對好的結果以及穩定的表現。所以呢我們在評估中使用這個權重。
4.2.4 目標 4：儘量降低測試成本
在為眾包任務推薦員工時，成本是一個不可避免的目標。眾包測試最重要的成本是對員工的獎勵。我們假設所有參與測試任務的員工都獲得同等報酬，這是現實世界眾包測試平臺中的常見做法。這樣，一組選定工人的成本（即第 4.3 節中的一個解決方案）就可以作為其規模來衡量。
4.3 多目標最佳化框架
我們在第 4.2 節中提到，MOCOM 需要最佳化四個目標。顯然，很難同時獲得所有目標的最佳結果。例如，為了最大限度地提高 bug 檢測機率，我們可能需要僱傭更多的群組工作，因此，犧牲了第四個目標，即最小化測試成本。我們提出的 MOCOM 尋求一個 Pareto 前沿（或一組解決方案）。帕累託前沿以外的解不能支配前沿內的任何解。
MOCOM 採用 NSGA-II 演算法（即非支配排序遺傳演算法 II）對上述四個目標進行最佳化。NSGA-II 是一個廣泛應用的多目標最佳化和自動軟體工程領域。根據，軟體分析中 65%以上的最佳化技術是基於遺傳演算法（針對單目標問題）或 NSGA-II（針對多目標問題）。有關 NSGA-II 演算法的更多詳細資訊，請參見。
在我們的群組工作者推薦場景中，帕累託前沿代表了 NSGA-II 確定的四個目標之間的最佳權衡。然後，測試人員可以檢查帕累託前沿，以找到最佳折衷方案，即選擇一個群體工作者來平衡錯誤檢測機率、相關性、多樣性和測試成本，或者選擇一個群體工作者來最大化一/二/三個目標，懲罰剩餘的一/二/三個目標。
MOCOM 有以下四個步驟：1）解決方案編碼。與其他推薦問題一樣，我們將每個 worker 編碼為二進位制變數。如果選擇 worker 時，值為 1；否則，值為零。解被表示為一個二進位制變數向量，其長度等於候選群組工作人員的數量。群組工作者推薦問題的解空間是所有可能組合的集合，無論是否選擇了每個群組工作者。2） 初始化。初始總體是隨機初始化的，即在所有可能的解（即解空間）中隨機選擇 K（K 是初始總體的大小）解。根據的建議，我們將 K 設為 200。3） 遺傳運算元。對於解決方案的二進位制編碼的演變，我們利用了中描述的標準運算子。我們使用單點交叉，位 flip 變異來產生下一代。我們使用二元競賽作為選擇運算元，其中兩個解是隨機的，兩個解中的一個將在下一個種群中生存。4） 健身功能。由於我們的目標是最佳化四個考慮的目標，因此每一個目標都是透過第 4.2 節中描述的目標函式來評估的。對於錯誤檢測機率、相關性和多樣性，這些值越大，解決方案的收斂速度就越快。測試成本得益於較小的值。
V 結論在密集源測試中，為測試任務推薦一組合適的眾工是非常有價值的，這樣就可以用更少的工人檢測到更多的軟體錯誤。我們首先提出了一種新的人群工作者特徵，它可以支援更有效的人群工作者推薦。我們用三個維度來描述群體工作者，即測試上下文、能力和領域知識。在此基礎上，本文提出了多目標群體工作者推薦方法（MOCOM），即為一個眾包測試任務推薦最少數量的群體工作者來檢測最大數量的 bug。具體而言，MOCOM 透過最大化工作人員的錯誤檢測機率、與測試任務的相關性、工作人員的多樣性和最小化測試成本來推薦群組工作人員。
我們對 562 項來自中國最大的眾包測試之一的測試任務（涉及 2405 名工作人員和 78738 份測試報告）進行了實驗評估實驗結果表明我們的 MOCOM 在更少的人群中檢測到更多的蟲子，其中 24 名工作人員的中位數可以檢測到 75%的潛在危險錯誤。所有目標都是工作建議所必需的因為取消任何目標都會導致績效顯著下降。此外，我們的方法也顯著優於五種常用的和最先進的基線方法，在 BDR@20 上平均提高了 19%至 80%。