眾包軟體測試（CST）是軟體測試中的一種新興趨勢。公司和開發人員透過 CST 平臺將測試任務分配給數千個線上測試人員。當前，CST 平臺管理人員正在努力尋找並解決挑戰，以達到最佳的 CST 做法。 CST 平臺已經應用了許多功能來改善 CST，包括通知電子郵件，線上聊天室，論壇，最重要的是，CST 平臺儀表板可以檢視所有測試專案和任務；這些功能使 CST 可以有效執行。儘管如此，CST 使用者發現很難及時瞭解測試專案更新。這與文獻中越來越多的研究保持一致。這項研究旨在透過尋找並克服潛在的過程限制來支援 CST。為此，我們採用了五個階段的方法：首先，透過審查 15 個 CST 平臺對 CST 的當前過程進行了研究。其次，確定了八項可能的改進 CST 的活動;其中選擇了六項在向第三階段的 30 名領域專家進行了調查之後，在第 4 階段，我們在基於 Web 的系統中設計和實現了五個流程模型，這些模型可以滿足之前確定的六項活動的需求。在第 5 階段中，我們透過與兩個 CST 平臺的代表和專家測試員進行訪談，並與使用該系統並評估過程價值的 20 名領域專家進行了基於場景的評估，從而評估了這些過程模型。結果表明，新的改進是合理的，可以加強 CST 的實踐。
引言沒有質量保證階段，軟體開發週期是不完整的。 質量保證的主要目標是確保產品達到或超過客戶期望。多年來，軟體開發領域出現了許多質量保證方法，策略和原則，例如單元測試，功能測試，系統測試，移動測試等。
軟體開發從業人員一直在努力，如何在短時間內以有效的成本獲得最佳的測試質量。 軟體組織有兩種測試實施策略：一種是建立內部質量部門，由員工，裝置和維護人員組成；第二種是將質量任務外包給另一個實體。 然而，該解決方案也是昂貴且複雜的，並且花費大量時間和精力。 兩種策略都侷限於少數測試人員的知識，因此在質量和效率方面都受到限制。 此外，兩種策略都無法清楚地瞭解預期的終端使用者對軟體的看法和期望。
隨著眾包現象的出現，軟體開發人員和投資人已將其用於提供眾包軟體開發測試解決方案。眾包軟體測試（CST）克服了舊方法的許多挑戰，透過 Web 2.0 技術與眾人合作，使效率更高。 分散式線上問題解決和生產模型，可擴充套件全球勞動力的好處，同時降低了執行成本。
本質上，眾包軟體測試使測試人員和客戶在軟體質量保證階段遍佈全球，並透過測試平臺進行溝通。這推動了 CST 提供者採用技術來實現測試流程並改善結果。在眾包專案中，團隊進行協調更好的則更有可能表現得更好。因此，在 CST 活動中的協調將有助於避免延誤，節省時間並提高測試團隊的意識。CST 平臺已使用許多功能來協調 CST 活動，包括通知電子郵件，線上聊天室，論壇，最重要的是，CST 平臺儀表板可檢視所有測試專案和任務；這些功能使 CST 得以有效執行。
為了克服眾包協調的挑戰，本研究旨在透過開發基於計算機的系統來支援眾包活動的有效管理。為此，使用了五個階段的方法：首先，透過使用研究 15 個 CST 平臺中的協調關係 30 的方法來研究 CST 的當前過程。第二，審查結果確定了八項可能的活動，以改善眾包；在第 3 階段向 30 位領域專家進行調查後，選擇了其中的 6 個。在第 4 階段，我們在基於 Web 的系統中設計和實現了五個過程模型，可以滿足對先前確定的六個活動的需求。在第 5 階段中，我們透過與兩個 CST 平臺的代表和一位專家測試員進行訪談，並與使用該系統並評估過程價值的 20 位領域專家進行了基於場景的評估。結果表明，新的改進是合理的，可以增強 CST 的實踐。本文分為以下幾部分：第 2 節介紹了 CST 的背景，同時在本節中討論了相關工作。第 3、4 節介紹了 whileSecs 的方法。 5–9 顯示了該研究的五個階段。最後，第 10 節是對本文的總結。
2 背景2.1 眾包軟體測試眾包軟體測試是軟體測試中的一種新興趨勢。公司和開發人員透過 CST 平臺將測試任務分配給數千個線上測試人員。因此，為工人提供了更多的工作機會和額外收入，為僱主提供了低成本的快速，高質量的服務。Leicht 等人將眾包軟體測試描述為“眾包在軟體開發領域的特定應用”。它指的是將軟體測試活動外包給一個人群。
與傳統的基於實驗室的測試相比，眾包測試有很多優勢，包括快速，便捷地招募真正的終端使用者作為參測試人員，而不是透過傳統的方式要求終端使用者來參加測試。在實驗室測試中，整個測試過程可能需要花費數週的時間，特別是如果客戶/使用者在不同的地點，並增加了旅行，問候和準備時間，而在眾包測試中，整個過程可以在數小時內完成。此外，由於節省了測試人員的支出，以及服務商，差旅，實驗室和裝置的支出，眾包測試的總成本大大降低了。因此，低成本測試允許更多的測試迭代，更多的測試改進和更多的測試人員。最後，來自世界各地的眾包測試參與者都很容易地與來自不同背景的參與者一同測試。這對於國際網站和應用程式特別有用。
在管理 CST 活動的內容中，所有三種依賴關係型別都存在，例如：
•
適合依賴：當許多測試人員在測試周期中共同工作以生成最終測試報告時，就會出現這種依賴關係。
•
流程依賴：CST 流程包括一系列順序步驟，以便獲得最終的測試結果。
•
共享依賴關係：CST 平臺使用共享的測試環境，並在其中進行所有測試活動的人群測試人員。
2.2 合作的概念合作是軟體開發的重要方面。 Mintzberg 指出：“從陶器製作到登陸月球，每一種有組織的人類活動都產生了兩個基本的、相反的要求：將勞動劃分為要執行的各種任務，以及合作完成任務的各項任務。為了實現成功的軟體系統，需要在軟體開發週期中進行充分合作。但是，這種合作很難實現，尤其是當專案複雜性由於團隊分散而增加時。
瞭解合作的概念將在本研究的後面部分中用於研究眾包軟體測試過程中涉及的合作依賴性，並建議改進過程（有關更多細節，請參見第 6 節）。
3 方法我們研究的目的是調查 CST 實踐的當前過程，並研究該過程的可能進展。 為了實現這一目標，研究分為以下幾個階段：
第 1 階段：調查當前的 CST 過程：我們對 15 個 CST 平臺進行了全面調查。評審結果在參考文獻中給出。
第 2 階段：確定潛在的改進：根據第 1 階段的審查，我們在這一階段提出了一系列改進措施，我們認為這可能會增強 CST。
第 3 階段：評估建議的支援：透過分發給 30 個領域專家的調查評估提議的活動。
第 4 階段：設計和實現：在此階段設計和實施已商定的活動。
第 5 階段：最終評估：在此階段，將使用 20 名領域專家進行深入訪談和基於情景的評估來評估已實施的功能。
4 第 1 階段：調查當前的 CST 過程為了理解 CST 過程，參考文獻中對當前平臺進行了調查。對目前的 CST 提供者進行了搜尋。 該研究僅關注主要用於軟體測試的平臺，因此，不包括通用眾包平臺。我們用來選擇平臺的步驟如下：
•
步驟 1：為現有的 CST 平臺建立候選池：
•
•
步驟 3：根據有關影響最大的平臺的可用資料對平臺列表進行排序。
結果發現，所有 CST 平臺都遵循一個通用過程，可以從一個高階角度來檢視和理解。該過程可以分為三個階段，如下所示：
•
提交測試專案：從客戶提交新的測試專案請求開始。
•
設計測試周期並執行測試：客戶上載實際的測試專案，專案經理會進一步審查該測試專案，以設計測試周期，定義開始和結束日期以及測試團隊負責人（TTL）。
•
完成測試過程：客戶確定接受和拒絕的錯誤，然後專案經理準備測試報告，該報告通常包括所探查的缺陷，測試人員的反饋，測試摘要和建議。
5 第 2 階段：確定潛在的改進為了提供過程改進，我們使用了研究協調依賴性的方法。這種方法在文獻中得到了廣泛的使用。我們遵循 Crowston 和 Osborn 提供的啟發式方法，對一種情況下的依賴關係和協調機制進行分析，從而進行以依賴為重點的分析。他們提出了這一程式：確定依賴關係，然後搜尋協調機制。換句話說，查詢依賴關係，然後詢問使用哪種協調支援來管理那些依賴關係。 Crowston 和 Osborn 建議提出以下問題，以發現依賴關係和協調機制：
•
每個活動的輸入/輸出是什麼（例如，資訊和其他必要的前提條件/後置條件）
•
這個過程和問題是否反映了未管理的依賴性？
兩位研究人員都檢查了該過程中涉及的每個活動，以瞭解如何更好地執行該活動。建議的協調改進清單經過多次修訂，直到兩位研究人員清單達成一致為止。該清單僅包括兩位研究人員認為透過引入新的協調機制可以提供可能的改進的活動。提議的協調支援可以幫助加快流程並提高流程效率和質量。這導致了對所涉及活動的新的協調機制，例如自動化，定製通知和提醒，它們可能會支援整個過程。
6 第 3 階段：評估建議的支援為了評估對提議支援的需求，已向 30 位領域專家進行了調查。 該調查是透過連結到 CST 論壇和社群的領域專家分發的。 此外，該連結還使用以下標籤在 Twitter 上釋出：#Crowdsourcedtesting #crowdsourcing #testing。還向頂級測試人員傳送了私人訊息，該調查包括兩個部分。 第一部分詢問背景資訊，例如職稱，經驗和所使用的 CST 工具。 第二部分提供了與科技委相關的活動清單，建議為此提供支援。要求受訪者對他們是否支援必要的程度進行評分。
7 第 4 階段：設計和實現本節介紹了 CST 活動的設計和實施，並討論了基於計算機的系統將如何提供第 2 階段中確定的所需支援。已為提議的活動建立了一套流程模型。 在之前的評估中。 這些模型提供了活動開發方式的直觀表示。這些模型在進入最終形式之前經歷了幾個週期。使用業務流程模型和符號（BPMN）建立了流程模型，該流程模型展示了活動流及其與不同角色的關係（即測試人員，專案經理和客戶）。
作為概念證明，已經開發了計算機系統以演示實現所提出的過程模型的可能性。 為了確保系統的可行性，已經實現了所有過程模型。已經使用了眾所周知的語言的 PHP 和 JavaScript 開發了一個基於 Web 的系統。 該資料庫是使用 MySQL 開發的，該 MySQL 與 PHP 相容並受其支援。 選擇這些語言的原因是可移植性和受歡迎程度。
8 第 5 階段：最終評估深度訪談是一種定性研究評估方法，可幫助研究人員收集有關其思想的詳細資訊，並有機會在輕鬆的氛圍中深入探索新問題。 訪談之所以有價值，是因為訪談是由在該領域工作的領域專家完成的。有人選擇了半結構化的訪談方法，因為它提供了共享思想的空間，同時使用開放式問題在特定主題上保持了對話過程模型，與參與者討論了實施的系統，以評估他們並聽取他們的想法和建議。
基於情景的評估（SBE）已作為評估所提出的過程模型的另一種方法。它提供了一種描述不同角色和系統之間具體相互作用的能力。場景具有可伸縮性和靈活性，足以考慮在空間，人員和時間上的分散式實踐。建議的評估方法是透過對真實場景進行的實際場景描述來進行評估。
9 總結本文透過提出一套旨在克服當前侷限性的過程模型來支援 CST 的有效管理。這項研究表明，CST 仍然需要進一步的支援。我們已經確定了八項可能的改進，其中六項已經開發。評估表明，這些改進是合理的，可以為 CST 增加價值。這項研究有助於促進 CST 的實踐，最終將有助於支援產生更好的測試質量。我們的發現表明，當前的 CST 平臺在管理 CST 流程方面還不那麼成熟，還有改進的空間。這可能是由於以下事實：眾包軟體測試活動的實踐相對較年輕，因為大多數 CST 公司都成立於之前十年。我們相信，隨著這些公司業務規模的不斷增長，隨著時間的推移，可以對本研究提供的工作進行進一步的擴充套件和擴充套件。例如，可以改進非活動測試人員的檢測方法，以提高效率。和先進的先進技術來監視使用者行為。此外，可以開發基於技術錯誤訊息儲存庫的自動報告系統；這些報告將幫助確定常見的技術問題及其在測試專案中的領域。