在CMM的發(fā)展進程中，曾經(jīng)提議將軟件評價與測試（Evaluation and Test）作為CMM的一個KPA加入到CMM中，雖然這一提議最終未獲通過，但通過對這一提議的討論，我們可以得到很多與軟件測試相關(guān)的一些有益的東西。
一、軟件評價與測試在整個軟件生命周期中的作用
評價是對軟件開發(fā)過程中產(chǎn)生的各種系統(tǒng)規(guī)格和模型進行的驗證活動。測試則是一種基于機器的對代碼執(zhí)行、確認的活動。大部分組織對評價和測試的定義都相對狹義，一般是指對代碼執(zhí)行物理測試用例的活動。事實上，很多公司甚至直到編碼已經(jīng)開始時才指定或安排測試人員。更有甚者，他們將這一活動的范圍僅僅限于功能測試，也許有時做一下性能測試。這種觀點在目前的CMM有關(guān)評價與測試的描述中被進一步強調(diào)，這就是SPE，軟件產(chǎn)品工程KPA。在SPE KPA活動中，活動5、6、7，僅僅用了基于代碼的測試作為例子，只明確地提到了功能測試。其他類型的測試只是用一句非常含糊的話來指代：“保證軟件滿足軟件需求 ”。
另一方面，建造摩天大廈的人們，則遠在砌第一塊磚之前就將評價和測試集成到了開發(fā)過程之中。通過建模來驗證穩(wěn)定性、防水性、照明布置以及電源的需求等等，從而實施評價。而目前，組織所使用軟件評價和測試方法就像是設(shè)計師一直等到大樓已經(jīng)建成才進行測試，而此時的測試只是能保證給水和照明可以工作而已。
CMM只是進一步將評價和測試的部分思想進行融合，用一個特殊的評價技術(shù)來代替，這個技術(shù)就是CMM中的一個KPA，同行評審。這也意味著，在提交代碼之前，唯一可干的評價就是同行評審，且已經(jīng)足夠了。事實上，對于一件事情的評價和測試的步驟包括：
(1)定義成功準則；
(2)涉及覆蓋這些準則的用例；
(3)執(zhí)行用例；
(4)驗證結(jié)果，驗證所有的內(nèi)容都已覆蓋。同行評審只是提供了一個基于紙面的測試機制。它既不能從根本上提供成功準則，也不能提供任何正式的機制以支持用例定義以用于同行評審中。同行評審本質(zhì)是主觀的，因此，基于誤解使程序員將缺陷引入產(chǎn)品，而到同行評審時，基于同樣的誤解，也使得人們無法發(fā)現(xiàn)這些缺陷。
評價和測試的一個相對堅固的內(nèi)涵范圍必須包括項目在開發(fā)周期每一個階段的每一個交付產(chǎn)品。它也必須考慮每個交付產(chǎn)品的每一個預(yù)期特性。而且必須包括每一個評價/測試步驟。下面我們看兩個例子：評價需求和對一個設(shè)計的評價。
一個需求文檔必須是完備的、一致的、正確的和清晰的。那么第一步就是基于項目/產(chǎn)品目標（即為什么要做這個項目的說明）對需求進行確認。這能夠保證我們定義了正確的功能集。下一步評價就是遍歷use-case腳本走查各功能規(guī)則，如果可能的話，最好用一些原型工具（screen prototype）作為輔助工具。第三步評價是有領(lǐng)域?qū)＜疫M行的對文檔的同行評審。第四步是由非領(lǐng)域?qū)＜疫M行的正式的含糊性評審（他們無法讀懂文檔里的功能知識，這將幫助確保各種規(guī)則是明確定義的，而不是隱含定義）。第五步評價是將需求轉(zhuǎn)換為布爾邏輯圖。這可以鑒別規(guī)則之間的順序問題，同時也能發(fā)現(xiàn)漏掉的用例(cases)。第五步評價是在CASE工具的輔助下進行的邏輯一致性檢查。第七步評價是由領(lǐng)域?qū)＜疫M行的對測試腳本的評審，這些腳本是從需求導(dǎo)出來的。
對設(shè)計的評價一樣可以進行一系列補救。一個是對照需求對設(shè)計文檔進行走查。另一評價是構(gòu)建一個模型來驗證設(shè)計的完整性（例如構(gòu)造一個操作系統(tǒng)的資源分配模式來保證不會發(fā)生死鎖）。第三種評價是建立模型來驗證性能特征。第四種是將形成的設(shè)計與其他公司的現(xiàn)成系統(tǒng)進行對比，以確保所設(shè)計的配置能夠處理預(yù)期的處理規(guī)模和數(shù)據(jù)規(guī)模。
上面的評價只有一部分