探索式測試實踐之缺陷大掃除和結對測試

　　探索式測試的定義在我的blog都做了較多說明，其中也談到了探索式測試在項目的實踐方式，接下來會詳細的說明其中來亮個實踐方式的具體實施過程。

　　探索式測試四象限

　　探索式測試是一種測試風格和思考方式，它強調的是學習在測試過程中的作用。無論測試人員在做功能測試、性能測試、安全測試或其他類型的測試，都可以使用探索式測試的思維方法，來幫助自己找到初始測試設計未考慮到的危險區域。

　　探索式測試不只是在腳本測試后才開始，它可以應用于軟件測試的各個階段。作為一種測試風格，探索式測試可以使用適合當前情景的任何測試技術(包括腳本測試常應用的測試技術)。那為什么我們還要把探索式測試和腳本測試分開呢?這是因為探索式測試的優勢來源于并行地實施測試學習、設計、執行和評估，來源于測試人員在此過程中的積極探索和主動調整，如果一再強調把探索式測試融合在腳本測試過程中，將不利于觀察到探索式測試的內涵和潛在效果。

　　測試專家James Bach曾經對探索式測試(ET)和腳本測試(ST)在項目實踐過程的變化進行了對比，請看圖 1

　　從嚴格的腳本測試到自由式的探索式測試，James Bach做了如下解釋：

　　最左邊的Pure Scripted，是嚴格的按照測試用例來執行測試，而且測試用例非常詳細，在項目測試過程中較少存在這種現象。

　　最右邊的Freestyle ET，是自由式的探索式測試，在測試執行的時候不依賴于測試文檔，只記錄產品缺陷和風險除外;測試執行之前不需要任何特別的準備，比如測試設計。

　　這兩種測試方式都是不常見的，有些走極端的傾向。在項目測試過程中，不可能完全采用Pure Scripted或Freestyle ET。比較好的辦法是在項目中混合腳本測試和探索式測試，并在不同的項目中采取不同的混合方式來制定項目測試計劃。在大部分的項目測試過程中，綜合腳本測試和探索式測試的優點可以得到較好的效果。

　　目前許多測試團隊以腳本測試為主導，偶爾在測試執行的時候發散性地去測試有疑惑的地方，但該發散性測試受經驗、時間、功能特性、測試任務等眾多因素影響，其結果無法跟蹤，且經驗不能傳承。為了更好的組合腳本測試和探索式測試的優點，可以考慮盡量減少編寫文檔的時間，也可以考慮增加在測試執行時學習產品和技術的時間，從而帶來更強的思維擴展性。

　　下面簡單介紹如何組合腳本測試和探索式測試過程中需要用到的幾個關鍵性的因素：

　　Vague Scripted：比較簡要的測試用例，是對腳本測試(ST)的初步簡化，可以理解為測試人員需要編寫測試用例，(但不必編寫詳細的預期結果)。測試用例可以包含操作步驟，但描述比較簡單，其目的是留下更多的空間給測試人員在測試執行的時候自由發揮。

　　Fragmentary test cases：使用一句話或幾個詞語描述的測試用例，類似于腳本測試中的測試用例標題。

　　Charters：探索式測試過程中使用到的一個非常清晰的任務列表，指出了要測試什么、怎么測試(強調策略，不是詳細測試步驟)、尋找什么樣的Bug、有哪些風險、要去檢查什么文檔等。

　　Roles：測試過程中確定每個測試人員一個獨立的角色去測試產品的某個部分。由測試人員自己掌控測試任務的進度和質量。

　　接下來將說明在實際的項目測試過程中，如何組合探索式測試和腳本測試。

　　象限編號的順序與不同形式的探索式測試實踐沒有直接關系。例如，在我們進行 “Freestyle ET”形式的探索式測試實踐時，完全可以采納結對測試(Pair Testing)的形式，或進行探索式測試之后采用全民分享(All Sharing)方式來分享更多的測試經驗。探索式測試屬于軟件測試的上下文驅動學派(Context-Driven School)，具體采用何種方式來進行探索式測試實踐，或如何組合多種實踐方式都是依賴于項目當時的情境，也就是項目本身的上下文環境。

　　由于本文只對第四象限的兩個方式進行詳細說明，則其他象限的具體實踐方式不在此說明。特別說明的是象限一和象限四是兩個面向探索精神的實踐方式，象限二和象限三是兩個偏向于流程和系統性的實踐方式。這里需要強調的是ET主導的實踐方式也是有一定的項目流程的基礎和系統性的思維路徑的，本文不做詳細的說明。

　　象限四中的測試實踐方式是由三個非常具有探索性的小活動(接下來稱為趣味性的實踐方式)組成。Bug大掃除 (Bug Bash)在微軟使用得非常普遍，且效果非常好。 結對測試(Pair Testing)是與結對編程相對應，由兩名或多名測試人員在一起同時測試一個SUT，并相互給出建議和指令，共享通過使用系統得到的(隱含)信息，從而不斷的積累系統知識和測試經驗。全民分享(All Sharing)是測試執行前或執行后所進行團隊分享的一個活動，具有不同背景和特長的測試人員分享自己發現Bug的思路，分享自己如何去測試軟件，分享自己在某種測試類型上的策略。

　　缺陷大掃除

　　熟悉微軟測試流程的測試人員應該都聽說過缺陷大掃除(Bug Bash。它是一項短期的全員測試活動。在微軟，許多開發團隊會在里程碑(Milestone)的末期執行缺陷大掃除。程序員、測試員、程序經理、用戶代表、市場人員在1~3天的窗口中，運用各自的技能和職業背景，集中精力來搜尋軟件的缺陷。通常，每位參與者會獲得一個小禮品，發現缺陷數目最多的冠軍會獲得一份大獎。

　　一般缺陷大掃除的組織者需要準備如下的內容：

　　l 活動對象：

　　l 活動時間：

　　l 測試環境：

　　l 如何訪問：

　　l 測試數據：

　　l 項目功能：

　　l 問題反饋：

　　l 獎項設置：

　　l 已發現但在處理中的bug列表：

　　缺陷大掃除是常規測試的有效補充。測試團隊將各個子系統連成業務系統，執行端到端(end-to-end)的系統測試，能夠發現個人在子系統測試中難以發現的缺陷。此外，測試人員在測試不熟悉的子系統時，沒有任何先入為主的“偏見”，往往能立即發現那些被“熟視無睹”的缺陷。而資深測試人員還可能發現一些初學者難以察覺的隱蔽問題。不過，相比找到的缺陷，我認為缺陷大掃除在以下兩個方面更有價值：

原文轉自：http://blog.sina.com.cn/s/blog_6cf812be01012h6l.html