軟件測試中CMM與軟件評價(jià)及測試
在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à)和測試。
二、在CMM中為什么要加入這個(gè)獨立的KPA
由五個(gè)重要方面能說(shuō)明必須有一個(gè)獨立的軟件評價(jià)與測試的KPA，即：
（1）評價(jià)和測試在促進(jìn)向有紀律的軟件工程過(guò)程過(guò)程的文化轉變中的作用；
（2）評價(jià)和測試在項目跟蹤中所起的作用；
（3）整個(gè)開(kāi)發(fā)和維護在評價(jià)和測試部分的預算；
（4）評價(jià)和測試訓練對軟件交付時(shí)間和成本方面的影響；
（5）評價(jià)和測試對軟件殘余缺陷的影響。
將軟件工業(yè)從一種手工（藝）匠方法向真正的訓練有素的工程層次邁進(jìn)實(shí)在是一種文化的轉折、躍變。CMM的首要的而且也是最重要的目標是，建立一種機制來(lái)推進(jìn)向軟件工程的文化改變。但是一個(gè)文化不可能發(fā)生激烈的改變，除非你深刻理解改變的重要性。必須全面理解向新的文化改變所能給我們解決的問(wèn)題。最后這一點(diǎn)，將使我們引導我們來(lái)討論測試在這一加速向訓練有素的文化改變中所起的作用。
在1960年代后期，IBM是第一批開(kāi)始應用正式軟件工程技術(shù)的組織之一。一開(kāi)始使用的是Dijkstra支持的技術(shù)。具有諷刺意味的是，并不是由軟件開(kāi)發(fā)人員發(fā)起這項努力的，而是軟件測試人員。這一創(chuàng )始性工作是在Poughkeepsie實(shí)驗室進(jìn)行的，屬于Philip Carol領(lǐng)導的面向測試的設計項目。
Phil是軟件測試技術(shù)工作組（SW Test Technology Group）的一個(gè)系統測試工程師。這個(gè)工作組主要負責定義軟件測試技術(shù)和工具以用于整個(gè)公司。大概在30年以前，他們就開(kāi)始意識到你不可能通過(guò)測試將質(zhì)量注于代碼中。你需要像考慮測試過(guò)程一樣也得考慮分析、設計和編碼過(guò)程。作為測試人員，由于測試需要接觸軟件開(kāi)發(fā)的所有方面，他們對問(wèn)題有更加徹底深入的理解。
正是這一對問(wèn)題的深入認識并將這一問(wèn)題明確有力地向開(kāi)發(fā)人員指出推動(dòng)了軟件開(kāi)發(fā)文化的迅速改變。隨著(zhù)改進(jìn)的開(kāi)發(fā)和測試技術(shù)的應用，IBM的OS操作系統的缺陷率在下一個(gè)發(fā)布降低了1/10.這確實(shí)是在短時(shí)間內產(chǎn)生的重要的文化變革，特別是這涉及到了分布在不同地域的近千名軟件開(kāi)發(fā)人員。
這種變化的加速除了對問(wèn)題的重視的直接推動(dòng)外，另一個(gè)推動(dòng)因素是與測試有關(guān)的一些因素，即在測試過(guò)程和開(kāi)發(fā)過(guò)程集成中的反饋環(huán)。隨著(zhù)開(kāi)發(fā)過(guò)程的不斷改進(jìn)，評價(jià)和測試過(guò)程并行地改進(jìn)以反映新的成功準則。隨著(zhù)開(kāi)發(fā)不斷使用新技術(shù)，他們直接從測試人員那里得到及時(shí)的反饋即他們究竟做的怎么樣，因為測試人員就是專(zhuān)門(mén)基于新的尺度對交付產(chǎn)品進(jìn)行確認的。
一個(gè)具體的例子是需求撰寫(xiě)改進(jìn)技術(shù)的應用，需求必須是明確的、確定的、邏輯上是一致的、完備的、正確的。有關(guān)結構化分析方法和面向對象的方法的培訓課教系統分析員如何來(lái)寫(xiě)一個(gè)好的需求。如果在他們剛剛寫(xiě)完第一個(gè)功能描述時(shí)就進(jìn)行模糊性評審，那么他們寫(xiě)的下一個(gè)功能就會(huì )更加清晰明確。這種緊湊的反饋環(huán)—寫(xiě)一個(gè)功能、評價(jià)一個(gè)功能，有效地加速了其學(xué)習曲線(xiàn)。這樣的話(huà)，過(guò)程從缺陷檢測到缺陷預防轉移的相當快速——他們正在寫(xiě)著(zhù)清晰、不模糊的規格。
將這些經(jīng)驗與我們的整個(gè)軟件工業(yè)做一個(gè)對比，結構化設計技術(shù)和面向對象的技術(shù)已經(jīng)在25年前就可以應用了（是的，OO確實(shí)已經(jīng)那么老了），然而我們的時(shí)間的情況卻遠遠落后于這些方法的最新技術(shù)發(fā)展水平。問(wèn)題是除非組織理解了正在解決的問(wèn)題，否則它不會(huì )全面接受或者全面理解一個(gè)解決方案（如：軟件工程方法和技術(shù)），而集成的評價(jià)和測試正是問(wèn)題理解的杠桿和關(guān)鍵。這里“集成評價(jià)和測試”被定義為將測試集成到軟件過(guò)程的每一步中，它也是為掌握一個(gè)技術(shù)所需的必要的反饋環(huán)的關(guān)鍵部分。任何沒(méi)有緊密反饋環(huán)的過(guò)程是具有致命缺陷的過(guò)程，因此評價(jià)和測量是加速文化改變的關(guān)鍵。
一個(gè)項目計劃一般包含任務(wù)、關(guān)聯(lián)、資源、進(jìn)度、預算和假設等等。每個(gè)任務(wù)都應當輸出一個(gè)良好定義的交付，且必須對交付產(chǎn)品進(jìn)行驗證以證明該交付產(chǎn)品是確實(shí)是完備的。如果你對任務(wù)輸出的完備性進(jìn)行評價(jià)和測試，那么你不可能準確地跟蹤項目的真實(shí)的狀態(tài)。
在決定一項實(shí)踐應不應當是獨立的KPA時(shí)，一個(gè)重要的實(shí)效因素是它在軟件開(kāi)發(fā)活動(dòng)的預算和人員投入中所占的比重。如果在這方面越顯著(zhù)，那么它應當受到的關(guān)注應當越多。而軟件測試在整個(gè)軟件開(kāi)發(fā)中所占的比重在一半左右。
集成評價(jià)和測試可以支持更多的活動(dòng)并發(fā)從而進(jìn)一步縮短進(jìn)度。如果需求沒(méi)有得到正式評價(jià)，就常會(huì )導致設計和編碼活動(dòng)產(chǎn)生對早期提交的功能范圍和定義的大量修改。正是基于這一原因，用戶(hù)手冊和培訓手冊等工作直到對代碼的測試都差不多了的時(shí)候才能開(kāi)始。到那時(shí)，幾乎沒(méi)有人會(huì )對早期的系統定義有什么信任。
同樣，沒(méi)有很好定義的需求也不能提供足夠的信息來(lái)支持測試腳本的設計，因此測試用例的設計和構建也只能等到編碼做得差不多的時(shí)候才能開(kāi)始。
根據這兩種情況，可以得出目前開(kāi)發(fā)過(guò)程是線(xiàn)性的：先需求、然后是設計、編碼、接著(zhù)是測試、編寫(xiě)用戶(hù)手冊。如果寫(xiě)的需求規格能夠達到一個(gè)確定級的詳程度（即：給定一個(gè)輸入集和一個(gè)系統初始狀態(tài)，你應當能夠按照規格中的規則準確地確定輸出和新系統的狀態(tài)），那么測試用例的設計以及用戶(hù)手冊的編寫(xiě)就可以和系統設計并行執行。這樣同時(shí)也就縮短了系統交付時(shí)間。關(guān)鍵是要對規格需求進(jìn)行正式的評價(jià)活動(dòng)。
從中我們看到在CMM中加入這個(gè)獨立的KPA是很有必要的。
三、結束語(yǔ)
通過(guò)以上的論述我們看到，評價(jià)是對軟件開(kāi)發(fā)過(guò)程中所產(chǎn)生的各種系統規格和模型的集成性進(jìn)行保證的活動(dòng)，測試則是基于機器的對代碼進(jìn)行測試的活動(dòng)。軟件評價(jià)和測試的目的是確認（即：判斷這是我們所要的嗎？）和驗證（即：這是不是正確？）每一個(gè)軟件項目交付產(chǎn)品，并及時(shí)發(fā)現這些產(chǎn)品中的任何缺陷。
軟件評價(jià)和測試包括識別需進(jìn)行評價(jià)和測試的交付產(chǎn)品；確定需要執行的評價(jià)和測試類(lèi)型；定義每個(gè)評價(jià)和測試的成功準則；設計、構建、執行所需的評價(jià)和測試；驗證評價(jià)和測試結果；驗證測試集全面覆蓋既定的評價(jià)和測試準則；創(chuàng )建和執行回歸庫以用于在交付產(chǎn)品發(fā)生修改后進(jìn)行重新驗證；登記、匯報、跟蹤發(fā)現的缺陷。
最開(kāi)始進(jìn)行評價(jià)的交付產(chǎn)品是軟件需求，隨后，大部分評價(jià)和測試是基于被確認的軟件需求。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
