傳統的軟件測試方法體系中的核心內容

　　最近接觸的一些軟件測試相關比較前沿的概念，和其他人討論時免不了要說到這些理論或者新概念和傳統的軟件測試理論有什么不同。但是首先我們對什么是傳統的軟件測試理論范圍的理解有差異，經常有個人說“這個不就和那個xxx一樣嗎?”，另外一個人立馬回復“傳統的測試理論還包括這個嗎?”，因此我覺得有必要把什么是傳統的軟件測試理論明確一下。這里的傳統軟件測試體系等同與經典軟件測試體系。

　　軟件測試的工作范圍

　　軟件測試體系一般涉及項目管理，Bug管理，用例管理三個方面。下面我會分開講各個方面工作的內容

　　一般測試部門的人員角色劃分

　　按工作的內容分，常見分成QA，TE，SCM這3種角色， 正式的QA和TE的差別在于，TE負責的是尋找Bug和執行用例的角色，而正式的QA一般在擁有CMMI等級的軟件公司中比較常見，他們一般不具體做尋找軟件Bug的工作，而是負責項目流程的建設和監督，并隨時拿出對該項目的一些度量指標來說明監控項目風險。有的公司也會把QA和TE放在一起就叫QA，干的是TE的活。SCM一般負責版本控制，build出包這活，也不涉及尋找Bug和執行用例，綜上，從正式的定義來說，QA偏向流程，TE尋找Bug，SCM負責出包。 所以一個QA和SCM可能會同時負責多個項目，而TE一般則是比較固定在某個項目中的。

　　項目執行與管理

　　在需求評審階段測試就需要介入，了解整個項目的過程，并積極參與產品需求評審，了解需求方對產品在測試方面的具體需求，比如性能指標，兼容系統范圍，本地化支持

　　代碼提交測試前，測試這邊一般要準備一份測試計劃和經過評審過的測試用例

　　測試策略(TestStrategy)一般寫上用測試的覆蓋范圍：比如功能，界面，安全，可用性，易用性，穩定性，數據庫，安裝，文檔

　　測試計劃(TestPlan)最主要的是劃分測試階段和測試資源安排,測試階段即各里程碑要達到的測試效果和目標，對于互聯網來說最簡單的劃分是測試環境和線上正式環境，測試環境上要測試哪些內容，線上正式環境上要測試哪些內容，當然實際項目的測試階段劃分要比這個復雜的多，比如我們的項目一般都是按4個測試階段在走。測試計劃里面還有一個重點是人員的安排，人員安排隨測試階段而變化，最開始可能需要的TE多一下，進入穩定階段后可逐步減少。

　　測試計劃中還規定了每個階段執行用例的輪數和用例范圍。

　　一般我們認為，測試計劃=測試策略+測試階段+測試資源安排。

　　用例編寫(TestCase Design)

　　測試分析(Test Anlysis)是為尋找Bug和用例編寫服務的，所以用在用例編寫這個環節上來說，測試分析主要針對的目標是測試需求分析，即產品需求明確后，測試這邊要看看這個需求的測試點有哪些，風險在什么地方，怎么才能測到(有些模塊是測不了的)，需不需要額外的工具來輔助測試，或者讓開發開放某些接口以便來達到測試目的。

　　用例設計方法：我們認為TE在編寫測試用例時應該了解產品的業務需求和實現邏輯，并了解經典的測試用例設計方法，比如邊界值，等價類劃分，正交矩陣實驗法等。最低要求應該掌握《軟件測試的藝術》這本書提到的各種方法。

　　用例類型：針對某一個功能在編寫用例時除了考慮用上述各種方法去構造測試用例外，至少還應該考慮UI用例，功能用例，交互用例，負面測試(Negative Testig)，可能涉及到的類型。

　　對UI測試的處理：，一種是寫成用例或者劃分一個測試用例類型，一種是不寫用例，拿UI流程圖一頁一頁檢查。

　　用例分級與追溯(Trace)：用例分級的目的是為了劃分用例的優先級，比如重點功能的用例優先級比較高，負面測試的用例比較低，級別低的用例可能在整個項目中就只執行一遍，而優先級高的用例可能要在不同的階段被重復執行。

　　用例追溯的目的是為了檢查產品需求是不是都被覆蓋到了。分級與追溯的作用可參考QC或TestLink的做法。

　　用例評審：

　　用例設計完成后測試內部或者外部對用例的評審。這個過程一般能發現很多開發和產品原先沒有想到的邏輯分支和處理。

　　Bug管理

　　對Bug的生命周期(Bug Lifecycle)或者Bug趨勢曲線，傳統的和非傳統看法都比較一致，沒什么大的異議。

　　以上體系只是涉及一般的軟件測試體系，沒有涉及CMM/CMMI或者ISO9000族中對質量管理的體現。

　　軟件測試的經典書籍

　　《軟件測試》 作者：Ron Patton

　　《軟件測試的藝術》 作者：梅爾斯

　　《人月神話》 作者：弗雷德里克·布魯克斯

　　《有效軟件測試——提高測試水平的50條建議》作者：Elfriede Dustin

原文轉自：http://agileqa.org/archives/100