主題：如何制定測試計劃 在測試階段，測試經理要綜合考慮以下影響測試的因素并完美地協調其中各個要素的關系，只有這樣做才能避免在測試過程中出現種種意外并影響測試的質量：
測試組建立、測試范圍的選擇、測試組的培訓、測試平臺的選擇和配置、測試技術和工具的選擇、測試執行的日程和進度、測試用例的設計、維護和更新、測試環境的設計和搭建、測試文檔的格式和提交時間、測試入口/出口的checklist、測試組成員的管理和激勵機制、測試過程的流程和定義、測試過程的質量監控。
一、測試團隊的建立和組織
測試團隊按照職能可分為四類組織：
1）測試設計和執行組，這類組織獎占有大部分的測試人力資源，負責測試的設計和執行。
2）技術支持組，測試中有兩種時候會用到特別的技術支持，一是測試工作平臺，包括測試用的各類數據庫，其維護和支持需要有專門技能的人負責；二是測試環境，測試環境隨測試對象的不同而大相近庭。
3）問題管理組，這些人的職責是處理和跟蹤測試中發現的問題，以保證所有發現的問題，在正確的時間，由正確的人，在正確的軟件基線上做正確的解決，最后由測試人員在正確的版本上做正確的驗證。
4）質量監控組，負責監控測試本身的質量，以保證測試能夠有效和有序的執行。
二、測試范圍的選擇
三、測試團隊的培訓
培訓分兩類，技術類和流程類。
技術類培訓專注于測試中將遇到的技術問題，比如待測產品的技術、設計和方案的培訓，測試工具的使用培訓等（QA在每次培訓前都宣布要針對培訓的內容進行考核，有力減少培訓中缺席、早退、打瞌睡等現象）；
流程類培訓是告訴大家如何按照事先約定的方式去工作（每一個測試活動都有相應的流程指導書，里面會對具體的行為做具體的規定）。
四、測試平臺的選擇和配置
測試團隊不借助任何平臺的結果：
1）成千上萬的測試用例無法有效管理，測試開始之初無從知道哪些測試用例對此項目是有用的，這將在很大程度上增加測試準備期的工作量。而且對于不同的軟件版本進行不同的測試覆蓋選擇時也會極不方便。
2）測試人員在測試過程中需要為每個測試用例填寫測試結果，但通常測試經理的苦惱在于：如果沒有工具有效管理這種行為，那么對于測試的進度無法有效地了解，測試當時的狀況，如測試用例的通過率，可執行率等數據都很難實時地得到。
3）測試中必然會發現問題，問題管理也是一大繁瑣的問題，這涉及一個工作流程的問題。
測試計劃階段需要明確我們即將采用何種測試平臺工具來實施測試，在此之后還有一系列的安裝、配置、培訓和維護等諸多方面的問題需要關注。
測試平臺主要包括：測試用例數據庫、測試計劃數據庫、測試報告數據庫、問題跟蹤數據庫。
五、測試技術和工具的選擇
測試從技術角度上有多種分類，其實如何分類并不重要，重要的是在某一測試項目中如何篩選適合本項目的技術手段才是最實際的問題。測試中并不是最有技術含量、最有吸引力的手段就一定是最適合的。
測試計劃階段中需要做的是：了解自己的項目需要什么測試。了解每種測試技術適合的范圍。之后得出結論：在本測試項目中，哪種測試技術是最有效的，以及針對這種測試技術需要做出哪些資源和人力方面的準備。
六、測試執行的日程和進度 測試經理需要明確清楚地回答這幾個問題：什么時間，在什么版本上，出于什么目的，做哪些和測試相關的活動。
通常的經驗，對于軟件測試項目來講，測試要進行至少四輪才有意義。
1）第一輪，驗證功能，提交發現的問題；
2）第二輪，驗證提交的問題是否被修改，同時看是否在修改后引入了新問題；
3）第三輪，驗證性能，假定前兩輪測試后那些低級的功能性的錯誤已經被消滅的差不多了，這時需要創造一些惡劣的環境，來驗證軟件是否足夠強壯；
4）第四輪，全面驗證軟件的全部待測點，并根據本次測試的結果評估產品上市的風險。
并不是所有的問題都是在測試開始第一輪就可以被全部發現，原因有幾個方面：
1）測試人員在第一輪可能尚未進入狀態，對待測產品的熟悉還有待提高；
2）測試進行中，可能有一些問題阻礙了其他問題的發現；
3）依靠執行測試用例不可能發現100%的錯誤，軟件的功能好比是面，靠孤立的點來覆蓋面試完全不可能的。因此測試的主觀因素就永遠不可避免。測試人員的靈機一動可能會發現很多重要的問題，而這種問題的發現一定要依靠一定的時間和工作量的積累。
M0（軟件項目啟動，需求定義階段）—M1（分布式開發階段）—M2（總體聯調階段）—M3（產品上市）
Mo—M1階段：測試的人才儲備期，主要從人力及其培訓方面做準備，保證在將來的測試階段有足夠熟練新技術新功能的測試人員；
M1—M2階段：測試的技術流程準備期，依據項目明確下來的需求，分別從計劃、技術、工具、環境、團隊、流程等方面做準備。包括制定測試計劃，設計測試用例，搭建測試環境，組建測試團隊，明確測試流程等；
M2—M3階段：測試的全速實施期，整個測試團隊按照之前的準備全速執行測試，力求在最短的時間內發現最多的問題；
M3后：對測試仍舊極為重要，測試團隊需要根據市場的反饋了解產品在市場上發生了哪些情況，協助開發人員復現這些問題，以使這些問題得到最快的定位和修改，而減少在市場上的負面影響。
測試日程的制定需要根據兩個文檔，第一是總體的項目時間表，第二是項目的軟件版本發布計劃。
制定測試日程需遵循以下原則：
1）每個軟件版本一定要有一個版本基本測試，目的是在最短的時間里判斷軟件是否值得一測；
2）在所有功能都集成起來之前不需要進行系統測試，但應該按照集成模塊的次序，進行各個子系統的測試；
3）現場測試盒互操作性測試要在系統測試進行至少兩輪之后才開始，以保證最基本的功能性問題已經被發現并解決；
4）壓力測試發生在上市之前的一兩個版本上，主要目的是試圖復現那些影響較大但復現概率極低的問題。
七、測試用例的設計、維護和更新 測試用例是所有測試活動的技術基礎，實在是非常值得把時間和人力投在它上面。
關于用例問題測試部與開發部之間的溝通：
1）每天開發工程師抽出半小時時間來回答測試人員的疑問
2）開發的任何一點變化都要在需求變更庫中存檔，數據庫的權限要同時開放給相關的測試人員，測試人員每天都需要在需求變更庫中檢查這些變更，同時同步地更新測試用例。
對于測試用例開發，在第一個軟件版本發布之前，基本測試用例集必須完成，針對新模塊的測試用例必須在該模塊第一次發布之前完成。
測試用例在以下三種情況下必須得到更新：
1）需求變更庫中顯示需求方出現了變動，相應的測試用例必須修改；
2）測試組內部評審時發現測試用例覆蓋不夠全面時，需要添加新的測試用例；
3）自由測試中發現了問題，相應的測試用例必須被添加。
八、測試環境的設計和搭建
九、測試文檔的格式和提交時間
測試團隊對外的輸出文檔有二：一是問題報告，二是測試報告。測試計劃中要清楚地寫明對這些報告內容上和時間上的要求。
測試報告是在測試的某一階段后，對測試過程的總結和待測短劍/版本的成熟度和風險的評估。
十、測試入口/出口的checklist
每一個測試項目的每一個環節都要有清楚的入口和出口的準則，也就是清楚的定義什么情況下測試可以開始和什么情況下測試應該結束。
軟件在提交系統測試之前應該按照事先約定的標準（checklist）進行一定的審查，以避免倉促提交測試再被一腳踢回來。
測試循環開始的Checklist：
1）版本的發布是否遵循了《項目軟件版本發布計劃》？
2）隨著版本的發布，是否一起提交了版本發布說明？
3）版本發布說明中是否詳細描述了此版本與上一版本的區別？
4）改動部分是否執行了單元測試和集成測試，是否有測試報告？
5）版本發布前是否對簡單功能進行了基本驗證？
6）版本發布說明中是否包含解決問題的列表和未解決問題的列表？
測試團隊自身也要有Checklist，即測試循環結束的Checklist：
1）該版本的測試報告是否已提交？
2）測試報告中是否對軟件的狀態下出了結論？
3）各子模塊測試的報告是否已提交？
4）是否100%完成了更改問題的驗證工作，是否有驗證結果的匯總？
5）該版本上新發現問題的列表是否已提交？
6）所有遺留問題的列表是否已提交？
7）所有遺留問題中最嚴重的TOP10是否已提交？
8）以上所有輸出物是否都按照標準化文檔模板書寫的？
十一、測試組成員的管理和激勵機制 我們已經充分地了解了測試的特殊性，它要求測試人員隨時保持旺盛的斗志，在強調職業道德的同時，一定的物質激勵措施絕對是有必要的。
十二、測試過程的流程和定義
測試并不是技術驅動的工作，更多的是管理和流程驅動的活動。
測試計劃中要描述兩大部分的流程，第一部分是測試管理流程，可以簡單的概括為計劃、實施和報告三部曲；第二部分是問題管理流程，規定如何管理、維護和跟蹤測試中發現的問題。
測試團隊方面常見的問題有：
1）有時候問題單輸入的質量不高，需要的信息提供不準或者不全，開發人員無法理解問題的全貌，往往需要經過多次溝通才能解決；對于異地開發甚至跨國開發的項目，這種溝通成本是很高而且低效的；
2）多個測試人員在填寫問題單時溝通不夠，經常同一個問題多個人多次上報，導致問題單的數目大于實際問題的數目，會給開發人員和問題管理員增加很多重復勞動；
3）測試人員對于功能的理解不夠深入，往往報告一些實際上不是問題的偽問題，這樣會增加其他團隊的工作量；
4）驗證問題的效率和準確性有待提高，有時候測試人員更喜歡追逐新問題，對舊問題的驗證興趣不高，但是對于項目來說，舊問題的驗證卻更有價值。
針對四大問題對測試流程進行修正：
1）QA需要抽查問題單的輸入質量；
2）測試人員在填寫問題單前需要在數據庫中按關鍵字搜索相關問題，只有確信以前沒有人提交過時才上報；
3）增強培訓，最大限度減少誤報；
4）在流程上保證驗證問題的優先級，規定在一個版本測試中，最先做的就是舊問題的驗證。
十三、測試過程的質量監控
測試過程的監控應該針對六大關鍵點：
1）測試計劃的風險評估；
2）測試文檔的質量；
3）計劃實施的質量；
4）測試報告的質量
5）問題管理的質量
6）測試范圍與覆蓋率的完備性。
版權聲明：本文出自 hellorenwei 的51Testing軟件測試博客：http://www.51testing.com/?578951
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
相關鏈接：
《笑傲測試》筆記（前言+第一式：廬山面目）
《笑傲測試》筆記（第二式：蓬門始開）
《笑傲測試》筆記（第四式：矯如龍翔）
《笑傲測試》筆記（第五式：浮云遮日）