作者 |劉艷青上海控安安全測評部測試經理

版塊 |鑒源論壇· 觀通

引語：第一篇對軌交信號系統從鐵路系統分類和組成、城市軌交系統分類和組成、城市軌交系統功能、城市軌交系統發展方面做了介紹，第二篇從信號基礎的講述了信號機、轉轍機、軌道電路等設置原則和含義，第三篇從軌交系統的安全性設計的必要性、控制設計、需求分析以及實現等方面進行分析，第四篇重點從聯鎖系統的原理方面進行闡述。本篇將從軌交軟件生命周期入手，重點從軟件不同階段、不同類型闡述各階段的測試的重點。

01

什么是軟件測試

1.1 測試的定義

“測試是一個證明錯誤不存在的過程”

“測試的目的是為了顯示一個程序正確的實現了預期的功能”

“測試是建立對程序做了他應該做的事情的信心的過程”

“測試只能證明缺陷的存在，而不能證明測試的不存在”

IEEE定義的軟件測試：“使用人工或自動的手段來運行或測定某個系統的過程，其目的在于它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。”

“Testing is the process of executing a program with the intent of finding errors.”--- Glen Myers

1.2 軟件測試的目的

驗證軟件的所有構件是否正確集成；驗證所有需求是否已經正確實現；發現缺陷并確保在部署軟件之前將缺陷解決。

1.3 軟件測試的意義

測試在開發總成本中占30-50%；保證程序的正確性、完整性和一致性；顯著降低完成和維護軟件的開支；大大降低部署質量低劣的軟件相關的責任或風險。

02

軟件生命周期

常用的軟件生命周期模型有：傳統瀑布模型、瀑布V模型 、增量模型 、迭代模型。

圖1 傳統瀑布模型

圖2 瀑布V模型

增量模型：需求基本明確，第一次需求分析包括所有需求，后續階段提需求變更。

迭代模型：需求不明確，每階段需求分析只包含這一階段的需求。

03

軌交軟件測試流程、策略

3.1 軌交軟件測試的基本流程

測試計劃→測試用例→準備數據→執行測試→輸出、分析測試結果。

圖3 軌交軟件測試的基本流程

（紫色背景為執行的操作，藍色背景為輸出的文檔或過程數據）

3.2 軌交軟件測試的測試策略

需要根據不同的輸入，在不同的測試階段中，采用相適應的測試策略。如，軟件模塊設計需要在單元測試階段進行測試。軟件結構設計需要集成測試進行測試，并對該階段的文檔進行驗證。對于軟件的需求，需要軟件確認測試活動進行確認測試。系統結構設計，以及多個子系統集成，在系統集成階段集成驗證。系統需求需要進行系統級的確認測試，對其驗證和確認。

圖4 軌交軟件各測試階段的測試策略

3.3 各測試階段輸出的測試文件

圖5 各測試階段輸出的測試文件

3.4 測試缺陷管理與跟蹤

測試中發現的缺陷可能是代碼缺陷，也可能是文檔缺陷。對于文檔缺陷，測試人員仍按照與預期的差異提交CR，由分析人員進行分析，明確修改文檔。如果是代碼缺陷，需要按照流程，修改代碼，重新發布代碼。對于回歸測試，如果有影響分析報告，本次回歸的用例范圍應不少于影響分析所要求的范圍。

測試過程中，應嚴格按照用例的預期結果判斷用例是否通過。如果執行測試中發現用例有誤或步驟需要細化或需要增加步驟，可以對用例修改，但在測試報告中，測試用例的版本為新版本，確保測試執行與實際用例版本一致。

3.5 白盒測試和黑盒測試的區別

白盒測試又叫邏輯驅動測試，具備以下特點：已知程序的內部工作邏輯；基于程序邏輯結構設計和構造測試用例和測試數據；測試程序內部的變量狀態、邏輯結構、運行路徑等；檢驗每條路徑是否按預定要求正確工作；檢查程序內部動作或運行是否符合設計規格要求。

黑盒測試的特點：不考慮程序的內部工作邏輯；從用戶角度出發；基于程序應實現的功能和定義好的需求規格設計測試用例和測試數據；驗證功能是否實現且與需求一致。

黑盒測試設計方法：等價類劃分（EP）、邊界值分析（BVA）、錯誤猜測（EG）、因果圖等。

04

軟件測試常用的幾個階段

4.1 單元測試

單元測試包括動態測試、代碼審核和代碼走讀。

動態測試是通過插樁和驅動，動態運行程序的最小組成單位（一般是函數），驗證函數是否與模塊設計文檔定義的功能一致。動態測試依據軟件詳細設計規格書進行。

代碼審核是利用工具或人工，檢查代碼是否滿足定義的編碼規則。

代碼走讀是通過人工閱讀代碼，檢查代碼中的邏輯錯誤或對結構優化提出改進。代碼走讀的形式可以是小組評審或純粹個人讀代碼。

圖6 單元測試動態測試

模塊接口：驗證數據能否正確的輸入、輸出；

邊界條件：邊界上出現的錯誤是很常見的；

覆蓋條件：或稱路徑分析，即對執行的基本路徑和循環進行測試；

出錯處理：良好的設計應該估計到投入使用后可能發生的錯誤，并給出相應的處理措施，保證邏輯上的正確性。

測試用例設計遵循：基于結構化測試（白盒）原則設計足夠的測試，達到要求的覆蓋率（語句覆蓋；判定覆蓋；條件覆蓋；判定/條件覆蓋；條件組合覆蓋；路徑覆蓋）

推薦：首先設計黑盒測試用例，然后分析代碼，從白盒角度分析，根據覆蓋率要求增減測試用例。

注意：在實踐中存在不好的傾向，單元測試人員純粹為了完成覆蓋率目標，不去理解被測模塊實現的功能，僅從白盒角度建立測試用例，往往不能發現模塊功能性的錯誤。

4.2 軟件集成測試

在單元測試的基礎上，根據選擇的集成方式，將模塊或任務或線程組裝，驗證被集成對象之間消息傳遞是否正確（必要時需要通過插樁來驗證）。

本測試依據軟件結構設計規格書進行。測試的對象是模塊間的接口、函數調用接口、消息接口、共享隊列、文件等。集成的對象可以根據實際情況分析后確定，可以是函數之間集成，也可以是任務或線程之間集成。

軟件集成測試的方式：大爆炸集成(Big-bang integration)；自頂向下集成(Top-down integration)；自底向上集成(Bottom-up integration)。

圖7 大爆炸集成

大爆炸集成 (Big-bang integration)：也叫非增量式集成。其優點：不需要插樁與驅動；缺點：不容易定位問題。

圖8 自頂向下集成

深度優先：M1-M2-M5-M8；M1-M2-M5-M8-M6；M1-M2-M5-M8-M6 -M3-S7；M1-M2-M5-M8-M6-M3-S7-S4。

寬度優先：M1-M2-M3-S4；M1-M2-M3-S4-M5-M6-S7；M1-M2-M3-S4-M5-M6-S7-M8。

優點：一開始就能看到系統的框架；

缺點：需要插樁，樁不能反映真實情況，所以測試可能不充分，且在樁中查看輸出不方便。

圖9 自底向上集成

自底向上集成 (Bottom-up integration)：屬于增量式集成。其優點：方便查看輸出。關鍵模塊在底部時，這種方式更有優越性。缺點：要在最后才能看到系統的框架。

執行集成測試的建議：核心任務應執行模塊級別的集成；非核心任務可只執行任務之間或進程之間的集成；集成測試以接口測試為主，功能測試為輔；集成策略采用大爆炸方式還是增量式集成方式視情況而定；集成測試集成的模塊可以是以線程為單位，或者以功能模塊為單位，或者以接口為單位或者以函數為單位。

需要工具支持：模塊集成可使用相應的白盒測試工具；任務/進程集成應使用協議分析軟件或邏輯分析儀、示波器等硬件測試分析設備。

4.3 軟件確認測試

將已經集成好的軟件，作為整個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他軟件元素結合在一起，在實際運行環境下，對軟件進行一系列的組裝和確認測試。

本測試依據軟件需求規格書進行。

圖10 軟件確認測試

安全測試（Safety Test）：驗證軟件是否會產生危險輸出，比如聯鎖軟件中如果板卡位置放置錯誤，軟件應宕機。

恢復性測試（Recovery Test）：人為使軟件出錯，檢查軟件是否能自動恢復，及自動恢復時初始化、參數等是否正確。

備份測試（Backup Test）：驗證軟件能夠自動進行數據備份。

GUI測試：界面顯示，是否友好

健壯性測試（Robust Test），也叫容錯性測試。忽略故障，繼續運行。比如，聯鎖備機故障不影響軟件輸出；聯鎖主機故障時，備機升級為主機，整個軟件仍能正確輸出。

安裝測試（Installation Test）：驗證是否能夠根據安裝說明書完成安裝，安裝過程中是否有合理的提示信息，是否對安裝環境有限制。驗證是否可以卸載。

4.4 系統集成測試

驗證各子系統的獨立功能及其接口、數據傳輸的正確性，滿足整個系統設計所規定的特性。該測試依據系統結構設計進行。

圖 11 系統集成測試

4.5 系統確認測試

功能測試 （Functional Test）：驗證功能實現是否符合軟件需求。

性能測試（Performance Test）：特定負荷下，CPU，網絡，內存，系統反應時間，指令執行時間等。

壓力測試（Stress Test）：也叫強度測試。資源超負荷（比如用戶），驗證系統能承受的最大壓力、找到系統在哪里失效及如何失效。

容量測試（Volume Test）：超額的數據容量，驗證系統的最大容量，一般和數據庫有關。

安全性測試（Security Test）：防范非法侵入。

安全測試（Safety Test）：驗證系統是否會產生危險輸出，比如聯鎖系統中如果板卡位置放置錯誤，系統應宕機。

恢復性測試（Recovery Test）：人為使軟件出錯，檢查系統是否能自動恢復，及自動恢復時初始化、系統參數等是否正確。

備份測試（Backup Test）：驗證系統能夠自動進行數據備份。

GUI測試：界面顯示，是否友好。

健壯性測試（Robust Test），也叫容錯性測試。忽略故障，繼續運行。比如，聯鎖系統備機故障不影響系統輸出；聯鎖主機故障時，備機升級為主機，整個系統仍能正確輸出。

4.6 驗收測試

最后正式將被測系統放到實際運行環境運行之前，完全真實的環境和操作過程，不使用任何模擬設備或模擬程序。本測試在現場進行。

05

總 結

軌交軟件系統大多采用瀑布V模型的生命周期模型，因涉及到需求分析、概要設計、詳細設計等，所以會有單元測試、集成測試、軟件系統測試對應各個階段的輸入進行驗證或確認測試。

各個階段的測試關注點不同，需要進行各種測試方法的適應性改變，如，EG的方法，在程序中植入錯誤，驗證既有測試用例是否能發現也可以驗證用例是否充分。測試用例中必須包含期望輸出，程序員應避免測試自己編寫的代碼、程序開發組織應避免測試自己編寫的代碼，徹底檢查每一個測試的結果，應為非法的、非預期的條件以及正常的、預期的條件設計測試用例，檢查程序是否執行了指定的行為只是測試的一部分，還應檢查程序是否執行了未指定的行為，這些是在設計用例、執行測試過程中的注意點，分別從獨立性、充分性等方面考慮。

審核編輯 黃宇