軟體測試方案淺析

 在軟體測試過程中，測試方案起到什麼樣作用？ 如何編寫測試方案？等等類似關於軟體測試方案的問題，往往沒有一致的答案。不同的公司往往有自己的測試方案模板，測試工程師的理解也會有所差別。以下是我關於測試方案的理解，希望能夠拋磚引玉。

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

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

測試需求分析：測試需求分析就是把產品需求（比如PRD文檔）和對使用者的理解（使用者體驗）轉化、分解成測試功能點，產品需求是我們測試需求主要輸入，但不是全部，我們還需要仔細分析產品設計說明，可以產出更多可測試的功能點（這些功能點往往沒有包含在產品需求中）。還要加入對效能、安全、介面和迴歸測試範圍分析。測試需求是確定測試進度計劃和資源的主要依據。 

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

測試資源：一般情況下，團隊同時有多重專案，測試PM需要根據項目的優先順序來確定每個項目的測試資源，一般情況下，軟體測試資源主要包括：人力和裝置機器。 

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

風險管理：在測試執行開始之前，對可能的風險進行分析和識別很重要，可以提前進行預防和採取應對措施，所以項目過程中，我們需要定期評估測試進度情況，提前進行風險預警。 

品質：品質是指測試專案需要達到的標準，各個公司和項目都會有相應的標準要求，由於品質標準可以是公司內多數項目共識，所以也可以不必在測試方案中列出。對測試專案來說，比較常見的是以測試案例執行率、通過率和未關閉BUG層級/數量來設定品質標準。 

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