度量是改進過程的有效途徑之一。通過對測試過程的度量，可以使測試過程規范化、可視化;對度量數據的分析，可以測量出測試過程的有效性及存在的問題，明確測試過程的改進方向，從而保證軟件的質量。因此，對軟件測試過程的度量研究具有十分重要的意義。
CMMI與軟件測試
CMMI是美國卡耐基梅隆大學的軟件工程研究所針對軟件質量保證的核心—軟件過程改進所提出的，它是一個成功的、廣泛使用的過程改進模型。
眾所周知，軟件測試是軟件過程不可分割的一部分，所以CMMI實際上也為軟件測試過程改進提供了一系列的指導方針和關鍵原則。在CMMI連續表示中，驗證(VER)和確認(VAL)過程域緊密的與軟件測試聯系在一起;而諸如配置管理(CM)、風險分析(RSKM)、量化項目管理(QPM)等過程域也同樣包含了對測試過程改進的有力支持。
CMMI與度量
CMMI提供了度量和分析(MA)過程域，其目的是開發和維持用于支持管理信息需要的度量能力。MA實際包含了度量和分析兩個步驟，度量在前，是為獲得過程或產品的表征數據;分析在后，是對數據進行分析，發現不一致、發現趨勢和發現問題。
CMMI的度量和分析流程主要分為3個部分:計劃、收集和分析。在計劃階段，主要任務是度量目標的確定和目標的細化;在收集階段，主要任務是按數據采集和存儲規程進行數據的收集、數據完整檢查;在分析階段，主要任務是按分析規程進行數據分析、存儲數據和結果，以及報告結果。MA過程域定義嚴格，流程清楚，目標明確，可以用它來指導軟件測試過程的度量活動。
軟件測試過程
按照MA的指導，任何對過程的度量都是建立在清晰的過程定義上的，因此，必須對軟件測試過程有一個準確的定義。傳統的軟件測試過程包括:測試計劃、測試設計、測試開發和測試執行等階段，每個階段都有一系列的任務。但是傳統的軟件測試過程定義無論是從測試范圍還是測試工作方式上都存在著明顯的不足，不利于進行過程度量，而CMMI則對傳統的軟件測試過程進行了擴充。因此，我們提出了一個基于CMMI的軟件測試過程模型(software test process model，STPM)，如圖1所示。
STPM有如下幾點改進:
(1)軟件測試不再只是對程序代碼的測試工作，而是包含了所有在軟件開發過程階段產出物的測試工作，這擴展了測試工作的范圍，更有利于發現軟件開發中的缺陷;
(2)測試過程與整個軟件開發過程是并行的，擴展了測試過程的工作方式;
(3)清晰的定義了過程的輸入輸出流，為整個過程的度量奠定了基礎;
(4)將測試的結果納入到了軟件開發的缺陷管理機制中，擴展了測試的作用。
度量目標
通過對STPM的分析 ，可以確定3類度量目標:①對測試產品的度量，這主要是對應STPM的輸入，包括需求規格說明、詳細設計說明、系統設計說明以及程序代碼等的度量;②對測試過程產品的度量，這主要是對應STPM的輸出，包括測試用例、測試報告等的度量;③對測試過程本身的度量，主要是對應STPM的執行狀態，包括時間狀態、環境狀態等的度量。
度量元的選取和細化
CMMI為過程改進提供了足夠多的實踐指導，但是，它只闡述了該做什么，而沒有闡述該如何做，這一點也在MA中體現了出來。所以，在CMMI提供的要求和原則下，具體的度量和分析工作需要我們自己來定義。在此，我們引入GQM方法來保證度量元選取和細化的有效性。GQM(goal-question-metric)方法源于軟件行業，是一種系統地對軟件及其開發過程實施定量化的度量方法。GQM引入了目標驅動的度量概念，在軟件開發過程中已經取得了很好的效果。GQM的基本思想是:先確定一組目標:再針對各個目標，提出可能會遇到的問題，來定義這個目標;最后，針對每一個問題再給出一組測量方法，并用這一組測量方法測量出來的數據(度量元)就是對這個問題的回答。
GQM方法在實施過程中最重要的就是要保證G、Q、M之間問題轉化的完整性和匹配性。而對CMMI的一個單獨的過程域而言，可以這樣來描述:首先，對該過程域定義一個目的;然后，為了達到這個目的，給出了一系列的關鍵目標(包含特定目標和共性目標);最后，針對每一個目標，細分關鍵實踐來實現，而每個關鍵實踐又可再分為具體的子實踐。即是說，CMMI的過程域從定義到實踐是一個嚴格意義上的完整性和匹配性轉化。如果從每個過程域的角度來進行軟件測試過程的度量研究，那么就可以建立起CMMI模型與GQM方法的映射關系，如圖2所示。
上面的映射關系分為目的層、問題層和度量層，這樣，CMMI也是目標驅動的。由于GQM方法是一套已經被證明成功的度量元選取方法，所以在生成了CMMI到GQM的映射后，由CMMI導出度量元是可行的。將CMMI與GQM的映射關系定義為C—G模型，并將應用到C—G模型中的CMMI相關軟件測試過程域定義為STPA(software test process area)，C-G模型和STPA為度量元選取和細化提供了理論依據。
CMMI不是專門為改進軟件測試過程而出現的，所以將STPA引入進入C—G模型中時，需要有一定的剪裁和適用的選取原則，才能保證度量元的有效性。本文從過程域、實踐、文檔、公共特性和相似結果5個方面，根據STPM，提出度量元的選取和細化遵循原則。
原則1 過程域剪裁。每個STPA都有幾個相關過程域，如果幾個STPA同時都包含一個確定的過程域，那么該過程域應該保留并合并;如果STPA涉及的相關過程域與軟件測試相關性不強，那么該過程域應該完全刪除不予考慮。這樣既可以保證STPA引申出來的軟件測試實踐的完整，又可以抓住STPA的核心。
原則2 實踐剪裁。CMMI面向的是整個軟件過程改進，所以在分析STPA時:①某些關注整個軟件過程的實踐，關注重點都要置換成軟件測試過程，并要以特定的測試輸入輸出作為基礎;②某些與軟件測試無關的實踐，或者是涉及到過程域的定義、維護以及審查等實踐，都可以被剪裁掉;③對某些零散的實踐，如果表示的都是同一個目標，那么應該將其合并;④對子實踐，如果直接度量元仍然無法確定，應允許再進行拆分。
原則3 文檔剪裁。每個STPA都包含了大量繁瑣的文檔，不利于管理和維護。因此，應該只保留與測試輸入輸出有關的計劃、規程、標準和報告等文檔，這也是將整個度量和分析過程開發成自動化系統時所期望得到的文檔數據。在保留的文檔中，還應該注意相關文檔的合并消除，降低文檔之間的冗余關系。
原則4 公共特性剪裁。每個STPA都有許多執行能力公共特性，這些內容在企業進行全面過程改進時或許有用，但是在進行軟件測試過程度量時，有些顯得無關和沒有必要。對此，可以采取以下3種方法:①納入到相關STPA中，例如人員、工具等資源的管理，可以在配置管理中統一度量;②直接作為該過程域的度量目標，例如過程狀態管理、維護，可以作為對測試過程本身的度量;③完全放棄，例如人員培訓、角色分配等。
原則5 相似結果的合并。通過對不同的STPA分析，可能會對軟件測試過程的某個屬性重復度量，這時就必須涉及到相似度量元的合并。主要原則有3點:①如果度量元完全重復，那么應該只保留一個;②如果度量元屬于同一度量目標，那么兩者都應該保留并歸為一類;③如果這個度量元是直接度量和間接度量的關系，那么應該將間接度量置于直接度量之下，并與該直接度量的其它間接度量進行合并。
應用案例
現以STPA中與軟件測試聯系最為緊密的確認(VAL)過程域為例，分析軟件測試過程的度量。VAL的目的是證實產品或產品構件置于預期的環境時滿足預期的用途。在STPM中，產品或產品構件就是被測試的產品，預期的環境是搭建的測試平臺，而用途則是產品的需求。因此，VAL在C-G模型的目的層是:證實被測試的產品置于搭建好的測試平臺下是否滿足產品預期的需求。
按照原則1和原則2，集中分析VAL的兩個特定目標:確認準備和確認產品。確認準備在STPM 中對應的是測試計劃和測試設計部分，輸入主要有測試產品和產品需求等，輸出主要有需求確認計劃和產品確認計劃等。確認產品在STPM中對應的是測試執行和結果分析部分，輸入主要來源與確認準備目標的輸出，而輸出主要有確認結果、確認報告和對查表等。因此，VAL在C-G模型的問題層是:01是否準備好了確認產品和確認環境？02確認的過程和結果是否有效？在明確了VAL的目標以及輸入輸出后，可以根據VAL的具體實踐以及實踐說明展開其在C-G模型中的問題層，結合原則2、原則3和原則4，將上述的VAL目標映射到C-G模型的度量層:M1產品規模度量;M2需求規模度量;M3測試用例規模度量;M4測試用例的有效性度量;M5測試結果的度量;M6測試工具使用度量;M7測試過程進度度量;M8測試充分性度量;M9測試平臺穩定性度量。
其中M1和M2屬于對測試產品的度量，M3、M4、M5和M6屬于對對測試過程產品的度量，M7、M8和M9屬于對測試過程本身的度量。進一步分析可以得到VAL對于STPM 的直接度量元，如表1所示。
表1所呈現的都是直接度量元，事實上，在VAL的分析過程中，一些直接度量元的導出是以間接度量元為基礎的，這些信息應該與度量元的數據收集方法、數據單位等一起寫入度量元的屬性定義中。
通過對軟件測試過程的度量和分析能夠提高軟件測試的有效性，保證軟件的質量。本文在清晰的軟件測試過程定義下，以CMMI這個成功的過程改進模型為基礎，對度量目標和度量元的有效選取進行了研究。下一步的工作重點，是定義數據采集和存儲規程進行度量數據的收集，以及定義分析規程來分析數據，提供度量結果和改進措施。最終，還需要開發一個自動化系統來支持整個度量和分析過程。而所有研究的基礎，則是對軟件測試過程度量元的選取，這也是本文研究的意義所在。
圖1 軟件測試過程模型
圖2 CMMI與GQM的映射關系模型
文章來源于領測軟件測試網 http://www.kjueaiud.com/
