核電廠非安全級控制系統軟件缺陷分析

卞小磊，周錦永，顧吉青，王 赫，張小盈

（國核自儀系統工程有限公司，上海 200241）

0 引言

軟件缺陷是軟件產品中存在不足，會導致軟件的運行與預期不同。從“軟件用戶”的角度來看，缺陷泛指一切導致軟件無法符合預期目標的東西。根據美國國家標準技術研究所（NIST）發布的研究報告稱，軟件缺陷或錯誤普遍存在并十分有害，每年給美國造成的經濟損失估計達595億美元，即約占其國內生產總值（GDP）的0.6%[1]。為了保證軟件能夠正常運行，對軟件存在的缺陷進行有效的分析是十分必要的。軟件開發公司和個人必須都積極采取有效的方法，盡可能減少缺陷[2]。

缺陷分析是提高核電廠數字化系統軟件質量重要的一環。在三代核電控制系統的開發過程中，控制系統測試工程師會在各個測試階段發現各種測試問題，然后由相關設計工程師進行修改關閉測試問題。在關閉測試問題的過程中，會相應地在項目管理工具中記錄該問題的各個屬性，如發現階段、問題類型等。如何對測試過程中的軟件缺陷進行管理跟蹤和分析，對減少缺陷數目，提高軟件質量有著重大現實意義。

核電廠非安全級控制系統采用分散控制的方法來實現核電廠各個功能的實現。電站控制系統實現多個工藝系統的控制功能，各個系統存在若干設備。在如此龐大的設計任務下，詳細設計階段一般會采用分批次進行系統的組態、測試工作。因此，為了提高軟件質量，通過前一批次發現的問題得到相應的經驗反饋來指導后面的工作是非常必要的。針對項目中對軟件缺陷管理的需要，本文首先論述了軟件缺陷概述，常見的缺陷分類分析方法，著重介紹正交缺陷分類（ODC）、根本原因分析（RCA）的基本概念，然后應用該方法對項目內發現的問題進行分類、分析，最后得到了分析結果及改進措施。

1 軟件缺陷

軟件缺陷是指對軟件產品期望屬性的偏離，軟件沒有滿足規范以及客戶要求，造成用戶使用不暢。SW-CMM對其定義是：系統或系統成分中能造成他們無法實現其被要求的功能的缺點。如果在執行過程中遇到缺陷，它可能導致系統的失敗。

軟件生命周期的各個階段必然或多或少的存在著缺陷，不同軟件開發設計階段產生的缺陷不同。針對已產生問題的分析研究，可能會發現需求階段引入的缺陷可能會導致設計出的軟件偏離客戶需求；設計階段引入的缺陷可能會導致系統無法實現預期功能，還可能增加測試難度；維護階段引入的缺陷可能會導致原有缺陷已被修改，但會引入更多新的缺陷[3]。

目前針對缺陷的分類分析方法在核電行業還沒有固定的標準，問題分析的目的也大多是為了解決問題，而不是去避免這一問題的再次發生。所以選擇一個合適的缺陷分類分析方法成為當前核電廠軟件缺陷的準則，成為一項重要任務。

2 缺陷分類及分析方法

2.1 缺陷分類方法

目前核電還沒有較為廣泛的缺陷分類及分析方法，軟件行業較為主流的缺陷分類方法有：GJB-437、正交缺陷分類（ODC）、IEEE軟件異常分類標準、Thayer分類法。這些方法各有優缺點，對比見表1。

表1 缺陷分類方法對比Table 1 Comparison of defect classification methods

國家軍用標準GJB-437根據軍用軟件錯誤的來源將軟件錯誤分為3類，分別為：程序錯誤，運行程序與相應的文檔不一致，而文檔是正確的；文檔錯誤，運行程序與相應的文檔不一致，而程序是正確的；設計錯誤，雖然運行程序與相應的文檔一致，但存在設計缺陷，可能產生錯誤[4]。該分類方法能分析軟件缺陷產生的位置，該分類方法最顯著的特點就是簡單。但是正由于分類方法太過于簡單，對軟件缺陷研究可以進一步提升軟件質量的作用非常有限。

ODC分類方法適合缺陷的定位排查以及原因分析，缺陷特征所帶來的信息能夠為缺陷的預防以及軟件質量的提升帶來較大作用。IBM一直在改進ODC，使其更加的完善。ODC的缺點是分類的過程比較復雜，過程中的缺陷未做考慮。分類過程中缺陷分析人員會根據主觀判斷，最終影響分類的屬性結果。

IEEE Std 1044-2009.Standard Classification for Anomalies軟件異常分類標準對軟件異常進行了定義并進行了分類[5]。該分類標準提供了異常數據作為軟件異常追蹤處理的參考，權威性較高。在軟件生命周期的各階段，該分類標準均提供了較為詳細的處理分類描述，分類信息豐富。不足之處在于沒有考慮軟件工程的過程缺陷，并且分類復雜。

Thayer分類是按照軟件缺陷的性質分類，將缺陷的性質作為錯誤分類的信息[6]。通過這種方法對缺陷先進行初步統計，按照缺陷發生的區域分布情況，對發生錯誤較為集中的組件進行統一的改進。這種分類方式沒有結合分類的過程，不容易分析出發生缺陷的原因，對軟件質量的提升改進有限。

綜合以上分類方法，本文選取ODC正交缺陷分類法對本核電項目進行缺陷的分類。

ODC（Orthogonal Defect Classification）是IBM Waston Research Center的R.Chillarege等人于1990年提出的缺陷分類方法[7]，經過數年的完善，目前已經得到較為廣泛的應用，取得了較好的應用效果。ODC方法適用于多周期、多版本、高復雜度的軟件開發過程。ODC提供了一套捕捉缺陷數據關鍵特性的方案，并就如何對分類的缺陷數據進行分析給出了指導[8]。

ODC分類法將缺陷特征分解為8個屬性：發現缺陷的活動、缺陷影響、缺陷觸發事件、缺陷載體、缺陷年齡、缺陷來源、缺陷類型和缺陷限定詞[7]。ODC中最重要的一個屬性就是缺陷類型，缺陷類型被分為7大類：賦值、檢驗、算法、時序、接口、功能、關聯。這些屬性中有很多是有目的地反映了產品周期中生成這些屬性的階段。

2.2 缺陷分析方法

將軟件缺陷進行ODC分類可以產生較多的定量分析的方法，如統計分析缺陷的來源、統計分析缺陷的分布、統計分析打開/關閉等，事實上項目人員也采用了這些分析方法。數據的分析也可以量化衡量產品質量，作為分析軟件可靠性的一種手段，但還需結合定性的缺陷分析方法作為補充。定性分析也能夠對一些容易忽略的個別缺陷進行分析，彌補一些遺漏的缺陷原因。定性的缺陷分析方法應用最廣泛的為根本原因分析（RCA），其方法在工業和醫療領域應用廣泛。

RCA可定義為：使用結構化的過程和方法，識別問題產生的根本原因并制定相應的解決方案，使問題不會重復發生。RCA是一種結構化的缺陷預防技術，它通過分析事件前后的因果關系，目的是能夠找到解決措施來消除發現的問題原因[9]。RCA研究是為了找出預防性方法，以消除單一缺陷或者整整一類缺陷。

RCA分為6個不同的步驟和缺陷，依次為事件確定、數據收集、數據分析與評估、糾正操作、通知與應用、遵循測量和報告。

數據分析與評估基本步驟如下：

1） 確保識別了缺陷事件并組織相關數據。

2） 評估其重要性。

3） 確定與該問題直接相關的原因。

4） 確定為什么會存在這些原因，并繼續工作，利用“5個為什么”方法和其他方法回溯找到根本原因。

5） 對這一階段所識別的所有原因進行分類。

通知與應用主要是將糾正操作向上游傳遞，上游反饋其執行情況的過程。遵循、測量和報告是對整個閉環的數據趨勢和模式的分析，最后給出書面結論和建議。

根本原因的優點：在開始時可以開展小型試驗分析，然后進行相應發展；對已按照缺陷類型進行分類的缺陷可以批量分析；可能是確定和糾正故障原因的最短路徑。

3 缺陷分類應用結果

考慮到核電儀控項目多周期、多版本、高復雜度的特點，軟件開發過程迭代較多，不適用于對過程要求嚴格的IEEE異常分類標準；Thayer分類法無法滿足通過缺陷分類來達到改善軟件開發過程，缺陷預防的目的也不適用；而對于ODC分類，其分類不依賴于軟件過程，對于其分類標準難以把握，可以通過ODC定義本地化的調整來解決。綜合比較投入的時間成本以及通過缺陷分析出的原因（產出），本文采用的缺陷分類方法為正交缺陷分類。

根據ODC分類定義，軟件設計階段的缺陷按以下3個階段、7個缺陷類別進行細分。分類的數據統計見表2。

表2 缺陷分類數量統計Table 2 Defect classification quantity statistics

4 原因分析及糾正措施

對缺陷進行分類和數據統計后，可以對缺陷進行定量和定性的原因分析。定量的原因分析主要用了缺陷分布分析，對各類缺陷在全部缺陷中的占比進行分析；定性的分析采用了根本原因分析的方法，對同一類的問題進行分析，從而得出糾正操作向上游傳遞。

4.1 缺陷分布分析

下面以某項目核電廠測試階段發現的問題為例進行分析。在此項目中，廠內測試共分為4層，Level 0層一般為零件測試，由供應商提供；Level 1層為單元測試，軟件部分主要是邏輯宏、畫面宏的測試；Level 2層軟件部分為控制應用軟件測試，包括邏輯測試與靜態畫面測試；Level 3層軟件部分為子系統集成測試。下面以Level 2和Level 3層測試階段所產生的缺陷為例進行分類分析。

4.1.1 邏輯、畫面測試階段

圖1為邏輯、畫面測試階段的缺陷分布統計。

由圖1項目人員可以得到幾點初步結果，如下：

圖1 邏輯、畫面測試缺陷分布統計圖Fig.1 Distribution statistics of logic and picture testing defects

1） 賦值/初始化、算法、接口、功能/類/對象的缺陷密度很大，故先考慮此類型的詳細分類，之后對詳細分類進行根本原因分析。

2） 由于觸發條件的限制，畫面測試發現的問題類別較少。故應該增加觸發條件，豐富測試用例的內容。

3） 缺陷類型為文檔的缺陷不存在，也側面說明了項目內的輸入評審已經較為完善。

4.1.2 邏輯畫面集成測試階段

圖2為邏輯、畫面測試階段問題的缺陷分布統計。

圖2 集成測試階段缺陷分布統計圖Fig.2 Statistical diagram of defect distribution in integration test phase

由圖2，項目人員可以得到幾點初步結果，如下：

1） 集成測試缺陷集中最多的依然是賦值/初始化，此類占比例最大的問題是畫面與邏輯中的點名不匹配或缺失。

2） 功能/類/對象的問題比例相對于預測試階段有了提高，所以下一步分析的要點應該為預測試階段之后發現的此類問題的內容。

3） 接口問題在邏輯中主要來源于I/O的連接；畫面中為管道、連接線的問題。

4） 算法問題主要是CFG（Configuration）參數和個別基本功能塊的缺失。

4.1.3 缺陷類別總占比

圖3為整個測試階段缺陷分布統計。

圖3中的數據可以指導項目人員對缺陷密度較大的幾類問題優先進行根本原因分析。比例較小的缺陷類型除考慮詳細分類外，應考慮測試規程在測試用例的類型上是否能夠更加豐富，增加觸發條件。另外，根據缺陷的集群性原則，應對發生錯誤較多的缺陷類型進行更加完善、嚴格的測試，使軟件的可靠性大大提高。

圖3 總體缺陷分布統計圖Fig.3 Overall defect distribution statistics

4.1.4 缺陷分類各階段對比分析

通過各個測試階段的缺陷類型占比可以得到哪類的缺陷分步比較密集，可以通過原因分析反饋到各個設計階段，提高軟件質量。測試階段的橫向對比可以得到項目人員的測試程度是否達到預期的目標，因此將各個階段的分類占比和ODC典型占比分布做了比較，用來反饋到各個測試階段，提高測試的有效性。圖4、圖5是Level 1～Level 3 3個階段的缺陷占比的橫向比較圖和典型分布圖。

通過圖4、圖5的對比和各類問題，可以得到以下幾點結論：

圖4 缺陷橫向對比圖Fig.4 Horizontal ccomparison of defects

圖5 缺陷類型分布趨勢圖Fig.5 Defect type distribution trend chart

1） 賦值/初始化：在單元測試（宏測試）階段開始都應該呈下降趨勢，但統計結果顯示一直呈上升趨勢，導致這一問題的原因是在執行前一階段時未能嚴格按照規程執行，導致后面測試還是會出現原來本應發現的問題。

2） 功能/類/對象：測試類型與典型類型趨勢大致一樣，隨著測試階段的進行，問題逐漸減少。

3） 檢查：按照典型趨勢，應逐步減少，但實際中逐漸增多，導致的原因可能是宏測試階段中觸發條件較少，之后會根據具體問題深入分析。

4） 接口：趨勢與典型趨勢一致，在檢測各個模塊間的接口主要是在邏輯測試階段進行，故邏輯階段發現的最多。

5） 算法：趨勢與典型趨勢一致，隨著測試的進行逐步減少。

4.2 產生原因分析及糾正措施

經過事件確定和數據收集，需進行數據分析與評估的問題主要為賦值/初始化，這一類別在宏測試階段、邏輯/畫面測試階段和邏輯畫面集成測試階段的總占比為54.98%，比例最高。以下以這一類別為例進行分析說明。

第一步：此類問題為賦值/初始化。

第二步：相關數據為前文統計的結果，包括的內容有發現問題的階段、解決方案、引入階段等。

第三步：賦值/初始化此類問題發生后影響邏輯與畫面集成，無法達到控制和顯示要求，直接影響了軟件的功能，重要性高。

第四步：產生該問題的直接原因是邏輯/畫面組態中參數填寫錯誤。

第五步、第六步：通過“5個為什么”分析，將得出的參數填寫錯誤的原因進行了歸類整理如下：

技術原因包括：①畫面宏參數未完全按照組態規范實施；②測試規程中未列出點名檢查清單。

技術管理原因包括：①邏輯組態中間點未有效管控；②培訓未覆蓋點命名規范。

根據其原因可以得到第4個步驟糾正操作的具體內容。糾正操作也分為技術上和技術管理上兩個部分：

技術上：在控制邏輯測試規程中詳細列出點名檢查清單。

技術管理上：①對組態規范實施進行統一培訓；②共享管理服務器內建立中間點管理庫，規范點命名管理；③對點命名規則進行統一培訓。

5 結論

基于ODC缺陷類型方法在工程實踐中的應用，按照此方法進行缺陷的分類、量化問題，進而通過缺陷分布分析對缺陷進行量化的分析，得到改進的措施。對于部分分布比例較大而且嚴重程度較高的缺陷使用了根本原因分析的方法，對此類缺陷進行定性分析，得到改進的措施，彌補了通過缺陷分析來得到技術、管理等方面的經驗反饋這一空白。

后續可以從兩個方面深入研究，一是ODC方法，嘗試應用ODC中的其他屬性，如分類屬性中的缺陷觸發（Triggers）、缺陷影響（Impact），可以更加豐富數據多樣性，進而得到更多反饋信息。其次，對后續組態測試問題進行缺陷分析并做橫向對比，通過數據分析來給出建議。