在 IEEE Standard 829 中有定義測試文件的範本應該長得什麼樣子, 你可以從很多地方找到個範本
http://en.wikipedia.org/wiki/IEEE_829
可是很多人看完後會說這個太複雜了, 有沒有簡單的方式, 連做事的時間都不夠了, 哪有時間寫這麼長的文件. 我想是否要照著這個範本寫並不重要, 重要的是你需要考慮以下事情
1. 什麼東西你要測試
也就是定義測試的目標物是什麼. 有時候有些人會搞錯測試的目標物, 明明要測的是你的系統, 可是卻測到受測系統所用到的平台或是資料庫. 有時候哪些東西不是你最先要處理的重點, 可是你卻一直在找他們的問題.
2. 你要測什麼
列出你要測試的功能. 這是乎很直覺, 但是在某些狀況下, 也許有些舊功能, 或是不是這次要注意的重點, 你是可以在這次的測試先忽略他們. 但是要先和相關利害人確認清楚.
3. 你要怎麼進行測試
你需要描述你的測試策略. 像是範圍, 單元或是整合或是 end to end , 工具, 是否要自動化, 哪些東西先測...等等
4. 什麼時候要測試
也就是說明你什麼時候要做哪些事情. 何時規劃, 何時開立個案, 何時執行個案, 何時回歸測試等等.
5. 可以進入測試的條件
並不是隨便寫個屍體就可以來測試了, 開發人員要先對自己寫的東西負責任, 準備好適當的文件, 或是經過適當 review 等等. 總之要定義好一些準則, 需要通過才能開始測試.
6. 可以結束測試的條件
你需要定義什麼條件滿足了, 測試才算結束. 像是沒有嚴重的 bug, 平均無故障時間減少到某個範圍, 或是當初計劃的測試項目都已經測完, 效能已經達到某個水準... 等等.
我想如果你的計劃已經能回答這些問題, 我想是否照著標準的範本並不重要. 因為你已經把重要的事情都考慮到了.
留言列表
