測試手段之探索性測試(1)

　　上次說到了理想中的測試模型，有很多測試手段，細心地人可以發現那里面加了一個很關鍵的一個測試手段就是探索性測試。其實這里面把它叫為測試手段不是很科學，而且容易產生歧義。

　　所以后面把它叫做一種測試方法。

　　自己研究探索性測試快半年了，對其有一定的了解，而且在國內也有相關的介紹，個人認為：

　　1. 大部分是正確的

　　2. 相當淺顯的介紹探索性測試

　　3. 沒有介紹探索性測試的實踐情況

　　自己看過了探索性測試(以下簡稱ET)的3個核心人物的一些關于ET的paper，也小小的實踐了一個ET的一種形式，有很多感慨。但一直沒有去寫，有以下原因：

　　1. 不知道怎么表達出來比較好，一直都認為自己理解ET不深

　　2. 為了不讓大家對ET存在誤區，且自己對于ET某些的認識也是存在不同的看法(隨著與James bach的溝通變得不一樣)

　　3. 自己對于ET具體的測試方法的抽象還存在部分疑惑

　　最后發現了一點點的感覺了，就想把自己了解的一些情況記錄下來Share給大家，希望能給大家帶來不一樣的認識。也希望不要給大家帶來ET認識上的誤區。

　　這里把ET叫做一種測試方法，而非測試技術，是有理由的。我們先可以分析下我們目前的測試模型，是集成在spiral或waterfall或類似的開發模型下，這就存在如下的幾個特點：

　　1. 測試文檔(計劃和設計和用例)必須非常詳細和明確

　　2. 測試設計和測試用例對于開發的文檔的依賴非常大

　　3. 測試執行的時候對于測試用例的依賴非常大

　　4. 測試執行的時候對于需求變更的應對力較差

　　我們可以把有以上特點的測試方法叫Scripted based testing(簡稱ST)，顯然我們目前就是這種測試方法，由于這個方法有些缺點，從而產生了一個新的測試方法：ET。

　　下面我們對于ET和ST進行了一些簡單的比較：

　　在這里我們可以看到一點就是ET似乎就是彌補ST的一些缺點，理智的人就會想到能不能ST和ET結合起來。這樣帶來的效果是不是更好呢?

　　我們認為大部分的項目的最佳組合地方是在中間，也就是我們可以采用ST的優點和ET的優點進行組合。但這里要說明的是ET是Context-Driven School的代表作，其強調的就是沒有最佳實踐，任何項目都有自己的特點，根據特有的特點制定最佳的測試方法組合策略。

　　對于上面的模型圖，可以看到有如下的特點：

　　最左邊就是Pure Scripted，也就是完全的按照測試用例來執行測試;而且測試用例非常詳細。

　　最右邊是Freestyle ET，也就是自由式的ET，沒有任何測試文檔;不需要記錄任何東西(bug除外);測試執行之前不需要任何準備。

　　可以看到上面的兩種方式都是不成熟的，而且都是不常見的，有點走極端。我們自己做項目過程中不可能完全走Pure Scripted或Freestyle ET。這里比較好的辦法就是混合ST和ET，并在不同的項目當中采取不同的混合策略來進行比較完善的測試方法的策略。在大部分的項目過程中，組合ST和ET會帶來意想不到的效果，

　　目前我們所有的項目都是ST為主導的，偶爾會在測試執行的時候會去發散性的去測試一些東西，但這個完全建立在經驗和時間和功能等眾多因素上。為了更好的混合ST和ET，我們考慮盡量減少文檔的編寫時間，提高更多的在測試執行時創造性的發揮，更加的體現在測試執行過程中持續性學習產品帶來的思維擴展性。

　　這里介紹下混合ST和ET時，需要用到的幾個關鍵性的因素：

　　Vague Scripted：比較模糊的測試用例，一般不是很詳細，這里可以理解為有一些測試用例(但沒有一些比較詳細的預期結果)，也會有一些步驟(但會預留有一些其他詳細的步驟而不是必須要做的)。

　　Fragmentary test cases：使用一句話或幾個詞語制定測試用例。

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

　　Roles：ET過程中給測試人員一個獨立的角色去測試產品的一部分。由他們自己掌控進度和質量。

　　這里主要說明了ET和ST的一些方式上的不同，至于ET的定義這里就不說了，下次介紹下ET在什么情況下適合做，ET做的好不好與哪些因素有關系。大家想要了解什么或者有什么問題，都可以留言。

　　以上分析參考James Bach等的paper

原文轉自：http://www.anti-gravitydesign.com