我成為
測試人員數年,在很多時候負載測試常常讓我感覺如芒刺在背。它需要花很長時間來實現一個定制的解決方案,但現代的方法模擬負載又并不是行之有效的。眾包測試在我看來就是一種負載測試;它可以使您在許多不同的環境中將一個特定的“東西”在大量的測試人員中測試。但就像所有類型的測試一樣,我相信它有一個適用的時間和地點。
讓數據說話
我最近參加的一個會議上展示了一個眾包測試最好的案例(盡管不是會議的目的)。讓我重現一下當時的場景。想象一下，一個在酒店舉行的超過800人參加的會議,再加上這是一個技術性會議。啟用無線設備的數量是大約每3位出席者就有一個。除此之外,許多與會者都入住該酒店,在他們逗留期間每個人都可以使用免費wifi。
當酒店人員在設置WIFI的時候，他能夠預期到如此大的使用量嗎？
第一天結束的時候，你并不能質疑酒店的服務。我們都有一個通過我們的房間門連接的不會收取費用的網絡。然而,作為一個參展商,這不是一個試圖證明使用云端的虛擬機的好時機。
與前面的示例不同,我認為有些情況下,應用
測試眾包形式確是不必要的。過去我曾經參與過得一個產品，發布測試周期大約為兩周。如何處理在許多遺留產品中常見的情況,這種問題又來了。有一些人建議眾包測試，把公司看作是服務提供者。然而，我相信這是一個濫用的詞了,而且它為大家建立了什么。產品是很復雜的,需要比較深入的理解才能確定一個問題是否實際上是一個問題,這不是一個典型的以用戶為中心的應用程序。它不是一個大眾市場的產品,設計語言環境和語言的多樣性是一個因素。它也并不是完美到用戶很難找到幾個被確認為是
Bug的產品，此情景下，關鍵問題確實發現的大量問題是否被記錄且反饋。
時間和地點
我們無可否認測試眾包的力量,事實上,它使不同的人,在不同的空間,測試在現實的真實世界的場景。但在努力加快測試的情況下,人們不應該選擇測試眾包。測試眾包有巨大的能量,但使用它時，應該經過一個深思熟慮的選擇,確保它是適當的技術。
關于作者
艾瑪·阿姆斯特朗(@EmmaAtester)是一個測試工程師，all-round do-gooder at Red Gate，他為軟件質量服務了超過13年。在此期間，她擅長手動和自動測試，從而有機會從編譯器深入到
web應用程序。
她精通于很多方法論,掌握了從處理底層芯片硬件技術到表層UI的技術,她除了管理測試團隊外，目前還參與到Red Gate最新的
軟件開發工具的
工作。
我成為測試人員數年,在很多時候負載測試常常讓我感覺如芒刺在背。它需要花很長時間來實現一個定制的解決方案,但現代的方法模擬負載又并不是行之有效的。眾包測試在我看來就是一種負載測試;它可以使您在許多不同的環境中將一個特定的“東西”在大量的測試人員中測試。但就像所有類型的測試一樣,我相信它有一個適用的時間和地點。