測試自動化目前是開發活動中的當紅要角, 不管有沒有做, 任何人都可以來說嘴幾句, 探索式測試自然也要來跟他攀上關係, 就讓我們來談談兩者要如何合作.
測試的做法, 主要分成檢查 (checking) 和探索 (exploring) 兩種. 因為很多人的誤解, 測試自動化 (Test Automation) 往往變成是偏向檢查類別的.
為什麼這麼說呢? 因爲很多人把 test automation 做成是 automated test execution 或 automated test case. 他們只是把現有測試流程給自動化, 或者是把測試個案給自動化. 也就是檢查之前要做的事情是否一一都做對. 因此, 這樣的測試自動化, 只能確保之前對現在是否還是對的, 但是無法找出更多或者是之前不知道的問題.
事實上, 測試自動化可以做得更多, 在這些方面可以幫探索式測試做的更好
(1) 輔助測試的進行
探索式測試雖說是以手動方式來進行, 但是在很多方面需要有工具來輔助:
a. 產生測試資料
像是測試資料的產生, 如果需要大量資料或是式混合型的資料, 有工具就會很方便.
b. 模擬測試場景
當你遇到某個很難重現的問題, 需要利用 ET 來試著找出問題. 這時候如果有工具可以模擬某幾個場景交互執行, 你便可以放他讓他試試看, 這樣會讓問題有更高機率可以找到, 或者可以所短問題重現的時間.
c. 檢查基礎功能
大家都是知道, 重複和固定的事情, 是程式最擅長處理. 因此你可以把一些基本功能或是場景, 將他們給自動化, 這樣測試人員就可以抽身, 去探索比較複雜的狀況.
就像微軟, 他們會進行 build verification test (BVT) 的自動化, 每次當有 build 產生時, 就會執行一次自動化, 先確保這個 build 基本功能沒問題, 避免浪費其他開發人員或是測試人員再次檢查的時間, 好讓他們可以放心拿去做下一步的事情.
d. 建議需要進一步測試的地方
有些 static analysis 工具, 可以檢查哪些地方有 security 問題, 或者是哪些地方程式複雜度太多, 這些都是系統有問題的地方. 並且你也可以知道這個開發人員的風格, 大致在哪些地方容易忽略, 你就可以多進行這類型的測試.
(2) 輔助你知道你不知道的
工具要能幫助你找到新問題, 或是學習你不知道的東西. 如果你都是確認你知道的, 其實你只是在進行 ST (scripted testing) 而已. Rex Black (著名測試顧問和作者) 曾說過:
You should consider a test case good when it is likely to detect a bug you haven’t seen yet, and you should consider a test case successful when it does so.
a. 執行時期產生不同測試資料
如果每次你都使用相同的測試資料, 自然每次都只能抓到相同的 bug. 如果測試程式可以在執行時產生不同測試資料, 這樣便可以驗證不同狀況.
b. 執行時期產生不同測試場景
除了測試資料要能不同外, 自然 test scenario 也要能不同, 這樣才能測到更多狀況. 例如, 微軟他們就很強調 model based testing, 他們用這個方法來進行 UI 自動化測試. 這樣就有機會可以在執行時期, 產生出不同的操作 flow. 否則, 如果只是用錄的, 這樣的 UI flow 便都是固定的.
所以, 測試自動化也是可以千變萬化的, 可以玩的花樣不是只有上述幾種, 只要你了解探索的精神, 你可以自己發展出適合你的應用.
好吧, 寫程式就寫程式, 有做測試自動化就很了不起, 幹嘛這麼燒腦呢?
全站熱搜
留言列表
