上次提到傳統測試方法不可行, 需要做些修改. 這次我們就來談談可以怎麼做
傳統測試缺乏什麼
測試進行的方式, 不外乎以下幾種做法
(1) 開發人員手動測試
通常是由開發人員進行測試, 來幫助確認程式是否按照預期的方式運作. 通常開發人員會抱怨沒有時間做這件事情, 也會覺得這件事情很 low, 沒有技術性, 會打從心底排斥這件事.
即使開發人員願意做, 往往也會因為不懂如何開立測試個案. 或者自己的程式, 下手通常不夠殘忍. 因此測試的效果不是很好.
(2) 自動化測試
基本上, 自動化測試也是門學問, 不懂的人往往需要花很多時間打造, 但是不是寫完就沒事, 你還需要花時間維護, 因為中間受測程式修改, 你會需要再修改測試程式, 這樣的代價其實是不小.
另外, 自動化測試大多是想確認之前寫的東西是否還正確, 他的重點不是在找出系統的所有問題, 或者是否還有哪些場景系統沒處理到. 因此, 大多自動化測試並不是在找出新的問題, 或是很多問題. 從要找到很多的 bug 的觀點來看, 自動化測試並不夠的.
我們希望測試方法可以再加強以下面向:
(1) 可以因應需求或系統修改
很多時候需求會被修改, 或者是隨著時間的演進, 我們對需求有不同的解釋, 因此當初寫個案或是設計文件可能過時, 我們需要有個機制, 可以針對這樣的狀況即時作出反應.
(2) 可以在時間不足下產生最好的成果
很多時候測試時間是被壓縮的, 在這短的時間, 不該都是在寫文件, 應該要有多點時間在測試, 但是也不能沒有規劃, 也不能沒有文件傳承.
什麼是 exploratory testing?
Exploratory testing 的出現, 一開始是想補強這些不足. 所謂的 exploratory testing, 是一種測試的風格, 他藉由同時進行學習, 測試設計, 和測試執行, 逐步了解受測系統, 進而做出更深入的測試.
這個定義一開始聽起來很抽象, 會想說這是什麼鬼? 讓我們拿個範例來解釋一下. 這裏提的是其中一種實施方式, 以迭代 (session) 方式進行, 每個迭代會先說好要處理哪個主軸, 其過程如下:
(1) 定義主軸
假設你要測試 Line app 的東西. 你對 Line app 並不了解. 你的第一個 迭代可能花個 30 分鐘, 先看看每個 menu 選項按下去再做什麼.
(2) 紀錄過程
並且在測試的過程中, 記錄自己做了什麼, 找到什麼問題
(3) 檢討
在每個迭代結束後, 執行者會跟其他人分享做什麼, 並且討論接下來可以往哪邊在深入. 例如, 每個 menu 選項都按過後, 大約知道 Line app 有什麼功能, 所以下次可能就從聊天功能繼續深入下去.
每次迭代的時間, 長度可能是 60, 90 或者 120 分鐘, 基本上足夠你做完上述三件事情即可.
Exploratory testing 的特性
(1) 在這個過程中, 它並不是事先先撰寫好測試個案, 他只說要測試什麼方向, 在迭代中才決定要怎麼測, 測了哪些會記錄下來.
(2) 它並不是沒有文件, 只是文件是一邊測一邊產生.
(3) 每次迭代完後, 你對受測軟體有更深入一點的了解, 然後你就可以規劃下一次要再往哪邊多測一點.
(4) 時間主要是花在執行測試上面, 而非是花很多時間規劃.
那是不是之後測試都是要改成 exploratory testing 這種作法呢? 那也不是. 有些時候測試偏向探索, 但是有些時候我們只想做 checking (檢查).
所謂的檢查, 就是先有個清單, 執行者只是確定清單上寫的是否都對. 像之前按表手動測試, 或者是大多數的測試自動化, 都是屬於檢查這一類的.
因此, 在一個測試活動中, 你會有檢查和探索兩件事, 分配比例多少, 可以自行決定. (下圖中的 scripted testing, 就是所謂檢查性的測試)
Exploratory testing 這樣的做法, 保持了彈性, 並且把時間花在刀口上. 但是這樣的做法, 老實說很吃測試人員的功力, 如果他只想照表操課, 不想多動腦筋, 每次在迭代後的檢討, 變成要花很多時間調教.
好了, 先介紹到此為止, 我知道這還是很抽象, 尤其對沒有手動測試經驗的人來說, 或許很難想像. 改天希望可以透過小小練習, 讓大家有感一點.
全站熱搜
留言列表
