測試與軟件生命週期
提示：看這篇文章之前需要有一些UML與RUP開發模式的知識
測試介紹
測試是什麼，就是在開發快完成時對程序進行找錯嗎？其實不然，就好像捕魚一樣，講就季節，陽光，水流，甚至魚網洞的大小的使用都直接影響到捕魚的效果。測試也是一樣，不僅僅只是找錯而已，還需要有計劃的進行，同時大家都知道發現軟件缺陷越早，修改的成本就越低。那麼怎樣才能準確而又及時的發現軟件缺陷，這首先要從軟件的生命週期講起。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
軟件的生命週期
軟件的生命週期將軟件開發分爲若干個階段，主要有需求，分析，設計，編碼，測試幾個主要的階段，同時在RUP的開發過程中除了這幾個主要階段外，還對這些階段進行迭代式的開發。但是我有幾點疑問，測試難道就必需在開發後期進行嗎。在早期的開發過程中也許是可以的，但是現在的軟件開發逐漸由小作坊式的開發進入大規模的團隊開發，早期介入測試有助於提早發現問題，同時大幅度的降低項目風險有很大的好處。不過如何在早期介入測試則是一個很值的討論的問題。下面我們從軟件生命週期詳細的敘述一下如何介入軟件測試。
需求，分析階段測試的結合
首先我們從軟件生命週期的各個階段進行分析。在需求，分析階段，需求人員會對用戶的需求進行詳細的分析，形成產品說明書，如果更好的可以細化到用例圖，活動圖。可能大家對UML不是很熟悉，我這裏作一下簡單的說明。用例是用來描述一個參與者（可以理解爲一個外部系統用戶，可以是人或外部系統）使用系統完成某一個過程的事件發生的順序，是系統的使用過程。用例圖則是系統的一組用例，用例的參與者（角色）以及用例與參與者之間的關係圖。下面就是一個簡單購物系統的用例圖。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
<?xml:namespace prefix = w ns = "urn:schemas-microsoft-com:office:word" />
如圖1
從圖中我們可以發現三個系統的功能，1購買商品，2安全驗證，3退還商品。這時我們測試人員可以知道這個系統有三個功能塊組成，這時可以在測試計劃書中結合產品說明書對這三個功能塊的測試目標進行詳細的描述，從而保證系統沒有重要功能塊的覆蓋面，後面有經驗的案例設計人員會通過測試計劃書設計出合理的案例對功能進行測試。這時我們測試人員還可以起到另一個作用，對需求的審覈，比如這裏對用戶是否要登陸，大家有不同的看法，這時可以讓需求人員進一步確認用戶是否需要使用登陸功能塊。不同系統的產品說明書與用例圖總是不同的，不過在我們測試人的眼裏，它可是用來確定產品是否可以滿足用戶需求的主要標準，一個用例就可以對應一個或是多個功能點，通過它可以明確的寫出測試的功能目標書，我稱爲測試計劃書。這裏主要描述產品需要達到的功能，性能要求，穩定性要求。也就是說我們在早期的需求分析階段就可以介入測試，確定後期測試的目標，如果要求更高點可以進一步的進行需求測試，論證需求是否可以滿足用戶的要求,從而減少需求風險。
設計階段與測試的結合
進入設計階段，設計組成員會提供詳細的設計文檔，其中主要有時序圖，協作圖(狀態圖)，類圖等等。時序圖向我們展示了用例事件發生的過程中與系統直接發生交互的處部參與者，系統（可以看作一個黑盒）。這時可以提取出有哪些系統是要進行測試的，可以明確我們黑盒測試的目標，而不是在最後再找有哪些系統是要進行測試的。協作圖可以詳細的描述出系統狀態的變化。爲一個大型軟件產品建立狀態圖是艱苦的事情，既然有大家的勞動成果爲什麼我們測試不利用呢？前面進行的測試需求是捕捉的都是靜態的需求，但這裏我們可以清晰的看到軟件狀態的變化，這時我們就可以針對各種狀態分析要測試的狀態轉換和主要的程序流程來設計測試案例，同時狀態的變化有時也是對系統接口的交接，這時設計的案例則主要針對接口優先的原則，保證了接口在掛接過程中得到有效的測試。下面就是一個狀態圖：
圖2
從圖中我們可以看到系統如何從進入post進行操作的過程，通過消息使系統發生了功能性變化，比如從購買（sale）到付費（payment）這個狀態的變化是由create的消息進行的，不過我們不需要關心這個，這個是設計人員與開發人員關注的，測試人員關注的是系統有那些狀態的變化，我們的測試案例是否可以測度這些狀態的變化。於是我們的測試案例就有補充，剛剛我們從用例圖中發現的都是靜態的功能需求比如上面的購買商品功能，而現在則可以看到實現購買功能系統進行狀態的變化的過程,這時測試案例就要對這種狀態的變化進行補充，從而讓案例可以覆蓋動態的變化，從而保證系統重要功能流程的測試,同時你們看到消息的變化就是接口的變化，從而也保證了接口得到充分的測試。而類圖的作用就更顯而易見了，下面就是一個類圖。
圖3
從類圖中你可以清晰的瞭解到這個系統有哪些實體類,比如這裏有Post實體類與Sale實體類，還有類內部的變量，函數，並且可以看到變量和函數的級別(public,private等等)。這樣你就可以有效的針對這些設計相應的測試案例。特別在國內無法達到像微軟這樣一對一的白盒測試時，針對函數的測試有助於較早期的發現問題，將軟件缺陷消滅在開發早期。
編碼階段實施測試
到達編碼階段時，怎樣在早期就可以介入測試，這要從每日編譯說起，在可能的情況下對已開發的功能進行每日編譯，形成可測試的版本，從而讓測試人員進行測試，這時前期的工作並沒以白做，這時我們已經有了測試需求說明書，測試計劃書與重要的案例，可以對它進行分配並測試，這時至少重要的功能在早期就得到了保障。同時隨着系統的不斷完善，可以讓各個功能模塊的測試人員增加測試案例，保證測試的完備性。每日編譯還有個好處，就是測出的軟件缺陷可以在當天就可以處理，從而保證了把缺陷消滅在早期。這時測試與開發已經完美的結合起來，做到測試與開發的同步，並且不相互衝突。
後期測試
開發後就是測試，說到現在這時你才感到輕鬆，由於測試與開發是同步進行的，所以這時我想你主要進行的就是對開發過程中發現的問題的迴歸測試。甚至你可以喝喝咖啡了J,因爲在編碼階段軟件缺陷就發現差不多了，這時主要的精力放在集成測試，性能測試，兼容性測試等一些測試上來，而且這些測試的標準在需求分析時就有了，比如性能測試，它要求的數據在需求時我們就關注過，有了這些有效的目標我們還做不好嗎。
總結
測試如果與軟件生命週期結合，可以有效的保證測試的目標和覆蓋率，，同時可以充分利用需求人員，設計人員的力量來指導我們的測試，不過也帶來一些問題，就是實施的難度，必需要求整個開發團隊使用RUP或是類似於RUP的適合自己的開發過程，同時高級測試人員對此要有一定的瞭解纔可能實施，不過它的好處還是顯而易見的，我們爲什麼不嘗試着做一下呢J,最後祝大家好運，多多發現問題，早早發現問題，寫出高質量的軟件。