軌交軟件測試過程管理

作者 |劉艷青上?？匕舶踩珳y評(píng)部測試經(jīng)理

版塊 |鑒源論壇· 觀通

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

01

什么是軟件測試

1.1 測試的定義

“測試是一個(gè)證明錯(cuò)誤不存在的過程”

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

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

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

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

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

1.2 軟件測試的目的

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

1.3 軟件測試的意義

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

02

軟件生命周期

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

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

圖2 瀑布V模型

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

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

03

軌交軟件測試流程、策略

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

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

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

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

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

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

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

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

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

3.4 測試缺陷管理與跟蹤

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

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

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

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

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

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

04

軟件測試常用的幾個(gè)階段

4.1 單元測試

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

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

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

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

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

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

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

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

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

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

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

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

4.2 軟件集成測試

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

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

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

圖7 大爆炸集成

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

圖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)點(diǎn)：一開始就能看到系統(tǒng)的框架；

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

圖9 自底向上集成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.6 驗(yàn)收測試

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

05

總 結(jié)

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

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

審核編輯 黃宇