群體測試之未揭之秘

標籤：style   http   使用   io   strong   資料   for   2014   

Nivedita Nimmagadda是Next Education的QA經理，她有10多年的經驗。她主要對新技術，工具，流程和方法的研究和開發有興趣。她一直在跟進軟體測試的最新趨勢以將QA工作減到最少並提高生產力。她熱衷於智能工作，而不是埋頭苦幹。她管理項目時最強調過程，並對不同專案管理和測試管理工具的整合做出了重大貢獻。她曾評估過功能自動化工具，移動自動化工具和效能工具，並培訓和指導團隊建立過強大的自動化架構。

?

?

　　聽到“群體測試”一詞時，首先竄入你或大家腦海的是什麼呢？——一大幫人在測試你的產品。沒錯，wiki就是這麼定義它的，不同於傳統測試方法，群體測試是由許多不同地方的不同測試員執行的，而不是僱傭的顧問和專家。如果你是管理一員或在決策團隊裡又或者是一名專案經理，接下來你又會疑惑：

　　群體測試如何保證品質？
　　 群體是獨立的且作為一個使用者來進行測試：IT業務飛速變化，設計的產品也一樣。需要的服務越多，要交付的客戶就越多，你的產品要被經常測試的幾率越多，而QA周轉期就越少。一旦我們遇上QA團隊並試著理解失敗的原因，或多或少是開發員和同行影響了QA測試的方法。群體測試的一個好處是，因為它的QA不團隊合作且它也不受開發員影響，所以它或許可以發現QA團隊之前沒有發現的bugs，並從使用者的角度協助我們提升產品。在業內我們可以做到最好地去評估你的產品並建議改變，如果需要的話。不同的人和環境的群體測試：一個QA團隊有可能測試所有的裝置和環境。如果是移動，這就很對，因為移動市場一直飛速發展，也意味著引進了新裝置且軟體版本也要變化以適應業務需求。要戰勝這些挑戰並確保你的APP或網頁在所有環境或配置中正常運行，就讓群體去測試。群體在被廣泛使用的配置和環境中測試產品，由此減少了在一些特殊配置中失敗的風險。此外，我們甚至可以選擇不同年齡段的人，以確保APP或網頁對大多數高使用供應商，行動裝置，全球訊號強度有效。它有助於我們測試最實際的使用方法。快速的周轉時間：群體很適應如周轉時間很短時公司想僱傭大量測試員並驗證一個產品，而不是就為了這個目的去僱傭QA一類的需求。可以是一大群人同時在不同的裝置，作業系統和環境上測試你的應用程式。另外，如果應用程式太大無法測試的話，就可以把它分成子模組（微任務）並指定給一個群體使用者。

　　我如何知道我得到了什嗎？我是否得到了正確的群體嗎？
　　 正確的測試員：這是另一件管理必須要關注的事。誰要一個應用程式一個應用程式地去測試它。對於B2C應用程式，我們或許對覆蓋一系列有廣泛代表性的目標使用者會有興趣。我們或許想根據如年齡，受教育程度，文化，語言等選擇測試員。對於B2B應用程式，一些領域知識，專業技能和條件或許是有利的或必要的。大多數情況下，強烈建議選擇專業軟體測試工程師。QA品質：眾包測試僱傭的QA是不同領域的認證測試工程師。對單個測試員的提問，背景檢查及“beta測試”都在使用者通過其平台使用他們前就做好了。指定QA的方法根據公司而變化，且在給這些公司指派任務前就要把這些都檢查好。根據測試員的良好表現，測試員才能為那家公司工作。

　　提供的定價模式是怎樣的，它是如何幫我省錢的？
　　 和其他演變一樣，眾包演變的主要原因之一是為減少所需QA成本。不同的眾包公司採用不同的定價模式。一些公司基於以下付款模式或以下模型的組合來支付測試員，允許企業按每個錯誤每個應用程式的支付模式去付費：根據測試人員發現的bug數量及這些bug的影響來支付測試員。這是分配給選定的測試組的任務，反過來，根據所提出的可以增加產品品質的真正的bug數量支付測試員。公司有一個B2C應用程式時，該方法更有用，因為新手和專業測試人員都只需要以終端使用者的身份去進行測試。在B2B應用程式中，測試人員將需要大量的培訓和專業化，且發現的BUG在被交給開發人員前需要進行驗證。這有助於以較低的成本找到大量缺陷。每個任務都要為bug支付不同的價格，測試員可以在任務懸賞說明裡看到：項目都在（每個使用者在上面都有資格給測試價格投標報價的）雲公司網站上。出價最低的人獲勝並被指派去測試應用程式。測試人員之間的比賽：不是立馬給測試員提供金錢，而是要求測試員在多個部分上工作，且每個項目都有不同的規定。一旦測試員贏得了比賽，並取得了相應的信譽點數，然後一直積累兌換錢，同時也增加了他們被下一個項目選擇的機會。資源集區：一些群體解決方案只有用個人才能有所超越，他們甚至還可以用行動裝置來測試，且個人通過貢獻他們的裝置收穫金錢。這能讓公司避免承受購買多台裝置的高成本壓力。自動化工具很貴，基本小公司買不起;通過雲和群體可以共用這些。測試人員也可以因為完成測試指令碼，提供有價值的反饋，以及完成其他各項任務而獲得報酬。對於軟體測試自動化或任何其他特定領域，受雇測試員很受歡迎，所需薪水也更高。這一類服務可以輕易從雲獲得。定價模式可以變的，無論是小時支付還是按完成的任務支付。

　　我該如何保護我公司的IP和/或使用者資料？
　　 使用群體的公司應具備能夠根據測試性質提供最多安全並按需複製與系統和基於內連網的測試環境一樣的基礎設施，包括：為客戶提供專門服務。但是考慮到群體測試的性質，比起IP和APPs的本質（這個測試員看不出來），公司更關心的是隱私問題及客戶資料。例如，如果公司關注隱私問題，那麼該公司就可以隱去測試時使用過的資料。安全，尤其是Mobile Security，是一個大問題，無論公司用的是內部資源還是外部的。

　　什麼時候用群體？
　　 群體測試的環境和條件繼續演變，但真正的關鍵在於“靈活創新”。想想幾十萬應用程式，不斷變化的平台和裝置，以及不計其數次的發布，實際上公司是一直在利用客戶在即時測試他們的軟體。那是一個美好新世界，與過去完全不一樣。比如，你的公司或許：
　　 ?吸引一家供應商提供完全的外包群體測試 
　　 ?讓眾包測試專家指導你員工的日常任務及難題 
　　 ?用群體測試平台找出並僱傭專業人才 
　　 ?同意群體測試平台建立並管理你自己的群體 
　　 ?用群體評估你的自我裝載工具和能力 
　　 ?吸引第三方加入以協助提供眾包策略，供應商管理，及對基於群體的解決方案的管理。 
　　 這些是基於你公司的獨特環境和目標的所有可能。靈活是創新（相比迅速開發巨大資源的傳統方式，公司如何確認、建立並管理群體；如何建立運行項目並意識到：群體不僅僅是 ‘工作’還是要為了如何更好地工作而思考）最重要的一方面。

　　什麼時候適合用群體測試（什麼時候不適合）？
　　 群體測試是如何融入整個公司採購測試策略，什麼時候適合用群體測試？在考慮在哪、何時能最好地對他們的軟體應用程式使用群體測試，公司應該要考慮幾個重要的可變因素。通常，群體測試最適合用在以下情況中：
　　 ? 互連網是‘作業環境’和串連機制時 
　　 ? 應用程式服務公開進行，且能夠接受全球請求時 
　　 ?有處理大規模的同時線上使用者的需要和能力時 
　　 ?用戶端電腦裝置是公開的，只有很少的需求——PC和 mobile時 
　　 ?應用程式穩定性有一些等級 
　　 有些東西公司只能用群體測試——比如反映真實使用者IT設定的多語言或“髒配置”。群體測試業也適於多種測試方法——如瀑布，敏捷——也很適合黑箱測試，顯然是對應防火牆外的應用程式。然而，群體不是全能的。公司不能指望群體去測試所有的特例及web或應用伺服器端驅動的不利條件，尤其是條件在測試前或後改變的話。儘管如此，公司還是讓他們的專屬群體去做白盒測試。事實上，在眾包和應用程式測試內傳統外包供應商正在努力建立專門專屬的群體來提高他們自己測試員的效率。簡而言之，根據以上因素，總有時間和地方讓公司把群體測試用作他們整個測試策略的一個重要部分。

　　使用群體時的挑戰
　　 有了各種形式的採購，就會出現關於多種可供買家選擇的工作方式的問題。各種應用程式測試方法都有障礙和困難。對於傳統外包，公司內外都有困難，包括：
　　 ?缺少自我裝載使得外部供應商難以介入 
　　 ?購買其他選項時內部資金不夠 
　　 ?對於供應商來說，缺少測試自動化工具和專業知識 
　　 ?供應商關於業務和相關應用程式的行業知識 
　　 評估群體測試的公司或許也有相似問題，但其他的就無關了（例如：專業或功能測試或許與B2C應用程式不太相關）。也有些問題只針對群體測試，比如市面上的新事物，進程和工人的品質問題，以及資料隱私、IP保護和安全問題。

著作權聲明：本文出自 SPASVO澤眾軟體測試網：http://www.spasvo.com/news/html/2014617142827.html

原創作品，轉載時請務必以超連結形式標明本文原始出處、作者資訊和本聲明，否則將追究法律責任。