《笑傲測試》筆記（第六式：伯仲伊呂）

主題：如何制定測試計劃

　　在測試階段，測試經理要綜合考慮以下影響測試的因素並完美地協調其中各個要素的關係，只有這樣做才能避免在測試過程中出現種種意外並影響測試的質量：

　　測試組建立、測試範圍的選擇、測試組的培訓、測試平臺的選擇和配置、測試技術和工具的選擇、測試執行的日程和進度、測試用例的設計、維護和更新、測試環境的設計和搭建、測試文件的格式和提交時間、測試入口/出口的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）測試範圍與覆蓋率的完備性。

====================================分割線================================

最新內容請見作者的GitHub頁：http://qaseven.github.io/