本指南旨在幫助讀者制定
測試計劃。請注意，真正的測試計劃是實際指導自己實施測試的一套想法。不管讀者是否制定書面測試計劃，我們設計的這個指南都會有所幫助。
本指南并不是一種模板，不是供讀者填寫的表格，而是一組旨在幫助讀者思考的思想，用于降低讀者遺忘重要內容的可能性。我們使用的是簡潔語言和描述，有可能不太適合測試新手。本指南主要向有經驗的測試員或測試組長提供支持。
以下分 七個任務主題。這些主題沒有一定順序。實際上，讀者可以按任何順序閱讀。只是需要注意，測試計劃的質量與是否很好地執行了任務以及使否很好地考慮了像這里提出的問題相關。狀態檢查部分有助于讀者確定是否制定了足夠好的測試計劃，但是我們建議讀者要在整個項目開發過程中，重新檢查并修改測試計劃（至少要在心中修改）。
1. 監視影響測試計劃的主要問題
確定影響制定實用、有效的測試策略中時間、
工作量或可行性要素的風險、障礙或其他挑戰。要把握計劃的整體作用。在整個項目開發過程中，全程監視這些問題。
____ 狀態檢查___________________________________________________
□ 是否有要滿足的特別關鍵或很難度量的產品質量標準？
□ 產品是否復雜或很難學會？
□ 測試員是否需要特殊培訓或工具？
□ 是否很難得到或配置的部分測試平臺？
□ 是否將測試未集成或半可操作的產品組件？
□ 是否存在具體的可測試性問題？
□ 項目團隊是否缺乏產品設計、技術或用戶群的經驗？
□ 測試是否必須很快開始？
□ 是否有制定測試計劃所需的信息還沒有收集到？
□ 是否能夠評審被測產品的某個版本（甚至是演示版、原型版或老版本）？
□ 是否有足夠的難以錄用或組織的測試人員？
□ 是否必須遵循自己所不熟悉的測試理論？
□ 項目計劃的制定是都沒有考慮測試需要？
□ 計劃是否要經過漫長的協商或批準？
□ 測試員是否遠離客戶？
□ 計劃是設計的一個內容嗎？
□ 客戶是否說不出測試員能夠為他們做什么？
2. 明確任務
本節給出的任何一部分或全部目標都可能是具體測試任務的一部分。有些任務比另外一些更重要。根據對具體項目的了解，為這些目標排隊。對于所有使用的目標，找出可以用來評判的具體的成功指標。
需要考慮的任務要素
□ 快速找出重要問題。
□ 進行綜合質量評估。
□ 確認產品質量是否達到具體標準。
□ 盡可能縮短測試時間或降低測試成本。
□ 盡可能提高測試效率。
□ 就提高質量或可測試性問題，向客戶提出建議。
□ 就如何測試向客戶提出建議。
□ 保證測試過程總是可以充分說明的。
□ 嚴格遵守特定的方法或指示。
□ 使特定的項目相關人員感到滿意。
可能的工作產品
□ 說明測試任務的簡短電子郵件。
□ 一頁紙篇幅的測試要求。
____ 狀態檢查___________________________________________________
□ 是否知道誰是自己的客戶？
□ 關鍵人物是否贊同測試任務？
□ 測試任務是否足夠清晰，以作為制定計劃的基礎？
3. 分析產品
了解被測試產品及其內部技術。了解如何使用被測產品。需要深入下去。隨著對產品了解的深入，測試會變得越來越好，因為自己越來越接近成為產品專家
分析什么
□ 用戶（用戶是誰，他們的職業是什么）。
□ 結構（代碼、文件等）。
□ 功能（產品做什么）。
□ 數據（輸入、輸出、狀態等）。
□ 平臺（外部硬件和軟件）。
□ 運營（產品是用來完成什么任務的）。
分析方式
□ 執行探索式測試。
□ 評審產品和項目文檔。
□ 與設計人員和用戶面談。
□ 與類似產品進行比較。
可能的工作產品
□ 測試覆蓋大綱。
□ 帶注釋的規格說明。
□ 產品問題清單。
____ 狀態檢查___________________________________________________
□ 設計人員贊同產品覆蓋大綱嗎？
□ 設計人員認為測試員了解產品嗎？
□ 測試員能夠可視化產品并預測產品行為嗎？
□ 測試員能夠產生測試數據（輸入和結果）嗎？
□ 測試員能夠配置并操作被測產品嗎？
□ 測試員理解產品將被怎樣使用嗎？
□ 測試員是否發現設計中的不一致問題？
□ 測試員是否找出顯式和隱式規格說明？
4. 分析產品風險
被測產品可能怎樣以一種重要方式失效？開始測試員最多也智慧有一個一般想法。隨著測試員對產品了解的深入，測試策略和測試會變得越來越好，因為對被測產品的失效機理了解的越來越多。
分析對象
□ 威脅（具有挑戰性的條件和數據）。
□ 脆弱性（在什么地方可能失效）。
□ 失效模式（可能的問題種類）。
□ 失效影響（問題的嚴重程度）。
分析方式
□ 評審需求和規格說明。
□ 評審實際失效。
□ 與設計人員和用戶面談。
□ 對照風險啟發和質量評判大綱評審產品。
□ 找出一般問題和失效模式。
可能的工作產品
□ 組件/風險矩陣。
□ 風險清單。
____ 狀態檢查___________________________________________________
□ 設計人員和用戶對風險分析認可嗎？
□ 測試員能夠找出所有重要的問題種類嗎？這些問題都應該在測試期間出現嗎？
□ 為了盡可能提高測試效果，測試員知道該把測試工作集中到哪些對象上嗎？
□ 設計人員是否采取措施使重要問題更容易被檢測，或降低發生的可能性？
□ 測試員如何發現自己的風險分析是否準確？
5. 設計測試策略
為了根據已有的產品最佳信息快速、有效地測試，測試員可以做什么？首先盡可能做出最好的決策，同時又要讓測試策略能夠在項目整個開發過程中改進。
考慮五方面的手段
□ 以測試員為核心的手段。
□ 以覆蓋率為核心的手段（結構覆蓋率和功能覆蓋率）。
□ 以問題為核心的手段。
□ 以活動為核心的手段。
□ 以評估為核心的手段。
計劃方式
□ 針對風險和產品域確定手段。
□ 可視化具體和實用手段。
□ 使測試策略多樣化，盡可能減少遺漏重要問題的機會。
□ 尋找通過自動化測試擴展測試策略的途徑。
□ 不要計劃得過死，使測試員能夠發揮自己的才智。
可能的工作產品
□ 逐項列出的每條所選測試策略以及如何運用的說明。
□ 風險/任務矩陣。
□ 所選測試策略固有的問題或挑戰清單。
□ 針對沒有充分覆蓋的產品部分提出的建議。
□ 測試用例（僅當需要時）。
____ 狀態檢查___________________________________________________
□ 客戶認同測試員制定的測試策略嗎？
□ 測試策略給出的所有內容都是必要的嗎？
□ 測試策略是否能夠實際貫徹？
□ 測試策略是否過于通用？可以容易地用于任何產品嗎？
□ 是否還有不準備測試的任何重要問題？
□ 測試策略利用了可用的資源和幫助者嗎？
6. 條件計劃
測試經理將如何實現測試策略？測試策略會受到條件約束或指示的很大影響，努力爭取所需的資源，并盡量利用可用的所有資源。
保障條件方面的問題
□ 測試工作量估計和進度評估。
□ 可測試性宣傳。
□ 測試團隊力量（合適技能）。
□ 測試員培訓與管理。
□ 測試員任務分配。
□ 產品信息收集與管理。
□ 項目團隊會議、溝通和協同。
□ 與項目團隊所有其他小組、包括開發小組的關系。
□ 測試平臺的獲得和配置。
□ 約定和協議。
□ 測試工具和自動化測試。
□ 插樁和模擬需要。
□ 測試包的管理和維護。
□ 構建和傳送協議。
□ 測試周期管理。
□ 錯誤報告系統和協議。
□ 測試狀態報告協議。
□ 代碼凍結與增量測試。
□ 項目最后的壓力管理。
□ 測試停止協議。
□ 測試效果的評估。
可能的工作產品
□ 問題清單。
□ 產品風險分析。
□ 責任矩陣。
□ 測試進度計劃。
____ 狀態檢查___________________________________________________
□ 項目團隊的保障條件是否支持已制定的測試策略？
□ 是否存在阻礙測試的問題？
□ 測試條件和策略是否能夠修改，以適應可以預見的問題？
□ 現在是否可以開發測試，以后再解決其余問題？
7. 共享測試計劃
測試員并不孤獨。測試過程必須服務于項目團隊。因此，要吸收項目團隊成員參與測試計劃的制定。不必夸大這個問題，至少要與團隊的關鍵成員討論，從而得到他們的理解和隱含的支持，以爭取實現測試計劃。
共享方式
□ 吸收設計人員和項目相關人員參加測試計劃制定過程。
□ 積極征求有關測試計劃的意見。
□ 盡自己所能幫助開發人員獲得成功。
□ 幫助開發人員理解他們的行為會對測試產生的影響。
□ 與技術文檔編寫員和技術支持人員就分享質量信息進行溝通。
□ 請設計人員和開發人員評審和批準參考材料。
□ 記錄和跟蹤約定。
□ 請別人分段評審測試計劃。
□ 通過減少測試計劃文檔中不必要的文字，來改進文檔的可評審性。
目標
□ 對測試過程的一致理解。
□ 對測試過程的一致承諾。
□ 測試過程的合理參與。
□ 管理層對測試過程的合理預期。
____ 狀態檢查___________________________________________________
□ 項目團隊是否關注測試計劃。
□ 項目團隊，特別是一線管理人員是否理解測試小組的角色？
□ 項目團隊是否感覺到測試小組關心項目團隊的最佳利益？
□ 測試小組和項目團隊其他小組之間是否有對立或積極的關系？
□ 是否有人認為測試員沒有將注意力集中到重要的測試上？
=========================================================================
這是一篇很長的文章，是討論如何制定語境驅動測試的測試計劃。會有很多的檢查項，幫助讀者不要忘記重要的內容。如果想照搬，肯定是不現實的。