装备软件系统级测试实践与研究

刘军

（中国航天科工集团第二研究院七〇六所 北京市 100854）

1 引言

随着装备信息化程度的提升，装备的“软件密集型系统”特征日益凸显，系统的软件组成复杂，一般都会包含多达几十个处理器软件配置项以及若干个FPGA/CPLD软件配置项。软件呈现“规模庞大、结构复杂、一体化综合”的趋势，为适应未来战争对信息化、网络化、体系化使用的需求，对互联互通互操作提出了更高要求。

然而，目前对装备的软件测评仍然以单一配置项为主，软件系统层次的需求分析和架构设计，以及系统级测试验证都是薄弱环节。近几年装备软件定型测评数据分析表明，在完整、充分的配置项测试后，装备系统级测试依然能发现不少涉及系统层面的软件缺陷，它们多为配置项之间、分系统之间的协调匹配性问题，其中的关键、重要问题将直接影响装备系统任务使命的完成。重要级以上的软件质量归零问题中，有51.4%的归零问题涉及系统层面，暴露在系统联试、靶场飞行试验前。这些数据表明，尽管对软件配置项的功能、性能进行了全面验证，并通过了特定使用模式下的系统联试，但是面向使命任务的软件系统级测试验证仍然很不充分。

2 装备软件特点及系统级测试意义

目前装备软件的特点主要表现在以下几方面：

（1）大多系统装备已初步具备组网能力，部分系统还可与其他装备进行混编，与外围指挥单元通讯多元化；

（2）装备系统内部结构复杂，软件规模庞大，甚至包含多层子系统，软件规模一般在几十万至几百万行不等；

（3）为满足当前发展需求，各装备系统软件研发、硬件选型中已适应了复杂电磁环境下的能力需要，完成了相关设计内容；

（4）对于研制总要求或等效文件中提到的性能指标，在系统/子系统规格说明中，很少能做到软/硬件性能指标分离、指标实现的有效分解。

面对以上软件系统特点，传统的软件配置项测试充分暴露自身“只见树木、不见森林”的缺陷：测试力度不够，无法验证软件配置项之间的功能协调性和接口协调性。

面对复杂的使用需求、日趋庞大的装备系统软件规模，相关订购部门更需要得到的是这些装备投入到复杂战场环境中的应用能力评价，而不是单一设备和单一软件的运行能力，这样对装备软件的测试评价提出了更高的要求。软件测评从以单一配置项的功能测试为主，转变为对功能和性能考核并重，突出对面向使命任务的软件系统的考核，对体系贡献度的评估。

在此背景下，系统级软件测试能够为全面评价装备软件效能提供有效手段，为全面评价装备系统效能提供了依据。

3 软件系统级测试现状分析

目前软件系统级测试主要采用动态测试为主的策略，以装备研制总要求、系统任务书、系统需求规格说明为测试依据，在真实环境下开展测试，普遍采用的测试方法包括：

（1）基于使命任务和典型应用场景的测试。

（2）基于工作流程和控制流程覆盖的测试。

（3）专项审查：接口分析、安全性分析、时序审查、使用流程审查。

专项审查的采用弥补了装备软件缺乏有效动态测试环境的问题，可以发现各分系统或配置项对于系统需求分解、指标分解、接口协议理解不一致的问题。

（4）采用“系统特征状态验证率”的系统测试充分性量化指标度量方法，针对系统关键特征状态测试覆盖情况进行分析和测试。

4 软件系统级测试发现的问题分析及对工作的启示

4.1 软件系统级测试问题原因分析

在对各装备件系统级测试发现的问题分析中，发现有以下产生原因：

（1）系统级测试特点决定的：单个软件配置项执行没有问题，但作为系统执行时就有问题，此类问题为典型的系统级问题，配置项无法发现；

（2）系统工作流程问题，对于需要各个分系统或配置项配合才能完成的任务，任务完成过程中会暴露出配置项测试未暴露的问题；

（3）系统设计缺陷（逻辑缺陷、异常处理、边界处理、临界点处理）导致的问题；

（4）各分系统或配置项设计师对于系统模型（协议）理解不一致或不到位导致的问题；

（5）各分系统或配置项在需求分析、设计时重点关注了对其本身的要求，忽略了研制总要求等顶层输入文件中项目的设计通用要求对本分系统/配置项的相关性分析和分解；

（6）配置项测试环境和系统实装环境的差异性导致的配置项测试遗漏的部分问题；

（7）测试人员认识提高，测试用例设计足够复杂激活潜在的软件缺陷。

4.2 软件系统级测试对软件研制的启示

看到以上问题产生的原因，不难发现如果在软件研制过程中采取一些措施，上述（1）～（5）问题在一定程度上是可以避免的。对此在软件研制过程中，应采取以下措施：

4.2.1 重视软件系统需求分析与系统设计

系统需求是介于用户需求和软件需求之间的重要桥梁，是确保用户需求能正确实现的重要保障，更是系统级测试的唯一依据。提供的系统软件需求类文档中，应明确系统软件用途，重点描述系统软件的任务使命、系统能力（覆盖技术指标）、软硬件环境要求、系统/分系统软件体系结构设计等（即系统的任务流、功能流、信息流）。

存在工作状态转换的，在提供的需求类文档中，应详细说明系统软件所包含的各种工作状态、转换方式，必要时，给出状态转换图进行说明转换条件、转换点。对于各种工作方式，应描述清楚对应的能力需求组，以及参与实现的软件，推荐使用表格进行说明。

提供的需求类文档中，在对系统能力需求展开描述时，建议从系统/分系统的角度出发，对每一组能力需求进行详细描述，建议给出工作流程图、数据流图，文字描述实现路径，哪些软件参与了哪些操作，并说明执行过程中的重点数据判读要求、数据执行周期要求（处理时间分布情况），应列出研制总要求中与软件相关的所有技术指标，并进行有效分解。

提供的需求类文档中，应详细描述整个系统软件的内/外部接口通讯内容，应详细描述切实可行的安全性需求与措施。

4.2.2 加强使用总体与设计总体、设计总体与设计师的沟通

软件研制中设计总体、设计师应定期与使用总体进行沟通，这样才能保证系统贴近用户使用；设计总体和设计师定期沟通，能够消除彼此理解上的一些差异，同时形成头脑风暴，完善模型设计，提高软件质量。

4.3 软件系统级测试对软件测试的启示

基于提高软件质量的要求，只在软件验收阶段进行系统级测试又显得有些不够，那在软件研制过程中是否可以实施系统级测试呢？而软件研制过程中各软件状态不定、测试周期短，导致无法完全进行系统级测试。针对此种情况，应从软件测试的思路和方法进行改进：

（1）测试设计时应多从使用者的角度进行设计，而不应只对软件进行覆盖性测试；

（2）需对软件任务剖面进行分析，构造任务应用场景；

（3）充分考虑与软件有关的所有硬件和设备对软件的影响；

（4）测试用例设计应增加针对饱和或满负荷情况下的设计且用例应尽量复杂；

（5）测试执行时耦合度高的软件应协同测试。

4.4 软件系统级测试对软件系统联调的启示

软件系统联调一般是依据实验任务对软件系统主要功能和流程进行验证，缺乏充分性。软件系统级测试是以测试的角度对软件系统的所有设计分支进行测试，功能覆盖全面充分。在对系统级测试结果分析中，发现有些问题如果系统联调能够测试充分一些，那这些问题本可以很早就能发现。针对此种情况，应该在软件系统联调中采取以下措施，提高软件可靠性。

（1）软件系统联调应转变思想：系统联调不应只为实验任务服务，而是应该提高软件系统可靠性为目的；

（2）组织软件系统联调的总体人员应了解软件测试，以软件测试的角度结合软件系统联调本身的特点，综合考虑制定联调方案；

（3）软件系统联调依据实验任务制定联调方案时，应尽可能充分考虑系统功能，提高测试充分性；

（4）软件系统联调应多考虑异常分支、异常情况，验证系统可靠性；

（5）必要时，软件系统联调应请测试人员参与。

5 软件系统级测试存在的问题

调研多个项目的软件系统级测试，发现软件系统级测试存在以下问题：

5.1 软件系统级测试依据方面的问题

软件配置项级测试的依据是软件研制任务书、软件需求规格说明、软件用户手册等技术文档；那么装备软件系统级测评的依据应该是什么？作为软件系统级测评，既然要摸清装备的性能底数、使用的边界条件和运行的极限状态，除了装备软件之间的接口协议、用户使用需求，还应该具有描述系统软件能力和使用条件顶层技术文档，以及具备领域知识的使用约束条件，如软件系统设计方案、软件系统运行方案、软件系统能力技术要求等。

目前，通过部分测评机构开展的一些系统级测评项目来看，研制方提交的软件系统级文档，仍然以配置项级功能、性能“块状”描述为主，不能转化为系统典型应用场景的用户需求和任务需求，难以作为系统测评的依据，这就需要系统软件设计人员充分了解装备使用需求，提出与软件相关的能力需求和使用需求，测评人员根据输入的使用需求和领域知识开展对软件能力需求的验证和摸底。

5.2 软件系统级测试的方法和策略方面的问题

装备软件系统级测评主要方法应以为黑盒测试方法或灰盒测试方法为主，一般不包括代码级的白盒测试，除非对于系统级发现问题，进行问题定位和归零时进行专项的代码级白盒测试。

5.3 软件系统级测试的环境方面的问题

各项标准中都规定系统级测试需要在实装环境中测试，但在实装中测试能否保证测试充分性？有些操作不能确定不损伤装备，谁敢去操作？有些装备属于小子样装备，无法提供给测试，如果没有条件怎么办，如何给出结论？

5.4 软件系统级测试执行方面的问题

系统级测试不同于配置项测试，传统配置项测试只针对单软件单功能的验证，很少针对系统整个流程进行验证。相应地系统级测试应以贴近实际、贴近用户、贴近使用为基本原则，以摸清系统软件的性能底数、极限状态、边界条件为根本要求，尽可能发现影响用户使用、影响任务流程、影响使用效能的软件问题，而如何对系统进行测试设计、测试执行则需要建立一套有别于传统配置项测试的操作流程或指南。

5.5 软件系统级测试充分性问题

由于装备中软件数量众多、软件规模大，依据文件种类、内容繁多，有研制总要求、系统需求规格说明、工作流程描述、模型和协议等一系列文档，虽然系统需求规格说明是系统及测试的主要依据已达成共识，文档的描述应该覆盖到哪些内容、哪个层次就是完备的从技术上未有好的理论指导，因此这种覆盖是一种弱覆盖。

现阶段，系统级测试主要是基于任务使命和典型应用场景的测试，测试过程中需要构建符合测试要求的应用场景，但应用场景覆盖是否充分，并没有理论进行指导。

对于整体性，是现在大多数系统级测试最关注的，也是考虑最多的，多集中在典型工作场景测试、功能覆盖测试、工作流程测试等等，但笔者认为，真正体现系统整体性的除了以上几种覆盖性测试，更应该关注系统输出，具体为任务使命是否达成、受软件影响的工作效能是否达标。对此类系统输出的覆盖性测试在配置项级测试时往往会弱化，应在系统级测试强化。

5.6 软件系统级评估方法的问题

目前的软件测试充分性指标主要是针对程序代码的，适用于单元测试、部件测试和软件配置项测试，针对系统测试均显得无能为力。系统测试关心的是系统任务的验证充分性，针对程序代码的充分性指标显然无法适应系统测试的工程需求。

6 针对软件系统级测试现有问题的解决方法

6.1 软件系统级测试依据

细化顶层论证，提供输入依据。应在研制总要求、装备立项论证报告等顶层文件明确装备试验鉴定中软件系统级测试涉及哪些系统/分系统/子系统，每个系统包括哪些软件配置项，明确测试的软件工作过程要求以及遵循的标准规范，如果在顶层文件制定时来不及明确，应该最晚在试验鉴定初案和试验鉴定总案中明确，在军方主导下完成相关各方参与的评审，作为系统级测试顶层的管理性依据。

在技术层面，对软件系统的描述应该是有层次的，在顶层输入之下，应该按层次构建完整的装备软件系统架构，对顶层需求逐层分解，对系统需求的描述也应该本着从宏观到具体的原则，装备的应该是从任务使命和任务要求，分解到具体的分系统/子系统。而针对不同层次，应解决当前层次系统的多元性、相关性和整体性描述问题，为系统级测试提供技术输入。

6.2 软件系统级测试的方法和策略

系统级的测评需求分析，应以用户使用需求为主，结合用户使用的典型场景，覆盖系统/子系统/分系统的能力需求为基本原则开展测评需求分析，测试需求分析内容应覆盖用户使用剖面、功能剖面，对于软件的使用边界、极限状态进行验证和摸底。

系统级测试应在配置项级测试完成，软件版本状态相对固化的状态下开展，先开展分系统级，再开在子系统级，最后开展系统级测试。系统级测试设计，应按照测试需求分析，依据用户使用需求的输入组合开展测试设计，包含正常的用户使用流程和异常的用户使用流程设计。对于典型的使用场景，应增加测试用例设计密度，尽可能覆盖典型使用场景下不同输入的多种组合。

系统测试执行，应严格按照用户使用需求说明书开展测试用例的执行。对于异常流程的测试用例，应充分评估对系统实物设备的影响，避免损坏实际设备。对于测试环境不支持的测试用例，应尽可能的模拟外围的环境，提高测试用例环境的执行率。系统测试数据分析不限于对测试用例、执行过程发现的软件缺陷的数据分析，还应该对系统测试用例执行过程产生的软件配置项之间实时交互的数据进行分析。通过对该部分的数据发现系统软件配置项之间存在不协调、不一致、不正确的蛛丝马迹；通过对该部分的数据分析定量评估系统级测试覆盖性，确定测试是否可以终止；通过对该部分数据分析，定位软件故障，发现软件缺陷，修正软件错误。

6.3 软件系统级测试的环境

软件系统级测评环境构建，应借助一定的实物设备，构建的半实物的系统级测试环境，对于指挥信息化装备，也可构建全数字的系统级测试环境。构建的环境应苛刻或等效于实际使用环境，能够支持系统边界外异常数据的输入能力，能够模拟软件运行极限状态的外部环境条件，支撑全过程的软件配置项之间交互数据的采集和重演。如图1 所示，对于被测系统而言，构建系统测试的关键是外围环境的模拟，如果外围环境能以软件模拟的方式实现的，尽量以软件的方式实现；对于外围实物难以直接模拟的，可以增加一层实物设备。

图1：系统级测试环境示意图

6.4 软件系统级测试执行方法

针对装备软件研制特点以及系统测试或系统试验发现的问题，本文开展了研究，建议装备软件系统级测试应从以下两方面进行研究：

6.4.1 面向使用过程的系统级测试用例生成技术

装备软件系统使用环境复杂，使用过程综合程度高，软件系统级高精度、抗干扰、快速反应性能的考核需要在系统级集成测试环境下开展。面对复杂软件系统，测试用例是一个与被测软件的交互执行过程相对应的、由输入控制点及其输入指令或数据等要素组成的多元组的序列。装备软件系统作为复杂大系统，对于装备软件系统级测试用例的描述应包括使用环境情景想定、使用过程描述、测试激励数据三个层次。系统级测试用例的描述示意图如图2所示。

图2：系统级测试用例的描述示意图

（1）使用环境情景想定。控制系统装备软件系统级测试用例的前置条件需要想定符合实际使用过程的情景，涵盖系统要求的各个性能指标、系统功能、任务剖面等。

（2）基于UML顺序图的使用过程描述。UML顺序图可以用来描述控制系统中不同对象之间的动态交互，显示一个使用过程中涉及对象间的消息传递关系。而消息是由系统特征状态构成的，课题研究应用UML顺序图依照由系统特征状态构造的任务剖面描述控制系统的测试场景，将输入、输出及约束条件合理组合生成覆盖该场景的测试流程，提高测试充分性。

（3）针对GUI的测试激励数据生成。装备软件系统包括嵌入式软件和GUI软件，针对嵌入式软件通常采用数据文件形式的测试用例，包括时间驱动和事件响应两类用例激励方式，目前已经较好的解决了这类软件的用例生成和用例加载方式。

6.4.2 软件系统级验证技术

（1）系统级形式化验证。将组成控制系统的各分系统作为对象，构建状态图，应用形式化语言描述上层设计的软件模型规格，研究形式化方法验证系统行为正确性和完备性。状态图用于对系统模型元素的动态行为进行建模，它描述一个实体基于事件反应的动态行为，显示该实体如何根据当前所处的状态对不同的事件做出不同的反应。形成状态机模型后，定义验证规则使用CTL语句对模型进行仿真验证。

（2）系统级协议分析。调研发现，近年的系统试验所暴露出的软件问题，诱因已经不是单一软件配置项处理的特殊数据或异常数据，而是在系统/子系统内、系统/子系统外流转的数据流在实际使用过程中发生的特例，也许基于本系统，它是有效数据，但由于它到来的时序特殊、与其他数据产生了叠加、软件集成后与整系统硬件未良好匹配等因素，导致其触发软件缺陷，因此需要通过系统地分析、审查接口通讯的协议，发现设备之间接口通讯方面可能存在的潜在隐患，进一步提高软件接口以及系统的可靠性水平。协议分析技术包括接口设计与实现审查、通讯设计与实现审查两部分。

6.5 软件系统级测试充分性

针对装备软件系统级测试中的应用场景设计是否充分、任务使命是否达标的问题，现阶段本文认为基于装备系统的使用效能分析评估指标体系，构造适用于系统级测试的指标评价体系能够较好解决该问题。系统级测试最终是希望能够对系统软件的使用效能进行评价，装备系统的使用效能分析评估指标体系是用来对整个装备系统的使用效能进行评价的，而基于此构建的适用系统级测试的评价体系能够很好地贴合使用效能评价体系。那么该如何构建适用系统级测试的评价体系？本文认为应该从以下步骤进行操作：

（1）根据装备系统的使用效能分析评估的指标体系，对相关指标进行裁剪，保留软件指标或与软件相关的指标，分析出适用系统级测试的评价指标；

（2）根据系统规格说明、模型和协议等输入类文档，增补、完善软件评价指标体系（功能、性能、安全性），并最终构建适用于系统测试的指标评价体系；

（3）针对软件系统级测试的指标评价体系，依据系统规格说明、模型等文档，由功能反推应用场景，设计应用场景。

6.6 软件系统级评估方法

软件系统级测试评估不仅应该关注系统测试充分性的评估，包括用户对典型用户场景的覆盖、使用功能剖面的覆盖、软件能力项目的覆盖、系统配置项目交互数据的覆盖等；还应该对系统级的软件能力、适用条件、极限状态以及完成任务的能力给出评价的指标体系和评价方法，通过此项的评价能够给出软件系统的质量评价，为软件系统的试验鉴定提供依据和支撑。

采用“系统特征状态验证率”的系统测试充分性量化指标度量方法，针对系统关键特征状态测试覆盖情况进行分析和测试，理论上回答了面向使用任务的测试是否充分的问题。系统具有许多特征，每一特征具有若干状态，所有的系统特征状态刻画了系统的行为特性。系统特征状态测试验证的是否充分理应成为系统测试所关心的核心问题。

7 结束语

系统级测试在未来很长一段时间，将是装备鉴定或大型试验前需要面临的一道考题，现有的软件测试技术应用于系统级测试不能很好的兼顾效率和成本、满足各方对系统级测试的期望，从某种层面上来说，随着装备的快速迭代，系统级测试的有效性将会成为制约装备软件测试有效性的决定性因素，因此，加大系统级测试技术、环境、人力等资源的投入将会是必然趋势。