轉自：http://tmq.qq.com/2016/10/do-need-to-consider-all-aspects-of-the-test-plan/
【本文系google blog翻譯】
如何做測試計划書，並能有理有力的推動測試計划實施？三星手機連爆事件警醒我們質量是企業頭上的一把刀，也是測試工程師頭上的一把刀。那么如何做好測試工作？ 首先要做好測試計划並推進計划實施，認真思考並回答文章中這些問題。
原文鏈接：http://googletesting.blogspot.com/2016/06/the-inquiry-method-for-test-planning.html
制定測試計划是一項復雜的工作。一個理想的測試計划通過成本收益分析和風險分析綜合平衡軟件開發（kevndi備注：本文中的軟件開發是軟件工程中的軟件開發，包括開發和測試）的相關因素來實現：
- 開發成本：一些特殊場景提供可測試版本和實現自動化測試耗費的時間和復雜性差別很大，而這會影響短期開發成本。（kevindi備注：google基本上是做全自動化測試）
- 維護成本：有些測試工作或測試計划維護成本差別很大，可能很容易也可能很難維護，這會影響長期的開發成本。如果需要手動測試，這也會增加長期成本。
- 金錢成本：有些測試方法可能需要付費資源。
- 測試收益：測試是能夠預防問題，並不同程度上助力項目開發（kevindi備注：提高開發效率）。當然，越早發現問題助益越大。
- 風險：缺陷場景的出現概率會有所不同，可能極少出現也可能大部分情況都出現。他們的影響可能是輕微滋擾，也可能是災難性的后果。
在測試計划中准確的平衡這些因素在很大程度上取決於項目的重要性、實施細節、可利用的資源和團隊的意見。許多項目在單元測試中可以高收益，低成本的實現很高的覆蓋率，但他們可能需要權衡大規模的測試和復雜邊界情況的測試。關鍵項目必須最大限度地降低風險，所以他們將接受更高的成本，對各級測試用例都大量投入資源。
這份指南用於幫助讀者在自己的項目中找到平衡點。此外，它並沒有提供一個測試計划模板。模板，因為往往過於籠統或過於具體，很快就會過時。相反，它着重於教你編寫測試計划時，如何選擇合適的內容。
測試計划與策略
首先，需要澄清測試計划兩種常用方法：
單一的測試計划：有些項目有一個“測試計划”，它描述了項目所有執行和計划中的測試。
單一測試策略和大量計划：一些項目有“測試策略”文件以及許多較小的“測試計划”文件。策略通常涵蓋了整體的測試方法和目標，測試計划涵蓋特定功能或項目變更。
他們都可以寫進或者集成到項目設計文件檔。這兩種方法都很有效，所以可以根據項目情況任意選擇。一般來說，穩定的項目受益於一個單一的計划，而迅速變化的項目，最好選擇不經常更改的策略和經常變更的計划。在這份指南中，我將把兩種測試文檔類型簡單地統稱為“測試計划”，如果您有多種類型文檔，只需要把下面的建議應用到全部文檔。（kevindi備注：下面開始通過一系列的問題引導讀者編寫測試計划）
內容選擇
寫測試計划的一個好辦法是先列出所有需要回答的問題，下面的清單提供了所有可能會適用於你的項目的重要問題。瀏覽一遍列表然后選擇適用的。通過回答這些問題，你就可以確定測試計划的內容，你應該圍繞所選內容以你團隊喜歡的格式創建測試計划。做選擇時，請務必平衡好上面提到的影響軟件開發的各種因素。
前提條件
你需要一個測試計划嗎？如果沒有項目設計文檔或一個清晰的產品概念，你可能不需要這么早編寫測試計划。
項目設計階段考慮了可測性嗎？項目開始實施前，所有方案必須設計為可測試的，最好是通過自動化。項目設計文檔和測試計划都應根據需要添加可測性評價。
你需不需要保證測試計划是最新的？如果是這樣，請注意不要添加太多的細節，否則可能難以維護測試計划。
其他團隊也做質量保障嗎？如果是這樣，你怎么減少重復性的工作？
風險
- 是否有任何關鍵的項目風險，以及你將如何緩解呢？比如：
傷到人或動物用戶數據的安全性和完整性用戶隱私公司系統的安全性硬件或財產損失法律與合規問題機密或敏感數據暴露數據丟失或損壞
收入損失
不可恢復的場景
服務水平協議
性能要求
誤導用戶
影響到其他項目
受他項目的影響
影響公司的公眾形象
生產力損失
- 該項目有沒有技術漏洞？試想一下：
功能或組件沒有特色，易出故障，或者急需重構開發平台和其他依賴庫（SDK等）經常出錯用戶危害到系統的可能性已知的技術漏洞
覆蓋
測試入口是什么樣的？它是只有一個對外接口的庫，還是一個多平台，有客戶端-服務器且有大量用戶狀態組合的系統？在測試計划中重點說明系統設計和架構可能出現的故障。
支持哪些平台？考慮列出所支持的操作系統，硬件、設備等，還需要說明各個平台如何執行測試用例，如何輸出測試結果。
有哪些功能點？考慮把所有功能做一個摘要列表，指出哪些功能是需要測試的。
究竟要不要測試？沒有測試套件會涵蓋所有的可能性。我們需要直面這個事實，並說明部分用例無法執行的原因。比如：低優先級且低風險的用例，低優先級且復雜的用例，其他團隊覆蓋的部分，沒有達到測試標准的功能等。
需要在什么用例中覆蓋？單元測試（小），集成測試（中）還是系統測試（大）用例中覆蓋？一般盡量在較小的用例測試，盡可能減少大的測試用例。測試計划需要說明把測試用例放在各個階段執行的理由。
手動測試和自動化測試哪個是最好的？如果考慮可執行性和成本-收益，自動化通常是最好的。許多項目可以自動化實現所有的測試。但是，可能有更好的理由來選擇手動測試。測試計划需要描述手動測試用例的類型並提供理論基礎。
- 你是如何覆蓋每個測試類別？試想一下：
輔助（無障礙）功能測試功能測試模糊測試國際化和本地化性能，負載，壓力和耐久性測試（又名浸泡測試）隱私測試安全測試冒煙測試
穩定性測試
可用性測試
你會使用靜態和動態分析工具嗎？靜態分析工具和動態分析工具可以發現很難在review和測試發現的問題，因此推薦考慮使用它們。
如何對系統組件和依賴庫（SDK）stub, mocke, fake, stage和進行功能測試？我們都有足夠的動力去做這些事情，這些測試在覆蓋率上都有各自的影響。
測試用例是在什么構建版本上執行？最新構建版本測試（kevindi備注：日構建版本？），還是迭代穩定版本，或者預發布版本？如果只測試最新版本，那么你怎么做release版本的增量測試（每個release構建版本的changelist）和系統配置變更測試，這些無法在日構建版本中覆蓋到。（kevindi備注：這里指的是release版本間的升級測試）（原文：What builds are your tests running against? Are tests running against a build from HEAD (aka tip), a staged build, and/or a release candidate? If only from HEAD, how will you test release build cherry picks (selection of individual changelists for a release) and system configuration changes not normally seen by builds from HEAD?）
- 哪些測試將在您的團隊之外執行呢？例如：
開發自驗（DogFooding）外部眾包測試公開的alpha/ beta版本（他們發布前如何進行測試？）外部信任的測試（External trusted testers）
數據遷移是如何測試？您可能需要專門測試遷移前和遷移后的結果。
你需要關注向后兼容？你可能擁有已發布的客戶端或者有其他系統依賴你的協議，配置，特性和邏輯。
你需要測試升級服務器/客戶端/設備軟件或依賴庫(SDK)/平台/ APIs這些軟件組件？
你有代碼覆蓋率的目標嗎？
工具和基礎設施
是否需要新的測試框架嗎？如果是這樣，補充說明或在計划中添加設計環節。
你需要建立一個新的測試實驗室？如果是這樣，補充說明或在計划中添加設計環節。
如果您的項目需要為其他項目提供服務，你需要提供測試工具給這些用戶？考慮提供mocks, fakes, and/or reliable staged servers協助其他用戶進行集成測試。
對於端到端的測試，如何將測試基礎設施，測試系統，以及其他依賴庫（SDK）進行管理？他們如何部署？如何構建持續測試環境和恢復環境？如何做數據中心間的遷移工作？
你需要一些工具來幫助調試系統或異常測試嗎？您可以使用現有的工具，或者您可能需要開發新的。
過程
有測試進度要求？已經取得了哪些時間承諾，什么時間該完成什么測試（或提供測試反饋）？是否有些測試是更重要需要提前完成？
如何持續構建和測試？大多數小測試有持續集成工具運行，但大的測試可能需要其他方法實現。或者，如果有必要您可以選擇性地運行大型測試。
- 如何報告和監測系統構建及測試結果？
你有一個團隊來監控持續集成？大測試可能需要由具有專業知識的人來監測。你需要測試結果狀態圖和其他項目健康檢查工具嗎？誰會收到電子郵件警報又如何處理？只需要有人將測試檢測結果簡單地口頭匯報給團隊嗎？
- 測試在版本發布中起什么作用？
他們是明確要發布待測版本，還是依賴持續集成測試的結果來確定是否發布？如果系統組件和依賴庫（SDK）獨立發布，需要對他們的每個發布進行測試嗎？“阻塞發布”的bug真的能阻止管理者進行版本發布嗎？有沒有對阻塞發布的標准達成共識？如果進行版本預發布（內測版本、金絲雀版本），這個過程是如何監控和測試的？外部用戶將如何報告bug？可以考慮反饋鏈接或其他類似的工具來收集和匯總。如何完成bug派發工作？可以考慮用標簽和分類把bug放置到不同的過濾結果中，需要確保負責創建bug和創建bug報告模板中的團隊都指導這一點。您正在使用bug跟蹤系統或者你需要設置一些自動或手動導入任務？你有沒有制定一個規范，規定在已發現bug解決之前如何再次提測新版本？如何測試未提交的修改？如果任何人都可以對任何實驗版本執行所有的測試（一件好事），可以考慮提供一個HOWTO。
團隊成員如何創建和/或調試測試用例？可以考慮提供一個HOWTO。
實用技巧
誰是測試計划的讀者？有些測試計划只能由少數人看，有的則是被許多人看。至少，你應該考慮所有利益相關者（項目經理，技術負責人，特性負責人）都進行了review。當寫測試計划時，一定要了解讀者的期望，為他們提供足夠的背景了解該計划，並回答您認為他們可能存在的疑問——即使你的答案是，你也沒有一個答案。也可以考慮為測試計划添加聯系人，因此，任何讀者可以得到更多的信息。
讀者如何查看實際的測試用例？手工測試用例可能在一個測試用例管理工具里，在一個單獨的文件中，或者包含在測試計划中。考慮提供鏈接到包含自動測試用例的目錄。
你是否需要在需求、功能和測試用例之間建立關聯性？
- 你是否有產品健康或質量目標，你會如何衡量成功？試想一下：
發行節奏在開發階段用戶抓bug的數量在發布測試階段bug的數量延期解決Bug的數量代碼覆蓋率手動測試成本創建新測試用例的難度