軟件評估與測試KPA方案（上）

　　作者簡介：本文作者熟悉junit單元測試工具及struts技術

　　介紹

　　KPA：Key Process Area。本文共有三部分：第一部分界定評估和測試內涵的范圍。第二部分則解釋為什么要開發這個獨立的KPA。第三部分給出該KPA提案，包括概念、目標，執行承諾、執行能力、執行活動、度量和分析以及實施驗證。最后將考慮如何與其他KPA集成，這包括確定該KPA的級別，以及對現有KPA的重新調整。

　　注意：關于“驗證”和“確認”在ISO9000中有嚴格的定義。

　　驗證：通過檢查和提供客觀證據，表明規定要求已經滿足的認可?！膀炞C”強調的是“規定規格要求”

　　確認：通過檢查和提供客觀證據，表明一些針對某一特定預期用途的要求已經滿足的認可?！按_認”強調的是“預期用途的要求”。

　　驗證的目的是證實設計階段輸出是否確保設計階段輸入要求;

　　確認的目的是通過產品確認設計是否滿足使用要求。

　　驗證的對象是設計輸出文件，計算書或樣品等;

　　確認的對象是最終產品(樣品)。

　　驗證的參與人員通常是設計部門;

　　確認的參與人員必須包括使用者或能代表使用要求的人員。

　　驗證的時機是設計適當階段，一般是設計階段輸出形成結果時;

　　確認的時機是成功的設計驗證后，一般針對最終產品，也可分階段確認。

　　第一部分：

　　測試與評價的定義(Definition of Evaluation and Testing)

　　評價是對軟件開發過程中產生的各種系統規格和模型進行的驗證活動。測試則是一種基于機器的、對代碼執行測試、確認測試的活動(Testing is the machine based activity of executing and validating tests against the code)。大部分組織對評價和測試的定義都相對狹義，一般是指對代碼執行物理測試用例的活動(the activity of executing physical test cases)。事實上，很多公司甚至直到編碼已經開始時才指定/安排測試人員。更有甚者，他們將這一活動的范圍僅僅限于功能測試，也許有時做一下性能測試。

　　在目前的CMM有關evaluation and test的描述中強調了這個觀點，那就是軟件的評價和測試要成為SPE KPA的一部分。在SPE KPA活動中，活動5、6、7，僅僅用了基于代碼的測試作為例子，且只明確地提到了功能測試。其他類型的測試只是用一句非常含糊的話來指代： “…..保證軟件滿足軟件需求 ”。

　　另一方面，建造摩天大廈的人們，則遠在砌第一塊磚之前將評價和測試集成到了開發過程之中。通過建模來驗證穩定性、防水性、照明布置以及電源的需求等等從而實施評價。而目前，組織所使用軟件評價和測試方法就像是設計師一直等到大樓已經建成才進行測試，而此時的測試只是能確認給水和照明是否可以工作而已。

　　CMM只是進一步將評價和測試的部分思想進行融合，采用一個特殊的評價技術來，這個技術就是CMM中的一個KPA：同行評審。這種做法意味著，在提交代碼之前，唯一可干的評價就是同行評審，且已經足夠了。事實上，對于一件事情的評價和測試的步驟包括：(1)定義完成/成功的標準;(2)涉及覆蓋這些準則的用例并構造這些用例;(3)執行用例;(4)驗證結果，包括驗證所有的內容都已覆蓋。同行評審只是提供了一個基于文檔的測試機制。它既不能從根本上提供成功準則，也不能提供任何正式的手段來支持用例定義以用于同行評審中。同行評審本質上是主觀的，因此，由于誤解使程序員將缺陷引入產品，而到同行評審時，可能基于同樣的誤解，也使得人們無法發現這些缺陷。

　　評價和測試必須貫徹在項目開發周期每一階段的每一個交付產品的始終(A robust scope for evaluation and test must emcompass project delivable at each phase in the developement life cycle) 。它也必須考慮每個交付產品的每一個預期特性。而且必須包括每一個評價/測試步驟。下面我們看兩個例子：評價需求和對一個設計的評價。

　　一個需求文檔必須是完備的、一致的、正確的和清晰的。那么第一步就是基于項目/產品目標(即為什么要做這個項目的說明)對需求進行確認。這能夠保證我們定義了正確的功能集。下一步評價就是遍歷use-case場景走查各功能規則，如果可能的話，最好用screen prototype(可視原型、屏幕原型?)來作為輔助工具。第三步評價是有領域專家進行的對文檔的同行評審。第四步是由非領域專家進行的正式的模糊性評審(他們無法讀懂文檔里的功能知識，這將幫助確保各種規則是明確定義的，而不是隱含定義)。第五步評價是將需求轉換為布爾邏輯圖。這可以鑒別規則之間的順序問題，同時也能發現漏掉的用例(cases)。第六步評價是在CASE工具的輔助下進行的邏輯一致性檢查。第七步評價是由領域專家進行的對測試腳本的評審，這些腳本是從需求導出來的。這種“?ite-size”(原英文不清楚)般的對規則的評審經常能夠發現在需求評審中漏掉的功能缺陷。

　　對設計的評價一樣可以進行一系列補救。第一種評價是走查來自于需求的測試(One is walking tests derived from requirements through the design document)。另一評價是構建一個模型來驗證設計的完整性(例如構造一個操作系統的資源分配模型來保證不會發生死鎖)。第三種評價是建立模型來驗證性能特征。第四種是將形成的設計與其他公司的現成系統進行對比，以確保在設計時進行的配置能夠應付預期的處理規模和數據規模。

　　上面的評價只有一部分可以用同行評審來完成，沒有一個是基于代碼的。而且上邊的例子中沒有一個評價是窮盡的，必要時我們可以進行的其他評價。核心關鍵是我們生產一個交付產品(如需求文檔)，在我們能夠正式稱它是完備并可被下一開發步驟使用之前，我們必須基于預期/期望的特征對之進行評價。而進行這些評價需要比進行同行評審更加復雜的技術。

　　這就是評價和測試的核心關鍵。一個特征的預定義集合，盡可能被明確定義，并能夠根據一個可交付產品對其進行驗證。例如，當你在學校，進行了數學測驗，老師會拿你的回答與預期答案相對比。老師不會說你的答案看上去是合理的，或者他們比較準確。答案是9.87652，要么它對，要么不對。同時，老師也不會等到學期結束才對在課程早期交上來試卷的進行判卷，而在他們做出來之際就進行了測試。目前我們軟件開發承擔更加生死攸關的風險，而我們卻是如此的不嚴格和不及時!

　　這些應進行評價和測試的交付產品應包括需求規格，設計規格、數據轉換規格和數據轉換代碼、培訓規格和培訓資料、硬件/軟件安裝規格、設備/工具安裝規格、問題管理支持系統規格、產品發布支持系統規格、用戶手冊和應用程序代碼等等。當然這并不是一個完整的列表。問題是你的項目生命周期中的每一個交付產品都必須被測試。

　　對于一個給定交付產品的評價和測試可能會延續項目生命周期的多個階段。越來越多的軟件組織開始從瀑布式模型向迭代式模型轉變。例如，設計規格可能會經過三個迭代才能產生。第一個迭代定義體系結構—它是人工的還是自動的，是集中的還是分散的，是在線的還是批處理式的，是直接文件存儲還是通過關系性數據庫等等。第二個迭代則可能繼續推動設計，來鑒別所有的模塊和模塊間的數據交換機制。第三個迭代則定義模塊內部的偽代碼。每個迭代都應當基于適當的特性來進行評價。

　　評價和測試的類型必須是魯棒的、堅固的。這包括對功能、性能、可靠性-可用性/實用性-可服務性、易用性、可移植性、可維護性和可擴展型的驗證，但絕不僅限于此。

　　總之，每個階段的每個交付產品必須通過正式的、訓練有素的技術來對適當的屬性進行評價和測試。

原文轉自：http://www.kjueaiud.com