指挥自动化信息系统改进类软件测试实施研究

刘军

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

1 引言

随着指挥自动化系统使用环境复杂性日益提升，新的需求迫使大量系统需要在已定型状态做硬件、软件的技术改进，提升战斗力。改进系统的硬件需要通过可靠性试验、物理试验等检验装备的相关性能指标，软件则需要通过软件测试、系统联试保证软件实现的正确性、性能指标的达标情况。验证过程中，这些软件如果做全面测试，在资源和进度要求上很难保证，因此大多采用回归测试，这就和评测组织技术能力、测试人员的责任性存在很大关联，过程和质量很难控制，往往测试结果与使用部门、系统总体部门所关心的内容存在一定偏差。因此，针对这些改进类软件如何启动测试、测试内容是什么、采用的测试环境是否合理以及对针对已定型技术状态的更改影响域所展开的分析等等都是需要研究和探讨的，用完善的操作规程、技术指导标准作为要求，能够有效的保证软件测试验证的质量，约束测试实施过程，提升测试充分性。本文档主要针对改进类软件特点、针对改进类软件问题和原因进行分析并提出提高该类软件质量的方法与措施。

2 指挥自动化信息系统软件特点

大型指挥自动化信息系统软件大多属于列为主要装备研制项目和一般装备研制项目的软件，其主要特点包括：

（1）多为非嵌入式软件，使用多任务操作系统、Oracle数据库等基础商用软件，硬件设备也多采用商用服务器、工作站等，大型指挥自动化信息系统作为装备，多以软件系统的形式进行软件定型。

（2）规模巨大，一般在几十万甚至上百万行，而对于如此巨大的软件系统软件的需求分析、设计文档内容相对单薄，对之前的项目进行过统计汇总，发现有的软件需求文档的描写力度是平均每条软件需求对应一万行左右的程序。

（3）系统职责分层、数据分布处理，往往将系统划分为分系统、子系统以及配置项等，不同的配置项部署于支持层、传输层、应用层等，处于不同层次的配置项行使的职责不同，支持层、传输层等配置项的功能在系统中对用户不可见，应用层配置项的功能需要经由支持层、传输层的功能协助完成；而从用户使用角度来看，使用功能是由多个软件配置项/构件组合共同完成的，单一配置项/构件不能实现用户的使用功能，配置项和系统需求的界限不易清晰的区分，分系统和子系统均是独立运行和保障用户使用的一个完整系统。

（4）人机交互多，系统的可用性、易用性必须符合用户的使用习惯和任务需要，受人员影响很大，是使用需求驱动的软件系统。

（5）软件多技术状态，指挥自动化信息系统需要满足试验、演习、应急任务等多种任务的需要，指挥自动化信息系统软件随体系组成、任务需求、互联对象状态的不同需要同时具备多个技术状态。

（6）研发过程软件逐步完善齐套，指挥自动化信息系统的功能和模型算法需要在试验和仿真验证中不断完善。系统研制的每一阶段，指挥自动化信息系统应具备参与试验和仿真的基本功能，随着验证结果逐步迭代升级。

（7）交互关系变化频繁、互操作性验证难度大。

指挥自动化信息系统对外互联对象多，许多交互对象处于研制状态，通信协议和逻辑需要随交互对象的研制过程进行修改。因此，目前装备软件所有软件齐套、技术状态固化后开展软件定型测试的模式，不适用于指挥自动化信息系统软件的管理。因为软件在持续迭代、缺乏一个像装备软件那样稳定的状态；指挥自动化信息系统的配置项对于互联互通互操作的验证有较高的要求，需要制定新的测试策略。

3 指挥自动化信息系统改进类软件测试研究的意义及现状

目前，国内装备软件大量存在改进情况，改进后软件开展鉴定测评，测评单位所依据的还是实施软件测评的各类国军标和内部体系文件，针对改进类软件没有针对性的标准，导致部分软件存在测试不充分的情况。针对现行有效的标准，课题组进行了调研，范围涉及国家标准、军用标准、行业标准共四类。调研内容包括：

（1）收集现行有效的国标、国军标和行业标准中对软件测试过程、软件维护的相关内容，分析和了解现有标准中的要求；

（2）收集软件研制过程的现状，分析整理软件的专业特点、种类等；

（3）分析软件测试类标准规范，针对软件更改导致的软件测试内容，分析标准中是否给出了具体的指导要求，明确需要细化和补充的内容。

通过调研结果，发现这些标准中，对软件测试给出了定义并提出了要求，但对于如何实施改进类软件测试缺少定义和指导，面对航天装备发展和改进的长远需求，该类软件会越来越多，控制该类软件测试质量、规范测试过程是必须开展的工作。针对改进类软件没有针对性的标准，这也是目前系统装备软件改进后开展鉴定测评所需要迫切解决的问题。

4 指挥自动化信息系统改进类软件缺陷及产生原因分析

研究主要装备软件研制特点，总结相关测试数据，整理软件缺陷与失效等数据，在对指挥自动化信息系统测试发现的问题分析中，发现问题有以下几种：

（1）软件设计问题；

（2）软件功能实现不完全或实现错误；

（3）编程语言问题；

（4）文档问题；

（5）版本管理问题；

对软件问题进行分析，发现问题产生原因有以下几种情况：

（1）软件设计问题：总体人员对工作流程认识不足，导致模型设计有缺陷。

（2）软件功能实现不完全或实现错误：1.更改模型时，总体人员对影响域分析不到位，本次修改未所有受影响的软件配置项进行分析，导致相关软件修改不到位，系统功能无法实现设计要求；2.模型描述有歧义，设计师对模型的理解与总体人员不一致，导致软件实现与设计要求不一致；3.设计师对负责的软件配置项影响域分析不全面，未对所有受影响的功能进行相应修改，功能实现不完全；或对新增功能对原有功能影响分析不充分，导致新增与原有功能存在冲突；4.设计师修改过程中本身引入的程序问题：包括功能与设计不一致、功能实现不正确、编程语言问题等。

（3）编程语言问题：设计师修改过程中本身引入的程序问题，如编程语言问题等。

（4）文档问题：设计师文档描述错误，导致文实不一致，如文档描述了多余功能（程序没有实现），程序更新后未对文档进行更新，程序有更改但文档未描述。

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

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

（7）软件的文档质量一般不高，往往软件功能和设计等技术内容高度概括，软件更改单描述简单。一个原因是出于对本单位软件知识产权的保护，担心文档写得太细或涉及软件算法会泄露单位的核心技术，另一个原因是受时间、进度限制软件文档跟不上软件更新的速度，只能先更改软件文档在升级文档，因此常出现文文不一致、文实不相符的情况。文档编制人员也会产生文档写得越粗放、越不用随着软件的修改而更新的想法。

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

5 指挥自动化信息系统改进类软件研制过程质量提高的建议

看到以上问题产生的原因，不难发现如果在软件研制过程中采取一些措施，上述（1）-（5）问题在一定程度上是可以避免的。对此在软件研制过程中，建议从采取几个方面提高软件质量：

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

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

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

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

5.3 加强软件改进影响域分析

软件更改应对更改影响域进行分析，当软件更改量大到无法进行影响域分析时，研制单位应重新对软件文档进行重新编写；否则，应要求总体人员和相关软件设计师进行影响域分析，并影响域分析报告进行规范确保影响域分析尽量详尽。

（1）总体人员下发更改需求时，应对需求更改的影响域进行分析，需求更改原因和更改前后需求应说明，分析更改的需求影响系统那些功能，涉及到哪些软件配置项；对需各软件配置项联合实现的功能进行分解说明，说明各软件配置项需要完成的功能点或要素，召集各软件设计师对功能或协议进行说明，确保各软件设计师对系统功能理解一致。

（2）软件设计师应对分解到本软件的需求进行影响域分析，更改需求影响软件哪些功能，更改前后功能应说明，必要时需对更改功能影响哪部分代码进行说明。

（3）测试人员对更改需求以及总体和设计师的影响域说明进行分析，分析列出测试需求，对更改前后代码进行比对，确认所有更改代码是否有依据，所有更改需求是否有代码进行支撑，对没有依据的代码和多余需求反馈给设计师，设计师应对这种情况进行说明并补充相关材料。

（4）测试人员应加强使用需求场景的验证，测试人员应对系统使用场景进行分析并验证。

（5）加强系统级测试，测试人员依据更改需求以及影响域分析，设定系统任务剖面或使用场景对系统进行系统级测试。

6 指挥自动化信息系统改进类软件测试实施研究

针对指挥自动化信息系统改进类软件特点，总结相关测试数据，整理软件缺陷与失效等数据，发现需要明确：

（1）改进类软件开展测评的测评依据、测试过程；

（2）进行软件修改影响域分析，需要提供影响域分析与描述方法。

下面分别对实施措施进行具体描述。

6.1 测评依据及测试过程

6.1.1 测试依据

针对改进类软件开展测试的依据可以包括：

（1）研制总体单位提交的系统更改方案；

（2）研制方提交的软件更改说明；

（3）研制方提交的软件问题单、软件更改单、软件验证单；

（4）研制方提交的针对软件更改所编制的影响域分析报告。

6.1.2 测试目的

改进类软件开展测试的目的包括：

（1）考核软件更改是否满足系统更改方案或等效文件所规定的技术要求；

（2）考核软件更改是否对整个软件或所处系统完成技术指标造成影响；

（3）为软件系统产品质量的评价提供依据。

6.1.3 进入条件

改进类软件进入测评的前提条件，依据具体项目建议包括以下内容：

（1）运行方案说明、软件修改设计说明、更改三单、影响域分析报告等技术文档符合相关标准要求，具有唯一标识，通过评审并纳入配置管理。

（2）具备末次测试的总结报告，如：鉴定测评报告、上一轮次测评报告。

6.1.4 测试方法

改进类软件测试方法与第三方测试方法一致，包括：静态测试、动态测试，需要针对软件改进内容实施影响域分析，影响域分析方法包括：控制流分析、数据流分析。

测试方法对应的测试类型包括：

（1）静态测试类型一般包括：代码审查、静态分析、编程准则检查；

（2）动态测试类型一般包括：功能测试、性能测试、接口测试、强度测试、余量测试、人机交互界面测试、安全性测试、恢复性测试、边界测试、数据处理测试、安装性测试、容量测试、互操作性测试、敏感性测试、标准符合性测试。

6.1.5 测评过程及人员职责

测评过程包括的活动分为基本活动和项目管理相关活动两大类，基本活动包括：测试策划、测试设计和实现、测试执行和测试总结等，在测试策划中开展影响域分析活动确定测评范围；项目管理相关活动包括：需求管理、策划管理、跟踪与控制、质量保证、配置管理等。

主要人员职责分工如下：

（1）系统或项目总师的职责：

1.提出对测评的总体要求；

2.对评测单位提出的重要问题及异议问题进行审核与处理。

（2）软件研制单位的职责：

1.落实软件测试计划，按要求提交被测件；

2.负责软件版本的正确性和被测件提交的完整性；

3.总体提出需求变更的更改，总体人员需明确更改需求适用的系统使用场景，负责对系统级需求更改的影响域进行分析，编制系统/子系统影响域分析报告，内容包含：对需各软件配置项联合实现的功能应进行分解说明，说明各软件配置项需要完成的功能点或要素，召集各软件设计师对功能或协议进行说明，确保各软件设计师对系统功能理解一致，分析软件更改对整个系统运行产生的战技指标影响；

4.软件设计师负责对分解到本软件的需求进行影响域分析并编制软件影响域分析报告，内容包含：更改需求影响软件哪些功能，更改前后功能说明等，必要时需对更改对应的代码列举说明；

5.及时处理软件测评过程中反馈的软件问题；

6.参与测评单位的测评大纲、测试说明、测评报告的评审。

（3）测评单位的职责：

1.按计划开展测评项目并出具测评报告；

2.对不符合入口接收条件的被测件，有权拒收或退回；

3.测评人员应依据总体和软件设计师提交的影响域分析报告对软件更改进行影响分析，形成测评需求，并逐项验证；

4.保护研制单位知识产权，不经过研制单位同意，不得对外泄露、借阅被测件内容。

6.1.6 环境要求

测评环境需要满足改进内容的验证需求，可以使用实际装备或实验室测评环境，性能指标验证一般应使用实装环境。开展测评前，应确认测评环境的有效性及完备性。

6.1.7 问题处理

测评过程中问题处理建议的要求如下：

（1）测评单位需要审查末次测评总结报告中的不修改问题，本次测评处理意见依然是不修改的应结合改进内容确认是否会产生不良影响；

（2）测评单位需要以软件问题报告单的形式向研制单位提交测评中发现的问题；

（3）研制单位需要针对软件问题报告单的问题描述对问题进行确认和定位，组织设计人员修改软件；

（4）针对测评中发现的软件问题，如果定位为陪试软件缺陷，需要由系统总体单位提交至陪试软件研制单位进行修改；

（5）测评过程中产生的不修改问题，系统总体单位需要组织确认，关键、重要级软件缺陷应具备软件问题不修改分析报告。

6.1.8 阶段评审

阶段评审一般建议包括测评方案评审、测试设计评审和测评总结评审，评审要求如下：

（1）测评方案评审：在测试策划阶段完成测评大纲或测试计划、测试需求规格说明的编制，并组织测评方案评审，评审组成员可包括：委托方、论证单位、系统总体单位、同行专家、软件研制单位的代表，评审组长可由系统总体单位设计师担任；

（2）测试设计评审：在测试设计阶段完成测试说明的编制，并组织测试设计评审，评审组成员可包括：系统总体单位、各相关软件研制单位的代表，评审组长可由系统总体单位设计师担任；

（3）测评总结评审：在测评总结阶段完成测评报告的编制，并组织测评总结评审，评审组成员可包括：委托方、论证单位、系统总体单位、同行专家、软件研制单位的代表，评审组长一般由项目总师/副总师担任。

6.2 影响域分析

6.2.1 分析要求影响域分析要求如下：

（1）系统总体针对改进类更改需求应依据研制总要求、运行方案说明或等效文件开展影响域分析形成系统/子系统影响域分析报告；

（2）纠错类更改应依据软件修改设计说明、软件问题单或等效文件开展影响域分析形成软件影响域分析报告；

（3）测评单位应依据研制总要求、软件修改说明、软件问题单、软件更改单或等效文件以及影响域分析报告开展分析，形成测试需求；

（4）影响域分析应基于系统、系统内软件、更改所处软件三个层次，分别分析软件更改对战技指标的影响。

6.2.2 分析方法

软件改进原因分为两类：

（1）总体需求变化，即总体单位提出改进需求，要求各配置项软件设计人员进行相应更改；

（2）软件自身发现的问题。

根据软件改进原因进行分析，相应影响域分析应分为两类：

（1）自下而上分析，即总体单位提出改进需求后，总体设计人员和软件设计人员应对该改进需求对哪些配置项软件有影响进行分析，软件设计人员对改进需求对本软件的功能是否有影响进行分析，测试人员对测试需求进行分析；

（2）自下而上分析，即当某个配置项更改后应按控制流和数据流进行分析，a）软件功能更改是否对系统功能有影响，该功能会涉及哪些软件，b）软件更改是否对数据有影响，受影响的数据会输出给那个模块或软件，总体人员和相关软件设计师进行确认，测试人员对测试需求进行分析。

开展改进类软件测试，推荐采用的分析方法及要求如下：

（1）控制流的方法对软件更改实施影响域分析，逐条分析软件更改对软件工作流程控制的影响并列出受影响的功能、性能等软件需求，应具体对应到末次开展全部测试版本的最小软件需求；

（2）采用数据流的方法对软件更改实施影响域分析，逐条分析软件更改对软件数据流的影响并列出受影响的功能、性能等软件需求，应具体对应到末次开展全部测试版本的最小软件需求。

控制流分析示例：

如图1所示，假设处理过程A发生了更改，则该更改可能造成的结果有几种情况：

图1：控制流分析举例

（1）处理过程A的更改对于过程模块A（图中处理过程A所在的模块）来说，输入和输出不发生变化，程序执行时序不发生变化；

（2）处理过程A的更改造成过程模块A的执行时序发生变化；

（3）处理过程A的更改造成过程模块A的输出结构发生变化；

（4）处理过程A的更改造成过程模块A的执行时序发生变化，同时，处理过程A的更改造成过程模块A的输出结构发生变化。

对于四种情况，影响域分析的结果见表1。

表1：控制流影响域分析示例

影响域分析结果应包含：软件更改率、软件更改内容、受影响的软件需求项等，应在软件测试需求或软件测评大纲中填写影响域分析结果，填写格式见表2。

表2：影响域分析结果

7 结束语

本文针对系统装备技术能力提升又导致软件更改的现状展开研究与分析，分析了改进类软件的缺陷类型及其产生原因、改进类软件更改改原因，并明确提出了提高改进类软件质量的措施，包括明确了改进类软件开展测评的测评依据、测试过程，以及需要进行软件修改影响域分析，希望能够对软件测试、软件研制以及软件联调提供一些帮助。后续将继续深入研究回归测试技术，完善回归测试流程规范，为系统软件顺利完成每一次实验努力。