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