探索性測試 Exploratory testing Test Charters QA test scenario test case test case generate QA testing

探索性測試指南

張庭瑋 Gary Chang 2024/02/19 10:00:00
927

前言:

 

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

 

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

 

設計

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

 

執行

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

 

分析

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

 

學習

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

 

 

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

 

 

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

 

 

 

測試指南 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

 

張庭瑋 Gary Chang