作者 |劉艷青上海控安安全測評部測試經(jīng)理

版塊 |鑒源論壇· 觀通

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

01

什么是軟件測試

1.1 測試的定義

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

“測試的目的是為了顯示一個程序正確的實現(xiàn)了預(yù)期的功能”

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

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

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

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

1.2 軟件測試的目的

驗證軟件的所有構(gòu)件是否正確集成；驗證所有需求是否已經(jīng)正確實現(xiàn)；發(fā)現(xiàn)缺陷并確保在部署軟件之前將缺陷解決。

1.3 軟件測試的意義

測試在開發(fā)總成本中占30-50%；保證程序的正確性、完整性和一致性；顯著降低完成和維護(hù)軟件的開支；大大降低部署質(zhì)量低劣的軟件相關(guān)的責(zé)任或風(fēng)險。

02

軟件生命周期

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

圖1 傳統(tǒng)瀑布模型

圖2 瀑布V模型

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

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

03

軌交軟件測試流程、策略

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

測試計劃→測試用例→準(zhǔn)備數(shù)據(jù)→執(zhí)行測試→輸出、分析測試結(jié)果。

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

（紫色背景為執(zhí)行的操作，藍(lán)色背景為輸出的文檔或過程數(shù)據(jù)）

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

需要根據(jù)不同的輸入，在不同的測試階段中，采用相適應(yīng)的測試策略。如，軟件模塊設(shè)計需要在單元測試階段進(jìn)行測試。軟件結(jié)構(gòu)設(shè)計需要集成測試進(jìn)行測試，并對該階段的文檔進(jìn)行驗證。對于軟件的需求，需要軟件確認(rèn)測試活動進(jìn)行確認(rèn)測試。系統(tǒng)結(jié)構(gòu)設(shè)計，以及多個子系統(tǒng)集成，在系統(tǒng)集成階段集成驗證。系統(tǒng)需求需要進(jìn)行系統(tǒng)級的確認(rèn)測試，對其驗證和確認(rèn)。

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

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

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

3.4 測試缺陷管理與跟蹤

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

測試過程中，應(yīng)嚴(yán)格按照用例的預(yù)期結(jié)果判斷用例是否通過。如果執(zhí)行測試中發(fā)現(xiàn)用例有誤或步驟需要細(xì)化或需要增加步驟，可以對用例修改，但在測試報告中，測試用例的版本為新版本，確保測試執(zhí)行與實際用例版本一致。

3.5 白盒測試和黑盒測試的區(qū)別

白盒測試又叫邏輯驅(qū)動測試，具備以下特點：已知程序的內(nèi)部工作邏輯；基于程序邏輯結(jié)構(gòu)設(shè)計和構(gòu)造測試用例和測試數(shù)據(jù)；測試程序內(nèi)部的變量狀態(tài)、邏輯結(jié)構(gòu)、運行路徑等；檢驗每條路徑是否按預(yù)定要求正確工作；檢查程序內(nèi)部動作或運行是否符合設(shè)計規(guī)格要求。

黑盒測試的特點：不考慮程序的內(nèi)部工作邏輯；從用戶角度出發(fā)；基于程序應(yīng)實現(xiàn)的功能和定義好的需求規(guī)格設(shè)計測試用例和測試數(shù)據(jù)；驗證功能是否實現(xiàn)且與需求一致。

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

04

軟件測試常用的幾個階段

4.1 單元測試

單元測試包括動態(tài)測試、代碼審核和代碼走讀。

動態(tài)測試是通過插樁和驅(qū)動，動態(tài)運行程序的最小組成單位（一般是函數(shù)），驗證函數(shù)是否與模塊設(shè)計文檔定義的功能一致。動態(tài)測試依據(jù)軟件詳細(xì)設(shè)計規(guī)格書進(jìn)行。

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

代碼走讀是通過人工閱讀代碼，檢查代碼中的邏輯錯誤或?qū)Y(jié)構(gòu)優(yōu)化提出改進(jìn)。代碼走讀的形式可以是小組評審或純粹個人讀代碼。

圖6 單元測試動態(tài)測試

模塊接口：驗證數(shù)據(jù)能否正確的輸入、輸出；

邊界條件：邊界上出現(xiàn)的錯誤是很常見的；

覆蓋條件：或稱路徑分析，即對執(zhí)行的基本路徑和循環(huán)進(jìn)行測試；

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

測試用例設(shè)計遵循：基于結(jié)構(gòu)化測試（白盒）原則設(shè)計足夠的測試，達(dá)到要求的覆蓋率（語句覆蓋；判定覆蓋；條件覆蓋；判定/條件覆蓋；條件組合覆蓋；路徑覆蓋）

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

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

4.2 軟件集成測試

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

本測試依據(jù)軟件結(jié)構(gòu)設(shè)計規(guī)格書進(jìn)行。測試的對象是模塊間的接口、函數(shù)調(diào)用接口、消息接口、共享隊列、文件等。集成的對象可以根據(jù)實際情況分析后確定，可以是函數(shù)之間集成，也可以是任務(wù)或線程之間集成。

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

圖7 大爆炸集成

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

圖8 自頂向下集成

深度優(yōu)先：M1-M2-M5-M8；M1-M2-M5-M8-M6；M1-M2-M5-M8-M6 -M3-S7；M1-M2-M5-M8-M6-M3-S7-S4。

寬度優(yōu)先：M1-M2-M3-S4；M1-M2-M3-S4-M5-M6-S7；M1-M2-M3-S4-M5-M6-S7-M8。

優(yōu)點：一開始就能看到系統(tǒng)的框架；

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

圖9 自底向上集成

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

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

需要工具支持：模塊集成可使用相應(yīng)的白盒測試工具；任務(wù)/進(jìn)程集成應(yīng)使用協(xié)議分析軟件或邏輯分析儀、示波器等硬件測試分析設(shè)備。

4.3 軟件確認(rèn)測試

將已經(jīng)集成好的軟件，作為整個元素，與計算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他軟件元素結(jié)合在一起，在實際運行環(huán)境下，對軟件進(jìn)行一系列的組裝和確認(rèn)測試。

本測試依據(jù)軟件需求規(guī)格書進(jìn)行。

圖10 軟件確認(rèn)測試

安全測試（Safety Test）：驗證軟件是否會產(chǎn)生危險輸出，比如聯(lián)鎖軟件中如果板卡位置放置錯誤，軟件應(yīng)宕機(jī)。

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

備份測試（Backup Test）：驗證軟件能夠自動進(jìn)行數(shù)據(jù)備份。

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

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

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

4.4 系統(tǒng)集成測試

驗證各子系統(tǒng)的獨立功能及其接口、數(shù)據(jù)傳輸?shù)恼_性，滿足整個系統(tǒng)設(shè)計所規(guī)定的特性。該測試依據(jù)系統(tǒng)結(jié)構(gòu)設(shè)計進(jìn)行。

圖 11 系統(tǒng)集成測試

4.5 系統(tǒng)確認(rèn)測試

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

性能測試（Performance Test）：特定負(fù)荷下，CPU，網(wǎng)絡(luò)，內(nèi)存，系統(tǒng)反應(yīng)時間，指令執(zhí)行時間等。

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

容量測試（Volume Test）：超額的數(shù)據(jù)容量，驗證系統(tǒng)的最大容量，一般和數(shù)據(jù)庫有關(guān)。

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

安全測試（Safety Test）：驗證系統(tǒng)是否會產(chǎn)生危險輸出，比如聯(lián)鎖系統(tǒng)中如果板卡位置放置錯誤，系統(tǒng)應(yīng)宕機(jī)。

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

備份測試（Backup Test）：驗證系統(tǒng)能夠自動進(jìn)行數(shù)據(jù)備份。

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

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

4.6 驗收測試

最后正式將被測系統(tǒng)放到實際運行環(huán)境運行之前，完全真實的環(huán)境和操作過程，不使用任何模擬設(shè)備或模擬程序。本測試在現(xiàn)場進(jìn)行。

05

總 結(jié)

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

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

審核編輯 黃宇