合格的測試計劃是怎樣誕生的？

不管是剛畢業的Tester仍是測試老鳥，是否想過「測試計劃」怎麼寫？之前寫的測試計劃「合格」嗎？我想不少人沒法給出答案。

作測試計劃一般是一件很是複雜的事情，一個理想的測試計劃要完成「投資回報分析」和「風險分析」，在軟件開發的衆多因素中尋求一個最優解：

• 實現投入： 實現「可測試性」和某些場景的自動化測試，須要花費大量的時間，還會增長軟件複雜度。會增長短時間內的研發投入。

• 維護投入：不管是自動化測試仍是手工測試，都會不一樣程度地增長長期投入。 財務投入： 有些測試可能會須要資金投入。

• 回報：測試可以減小軟件bug，並在不一樣程度上提高生產力。在軟件研發過程當中，越早發現問題，帶來的收益越大。

• 風險：沒法預測何時會碰到出問題的場景，而一旦出問題，帶來的後果也沒法預測：可能只是對用戶體驗有少量影響，也多是一場災難。

要有效的平衡以上因素，須要評估項目的具體狀況：如何實現的？資源是否可用？團隊是什麼意見？儘管許多項目可以作到「低投入，高回報」的高覆蓋率單元測試，可是他們也須要衡量「larger tests」和更復雜的場景。關鍵性的項目必須儘量的下降風險，爲了覆蓋全部的測試層級，可能會作出一個高投入的測試決策。

本文將圍繞「如何找到項目中的平衡點」展開。由於模板每每不具有通用性，並且很容易「過期」，因此在這裏並不會提供測試計劃模板。內容聚焦於作測試計劃的過程當中「如何選擇最優的內容」。

測試計劃 vs. 測試策略
開始以前，先澄清一下兩種定義測試計劃的方式：

• 單個測試計劃： 一些項目擁有單個「測試計劃」，描述與項目相關的全部實現與測試。

• 單個測試策略+多個測試計劃：
  一些項目擁有單個「測試策略」和許多小的「測試計劃」文檔。測試策略覆蓋全部的測試路徑與目標，測試計劃覆蓋特定的特性或者項目更新。

或許兩種「測試計劃」並無孰優孰劣之分，請針對具體的項目具體選擇。通常來講，穩定的項目選擇「單個測試計劃」更好，變化頻繁的項目更加適合「固定測試策略」+「不固定增長的測試計劃」。

內容選擇
作測試計劃最好的方式是羅列出全部須要解答的問題。不管是否會對項目產生影響，咱們都要全面的進行收集全部重要問題。瀏覽一下收集的問題列表，篩選出全部影響項目的問題。在回答這些問題的過程當中，就能夠理出測試計劃的內容，而後以團隊可接受的方式編寫一份測試計劃（須要綜合考慮上文中提到的幾個因素來衡量計劃的內容）。

前提

• 須要測試計劃嗎？ 若是沒有項目設計文檔或者還不清楚項目長什麼樣，那麼不要急着去寫測試計劃。

• 可測試性是否被歸入了項目設計？
  在項目開始大規模開發以前，必須爲全部的場景設計可測試性，最好可以支持自動化測試。項目設計文檔和測試計劃中都須要對可測試性提出要求。

• 須要持續更新測試計劃嗎？ 若是要持續更新，請不要在計劃中描述太多的細節，不然將難以維護。

• 工做成果是否與其餘團隊有重疊？ 若是有重疊，如何避免重複工做？

風險
是否有明顯的項目風險，如何減小風險？ 例如：

• 會傷害人或動物

• 影響用戶數據的安全性和完整性

• 侵犯用戶隱私

• 影響公司系統安全

• 致使硬件或財產損失

• 存在法律或誠信問題

• 泄露機密或者敏感信息

• 致使數據丟失

• 致使收入減小

• 存在沒法覆蓋的場景

• 須要知足性能要求

• 誤導用戶

• 影響其餘項目

• 被其餘項目影響

• 影響公司對外形象

• 下降生產力

項目有哪些技術缺陷？ 例如：

• 已知特性或者組件容易被入侵，健壯性查，或者急需重構

• 項目依賴的組件或者平臺頻繁致使問題

• 用戶有可能會對系統形成破壞

• 以往問題的趨勢如何

覆蓋率

• 項目長什麼樣？ 是一個只有一個方法的簡單library，仍是有複雜用戶場景的軟件系統？描述被測系統的設計和架構，分析可能出問題的地方。

• 支持什麼平臺？ 建議列舉出支持的操做系統，硬件，設備等。描述一下不一樣平臺上測試的表現。

• 有什麼特性？ 建議將全部特性列出概要清單，描述一下哪些特性要進行測試

• 哪些內容不會被測試？沒有一種測試會覆蓋全部可能性。最好提早想好哪些用例不會進行測試。例如：」低風險低優先級用例「，」複雜功能低優先級用例「，」被其餘團隊測試過的功能「，」沒有準備好的特性「等等，都屬於低風險功能，而不會進行測試。

• 單元測試（small）、集成測試（medium）、系統測試（large）分別應該覆蓋那些功能？ 儘量多地作「smaller tests」，少部分的用例使用「larger tests」。描述一下不一樣種類測試用例分別在哪一種規模的測試中進行，並提供理論依據。

• 哪些用例要手工執行，哪些用例要自動化？若是自動化具有可行性而且實現代價不高，一般是最好的選擇。許多項目能將全部測試都自動化。然而，有些項目選擇手工測試也有充分的理由。描述一下什麼樣的測試用例要進行手工測試，並提供理論依據。

• 是否覆蓋了全部測試類型？ 例如：可達性,功能 模糊（測試,國際化和本地化 性能，加載，壓力和耐久性,隱私安全性,冒煙,穩定性,易用性

• 須要使用靜態和/或動態分析工具嗎？ 不管是靜態分析工具，仍是動態分析工具都可以找到一些測試過程當中很難找到的問題，因此建議使用分析工具。

• 測試過程當中，系統組件和依賴之間是「stubbed」，」mocked」，」faked」，」staged」,仍是正常使用？
  每一項內容都會影響最終的測試覆蓋率。

• 測試運行在哪一個」構建「之上？ 在」HEAD「，」stage「，仍是」待發布「版本之上？若是是在」HEAD「上測試，怎麼測試」cherry picks（只發布部分改動）「？怎麼測試系統配置的改變？

• 什麼樣的測試應該在團隊以外進行？ 例如：」吃狗糧「,外部的衆包測試,公開的」alpha/beta「版本（如何在正式發佈前測試）,可信的外部Tester

• 怎麼測試數據遷移？ 可能須要特殊的測試來對比遷移數據先後的結果。

• 是否須要關注向後兼容？ 可能存在一個之前版本的客戶端，或者有另一個系統依賴於當前系統的協議、配置、特性或者行爲。

• 是否須要測試」服務器/客戶端/終端「的升級場景？是否須要測試軟件所依賴的」庫/平臺/API「？

• 是否有代碼行的覆蓋率的目標？

工具和基礎建設

• 是否須要新的測試框架？ 若是須要，請描述或者在測試計劃中增長設計連接。

• 是否須要新的測試實驗室？ 若是須要，請描述，或者在測試計劃中增長設計鏈接。

• 若是當前項目爲其餘項目提供服務，是否要像用戶提供測試工具？
  建議提供」mocks「，」fakes「和/或可靠的stage服務器，方便用戶進行集成測試。

• 對於end-to-end測試，如何管理測試基礎設施、被測系統和其餘的依賴？
  如何部署？如何持續地進行」set-up/tear-down「？數據遷移怎麼作？

• 是否須要工具來對系統進行debug或者測試錯誤？ 可使用現有的工具，也可能須要開發一款新的工具。

執行過程

• 是否要拿出一個測試時間表？ 什麼時間，會進行哪一項測試（或者提供測試結果）？是否一些測試的比其餘測試更加劇要？

• 如何持續不斷的進行構建和測試？ 大部分」small tests「會經過持續集成工具來運行，可是」large
  tests「可能須要不一樣的運行方式。

• 如何上報和監控構建和測試的結果？是否有一個團隊負責監控持續集成？」large
  tests「可能要求專業技術人員來進行監控。是否有一個dashboard來查看測試接結果和項目的健康度？如何發送告警郵件，以及告警郵件會通知哪些人？監控測試的同事只是簡單地以口頭傳達的方式通知團隊嗎？

• 發佈過程當中如何進行測試？是否是隻會使用」待發布版本「，或者發佈的程序嚴格依賴於持續測試的結果？若是系統組件和依賴要被獨立發佈，是否在每個發佈類型上都進行了測試？發佈決策者是否會由於」阻塞發佈」的bug而中止發佈？「阻塞發佈」是否有統一的標準？首次發佈的時候，如何監控進度並組織測試？

• 外部用戶如何上報bug？ 建議增長反饋鏈接或者其餘相似的工具來收集上報的問題。

• 如何將bug分類？ 建議使用標籤和類型對bug進行分類管理。同時確保團隊也要使用與此相同的bug上報模板。

• 應該被解決的bug未解決就要被close，是否有一種機制能夠提交新的測試？

• 未提交的改動如何進行測試？ 若是有人能作到，建議提供使用說明。

• 團隊成員如何構建測試 和/或 進行debug？ 建議提供使用說明。

使用

• 測試計劃的讀者是誰？
  雖然有些測試計劃會被許多人讀到，可是有些測試計劃只會被不多一部分人讀到。測試計劃至少應該被全部的利益相關者（項目管理者，技術leader，產品管理者）review。寫測試計劃的時候爲了確保讀者可以理解，須要提供足夠的背景材料，回答全部可能的疑問。同時，建議在測試計劃中增長聯繫方式，方便讀者可以獲取更多的信息。

• 讀者如何review測試用例？
  手工測試用例可能會被放在一個測試用例管理工具中，可能會放在單獨的文檔中，也可能直接寫在測試計劃中。自動化測試建議提供對應的連接。

• 需求、特性和測試之間是否須要可追溯？

• 是否有通用的產品健康度或者質量目標？如何進行評估？ 例如：
  發佈節奏,用戶發現的bug數量,在「release testing」中發現的bug數量,超時未解決的bug數量,代碼覆蓋率,手工測試的投入,建立新測試的難度

本文系TestBird測試工程師編譯整理。想了解更多開發測試相關信息，請訪問 TestBird。
原文地址：
http://googletesting.blogspot...