在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，要麼它對，要麼不對。同時，老師也不會等到學期結束才將在課程早期交上來的進行判卷，在他們做出來之際就得到了測試。目前我們軟體開發承擔更加大風險，難道我們還可以有任何的不嚴格和不及時嗎？
這些應當進行評價和測試的交付產品應當包括需求規格說明書，設計規格說明書、資料轉換規格和資料轉換**、資料庫設計說明書、培訓資料、硬體/軟體安裝規格、使用者手冊和應用程式**等等。當然這並不是乙個完整的列表。問題的關鍵是，在你的專案生命週期中的每乙個交付產品都必須被測試。
評價和測試的型別必須是魯棒的、堅固的。這包括對功能、效能、可靠性-可用性/實用性-可服務性、易用性、可移植性、可維護性和可擴充套件性等的驗證，但絕不僅限於此。
總之，每個階段的每個交付產品必須通過正式的、訓練有素的技術來對適當的屬性進行評價和測試。
二、在cmm中為什麼要加入這個獨立的kpa
由五個重要方面能說明必須有乙個獨立的軟體評價與測試的kpa，即：
(1)評價和測試在促進向有紀律的軟體工程過程過程的文化轉變中的作用；
(2)評價和測試在專案跟蹤中所起的作用；
(3)整個開發和維護在評價和測試部分的預算；
(4)評價和測試訓練對軟體交付時間和成本方面的影響；
(5)評價和測試對軟體殘餘缺陷的影響。
將軟體工業從一種手工(藝)匠方法向真正的訓練有素的工程層次邁進實在是一種文化的轉折、躍變。cmm的首要的而且也是最重要的目標是，建立一種機制來推進向軟體工程的文化改變。但是乙個文化不可能發生激烈的改變，除非你深刻理解改變的重要性。必須全面理解向新的文化改變所能給我們解決的問題。最後這一點，將使我們引導我們來討論測試在這一加速向訓練有素的文化改變中所起的作用。
在2023年代後期，ibm是第一批開始應用正式軟體工程技術的組織之一。一開始使用的是dijkstra支援的技術。具有諷刺意味的是，並不是由軟體開發人員發起這項努力的，而是軟體測試人員。這一創始性工作是在poughkeepsie實驗室進行的，屬於philip carol領導的面向測試的設計專案。
phil是軟體測試技術工作組(sw test technology group)的乙個系統測試工程師。這個工作組主要負責定義軟體測試技術和工具以用於整個公司。大概在30年以前，他們就開始意識到你不可能通過測試將質量注於**中。你需要像考慮測試過程一樣也得考慮分析、設計和編碼過程。作為測試人員，由於測試需要接觸軟體開發的所有方面，他們對問題有更加徹底深入的理解。
正是這一對問題的深入認識並將這一問題明確有力地向開發人員指出推動了軟體開發文化的迅速改變。隨著改進的開發和測試技術的應用，ibm的os作業系統的缺陷率在下乙個發布降低了1/10。這確實是在短時間內產生的重要的文化變革，特別是這涉及到了分布在不同地域的近千名軟體開發人員。
這種變化的加速除了對問題的重視的直接推動外，另乙個推動因素是與測試有關的一些因素，即在測試過程和開發過程整合中的反饋環。隨著開發過程的不斷改進，評價和測試過程並行地改進以反映新的成功準則。隨著開發不斷使用新技術，他們直接從測試人員那裡得到及時的反饋即他們究竟做的怎麼樣，因為測試人員就是專門基於新的尺度對交付產品進行確認的。
乙個具體的例子是需求撰寫改進技術的應用，需求必須是明確的、確定的、邏輯上是一致的、完備的、正確的。有關結構化分析方法和物件導向的方法的培訓課教系統分析員如何來寫乙個好的需求。如果在他們剛剛寫完第乙個功能描述時就進行模糊性評審，那麼他們寫的下乙個功能就會更加清晰明確。這種緊湊的反饋環—寫乙個功能、評價乙個功能，有效地加速了其學習曲線。這樣的話，過程從缺陷檢測到缺陷預防轉移的相當快速----他們正在寫著清晰、不模糊的規格。
將這些經驗與我們的整個軟體工業做乙個對比，結構化設計技術和物件導向的技術已經在25年前就可以應用了(是的，oo確實已經那麼老了)，然而我們的時間的情況卻遠遠落後於這些方法的最新技術發展水平。問題是除非組織理解了正在解決的問題，否則它不會全面接受或者全面理解乙個解決方案（如：軟體工程方法和技術），而整合的評價和測試正是問題理解的槓桿和關鍵。這裡「整合評價和測試」被定義為將測試整合到軟體過程的每一步中，它也是為掌握乙個技術所需的必要的反饋環的關鍵部分。任何沒有緊密反饋環的過程是具有致命缺陷的過程，因此評價和測量是加速文化改變的關鍵。
乙個專案計畫一般包含任務、關聯、資源、進度、預算和假設等等。每個任務都應當輸出乙個良好定義的交付，且必須對交付產品進行驗證以證明該交付產品是確實是完備的。如果你對任務輸出的完備性進行評價和測試，那麼你不可能準確地跟蹤專案的真實的狀態。
在決定一項實踐應不應當是獨立的kpa時，乙個重要的實效因素是它在軟體開發活動的預算和人員投入中所佔的比重。如果在這方面越顯著，那麼它應當受到的關注應當越多。而軟體測試在整個軟體開發中所佔的比重在一半左右。
整合評價和測試可以支援更多的活動併發從而進一步縮短進度。如果需求沒有得到正式評價，就常會導致設計和編碼活動產生對早期提交的功能範圍和定義的大量修改。正是基於這一原因，使用者手冊和培訓手冊等工作直到對**的測試都差不多了的時候才能開始。到那時，幾乎沒有人會對早期的系統定義有什麼信任。
同樣，沒有很好定義的需求也不能提供足夠的資訊來支援測試指令碼的設計，因此測試用例的設計和構建也只能等到編碼做得差不多的時候才能開始。
根據這兩種情況，可以得出目前開發過程是線性的：先需求、然後是設計、編碼、接著是測試、編寫使用者手冊。如果寫的需求規格能夠達到乙個確定級的詳程度(即：給定乙個輸入集和乙個系統初始狀態，你應當能夠按照規格中的規則準確地確定輸出和新系統的狀態)，那麼測試用例的設計以及使用者手冊的編寫就可以和系統設計並行執行。這樣同時也就縮短了系統交付時間。關鍵是要對規格需求進行正式的評價活動。
從中我們看到在cmm中加入這個獨立的kpa是很有必要的。
三、結束語
通過以上的論述我們看到，評價是對軟體開發過程中所產生的各種系統規格和模型的整合性進行保證的活動，測試則是基於機器的對**進行測試的活動。軟體評價和測試的目的是確認(即：判斷這是我們所要的嗎？)和驗證(即：這是不是正確？)每乙個軟體專案交付產品，並及時發現這些產品中的任何缺陷。
軟體評價和測試包括識別需進行評價和測試的交付產品；確定需要執行的評價和測試型別；定義每個評價和測試的成功準則；設計、構建、執行所需的評價和測試；驗證評價和測試結果；驗證測試集全面覆蓋既定的評價和測試準則；建立和執行回歸庫以用於在交付產品發生修改後進行重新驗證；登記、匯報、跟蹤發現的缺陷。
最開始進行評價的交付產品是軟體需求，隨後，大部分評價和測試是基於被確認的軟體需求。
CMM與軟體生命週期
cmm是作為乙個普適性的模型提出的，它明確指出既不限制也不建議專案使用哪一種生命週期模型，也沒有涉及到特定領域的專門知識或軟體技術。cmm的內容包括了大量的行業實踐，這些行業實踐 於廣泛的軟體組織，而這些軟體組織的共同特點將決定這些行業實踐的特點，從而決定cmm的內容。另外，在cmm提出的那個時代，...
3軟體質量與評價
質量 反映實體滿足明確的和隱含的需求的能力的特性的總和。質量 實體特性的總和，滿足明確的和隱含的需求的能力。測度的運用是建立測量方法的依據，也是解決軟體質量的關鍵。測度是軟體質量中用於測量的一種量化的標度和方法 度量是指測量的結果。印象軟體質量的因素有兩大類 直接測量和間接度量，每種型別測度都必須發...
軟體測試質量和效率評價之我見
寫在前面 近期在研究如何提高軟體測試質量和效率，發現要完成這個課題，先要搞清楚如何評價軟體測試質量和效率？蒐羅了不少資料，木有找到權威的說法，於是結合自己的經驗進行了總結，便得此文，願拋磚與業界朋友 軟體測試質量和效率評價的範疇 原本打算將軟體測試質量和效率分別評價，但基於軟體測試不可窮盡的特點，以...