無責任軟體品保 : 軟體測試十要
先有測試計劃 (Test Plan) 在 開始測試之前，請先靜下心做一個測試計劃。軟體的功能越來越複雜，沒有一個測試計劃按表執行，到頭來就是一團迷糊仗。在測試團隊日漸成長的公司裡，這可以 幫助 PM/QA Lead 最大的發揮 QA 的效能，確實掌握產品開發時程。若你是一人要身兼數職校長加撞鐘的情況，拿張紙想一下把測試的要項寫下來，也可以產生易想不到的功效。 安排專責測試人員 (QA Enginner, Test Engineer) 不 管是 QA Enginner 或是 Test Engineer，大部份的研發單位目前應該都有專職的軟體測試人員編制；所以一般而言這件事還算單純。即使你是在一個全由 RD 組成的小公司或研發團隊，也可以把 RD 編組來進行交叉測試。請記得，再聰明的程式設計師也總是會有盲點；請把負責開發的人員與負責測試的人員分開來，才能達到品質把關的目的。測試人員就等於是 PM 的眼睛，把未經過測試的產品出貨，就像在西門町由樓上丟顆石頭下來祈禱不會砸到人一樣。 功能驗證測試 (F.A.S.T: Feature Acceptance Simple Test) 當 大伙兒辛辛苦苦終於把產品的新功能 coding 出來，這時最優先的任務就是先跑一輪基本功能。英文的 Feature Acceptance Simple Test 縮寫就是 “FAST”，望文生義這個測試就是要跑的又準又快。請將主功能一項一項列出來，找一個最穩定的 OS 版本照著需求文件跑一次。這個測試最好是控制在一天的時程內，可以有效的反應到底那些功能 OK 了，那些功能其實根本不能用。 相容性測試 (Compatibility Test) 測 試產品將來需要使用的環境或平台的相容性是基本工夫，同時也是最秏時秏力的項目。在能力所及的情況下，相容性測試要盡早開始。軟體在 Coding 或 Alpha stage 時通常比較 buggy 而讓 QA 很難分心看其他的問題。但往往等比較穩定後，才發現所用的解決方案相容性有問題而又得大改。在這個階段，測試的環境可以先安排好跑過一輪，就能早期發現這 類問題。 壓力測試 (Stress Test) 架設一台 Svr 要能同時維持多少線上使用者？跑一個功能要能吃多少筆資料？這些標準在產品開發一開始 PM/QA Lead 就先盡早訂下來。標準訂立了後實