李紹棟
(北京廣利核系統工程有限公司,北京 100094)
近年來,許多計算機軟件應用于關鍵領域,從醫療電子設備、空中交通管制系統到核電站。盡可能杜絕軟件系統一切可能存在的缺陷,是保護人類生命和財產安全的重要保障。然而,由于軟件中存在無法預知的錯誤,通常通過人為的方式判斷出可能存在錯誤的地方,并對此處進行相應修改。但是在軟件測試結束后,仍不能確保軟件系統中已不再存在錯誤。盡管如此,軟件測試還是能夠準確地估算出軟件出錯的可能性及其可能導致事故后果的嚴重程度,并將其控制在可接受的范圍內。由此可見,軟件測試絕不是一個簡單輕松的過程,除了要占用大量的資源,還需要投入大量的人力、消耗大量的時間。對于核電DCS 應用軟件測試更是如此,人力資源約占整個測試階段的30%~40%,測試時間會占到整個軟件開發周期的20%~30%,由此可見軟件測試工作的繁重,同時由于種種原因,人因失誤難以避免。因此,如何實現核電DCS 應用軟件測試的自動化以提高軟件測試效率、減少人工重復性工作,是一個亟待解決的問題。
1983 年,IEEE 提出軟件工程的標準術語,將軟件測試定義為:“使用人工或自動手段來運行或測試某個系統的過程,其目的在于檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別”[1]。該定義中明確地提出軟件測試的目標是檢驗被測軟件是否滿足需求。
核電DCS 應用軟件測試的目的是證明軟件設計到軟件實現的一致性,邏輯測試的對象是配置管理的工程組態。根據程序執行的方式,可以將軟件測試方法分為人工測試和自動化測試兩類。根據測試過程中程序的執行狀態,可以將軟件測試分為靜態測試和動態測試[2]。根據測試過程對系統內部結構和具體實現算法細節的關心情況,軟件測試方法可分為黑盒測試和白盒測試。核電應用軟件邏輯傳統測試方法按照分類來說,屬于人工的、靜態或動態的白盒測試。
核電站安全級DCS 應用軟件邏輯測試是為了驗證工程軟件組態與功能圖的輸入變量和輸出變量名稱、類型及邏輯組態的一致性。其主要檢查安全級DCS 組態文件是否正確實現了工程設計圖紙要求的控制功能,測試過程中需確認點名、邏輯功能塊選擇、跳轉頁面的名稱、邏輯功能塊的輸入輸出信息和邏輯組態實現的功能及信號流向與FD功能圖一致性。
測試人員通過在維護工具上強制的方法來產生信號,信號經過相應的算法塊會產生相應的操作結果,將通過算法塊的運算結果與算法塊的功能加以比較,就能得出該算法塊的功能是否正確,信號流向是否正常等一系列結果,通過驗證的使用記號筆進行涂抹標記。具體測試方法流程如圖1 所示。
由于核能的特殊性,一個小誤差經過累計可能導致一次核事故。因此,核電軟件對每個數據的精度要求都比較高。核電站一旦爆發事故,便會引起不堪設想的嚴重后果。因而在核電軟件的測試過程中需要特別關注如何檢測和更正發生的軟件故障,同時又能保證其按預定的成本、進度、質量順利地執行并完成,顯得尤為重要。

圖1 人工邏輯測試流程圖Fig.1 Flow chart of manual logic test
基于以上幾點,上述測試方式在實踐過程中,往往存在以下問題:
1)測試周期長、通用性差
涂抹測試方法在A 項目安全級DCS 應用軟件邏輯測試一個版本5100 余張大約需要投入10 人大約需要2 個月工期,占用了20%的測試周期40%的人力資源,且后續多個版次及后續項目應用軟件邏輯測試仍需大量人力和時間,所以現有測試方法周期長、效率低。
2)自動化程度低,人因失誤
人工測試過程中,測試人員往往采用手動加載工程、手動使用工程師站軟件強制信號、人工讀取工程師站軟件反饋信號的方式進行測試。這種主要依靠手工測試方式效率較低,一個DCS 項目1 個版次就將近5100 多張功能圖,按10 人10 張/天的工作量計算,測試時間往往長達2 個月。測試人員采用手動加載工程、手動使用工程師站軟件強制信號、人工讀取工程師站軟件反饋信號,在功能圖上進行涂抹確認的方式進行測試,由于測試人員知識、狀態差異,難免會由于人因出現錯誤或遺漏。
3)測試結果的可追溯性差
測試人員采用在功能圖上進行涂抹確認的方式形成測試記錄,當發生錯測、漏測時,僅僅依靠涂抹不足以分析錯測、漏測的原因。如果測試人員的能力達不到規定的要求,軟件測試的過程失去控制,從而導致軟件測試結果的重現性差,不同的測試人員對同一個軟件的測試結果經常是不同的,導致測試結果的可追溯性差。
軟件邏輯測試的目標是盡可能多地發現軟件中存在的問題,軟件測試是軟件質量保證的關鍵步驟。針對人工比對涂抹的測試方法存在測試周期長、測試效率低、人因失誤無法避免等問題。為了提升應用軟件邏輯測試的自動化率水平,減少測試人力投入,縮短測試工期,減少和避免人工測試引入的人因失誤,引入了一種通過因果圖分析法,將輸入文件轉化因果圖進而轉化為真值表測試用例,然后提出需要,開發相應的自動化測試工具。最終,通過自動化測試工具,使得測試用例能夠自動讀取、自動執行、自動生成測試記錄。還可以將大量的測試用例收集到測試用例庫中,經過合理分類,供測試人員復用,有利于提高后續項目的測試效率。
影響軟件邏輯測試的因素很多,例如軟件本身的復雜程度,組態人員(包括分析、設計、測試人員)的素質,測試方法和技術的運用等。測試用例是測試工作的指導,可以把人為的因素減少到最小,而且會隨著測試的進行日趨完善,是軟件測試質量穩定的根本保障。測試用例是為特定目標開發的測試輸入、執行條件和預期結果的集合[3]。測試用例屬于軟件測試工作的指導性文件,測試用例的優劣直接影響軟件測試的質量。
軟件測試中的邏輯測試是從用戶的角度出發,以功能圖和算法塊手冊為依據來設計測試用例,執行測試活動的。為了盡可能多地發現系統中的缺陷,驗證系統實現與需求之間一致性,邏輯測試用例需要設計的非常具體、詳細,包括每一操作步驟的執行動作、輸入數據等。僅憑個人的工作經驗來設計測試用例,測試質量無法保證,因此有必要尋找一種經濟有效的用例設計方法,以期用最少的人力和資源投入,在最短的時間內完成測試,并發現軟件的問題,進而保證軟件的品質。
在核電DCS 軟件測試領域,因果圖是一種較好地檢測應用軟件問題或缺陷的方法。因果圖法是一種根據條件組合生成測試用例的系統性方法,它利用圖解法分析輸入的各種組合情況,從而設計測試用例,適合于檢查程序輸入條件的各種組合情況。因果圖通過將不同條件組合轉換為圖表的形式來獲得需求中額外的情況,以最有效率的方式來驗證軟件程序。
使用因果圖處理邏輯關系的技巧如下(T 代表“Ture”,F 代表“False”,effect 代表“作用”):
如果輸入條件是N 個“因”通過“or”組成的邏輯關系,那么就要用到N +1 個測試用例:
①如果輸入1T or 2F...or NF ',輸出為T;
②如果輸入1F or 2T...or NF ',輸出為T;
......

圖2 因果關系圖Fig.2 Causality diagram
N.如果輸入1F or 2F...or NT ',輸出為T;
N+1.如果輸入1F or 2F...or NF ',輸出為F;
同理,如果輸入條件是N 個“因”通過“and”組成的邏輯關系,那么也要用到N +1 個測試用例:
①如果輸入1F and 2T...and NT ',輸出為F;
②如果輸入1T and 2F...and NT ',輸出為F;
......
N.如果輸入1T and 2T...and NF ',輸出為F;
N+1.如果輸入1T and 2T...and NT ',輸出為T;
按照此原理,每個“果”所需要的測試用例數量通常是“因”的數量加1。經過實踐發現,每個“果”所需要的測試用例必須至少等于這個“果”所對應“因”的數量加1。
基于以上基本理論,某核電項目改進邏輯測試用例,通過真值表模板來制作應用軟件邏輯測試用例,具體用例設計方法如下:
1)分析軟件規格說明描述中,哪些是原因(即輸入條件或輸入條件的等價類),哪些是結果(即輸出條件),并給每個原因和結果賦予一個標識符。
2)分析軟件規格說明描述中的語義。找出原因與結果之間,原因與原因之間對應的關系。根據這些關系,得出因果圖,如圖2 所示。
3)標記約束或限制條件,由于語法或環境限制,有些原因與原因之間、原因與結果之間的組合情況下不可能出現。為表明這些特殊情況,在因果圖上用一些記號表明約束或限制條件。
4)把因果圖轉換為判定表,用判定表中的每一項生成測試用例。
5)按照邏輯對應關系得出一個單獨完整的測試用例,該測試用例覆蓋了所有需求,詳見表1。
此例不考慮設計因素的情況下僅用了10 步就將“003KS”的需求包含在內,保證了測試用例滿足需求。由此可見,因果圖能幫助人們按一定步驟,高效率地選擇測試用例,并且以最小覆蓋的范圍來盡可能地找出程序中的缺陷或錯誤。

表1 測試用例Table 1 Test cases
測試用例設計時,需從以下幾個方面考慮測試覆蓋率是否滿足要求:
1)功能圖頁中所有輸入變量、輸出變量需納入測試覆蓋率。
2)以測試用例為單位,統計所有變量類型的數量。
3)統計測試步驟中變量數值變化的數量和名稱。
4)按照下面的公式計算覆蓋率:覆蓋率=執行過程中變化的變量數量/變量總數量。
5)用例第一步執行完成后,記錄變量數值作為統計基準值,后續發生變化的認為是變化。
測試用例完成設計之后,為了進一步減少測試人力投入,縮短測試工期,減少和避免人工測試引入的人因失誤,提高自動化率。經過對多項目邏輯測試數據的分析,對自動化測試工具提出了具體的需求,以滿足軟件邏輯自動化測試:
1)獨立運行,具備仿真功能,按照測試用例中的步驟,執行強制和取消強制輸入變量的操作,讀取輸出變量的結果。
2)組態文件中每個算法塊都有唯一的名稱,自動化工具能夠支持算法塊輸入引腳和輸出引腳的強制和讀取。
3)測試用例中輸出變量回讀時間與組態中算法塊延時時間一致,軟件能夠根據控制站周期與回讀時間計算仿真周期計數,回讀結果按照周期計數總數執行。
4)測試用例中能通過“-”表示空白信息,軟件加載時遇到“-”不進行校驗處理。
5)測試執行完成后,結果為“√”的代表執行通過,結果為“×”的標記執行不通過,通過紅色高亮顯示。

圖3 自動化邏輯測試流程圖Fig.3 Flow chart of automated logic test
經定制開發的自動化測試工具能夠正常執行自動化仿真測試,并且生成執行結果和測試報告。
邏輯測試用例設計完成之后,通過自動化測試工具,加載工程文件和自動化邏輯測試用例文件后,選擇自動執行測試用例,工具讀取試驗條件變量的在線值,依次判斷試驗條件是否滿足,滿足則進行下一步;試驗時,工作區顯示當前正在進行的邏輯測試用例,并更新執行完成的每一步驟的結果,試驗失敗則更新為紅色顯示的實驗失敗的數據(預期值后加括號顯示失敗數據)和試驗結果(“×”),試驗成功則表示預期值與試驗數據一致,只更新為綠色顯示的實驗結果(“√”);自動化邏輯測試試驗項結束時對所有變量數值進行記錄,最終輸出試驗結果和形成測試記錄。
自動化測試流程如圖3 所示。顯而易見,自動化邏輯測試是一種高效的、動態的、黑盒自動測試方法。
自動化邏輯測試方法適用于所有核電站項目安全級DCS 項目應用軟件邏輯測試。通過相應平臺的自動化測試工具,能夠大幅提升測試效率。結合在某核電項目DCS 工廠測試應用的效果來看,對于傳統的上述測試項目,相比原有的人工確認涂抹測試方式,單項測試的耗時平均縮短80%;測試期間人力投入可減少50%。自動化邏輯測試方法不僅提高了效率,還減少了人因失誤,具體效果詳見表2。

表2 人工測試與自動化測試效果對照表Table 2 Comparison table of manual test and automated test effect
本文以核電站安全級DCS 自主化開發為研究背景,對比了自動化邏輯測試方法與人工測試方法之間的差異,并結合工程實踐,自動化測試方法不僅能提升測試效率與準確率,同時降低了人因失誤,及早發現并解決DCS 存在的問題,降低后續工程測試階段以及現場改造成本。另外需要特別指出的是,人工邏輯測試方法仍然有效,但需要投入大量有經驗測試人員去執行測試,測試效率、用例復用性、可追溯性方面不如自動化邏輯測試方法有效。