移動應用眾測之“Bug探索測試”實戰

認識Bug探索眾測

隨著移動互聯網業務的高速發展，越來越多的人認識到Bug探索眾測的重要性。那么什么是Bug探索眾測呢？Bug探索眾測是測試專家Cem Kaner博士在1983年提出的，Bug探索眾測是一種軟件測試風格，它強調獨立測試人員的個人自由和職責，為了持續優化其工作的價值，將測試相關學習、測試設計、測試執行和測試結果分析作為相互支持的活動，在整個項目過程中并行地執行。該定義包含三個方面的內容:
一種思維方法
Bug探索眾測強調依據當前環境選擇合適的測試手段，而不局限于特定的測試技術。測試人員可以在探索式測試中使用任何一種測試技術，也可以將探索式風格應用于任何測試活動。
一種責任
Bug探索眾測人員應該為個人和團隊負責，調動所有能量，發揮人的靈活性。
循環迭代
Bug探索眾測旨在將測試學習、測試設計、測試執行和測試結果分析作為一個循環快速地迭代，以不斷收集反饋、調整測試、優化價值。

Bug探索眾測的價值

常規測試方法的不足
常規的測試方法，可以有效確保測試人員設置的單個或者多個常見場景不會出現大的問題，但是用戶的使用環境和APP開發方的環境千差萬別，與測試人員完全不同的網絡環境(2G、3G、4G、WIFI)、 不一致的運營商(電信，移動，聯通)，完全不同的手機設備和OS系統，如此種種，傳統測試無法覆蓋所有可能性和場景，這也是很多產品設計優秀，但依然差評滿滿的根源。這個時候移動應用Bug探索眾測就顯得尤為重要和必要。
Bug探索眾測在不同企業的應用
在不同的企業應用Bug探索眾測有著不同的方式方法。在大型企業中（銀行、保險、證券、政府、上市公司等），擁有大量的內部員工，每個員工都擁有1-2款個人移動設備，這種天然的優勢為企業內部眾測提供了充沛的資源，大型企業可以“足不出戶”依托健全的眾測信息化管理平臺，完成移動應用的Bug探索眾測。而中小企業（創業型的互聯網公司，無法調動更多內部資源的信息化部門等），并不具備充沛的可用資源優勢。這類企業開展Bug探索眾測顯然需要外部力量的支持，可以選擇成熟、口碑好的眾測平臺，由外部眾測平臺提供測試專家資源完成相應的Bug探索眾測。
常規測試與Bug探索眾測
常規測試是測試質量保障的重要手段，Bug探索眾測能夠有效補充常規測試不能覆蓋的場景、多種用戶行為等差異化測試內容。兩者相互結合，相互補充，缺一不可。

Bug探索眾測的意義和作用

? 探索測試的最大特色是在對測試對象進行測試的同時，創造新的、區別于固有的測試思想及方法。這相對于傳統軟件測試過程中嚴格的“先設計，后執行”來說，是具有很大區別的。
? 探索測試強調測試過程中要有更多的發散思維，這也是與保守測試方式的最大區別。保守測試方式強調設想完善的測試用例，測試人員嚴格按測試用例執行測試，這多少限制了測試人員的測試思維，測試人員往往缺乏主觀能動性。
? 探索測試讓測試工作脫離常規用例，深度挖掘應用中不易被發現的Bug，確保產品質量穩定，提升產品體驗。
? 多人大面積驗證核心功能，通過發散性測試，模擬各種異常場景和極端測試方法，找出各類潛在問題和風險。
? Bug探索眾測模擬真實用戶角度，結合團隊測試經驗，最大限度探索用戶使用習慣和路徑，探索復雜操作流程；真實模擬異常應用場景及系統特有功能，確保主要功能使用流暢，避免影響用戶體驗的問題，發現研發人員不易發覺的Bug。

移動應用Bug探索眾測過程

測試環境準備
移動應用的Bug探索眾測，通常是在外網環境進行，可選擇有安全防護配套的SIT環境、UAT環境，也可以選擇灰度發布環境，以及生產環境。需要特別指出：信息安全防護以及涉及知識產權保護等涉密環節應盡可能回避，因為眾測可能在非本機構內開展。APP安裝包的加固也是非常重要的環節，通常情況下，研發過程中的測試包未進行加固處理。
Bug探索眾測，需要一套相對穩定的環境，如果用于該項任務的測試環境每天都會多次集成和發布版本，會影響眾測的效果，可能的情況：提出很多因為環境問題相關的無效缺陷，或者導致測試中斷，測試者情緒嚴重受挫，從而測試效果大打折扣。
測試設計
Bug探索眾測，通常是兩種模式：基于場景探索或者自由式探索。顯然，基于場景的Bug探索眾測更具有針對性，無論是問題的聚焦程度，還是Bug的提出質量，都遠遠好于自由式探索的眾測。
基于場景的眾測，并不需要給出非常詳細的Test Case（Step By Step方式），雖然詳細的測試步驟指向性非常明確，但也會極大的限制測試者的思維。基于場景的眾測，只需要給出明確的目標，如：1、完成注冊 2、完成商品選擇 3、完成訂單支付等測試內容，讓測試者基于目標去探索執行過程中存在的Bug。
測試的組織與執行
Bug探索眾測在任務發布后，通常會在很短的時間結束，沒有周期的任務一般是24小時內結束。在24小時內，您要做的不只是等待測試結果的反饋，還需要解決參與者提出的各種問題。參與Bug探索眾測的人員一般是本Team以外的測試者，可能對產品的首次使用存在一定的疑問。這個是正常的，或許您可以從他們的疑問中能夠發現產品設計的問題，因為2C的移動應用是不需要任何操作手冊的，如果用戶上手困難，這本身就是嚴重的體驗問題。如何處理測試者的疑問和問題，需要有健全的眾測信息化管理平臺來解決，或通過IM方式，或通過公告管理的方式。
測試結果確認
測試結果確認，主要工作為測試執行過程的確認以及Bug的確認。測試執行過程確認是指，識別測試者確實按照既定的場景完成了整個Bug探索測試過程，通常以截圖、視頻等方式作為依據。Bug確認是測試結果確認的重點，包括：有效Bug識別、無效Bug識別、重復Bug識別，需要進一步重現的Bug等。這是一件有些工作量的工作，看起來很復雜，但是如果運用了自動識別重復Bug的功能，會讓重復Bug識別變得智能高效。目前，很多企業在使用QQ群、微信群等方式管理眾測，顯然無法達到高效管理眾測的目的。
Bug探索眾測報告
Bug探索眾測報告是對整個測試活動的總結，包括：眾測時間的花費、眾測費用的花費、眾測覆蓋程度分析、眾測發現的Bug分析，以及眾測結果數據能夠度量的風險分析等。應用平臺化管理，上述內容是可以自動輸出的，無須人為重新采集數據。
基于共享經濟模式的Bug探索眾測模式，讓測試一切變得更高效，為敏捷迭代提供了一個非常好的途徑方法。