徐東，祁薇，張曉雯

（海軍大連艦艇學院基礎部，大連 116018）

0 引言

軟件產(chǎn)品已經(jīng)在各個領域得到廣泛應用，軟件產(chǎn)品質(zhì)量亦變得越來越重要。軟件產(chǎn)品中存在的不足與缺陷會造成非常嚴重的后果，如2011年的溫州動車追尾事故所導致的212人傷亡事件等。軟件產(chǎn)品質(zhì)量對每個軟件開發(fā)團隊提出了更高的要求，軟件產(chǎn)品質(zhì)量在軟件開發(fā)過程中的重要性也是不言而喻的。在軟件開發(fā)領域，CMM已經(jīng)越來越受到重視，高質(zhì)量的編碼是提高CMM軟件產(chǎn)品質(zhì)量的重要保證，除對編碼人員的業(yè)務水平、團隊的整體能力有要求外，更需要一套科學的行之有效的編碼檢查方法與過程控制策略，盡早地發(fā)現(xiàn)軟件產(chǎn)品的缺陷，從而降低軟件開發(fā)與測試成本。

1 CMM模型概況

CMM模型，英文全稱為Software Capability Maturity Model，是軟件開發(fā)單位在進行軟件產(chǎn)品開發(fā)時，對其軟件產(chǎn)品開發(fā)過程的各個階段的進行性描述，包括對過程和階段性產(chǎn)品等的定義、實施辦法、度量標準、控制手段和改善機制等，其核心思想是將軟件產(chǎn)品的開發(fā)過程看作為一個逐步發(fā)展的過程，并依此對軟件產(chǎn)品開發(fā)過程和軟件產(chǎn)品維護等方面進行強調(diào)過程特性的質(zhì)量監(jiān)控。CMM可以較為科學地對軟件產(chǎn)品開發(fā)單位的軟件產(chǎn)品研制及開發(fā)能力進行評價，并幫助其實施軟件開發(fā)質(zhì)量自檢，進一步完善和改進其軟件產(chǎn)品開發(fā)過程控制方法，提高軟件開發(fā)的質(zhì)量和效率。CMM共分5個級別，隨著CMM級別的提高，軟件可靠性將有數(shù)量級的改進[1]。

目前很多軟件開發(fā)組織都已經(jīng)實施了CMM，甚至CMMI，隨著CMM軟件產(chǎn)品復雜程度和規(guī)模的增加，軟件測試作為一種保證基于CMM模型進行軟件開發(fā)的軟件質(zhì)量的手段，目前尤其受人們的重視。相對于敏捷方法，傳統(tǒng)的如瀑布模型等軟件開發(fā)過程方法，越來越無法滿足當前高質(zhì)量高效率軟件產(chǎn)品開發(fā)的要求，測試人員不能在設定的控制點之前測試，這就導致此前無法找到編碼設計缺陷；而等到了該控制點，再根據(jù)該點的原測試要求進行測試，編碼上可能就會累積大量的缺陷設計，此時再進行編碼修復，肯定會導致一系列的編碼重寫或變動，嚴重影響了軟件開發(fā)進程。CMM作為一個復雜的過程體系，在軟件測試過程控制方面，有著很多的參考做法，但在CMM中基于敏捷思想的實踐做法數(shù)量卻有限，且很多都涉及到與敏捷思想的融合問題[2]。實際上，CMM與敏捷思想在適用范圍、做法等諸多方面上還是存在差異的，不但存在著明顯的區(qū)別甚至對立，還存在著一定的互補關系，創(chuàng)建一組基于敏捷思想的CMM軟件測試模型和方法，可以取得更好的軟件開發(fā)效率。

2 敏捷的核心思想

敏捷在軟件開發(fā)過程中主要體現(xiàn)了以人為本的理念，開發(fā)過程以循序漸進、階段性迭代作為其軟件開發(fā)的主要特征，及時滿足軟件不斷變更的需求。敏捷宣言強調(diào)團隊行為，個體能力付出與及時交流并重，強調(diào)任何可測階段的軟件都是可用的，強調(diào)各方協(xié)作而不是談判，強調(diào)開發(fā)過程的動態(tài)調(diào)整而不是必須按部就班。敏捷軟件過程開發(fā)中，先將整體項目切分成多個子項目，每個子項目獨立完成，但各子項目之間又相互聯(lián)系，每一個子項目都要經(jīng)過軟件測試，保證各子項目都能成功運行，在整個開發(fā)過程中，軟件始終處于可用狀態(tài)。敏捷開發(fā)提倡盡早測試，即只要有可能就進行測試，這種方式更容易在項目早期發(fā)現(xiàn)及控制缺陷數(shù)目。

3 編碼檢查

編碼檢查是一種高效的軟件測試手段，通過編碼檢查能夠盡早地發(fā)現(xiàn)軟件已經(jīng)存在或潛在的缺陷，找出動態(tài)軟件測試難以發(fā)現(xiàn)或隔離的軟件設計缺陷。事實證明，越早發(fā)現(xiàn)編碼缺陷，越有利于降低整體軟件測試的成本。另外，編碼檢查能夠為軟件開發(fā)過程中的動態(tài)測試過程設計、測試用例制定及使用提供思路。

但當前的CMM軟件編碼檢查主要采用傳統(tǒng)的方法，這種傳統(tǒng)方法通常只關注代碼本身的邏輯問題，如語義語法錯誤等，沒有與該軟件產(chǎn)品所處的專業(yè)領域知識相關聯(lián)，不易及時發(fā)現(xiàn)編碼專業(yè)功能等方面的問題，而必須等待功能測試環(huán)節(jié)才能發(fā)現(xiàn)，勢必會造成編碼缺陷的累積，也會影響軟件開發(fā)過程。

針對傳統(tǒng)的編碼檢查方法存在的一系列問題，采用與專業(yè)領域相結合的編碼檢查方法。即在傳統(tǒng)的編碼檢查方法基礎上，將通用編碼檢查與相關的專業(yè)領域知識相結合，組建基于某專業(yè)領域的編碼檢查清單。首先建立針對不同軟件開發(fā)語言的通用編碼檢查知識庫，如C語言；然后根據(jù)該軟件產(chǎn)品所涉及的專業(yè)領域，將軟件產(chǎn)品從功能上進行劃分，建立某專業(yè)領域編碼檢查要素知識庫；最后將以上兩個知識庫進行融合，形成基于某專業(yè)領域的編碼檢查清單[3]。

4 CMM編碼檢查的敏捷方案

4.1 工作流的元定義[ 4]

工作流已經(jīng)得到很多驗證，這項技術與管理模式可以有效降低軟件產(chǎn)品的開發(fā)風險，業(yè)務流程更加可控、更容易維護，新業(yè)務流程的部署也會變得相對容易，提高了對軟件產(chǎn)品迭代開發(fā)的支持。因此，在敏捷開發(fā)與測試中，使用工作流系統(tǒng)可使軟件開發(fā)更有效、風險更低。工作流管理聯(lián)盟這個組織定義了元模型,其全稱為Process Definition Meta-mode，簡稱為PDM結構，如圖1所示。

圖1 PDM元模型

4.2 CMM編碼檢查應用H模型

模型中，CMM軟件開發(fā)與編碼檢查并發(fā)執(zhí)行，構成基于工作流的H型模型結構[5-6]，其中編碼檢查工作流引擎為其核心部件，整個過程中強調(diào)盡早測試等敏捷測試原則，如圖2所示。過程控制的基本流程為：

（1）由編碼檢查及編碼人員共同建立編碼檢查事例庫；

（2）由任務分配來觸發(fā)編碼檢查的工作流引擎，制定各階段的檢查方案，并由編碼專家及檢查專家共同評審檢查方案，通過后進行檢查。若檢查結果無誤，則執(zhí)行檢查評估并填寫相關文檔，若檢查有誤則產(chǎn)生相關編碼缺陷報告并提交審核；

（3）審核編碼缺陷報告，如果發(fā)現(xiàn)的編碼缺陷是可以修正的，則作為新任務對象再次進行分配；

（4）由任務分配來再次觸發(fā)編碼檢查工作流引擎（編碼缺陷修正），由編碼人員進行編碼修正，自測成功后進入編碼回歸檢查階段；

（5）回歸檢查將上步修正后的編碼作為新任務進行任務再分配；觸發(fā)引擎，回到（2）進行迭代，當再無編碼缺陷時執(zhí)行關閉。

圖2 編碼檢查應用模型

4.3 編碼檢查用例缺陷狀態(tài)

軟件開發(fā)過程的每個階段都可能產(chǎn)生編碼缺陷，在整個軟件開發(fā)過程中對編碼缺陷實行全程跟蹤管理是非常必要的，因為這種編碼缺陷有可能是由上一個階段的工作失誤造成。在理想狀態(tài)下，編碼缺陷的狀態(tài)以及編碼缺陷狀態(tài)之間的流轉路徑能夠根據(jù)編碼檢查人員的預定要求在編碼檢查之前進行設置[7]。新發(fā)現(xiàn)的編碼缺陷或沒被修改的編碼缺陷要提交給編碼人員進行編碼缺陷修正，待編碼人員完成編碼缺陷修復后，再次提交編碼檢查，如經(jīng)過檢查后確定編碼缺陷已被修正，則標記“已修正”；如果編碼沒有修正成功，則將作為新編碼缺陷再次提交修正。另外，如果編碼檢查人員發(fā)現(xiàn)的編碼缺陷是潛在的并且馬上修正代價過高，則在其不影響當前階段性檢查的情況下推遲至下階段。

4.4 編碼檢查任務分配

編碼檢查任務的分配要依照四步原則進行，即計劃、執(zhí)行、檢查、調(diào)整，無論哪個階段的編碼檢查，必須先制定相應計劃，明確編碼檢查步驟和檢查用例，與此同時，要明確檢查的時間和資源消耗等，依此進行人員和任務分配[8]。

4.5 編碼檢查用例

編碼檢查團隊中必須包含兩類成員：一是精通編碼語言的程序設計專家，二是專業(yè)領域?qū)＜遥☉邆浯笮蛙浖_發(fā)經(jīng)驗），兩類專家注重溝通，共同制定編碼檢查方案，檢查方案隨著軟件開發(fā)進度的不同以及項目的不同動態(tài)調(diào)整編碼檢查清單。

編碼檢查用例采用基于某專業(yè)領域的編碼檢查清單中的用例，并將用例分靜態(tài)和動態(tài)兩種狀態(tài)，規(guī)定只有動態(tài)用例才能參與真正的編碼檢查活動，所以，必須將任務分配后的編碼檢查用例狀態(tài)由靜態(tài)改成動態(tài)。實施中，靜態(tài)檢查用例包括通用數(shù)據(jù)與專業(yè)領域數(shù)據(jù)及邏輯，動態(tài)檢查用例的標記包括檢查用例的狀態(tài)、檢查結果以及檢查報告等信息進行標記，可用“尚未檢查、檢查通過、檢查失敗、檢查出設計問題”四個狀態(tài)來跟蹤編碼檢查用例的執(zhí)行情況。

5 結語

本著敏捷開發(fā)原則并結合專業(yè)領域知識進行編碼檢查，做到有需要就檢查，盡量早地發(fā)現(xiàn)錯誤并改正錯誤。同時編碼檢查可分為自查和驗收性檢查兩種，自查應在開發(fā)團隊內(nèi)進行，并把編碼自查看作是軟件開發(fā)的一部分，且是重要的優(yōu)化手段；驗收性檢查一般由項目管理者或上級負責，包括階段性驗收檢查。本文模型可以使整個編碼檢查過程更加清晰，使軟件產(chǎn)品質(zhì)量得以保證、提高開發(fā)效率，對中小型軟件開發(fā)有著很好的適用性。

參考文獻：

[1]俞磊，白尚旺，黨偉超等.基于CMM-3的軟件測試過程模型的研究[J].計算機與數(shù)字工程，2011（7）：79-82.

[2]徐俊，彭章綱.敏捷開發(fā)過程與CMMI實施融合研究[J].現(xiàn)代計算機，2011（12）:21-23.

[3]周景科.專業(yè)領域軟件的代碼審查方法研究[J].軟件產(chǎn)品可靠性與環(huán)境試驗，2016（6）：39-44.

[4]趙瑞東等.工作流與工作流管理技術綜述[J].科技信息，2007（8）：105-107.

[5]徐東，張曉雯等.CMM軟件測試H模型研究[J].軟件工程師，2014（4）：11-13.

[6]張曉雯，徐東.基于工作流的軟件測試H模型研究[J].軟件導刊，2013（2）：24-26.

[7]吳慧韞.基于工作流的軟件測試管理系統(tǒng)研究與設計[D].南昌：南昌大學，2005.

[8]鄭小軍等.基于工作流技術的軟件測試流程定義與監(jiān)控[J].計算機應用研究，2007（2）：43-45.