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

　　探索式測試的定義在我的blog都做了較多說(shuō)明，其中也談到了探索式測試在項目的實(shí)踐方式，接下來(lái)會(huì )詳細的說(shuō)明其中來(lái)亮個(gè)實(shí)踐方式的具體實(shí)施過(guò)程。

　　探索式測試四象限

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

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

　　測試專(zhuān)家James Bach曾經(jīng)對探索式測試(ET)和腳本測試(ST)在項目實(shí)踐過(guò)程的變化進(jìn)行了對比，請看圖 1

　　從嚴格的腳本測試到自由式的探索式測試，James Bach做了如下解釋?zhuān)?/p>

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

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

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

　　目前許多測試團隊以腳本測試為主導，偶爾在測試執行的時(shí)候發(fā)散性地去測試有疑惑的地方，但該發(fā)散性測試受經(jīng)驗、時(shí)間、功能特性、測試任務(wù)等眾多因素影響，其結果無(wú)法跟蹤，且經(jīng)驗不能傳承。為了更好的組合腳本測試和探索式測試的優(yōu)點(diǎn)，可以考慮盡量減少編寫(xiě)文檔的時(shí)間，也可以考慮增加在測試執行時(shí)學(xué)習產(chǎn)品和技術(shù)的時(shí)間，從而帶來(lái)更強的思維擴展性。

　　下面簡(jiǎn)單介紹如何組合腳本測試和探索式測試過(guò)程中需要用到的幾個(gè)關(guān)鍵性的因素：

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

　　Fragmentary test cases：使用一句話(huà)或幾個(gè)詞語(yǔ)描述的測試用例，類(lèi)似于腳本測試中的測試用例標題。

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

　　Roles：測試過(guò)程中確定每個(gè)測試人員一個(gè)獨立的角色去測試產(chǎn)品的某個(gè)部分。由測試人員自己掌控測試任務(wù)的進(jìn)度和質(zhì)量。

　　接下來(lái)將說(shuō)明在實(shí)際的項目測試過(guò)程中，如何組合探索式測試和腳本測試。圖2 展示了不同目的的探索式測試象限。

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

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

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

　　缺陷大掃除

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

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

　　l 活動(dòng)對象：

　　l 活動(dòng)時(shí)間：

　　l 測試環(huán)境：

　　l 如何訪(fǎng)問(wèn)：

　　l 測試數據：

　　l 項目功能：

　　l 問(wèn)題反饋：

　　l 獎項設置：

　　l 已發(fā)現但在處理中的bug列表：

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

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