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

版塊 |鑒源論壇· 觀通

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

01

軟件開發過程簡介

基本活動：為了保證開發能夠實現任務的要求而必須完成的工作活動。

支持活動：為了保證開發過程按照既定的體系要求而開展的管理活動。

其他管理活動：為了確保軟件開發過程的風險、保密、安全，與利益相關方、體系持續改進等工作而需要實施的管理活動。

圖 1

項目策劃：

承辦方接收到交辦方的軟件研制任務書時為軟件立項，應為實施本規范所要求的活動和軟件研制任務書中其他有關軟件需求所要求的各項活動制定軟件開發計劃。該計劃應與系統級策劃一致，計劃應以軟件項目估計為基礎。計劃包括估計工作產品和任務的屬性，確定需要的資源，協商承諾，產生進度表，以及標識和分析項目風險，制定測量、數據管理、評審、和利益相關方的協調計劃等。

為了制定軟件開發計劃可能有必要反復進行這些活動。根據軟件開發計劃提供實施和控制軟件項目活動的基礎，而軟件項目活動處理對項目交辦方的承諾。項目進行中，軟件開發計劃常因下列情況而需修訂：需求和承諾更改、不準確的估計、糾正措施和過程更改。

其結果為承辦方負責完成的軟件開發計劃，開發計劃中應包括估計報告。軟件質量保證計劃和軟件配置管理計劃一般合并在軟件開發計劃中，必要時，可以分別編制，但應在軟件開發計劃中說明理由。

支持活動：

a) 軟件配置管理；

b) 軟件產品評價；

c) 軟件質量保證；

d) 糾正措施；

e) 評審；

f) 測量與分析。

其他管理活動：

a) 風險管理；

b) 保密有關活動；

c) 分承辦方管理（即分承制方管理）；

d) 與獨立驗證和確認機構的聯系；

e) 與相關開發方的協調；

f) 項目過程的改進。

這些活動可以重疊或迭代應用，不必按上面列出的次序執行。針對具體軟件，可對這些活動進行裁剪，軟件開發過程及對這些活動進行的裁剪，各單位組織級應制定裁剪指南，項目級應在軟件開發計劃中描述。

02

軟件內部測試

2.1 如何做軟件內部測試

Why：

軟件測試的目的是為了節省后期修改軟件問題資金和進度。

第一，是為了確認軟件的質量是否滿足設計要求，一方面是為了確認軟件做了期望做的事情；另一方面是確認軟件是否以正確的方式來做了事情；（做了三級中規定的驗證和確認的測試部分的工作）；

第二，提供質量信息，為開發組提供質量相關信息；

第三，對軟件和開發進行評價。

When：

軟件測試一般是在完成軟件實現后進行測試，但根據具體實施，最佳實踐是在軟件實現過程中完成了產品模塊的編碼后，及時進行測試工作能有效提高軟件測試效率，集成測試工作可結合軟件代碼。

What：

軟件測試就是為了驗證和確認軟件是否按照設計要求完成了既定的要求。

Who：

單元測試和集成測試工作一般由軟件開發人員進行驗證工作，配置項合格性測試和系統合格性測試一般由專業的測試隊伍進行軟件測試，配置項合格性測試由項目開發團隊的測試組織進行，系統合格性測試一般由軟件任務下達方組織實施。

How：

單元測試一般要開展代碼審查、靜態分析、邏輯測試、功能測試、邊界測試；

集成測試一般要開展功能測試、接口測試和邏輯測試；

配置項合格性測試一般要開展文檔審查、代碼審查、靜態分析、功能測試、性能測試、接口測試和余量測試、邊界測試、人機界面測試、安全性測試、恢復性測試和安裝性測試等；系統合格性測試要求和配置項合格性測試的類型基本一致。

圖 2

2.2 測試的工作流程

確定測試的對象和測試目的 →明確測試依據 →確定進入時機 →確定測試類型和測試策略 →規范測試步驟 →明確測試的技術要求 →建立結束準則 →確定測試工作產品。

03

單元測試技術的要求

3.1 總體要求

a）應建立測試軟件單元的環境，如樁模塊和驅動模塊；

b）對軟件設計文檔規定的軟件單元的功能、性能、接口等逐項進行測試；

c）軟件單元的每個特性應至少被一個正常測試用例和一個異常測試用例覆蓋；

d）測試用例的輸入應至少包括有效等價類值、無效等價類值和邊界數據值；

e）滿足語句覆蓋率要達到100％的要求；

f）滿足分支覆蓋率要達到100％的要求；

g）滿足輸出數據及其格式的要求。

3.2 單元測試-代碼審查的要求

a）代碼審查應是人工閱讀代碼的結果，可以借助輔助工具予以輔助分析，但不應以工具掃描結果作為代碼審查結果；

b）代碼審查的內容包括：程序代碼的控制流程、數據處理是否滿足設計要求；程序代碼的編程語言使用是否正確、規范、安全、可靠；程序代碼是否滿足軟件可靠性安全性設計準則的相關要求；

c）代碼審查應建立代碼審查單，依據使用語言、軟件特點，細化代碼審查內容，檢查的內容包括：命名規則檢查、代碼格式檢查、內存使用檢查、表達式判斷邏輯檢查、程序可讀性檢查、程序多余物檢查、寄存器使用情況檢查等內容。

表 1

3.3 單元測試-靜態分析的要求

靜態分析應明確分析工具的名稱和版本。

靜態分析的內容包括：程序結構分析；數據結構分析；控制流程分析；程序質量度量。

靜態分析結果的使用：為代碼審查提供必要的信息為單元測試提供必要的信息；提供程序代碼質量度量信息。

質量度量指標要求：模塊的平均圈復雜度不大于10模塊圈復雜度大于20的比例不大于20%；模塊最大圈復雜度不大于80；源程序的總注釋率不小于20%模塊的平均規模不大于200行。

根據軟件編程語言的具體特點開展控制流分析、數據流分析、表達式分析。

表 2

3.4 單元測試—邏輯測試

a）語句覆蓋率（SC）測試；

b）分支覆蓋率（DC）測試；

邏輯測試主要通過動態運行測試用例，統計測試用例的運行路徑，計算覆蓋率。

語句覆蓋率是指在運行完成所有設計的測試用例后，軟件程序對每一條語句的覆蓋百分比；

注：語句覆蓋率 = （至少被執行一次的語句數量）/（可執行的語句總數）

分支覆蓋率是指在運行完成所有設計的測試用例后，使得程序中每個判斷至少取真分支和假分支一次，即判斷的真假值均曾被滿足的百分比。

注：分支覆蓋率=（判定結果被評價的次數）/（判定結果的總數）

3.5 單元測試—結束準則

a）軟件功能與設計說明一致；

b）控制流程正確；

c）語句覆蓋率和分支覆蓋率達到規定的覆蓋率；

d）質量保證完成對內部測試的文檔、程序是否符合規范的要求等符合性檢查；

e）單元測試文檔、代碼等配置項進入受控庫管理。

04

總 結

本文從為什么要做測試、什么時候是合適的介入測試的時機、如何做單元測試幾個方面介紹了測試技術。測試不是一蹴而就，也不是可以跟著理論走一遍下了，就可以很好地做好測試這門技術。需要測試人員結合測試理論，系統全面地了解項目，多方面地挖掘測試本身的側重點，結合項目的實際，挖掘項目自身的風險點。

審核編輯 黃宇