【翻譯】做測試計劃需要考慮的方方面面

制定測試計劃是一項復(fù)雜的工作。一個理想的測試計劃是通過[成本效益分析]和[風(fēng)險分析]綜合平衡軟件開發(fā)（kevin備注：本文中的軟件開發(fā)是軟件工程中的軟件開發(fā)，包括開發(fā)和測試）的相關(guān)因素來實現(xiàn)：

開發(fā)成本：一些特殊場景提供可測試版本和實現(xiàn)自動化測試耗費的時間和復(fù)雜性差別很大，而這會影響短期開發(fā)成本。（kevin備注：google基本上是做全自動化測試）

維護成本：有些測試工作或測試計劃維護成本差別很大，可能很容易也可能很難維護，這會影響長期的開發(fā)成本。如果需要手動測試，這也會增加長期成本。

金錢成本：有些試驗方法可能需要付費資源。

測試收益：測試是能夠預(yù)防問題和不同程度的幫助生產(chǎn)力（kevin備注：這是測試驅(qū)動開發(fā)？不是特別理解）。此外，早先它們可以捕捉在開發(fā)生命周期的問題，更大的益處。

風(fēng)險：故障場景的概率可能會有所不同從極少出現(xiàn)到大部分情況都出現(xiàn)，他們的后果可能從輕微滋擾到災(zāi)難性的后果。

在測試計劃中準確的平衡這些因素在很大程度上取決于項目的重要性，實施細節(jié)，可利用的資源和團隊的意見。許多項目在單元測試中可以高效益，低成本的實現(xiàn)卓越的覆蓋率，但他們可能需要權(quán)衡大規(guī)模的測試和復(fù)雜邊界情況的測試。關(guān)鍵任務(wù)項目必須最大限度地降低風(fēng)險，所以他們將接受更高的成本，對各級測試用例都大量投入資源。

這份指南用于幫助讀者在自己的項目中找到平衡點。此外，它并沒有提供一個測試計劃模板。模板，因為往往過于籠統(tǒng)或過于具體，很快就會過時。相反，它著重于編寫測試計劃時，如何選擇合適的內(nèi)容。

測試計劃與策略

首先，需要澄清測試計劃兩種常用方法：

單一的測試計劃：有些項目有一個“測試計劃”，它描述了項目的所有執(zhí)行和計劃中的測試。

單一的測試策略和許多計劃：一些項目具有“測試策略”的文件以及許多較小的“測試計劃”的文件。策略通常的涵蓋了整體的測試方法和目標(biāo)，同時計劃涵蓋特定功能或項目變更。

他們都可以寫進或者集成到項目設(shè)計文件檔案集。這兩種方法都得很有效，所以可以根據(jù)項目情況任意選擇。一般來說，穩(wěn)定的項目受益于一個單一的計劃，而迅速變化的項目，最好選擇不經(jīng)常更改的戰(zhàn)略和經(jīng)常變更的計劃。在這份指南中，我將把兩種測試文檔類型簡單地作為“試驗計劃”，如果您有多種類型文檔，只需要把下面的建議應(yīng)用到全部文檔。

內(nèi)容選擇

寫測試計劃的一個好辦法是先列出所有需要回答的問題，下面的清單提供了所有可能會適用于你的項目的重要問題。瀏覽一遍列表然后選擇適用的。通過回答這些問題，你就可以確定測試計劃的內(nèi)容，你應(yīng)該圍繞所選內(nèi)容以你團隊喜歡的格式創(chuàng)建測試計劃。做選擇時，請務(wù)必平衡好上面提到的影響軟件開發(fā)的各種因素。

前提條件

你需要一個測試計劃嗎？如果沒有項目設(shè)計文檔或一個清晰的產(chǎn)品概念，你可能不需要這么早編寫測試計劃。
項目設(shè)計階段考慮了可測性嗎？項目開始實施前，所有方案必須設(shè)計為可測試的，最好是通過自動化。項目設(shè)計文檔和測試計劃都應(yīng)根據(jù)需要添加可測性評價。
你需不需要保證測試計劃是最新的？如果是這樣，請注意不要添加太多的細節(jié)，否則可能難以維護測試計劃。
其他團隊也做質(zhì)量保障嗎？如果是這樣，你怎么減少重復(fù)性的工作？

風(fēng)險

是否有任何關(guān)鍵的項目風(fēng)險，以及你將如何緩解呢？比如：

傷到人或動物

用戶數(shù)據(jù)的安全性和完整性

用戶隱私

公司系統(tǒng)的安全性

硬件或財產(chǎn)損失

法律與合規(guī)問題

機密或敏感數(shù)據(jù)暴露

數(shù)據(jù)丟失或損壞

收入損失

不可恢復(fù)的場景

服務(wù)水平協(xié)議

性能要求

誤導(dǎo)用戶

影響到其他項目

受他項目的影響

影響公司的公眾形象

生產(chǎn)力損失

該項目有沒有技術(shù)漏洞？試想一下：

功能或組件沒有特色，易出故障，或者急需重構(gòu)

開發(fā)平臺和其他依賴庫（SDK？）經(jīng)常出錯

用戶危害到系統(tǒng)的可能性

已知的技術(shù)漏洞

覆蓋

測試入口是什么樣的？它是只有一個對外接口的庫，還是一個多平臺，有客戶端-服務(wù)器且有大量用戶狀態(tài)組合的系統(tǒng)？在測試計劃中重點說明系統(tǒng)設(shè)計和架構(gòu)可能出現(xiàn)的故障。
支持哪些平臺？考慮列出所支持的操作系統(tǒng)，硬件、設(shè)備等，還需要說明各個平臺如何執(zhí)行測試用例，如何輸出測試結(jié)果。
有哪些功能點？考慮把所有功能做一個摘要列表，指出哪些功能是需要測試的。
究竟要不要測試？沒有測試套件會涵蓋所有的可能性。我們需要直面這個事實，并說明部分用例無法執(zhí)行的原因。比如：低優(yōu)先級且低風(fēng)險的用例，低優(yōu)先級且復(fù)雜的用例，其他團隊覆蓋的部分，沒有達到測試標(biāo)準的功能等。
需要在什么用例中覆蓋？單元測試（?。?，集成測試（中）還是系統(tǒng)測試（大）用例中覆蓋？一般盡量在較小的用例測試，盡可能減少大的測試用例。測試計劃需要說明把測試用例放在各個階段執(zhí)行的理由。
手動測試和自動化測試哪個是最好的？如果考慮可執(zhí)行性和成本-收益，自動化通常是最好的。許多項目可以自動實現(xiàn)所有的測試。但是，可能有更好的理由來選擇手動測試。測試計劃需要描述手動測試用例的類型并提供理論基礎(chǔ)。
你是如何覆蓋每個測試類別？試想一下：

輔助（無障礙）功能測試

功能測試

模糊測試

國際化和本地化

性能，負載，壓力和耐久性測試（又名浸泡測試）

隱私測試

安全測試

冒煙測試

穩(wěn)定性測試

可用性測試

你會使用靜態(tài)分析工具和動態(tài)分析工具嗎？靜態(tài)分析工具和動態(tài)分析工具可以發(fā)現(xiàn)很難在review和測試發(fā)現(xiàn)的問題，因此推薦考慮使用它們。
如何對系統(tǒng)組件和依賴庫（SDK）stub, mocke, fake, stage和進行功能測試？我們都有足夠的動力去做這些事情，這些測試在覆蓋率上都有各自的影響。
測試用例是在什么構(gòu)建版本上執(zhí)行？最新構(gòu)建版本測試（kevin備注：日構(gòu)建版本？），還是迭代穩(wěn)定版本，或者預(yù)發(fā)布版本？如果只測試最新版本，那么你怎么做release版本的增量測試（每個release構(gòu)建版本的changelist）和系統(tǒng)配置變更測試，這些無法在日構(gòu)建版本中覆蓋到。（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?）
哪些測試將在您的團隊之外執(zhí)行呢？例如：

開發(fā)自驗（DogFooding）

外部眾包測試

公開的alpha/ beta版本（他們發(fā)布前如何進行測試？）

外部信任的測試（External trusted testers）

數(shù)據(jù)遷移是如何測試？您可能需要專門測試遷移前和遷移后的結(jié)果。
你需要關(guān)注向后兼容？你可能擁有已發(fā)布的客戶端或者有其他系統(tǒng)依賴你的協(xié)議，配置，特性和邏輯。
你需要測試升級服務(wù)器/客戶端/設(shè)備軟件或依賴庫(SDK)/平臺/ APIs這些軟件組件？
你有代碼覆蓋率的目標(biāo)嗎？

工具和基礎(chǔ)設(shè)施

是否需要新的測試框架嗎？如果是這樣，補充說明或在計劃中添加設(shè)計環(huán)節(jié)。
你需要建立一個新的測試實驗室？如果是這樣，補充說明或在計劃中添加設(shè)計環(huán)節(jié)。
如果您的項目需要為其他項目提供服務(wù)，你需要提供測試工具給這些用戶？考慮提供mocks, fakes, and/or reliable staged servers協(xié)助其他用戶進行集成測試。
對于端到端的測試，如何將測試基礎(chǔ)設(shè)施，測試系統(tǒng)，以及其他依賴庫（SDK）進行管理？他們?nèi)绾尾渴?？如何?gòu)建持續(xù)測試環(huán)境和恢復(fù)環(huán)境？如何做數(shù)據(jù)中心間的遷移工作？
你需要一些工具來幫助調(diào)試系統(tǒng)或異常測試嗎？您可以使用現(xiàn)有的工具，或者您可能需要開發(fā)新的。

過程

有測試進度要求？已經(jīng)取得了哪些時間承諾，什么時間該完成什么測試（或提供測試反饋）？是否有些測試是更重要需要提前完成？
如何持續(xù)構(gòu)建和測試？大多數(shù)小測試有持續(xù)集成工具運行，但大的測試可能需要其他方法實現(xiàn)?；蛘?，如果有必要您可以選擇性地運行大型測試。
如何報告和監(jiān)測系統(tǒng)構(gòu)建及測試結(jié)果？

你有一個團隊來監(jiān)控持續(xù)集成？

大測試可能需要由具有專業(yè)知識的人來監(jiān)測。

你需要測試結(jié)果狀態(tài)圖和其他項目健康檢查工具嗎？

誰會收到電子郵件警報又如何處理？

只需要有人將測試檢測結(jié)果簡單地口頭匯報給團隊嗎？

測試在版本發(fā)布中起什么作用？

他們是明確要發(fā)布待測版本，還是依賴持續(xù)集成測試的結(jié)果來確定是否發(fā)布？

如果系統(tǒng)組件和依賴庫（SDK）獨立發(fā)布，需要對他們的每個發(fā)布進行測試嗎？

“阻塞發(fā)布”的bug真的能阻止管理者進行版本發(fā)布嗎？有沒有對阻塞發(fā)布的標(biāo)準達成共識？

如果進行版本預(yù)發(fā)布（內(nèi)測版本、金絲雀版本），這個過程是如何監(jiān)控和測試的？

外部用戶將如何報告bug？可以考慮反饋鏈接或其他類似的工具來收集和匯總。

如何完成bug派發(fā)工作？可以考慮用標(biāo)簽和分類把bug放置到不同的過濾結(jié)果中，需要確保負責(zé)創(chuàng)建bug和創(chuàng)建bug報告模板中的團隊都指導(dǎo)這一點。您正在使用bug跟蹤系統(tǒng)或者你需要設(shè)置一些自動或手動導(dǎo)入任務(wù)？
你有沒有制定一個規(guī)范，規(guī)定在已發(fā)現(xiàn)bug解決之前如何再次提測新版本？
如何測試未提交的修改？如果任何人都可以對任何實驗版本執(zhí)行所有的測試（一件好事），可以考慮提供一個HOWTO。
團隊成員如何創(chuàng)建和/或調(diào)試測試用例？可以考慮提供一個HOWTO。

實用技巧

誰是測試計劃的讀者？有些測試計劃只能由少數(shù)人看，有的則是被許多看。至少，你應(yīng)該考慮所有利益相關(guān)者（項目經(jīng)理，技術(shù)負責(zé)人，特性負責(zé)人）都進行了review。當(dāng)寫測試計劃時，一定要了解讀者的期望，為他們提供足夠的背景了解該計劃，并回答您認為他們可能存在的疑問——即使你的答案是，你也沒有一個答案。也可以考慮為測試計劃添加聯(lián)系人，因此，任何讀者可以得到更多的信息。
讀者如何查看實際的測試用例？手工測試用例可能在一個測試用例管理工具里，在一個單獨的文件中，或者包含在測試計劃中?？紤]提供鏈接到包含自動測試用例的目錄。
你是否需要在需求、功能和測試用例之間建立關(guān)聯(lián)性？
你是否有產(chǎn)品健康或質(zhì)量目標(biāo)，你會如何衡量成功？試想一下：

發(fā)行節(jié)奏

在開發(fā)階段用戶抓bug的數(shù)量

在發(fā)布測試階段bug的數(shù)量

延期解決Bug的數(shù)量

代碼覆蓋率

手動測試成本

創(chuàng)建新測試用例的難度

原文地址：The Inquiry Method for Test Planning by Anthony Vallone
updated: July 2016