在CMM的發(fā)展進(jìn)程中，曾經(jīng)提議將軟件評價(jià)與測試（Evaluation and Test）作為CMM的一個(gè)KPA加入到CMM中，雖然這一提議最終未獲通過(guò)，但通過(guò)對這一提議的討論，我們可以得到很多與軟件測試相關(guān)的一些有益的東西。
一、軟件評價(jià)與測試在整個(gè)軟件生命周期中的作用
評價(jià)是對軟件開(kāi)發(fā)過(guò)程中產(chǎn)生的各種系統規格和模型進(jìn)行的驗證活動(dòng)。測試則是一種基于機器的對代碼執行、確認的活動(dòng)。大部分組織對評價(jià)和測試的定義都相對狹義，一般是指對代碼執行物理測試用例的活動(dòng)。事實(shí)上，很多公司甚至直到編碼已經(jīng)開(kāi)始時(shí)才指定或安排測試人員。更有甚者，他們將這一活動(dòng)的范圍僅僅限于功能測試，也許有時(shí)做一下性能測試。這種觀(guān)點(diǎn)在目前的CMM有關(guān)評價(jià)與測試的描述中被進(jìn)一步強調，這就是SPE，軟件產(chǎn)品工程KPA。在SPE KPA活動(dòng)中，活動(dòng)5、6、7，僅僅用了基于代碼的測試作為例子，只明確地提到了功能測試。其他類(lèi)型的測試只是用一句非常含糊的話(huà)來(lái)指代：“保證軟件滿(mǎn)足軟件需求 ”。
另一方面，建造摩天大廈的人們，則遠在砌第一塊磚之前就將評價(jià)和測試集成到了開(kāi)發(fā)過(guò)程之中。通過(guò)建模來(lái)驗證穩定性、防水性、照明布置以及電源的需求等等，從而實(shí)施評價(jià)。而目前，組織所使用軟件評價(jià)和測試方法就像是設計師一直等到大樓已經(jīng)建成才進(jìn)行測試，而此時(shí)的測試只是能保證給水和照明可以工作而已。
CMM只是進(jìn)一步將評價(jià)和測試的部分思想進(jìn)行融合，用一個(gè)特殊的評價(jià)技術(shù)來(lái)代替，這個(gè)技術(shù)就是CMM中的一個(gè)KPA，同行評審。這也意味著(zhù)，在提交代碼之前，唯一可干的評價(jià)就是同行評審，且已經(jīng)足夠了。事實(shí)上，對于一件事情的評價(jià)和測試的步驟包括：(1)定義成功準則；(2)涉及覆蓋這些準則的用例；(3)執行用例；(4)驗證結果，驗證所有的內容都已覆蓋。同行評審只是提供了一個(gè)基于紙面的測試機制。它既不能從根本上提供成功準則，也不能提供任何正式的機制以支持用例定義以用于同行評審中。同行評審本質(zhì)是主觀(guān)的，因此，基于誤解使程序員將缺陷引入產(chǎn)品，而到同行評審時(shí)，基于同樣的誤解，也使得人們無(wú)法發(fā)現這些缺陷。
評價(jià)和測試的一個(gè)相對堅固的內涵范圍必須包括項目在開(kāi)發(fā)周期每一個(gè)階段的每一個(gè)交付產(chǎn)品。它也必須考慮每個(gè)交付產(chǎn)品的每一個(gè)預期特性。而且必須包括每一個(gè)評價(jià)/測試步驟。下面我們看兩個(gè)例子：評價(jià)需求和對一個(gè)設計的評價(jià)。
一個(gè)需求文檔必須是完備的、一致的、正確的和清晰的。那么第一步就是基于項目/產(chǎn)品目標（即為什么要做這個(gè)項目的說(shuō)明）對需求進(jìn)行確認。這能夠保證我們定義了正確的功能集。下一步評價(jià)就是遍歷use-case腳本走查各功能規則，如果可能的話(huà)，最好用一些原型工具（screen prototype）作為輔助工具。第三步評價(jià)是有領(lǐng)域專(zhuān)家進(jìn)行的對文檔的同行評審。第四步是由非領(lǐng)域專(zhuān)家進(jìn)行的正式的含糊性評審（他們無(wú)法讀懂文檔里的功能知識，這將幫助確保各種規則是明確定義的，而不是隱含定義）。第五步評價(jià)是將需求轉換為布爾邏輯圖。這可以鑒別規則之間的順序問(wèn)題，同時(shí)也能發(fā)現漏掉的用例(cases)。第五步評價(jià)是在CASE工具的輔助下進(jìn)行的邏輯一致性檢查。第七步評價(jià)是由領(lǐng)域專(zhuān)家進(jìn)行的對測試腳本的評審，這些腳本是從需求導出來(lái)的。
對設計的評價(jià)一樣可以進(jìn)行一系列補救。一個(gè)是對照需求對設計文檔進(jìn)行走查。另一評價(jià)是構建一個(gè)模型來(lái)驗證設計的完整性（例如構造一個(gè)操作系統的資源分配模式來(lái)保證不會(huì )發(fā)生死鎖）。第三種評價(jià)是建立模型來(lái)驗證性能特征。第四種是將形成的設計與其他公司的現成系統進(jìn)行對比，以確保所設計的配置能夠處理預期的處理規模和數據規模。
上面的評價(jià)只有一部分可以用同行評審來(lái)完成，沒(méi)有一個(gè)是基于代碼的。而且上邊的例子中沒(méi)有一個(gè)評價(jià)是窮盡的，必要時(shí)我們可以進(jìn)行的其他評價(jià)。關(guān)鍵是我們輸出一個(gè)交付產(chǎn)品（如需求文檔），在我們能夠正式稱(chēng)它是完備的并可被下一開(kāi)發(fā)步驟使用之前，我們必須基于預期的特征對之進(jìn)行評價(jià)。而進(jìn)行這些評價(jià)需要比進(jìn)行同行評審更加復雜的技術(shù)。
這就是評價(jià)和測試的關(guān)鍵所在。一個(gè)特征的預定義集合，盡可能被明確定義，用來(lái)對一個(gè)交付產(chǎn)品來(lái)進(jìn)行確認。例如，當你在學(xué)校，進(jìn)行了數學(xué)測驗，老師會(huì )拿你的回答與預期答案相對比。老師不會(huì )僅僅說(shuō)他們看上去也是合理的，或者他們更加準確。答案是9.87652，要么它對，要么不對。同時(shí)，老師也不會(huì )等到學(xué)期結束才將在課程早期交上來(lái)的進(jìn)行判卷，在他們做出來(lái)之際就得到了測試。目前我們軟件開(kāi)發(fā)承擔更加大風(fēng)險，難道我們還可以有任何的不嚴格和不及時(shí)嗎？
這些應當進(jìn)行評價(jià)和測試的交付產(chǎn)品應當包括需求規格說(shuō)明書(shū)，設計規格說(shuō)明書(shū)、數據轉換規格和數據轉換代碼、數據庫設計說(shuō)明書(shū)、培訓資料、硬件/軟件安裝規格、用戶(hù)手冊和應用程序代碼等等。當然這并不是一個(gè)完整的列表。問(wèn)題的關(guān)鍵是，在你的項目生命周期中的每一個(gè)交付產(chǎn)品都必須被測試。
對于一個(gè)給定交付產(chǎn)品的評價(jià)和測試可能會(huì )延續項目生命周期的多個(gè)階段。越來(lái)越多的軟件組織開(kāi)始從瀑布式模型向迭代式模型轉變。例如，設計規格可能會(huì )經(jīng)過(guò)三個(gè)迭代才能產(chǎn)生。第一個(gè)迭代定義體系結構—它是人工的還是自動(dòng)的，是集中的還是分散的，是在線(xiàn)的還是批命令式的，是直接文件存儲還是通過(guò)關(guān)系性數據庫等等。第二個(gè)迭代則可能繼續推動(dòng)設計，來(lái)鑒別所有的模塊和模塊間的數據交換機制。第三個(gè)迭代則定義模塊內部的偽代碼。每個(gè)迭代都應當基于適當的特性來(lái)進(jìn)行評價(jià)與測試。
評價(jià)和測試的類(lèi)型必須是魯棒的、堅固的。這包括對功能、性能、可靠性-可用性/實(shí)用性-可服務(wù)性、易用性、可移植性、可維護性和可擴展性等的驗證，但絕不僅限于此。
總之，每個(gè)階段的每個(gè)交付產(chǎn)品必須通過(guò)正式的、訓練有素的技術(shù)來(lái)對適當的屬性進(jìn)行評價(jià)和測試。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/