基于数据源识别和驱动分析的软件系统测试方法

魏 波，张慧颖，司倩然

(北京跟踪与通信技术研究所，北京 100094)

0 引言

航天测控中心软件系统主要部署于航天测控中心、测量船、二级指控中心等，完成对遥测数据、外测数据的接收、处理、显示，对测控设备的引导控制，以及向航天器发送遥控指令等功能[1]。基本的航天测控软件系统一般包括数据交换、汇集分发、遥测数据处理、外测数据处理、综合数据处理、监视显示、安控辅助判决、遥控发令等软件配置项。航天测控软件系统具有架构复杂、软件配置项多、内外接口复杂、实时性强、软件安全关键等级高等显著特点[2]，对软件测试提出了非常高的要求[3]。

软件测试的目的是发现软件错误，验证其是否满足研制任务书、软件需求、软件设计等规定的各项技术要求，并为软件质量评价提供依据[4]。依照测试级别来分，软件研制过程中，会依次进行软件单元测试、软件集成测试、软件配置项测试、软件系统测试等各个级别的测试，各级别的测试的关注点是不同的[5-6]。

软件系统测试一般在真实的系统工作环境下进行，重点检查系统所属配置项之间的接口、时序、逻辑关系等是否正确[7]，重点考核各软件配置项之间能否协调有序的正确工作[8]，是否满足软件系统设计说明的要求。开展系统测试的前提是系统包含的软件配置项都已经通过了各自的配置项测试。

1 软件系统测试的现状和困境

当前，相对于配置项测试，人们对系统测试的重视还不够，在配置项测试完成后，存在不进行正规的系统测试，直接以系统联调代替系统测试的情况，导致在联调中暴露出软件系统的诸多问题，严重影响任务进度。

根据软件工程规范要求，系统测试的输入是软件系统设计说明。软件系统设计说明中应准确分析、提取、描述软件系统需求，包括功能、性能、外部接口、适应性、安全性、操作、可靠性以及其他需求。但因人们对系统测试重视不够，导致编写的软件系统设计说明往往不够规范，关键内容缺失。

依照载人航天工程软件工程化技术标准的要求，软件系统设计说明应在系统分析与设计阶段编写，是后续编写软件配置项需求规格说明的依据。但有些时候，软件系统设计说明往往与软件配置项需求规格说明同步编写，或晚于软件配置项需求规格说明进行补写，系统级的需求往往成为了多个配置项需求的简单罗列。

以上种种情况，导致第三方评测机构在进行系统测试需求分析和测试设计时，得到的软件系统需求要么非常简单，无法作为有效的系统测试依据进行测试设计；要么是所有软件配置项需求的简单罗列，缺少系统级软件需求等关键信息，如果测试人员依照这些需求进行用例设计，就变成了系统所属各软件的配置项测试，无法体现系统测试的价值。

目前，对系统测试方法研究，大多集中于基于控制流[9]、基于场景[10-11]、基于数据流和控制流叠加[12]、基于业务流程[13]、基于操作概图(Operational Profile)[14]和基于形式化模型(Formal Model)[15]等方面，虽然取得了较好的测试效果，但仅仅适合于指挥控制、金融、电子商务等基于工作流的软件系统。

本文结合航天测控中心软件系统特点，设计了一种基于数据源识别和数据驱动分析的软件系统测试方法，能够从软件系统层面入手，快速梳理系统测试需求，提高系统测试用例设计针对性，进而提高测试效率和测试有效性。

2 基于数据识别和驱动分析的软件系统测试方法设计

航天测控中心软件系统是一个典型的数据驱动型软件系统，具有数据输入、处理和输出的典型特征，其大部分功能均由数据触发，数据的类型和状态决定了数据处理逻辑的不同分支。在具体编程实现上，各软件基本采用多线程处理架构，数据接收线程通过输入接口接收数据，根据数据类型标志放入不同的数据接收缓冲区；处理线程从数据接收缓冲区中取出数据，根据数据的要求，或进行系统行为控制，或进行数据处理并将处理结果放入数据发送缓冲区；数据发送线程从数据发送缓冲区取出数据，通过输出接口向外发送数据。

本文针对数据驱动型软件系统特点，设计了一种基于数据识别和驱动分析的软件系统测试方法，通过对系统处理数据的测试全覆盖，进而覆盖系统的绝大部分功能和性能，从而以较小的测试成本，最大程度的检验系统所属软件配置项之间的接口、时序、逻辑关系，达到系统级测试的目的。

基于数据识别和驱动分析的系统测试方法的关键技术包括数据源的识别、数据路径分析、数据状态分析、系统级数据顺序图绘制、系统测试用例设计等。该系统测试方法的一般工作流程如图1所示。

图1 基于数据源识别和驱动分析的系统测试方法工作流程图

3 关键技术

3.1 数据源识别

本文规定，系统中被注入的或自主产生的一类数据，称为一个数据源。通过定义可知，数据源的类型有两种，一种是外部数据源，即系统外部注入的数据，典型的该类数据有遥测数据、雷达测量数据、光学测量数据等。另一种是内部数据源，即系统在运行过程中，由操作人员操作控制产生，或由软件系统自主产生的数据，典型的该类数据包括遥控指令数据、综合弹道、设备引导数据、系统状态上报数据等。

识别数据源的方法主要包括3种。一是梳理软件系统设计等文档，通过系统外部接口中输入接口的描述来识别外部数据源；二是梳理系统所含的各个软件配置项的需求规格说明文档，通过功能和接口的描述，识别系统内部数据源。三是通过与操作员和系统总体人员的交互，并依靠测试分析人员的领域知识和测试经验来识别数据源。

需要说明的是，由于系统中数据传递路径较长，虽然一个数据源在系统内部流动时，格式或内容发生了变化，但我们仍然定义它为一个数据源，所发生变化的仅仅是该数据源的状态。

识别数据源的关键在于不重复、不遗漏。我们将识别的数据源，以表格的形式表示出来，该表格包含数据源描述、数据源类型、数据发起方等字段。其中数据发起方可以是外部硬件设备或外部软件系统，也可以是软件系统内部的软件配置项。在对某测控中心软件系统进行系统测试时，获取的外部数据源如表1所示，获取的内部数据源表如表2所示。

表1 某测量船测控中心软件系统外部数据源表

表2 某测量船中心软件系统内部数据源表

3.2 数据路径分析和数据状态分析

识别数据源后，下一步工作是数据路径分析和数据状态分析。数据路径分析，是指分析数据源在系统内部各配置项之间被处理、传递的路径，分析的粒度应达到配置项级别。数据状态分析则是分析和确定数据在路径中各个节点上的状态。这两个分析步骤关系紧密，且在时间上是交叉进行的，在实际测试中，可以同时进行路径分析和状态分析。

本文规定数据源首次从外部注入系统时，或首次在系统内部产生时，其状态为初始状态。当数据流出系统，或者终止在系统内部某个配置项时，其状态为最终状态。当一个数据源在系统中流动时，必然会依照数据处理流程，依次途径系统中多个软件配置项，在每流经一个软件配置项后，数据的状态一般会发生变化。

数据的状态包括数据帧格式、频率、存储介质，以及帧内各数据项的类型、字节长度、数值、单位、量纲等特性，上述特性均可以从系统的接口控制文件中获得。数据状态的变化，包括了数据帧的转发、数据帧的格式变化、数据帧的分解和重组、数据量纲的变化、数据坐标系的转换、参数值的解算、数据融合处理等。数据状态变化的正确与否，反映了系统功能的正确性。

针对每一个数据源，都要分析和记录其数据路径和状态变化，分析要素见表3。

表3 数据路径分析和状态分析要素表

3.3 基于顺序图的系统数据流向图

识别出全部数据源、并依照分析要素进行路径分析和状态分析后，下一步要对分析结果进行建模和呈现。当前，研究人员对基于UML模型的系统测试方法进行了一些研究，文献[16]通过扩展UML用例图的方法导出系统测试用例，文献[17]综合利用UML活动图和用例图信息，通过扩展活动图的方法获取系统测试信息，均取得了较好的效果。

本文设计了一种简化的UML顺序图，对系统的数据流向图进行建模。UML顺序图的主要元素为参与者和事件消息等[19]，主要用来帮助用户准确的为组成系统的各部分之间如何交互进行建模[18]。本文设计的基于顺序图的数据流向图，参与者为与该数据源有关的外部硬件设备、外部软件系统，以及系统内部所属软件配置项，事件消息为具备一定状态特征的数据。一个典型的飞船遥测数据源的数据流向图如图2所示。

图2 飞船遥测数据源的系统数据流向图

3.4 编写软件系统测试用例

设计系统测试用例，关键在于确定用例的测试输入和期望结果。以下给出依照系统数据流向图，确定测试输入和期望结果的方法。

1)测试输入:

系统测试用例的输入，取决于数据源的初始状态，通过数据流向图，可以得到数据源的初始状态。在图2中，数据源的初始状态为注入至数据交换软件配置项的原始遥测帧。

当数据的初始状态是外部注入时，测试用例的输入是外部测量设备或者测试仿真程序产生的注入数据；当数据的初始状态是由系统内部产生时，测试用例的输入就是操作员对系统的相关操作，或者软件系统自主产生的数据。

2)期望结果：

系统测试用例的期望结果，包括3个基本要素。(1)确定系统测试检查点，即在系统什么位置获取数据状态；(2)通过什么方式获取数据状态；(3)期望的数据状态应该是什么。

一般来说，数据的最终状态表明系统功能将在该点完成，该点对测试人员而言往往是可见的，因此我们将数据最终状态所处的软件配置项设置为系统测试检查点。通过查看该软件配置项的显示界面、数据文件、数据库等方式，获取数据的实际状态，并与接口控制文件中规定的期望状态相比较，验证系统功能是否正确。

图2中，飞船遥测数据源的最终状态有两处，一处是数据存储软件配置项存储的原始遥测帧，另一处是监视显示软件配置项界面显示的解算后遥测参数值，因此该测试用例将拥有两个系统检查点，在后续的用例设计中将至少对应两个测试步骤。

需要说明的是，数据的中间状态对用户来说则不一定是可见的，但如果测试中有必要，测试人员依旧可以通过网络捕获、查看日志、查看共享内存的方法来设置系统检查点。

3)编写系统测试用例：

依照系统数据流向图2，确定系统测试输入和期望结果后，编写的系统测试用例如表4所示。

表4 飞船遥测数据接收、处理和显示测试用例

需要说明的是，表4测试用例是针对一个数据源编写的。系统测试时，要按照系统真实使用场景，同时注入系统工作时的所有数据源，测试人员需要同时关注每个数据源的处理结果，以及有关联关系的多个数据源的综合处理结果。

4 实验结果与分析

在某测控中心软件系统测试中，对本文提出的系统测试方法进行了验证。用例设计阶段，通过对数据源的识别，数据路径和状态分析，共设计测试用例91个，测试用例设计情况见表5。

表5 测试用例设计一览表

表5中，因系统参试设备较多，且大多数设备产生多种数据，共梳理出62个外部数据源。梳理内部数据源19个，包括遥控数据、综合弹道、设备引导数据、系统状态上报数据、链监信息等，遥控数据又细分为指令码、执行脉冲、指令序列等多个子类。综合性测试用例则进行多个数据源的组合，用于数据优选功能、数据融合功能、性能和余量测试。

系统测试共发现软件缺陷13处，软件缺陷分布情况见表6。

表6 软件缺陷分布一览表

该系统是在原有系统基础上进行的国产化改造，大部分软件为代码移植，故13个软件缺陷符合测试预期。其中软件功能缺陷3个，说明软件配置项测试比较充分，大部分软件功能缺陷已在配置项测试中发现并解决。其余10个软件缺陷为系统级缺陷，分布于系统内外接口、软件互操作和综合试验流程中，系统级缺陷数占比为76.92%。而系统所属配置项间接口、时序、逻辑关系是否正确，能否协调有序工作，正是软件系统测试应重点关注的对象。

经过本次系统测试，该系统一年内运行稳定，成功执行多次试验任务。实践证明，本文提出的基于数据源识别和数据驱动分析的软件系统测试方法，从系统所处理的数据入手，能够快速、清晰提取测试需求，提高系统测试用例设计的针对性和有效性。

5 结束语

本文结合航天测控中心软件系统的特点，设计了一种基于数据源识别和数据驱动分析的航天测控软件系统测试方法，给出了该方法的一般工作流程，并对数据源的识别、数据路径分析、数据状态分析，系统数据流向图绘制、系统测试用例编写等关键技术进行了研究。该方法是对传统的基于需求的系统测试方法的有力补充，能够显著提高系统测试用例设计的针对性和有效性。该方法已经在多个航天测控中心、测量船的软件系统测试中得到应用和验证，结果表明，该方法能够有效发现系统层面的软件缺陷，提高系统测试效率。后续，作者将针对该方法的测试充分性、测试数据和测试用例辅助生成[20]、数据驱动和业务驱动相结合的系统测试方法做进一步的研究。