將這些經(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/
