CMM與軟件評價及測試

2019-11-17 04:44:19

字體：大中小

來源：轉載

供稿：網友

　　在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的首要的而且也是最重要的目標是，建立一種機制來推進向軟件工程的文化改變。但是一個文化不可能發生激烈的改變，除非你深刻理解改變的重要性。必須全面理解向新的文化改變所能給我們解決的問題。最后這一點，將使我們引導我們來討論測試在這一加速向練習有素的文化改變中所起的作用。

　　在1960年代后期，IBM是第一批開始應用正式軟件工程技術的組織之一。一開始使用的是Dijkstra支持的技術。具有諷刺意味的是，并不是由軟件開發人員發起這項努力的，而是軟件測試人員。這一創始性工作是在Poughkeepsie實驗室進行的，屬于Philip Carol領導的面向測試的設計項目。

　　Phil是軟件測試技術工作組(SW Test Technology Group)的一個系統測試工程師。這個工作組主要負責定義軟件測試技術和工具以用于整個公司。大概在30年以前，他們就開始意識到你不可能通過測試將質量注于代碼中。你需要像考慮測試過程一樣也得考慮分析、設計和編碼過程。作為測試人員，由于測試需要接觸軟件開發的所有方面，他們對問題有更加徹底深入的理解。

　　正是這一對問題的深入熟悉并將這一問題明確有力地向開發人員指出推動了軟件開發文化的迅速改變。隨著改進的開發和測試技術的應用，IBM的OS操作系統的缺陷率在下一個發布降低了1/10。這確實是在短時間內產生的重要的文化變革，非凡是這涉及到了分布在不同地域的近千名軟件開發人員。

　　這種變化的加速除了對問題的重視的直接推動外，另一個推動因素是與測試有關的一些因素，即在測試過程和開發過程集成中的反饋環。隨著開發過程的不斷改進，評價和測試過程并行地改進以反映新的成功準則。隨著開發不斷使用新技術，他們直接從測試人員那里得到及時的反饋即他們究竟做的怎么樣，因為測試人員就是專門基于新的尺度對交付產品進行確認的。

　　一個具體的例子是需求撰寫改進技術的應用，需求必須是明確的、確定的、邏輯上是一致的、完備的、正確的。有關結構化分析方法和面向對象的方法的培訓課教系統分析員如何來寫一個好的需求。假如在他們剛剛寫完第一個功能描述時就進行模糊性評審，那么他們寫的下一個功能就會更加清楚明確。這種緊湊的反饋環—寫一個功能、評價一個功能，有效地加速了其學習曲線。這樣的話，過程從缺陷檢測到缺陷預防轉移的相當快速----他們正在寫著清楚、不模糊的規格。

　　將這些經驗與我們的整個軟件工業做一個對比，結構化設計技術和面向對象的技術已經在25年前就可以應用了(是的，OO確實已經那么老了)，然而我們的時間的情況卻遠遠落后于這些方法的最新技術發展水平。問題是除非組織理解了正在解決的問題，否則它不會全面接受或者全面理解一個解決方案（如：軟件工程方法和技術），而集成的評價和測試正是問題理解的杠桿和要害。這里“集成評價和測試”被定義為將測試集成到軟件過程的每一步中，它也是為把握一個技術所需的必要的反饋環的要害部分。任何沒有緊密反饋環的過程是具有致命缺陷的過程，因此評價和測量是加速文化改變的要害。

　　一個項目計劃一般包含任務、關聯、資源、進度、預算和假設等等。每個任務都應當輸出一個良好定義的交付，且必須對交付產品進行驗證以證實該交付產品是確實是完備的。假如你對任務輸出的完備性進行評價和測試，那么你不可能準確地跟蹤項目的真實的狀態。

　　在決定一項實踐應不應當是獨立的KPA時，一個重要的實效因素是它在軟件開發活動的預算和人員投入中所占的比重。假如在這方面越顯著，那么它應當受到的關注應當越多。而軟件測試在整個軟件開發中所占的比重在一半左右。

　　集成評價和測試可以支持更多的活動并發從而進一步縮短進度。假如需求沒有得到正式評價，就常會導致設計和編碼活動產生對早期提交的功能范圍和定義的大量修改。正是基于這一原因，用戶手冊和培訓手冊等工作直到對代碼的測試都差不多了的時候才能開始。到那時，幾乎沒有人會對早期的系統定義有什么信任。

　　同樣，沒有很好定義的需求也不能提供足夠的信息來支持測試腳本的設計，因此測試用例的設計和構建也只能等到編碼做得差不多的時候才能開始。

　　根據這兩種情況，可以得出目前開發過程是線性的：先需求、然后是設計、編碼、接著是測試、編寫用戶手冊。假如寫的需求規格能夠達到一個確定級的詳程度(即：給定一個輸入集和一個系統初始狀態，你應當能夠按照規格中的規則準確地確定輸出和新系統的狀態)，那么測試用例的設計以及用戶手冊的編寫就可以和系統設計并行執行。這樣同時也就縮短了系統交付時間。要害是要對規格需求進行正式的評價活動。

　　從中我們看到在CMM中加入這個獨立的KPA是很有必要的。

　　三、結束語

　　通過以上的論述我們看到，評價是對軟件開發過程中所產生的各種系統規格和模型的集成性進行保證的活動，測試則是基于機器的對代碼進行測試的活動。軟件評價和測試的目的是確認(即：判定這是我們所要的嗎？)和驗證(即：這是不是正確？)每一個軟件項目交付產品，并及時發現這些產品中的任何缺陷。

　　軟件評價和測試包括識別需進行評價和測試的交付產品；確定需要執行的評價和測試類型；定義每個評價和測試的成功準則；設計、構建、執行所需的評價和測試；驗證評價和測試結果；驗證測試集全面覆蓋既定的評價和測試準則；創建和執行回歸庫以用于在交付產品發生修改后進行重新驗證；登記、匯報、跟蹤發現的缺陷。

　　最開始進行評價的交付產品是軟件需求，隨后，大部分評價和測試是基于被確認的軟件需求。

上一篇：構建可“復用”的軟件測試環境

下一篇：UML組件圖詳解