軟件測試不僅僅只是找錯而已，還需要有計劃的進行，同時大家都知道發(fā)現軟件缺陷越早，修改的成本就越低。那么怎樣才能準確而又及時的發(fā)現軟件缺陷，這首先要從軟件生命周期講起。
軟件的生命周期
軟件的生命周期將軟件開發(fā)分為若干個階段，主要有需求，分析，設計，編碼，測試幾個主要的階段，同時在RUP的開發(fā)過程中除了這幾個主要階段外，還對這些階段進行迭代式的開發(fā)。但是我有幾點疑問，測試難道就必需在開發(fā)后期進行嗎。在早期的開發(fā)過程中也許是可以的，但是現在的軟件開發(fā)逐漸由小作坊式的開發(fā)進入大規(guī)模的團隊開發(fā)，早期介入測試有助于提早發(fā)現問題，同時大幅度的降低項目風險有很大的好處。不過如何在早期介入測試則是一個很值的討論的問題。下面我們從軟件生命周期詳細的敘述一下如何介入軟件測試。
需求，分析階段測試的結合
首先我們從軟件生命周期的各個階段進行分析。在需求，分析階段，需求人員會對用戶的需求進行詳細的分析，形成產品說明書，如果更好的可以細化到用例圖，活動圖。也就是說我們在早期的需求分析階段就可以介入測試，確定后期測試的目標，如果要求更高點可以進一步的進行需求測試，論證需求是否可以滿足用戶的要求，從而減少需求風險。
設計階段與測試的結合
進入設計階段，設計組成員會提供詳細的設計文檔，其中主要有時序圖，協作圖(狀態(tài)圖)，類圖等等。時序圖向我們展示了用例事件發(fā)生的過程中與系統直接發(fā)生交互的處部參與者，系統（可以看作一個黑盒）。這時可以提取出有哪些系統是要進行測試的，可以明確我們黑盒測試的目標，而不是在最后再找有哪些系統是要進行測試的。協作圖可以詳細的描述出系統狀態(tài)的變化。為一個大型軟件產品建立狀態(tài)圖是艱苦的事情，既然有大家的勞動成果為什么我們測試不利用呢？前面進行的測試需求是捕捉的都是靜態(tài)的需求，但這里我們可以清晰的看到軟件狀態(tài)的變化，這時我們就可以針對各種狀態(tài)分析要測試的狀態(tài)轉換和主要的程序流程來設計測試案例，同時狀態(tài)的變化有時也是對系統接口的交接，這時設計的案例則主要針對接口優(yōu)先的原則，保證了接口在掛接過程中得到有效的測試。
編碼階段實施測試
到達編碼階段時，怎樣在早期就可以介入測試，這要從每日編譯說起，在可能的情況下對已開發(fā)的功能進行每日編譯，形成可測試的版本，從而讓測試人員進行測試，這時前期的工作并沒以白做，這時我們已經有了測試需求說明書，測試計劃書與重要的案例，可以對它進行分配并測試，這時至少重要的功能在早期就得到了保障。同時隨著系統的不斷完善，可以讓各個功能模塊的測試人員增加測試案例，保證測試的完備性。每日編譯還有個好處，就是測出的軟件缺陷可以在當天就可以處理，從而保證了把缺陷消滅在早期。這時測試與開發(fā)已經完美的結合起來，做到測試與開發(fā)的同步，并且不相互沖突。
后期測試
開發(fā)后就是測試，說到現在這時你才感到輕松，由于測試與開發(fā)是同步進行的，所以這時我想你主要進行的就是對開發(fā)過程中發(fā)現的問題的回歸測試。甚至你可以喝喝咖啡了J,因為在編碼階段軟件缺陷就發(fā)現差不多了，這時主要的精力放在集成測試，性能測試，兼容性測試等一些測試上來，而且這些測試的標準在需求分析時就有了，比如性能測試，它要求的數據在需求時我們就關注過，有了這些有效的目標我們還做不好嗎。
測試如果與軟件生命周期結合，可以有效的保證測試的目標和覆蓋率，同時可以充分利用需求人員，設計人員的力量來指導我們的測試，不過也帶來一些問題，就是實施的難度，同時高級測試人員對此要有一定的了解才可能實施，不過它的好處還是顯而易見的，我們?yōu)槭裁床粐L試著做一下呢，最后祝大家好運，多多發(fā)現問題，早早發(fā)現問題，寫出高質量的軟件。
推薦閱讀：
APP軟件開發(fā)生命周期可以分為幾個階段？
軟件生命周期管理工具ALM案例庫的作用有哪些？
軟件開發(fā)生命周期6個階段
軟件生命周期階段有哪些？軟件生命周期工具ALM功能有哪些？
為什么要做軟件生命周期管理？四大理由
sales@spasvo.com
