CMM與軟件評價及測試(3)

　　一個項目計劃一般包含任務、關聯、資源、進度、預算和假設等等。每個任務都應當輸出一個良好定義的交付，且必須對交付產品進行驗證以證明該交付產品是確實是完備的。如果你對任務輸出的完備性進行評價和測試，那么你不可能準確地跟蹤項目的真實的狀態。

　　在決定一項實踐應不應當是獨立的KPA時，一個重要的實效因素是它在軟件開發活動的預算和人員投入中所占的比重。如果在這方面越顯著，那么它應當受到的關注應當越多。而軟件測試在整個軟件開發中所占的比重在一半左右。

　　集成評價和測試可以支持更多的活動并發從而進一步縮短進度。如果需求沒有得到正式評價，就常會導致設計和編碼活動產生對早期提交的功能范圍和定義的大量修改。正是基于這一原因，用戶手冊和培訓手冊等工作直到對代碼的測試都差不多了的時候才能開始。到那時，幾乎沒有人會對早期的系統定義有什么信任。

　　同樣，沒有很好定義的需求也不能提供足夠的信息來支持測試腳本的設計，因此測試用例的設計和構建也只能等到編碼做得差不多的時候才能開始。

　　根據這兩種情況，可以得出目前開發過程是線性的：先需求、然后是設計、編碼、接著是測試、編寫用戶手冊。如果寫的需求規格能夠達到一個確定級的詳程度 (即：給定一個輸入集和一個系統初始狀態，你應當能夠按照規格中的規則準確地確定輸出和新系統的狀態)，那么測試用例的設計以及用戶手冊的編寫就可以和系統設計并行執行。這樣同時也就縮短了系統交付時間。關鍵是要對規格需求進行正式的評價活動。

　　從中我們看到在CMM中加入這個獨立的KPA是很有必要的。

　　三、結束語

　　通過以上的論述我們看到，評價是對軟件開發過程中所產生的各種系統規格和模型的集成性進行保證的活動，測試則是基于機器的對代碼進行測試的活動。軟件評價和測試的目的是確認(即：判斷這是我們所要的嗎?)和驗證(即：這是不是正確?)每一個軟件項目交付產品，并及時發現這些產品中的任何缺陷。

　　軟件評價和測試包括識別需進行評價和測試的交付產品;確定需要執行的評價和測試類型;定義每個評價和測試的成功準則;設計、構建、執行所需的評價和測試;驗證評價和測試結果;驗證測試集全面覆蓋既定的評價和測試準則;創建和執行回歸庫以用于在交付產品發生修改后進行重新驗證;登記、匯報、跟蹤發現的缺陷。

　　最開始進行評價的交付產品是軟件需求，隨后，大部分評價和測試是基于被確認的軟件需求。

原文轉自：http://www.uml.org.cn/Test/test122502.htm