大家做項目或産品過程中,遇到最多的,也覺得最有風險的就是測試計劃。關于如何做測試計劃,每個人都有自己的經驗,這裡不發表個人觀點,而是翻譯國外某位大師的對于制定測試計劃的一些思想,希望對大家将來制定測試計劃有用。而且關于測試計劃的大部分問題我想都可以在這裡找到答案,本人英文水準有限,翻譯有不妥之處,請指正。作者為JamesBach
制定計劃
1. 分析産品
分析什麼
使用者(他們是誰,他們做什麼的)
操作(這個操作是幹什麼用的)
産品結構(代碼,檔案,等)
産品功能(這些功能是幹什麼用的)
産品資料(輸入的,輸出的,狀态,等)
平台(外部的硬體和軟體)
怎麼分析
走一下産品/原型的主要流程
評審産品和項目文檔
咨詢設計人員和使用者
與類似的産品做比較
可能的工作産出
産品的功能範圍概要
注釋性的文檔
産品的問題清單
執行狀态檢查
設計人員有沒有确認以及準許了産品的功能範圍概要?
設計人員有沒有認為你已經正确了解了這個産品?
你能不能将這個産品形象化并且預測正确的行為?
你能不能造出産品的測試資料(輸入和結果)?
你能不能配置和操作這個産品?
你有沒有了解這個産品是怎麼樣被使用的?
你有沒有注意到設計中的漏洞或不一緻的地方?
關于這個産品你還有沒有未解決的問題?
2. 分析産品的風險
分析什麼
産品受到的威脅
産品的易受攻擊的地方
失敗的方式
失敗後的影響
怎麼分析
評審需求和規格說明書
評審出現問題的一些事件
咨詢設計人員和使用者
通過探索性風險分析和品質判據清單來評審産品
識别基本的錯誤/失敗方式
可能的工作産出
元件風險清單矩陣
失敗模型概要
執行狀态檢查
設計人員和使用者有沒有對風險分析達成一緻?
你有沒有發現所有的重要的問題,而這些問題是否在測試過程出現呢?
你是否知道在哪些地方要集中測試精力并獲得最大的效率呢?
設計人員有沒有做一些事情使得重要的問題更容易的發現,或減少其發生的機率呢?
如果你的風險分析是正确的,你是怎麼發現的呢?
3. 設計測試政策
基本政策
Domaintesting(包括邊界值)
使用者測試
壓力測試
回歸測試
Sequence testing
State testing
基于文檔的測試
結構化測試(單元測試等)
怎麼計劃
對于風險和産品功能比對政策
将特殊的和實際的政策形象化
分析是否可用自動化的機會
使用原型去測試probes和harnesses
不要強加計劃,讓測試人員自己決定
可能的工作産出
各個類型的報告怎樣應用的測試政策文檔
風險/任務的matrix
已選擇的政策中存在的問題或挑戰清單
對産品覆寫比較少的部分提供的建議
測試用例(如果是必須的)
執行狀态檢查
設計人員對這個測試政策達成一緻了嗎?
這個政策對于項目每個參與人員以及協助人員都有用嗎?
這個測試政策是否很基本了?是否也容易的應用到這個産品中?
這個測試政策是否透露了是以的重要的問題
4. 計劃安排
安排的内容
測試時間的評估和計劃
易測性的工程分析
測試團隊人員(詳細的能力)
測試人員的教育訓練和監督
測試人員的任務的指定
産品開發資訊的收集和管理
項目會議,溝通,協調的方式
與其他已存在的功能之間的關系,包括開發過程中
測試平台的認購和配置
測試工具盒自動化
需要用到的測試樁和mock
測試套的管理和維護
建立和輸出協定約定
測試周期管理
問題報告系統和約定
測試狀态報告的約定
代碼當機和增量測試
測試後期的壓力管理
項目階段輸出協定約定
測試效率的預估
可能的工作産出
問題清單
項目風險分析
任務和責任matrix
測試時間表
與開發之間的約定和協定
執行狀态檢查
這個項目所列的安排是否支援測試政策?
是否存在一些問題會阻礙測試的執行?
在可見性的問題面前,這些安排和政策是否适合?
你現在是否開始測試還是以後整理剩下的問題?
5. 分享計劃
分享的方式
讓設計人員和股東都參與到整個測試計劃的制定過程中
更主動的擷取關于測試計劃的意見
盡最大可能幫助開發人員保持進度
幫助開發人員了解他們做什麼會影響測試
與技術支援和寫技術文檔的人分享産品品質資訊
讓設計人員和開發人員評審并且準許是以相關的文檔
記錄并加強與開發之間的約定
讓參與人員評審測試計劃的細節
在測試計劃中盡量減少沒必要的資訊以增加評審的效率
目标
對于測試過程達到一緻的了解
對于測試過程達到一緻的承諾
人員對于測試過程有個合理的參與度
對于測試過程,在管理上有個合理的期望
執行狀态檢查
整個項目團隊對于測試計劃有沒有足夠重視?
整個項目團隊,特别是一線的管理層有沒有完全了解測試團隊的作用?
整個項目團隊,有沒有感覺到測試團隊在項目過程中有最大的效益?
測試團隊和項目其他團隊有無争議性或建設性的關系?
項目團隊裡有沒有成員感覺測試人員經常越出常軌,而不是關注重要的測試任務?