測試方案

1.編寫測試方案的目的是啥？

也許有人會說：根據產品功能需求（好比PRD）文檔，參考產品設計文檔，測試工程師就能夠理解需求、設計測試用例了，不須要測試方案文檔，即便寫了測試方案，也主要是把產品需求和設計文檔內容copy一下而已。有以上這樣的想法，是由於沒有真正理解測試方案的做用。其實軟件測試方案的做用很是相似於產品設計說明（文檔），開發工程師根據產品功能需求和設計說明來編碼實現功能，而測試工程師須要基於產品功能需求和測試方案來設計和執行測試用例，同時也要參考產品設計說明文檔，因此測試方案目的是：在方向上明確要測什麼、怎麼測，以及達到什麼樣質量標準。

2.如何產出有效的測試方案？

若是隻是把產品需求和部分設計說明內容copy一下，給出測試進度計劃，這樣的測試方案對用例設計和執行意義不大。我想做爲方案，至少要包括幾個關鍵因素：範圍，時間，資源和質量，而不一樣行業產品，測試方案應該相應地進行對這幾個關鍵因素進行分解和調整。對於軟件測試方案，我想主要應該包括：測試需求分析，測試策略，測試資源，測試計劃，項目風險和質量，若是咱們可以明確以上這些因素，這樣的測試方案就必定可以有效地指導咱們測試設計和執行。

2.1測試需求分析：

測試需求分析就是把產品需求（好比PRD文檔）和對用戶的理解（用戶體驗）轉化、分解成測試功能點，產品需求是咱們測試需求主要輸入，但不是所有，咱們還須要仔細分析產品設計說明，能夠產出更多可測試的功能點（這些功能點每每沒有包含在產品需求中）。還要加入對性能、安全、接口和迴歸測試範圍分析。測試需求是肯定測試進度計劃和資源的主要依據。

2.2測試策略：

測試需求肯定後，咱們就要思考如何驗證測試需求中的功能點，採用什麼測試方法：手工、自動化測試和是否須要新方法或工具，好比新功能採用手工測試，部分迴歸用例使用自動化腳本，用新方法來準備測試數據，採用合適的工具驗證複雜的測試結果。肯定測試優先級，確認哪些業務功能是最重要，那個是新代碼模塊，哪些舊模塊改動較大，與之相關的功能點要重點測試，測試不可能１００％覆蓋，可是對於重要、高危的功能必需要全面驗證，保證資源投入到當前最高優先級的任務。

2.3測試資源：

通常狀況下，團隊同時有多個項目，測試PM須要根據項目的優先級來肯定每一個項目的測試資源，通常狀況下，軟件測試資源主要包括：人力和設備機器。

2.4測試計劃：

根據測試需求和策略，結合項目優先級和測試資源狀況，評估測試進度計劃，通常狀況下，測試資源越充分，測試進度越樂觀，但並不是絕對，有時候一些軟件ＢＵＧ會阻塞測試進度，這也是項目風險的一部分。

2.5風險管理：

在測試執行開始以前，對可能的風險進行分析和識別很重要，能夠提早進行預防和採起應對措施，因此項目過程當中，咱們須要按期評估測試進度狀況，提早進行風險預警。

2.6質量：

質量是指測試項目須要達到的標準，各個公司和項目都會有相應的標準要求，因爲質量標準能夠是公司內多數項目共識，因此也能夠沒必要在測試方案中列出。對測試項目來講，比較常見的是以測試用例執行率、經過率和未關閉BUG級別/數量來設定質量標準。

測試方案初稿完成後，必需要請項目相關測試、開發和需求方同事評審，澄清對需求和設計的理解，討論測試方法，每每在測試方案評審中，咱們可以對產品需求進行完善，給產品詳細設計提供更多輸入，使開發同事可以提早完善代碼邏輯，並且測試工程師也可以進一步理解需求和設計，從而有助於設計完善測試用例設計，保證測試覆蓋率。