指挥自动化信息系统软件鉴定测评情况分析与建议

刘军

关键词 大型指挥自动化信息系统 鉴定测评 分析

1概述

大型指挥自动化信息系统作为情报支持的主要装备，具有以下特征：（1）信息处理数据量大，速度快。在指挥自动化系统中，各个分系统和数据处理组合之间采用了数字化的数据交换方式，并且最快的每几秒甚至几毫秒交换一次数据，每次达数百个字节，要求处理的数据量很大;（2）控制复杂性高，系统包括多个分系统及其组合或设备，有很多状态量和数据量，并且其周期不尽相同，系统软件要对它们进行统一管理，逻辑关系非常复杂;（3）实时性要求强，各个分系统和数据处理组合之间的数据交换周期是不同的，指控计算机按照统一的时序来协调分系统的工作，实现多个设备的同步。一旦在实时性方面出现错误，就会造成整个系统的失败;（4）可靠性要求高，系统很小的失误可能引起重大损失。所以，系统中指挥控制系统的仿真与测试是非常重要的，在飞行试验前要对指挥自动化系统进行大量的测试和验证工作。

针对本类软件，目前已开展了不少的鉴定测评工作，从顶层的管理要求上与嵌入式软件系统没有区别。本文根据前期工程实践情况，将指挥自动化信息系统软件鉴定测评工作中的经验、存在的问题和建议进行总结。

2软件特点

大型指挥自动化信息系统软件主要特点包括：（1）多为非嵌入式软件，使用多任务操作系统、Oracle数据库等基础商用软件，硬件设备也多采用商用服务器、工作站等，大型指挥自动化信息系统作为装备，多以软件系统的形式进行软件鉴定;（2）规模巨大，一般在几十万甚至上百万行，而对于如此巨大的软件系统软件的需求分析、设计文档内容相对单一，对之前研制的项目进行过统计汇总，发现有的软件需求文档的描写力度是平均每条软件需求对应一万行左右的程序;（3）系统职责分层、数据分布处理，往往将系统划分为分系统、子系统以及配置项等，不同的配置项部署于支持层、传输层、应用层等，处于不同层次的配置项行使的职责不同，支持层、传输层等配置项的功能在系统中对用户不可见，应用层配置项的功能需要经由支持层、传输层的功能协助完成;（4）体系结构构成的成分较复杂，有通用配置项/ 构件、系统共用配置项/ 构件等，这些配置项/ 构件的开发单位、技术状态和主管研制部门不同，技术和管理性因素都很多，不完全受控于系统鉴定;（5）人机交互多，系统的可用性、易用性必须符合用户的使用习惯和使用需要，受人员影响很大，是使用需求驱动的软件系统。

3鉴定测评情况分析

3.1研制过程分析

过程控制：针对此类软件系统，主管机关一直强调其为“永远不交钥匙的系统”，顾名思义，该系统无论是鉴定过程中，还是鉴定交付之后，需要研制单位永远无条件的给予技术支持和维护。这种观念本身是正确的，软件装备研制的目的是让用户用好装备，满足其使用需求是软件装备的最终目标。但是，有些研制单位却因此产生误解，认为软件即使交给用户队也可以随时更改，不用控制版本，导致研制过程不规范，同时给测评过程带来了巨大的困难。

软件重用：由于此类软件系统功能需求多，程序规模大，因此研制单位在软件需求分析和开发中，一般会选择较为成熟的软件构件或商用软件进行重用集成，以期降低研制成本，提高软件的可靠度，但会造成3 个问题。一是对重用的软件/ 构件是否适用于本系统，调研不充分，集成后（有时到交付阶段）发现此类问题但又难于更改;二是重用或购买的软件/ 构件有缺陷无人维护;三是此类软件/ 构件的问题在某个分系统中暴露和更改后，没有同步更改到其他分系统。

内部测试情况参差不齐：研制阶段过程中对软件的内部测试不充分，有时仅在研制开始阶段进行了测试，且测试仅做到大功能的覆盖，后续软件更改后未进行测试，许多问题留到了鉴定阶段。

软件的文档质量一般不高，往往软件功能和设计等技术内容高度概括。一是出于对本单位软件知识产权的保护，担心文档写得太细或涉及软件算法会泄露单位的核心技术;二是受时间、进度的限制，软件文档跟不上软件更新的速度，只能先更改软件文档在升级文档，因此常出现文文不一致、文实不相符的情况[1] 。

3.2鉴定测评过程分析

时间因素与节奏：鉴定测试是软件系统交付之前的重要质量保障环境之一，软件测评质量和进度受到研制进度的影响。理论上进入设计鉴定阶段的一个重要标志是软件技术状态固化，由于指揮自动化信息系统使用需求驱动和“不交钥匙”的特点，技术状态固化几乎不可能。根据用户需求软件的功能、界面和操作流程处于一个始终变化的状态，软件的更改会包含测试中发现问题和用户使用的要求，这就给鉴定测评工作带来了巨大的挑战和制约。

测试策略方面：由于指挥自动化系统往往由多个配置项组成，在有限的测试时间内如何突出重点提高测试质量是很重要的测试策略问题，如果按照对装备软件的测试策略，过分强调配置项测试的测试级别问题，会忽略本类系统的结构特点。针对系统中多数软件配置项不能单独运行实现系统功能的情况，对配置项之间组合能力的验证不充分，容易造成“只见树木不见森林”的问题。

测试环境方面：测试环境多是以系统集成联试为目的开发的，难以支持软件的有些接口测试、甚至部分软件的功能测试，相应的测试用例只能通过代码审查加以验证。此外，指挥自动化信息系统测试环境难于与实装环境完全一致，测评单位甚至研制单位都不能准确获得网络拓扑结构、电磁干扰情况等信息，受资金限制，研制单位也很难提供与实装一致的高配置服务器等设备，只能按研制方和测试方现有条件和理解在尽可能最相似环境中进行测试。

文档质量和人员配合方面：由于研制单位软件需求过于粗放，对软件测试的充分性依赖于软件测试人员的沟通能力、系统理解能力和对背景的了解程度，同时依赖测试人员的责任心。

4过程改进建议

通过指挥自动化信息系统的鉴定测评工作，本文主要从测评的角度和对研制过程改进的引导方面提出以下建议。

4.1多层次、多途径控制软件的质量

（1）引导研制单位加强内部测试，加大内部测试的检查/ 评审力度，内部测试以软件单元和配置项测试为重点，测试功能、接口、边界乃至性能等方面的正确性，尽可能暴露软件问题，这部分工作在后期系统集成后不易暴露，带来的影响和更改风险很大;提交评测时，应出具内部测试报告。

（2）建议主管机关适当调整鉴定测评与用户试验试用严格分开的程序，采用鉴定测评与用户试验试用迭代前进的工作方式。由于“软件装备”人机交互量大、使用需求驱动软件需求、在用户的使用中系统不断成熟，而软件鉴定测评解决软件与研制总要求的符合性问题，用户试用可解决“软件装备”可用性、易用性问题，因此建议在软件鉴定测评后研制单位解决主要问题，即可提交用户试验试用，在用户提出更改意见后，更改程序并进行回归测试，如此几轮，可将问题逐步收敛，最终满足鉴定测评的要求，基本达到满足用户使用要求的目标[2] 。

4.2加强实验验证平台和测试环境建设

对于“软件装备”，研制方在立项研制之初就应该充分考虑试验验证平台和测试环境的搭建，将之作为研制工作的一部分，并应该充分考虑经费投入。系统级测评环境构建应借助一定的实物设备，构建的半实物的系统级测试环境，对于指挥信息化装备，也可构建全数字的系统级测试环境。构建的环境应苛刻或等效于实际使用环境，能够支持系统边界外异常数据的输入能力，能够模拟软件运行极限状态的外部环境条件，支撑全过程的软件配置项之间交互数据的采集和重演。如图1 所示，对于被测系统而言，构建系统测试的关键是外围环境的模拟，如果外围环境能以软件模拟的方式实现的，尽量以运行软件的方式实现;对于外围实物难以直接模拟的，可以增加一层实物设备[3]。

4.3重视系统级测试，加大系统级测试和功能组合测试力度

鉴定测评工作应重点进行系统级测试，严格验证“软件装备”对研制总要求的任务使命和任务功能等使用要求的满足程度。其中，系统级测试是指将子系统、分系统乃至系统均作为独立运行保障用户使用的系统进行完整、全面的测试。经历了软件内部测试（单元测试、部件测试、配置项测试、系统联试）、第三方评测，系统装备是否还需要开展系统级测试？ 答案是肯定的，因为这些测试都不能替代系统级测试工作。据不完全统计，软件质量问题中系统级问题占20%以上。事实上，一方面，系统级测试是对配置项测试的补充，可以发现配置项测试中遗漏的问题，另一方面，系统级测试可以发现配置项之间工作不协调的问题，是软件测试中不可或缺的一部分。

4.4注重测试策略的实效性

由于“软件装备”规模巨大，进行全面的代码审查不太现实，即使进行10%的代码审查也要审查几万行或十几万行（不包括被审查范围相关的程序量），审查规模过于庞大，带来的开销和时间周期对于鉴定工作均可能难以承受，因此建议不以代码审查比例评价测试，关注代码审查范围的选择原则和理由是否合理、充分。

“软件装备”需求复杂，制约功能的进入和状态转移的因素很多，有些和具体设备情况、用户使用习惯等有关，需要通过数据库或配置文件加以约束;软件运行流程复杂，有些功能软件运行路径长，多个子系统或配置项配合才能完成一个测试用例，对整个系统来讲可用较少的测试用例对软件做较充分的验证，有些功能软件运行路径短则需要大量的测试用例来覆盖，因此每百行测试用例的个数不是衡量测试的唯一标准，应具体情况具体分析。

4.5重视用户需求，加强需求管理

用户需求驱动的模式决定了“软件装备”需求变化大的特点，建议加强需求评审和需求变更控制，尤其是在设计定型过程中严格控制需求变更，对需求改动量、变化内容进行分析;測试需求应根据软件需求的变更及时更新，分析需求变更对已有需求的影响，及时调整测试内容;加强需求评审，一项需求改动应将与该需求相关的总体人员、软件设计师、测试人员聚到一起，对需求进行评审并提交详尽的软件更改单，详细描述更改原因、更改内容及影响域分析、验证措施。

4.6严格控制重用/ 外购软件质量

针对“软件装备”构成系统的成分较复杂的特点，建议研制单位在系统研制伊始应确保共用软件配置项的质量，选择已通过鉴定测评的成熟软件，或安排专门的鉴定测评，共用软件的质量风险应在鉴定测评开展之前排除，鉴定测评开展时研制主管部门和定办协商明确鉴定测评的范围，规定非测评范围的软件的使用原则和发现问题的处理方法和通报途径;对于多个系统或子系统共用的构件/ 软件，应严格配置管理和配管检查机制，避免造成型号内版本不一致的情况。在严格配置管理的前提下，可在某个子系统中对共用的构件/ 软件进行全面测试，其他子系统直接采信结果[4] 。

5结束语

软件测试在保障软件质量方面起发挥着重要作用，通过软件测试发现并弥补的软件缺陷非常多。在鉴定评测中若能从管理要求、测试技术、测试流程、测试策略等方面进行不断改进与完善，必能更好保证鉴定测评的质量，从而为指挥自动化软件质量提供更大保障。