CMM與軟件評價及測試

　　在CMM的發展進程中，曾經提議將軟件評價與測試(Evaluation and Test)作為CMM的一個KPA加入到CMM中，雖然這一提議最終未獲通過，但通過對這一提議的討論，我們可以得到很多與軟件測試相關的一些有益的東西。

　　一、軟件評價與測試在整個軟件生命周期中的作用

　　評價是對軟件開發過程中產生的各種系統規格和模型進行的驗證活動。測試則是一種基于機器的對代碼執行、確認的活動。大部分組織對評價和測試的定義都相對狹義，一般是指對代碼執行物理測試用例的活動。事實上，很多公司甚至直到編碼已經開始時才指定或安排測試人員。更有甚者，他們將這一活動的范圍僅僅限于功能測試，也許有時做一下性能測試。這種觀點在目前的CMM有關評價與測試的描述中被進一步強調，這就是SPE，軟件產品工程KPA。在SPE KPA活動中，活動5、6、7，僅僅用了基于代碼的測試作為例子，只明確地提到了功能測試。其他類型的測試只是用一句非常含糊的話來指代：“保證軟件滿足軟件需求 ”。

　　另一方面，建造摩天大廈的人們，則遠在砌第一塊磚之前就將評價和測試集成到了開發過程之中。通過建模來驗證穩定性、防水性、照明布置以及電源的需求等等，從而實施評價。而目前，組織所使用軟件評價和測試方法就像是設計師一直等到大樓已經建成才進行測試，而此時的測試只是能保證給水和照明可以工作而已。

　　CMM只是進一步將評價和測試的部分思想進行融合，用一個特殊的評價技術來代替，這個技術就是CMM中的一個KPA，同行評審。這也意味著，在提交代碼之前，唯一可干的評價就是同行評審，且已經足夠了。事實上，對于一件事情的評價和測試的步驟包括：(1)定義成功準則;(2)涉及覆蓋這些準則的用例; (3)執行用例;(4)驗證結果，驗證所有的內容都已覆蓋。同行評審只是提供了一個基于紙面的測試機制。它既不能從根本上提供成功準則，也不能提供任何正式的機制以支持用例定義以用于同行評審中。同行評審本質是主觀的，因此，基于誤解使程序員將缺陷引入產品，而到同行評審時，基于同樣的誤解，也使得人們無法發現這些缺陷。

　　評價和測試的一個相對堅固的內涵范圍必須包括項目在開發周期每一個階段的每一個交付產品。它也必須考慮每個交付產品的每一個預期特性。而且必須包括每一個評價/測試步驟。下面我們看兩個例子：評價需求和對一個設計的評價。

　　一個需求文檔必須是完備的、一致的、正確的和清晰的。那么第一步就是基于項目/產品目標(即為什么要做這個項目的說明)對需求進行確認。這能夠保證我們定義了正確的功能集。下一步評價就是遍歷use-case腳本走查各功能規則，如果可能的話，最好用一些原型工具(screen prototype)作為輔助工具。第三步評價是有領域專家進行的對文檔的同行評審。第四步是由非領域專家進行的正式的含糊性評審(他們無法讀懂文檔里的功能知識，這將幫助確保各種規則是明確定義的，而不是隱含定義)。第五步評價是將需求轉換為布爾邏輯圖。這可以鑒別規則之間的順序問題，同時也能發現漏掉的用例(cases)。第五步評價是在CASE工具的輔助下進行的邏輯一致性檢查。第七步評價是由領域專家進行的對測試腳本的評審，這些腳本是從需求導出來的。

　　對設計的評價一樣可以進行一系列補救。一個是對照需求對設計文檔進行走查。另一評價是構建一個模型來驗證設計的完整性(例如構造一個操作系統的資源分配模式來保證不會發生死鎖)。第三種評價是建立模型來驗證性能特征。第四種是將形成的設計與其他公司的現成系統進行對比，以確保所設計的配置能夠處理預期的處理規模和數據規模。

　　上面的評價只有一部分可以用同行評審來完成，沒有一個是基于代碼的。而且上邊的例子中沒有一個評價是窮盡的，必要時我們可以進行的其他評價。關鍵是我們輸出一個交付產品(如需求文檔)，在我們能夠正式稱它是完備的并可被下一開發步驟使用之前，我們必須基于預期的特征對之進行評價。而進行這些評價需要比進行同行評審更加復雜的技術。

　　這就是評價和測試的關鍵所在。一個特征的預定義集合，盡可能被明確定義，用來對一個交付產品來進行確認。例如，當你在學校，進行了數學測驗，老師會拿你的回答與預期答案相對比。老師不會僅僅說他們看上去也是合理的，或者他們更加準確。答案是9.87652，要么它對，要么不對。同時，老師也不會等到學期結束才將在課程早期交上來的進行判卷，在他們做出來之際就得到了測試。目前我們軟件開發承擔更加大風險，難道我們還可以有任何的不嚴格和不及時嗎?

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