測試與軟體生命週期

雖然又是一篇比較「空」的文章，但是比較少見的提到了各種圖的應用，所以還是轉貼一下，希望能對一些朋友有用。

uml與

rup開發模式的知識

測試是什麼，就是在開發快完成時對程式進行找錯嗎？其實不然，就好像捕魚一樣，講就季節，陽光，水流，甚至魚網洞的大小的使用都直接影響到捕魚的效果。測試也是一樣，不僅僅只是找錯而已，還需要有計畫的進行，同時大家都知道發現軟體缺陷越早，修改的成本就越低。那麼怎樣才能準確而又及時的發現軟體缺陷，這首先要從軟體的生命週期講起。

軟體的生命週期將軟體開發分為若干個階段，主要有需求，分析，設計，編碼，測試幾個主要的階段，同時在

rup的開發過程中除了這幾個主要階段外，還對這些階段進行迭代式的開發。但是我有幾點疑問，測試難道就必需在開發後期進行嗎。在早期的開發過程中也許是可以的，但是現在的軟體開發逐漸由小作坊式的開發進入大規模的團隊開發，早期介入測試有助於提早發現問題，同時大幅度的降低專案風險有很大的好處。不過如何在早期介入測試則是乙個很值的討論的問題。下面我們從軟體生命週期詳細的敘述一下如何介入軟體測試。

首先我們從軟體生命週期的各個階段進行分析。在需求，分析階段，需求人員會對使用者的需求進行詳細的分析，形成產品說明書，如果更好的可以細化到用例圖，活**。可能大家對

uml不是很熟悉，我這裡作一下簡單的說明。用例是用來描述乙個參與者（可以理解為乙個外部系統使用者，可以是人或外部系統）使用系統完成某乙個過程的事件發生的順序，是系統的使用過程。用例圖則是系統的一組用例，用例的參與者（角色）以及用例與參與者之間的關係圖。下面就是乙個簡單購物系統的用例圖。

如圖

1 從圖中我們可以發現三個系統的功能，

1購買商品，

2安全驗證，

3退還商品。這時我們測試人員可以知道這個系統有三個功能塊組成，這時可以在測試計畫書中結合產品說明書對這三個功能塊的測試目標進行詳細的描述，從而保證系統沒有重要功能塊的覆蓋面，後面有經驗的案例設計人員會通過測試計畫書設計出合理的案例對功能進行測試。這時我們測試人員還可以起到另乙個作用，對需求的審核，比如這裡對使用者是否要登陸，大家有不同的看法，這時可以讓需求人員進一步確認使用者是否需要使用登陸功能塊。不同系統的產品說明書與用例圖總是不同的，不過在我們測試人的眼裡，它可是用來確定產品是否可以滿足使用者需求的主要標準，乙個用例就可以對應乙個或是多個功能點，通過它可以明確的寫出測試的功能目標書，我稱為測試計畫書。這裡主要描述產品需要達到的功能，效能要求，穩定性要求。也就是說我們在早期的需求分析階段就可以介入測試，確定後期測試的目標，如果要求更高點可以進一步的進行需求測試，論證需求是否可以滿足使用者的要求

,從而減少需求風險。

進入設計階段，設計組成員會提供詳細的設計文件，其中主要有時序圖，協作圖

(狀態圖

)，類圖等等。時序圖向我們展示了用例事件發生的過程中與系統直接發生互動的處部參與者，系統（可以看作乙個黑盒）。這時可以提取出有哪些系統是要進行測試的，可以明確我們黑盒測試的目標，而不是在最後再找有哪些系統是要進行測試的。協作圖可以詳細的描述出系統狀態的變化。為乙個大型軟體產品建立狀態圖是艱苦的事情，既然有大家的勞動成果為什麼我們測試不利用呢？前面進行的測試需求是捕捉的都是靜態的需求，但這裡我們可以清晰的看到軟體狀態的變化，這時我們就可以針對各種狀態分析要測試的狀態轉換和主要的程式流程來設計測試案例，同時狀態的變化有時也是對系統介面的交接，這時設計的案例則主要針對介面優先的原則，保證了介面在掛接過程中得到有效的測試。下面就是乙個狀態圖：

圖

2 從圖中我們可以看到系統如何從進入

post

進行操作的過程，通過訊息使系統發生了功能性變化，比如從購買（

sale

）到付費（

payment

）這個狀態的變化是由

create

的訊息進行的，不過我們不需要關心這個，這個是設計人員與開發人員關注的，測試人員關注的是系統有那些狀態的變化，我們的測試案例是否可以測度這些狀態的變化。於是我們的測試案例就有補充，剛剛我們從用例圖中發現的都是靜態的功能需求比如上面的購買商品功能，而現在則可以看到實現購買功能系統進行狀態的變化的過程

,這時測試案例就要對這種狀態的變化進行補充，從而讓案例可以覆蓋動態的變化，從而保證系統重要功能流程的測試

,同時你們看到訊息的變化就是介面的變化，從而也保證了介面得到充分的測試。而類圖的作用就更顯而易見了，下面就是乙個類圖。

圖

3 從類圖中你可以清晰的了解到這個系統有哪些實體類

,比如這裡有

post

實體類與

sale

實體類，還有類內部的變數，函式，並且可以看到變數和函式的級別

(public,private等等)

。這樣你就可以有效的針對這些設計相應的測試案例。特別在國內無法達到像微軟這樣一對一的白盒測試時，針對函式的測試有助於較早期的發現問題，將軟體缺陷消滅在開發早期。

到達編碼階段時，怎樣在早期就可以介入測試，這要從每日編譯說起，在可能的情況下對已開發的功能進行每日編譯，形成可測試的版本，從而讓測試人員進行測試，這時前期的工作並沒以白做，這時我們已經有了測試需求說明書，測試計畫書與重要的案例，可以對它進行分配並測試，這時至少重要的功能在早期就得到了保障。同時隨著系統的不斷完善，可以讓各個功能模組的測試人員增加測試案例，保證測試的完備性。每日編譯還有個好處，就是測出的軟體缺陷可以在當天就可以處理，從而保證了把缺陷消滅在早期。這時測試與開發已經完美的結合起來，做到測試與開發的同步，並且不相互衝突。

開發後就是測試，說到現在這時你才感到輕鬆，由於測試與開發是同步進行的，所以這時我想你主要進行的就是對開發過程中發現的問題的回歸測試。甚至你可以喝喝咖啡了j,

因為在編碼階段軟體缺陷就發現差不多了，這時主要的精力放在整合測試，效能測試，相容性測試等一些測試上來，而且這些測試的標準在需求分析時就有了，比如效能測試，它要求的資料在需求時我們就關注過，有了這些有效的目標我們還做不好嗎。

測試如果與軟體生命週期結合，可以有效的保證測試的目標和覆蓋率，，同時可以充分利用需求人員，設計人員的力量來指導我們的測試，不過也帶來一些問題，就是實施的難度，必需要求整個開發團隊使用

rup或是類似於

rup的適合自己的開發過程，同時高階測試人員對此要有一定的了解才可能實施，不過它的好處還是顯而易見的，我們為什麼不嘗試著做一下呢

測試與軟體生命週期

測試與軟體生命週期

測試與軟體生命週期

軟體測試生命週期

相關推薦