軟體測試是一件重要, 但是大多數人都忽略的事情, 或者沒有時間去處理. 為什麼會這樣呢? 讓我們來聊聊.
傳統測試方法
傳統我們進行測試時, 很多時候會寫個測試計畫, 不過這大多是例行公事, 效用不是很大. 接著, 測試人員會開始撰寫測試個案, 規劃測試要怎麼進行. 最後, 就依據測試個案來對受測軟體進行測試. 沒事, 就可以出貨. 有事, 就請開發人員修改, 改正後再驗證, 然後就收工.
撰寫測試計畫 --> 開立測試個案 --> 執行測試個案 —> 驗證修復結果
傳統測試方法的好處
(1) 可以重複
當下次要重新再測時, 可以將之前的測試個案再跑一次
(2) 知道還剩多少沒做
跑了多少測試個案, 多少沒跑, 這很容易管理
(3) 有文件
這些過程都有詳細的文件, 並且都是一步一步教你怎麼做
(4) 可以請技術沒這麼好的人幫忙
當測試個案開立完後, 可以請工讀生, 或是技術能力沒那麼強的人, 照表抄課, 這樣測試就可以做完.
傳統測試方法的問題
(1) 系統往往到最後才確定
身為開發人員你ㄧ定很清楚, 直到最後一刻, 你都可能不斷修改程式, 即使需求沒修改. 事先開好的測試個案會還適用嗎? 如果沒有持續修改測試個案, 或者是增加測試個案, 只是把原先開立好的個案執行完, 這樣一點意義都沒有.
(2) 系統比你想的複雜
大家都知道, 文件寫的內容, 往往只有程式真相的一小部分. 因此, 你覺得只需要執行完事先開好的個案就好嗎? 裡面可能還有很多變化, 還有很多地方是你不知道或是想像不到, 那些地方要怎麼辦呢? 如果這時候你還請工讀生來做, 你怎能奢望他們深入探索呢?
(3) 花在執行測試時間很少
開發人員另外有件事情也很了解, 開發就應該花多點時間在寫程式, 不能老是都是在寫文件. 你可以花時間思考, 但不是都是花時間在寫文件. 可是傳統測試流程, 大多把時間用在寫計畫和測試個案, 往往執行時間都不到測試時間 20%, 這樣真的能找到很多問題嗎?
(4) 測試時間不夠
很多場合, 都是開發把時間給用光或是用超過, 因此到測試人員或是測試階段時, 往往所剩時間已經不多, 在這短的時間內, 你不但要讀完文件, 了解系統, 開立測試個案, 執行個案, 和撰寫測試報告. 你覺得傳統做法能應付這樣的狀況. 大多都只是能達到有做, 做好會變成是不敢奢求的事.
(5) 大多的 bug 是撿到的
這是一個很尷尬的現象, 你會發現到測試報告上的 bug 大多不是來自於測試個案, 很多是不小心在別的地方試試, 然後就找到 bug.
從上述的問題得知, 測試的做法需要改變, 否則上述這些問題, 將會無法處理, 也會讓測試變成一件雖然要做, 但是做完後沒太多加值的活動. 不做不太放心, 但是只求有做, 是無法帶來大家的認可和尊敬.
可是, 要怎麼改變呢? 下次我們來聊聊怎麼做.
全站熱搜
留言列表
