基于EN歐標流程的V模型軟件測試

周亞男，劉錦峰，朱程輝

（卡斯柯信號有限公司，上海 200071）

0 引言

V模型是軟件生命周期的基礎模型，也是軌道交通信號系統軟件開發的首選模型。在軌道交通系統自動化的發展過程中，軟件功能越來越復雜，安全性成為軌道交通信號軟件開發所關注的一個重點。軟件開發中存在著許多不可預測的因素，可能埋藏著不少重大風險，如何將風險控制在可接受的范圍內，以保證軌道交通信號軟件的安全可靠，是軟件開發生命周期中所必須要解決的問題，目前越來越多的企業引入了歐洲的鐵路相關標準[1]。

1 歐洲鐵路標準簡介

軌道交通業的標準依據是歐洲電工標準化委員會（CENELEC）規定的EN5012X系列，是IEC61508在軌交行業的派生標準，涉及如下：EN50129鐵路應用——信號領域的安全相關電子系統；EN50126鐵路應用——可靠性、可用性、可維護性和安全性；EN50128鐵路應用——通信、信號和處理系統-鐵路控制和防護系統軟件；EN50159-1鐵路應用——通信、信號和處理系統，第一部分：封閉式傳輸系統中的安全通信；EN50159-2鐵路應用——通信、信號和處理系統，第二部分：開放式傳輸系統中的安全通信。

本文主要圍繞EN50128展開討論，該標準對軟件開發生命周期的不同階段提出了包含流程、方法、技術的詳細要求。通過規范軟件的開發過程以及技術要求，來保證軌道交通軟件的質量和可靠性。

2 軟件測試流程

軟件生命周期V模型是一種線性順序模型，提供了一種結構化的、自頂向下的軟件開發方法，每階段主要工作成果從一個階段傳遞到下一個階段，每個階段的產出物必須經過評審或者測試。

傳統的V模型測試活動如圖1所示，定義了單元測試、軟件集成、軟件確認三個階段，分別對應詳細設計、概要設計、軟件需求，但是在軟件生命周期過程中沒有明確具體的活動以保證測試用例與需求設計之間的一致性，以及測試用例對需求覆蓋的完整性，導致完整的需求滿足情況一直到后期的驗收才被驗證。

圖1 傳統V 模型

相對于傳統的V模型，CENELECEN50128對整個軟件生命周期的過程進行控制，對各階段的工作有具體的指導要求，對采取的技術和方法提出了建議，通過流程控制來減少人為疏漏。結合EN50128的V模型生命周期如圖2所示。

圖2 結合EN50128 的V 模型

藍色字體為對比增加部分，包括：

（1）各階段有上下級關系的文檔增加追蹤驗證活動。該活動要求需求、設計文檔標簽化、條目化、結構化，同時由獨立的驗證人員逐條核查文檔內容，保證了不同階段的需求、設計之間的正確性、完整性、一致性。

（2）測試文檔對需求、涉及覆蓋情況的驗證活動。同樣由獨立的驗證人員檢查每一條需求是否都被用例完整覆蓋，測試用例設計正確無誤可執行。

（3）各階段的測試技術方法選擇要求。對各階段測試強制使用或者強烈推薦使用的測試方法選擇提出要求，該部分在下個章節詳細探討。

（4）測試執行的驗證活動。由獨立的驗證人員對測試執行過程以及結果進行監督以及驗證，減少測試過程中人為失誤導致的測試結果偏離。

（5）對整個軟件的驗證活動和測試活動的總結報告。通過分析或者證明所有的軟件需求都是按照適用的SIL要求進行開發，測試的，并且評估各階段所有的異常和偏離，給出軟件是否滿足定義的軟件安全完整性等級，符合軟件要求及其預期的結論。

以上活動可以看出，V模型結合EN50128以后，需求、設計以及測試文檔形成了完整的可追蹤關系，對整個開發過程中的需求形成了閉環管理。此外，要求研發、驗證、以及測試人員保持人員獨立性，通過完整的流程控制以及測試方法選用指導，保證在軟件開發生命周期過程中，盡早找出需求偏離和軟件缺陷，從而更高效地提高軟件質量，最大可能地減少返工成本[2-3]。

3 軟件測試方法

在EN50128標準中，將軟件安全完整性等級劃分為SIL0～SIL4五個等級，軟件安全完整性等級越高，對于測試技術方法的選擇要求越嚴格，軟件的SIL等級決定了測試過程中需要實現的測試方法：?“M”為必填項；?“HR”為強烈建議使用；?“R”為建議使用；?“—”為無要求。

每一個測試階段都有測試方法的推薦使用，對于標為R和HR的測試方法，一般都必須使用，如果不使用需要給出合理的解釋[4-5]。下面詳細介紹在不同的測試階段如何根據不同的安全等級選擇測試技術方法，本章節中測試技術方法表格均引自EN50128。

3.1 單元測試

單元即模塊測試，一般測試對象為源代碼，測試活動包括靜態測試和動態測試兩類。靜態測試又包含代碼驗證和代碼走讀，根據軟件詳細設計文件，通過對源代碼的編碼規范、代碼結構以及格式的審查和分析，在動態測試之前發現代碼問題。靜態測試的方法要求如表1，表2所示。

單元動態測試的對象一般為單個函數，通過測試人員編寫的測試驅動函數（通過工具可實現自動化）以及測試樁函數來動態執行代碼，發現軟件的缺陷。對于動態測試的要求如表3，表4所示。

表1 編碼規范（源自EN50128 A.12）

表2 靜態分析（源自EN50128 A.19）

表3 動態分析和測試（源自EN50128 A.13）

表4 代碼的測試覆蓋率（源自EN50128 A.21）

3.2 集成測試

集成測試的對象是軟件模塊，通過將軟件模塊一次性或者增量的方式進行組裝，根據軟件設計要求，對模塊功能以及模塊接口的正確性進行測試，軟件集成測試要求使用的方法如表5，表6所示。

表5 功能/黑盒測試（源自EN50128 A.14）

表6 性能測試（源自EN50128 A.18）

3.3 軟件確認測試

軟件確認測試是對整個軟件的功能以及性能進行的完整測試，一般是用黑盒的測試方法，驗證被測軟件是否滿足軟件需求定義。軟件確認測試要求使用的方法如上文表3，表5，表6所示，其中表3的技術方法在單元測試和軟件確認測試階段均引用到，只需保證組合起來能覆蓋完整即可。軟件測試是一個人為執行的過程，軟件測試的流程和方法直接影響測試結果的準確性和有效性，因此，軟件測試過程的指導流程至關重要。EN50128通過對以上三個不同測試階段指定軟件測試技術方法為軟件測試質量的保證提供了強有力的依據。

4 結論

本文分析了傳統V模型簡單在軌道交通軟件開發過程中應用的不足之處，歸納了EN50128結合傳統V模型在軟件測試過程的支持和擴充。通過分析和探討EN50128中對V模型測試過程以及技術方法的要求，總結出適合鐵路信號系統軟件不同安全等級的通用軟件測試方法和流程，對相關軟件的測試工作具有實際應用指導作用。