探索性測試指南

前言：

探索性測試是由四個步驟所組成的循環

『在設計和執行測試的同時了解系統，並使用前一次測試的反饋來指導下一次測試』*

設計

新一輪測試的開始，我們會對正在測試的系統有基本的了解，列出可能要問的問題或要填補的知識落差，因此提出並設計一個新的測試想法。

執行

設計完之後會執行，可能會需要一些工具協助。

分析

執行完成後，分析測試的結果。

學習

分析的結果將會更新我們對於系統的了解，我們帶著更新後的結果再次這個循環。

前言繞了一大圈，本文是接續這篇文章，說明如何『設計』、解決“不曉得怎麼測”之後，要怎麼完成一個測試循環。

或是 --- 在時間和成本都有限的情況下，怎樣才算測夠了呢？

測試指南 Test Charter**

模板如下：

探索 [目標]

使用 [資源/工具]

發現 [資訊/結果]

如同鄭和下西洋一般，每次出航都只有簡單的目標以及方向，過程中遇到問題再進行微調。

鄭和最一開始收到的指令非常簡單：

『帶著船隊去西洋拓展貿易路線』

套上模板的話就會長這樣

 [探索]西洋 > [使用]船隊 > [發現]貿易路線

對應測試的話便是

探索 [目標]

這次測試的是專案中的哪個功能或模組？

使用 [資源/工具]

本次任務中有哪些資源能使用，需要什麼權限？

發現 [結果]

出現了什麼異常狀況？

過程中可能會遇到其他錯誤，先簡單記下來就好，畢竟探險的資源和時間有限，對吧？

我們還是使用訂房網站的情境：

『客戶反應一直不能完成訂房』

套著上面的模板，會是這樣：

[探索] API ，尤其是PUT

[使用] 不同的資料組合測試

[發現] 最後找到原來是客戶電話格式造成的問題

在本輪測試中，我們發現電話格式可能會產生問題，去開發文件中找看看有沒有用到相關欄位的地方、也可以針對POST / DELETE 試試看會不會出現問題，再結合開頭提到的測試循環，展開新一輪的測試。

  到文章結尾，已經可以回答“怎樣才算測完”

1.  經過多次的測試循環( 設計> 執行 > 分析 >學習)後，沒有新的想法出現。

2.  時間不夠了：是的，雖然從頭到尾都沒有提到時間要素，不過正常情況下，我們收到的指令是“禮拜三以前完成測試“再來才是把功能做切割，至於怎麼切、怎麼分，由於規劃時間的方式因人而異，故本文便不展開說明。

結語：

   探索性測試並非毫無方向的亂衝，其實是可以有策略地執行。雖說是探索，但我們要進行的是”有限度”地探索，除了測試指南之外，還有用心智圖來作為輔助工具，只是筆者不善使用這個工具，所以放在文末作為補充資料給大家參考。

Testing Web APIs Ch.5

備註

*原文為『.. simultaneously learning about the system while designing and executing tests, using feedback from the last test to inform the next.』 by Elisabeth Hendrickson

** 原文為
Explore <Target>

Using <Tools>

To discover <Risk/Information>

參考資料：

『Session-Based Test Management』 by James and Jon Bach

『Testing Web APIs』 by Mark Winteringham

『Explore it !』 by Elisabeth Hendrickson