ICS35.240.01

CCSJ28

CRSS

重慶市機器人學會團體標準

T/CRSSXXXX—XXXX

服務機器人軟件試驗方法

Servicerobots-Softwaretestingmethod

（征求意見稿）

在提交反饋意見時，請將您知道的相關專利連同支持性文件一并附上。

XXXX-XX-XX發布XXXX-XX-XX實施

重慶市機器人學會發布

T/CRSSXXXX—XXXX

服務機器人軟件試驗方法

1范圍

本文件規定了服務機器人軟件試驗方法的術語和定義、技術要求、試驗條件和試驗方法。主要的技

術內容有測試對象的安全性等級要求、測試目的、測試內容、測試級別、測試方法、測試過程、測試用

例、測試管理、文檔編寫和測試工具，從而實現對機器人軟件測試與評估。

本文件適用于服務機器人軟件測試與評估。

2規范性引用文件

下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，

僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本

文件。

GB/T12643—2013機器人與機器人裝備詞匯

GB/T25000.10—2016系統與軟件工程系統與軟件質量要求和評價(SQuaRE)第10部分：系統與

軟件質量模

GB/T25000.51—2016系統與軟件工程系統與軟件質量要求和評價(SQuaRE)第51部分：就緒可

用軟件產品（RUSP）的質量要求和測試細則

GB/T38260—2019服務機器人功能安全評估

GB/T38634—2020系統與軟件工程軟件測試

3術語和定義

下列術語和定義適用于本文件。

機器人robot

具備一定程度的自主能力，可在其環境內運動以執行預期的任務的執行機構。

服務機器人sevicerobot

除工業自動化應用外，能為人類或設備完成有用任務的機器人。

注：工業自動化應用包括(但不限于)制造、檢驗、包裝和裝配。

注：用于生產線的關節機器人是工業機器人,而類似的關節機器人用于供餐的就是服務機器人。

[來源：GB/T12643—2013,2.10]

安全相關軟件safety-relatedsoftware

在服務機器人安全相關系統中，用于實現SRCF的軟件。

[來源：GB/T38260—2019,3.1.20]

4服務機器人軟件系統

機器人的軟件設計應與硬件資源相適應。服務機器人軟件系統應包括運行環境、驅動程序、應用

軟件，還應具備系統運行日志、數據共享接口及相應的異常檢測和處理機制，包含故障自檢和故障修復

程序等。服務機器人軟件架構通常包含但不限于以下四層。

人機交互及傳感器網絡管理層（必備）：用戶通過語音、觸摸屏、按鍵等向機器人發送指令；對

傳感器網絡進行管理。

中間服務層（必備）：將機器人低、中、高級功能封裝成相應的服務，導航規劃、任務執行、操

作動作等。

4

T/CRSSXXXX—XXXX

操作器及傳感器驅動軟件接口層（必備）：系統中各種傳感器、操作器等硬件設備的軟件接口。

中臺管理層（選配）：采集、分析單個服務機器人終端數據，也可以支持遠程控制。

服務機器人系統按功能模塊分可以包含但不限于人機交互系統、業務系統、控制系統、圖像識別

系統、運動系統、導航定位系統、環境認知系統、大數據決策系統等。

5軟件等級

軟件等級的定義

服務機器人軟件等級是在系統安全評估過程中確定的，它是根據軟件對潛在的失效狀態的貢獻率

來劃分的。軟件等級隨著失效狀態類別的變化而變化。

服務機器人軟件等級的定義如下：

a)A級：其異常狀態將會導致或引起系統功能的失效并給服務機器人、使用者及周圍環境帶來災

難性的失效狀態的軟件，如安全相關軟件；

b)B級：其異常狀態將會導致或引起系統功能的失效并給服務機器人帶來嚴重的失效狀態的軟

件；

c)C級：其異常狀態不會降低服務機器人的安全性和可操作性。

軟件等級的確定

5.2.1如果服務機器人軟件部分的異常狀態引起多個失效狀態，軟件部件中最嚴重的失效狀態類別決

定了軟件部件的軟件等級。

5.2.2系統功能可以分配到一個或多個已劃分的軟件部件中，并行實施是用多個軟件部件來實現一個

系統功能。這樣，只有多個部件的異常狀態才能產生一個失效狀態。對并行架構，至少有一個軟件部件

具有與系統功能最嚴重的失效狀態類別相應的軟件等級。

5.2.3一個系統功能亦可用多個軟件部件來串行實施。這樣，任何部件的異常狀態都能產生失效狀態。

在這種情況下，軟件部件講具有與系統功能的最嚴重的失效狀態類別相應的軟件等級。

6一般要求

測試目的

服務機器人軟件的測試目的是：

a)驗證軟件是否滿足服務機器人系統規格說明、系統設計說明、軟件需求規格說明、軟件設計說

明等規定的軟件功能、性能、接口、安全及其他特性要求；

b)通過軟件測試，盡早的發現軟件中的缺陷，通過修正各種缺陷提高軟件質量，規避軟件發布后

由于潛在的軟件缺陷造成的失效所帶來的風險。；

c)為服務機器人軟件產品確認、驗收以及軟件質量評估提供依據。

測試原則

服務機器人軟件的測試原則主要包括：

a)充分性。軟件測試應全面覆蓋軟件功能、性能、接口等需求及其他特性要求；

b)客觀性。軟件測試應采取客觀公正的態度，測試過程、人員應保持相對的獨立性；

c)追溯性。所有的測試點都可追溯到需求/用戶。

測試級別

如下測試級別的詳細描述見本文件第8章測試技術要求：

a)單元測試；

b)集成測試；

c)系統測試。

注1：回歸測試可出現在上述每個測試類別中，并貫穿于整個軟件全生命周期，單獨分類進行描述。

注2：不同類型服務機器人應完成的測試級別參考附錄C。

5

T/CRSSXXXX—XXXX

軟件等級與測試級別的關系

針對服務機器人軟件特點，A級軟件必須完成單元測試、集成測試、系統測試。B級軟件至少完成

集成測試與系統測試。C級軟件至少完成系統測試。

測試類型

應根據軟件測試目的、要求及軟件等級等特點，選取適當的測試類型，測試類型技術要求見附錄A：

a)文檔類測試。文檔審查；

b)代碼類測試。代碼審查、靜態分析；

c)數據類測試。數據處理測試；

d)功能類測試。功能測試、邊界測試、可恢復性測試；

e)性能類測試。性能測試、余量測試、強度測試、容量測試；

f)接口類測試。接口測試、人機交互界面測試；

g)專項類測試。安全性測試、可靠性測試、兼容性測試。

測試方法

從是否實際執行程序的角度，測試方法可分為動態測試和靜態測試。從是否考慮程序內部結構和內

部特性的角度，測試方法可分為白盒測試、黑盒測試和灰盒測試。

測試方法的選用及要求包括：

a)單元測試一般采用白盒測試方法，輔助以黑盒測試方法；集成測試和系統測試一般采用黑盒測

試方法，輔助以白盒測試方法；

b)測試用例設計時，應依據測試類型的特點，使用恰當的測試方法對測試用例進行分析與設計，

確保測試用例的充分性、典型性、準確性和合理性：

1)充分性。如使用功能分解法對功能測試點進行分解，分解粒度應達到恰當的細度；

2)典型性。如使用等價類劃分法設計具有代表性的測試用例，避免同類測試用例無實質意義

的機械累加；

3)準確性。如使用邊界值分析法確定邊界條件，分析邊界條件所對應的輸入數據；

4)合理性。如使用判定表法生成測試用例，保證測試用例驗證需求規格的合理性。

c)測試方法的使用結果應在測試用例中進行詳細說明，基于某測試方法生成的測試用例集，應進

行統一歸類說明；

d)基于可量化度量的測試方法生成的測試用例，其測試結果應進行量化評價。

測試過程

服務機器人軟件測試過程主要包括以下四個步驟，回歸測試應在軟件更改情況及影響域分析的基

礎上視情況執行a)~c)。

a)測試需求分析與策劃。確定需要測試的內容、測試的充分性要求，提出測試的基本方法；確定

測試的資源、技術需求；分析測試風險，制定測試計劃；進行測試計劃評審；

b)測試設計與實現。設計和選取測試用例；獲取并驗證測試數據；根據測試資源、風險等約束條

件，確定測試用例執行順序，編制測試用例；獲取測試資源，開發或選用測試工具；建立并校

準測試環境；進行測試用例評審；

c)測試執行。執行測試用例，獲取并記錄測試結果數據；分析測試過程的正常或異常終止情況，

視情補充或停止測試；對測試過程中發現的問題進行分析確認并填寫問題報告單；

d)測試總結。匯總測試數據，總結測試工作，評估測試結果，描述測試狀態；編制測試報告，進

行測試總結評審。

測試環境

服務機器人軟件測試環境通常包括被測軟件運行所需的軟件、硬件、數據、工具及接近服務機器人

真實工作外部環境，如家居環境、商場環境、酒店環境、醫院環境等。場景化測試是服務機器人測試的

重點：

6

T/CRSSXXXX—XXXX

a)不同的測試級別一般使用不同的測試環境，應保證與軟件實際運行環境的一致性或相容性。通

常，單元測試可在仿真環境下進行，集成測試、系統測試應在至少接近服務機器人真實工作環

境下進行；

b)應采取措施保證測試的軟件環境沒有被病毒感染；

c)測試環境應盡可能與開發環境分離；

d)測試環境應達到系統或軟件對安全性、保密性的需求；

e)測試環境應考慮被測軟件對設備、網絡設施等硬件環境的適應能力，以及對系統軟件、其他并

行使用的應用軟件等軟件環境的適應能力；

f)當測試環境與實際環境存在差異時，應進行差異性分析，說明在該環境下測試結果的有效性；

g)應根據測試要求選用測試工具，包括采購商用測試工具和自行開發測試工具；

h)對測試結果有重要影響的測試數據、有指標要求的測試工具，在投入使用前應采用適當的方法

對其是否符合測試要求進行校核、確認；

i)應對測試工具實施管理，包括版本控制、升級以及技術支持；

j)在測試執行前應對測試環境進行校核，在測試過程中應對測試環境進行管理和維護。

軟件問題分級分類及處理

6.9.1軟件問題后果

軟件中的錯誤可能導致故障的出現，產生服務機器人失效狀態。

6.9.2軟件問題分類

軟件測試過程中發現的問題可分為：

a)需求問題。產品定義或需求問題；

b)設計問題。系統設計或軟件設計問題；

c)文檔問題。文檔描述問題；

d)編碼問題。代碼實現問題；

e)數據問題。數據規格及內容問題；

f)其他問題。上述問題之外的問題。

6.9.3問題等級

軟件問題分為災難、嚴重、一般、改進建議四個等級：

a)災難問題。將會造成服務機器人失去控制并對周圍環境造成破壞或對人造成傷害。

1)導致系統死機、崩潰或異常退出；

2)主要功能未實現或實現錯誤；

3)造成人員、設備、環境等重大損失；

4)重要數據丟失，且很難恢復。

b)嚴重問題。將會降低服務機器人功能水平大幅下降。

1)沒有完整實現軟件需求，對主要功能性能等有較大影響；

2)沒有正確實現軟件需求，對主要功能性能等有較大影響；

3)造成環境等嚴重損失；

4)重要數據丟失，但能以某種方式恢復；

5)軟件文檔對主要功能、性能描述缺失或錯誤。

c)一般問題。不會降低服務機器人的安全性和可操作性，軟件問題對軟件功能性能有較小影響。

1)沒有完整實現軟件需求，對軟件主要功能性能影響較小，或對一般功能性能造成影響；

2)沒有正確實現軟件需求，對軟件主要功能性能影響較小，或對一般功能性能造成影響；

3)軟件操作與軟件使用說明不符；

4)軟件文檔存在準確性、一致性、錯別字等影響較小的問題。

d)改進建議。測試過程中發現的對軟件功能有輕微影響的問題可提出改進建議。

6.9.4問題處理

7

T/CRSSXXXX—XXXX

在軟件測試過程中應如實記錄測試過程、原始數據、結果及發現的故障現象，填寫軟件問題報告單：

a)測試人員應與開發人員共同確認發現的軟件問題；

b)開發人員應對問題進行定位，開展原因分析，提出修改措施，說明修改對軟件的影響，如不修

改，應說明理由及其影響，在回歸測試前提交給測試方；

c)對測試中有爭議的問題，應組織利益相關方及領域專家共同確認。

測試文檔

軟件測試過程中的文檔主要包括(參見附錄B)：

a)軟件測試計劃；

b)軟件測試用例及測試記錄；

c)軟件問題單；

d)軟件測試報告；

e)其他管理文檔和記錄，如：評審、質量保證、項目跟蹤以及配置管理等記錄和報告。

7測試過程

測試需求分析與策劃

7.1.1過程輸入

開展軟件測試需求分析與策劃活動的輸入應包括：

a)軟件測試任務書、合同或其他等效文件；

b)軟件開發文檔，例如，系統需求說明、接口需求說明、系統設計說明、接口設計說明、軟件研

制任務書、軟件需求規格說明、軟件設計說明、軟件用戶手冊、數據庫設計說明等；

c)軟件更改及影響分析報告（必要時）；

d)軟件源程序；

e)軟件運行資源。

7.1.2過程輸出

軟件測試需求分析與策劃階段輸出的主要產品為軟件測試計劃。

7.1.3過程要求

軟件測試需求分析與策劃要求一般包括：

a)測試需求分析。根據輸入信息分析測試需求并確定以下內容：

1)確定測試級別；

2)確定測試充分性要求。根據被測軟件的重要性、測試目標和約束條件，確定測試范圍及每

一范圍所要求的覆蓋程度；

3)確定測試需求。分析被測軟件的功能、性能、接口、數據結構、設計約束等，包括隱含需

求及特殊需求；

4)根據測試需求確定測試類型及其測試點；

5)分析并確定測試環境需求。

b)測試策劃。根據測試需求分析結果策劃測試活動，確定以下內容：

1)確定測試資源要求，包括人員、設備、設施等；

2)確定測試策略、技術和方法，包括測試環境搭建策略、集成測試策略、采用的標準或非標

準測試方法以及測試數據生成和驗證方法、測試數據注入方法、測試結果捕獲方法及分析

方法、使用的測試工具、動靜態測試先后順序等；

3)確定測試結束條件；

4)確定被測軟件的評價準則和方法；

5)根據任務要求、資源、風險、測試充分性等因素確定測試進度；

6)分析測試風險及應對措施，例如，技術風險、人員風險、資源風險和進度風險等；

7)確定測試點目跟蹤與控制、配置管理和質量保證等要求。

8

T/CRSSXXXX—XXXX

c)編寫軟件測試計劃；

d)軟件測試計劃應受到變更控制和版本控制。

測試設計與實現

7.2.1過程輸入

開展軟件測試設計與實現的輸入應包括但不限于以下內容：

a)軟件測試計劃；

b)軟件開發文檔，例如，系統規格說明、接口需求規格說明、軟件需求規格說明、系統設計說明、

接口設計說明、數據庫設計說明、軟件設計說明、軟件用戶手冊等；

c)軟件源程序、可執行文件及軟件運行所依賴的數據；

d)軟件運行的硬件環境；

e)系統運行的場景。

7.2.2過程輸出

軟件測試設計與實現階段輸出應包括：

a)軟件測試用例；

b)軟件測試數據；

c)自行開發的測試程序、軟硬件工具；

d)仿真或真實的服務機器人運行場景。

7.2.3過程要求

軟件測試設計與實現的要求一般包括：

a)對所有測試點或測試子項設計測試用例，并進行標識；

b)根據測試資源、風險等約束條件確定測試用例/典型實例執行順序；

c)針對測試輸入要求，設計測試數據，準備和驗證測試數據；

d)準備測試資源，例如，測試工具、搭建測試環境所必須的軟硬件資源，必要時，開發測試執行

所需測試程序、軟硬件工具；

e)建立和校核測試環境，記錄校核結果，說明測試環境的偏差及對測試結果的影響；

f)編寫軟件測試用例，確定軟件測試用例與軟件測試計劃的追蹤關系；

g)應對該階段工作產品進行評審；

h)軟件測試用例、測試程序應受到變更控制和版本控制。

測試執行

7.3.1過程輸入

開展軟件測試執行活動的輸入應至少包括：

a)通過評審的軟件測試計劃、軟件測試用例；

b)已建立并通過驗證的測試環境、測試數據、測試工具等；

c)被測軟件已納入配置管理。

7.3.2過程輸出

軟件測試實施階段輸出應包括：

a)軟件測試記錄；

b)軟件問題報告。

7.3.3過程要求

軟件測試執行的要求一般包括：

a)靜態測試一般先于動態測試執行；

b)文檔審查、代碼審查應按照審查單要求逐項進行，記錄審查情況、存在的問題等信息；

9

T/CRSSXXXX—XXXX

c)應按照軟件測試用例的內容和要求執行測試用例，如實、具體、完整地記錄測試輸入數據、測

試結果，當測試結果有量值要求時，應準確記錄實際的量值；

d)根據每個測試用例的期望測試結果、實際測試結果和評估準則，分析并判定測試結果；

e)在執行測試的過程中，可根據測試的進展情況補充測試用例，必要時變更軟件測試計劃；

f)當所有的測試用例執行完畢，應對測試的充分性進行分析。如果發現測試工作不足，或測試未

達到預期要求時，可增加新的測試用例或測試數據，直到達到充分性要求；

g)原始記錄應有簽署，并受到嚴格管理；

h)匯總測試中有異議的問題，組織問題確認評審。

測試總結

7.4.1過程輸入

開展軟件測試總結的輸入應包括：

a)軟件測試任務書、合同或其他等效文件；

b)被測軟件相關文檔、代碼和數據；

c)測試文件，包括軟件測試計劃、軟件測試用例及測試記錄、軟件問題報告、軟件回歸測試方案

（如需要）。

7.4.2過程輸出

軟件測試總結階段輸出為軟件測試報告。

7.4.3過程要求

軟件測試總結的要求一般包括：

a)分析和評價測試工作，一般包括：

1)總結軟件測試計劃和軟件測試用例的變化情況及其原因；

2)分析測試工作完成情況，包括回歸測試；

3)分析測試環境與軟件實際運行環境之間的差異及其對測試結果的影響；

4)對測試異常終止情況，分析未能被測試活動充分覆蓋的范圍及其理由。

b)分析和評價被測軟件，一般包括：

1)說明被測軟件對研制任務書等文檔規定的軟件功能、性能、接口及質量特性等要求的滿足

情況；

2)統計并分析所發現的軟件問題，對遺留的軟件問題說明不能解決的理由，給出其可能給軟

件和系統帶來的影響，可能時，推薦糾正方案或方法；

3)分析軟件設計、代碼中可能存在的缺陷和風險；

4)根據測試結果評估被測軟件，給出評估意見和改進建議。

c)分析測試產生的數據和文檔，積累測試資產，一般包括：典型軟件問題、典型用例、測試腳本、

管理數據（如生產率、工作量、進度等）；

d)編制軟件測試報告；

e)應進行測試總結評審；

f)軟件測試報告應受到變更控制和版本控制。

8測試技術要求

單元測試

8.1.1測試對象

單元測試的對象是具有輸入/輸出、完成特定功能、可被調用使用的最小代碼集合的軟件單元。在

編程語言中，通常將一個函數、一個模塊、一個過程、一個子程序視為一個軟件單元。

8.1.2測試目的

10

T/CRSSXXXX—XXXX

驗證軟件單元是否實現了軟件設計規定的功能、性能、接口和其他設計約束等要求，發現單元內可

能存在的錯誤，并保證代碼質量。

8.1.3開始條件

單元測試進入條件如下：

a)軟件單元代碼無錯誤地通過編譯；

b)具備滿足要求的測試環境及測試工具。

8.1.4技術要求

具體要求如下：

a)單元測試應列表說明被測單元的清單，對單元的剪裁應說明理由，關鍵單元、重要單元不允許

被剪裁；

b)單元測試的直接依據應是詳細設計文檔（軟件設計說明中的詳細設計部分），被測單元清單中

應說明文檔依據的索引；

c)應采用靜態測試和動態白盒測試的測試方法開展單元測試；

d)一般應在動態測試前開展靜態測試，靜態測試發現的問題修改后再進行動態測試；

e)在動態測試中，應設計測試用例逐項驗證軟件單元的功能、性能、接口等設計要求；

f)測試用例的輸入應覆蓋單元接口輸入變量的有效值、無效值和邊界值；

g)單元測試覆蓋率要求如下：

所有單元的語句覆蓋率和分支覆蓋率應達到80%及以上。

h)對于覆蓋率未達到指標要求的單元，應說明原因，并通過代碼審查進行輔助驗證。

8.1.5環境要求

要求如下：

a)應建立單元測試環境，配備軟件單元測試工具；

b)單元測試環境可以是仿真環境、模擬環境、開發環境（推薦）；

c)單元測試環境應支持驅動模塊和樁模塊的編寫與加載，并與測試用例一起進行有效管理。

集成測試

8.2.1測試對象

a)任意一個軟件單元及與其接口相連的其他軟/硬件集成得到的局部系統及其集成過程。

b)任意一個組裝得到的軟件系統。

8.2.2測試目的

軟件集成測試的目的是檢驗軟件單元之間、軟件單元和已集成的軟件系統之間的接口關系，并驗證

已集成軟件系統是否符合設計要求。

8.2.3開始條件

集成測試進入條件如下：

a)軟件已納入軟件配置管理，所涉硬件技術狀態受控；

b)具備與被測軟件源代碼版本對應的文檔；

c)具備滿足要求的測試環境。

8.2.4技術要求

軟件集成測試一般應符合以下技術要求：

a)應采用適合的集成測試策略，使系統中所有的軟件和硬件都被集成和測試；

b)應對已集成軟件進行必要的靜態測試，并先于動態測試進行；

c)軟件要求的每個特性應被至少一個正常的測試用例和一個被認可的異常測試用例覆蓋；

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

11

T/CRSSXXXX—XXXX

e)應測試運行條件（如數據結構、輸入/輸出通道容量、內存空間、調用頻率等）在邊界狀態下，

進而在人為設定的狀態下，軟件的功能和性能；

f)應驗證局部系統內外接口的匹配性、協調性、一致性，具體包括；

1)集成后的軟件子系統之間、軟硬件之間交互接口數據及其格式；

2)局部系統的輸出數據及其格式；

3)在任意外部輸入情況下，局部系統從外部接口采集和發送數據的能力，包括對正常數據及

狀態的處理，對接口錯誤、數據錯誤、錯誤的識別及處理。

g)應驗證集成后的軟硬件工作時序之間的匹配性、協調性、一致性；

h)應驗證局部系統對硬件資源使用及硬件資源配置之間的匹配性、協調性、一致性、合理性和資

源余量。

i)對不同的實際問題應外加相應的專門測試，比如安全測試、兼容性測試等。

8.2.5測試環境

集成測試環境要求如下：

a)集成測試環境推薦使用軟件真實運行環境和真實外部硬件環境；

b)若選擇仿真或模擬測試環境，應進行環境等效性分析；

c)應配備必要的軟件測試工具、監測設備、數據分析軟件等。

系統測試

8.3.1測試對象

系統測試的對象是完整的、集成的服務機器人軟硬件系統。

8.3.2測試目的

系統測試的目的是在真實系統工作環境下檢驗完整的服務機器人軟硬件系統的功能、性能、接口、

安全性、可靠性、易用性等各項要求。

8.3.3開始條件

系統測試進入條件如下：

a)軟件已通過集成測試；

b)被測軟件已納入軟件配置管理，所涉硬件技術狀態受控；

c)具備軟件系統測試要求的環境；

d)具備與被測軟件源代碼版本對應的文檔。

8.3.4技術要求

軟件系統測試一般應符合以下技術要求：

a)開展測試需求分析，列表說明系統的測試點，并說明與需求點的對應關系。通常一個需求點應

被若干個測試用例所覆蓋，一般應被正常測試用例和異常測試用例所覆蓋；

b)應采用文檔審查和動態測試的測試方法開展系統測試，一般采用的是動態黑盒測試方法。

c)依據系統的任務剖面，從運行場景出發進行情景想定分析，開展系統任務想定設計；

d)應在動態測試前開展文檔審查，文檔審查應包含系統的所有相關文檔，例如通訊協議、數據處

理算法等，在文檔審查問題得到有效處理后再進行動態測試；

e)測試用例的輸入一般應被有效值、無效值和邊界值所覆蓋；

f)軟件之間及軟件與硬件之間的所有接口應進行測試用例設計；

g)建立系統測試環境。依據系統的特點及具體情況，系統測試環境可以是半實物仿真環境、全實

物實裝環境等，系統測試環境應能支持運行方案說明中描述的運行場景，支持系統任務過程所

需情景想定的配置，支持系統任務過程測試用例的加載、執行、過程數據采集等，評估測試環

境對測試結果的影響，分析系統測試環境的局限性，確認系統測試環境的有效性；

h)動態測試的測試類型選擇要求：

1)至少應包括：功能測試、性能測試、接口測試、邊界測試；

12

T/CRSSXXXX—XXXX

2)關鍵重要系統的測試類型應增加：安全性測試、余量測試、強度測試。在實裝系統上開展

的安全性測試，應在安全關鍵部件模擬器的配合下進行測試；

3)測試類型應結合軟件的特點進行選擇，如，具有人機交互界面的系統應進行人機交互界面

的測試，具有雙機熱備份或冷備份功能的系統應進行恢復性測試，對可異步并發操作同一

共享數據源的相關軟件應進行互操作性測試等；

i)基于運行方案說明中的運行場景，將系統規格說明中的系統能力需求組合為系統的任務需求，

逐一驗證系統的任務運行能力。

8.3.5測試環境

系統測試環境要求如下：

a)推薦使用全實物實裝環境。若選擇全數字仿真環境或半實物仿真環境，應進行環境等效性分析；

b)應配備必要的軟件測試工具、監測設備、數據分析軟件等。

回歸測試

8.4.1測試對象

更改后的軟件，包括更改所影響到的軟件單元、軟件子系統、軟件系統，還應包括因軟件更改涉及

到的集成過程。

8.4.2測試目的

對更改后的軟件重新進行測試，以確認更改正確且更改未引入新的軟件問題，即更改未影響軟件原

有的、正確的功能、性能和其他規定的要求。

8.4.3開始條件

回歸測試進入條件如下：

a)被測軟件已納入配置管理；

b)具備軟件開發文檔、代碼、數據、軟件問題處理單（或軟件更改及影響分析報告）等；

c)具備相關的測試文檔及資源；

d)具備相應級別測試的進入條件。

8.4.4技術要求

具體要求如下：

a)應統計軟件修改的代碼更改量，包括：

1)相同行。更改前與更改后完全相同的代碼行；

2)修改行。更改前與更改后部分相同的代碼行；

3)增加行。更改前沒有而更改后有的代碼行；

4)刪除行。更改前有而更改后沒有的代碼行；

5)更改行。修改行、增加行、刪除行之和；

6)更改率。更改行/(更改行+相同行)*100%。

b)當軟件完成測試后，后續軟件又發生了變化，如軟件更改率大于20%，則應按全新軟件重新測

試；

c)應依據軟件更改影響分析結果確定回歸測試范圍，選用或修改已有的測試用例，或新增測試用

例，并對測試用例使用情況進行分類統計：

1)沿用測試用例；

2)修改測試用例，即測試用例的名稱、標識未改，但內容略有修改；

3)新增測試用例。

d)應論證或證明測試用例的執行覆蓋了全部修改內容；

e)回歸測試的技術要求應符合原測試級別的技術要求。

13

T/CRSSXXXX—XXXX

A

A

附錄A

(規范性）

測試類型技術要求

A.1文檔類測試

A.1.1文檔審查

文檔審查是開展的針對軟件相關文檔的審查。文檔審查的具體要求如下：

a)審查軟件文檔種類是否齊套；

b)審查軟件文檔內容是否完整；

c)審查軟件文檔描述是否準確；

d)審查軟件文檔格式是否規范；

e)審查軟件文檔是否文文一致、文實相符；

f)編制審查所用文檔檢查單并通過評審。

A.2代碼類測試

A.2.1代碼審查

代碼審查是依據相關標準及軟件文檔開展的針對軟件程序代碼的審查。代碼審查的具體要求如下：

a)以人工閱讀方式對代碼進行審查，可以借助工具輔助完成分析。

b)代碼審查包含編程準則檢查、代碼流程審查、軟件結構審查、需求實現審查四個審查類型，測

試需求分析中應確定需要開展的審查類型。

c)編程準則檢查：依據編程準則的要求，對程序的編碼進行編程準則的符合性檢查。編程準則檢

查應依據語言特點，確定編程準則的檢查標準并通過評審，使用專業工具掃描出的警告信息應

經過人工核實確認。

d)代碼流程審查：審查程序代碼的條件判別、控制流程、數據處理等是否滿足設計要求。

e)軟件結構審查：依據設計文檔，審查程序代碼的結構設計，包括程序結構設計和數據結構設計，

f)在程序設計層發現問題。需求實現審查：依據需求文檔及其他相關資料，審查程序代碼的需求

層的功能實現，審查中應形成所有變量物理含義及取值含義的變量字典，依據數學模型、邏輯

模型、時序模型、處理模型等和變量字典審查程序代碼的處理流程，發現需求實現的問題。

g)代碼審查的軟件單元應列表匯總，并針對軟件單元說明開展的審查類型。

h)應根據軟件的特點及審查內容，確定審查所用的代碼審查單并通過評審。

A.2.2靜態分析

靜態分析是可借助專業工具對程序代碼特性進行機械性和程序化的專項分析，靜態分析的內容通

常包括程序結構分析、數據結構分析、控制流分析、數據流分析、接口分析、表達式分析、語言使用分

析、軟件質量指標度量等。

靜態分析應對程序代碼的質量度量元進行統計與度量。程序質量度量的具體要求如下：

a)質量度量元包括：軟件的代碼行數、有效代碼行數、注釋行數、模塊數、模塊代碼行數、模塊

圈復雜度、模塊基本復雜度、模塊扇入數、模塊扇出數等。

b)通常指標要求如下：

1)軟件總注釋率不小于20%（注釋行數/代碼行數*100%）；

2)模塊的平均規模不大于200行（模塊代碼行數之和/模塊數）；

3)模塊的平均圈復雜度不大于10（模塊圈復雜度之和/模塊數）；

4)模塊的平均扇出數不大于7（模塊扇出數之和/模塊數）。

c)對圈復雜度、規模行數、扇出數不滿足指標要求的模塊，應進行專項代碼審查。

d)基于指標要求并結合其他度量結果，給出軟件編碼質量的評價。

A.3數據類測試

14

T/CRSSXXXX—XXXX

A.3.1數據處理測試

數據處理測試是對完成專門數據處理功能所進行的測試。數據處理測試的具體要求如下：

a)應對數據文件存取、數據庫操作、數據采集、數據融合、數據轉換、數據解析等專門數據處理

功能進行測試；

b)應對剔除壞數據、數據濾波、數據容錯等數據特殊處理功能進行測試；

c)應針對數據讀取/寫入過程中的容錯、保護、超時等進行測試；

d)應對大數據處理算法、模型的實現正確性進行測試。

A.4功能類測試

A.4.1功能測試

功能測試是對軟件的功能需求逐項進行的測試，以驗證其功能是否滿足要求。功能測試的具體要求

如下：

a)應對軟件功能進行分析，通過等價類、邊界值、判定表、因果圖、猜錯法等分析方法確定軟件

功能的輸入；

b)輸入等價類應包括正常等價類和異常等價類；

c)輸入邊界值應包括合法邊界值和非法邊界值；

d)確定功能的輸出及預期的輸出結果和判定條件；

e)應用真實數據測試超負荷、飽和及其他最壞情況等極端條件；

f)應對功能控制流程、狀態轉換、模式切換等的正確性和合理性進行驗證；

g)在系統測試中，應在任務剖面和業務流程中進行測試；

h)建議采用組合測試法、蛻變測試法等方法提高關鍵功能的測試充分性。

A.4.2邊界測試

邊界測試是對軟件處在邊界或端點情況下運行狀態的測試。邊界測試的具體要求如下：

a)應對輸入域或輸出域的端點或邊界點進行測試；

b)針對數據結構（如，數組、字符串、堆棧等）進行端點或邊界點測試；

c)針對狀態的轉換條件（如，閾值判別、區間判別等）進行端點或邊界點測試；

d)針對狀態的出現概率（如，設備狀態、通訊狀態等）進行小概率極端情況的測試；

e)功能、性能、容量等涉及到的極限情況均視為廣義端點或邊界點進行測試；

f)需要時，應考慮接近邊界、超越邊界、連續來回穿越邊界等各種情況的測試。

A.4.3恢復性測試

恢復性測試是對有恢復或重置功能的軟件的每一類導致恢復或重置的情況逐一進行的測試，以驗

證其恢復或重置功能。恢復性測試是要證實在克服軟硬件故障后，系統能否正常地繼續進行工作，且不

對系統造成任何損害。

恢復性測試的具體要求如下：

a)應對探測錯誤并通過容錯恢復其正常工作的能力進行測試；

b)應對自復位或備機切換措施恢復繼續工作的能力進行測試；

c)應對系統恢復后，依據記錄數據恢復故障前運行作業、相關數據和系統狀態等能力進行測試；

d)應對恢復時間是否滿足規定要求進行測試。

A.5性能類測試

A.5.1性能測試

性能測試是對軟件的性能需求逐項進行的測試，以驗證其性能是否滿足要求。性能測試的具體要

求如下：

a)應進行數據精度的測試，如數值計算的精確度等；

b)應進行時間精度的測試，如執行時間、響應時間等；

c)應進行空間占用的測試，如軟件運行所占用的內存空間等；

15

T/CRSSXXXX—XXXX

d)應進行處理能力的測試，如功能所處理的數據量等；

e)應進行數據傳輸吞吐量的測試；

f)應關注軟件并發處理能力的測試；

g)在系統測試中，應關注軟件性能和硬件性能的集成；

h)測試結果應得到具體的量化數值；

i)對具有不確定性的數值：

1)應至少得到10組以上的實測值；

2)應給出最大值、最小值、平均值的統計結果；

3)對波動性較大的測量值，應統計出實測值的方差。

A.5.2余量測試

余量測試是對軟件是否達到需求要求的余量的測試。余量測試的具體要求如下：

a)針對時間約束要求，應測試出實際執行時間相對于時間約束要求的余量；

b)針對空間約束要求，應測試出實際占用空間相對于空間約束要求的余量；

c)針對處理約束要求，應測試出軟件具備的處理能力相對于處理約束要求的余量；

d)針對通訊約束要求，應測試出數據傳輸吞吐量相對于帶寬的余量；

e)如無明確規定，最少應有20%以上的余量。

A.5.3強度測試

強度測試是檢驗軟件的外部可變性影響條件惡劣到何種程度將導致軟件無法正常工作的測試。強

度測試的具體要求如下：

a)應首先確定軟件運行所依賴的外部可變性影響條件；

b)控制外部可變性影響條件的范圍變化（如，處理的信息量越來越大、通訊的數據量越來越大、

監測報警數越來越多），測試出直到軟件故障或條件已達極限時的范圍極限條件；

c)控制外部可變性影響條件的頻度變化（如，越來越頻繁的外部錯誤、越來越小的通訊周期、越

來越頻繁的中斷信號），測試出直到軟件故障或條件已達極限時的頻度極限條件；

d)對軟件進行業務流程工作狀態下的規定的長時間連續不中斷運行的測試（并不要求一定運行至

出現故障）；

e)當軟件運行環境資源不能保證時，應在測試中逐步惡化運行環境條件，測試出直到軟件故障時

的極限運行環境條件；

f)對具有降級處理能力的軟件，應對降級條件進行極限情況測試。

A.5.4容量測試

容量測試是檢驗軟件的能力最高能達到什么程度的測試。容量測試一般應測試到在正常情況下軟

件所具備的最高能力。容量測試的具體要求如下：

a)針對具有時間約束要求的功能，應測試出正常工作條件下實際執行時間的最值范圍；

b)針對具有空間約束要求的功能，應測試出正常工作條件下實際占用空間的最值范圍；

c)針對通訊接口，應測試出正常工作條件下實際傳輸時間、傳輸數據量的最值范圍；

d)針對軟件的處理能力，如處理目標數等，應測試出正常工作條件下處理能力的最值范圍。

A.6接口類測試

A.6.1接口測試

接口測試是對軟件的接口需求逐項進行的測試，以驗證其接口是否滿足要求。功能測試的具體要求

如下：

a)應對接口的信息格式是否正確進行測試，如幀格式是否滿足要求；

b)應對接口的信息內容是否正確進行測試，如內容的解析是否正確；

c)應對接口的時間特性是否滿足要求進行測試，如傳輸時間、時序關系等；

d)應對外部干擾、丟幀、錯幀、誤碼等異常模式予以容錯性驗證；

e)集成測試和系統測試中，應重點對軟件的所有外部接口進行測試；

16

T/CRSSXXXX—XXXX

f)軟硬件系統中應特別關注軟硬件接口，應關注信號觸發類的接口測試。

A.6.2人機交互界面測試

人機交互界面測試是對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用

戶的要求。人機交互界面測試的具體要求如下：

a)應依據用戶手冊或操作手冊，逐條驗證文實的一致性；

b)應對界面顯示的符合性、準確性、直觀性等進行測試；

c)應對操作輸入的方便性、健壯性、提示性等進行測試；

d)應對人機交互的友好性、導航性、適宜性等進行測試；

e)軟硬系統中作為軟件輸入的操作桿、旋鈕、開關等均屬于操作界面范疇，作為軟件輸出的警示

燈、蜂鳴器等均屬于顯示界面范疇。

A.7專項測試

A.7.1A.7.1安全性測試

安全性測試是檢驗軟件功能安全性以及信息安全性是否滿足要求的測試。安全性測試的具體要求

如下：

a)應對軟件安全性需求中確定的與軟件相關的所有故障模式進行逐一測試，驗證軟件處理故障模

式的安全性措施正確并有效。

b)應對系統故障后的降級處理能力進行測試。

c)軟硬件系統中，應進行軟硬混合故障模式的測試。

d)軟件的安全關鍵單元或部件，必須進行安全性測試。

e)對涉及安全性措施的結構、算法、容錯、冗余及中斷處理等設計，必須進行針對性的測試。

f)應對多點組合故障模式進行測試，并結合各種最壞情況的組合進行測試。

g)應對雙工切換、多機替換等安全性的冗余設計措施進行測試。

h)應對可能的異常事件進行測試，包括：

1)可能的硬件異常，如，外設故障等；

2)可能的軟件異常，如，程序跑飛等；

3)可能的操作異常，如，操作失誤等；

4)可能的輸入異常，如，數據丟幀等；

5)可能的時序異常，如，控制流程的時間順序紊亂等。

i)應對軟件的信息保密與防護能力進行測試：

1)應對軟件使用的身份識別、權限保護能力進行測試；

2)應對重要數據保護能力（如，抗非法訪問能力、加密傳輸能力等）進行測試；

3)應對軟件和系統被惡意篡改或被攻擊的防護能力進行測試。

A.7.2可靠性測試

可靠性測試是在真實的或仿真的環境中，以軟件可靠性評估為目的，按照運行剖面和使用的概率分

布進行的軟件功能測試。軟件可靠性測試的具體要求如下：

a)測試環境應與典型使用環境的統計特性相一致，必要時使用測試平臺；

b)從用戶視角出發進行情景想定分析，建立軟件的使用剖面（任務剖面/業務剖面/運行剖面/操作

剖面等）；

c)應對軟件使用程度進行定量度量，如，使用剖面的概率分布、使用特征的覆蓋率等；

d)必須保證輸入覆蓋，應覆蓋重要的輸入變量值（所有被測輸入值域的概率之和必須大于軟件可

靠性要求）、各種使用功能、相關輸入變量可能組合以及不合法輸入域等；

e)對于可能導致軟件運行方式改變的一些邊界條件和環境條件，必須進行針對性測試；

f)監測軟件出現的故障，通常情況下，軟件一旦出現故障，應進行軟件的糾錯性修改，修改后的

軟件繼續進行后續的測試；

g)記錄并統計軟件的故障數據，依據故障數據對軟件可靠性指標進行量化評估。

A.7.3兼容性測試

17

T/CRSSXXXX—XXXX

兼容性測試是檢驗軟件不同版本之間、不同軟件產品之間、不同軟硬件環境之間兼容程度的測試。

兼容性測試的具體要求如下：

a)當新版本軟件替代舊版本軟件時，應進行向下兼容性測試；

b)當多個軟件版本可以同時使用時，應進行相互兼容性測試；

c)當兩個軟件產品可在同一硬件環境中替換使用時，應進行交錯兼容性測試；

d)當軟件產品可能在不同的硬件設備中使用時，應進行適配兼容性測試；

e)當軟件產品可能在不同的軟件環境中使用時，應進行環境兼容性測試。

18

T/CRSSXXXX—XXXX

B

B

附錄B

(資料性）

軟件測試文檔模板

B.1軟件測試用例編寫模板

表B.1測試用例設計單

被測軟件版本測試用例名稱

測試用例標識測試用例

用例設計方法用例屬性

用例初始化

前提與約束

終止條件

測試過程

序號輸入及操作說明期望測試結果實際測試結果

評估準則

設計人員設計日期

執行情況執行結果問題標識

測試人員測試監督員測試執行日期

模板說明：

19

T/CRSSXXXX—XXXX

a）測試用例名稱：測試用例名稱應盡量體現該測試用例的核心意圖；在同一個測試點目中，測試

用例名稱必須唯一；

b）測試追蹤：相應的測試點的標識；

c）測試用例：簡要描述測試的對象、目的和所采用的測試方法；

d）測試用例設計方法：如等價類劃分、邊界值分析、猜錯法、因果圖、功能圖等；

e）用例屬性：對于測試軟件正常功能和接口的測試用例，填寫“正常”測試軟件異常功能和接口

的測試用例，填寫“異常”；

f）測試用例初始化：包括軟件配置、測試配置（如測試工具、模擬系統等）、參數設置等的初始

化要求；

g）前提與約束：說明實施測試用例有關的硬件配置情況，例如測試環境中各設備連接情況、某個

設備的狀態設置情況等；

h）終止條件：說明測試用例的測試正常終止和異常終止條件；

i）輸入及操作說明：記錄測試執行的輸入，包括：

1）測試輸入項的名稱、具體內容（如確定的數值、狀態或信號等）、性質（如有效值、無效

值、邊界值等；

2）測試輸入的來源（如：測試程序生成、磁盤文件讀取、網絡數據接收、人機交互界面輸入

等），以及真實的還是模擬的；

3）測試輸入的時間順序或事件順序。

j）評估準則：對于功能性測試用例，評估準則可填寫“與期望結果一致”；對于非功能性測試用

例，給出具體評估方法，例如：實際測試結果所需的精確度，允許的實際測試結果與期望結果之間差

異的上、下限，時間的最大或最小間隔，時間數目的最大或最小值等。

B.2軟件測試問題單模板

表B.2軟件問題報告單

項目

單編號

名稱

問題名稱

軟件

問題數目

版本

問題來源

需求問設計問文檔問編碼問數據問其它問

問題類型

題題題題題題

問題等級災難問題嚴重問題一般問題改進建議

問題描述

20

T/CRSSXXXX—XXXX

處理措施

開發意見

及簽字

簽字：年