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