代碼審查缺陷密度量化模型研究

鴉 文，楊沁梅

（中國電子科技集團公司第二十八研究所，江蘇 南京 210007）

0 引言

測試是“使用為發現錯誤所選擇的輸入和狀態的組合而執行代碼的過程”[1-4]，代碼審查是軟件測試的手段之一，是在不執行軟件的條件下有條理地仔細審查軟件代碼，從而找出軟件缺陷的過程。代碼審查必須依靠具有軟件系統開發經驗、編程經驗、測試經驗的技術人員集體審查[5]。進行代碼審查的主要目的是提高軟件質量，及早發現軟件缺陷，避免因這些缺陷造成更大的災難[6]。在開發過程初期進行軟件代碼審查非常有價值，不僅可以找出后期軟件測試階段難以發現或隔離的軟件缺陷，降低研發成本；同時還可以促進開發團隊內部溝通和知識共享，提升團隊開發能力。

量化管理是CMMI的主要內容之一，量化管理使得軟件管理者擁有決策的客觀基礎，能在量化的范圍內預測性能，可以有效地監控項目過程，處理過程偏差的特殊原因[7-12]。

為此，可以將代碼審查過程識別為影響項目目標達成的關鍵過程之一，通過建立過程性能模型和使用適當的量化分析方法[13-14]，來指導代碼審查活動的策劃和實施，達到提升產品最終質量的目標。統計過程控制中主要利用控制圖來記錄過程質量[15]。

1 代碼審查平臺

軟件項目管理過程中，組織往往缺少量化的數據支撐，從而導致對于有關量化的改進目標制定或者項目的量化目標制定無從下手[16]。為此，可以通過集成開源的配置管理、代碼檢測、權限控制工具，建立代碼審查平臺來進行在線審查和數據采集，為后續的模型建立和量化分析過程提供平臺支撐。

一種可行的代碼審查平臺設計架構如圖1 所示。

圖1 代碼審查平臺架構

其中：

（1）Crowd 是atlassian 公司推出的集成化組件，其實現和配置簡單，功能齊全，用于用戶管理和授權登錄。利用此平臺可錄入代碼審查活動相關人員信息并賦予不同的使用和管理權限。

（2）Crucible工具是一個代碼檢測工具，能檢查、注釋、編輯代碼，并記錄結果，幫助開發人員發現和糾正缺陷，提高代碼開發效率。代碼審查活動主要依托共用平臺Atlassian Crucible 模塊實施。

（3）Gitlab 是一個用于倉庫管理系統的開源項目，使用Git 作為代碼管理工具，并在此基礎上搭建起來的Web服務。該模塊用于瀏覽源代碼和代碼缺陷管理。開發團隊可使用該模塊瀏覽歷史版本，也可以利用其代碼片段收集功能實現代碼復用、查找。該模塊非強制使用，由項目組/業務室選擇使用。

2 代碼審查觸發時機

代碼審查由項目軟件負責人或專業/業務負責人在完成以下代碼研發和自測后組織執行。可重點針對以下對象進行審查：

（1）被定義為關重件配置項的代碼；

（2）核心算法、主要業務邏輯、關鍵數據處理、提供對外接口的代碼；

（3）新員工產生的代碼；

（4）前期測試過程中問題較多的軟件代碼。

3 代碼審查

3.1 審查準備

3.1.1 建立專家庫

項目研發組織首先應建立代碼審查專家庫，主要成員可以是組織內各領域的資深程序員和各專業/業務的技術骨干。

每次代碼審查前，由各項目/專業/業務負責人依據被審查代碼的專業/業務類型從部門代碼審查專家庫中選取除被審代碼編寫者之外的代碼審查人員，成立代碼審查組，并指定代碼審查組長。

3.1.2 設置用戶權限

依托代碼審查平臺可以實現用戶的添加和權限設定，主要步驟如下：

（1）由配置管理員在Crowd 模塊中錄入人員信息（支持分組），并設定各模塊管理員和使用者角色；

（2）配置管理員將Crucible、Gitlab 模塊的權限信息與Crowd 相連，確保Crowd 模塊中的用戶信息在各個模塊中可見；

（3）各項目/專業/業務負責人在需使用的模塊中設定人員權限。

3.1.3 選取和提交審查代碼

代碼審查前，各項目/專業/業務依據第2 節選取需審查代碼（但不限于）。

3.2 執行代碼審查

代碼審查專家在Crucible 上開展代碼審查活動，審查重點為代碼整體架構、風格、邏輯質量等，審查項及主要要求參考表1。

表1 首輪采集

具體方法：

（1）代碼審查專家登錄“lzb.cru.com:8060/cru”，打開代碼開展審核；

（2）點擊有問題的代碼，并輸入審查意見，點擊“Comment”提交。

3.3 審查問題整改歸零

（1）代碼審查后，開發人員根據代碼審查專家提出的問題對代碼進行修改；（2）完成修改后，重新提交代碼審查；（3）代碼審查人員進行回歸確認。

3.4 審查結果處置

項目代碼審查活動結束后，由代碼審查組長匯總、分析代碼審查數據，并及時將代碼審查過程中遇到的典型編碼缺陷在開發團隊或全部門集中宣貫，減少典型缺陷重復發生。

4 代碼審查過程性能模型建立

4.1 模型定義

代碼審查缺陷清除模型預測值為代碼審查發現缺陷的密度，分析確定影響部級代碼審查質量的因子是：審查專家能力、開發人員能力和代碼審查速率。即：代碼審查發現缺陷的密度＝f（審查專家能力，開發人員能力，代碼審查速率）。

模型因子取值如下：

（1）審查專家能力取值：5 表示能力高，從事軟件編碼工作5 年及5 年以上；3 表示能力中，從事軟件編碼工作大于等于3 年且少于5 年；1 表示能力低，從事軟件編碼工作少于3 年。

（2）開發人員能力取值：5 表示能力高，從事軟件編碼工作5 年及5 年以上；3 表示能力中，從事軟件編碼工作大于等于3 年且少于5 年；1 表示能力低，從事軟件編碼工作少于3 年。

（3）代碼審查速率＝代碼審查代碼規模÷代碼審查總工時。

4.2 數據采集

首輪采集了21 組有效數據，見表1。

4.3 模型試算

4.3.1 正態性檢驗

經使用Mintab工具計算得到的審查專家能力、開發人員能力和代碼審查速率這3 個參數的正態性檢驗結果如圖2 所示。

圖2 正態性檢驗結果

4.3.2 相關性分析

經使用Mintab工具計算得到的審查專家能力（x1）、開發人員能力（x2）、審查速率（x3）和代碼審查缺陷密度（Y）這4 個參數的相關性結果如圖3 所示。

圖3 相關性分析結果

4.3.3 回歸分析結果

進一步使用Mintab工具計算，得到初步建立的模型算法，如圖4 所示。即：

圖4 回歸分析結果

代碼審查缺陷密度（個/千行）=3.583+0.076×審查專家能力-0.159×開發人員能力-1.977×代碼審查速率

4.4 基線建立

經Mintab工具計算得到代碼審查缺陷密度概率圖如圖5 所示，計算得到的P 值大于0.05，顯示樣本數據服從正態分布。

圖5 代碼審查缺陷密度概率圖

進一步使用控制圖檢查數據的穩定性，如圖6 所示，數據點隨機地分布在中心線（即基線均值）上下，且在基線上下限之間，表明數據基本穩定。

圖6 數據穩定性檢查

最終獲得的基線值如圖7 所示，即代碼審查缺陷密度平均為1.921 9 個/千行代碼。

圖7 代碼審查基線值

5 結論

研發團隊所屬組織可以根據組織對產品質量的要求和團隊實際情況，參考以上得到的代碼審查缺陷密度平均值來設定組織級代碼缺陷目標，并使用建立的模型，依據代碼審查的代碼規模、選定的審查專家能力，計算得到代碼審查工時的估計值，并據此估計值進行代碼審查活動的策劃。通過所屬項目后續的測試、檢驗活動，可以再逐步分析代碼審查遺留問題的影響，并重新修正模型和目標，進而逐步達到通過有效代碼審查提升代碼質量的目的。