2008年5月18日 星期日

P11 測試的過程(4)──讓使用者確認系統沒有問題

在經過一連串的內部測試,確定在較正常的操作下可以無誤地執行功能後就準備進入使用者測試階段。在此之前要保證輸入後的執行與傳回都必須可以正常完成,因為使用者測試主要是測試各種輸入的狀況並確認執行時的檢查與傳回之顯示是否正確。

進行的方式與Test Case大致相同,不過使用者會根據他們的工作習慣來操作,同時還會故意用錯誤的操作與不正確的值來檢驗系統是否能夠防止並提示。功能的執行大多是線性的,頂多會有流程的分歧點指向另一段線性流程,但是UI介面的設計就具有很高的複雜度,這是因為使用者的每一個輸入動作都是獨立的功能,許多UI的動作又會相互牽動造成影響。我們可以想見在使用者測試時會冒出許多大大小小的錯誤回報。

使用者會根據交易的生命週期來切割出每一個交易應測試的範圍,然後就從開啟畫面、輸入資料、事件觸發、資料檢查、訊息提示、執行功能、畫面切換、結果回報……等等不同的層面來檢查系統各個階段的正確與錯誤的處理方式。對於使用者回報的問題,我們必須具有快速分辨出問題屬於哪個Module或Component問題的能力,方能快速、準確地定位問題並加以解決;如果一時之間無法找出發生點,可以經由討論與測試來縮小範圍以便定位。

解決使用者測試出來的問題,最忌諱的是產生side effect與defect reopen,這會令使用者感覺系統極端不穩定。問題應該越解越少,問題數能夠持續收斂的系統是可以預期在哪一天可以結束測試的。

沒有留言:

張貼留言