測試計劃非常重要，它是測試中的一項最基本的環(huán)節(jié)，我們在寫測試計劃之前一定要做好方方面面的準備工作，以便我們在寫的過程中可以隨時提取。測試計劃的一些資源，比如人員，環(huán)境就需要我們做大量的準備了。所以寫一份詳盡的測試計劃并不是那么容易的。還有就是測試計劃它是測試生命周期中非常關鍵的一個部分，所以要保證軟件的質(zhì)量一定要先做好測試計劃。如果您的經(jīng)驗比較豐富，那么寫一份詳盡的測試計劃對您來說便不在話下了。

測試計劃是定義這些資源并表達測試需求的地方。測試計劃還有一個主要目標是與團隊的其他成員，也許還有其他團隊溝通如何計劃進行測試。沒有測試計劃，關于測試的交流就變得非常動態(tài)，人們可能在任何給定的時間都不知道測試的目標和期望。記住沒有一個測試計劃是完美的，但是你在編寫測試計劃中獲得的經(jīng)驗越多，計劃就越容易。

那么，一份詳盡的測試計劃主要包括以下內(nèi)容：

測試計劃標識符

提供文檔的唯一標識符，根據(jù)公司配置管理，標識號可以是數(shù)字或字母數(shù)字。

比如：系統(tǒng)需求規(guī)范、用例文檔、項目計劃等。

介紹或總結項目的目的和范圍。

比如測試的產(chǎn)品是什么，目標是測試產(chǎn)品的功能。

需要測試的功能

此章節(jié)需要列出項目中需要測試的所有功能。

不需要測試的功能

項目中不需要測試的功能，并且說明排除原因，如無影響/受影響較小/優(yōu)先級較低的功能。

測試策略

包括測試類型、如何測試和測試重點。

比如哪些模塊使用自動化測試，哪些模塊使用手動測試，壓力測試要執(zhí)行多少天，尤其關注內(nèi)存泄漏等。

測試可交付成果

測試的所有可交付成果，如測試用例、測試報告，bug分析等。

項目通過/失敗標準

我們將指定用于確定測試項通過或失敗百分比的標準。

示例：產(chǎn)品所有主要功能都符合需求，測試用例的通過率應大于95%，并且不應有任何嚴重bug。

停測標準

指定何時停止測試。

比如冒煙測試不通過就停止測試。

測試任務

要執(zhí)行的所有任務/步驟。

比如測試環(huán)境應該在測試執(zhí)行階段之前準備好，編寫測試用例，準備測試總結報告等。

資源需求

人力資源，測試環(huán)境所需的硬件、軟件和任何其他工具的列表。

職責

指定了每個測試任務的角色和職責列表。

比如測試計劃應由測試負責人編制。測試的準備和執(zhí)行應由測試人員進行。

人員配置和培訓需求

培訓/招聘需要彌補現(xiàn)有技能和預期技能之間的差距。

進度安排

完成關于何時開始、何時結束以及每項任務應進行多長時間的詳細信息。

比如執(zhí)行測試執(zhí)行10個工作日，總結測試報告1個工作日。

風險評估

詳細說明項目中可能遇到的風險和應對措施。項目中經(jīng)常碰到的有需求變更，人員變動，被重大缺陷block住。

批準

誰應該簽署并批準測試項目。

以上就是一份測試計劃中該有的內(nèi)容，大家可以在腦海里與自己正在做的項目對號入座一把。

唯一的不變就是變化

人們可能傾向于不談計劃的一個原因是，他們知道任何計劃都可能改變。測試計劃也不例外。但是它不應該成為阻止你創(chuàng)建測試計劃的借口。如何讓測試計劃變得彈性和靈活去應付變化呢?答案就是基于簡單原則。文檔中，比如名稱、日期、風險和技術細節(jié)等方面，如果計劃越詳細和具體，則發(fā)生更改時，測試計劃就越脆弱。但是，問題又來了，如果沒有細節(jié)，測試計劃又有什么價值?當涉及到測試目標、范圍和其他更穩(wěn)定的方面，它們相對更能經(jīng)受住變化。但對于日程安排、人員和其他相對容易發(fā)生變化的方面，一個好的做法是以一種可以記錄更改的方式去描述它們，而不需要創(chuàng)建測新版本的測試計劃。

測試計劃是測試中的一項基本且必須的環(huán)節(jié)，測試計劃就像”測試版”的項目計劃。在測試的許多方面，需要一定程度的計劃和準備，以便在需要時獲得所需的資源。一些資源，如人員和環(huán)境，可能需要大量準備。測試計劃是定義這些資源并表達測試需求的地方。測試計劃還有一個主要目標是與團隊的其他成員，也許還有其他團隊溝通如何計劃進行測試。沒有測試計劃，關于測試的交流就變得非常動態(tài)，人們可能在任何給定的時間都不知道測試的目標和期望。

以上我們分享了一份詳盡的測試計劃應該怎么寫，還有就是沒有一個測試計劃是完美的，但是你在編寫測試計劃中獲得的經(jīng)驗越多，那么計劃寫得就越容易。如果您想了解更多相關信息，請您繼續(xù)關注中培偉業(yè)。