RB/T 234-2024 轨道交通装备系统软件测评规范 清晰版

中华人民共和国认证认可行业标准

RB/T 234—2024

轨道交通装备系统软件测评规范

2025⁃09⁃28 发布 2025⁃12 ⁃01 实施

国家认证认可监督管理委员会发 布中国 标准 出版 社出 版

前言

本文件按照 GB/T 1.1—2020《标准化工作导则第 1 部分：标准化文件的结构和起草规则》的规定起草。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

本文件由国家认证认可监督管理委员会提出并归口。

本文件起草单位：中车青岛四方车辆研究所有限公司、航天中认软件测评科技(北京)有限责任公司、北京交通大学。

本文件主要起草人：马翔宇、孙国斌、曹虎、吴永、王爱菲、曹源、马法运、袭文娟、李德祥、林鸿、孔红、王正。

轨道交通装备软件要求具备高可靠性、高安全性，且具有运行频率高、维护周期长等特点，对软件质量的要求极高。而测评是软件生命周期中一个独立的关键阶段，完整、规范的测评工作是保证软件质量的重要手段。

轨道交通是国家战略性、先导性、关键性重大基础设施，在经济社会发展中的地位和作用至关重要。中国国家铁路集团有限公司出台了《新时代交通强国铁路先行规划纲要》，要求建立健全评价标准体系，确保轨道交通装备本质安全，完善铁路基础设施和装备安全技术标准规范，提升关键设施全生命周期安全性、可靠性，建立健全交通强国、铁路先行评价指标体系，更好地科学评判和开展对标对表，构建系统完备、先进适用、自主可控、世界领先的中国铁路技术标准体系，加快中国铁路技术标准国际化，提升中国铁路品牌的国际影响力。

轨道交通装备乃至车辆装备领域，软件相关的标准相对匮乏，国内轨道交通相关企业普遍引用欧洲标准对软件进行管理与评估，采用国外认证公司进行评估认证，而这些标准主要集中在软件工程、软件过程管理方面，在软件测试与评价规范、指南等方面尚未有相关标准。为推动轨道交通装备软件标准体系的建设，建立完善规范的软件认证方面的测评流程，制定本文件，目的在于推动轨道交通装备软件标准化工作更好地服务轨道交通装备发展;另一方面，充分考虑轨道交通装备行业的特点，结合软件标准化，在契合发展的基础上，使标准建设更体现出轨道交通行业特色。

本文件根据轨道交通装备系统软件的特点和软件安全完整性等级要求，为轨道交通装备企业、研究机构及第三方机构提供软件测评规范与指南。本文件相较于其他标准，完善了测试具体内容，可操作性更强，同时增加了测试评价内容，是集测评一体化的标准规范。

1 范围

本文件规定了轨道交通装备系统软件测评的一般要求、软件单元测试及评价、软件集成测试及评价、软件硬件集成测试及评价、软件确认测试及评价和系统测试及评价。

本文件适用于城市轨道交通装备控制和防护系统软件全生命周期的测评，本文件不适用于轨道交通装备系统信息安全类软件测评。

2 规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件;不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

GB/T 9386 计算机软件测试文档编制规范

GB/T 11457—2006 信息技术软件工程术语

GB/T 15532—2008 计算机软件测试规范

GB/T 20158 信息技术软件生存周期过程配置管理

GB/T 28808—2021 轨道交通通信、信号和处理系统控制和防护系统软件

3 术语和定义

GB/T 11457—2006 和 GB/T 28808—2021 界定的以及下列术语和定义适用于本文件。

评价 evaluation

实体满足其规定准则的程度的系统性评价。

[来源：GB/T 25000.40—2018，4.16]

软件配置项 software configuration

软件产品在不同时期的组合。该组合随着开发工作的进展而不断变化。

注：通常包括与合同、过程、计划和产品有关的文档和资料;源代码、目标代码和可执行代码;软件工具、库内的可重用软件、外购软件及顾客提供的软件等的相关产品。

[来源：GB/T 11457—2006，2.1477，有修改]

软件部件 software component

软件配置项中的一个明确的部分。

注：一个软件部件含有多个软件单元、也可以含有多个较低级的软件部件。

[来源：GB/T 11457—2006，2.1476，有修改]

静态分析 static analysis

基于它的格式、结构、内容或文档评价系统或部件的过程。

注：静态分析一般包括边界值分析、控制流分析、数据流分析和接口分析。

[来源：GB/T 11457—2006，2.1577，有修改]

软件安全完整性等级 software safety integrity level

一组分级数字，它决定了应运用于软件的技术和措施。

注 1：软件失效带来的风险越高，软件安全完整性等级就越高。

注 2：本文件标识了 5 种软件安全完整性等级：SIL0~SIL4，其中 SIL0 为最低等级，SIL4 为最高等级。

[来源：GB/T 28808—2021，3.1.38，有修改]

轨道交通装备系统软件 rail transit equipment system software

轨道交通控制和防护系统所需各类装备系统中的程序、规程、数据和相关文件。

注：适用于城市轨道交通装备系统。

软件生命周期 software life cycle

当软件产品从构思开始至软件不再可用结束的时间周期。

注：典型的软件生命周期包括需求阶段、设计阶段、实现阶段、测试阶段、安装和验收阶段、操作和维护阶段，有时还包括退役阶段。

[来源：GB/T 11457—2006，2.1506，有修改]

测试评价 testing evaluation

根据测试结果评价被测实体满足其规定准则的程度。

4 总体要求

4.1 测评目的

轨道交通装备系统软件的测评目的应包括：

a) 通过测试，发现是否存在软件问题，验证是否满足软件开发合同的基本需求;

b) 评价软件是否满足软件开发合同或项目开发计划、系统需求规范、软件需求规范、软件结构设计规范、软件详细设计规范、编码规范及相关技术协议所规定的质量特性和技术要求。

4.2 测评阶段

软件测评工作应包含以下各阶段：

a) 软件单元测试及评价;

b) 软件集成测试及评价;

c) 软件硬件集成测试及评价;

d) 软件确认测试及评价;

e) 系统测试及评价。

4.3 测试环境

测试环境应满足以下要求：

a) 包括测试的运行环境和测试工具环境;包括软件(如操作系统、编译软件、静态测试软件、动态测试软件、测试数据生成软件、测试结果获取和处理软件、测试驱动软件等)和硬件(如计算机、陪测设备、设备接口等)。

b) 测试的运行环境应满足软件测试合同(或项目计划)的要求，通常是实际轨道交通装备系统运行环境，或相容的系统运行环境。若选择仿真或模拟测试环境，应加以论证并进行确认。

c) 按 GB/T 15532—2008 的 4.8.2 选择测试工具。

4.4 测试用例

4.4.1 测试用例的设计要求

设计测试用例时，应满足以下要求：

a ) 测试用例设计应符合 GB/T 15532—2008 中 4.5.1 测试用例设计原则。

b) 安全完整性等级要求应按照附录 A 的规定设计能够覆盖当前测试阶段要求的测试活动的测试用例。

4.4.2 测试用例要素

测试用例要素参照 GB/T 15532—2008 中 4.5.2 的测试用例要素执行。

4.5 测评方法

4.5.1 静态测试及评价

4.5.1.1 静态测试是不运行程序而寻找程序代码中可能存在的错误和评估程序代码质量的过程。

4.5.1.2 静态测试方法宜采用代码审查、代码走查、质量度量和静态分析。对于规模较小、安全性要求很高的代码可进行形式化证明。

4.5.1.3 静态测试的质量度量与静态分析的方法见附录 B。

4.5.1.4 软件静态测试结果宜从代码规范性、可读性、可维护性、安全性、效率、可靠性、复杂度、代码缺陷数量及分布等指标进行评价。

4.5.2 动态测试及评价

4.5.2.1 动态测试是指在测试数据上运行程序并全面分析输出以发现错误的过程。

4.5.2.2 动态测试方法应采用黑盒测试方法或白盒测试方法。

4.5.2.3 动态测试的方法见附录 C。

4.5.2.4 软件动态测试结果宜从测试覆盖率、功能性、可靠性、效率、易用性、维护性、可移植性、代码缺陷数量及分布等指标进行评价。

4.6 测试评价内容

测试评价应包含但不限于以下内容。

a) 对测试执行情况、测试结果情况进行汇总，计算测试需求的覆盖率;对软件问题尤其是遗留问题进行描述，对问题的影响域进行分析;对软件质量进行评价。

b) 对测试工作进行分析和评价，包括：总结测评计划、测试说明的变化情况及变化的原因;对异常终止情况，说明未能被测试活动充分覆盖的范围及其理由;确定无法解决的软件测试事件及不能解决的理由。

c) 对被测软件进行分析和评价，包括：总结测试中所反映的被测软件与软件需求(或软件设计)之间的差异;根据差异评价被测软件的设计和实现，可提出改进建议;当进行软件确认测试或系统测试时，应对被测软件的性能做出评估，指明偏差、问题和约束条件等对于被测运行的影响。

d) 形成测评报告并对测评报告进行评审。评审测试执行及评价活动的有效性、测评结果的正确性和合理性、是否达到了测评目的等。

4.7 测评过程

4.7.1 测试的准入准出条件

a ) 开始软件测试工作应具备以下准入条件：

1) 具有软件测试所需的各种文档;

2) 所提交的被测软件受控;

3) 软件源代码正确通过编译或汇编。

b) 结束软件测试工作应具备以下准出条件：

1) 已按要求完成了测评策划所规定的软件测试任务;

2) 实际测试过程遵循了评审后的软件测评计划和软件测试说明;

3) 客观、详细地记录了软件测试过程和软件测试中发现的所有问题;

4) 软件测试文档齐全、符合规范;

5) 软件测试的全过程自始至终在控制下进行;

6) 软件测试中的问题或异常有合理解释或正确有效的处理;

7) 软件测试工作通过了测试评审;

8) 全部测试软件、被测软件、测试支持软件、测试文档和评审结果已纳入配置管理。

4.7.2 测评策划

测评策划应包含但不限于以下内容：

a) 进行测评需求分析，确定该级别的测评范围和任务，包括需要测评的内容、测评活动等;进行安全完整性等级分析，确定在测评范围下软件需满足的安全完整性等级以及测评指标。

b) 确定测评策略和方法，分析可能实施的测评方法，确定测评遵循的标准和过程，考虑可能需要的软件硬件测评环境。

c) 确定测评周期，预测完成整个测评所需时间。

d) 确定测评人力资源的分配。组建测评项目组，确定测评负责人和测评成员，明确各成员的相关责任以及制定测评任务安排。

e) 确定测评交付成果。按照不同的测评任务以及测评阶段，确定当前测评阶段完成后应该交付的过程记录、文档等测评成果。

f) 测评风险分析。主要考虑项目开发延期、测评人员不足、用例无法全面覆盖测试点、时间不足、问题无法及时修改导致无法验证、测评人员技术不足导致进度延期，并制订应对措施。

g) 根据测评合同(或项目计划)的要求和被测软件的特点，确定各测评级别的准出条件;通常情况下，要求关键、重要级别的问题全部修改，问题级别要求应按附录 D 划分。

h) 对于软件单元测试及评价、软件集成测试及评价和软件硬件集成测试及评价，在该阶段开展测评对象分析工作，依据软件详细设计规范和软件结构设计规范对测评对象进行分析工作。确定测评类型、测评内容、测评方法、测评要求、软件集成策略及软硬件集成策略;建立测试单元、测试部件与软件设计规范的追溯关系。

i) 对于软件确认测试及评价、系统测试及评价，在该阶段开展测评需求分析工作，依据软件需求规范和系统需求规范对测评任务进行测评需求分析。确定测评类型、测评内容、测评方法、测评要求;确定测评类型中的各个测评项;建立测评项与软件需求规范或者系统需求规范的追溯关系。

j) 将策划的结果形成测评计划并通过评审。

4.7.3 测试设计与实现

测试设计与实现应包含但不限于以下内容：

a) 建立测试环境。对软件系统根据测试阶段逐级分解，按照 4.3 的要求准备并获取对应的测试阶段的软硬件测试资源，开发测试辅助软件，搭建测试环境并校核。

b) 编写测试用例。依据测试需求，分析并选用已有的测试用例或设计新的测试用例;将需测试的软件特性分解，针对分解后的每种情况设计测试用例，每个测试用例的设计应符合 4.4 的规定。

c) 获取测试数据。包括获取现有的测试数据和生成新的数据，并按照要求验证所有数据。

d) 确定 测试 顺序。 可从 资源 约束、风险、优先 以及 测试 用例 失效 造成 的影 响或 后果 几个 方面考虑。

e) 获取测试资源。对于支持测试的软件和硬件，可从现有工具中选定或研制开发。

f) 编写测试程序。包括开发测试支持工具、单元测试的驱动模块和桩模块。

g) 编写测试说明，建立测试说明与设计规范文件和需求规范文件的追踪关系，测试说明应通过评审。评审测试说明的合理性和测试用例的正确性，有效性和覆盖充分性，评审测试组织、环境和设备工具是否齐备并符合要求。

4.7.4 测试执行

测试执行应包含但不限于以下内容：

a ) 按测评计划和测试说明的内容和要求执行测试。

b) 如实填写测试的原始记录，获取测试结果。

c) 根据每个测试用例的期望测试结果、实际测试结果和评价准则判定该测试用例是否通过，并将结果记录在测试记录中。如果测试用例不通过，测试人员应认真分析情况，并根据以下情况采取相应措施：

1) 测试说明和测试数据的差错：应改正差错信息并详细记录，然后重新运行该测试。

2) 执行测试步骤时的差错：应重新运行未正确执行的测试步骤。

3) 测试环境(包括软件环境和硬件环境)中的差错。应修正测试环境，将环境修正情况详细记录，重新运行该测试;如果不能修正环境，应记录理由，再核对终止情况。

4) 软件的设计与实现差错：应划分问题级别，填写软件问题报告单(参考附录 E)，可提出软件修改建议，然后继续进行测试;或者把差错与异常终止情况进行比较，核对终止情况。软件变更完毕后，应根据情况对其进行回归测试;回归测试中需要相应地修改测试设计和数据。

d) 当所有的测试用例执行完毕，测评人员根据测试的充分性要求和失效记录，确定测试工作是否充分，是否需要增加新的测试。当测试过程正常终止时，如果发现测试工作不足，则进行补充测试，直到测试达到预期要求，并将附加的内容记录在测评报告中;如果不需要补充测试，则将正常终止情况记录在测评报告中。当测试过程异常终止时，记录导致终止的条件、未完成的测试和未被修正的差错。

4.7.5 回归测试

回归测试应按照 GB/T 15532—2008 第 10 章执行。

4.7.6 测试评价

测试完成后应按照 4.5、4.6 进行评价。

4.7.7 测评通过条件

各测评阶段的通过条件应满足以下要求：

a) 测评过程遵循了评审后软件测评计划和软件测试说明;

b) 达到测评计划中规定的测试覆盖率要求且软件执行正确;

c) 客观、详细地记录了测试过程中发现的所有问题;

d) 测评计划、测试说明、测评报告等测试文档齐全、符合规范;

e) 满足相应阶段测评计划中的准出条件;

f) 相应阶段中的各种测评活动通过评审。

4.8 记录及文档

软件各阶段测评均应有计划地进行，记录包括输入数据、预期结果、测评结果及测评规程，记录内容应存档保留，并且确保测评的可重现性。

文档应包括测评计划、测试说明、测评报告。文档的基本内容和要求应符合 GB/T 9386 的规定。

应按 GB/T 20158 规定的软件配置管理要求，将测评过程中产生的各种软件工作产品纳入配置管理。

4.9 软件生命周期各阶段测评工作

测评工作应贯穿于软件生命周期全过程，软件开发不同阶段均应有测评工作，测评工作的各个活动应分布在软件开发过程中。各阶段应完成的测评工作(策划、设计与实现、执行、报告与总结)应按表 1 进行。

表 1 软件生命周期各阶段测评工作

5 软件单元测试及评价

5.1 测评对象与目的

测评对象应为软件模块中所有应测试的软件单元。

测评目的应包括：

a ) 检验 每个 软件 单元 能否 正确 地实 现详 细设 计规 范中 规定 的功 能，满足 其性 能和 接口 等的要求;

b) 度量软件质量，并对其是否能满足设计要求进行评价。

5.2 测评技术要求

5.2.1 通用要求

软件单元测评应满足以下通用技术要求：

a) 在对软件单元进行动态测试与评价之前，对软件单元进行静态测试与评价;

b) 对软件详细设计规范规定的软件单元的功能、性能、接口等逐项进行测试与评价;

c ) 测试用例的设计应使语句、分支、修正的条件判定满足表 A .11 的要求;

d) 对有特殊要求的软件单元，应进行占用空间、运行时间、计算精度等测试并评价是否满足设计要求;

e) 对输出数据及其格式进行测试与评价;

f) 软件单元测试的安全完整性等级要求符合表 A .1 的规定。

对具体的软件单元，可根据软件测评计划、软件单元的重要性及安全完整性等级等要求对上述内容进行裁剪。

5.2.2 进入条件

软件单元测评应符合以下进入条件：

a) 具备软件详细设计规范并受控;

b) 软件单元源代码通过编译或汇编。

5.2.3 通过条件

软件单元测评通过条件应满足 4.7.7 的要求。

5.2.4 测评文档

软件单元测评工作完成后形成的文档应包括：

a) 软件单元测评计划;

b) 软件单元测试说明;

c ) 软件单元测评报告。

5.3 测试

5.3.1 测试内容

软件单元测试应包括以下内容：

a ) 软件单元的功能测试：对软件详细设计规范规定的软件单元的功能逐项进行测试。

b) 软件单元的性能测试：按软件详细设计规范的要求，对软件单元的性能(如精度、时间、容量等)进行测试。

c ) 软件单元的接口测试：

1) 被测单元的实际参数与该单元的形式参数的个数、属性、量纲、顺序是否一致;

2) 被测单元调用子模块时，传递给子模块的实际参数与子模块的形式参数的个数、属性、量

纲、顺序是否一致;

3) 是否修改了只作为输入值的形式参数;

4) 调用内部函数的参数个数、属性、量纲、顺序是否正确;

5) 被测单元在使用全局变量时是否与全局变量的定义一致;

6) 在单元有多个入口的情况下，是否引用了与当前入口无关的参数;

7) 常数是否当作变量来传递;

8) 输入/输出文件属性的正确性;

9) 规定的输入/输出格式说明与输入/输出语句是否匹配;

10) 缓冲区容量与记录长度是否匹配;

11) 文件是否先打开后使用;

12) 文件结束条件的判断和处理的正确性;

13) 对输入/输出错误是否进行了检查并做了处理以及处理的正确性。

d) 重要的执行路径测试。

e ) 局部数据结构测试：测试软件单元内部的数据能否保持其完整性，包括内部数据内容、格式及相互关系。设计测试用例以检查如下差错：

1) 不正确或不一致的数据类型说明;

2) 错误的变量名，如变量名拼写错误或缩写错误等;

3) 使用尚未赋值或尚未初始化的变量;

4) 差错的初始值或差错的缺省值;

5) 不一致的数据类型;

6) 下溢、上溢或是地址差错;

7) 全局数据对软件单元的影响。

f) 错误处理测试：测试软件单元是否包含错误处理的措施;在运行过程中发生差错时，其出错处理措施是否有效。若出现下列情况之一，则表明软件单元的出错处理功能包含差错或问题：

1) 差错的描述难以理解;

2) 在对差错进行处理之前，差错条件已经引起系统的干预;

3) 所提供的差错描述信息不足以确定造成差错的位置或原因;

4) 显示的差错提示与实际差错不符;

5) 对差错条件的处理不正确;

6) 意外的处理不当;

7) 联机条件处理(即交互处理等)不正确。

g) 语句覆盖测试，分支覆盖测试，修正的条件判定覆盖(MC/DC)等测试。

h) 影响 5.3.1 中各条的界限条件(边界值)。

5.3.2 实施步骤

5.3.2.1 测评策划

测评策划应满足 4.7.2 的要求并包含但不限于以下内容：

a ) 确定测评充分性要求。根据软件单元的安全等级要求、软件单元测评目标和约束条件，确定测评范围，所要求的覆盖率满足表 A .11 的要求;

b) 确定测评终止的要求。指定测评过程正常终止的条件(如测试充分性是否达到要求)，确定导致测评过程异常终止的可能情况(如软件编码错误);

c ) 确定需要测评的软件特性。根据软件详细设计规范的描述确定软件单元的功能、性能、状态、

接口、数据结构、设计约束等内容;

d) 确定测评需要的技术和方法。如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术、程序打桩技术;

e ) 编写软件单元测评计划并通过评审。测评计划包括 5.3.2.1 中的各条内容。

5.3.2.2 测试设计

测试设计应按照 4.7.3 的要求开展。

5.3.2.3 测试执行

测试执行应按照 4.7.4 的要求开展。

5.4 评价

软件单元测试完成后，应根据以下准则和方法对软件进行评价：

a ) 是否满足 5.2 测评技术要求;

b) 软件单元是否满足测评计划中静态分析、质量度量的标准要求;

c ) 软件单元是否满足表 A .11 的覆盖率要求;

d) 关键缺陷、重要缺陷是否 100% 修改;一般缺陷、建议缺陷遗留比例是否高于测评计划中的要求，是否全部闭环处理;

e) 功能测试、性能测试的软件误差是否控制在允许范围内;

f) 通过缺陷密度分析的方法分析软件的稳定性。如果缺陷密度逐渐收敛，说明版本逐渐稳定;如果趋势起伏不定，需要分析研究原因，查找不稳定原因;如果缺陷密度趋势呈波状，说明版本极其不稳定，需进行分析确认。

5.5 测评总结

测评总结应按照 4.7.6、5.4 的要求执行，根据软件详细设计规范、软件单元测评计划、软件单元测试说明、测试执行记录和软件问题报告单等，编写软件单元测评报告，对测试工作进行总结，对被测软件进行评价。

6 软件集成测试及评价

6.1 测评对象与目的

测评对象应包括：

a) 软件单元;

b) 软件单元集成得到的软件部件。

测评目的是验证软件单元集成后的软件功能和集成单元间接口的数据传递是否符合设计要求，并对软件进行质量评价。

6.2 测评技术要求

6.2.1 通用要求

软件集成测评应满足以下通用技术要求：

a ) 对软件部件进行必要的静态测试评价，且先于动态测试评价。

b) 采用增量集成测试法、非增量集成测试法等验证新的软件单元和(或)软件部件是否可与已有

的软件部件一起执行。

c ) 对软件结构设计规范规定的软件部件的功能、性能等特性逐项进行测评。

d) 测评软件单元、软件部件之间的所有接口是否能达到 100% 的调用覆盖率。对达不到 100%覆盖率或不可测试的代码，使用恰当的技术证明其正确性。

e ) 测评从外部接口采集和发送数据的能力，包括对正常数据及状态的处理，对接口错误、数据错误、协议错误的识别及处理。

f) 应测评运行条件(如数据结构、I/O 通道容量、内存空间、调用频度)在边界状态下以及在人为设定的状态下软件部件的功能和性能。

g) 测评运行条件下若多个单元共享一些资源，是否造成资源的访问冲突的问题。

h) 测评每个软件单元集成之后，集成后软件部件的误差是否满足要求。

i) 对安全性要求比较高的软件结构设计，对其进行安全性分析，明确每一个结构的危险状态和导致危险的可能原因，并对此进行针对性的测评。

j) 检查是否有多余的软件单元。

k) 软件集成测试的安全完整性等级要求应符合附录 A 中表 A .2 的规定。

对具体的软件部件，可根据软件测评计划、软件部件的重要性及安全完整性等级等要求对上述内容进行裁剪。

6.2.2 进入条件

软件集成测评应符合以下进入条件：

a) 具备软件结构设计规范并受控;

b) 待集成的软件单元通过单元测试;

c ) 软件单元源代码通过编译或汇编。

6.2.3 通过条件

软件集成测评通过条件应满足 4.7.7 的要求。

6.2.4 测评文档

软件集成测评工作完成后形成的文档应包括：

a) 软件集成测评计划;

b) 软件集成测试说明;

c) 软件集成测评报告。

6.3 测试

6.3.1 测试内容

软件集成测试应包括以下内容。

a ) 全局数据结构。可测试全局数据结构的完整性，包括数据的内容、格式，并对内部数据结构对全局数据结构的影响进行测试。

b) 软件单元之间的接口测试。

c ) 软件部件的功能测试。

d) 根据需求进行软件部件运行时间、运行空间、计算精度的测试。测试已集成软件的运行时间，算法的最长路径下的计算时间，测试软件运行占用的内存空间和外存空间。测试软件中具有准确性要求的功能和精度要求的项(如数据处理精度、时间控制精度、时间测量精度)。

e ) 边界下的性能测试。

f) 在互操作性方面，可测试以下两种接口：所加入的软件单元与已集成软件之间的接口;已集成软件与支持其运行的其他软件、例行程序的接口。对接口的输入和输出数据的格式、内容、传递方式、接口协议等进行测试。测试软件的控制信息，如信号或中断的来源、信号或中断的目的、信号或中断的优先级、信号或中断的表示格式或表示值、信号或中断的最小最大和平均频率、响应方式和响应时间等。

6.3.2 实施步骤

6.3.2.1 测评策划

a ) 确定测评充分性要求。根据软件的安全完整性等级，确定测评范围所要求的调用覆盖程度。

b) 确定测评终止的要求。指定测评过程正常终止的条件(如是否达到测试的充分性要求)，并确定导致测评过程异常终止的可能情况(如软件接口错误)。

c ) 确定需要测评的软件特性。根据软件结构设计规范(含接口设计文档)的描述确定软件的功能、性能、状态、接口、数据结构、设计约束等内容和要求并对其标识。若需要，将其分类。并从中确定需测试的软件特性。

d) 确定测评需要的技术和方法，如测试数据生成和验证技术、测试数据输入技术、测试结果获取技术、增量测试的集成策略。

e ) 确定集成测评的测评单元。参考软件结构设计规范，整理出需开展集成测评的功能单元/模块，并确定功能模块之间交互的数据，然后针对各个功能模块，依次找出各个子功能点的主调函数，并将主调函数和它的被调函数作为一个测评部件列出。

f) 编写软件集成测评计划并通过评审。测评计划包括 6.3.2.1 中的各条内容。

6.3.2.2 测试设计

6.3.2.3 测试执行

6.4 评价

软件集成测试完成后，应根据以下准则和方法对软件进行评价：

a) 是否满足 6.2 测评技术要求;

b) 覆盖率是否满足测评计划中单元、部件调用覆盖率的要求;

c) 统计软件部件之间规定接口项，测试验证软件正确实现接口项数量是否满足规定要求;计算数据交换正确性是否满足规定要求;

d) 是否满足 5.4 中 d)~ f)的要求。

6.5 测评总结

测评总结应按照 4.7.6、6.4 的要求执行，根据软件结构设计规范、软件集成测评计划、软件集成测试说明、测试执行记录和软件问题报告单等，编写软件集成测评报告，对测试工作进行总结，对被测软件进行评价。

7 软件硬件集成测试及评价

7.1 测评对象与目的

测评对象应为已集成在实际硬件平台中的软件部件与硬件之间的接口。

测评目的是检验在实际硬件平台上运行的软件部件与硬件平台的接口关系，验证已集成软件系统是否符合设计要求，并对软件进行质量评价。

7.2 测评技术要求

7.2.1 通用要求

软件硬件集成测评应符合以下通用技术要求：

a) 测试软件部件和硬件之间的所有接口;

b) 测试软件是否能按要求处理硬件故障;

c) 测试软件结构设计规范中要求的时序和性能;

d) 针对硬件是否有冗余设计不同测试用例;

e) 测试软件部件与硬件之间的所有调用是否能达到 100% 的调用覆盖率。对达不到 100% 覆盖率或不可测试的代码，使用恰当的技术证明其正确性。

f) 软件硬件集成测试的安全完整性等级符合表 A .3 的规定。

对具体的软件部件与硬件之间的接口，可根据软件测评计划、软件部件与硬件之间的接口的重要性及安全完整性等级等要求对上述内容进行裁剪。

7.2.2 进入条件

软件硬件集成测试应符合以下进入条件：

a) 具备软件结构设计规范并受控;

b) 测试的软件通过软件集成测试。

7.2.3 通过条件

软件硬件集成测试通过条件应满足 4.6.6 的要求。

7.2.4 测评文档

软件硬件集成测评工作完成后形成的文档应包括：

a) 软件硬件集成测评计划;

b) 软件硬件集成测试说明;

c ) 软件硬件集成测评报告。

7.3 测试

7.3.1 测试内容

软件硬件集成测试应包括以下测试内容：

a) 软件与硬件的接口，如硬线、继电器、电磁阀、传感器等硬件信号;

b) 软件部件之间的通信协议，如列车总线通信协议、芯片内部通信协议等;

c) 软件部件的功能测试，软件与硬件集成后或者是不同软件部件建立通信后须测试的功能;

d) 软件部件的性能测试，如软件部件运行时间、运行空间、计算精度;

e) 软件集成测试的无法测试的功能和性能;

f) 确认测试环境难以实现的工况下的预先测试。

7.3.2 实施步骤

7.3.2.1 测评策划

a ) 满足 6.3.2.1 中 a)~ d)的要求;

b) 根据软件接口规范和通信协议划分接口测试项，依据软件结构设计规范确定被测评软件部件的功能和性能需求;

c) 编写软件硬件集成测评计划并通过评审。测评计划包括 7.3.2.1 中的各条内容。

7.3.2.2 测试设计

7.3.2.3 测试执行

7.4 评价

软件硬件集成测试完成后，应根据以下准则和方法对软件进行评价：

a) 是否满足 7.2 测评技术要求;

b) 软件部件与硬件之间的接口是否满足测评计划中调用覆盖率的要求;

c) 统计软件部件与硬件之间规定接口项，测试验证软件正确实现接口项数量是否满足规定要求;计算数据交换正确性是否满足规定要求;

7.5 测评总结

测评总结应按照 4.7.6、6.4 的要求执行，根据软件结构设计规范、软件硬件集成测评计划、软件硬件集成测试说明、测试执行记录和软件问题报告单等，编写软件硬件集成测评报告，对测试工作进行总结，对被测软件进行评价。

8 软件确认测试及评价

8.1 测评对象与目的

测评对象应为软件配置项。

测评目的是检验软件与软件需求规范的一致性，并对软件进行质量评价。

8.2 测评技术要求

8.2.1 通用要求

软件确认测评应符合以下通用技术要求：

a) 必要时在高层控制流图中做结构覆盖测评;

b) 逐项测评软件需求规范规定的软件配置项的功能、性能、可靠性、安全保密性等特性;

c) 测评软件配置项的所有外部输入、输出接口(包括和硬件之间的接口);

d) 测评软件配置项的输出及其格式;

e) 测评运行条件在边界状态和异常状态下，或在人为设定的状态下，软件配置项的功能和性能;

f) 测评软件配置项的全部存储量、输入/输出通道和处理时间的余量;

g) 测评设计中用于提高软件配置项安全性、可靠性的结构、算法、容错、冗余、中断处理等方案;

h) 对有恢复或重置功能需求的软件配置项，测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试评价;

i) 对不同的实际工况问题，外加相应的专门测评;

j) 软件确认测试的安全完整性等级要求符合表 A .4 的规定。

对不同的软件配置项，可根据软件测评计划、软件配置项的重要性及安全完整性等级等要求对上述内容进行裁剪。

8.2.2 进入条件

软件确认测评应符合以下进入条件：

a) 具备软件需求规范并受控;

b) 完成并通过软件集成测试评价、软件硬件集成测试评价;

c ) 软件配置项可运行在真实工作环境或满足 4.3 要求的仿真环境下。

8.2.3 通过条件

软件确认测评通过条件应满足 4.7.7 的要求。

8.2.4 测评文档

软件确认测评工作完成后形成的文档应包括：

a) 软件确认测评计划;

b) 软件确认测试说明;

c) 软件确认测评报告。

8.3 测试

8.3.1 测试内容

8.3.1.1 根据软件需求规范中定义的全部功能和性能要求及软件确认测评计划，测试整个软件是否达到了要求。测试内容至少应包括功能测试、性能测试和外部接口测试，必要时，还包括人机交互界面测试、强度测试、余量测试、安全性测试、恢复性测试、边界测试、安装性测试、敏感性测试等内容。

8.3.1.2 功能测试应包含以下内容：

a ) 从适合性方面测试软件需求规范规定的软件的每一项功能;考虑软件功能对操作模式、运行环境、运行状态、状态转换、运行时间等的覆盖要求;对于在软件需求规范中没有指明，而在用户使用手册、操作手册中表明出来的每一项功能及操作，都应有相应测试用例覆盖。

b) 从准确性方面考虑，对软件中具有准确性要求的功能和精度要求的项(如数据处理精度、时间控制精度、时间测量精度)进行测试。

c ) 从互操作性方面测试软件需求规范和接口设计文档规定的软件与外部设备的接口、与其他系统的接口。测试接口的格式和内容，包括数据交换的数据格式和内容;测试接口之间的协调性;测试软件对系统每一个真实接口的正确性;测试软件从接口接收和发送数据的能力;测试

数据的约定、协议的一致性;测试软件对外围设备接口特性的适应性。

d) 从安全保密性方面测试软件及其数据访问的可控制性。测试软件防止非法操作的模式，包括防止非授权的创建、删除或修改程序或信息，必要时做强化异常操作的测试。测试软件防止数据被讹误和被破坏的能力。测试软件的加密和解密功能。

8.3.1.3 性能测试应包含以下内容：

a) 测试程序在获得定量结果时程序计算的精确性(处理精度);

b) 测试程序在有速度要求时完成功能的时间(响应时间);

c) 测试程序完成功能所能处理的数据量;

d) 测试程序各部分的协调性，如高速、低速操作的协调;

e) 测试软/硬件中因素是否限制了程序的性能;

f) 测试程序的负载潜力;

g) 测试程序运行占用的空间。

8.3.1.4 外部接口测试应包含以下内容：

a) 测试所有外部接口，检查接口信息的格式及内容;

b) 对每一个外部的输入/输出接口做正常和异常情况的测试。

8.3.1.5 人机交互界面测试应包含以下内容：

a) 测试操作和显示界面及界面风格与软件需求规范中要求的一致性和符合性;

b) 以非常规操作、误操作、快速操作来检验界面的健壮性;

c) 测试对错误命令或非法数据输入的检测能力与提示情况;

d) 测试对错误操作流程的检测与提示;

e) 如果有用户手册或操作手册，应对照手册逐条进行操作和观察。

8.3.1.6 强度测试应包含以下内容：

a) 性能的强度测试;

b) 降级能力的强度测试;

c) 系统健壮性测试;

d) 系统饱和测试。

注：强度测试在某种程度上被看作性能测试的延伸，能够测出软件功能、性能的实际极限。

8.3.1.7 余量测试应包含以下内容：

a) 测试全部存储量的余量;

b) 测试输入、输出及通道的余量;

c) 测试功能处理时间的余量。

8.3.1.8 安全性测试应包含以下内容：

a) 进行软件安全性分析，在软件需求中明确每一个需求的危险状态及导致危险的可能原因，在测试中全面检验软件在这些危险状态下的反应;

b) 除在正常条件下测试外，在异常条件下测试软件，以表明不会因可能的单个或多个输入错误而导致不安全状态;

c) 硬件及软件输入故障模式测试;

d) 边界、界外及边界接合部的测试;

e) 包括“0”、穿越“0”以及从两个方向趋近于“0”的输入值;

f) 在最坏情况配置下的最小和最大输入数据率;

g) 操作员接口测试包括在安全性关键操作中的操作错误，以验证安全系统对这些错误的响应;

h) 测试双工切换、多机替换的正确性和连续性;

i) 测试防止非法进入系统并保护系统数据完整性的能力。

8.3.1.9 恢复性测试应包含以下内容：

a) 探测错误功能的测试;

b) 能否切换或自动启动备用硬件的测试;

c) 在故障发生时能否保护正在运行的作业和系统状态的测试;

d) 在系统恢复后，能否从最后记录下来的无错误状态开始继续执行作业的测试。

8.3.1.10 边界测试应包含以下内容：

a) 软件的输入域或输出域的边界或端点的测试;

b) 状态转换的边界或端点的测试;

c) 功能界限的边界或端点的测试;

d) 性能界限的边界或端点的测试;

e) 容量界限的边界或端点的测试。

8.3.1.11 安装性测试应包含以下内容：

a) 不同配置下的安装和卸载测试;

b) 安装规程的正确性的测试。

8.3.1.12 敏感性测试应包含以下内容：

a) 发现有效输入类中可能引起某种不稳定性的数据组合的测试;

b) 发现有效输入类中可能引起某种不正常处理的数据组合的测试。

8.3.2 实施步骤

8.3.2.1 测评策划

a) 确定测评充分性要求。根据软件的重要性和完整性级别，确定测评范围所要求的软件需求覆盖程度。

b) 确定测评终止的要求。指定测评过程正常终止的条件(如测评的充分性要求是否达到)并确定导致测评过程异常终止的可能情况。

c) 确定需要测评的软件特性。根据软件测评合同(或项目计划)及软件需求规范的描述确定软件的功能、性能、状态、接口、数据结构、设计约束等内容和要求并对其标识。从中确定需测评的软件特性。

d) 确定测评需要的技术和方法，如测试数据生成和验证技术、测试数据输入技术、测试结果获取技术、是否使用标准测试集等。

e) 编写软件确认测评计划并通过评审。测评计划应包括 8.3.2.1 中的各条内容。

8.3.2.2 测试设计

8.3.2.3 测试执行

8.4 评价

软件确认测试完成后，应根据以下准则和方法对软件进行评价：

a) 可参考 GB/T 28808—2021，从被测软件的功能性、可靠性、效率、易用性、维护性和可移植性等方面对软件质量进行评价。

b) 功能性：

1) 正确性。统计软件规定功能项，分解测试功能项，验证测试功能项，包括未正确实现的功能项、计算功能正确性、回归测试后功能正确性。

2) 完整性。统计测试验证测试功能项，未完全实现功能项，占全部功能的百分比;计算功能完整性。

c) 可靠性：

1) 容错能力。描述软件容错性处理措施，对容错能力进行评价。

2) 安全性措施。描述软件安全性处理措施，对安全性措施进行评价。

3) 针对测试用例的失效密度。统计设计测试用例个数，执行个数，未通过个数;计算针对已执行测试用例的失效密度，回归测试后失效密度。

d) 效率：

1) 时间特性。通过实际测试结果及与指标要求对比，对软件响应、处理时间和吞吐量满足要求的情况进行评价。

2) 资源特性。通过实际测试结果及与指标要求对比，对软件所使用的资源数量及其使用时间满足要求的情况进行评价。

e) 易用性：

1) 易理解性。对文档从用户的角度是否完整地描述了软件的功能和使用流程进行评价。

2) 易操作性。对错误操作的防范能力、错误提示的准确性、错误提示的充分性方面进行评价。

f) 维护性：

1) 易分析性。对为诊断缺陷或失效原因及为判定待修改的部分的能力进行评价。

2) 易改变性。对软件产品使指定的修改可以被实现的能力进行评价。

3) 稳定性。对软件产品避免由于软件修改而造成意外结果的能力进行评价。

4) 易测试性。对软件产品使已修改软件能被确认的能力进行评价。

5) 维护性的依从性。对软件产品遵循与维护性相关的标准或约定的能力进行评价。

g) 可移植性：

1) 适应性。对软件产品无需采用额外的活动或手段就可适应不同指定环境的能力进行评价。

2) 易安装性。对软件产品在指定环境中被安装的能力进行评价。

3) 共存性。对软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力进行评价。

4) 易替换性。对软件产品在同样环境下，替代另一个相同用途的指定软件产品的能力进行评价。

5) 可移植性的依从性。对软件产品遵循与可移植性相关的标准或约定的能力进行评价。

h) 是否满足 5.4 中 d)~ f)的要求。

i) 是否满足 8.2 测评技术要求。

8.5 测评总结

测评总结应按照 4.7.6、8.4 的要求执行，根据软件需求规范、软件确认测评计划、软件确认测试说明、测试执行记录和软件问题报告单等，编写软件确认测评报告，对测试工作进行总结，对被测软件进行评价。

9 系统测试及评价

9.1 测评对象与目的

测评对象应为包含一个或几个软件的上一层软件系统。

测评目的是在真实系统工作环境或满足 4.3 环境要求的系统仿真环境下考核各软件之间能否协调正确工作，是否符合软件系统设计说明或软件系统设计方案的要求，并对软件进行质量评价。

9.2 测评技术要求

9.2.1 通用要求

系统测评应符合以下技术要求：

a) 按照 8.2.1 通用要求，根据系统需求规范中对软件的需求，对软件系统进行测评;

b) 应测评软件配置项之间及软件系统与硬件之间的接口;

c) 系统测试的安全完整性要求符合表 A .5 的规定。

对不同的软件系统，可根据软件测评计划、软件系统的重要性及安全完整性等级等要求对上述内容进行裁剪。

9.2.2 进入条件

系统测试应符合以下进入条件：

a) 具备系统需求规范并受控;

b) 系统中的软件都通过了软件确认测试;

c) 软件系统可运行在工作环境或满足 4.3 要求的系统仿真环境下。

9.2.3 通过条件

系统测试通过条件应满足 4.7.7 的要求。

9.2.4 测评文档

系统测评工作完成后形成的文档应包括：

a) 系统测评计划;

b) 系统测试说明;

c ) 系统测评报告。

9.3 测试

9.3.1 测试内容

在系统测试中，按照系统需求规范中规定的软件系统结构，将各软件配置项集成为相应级别的软件系统并对其进行测试，以检验软件是否满足系统需求规范、系统设计方案等规定的要求。测试内容至少应包括功能测试、性能测试、接口测试，必要时，还应包括余量测试、强度测试、安全性测试、恢复性测试、边界测试、安装性测试、敏感性测试等内容。具体内容参见 8.3.1。

9.3.2 实施步骤

9.3.2.1 测评策划

测评策划应满足 4.7.2 的要求并包含但不限于以下内容。

a ) 确定测评充分性要求。根据软件的重要性和完整性级别，确定测评范围所要求的系统需求覆盖程度。

b) 确定测评终止的要求。指定测评过程正常终止的条件(如测试充分性是否达到要求)并确定导致测评过程异常终止的可能情况(如接口错误)。

c ) 确定需要测评的软件特性。根据软件开发合同或系统需求规范的描述确定系统的功能、性能、状态、接口、数据 结构、设计 约束 等内 容和 要求，对其 标识。并从 中确 定需 测评 的软 件特性。

d) 确定测评需要的技术和方法，如测试数据生成和验证技术、测试数据输入技术、测试结果获取技术、是否使用标准测试集等。

e ) 编写系统测评计划并通过评审。测评计划应包括 9.3.2.1 中的各条内容。

9.3.2.2 测试设计

9.3.2.3 测试执行

9.4 评价

系统测试完成后，应根据以下准则和方法对软件进行评价：

a) 是否满足 9.2 测评技术要求;

b) 是否满足 8.4 中 a)~ h)的要求。

9.5 测评总结

测评总结应按照 4.7.6、9.4 的要求执行，根据系统需求规范、系统测评计划、系统测试说明、测试执行记录和软件问题报告单等，编写系统确认测评报告，对测试工作进行总结，对被测系统进行评价。

附录 A

(规范性)

软件安全完整性等级要求

A.1 总述

表 A . 1~ 表 A .5 与本 文件 的正 文条 款相 关联，用以 说明 符合 性的 实现 方法。其中 细化 表格，即表 A .6~表 A .12 是对条款表格中某些条目的扩展(例如：表 A .8 是对表 A .1 中“静态分析”的扩展)。

每个软件安全完整性等级对表格中的每项技术或措施都有要求。在本文件中，轨道交通装备系统软件安全完整性等级 1 和安全完整性等级 2 对于每项技术或措施的要求是相同的，安全完整性等级 3和安全完整性等级 4 对于每项技术或措施的要求也是相同。表中“M ”“HR ”“R ”“— ”“NR”的含义与GB/T 28808—2021 一致。

A.2 条款表

软件安全完整性等级要求按表 A .1~表 A .12 执行。

表 A.1 软件单元测试要求

表 A.2 软件集成测试要求

表 A.3 软件硬件集成测试要求

表 A.4

软件确认测试要求

表 A.5

系统测试要求

表 A.6 编码规范

表 A.7 动态测试

表 A.8 静态分析

表 A.9 功能/黑盒测试

表 A.10 性能测试

表 A.11 代码测试覆盖率

表 A.12 建模

附录 B (资料性)静态测试

B.1 质量度量

B.1.1 概述

从软件自身的性质而不是从它的开发或测试历史来预测程序的属性。这些模型评价软件的一些结构性质并将它们与一些期望的属性(如复杂度)关联起来。在程序复杂度度量中，使用比较广泛的方法有：代码行度量法、霍尔斯特德(Halstead)方法、麦克凯(McCabe)方法。

B.1.2 代码行度量法

代码行度量法是统计一个程序模块的源代码行数目，并以源代码行数作为程序复杂性的度量。它的前提是程序复杂性随着程序规模的增加不均衡的增长，以及控制程序规模的方法最好是采用分而治之的办法。

B.1.3 Halstead 复杂性测度

基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。

B.1.4 McCabe 方法

它是一种主要的软件质量度量方法，它基于以下前提：

a) 程序的复杂性很大程度上取决于程序控制流的复杂性;

b) 单一的顺序程序结构最简单循环和选择所构成的环路越多程序就越复杂。

McCabe 方法是一种基于程序控制流的复杂性度量方法，它定义的程序复杂性度量值又称环路复杂度，McCabe 环路复杂度度量值实际上是为软件测试的难易程度提供了一个定量度量的方法，同时间接地表示了软件的可靠性。

B.2 静态分析

B.2.1 概述

静态分析一般包括边界值分析、控制流分析、数据流分析和接口分析。此外，静态分析还可以完成下述工作：

a) 提供间接涉及程序问题的信息：

1) 每一类型语句出现的次数;

2) 所有变量和常量的交叉引用表;

3) 标识符的使用方式;

4) 过程的调用层次;

5) 违背编码规则;

6) 程序结构图和程序流程图;

7) 子程序规模、调用/被调用关系、扇入/扇出数。

b) 进行语法/语义分析，提出语义或结构要点，供进一步分析;

c) 进行符号求值;

d) 为动态测试选择测试用例进行预处理。

静态分析常需要使用软件工具进行。 静态分析是在程序编译通过之后，其他静态测试之前进行的。

B.2.2 边界值分析

程序的输入域被划分成若干输入类别。测试宜包括每个类别的边界值和极限。测试检查规格说明的输入域的边界与程序的边界是否一致。在直接和间接转换中，0 值的使用通常容易出错，应特别留意：

a) 除数为 0;

b) 非打印控制符;

c) 栈或链表元素为空;

d) 空的矩阵;

e) 0 表项。

输入(参数)的边界通常直接对应于输出范围的边界。宜编写测试用例使得输出达到其限值。 同时也要考虑，是否可指定测试用例使它的输出超出规格说明的边界值。

B.2.3 控制流分析

控制流分析是使用控制流程图系统地检查被测程序的控制结构的工作。控制流按照结构化程序规则和程序结构的基本要求进行程序结构检查。被测程序不包含这些要求：

a) 转向并不存在的语句标号;

b) 没有使用的语句标号;

c) 没有使用的子程序定义;

d) 调用并不存在的子程序;

e) 从程序入口进入后无法达到的语句;

f) 不能达到停止语句的语句。

控制流程图是一种简化的程序流程图，控制流程图由“节点 ”和“弧 ”两种图形符号构成。

B.2.4 数据流分析

数据流分析是用控制流程图来分析数据发生的异常情况。这些异常包括被初始化、被赋值或被引用过程中行为序列的异常。数据流分析也作为数据流测试的预处理过程。

数据流分析首先建立控制流程图，然后在控制流程图中标注某个数据对象的操作序列。遍历控制流程图，形成这个数据对象的数据流模型，并给出这个数据对象的初始状态，利用数据流异常状态图分析数据对象可能的异常。

数据流分析能够查出引用未定义变量、对以前未使用的变量再次赋值等程序差错或异常情况。

B.2.5 接口分析

接口分析主要用在程序静态分析和设计分析。接口一致性的设计分析涉及模块之间接口的一致性以及模块与外部数据库之间的一致性。程序的接口分析涉及子程序以及函数之间的接口一致性，包括检查形参与实参的类型、数量、维数、顺序以及使用的一致性。

附录 C (资料性)动态测试

C.1 概述

动态测试是建立在程序的执行过程中。根据对被测对象内部情况的了解与否，分为黑盒测试和白盒测试。

在软件单元测试时一般采用白盒测试，软件集成测试及软件硬件集成测试一般白盒测试和黑盒测试结合使用，软件确认测试及系统测试时一般采用黑盒测试。

C.2 黑盒测试方法

C.2.1 功能分解

功能分解是将需求规范中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。步骤如下：

a) 使用程序设计中的功能抽象方法把程序分解为功能单元;

b) 使用数据抽象方法产生测试每个功能单元的数据。

功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能由其下一层功能定义。按照功能层次进行分解，能够得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。

数据抽象中，数据结构能够由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集合。程序的每一个输入和输出量的取值集合用数据抽象来描述。

C.2.2 等价类划分

等价类划分是在分析需求规范的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试用例。步骤如下：

a) 划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合;

b) 划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合;

c) 为每一个等价类定义一个唯一的编号;

d) 为每一个等价类设计一组测试用例，确保覆盖相应的等价类。

C.2.3 边界值分析

边界值分析是针对边界值进行测试的。使用等于、小于和大于边界值的数据对程序进行测试的方法就是边界值分析方法。步骤如下：

a) 通过分析规格说明，找出所有可能的边界条件;

b) 对每一个边界条件，给出满足和不满足边界值的输入数据;

c) 设计相应的测试用例。

对满足边界值的输入能够发现计算差错，对不满足的输入可以发现域差错。该方法会为其他测试方法补充一些测试用例，绝大多数测试都会用到本方法。

C.2.4 因果图

因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一

列设计一个测试用例。步骤如下：

a) 分析程序规格说明，引出原因(输入条件)和结果(输出结果)，并给每个原因和结果赋予一个标识符;

b) 分析程序规格说明中语义的内容，并将其表示成连接各个原因和各个结果的“ 因果图”;

c) 在因果图上标明约束条件;

d) 通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表;

e) 把判定表中每一列表示的情况生成测试用例。

如果需求规范中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，以至于根据因果图得到的测试用例数目非常大，此时不宜使用本方法。

C.2.5 判定表

判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相应要执行的操作构成规则，条目中的每一列是一条规则。

条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试用例。

建立并优化判定表，把判定表中每一列表示的情况写成测试用例。

该方法的使用有以下要求：

a) 规格说明以判定表形式给出，或是很容易转换成判定表;

b) 条件的排列顺序不会影响执行哪些操作;

c) 规则的排列顺序不会影响执行哪些操作;

d) 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则;

e) 如果某一规则的条件得到满足，将执行多个操作，这些操作的执行与顺序无关。

C.2.6 随机测试

随机测试指测试输入数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试。

C.2.7 猜错法

猜错法是有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试用例的方法。

C.2.8 正交实验法

正交实验法是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种科学的实验设计方法。

利用正交实验法来设计测试用例时，首先要根据被测软件的规格说明书找出影响功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当作状态，生成二元的因素分析表。然后，利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的测试用例的数目将大大减少。

C.3 白盒测试方法

C.3.1 控制流测试

控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。

所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。常用的覆盖如下：

a) 语句覆盖：要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被执行一次，语句覆盖在测试中主要发现出错语句;

b) 分支覆盖：要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖;

c) 条件覆盖：要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次;

d) 条件组合覆盖：要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖 ”和“条件覆盖 ”的各种要求;

e) 路径覆盖：要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。

以上各种覆盖的控制流测试步骤如下：

a) 将程序流程图转换成控制流图;

b) 经过语法分析求得路径表达式;

c) 生成路径树;

d) 进行路径编码;

e) 经过译码得到执行的路径;

f) 通过路径枚举产生特定路径的测试用例。

C.3.2 数据流测试

数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。

数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。

数据流测试步骤如下：

b) 在每个链路上标注对有关变量的数据操作的操作符号或符号序列;

c) 选定数据流测试策略;

d) 根据测试策略得到测试路径;

e) 根据路径可以获得测试输入数据和测试用例。

动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿着与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。

C.3.3 程序变异

一种差错驱动测试，是为了查出被测软件