CN103761186A

CN103761186A - 符合arinc661规范的飞机座舱显示系统服务器软件的测试方法

Info

Publication number: CN103761186A
Application number: CN201410022618.8A
Authority: CN
Inventors: 王辉; 丁毅; 马慧芳
Original assignee: China Aeronautical Radio Electronics Research Institute
Current assignee: China Aeronautical Radio Electronics Research Institute
Priority date: 2014-01-17
Filing date: 2014-01-17
Publication date: 2014-04-30

Abstract

本发明揭示了一种符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，包括如下步骤：步骤一：提取测试依据；步骤二：确定测试方式；步骤三：如为手动测试方法则接收用户设计的DF文件结构；如为自动测试方式则进行自动化测试；步骤四：生成测试输入及测试期望结果，与现有技术相比较，本发明提供快速方便生成测试输入和测试期望结果的方法，以提高软件测试的效率和正确率，从而缩短测试周期，降低测试开销。

Description

符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法

【技术领域】

本发明属于航空座舱显示系统（CDS,Cockpit Display System）软件测试领域，涉及一种符合ARINC661规范的CDS服务器软件的测试方法。

【背景技术】

ARINC661规范(全称为座舱显示系统与用户系统的接口规范,CockpitDisplay System Interface To User Systems，Aeronautical Radio,INC.颁布)的第一版发布于2003年，目前已更新至第五版。由于其灵活性、开放性和实用性而发展成为了飞机座舱显示系统的行业标准，波音787和空客A380等重大机型的显示系统均采用了此规范。

ARINC661规范采用CS（Client-Server）架构。在定义阶段，服务器端软件加载并解析二进制格式的客户端DF（Definition File）文件（简称DF文件），然后根据DF文件内容控制CDS的显示。

依据ARINC661规范和DO-178C(全称为“机载系统和设备适航审定中的软件考虑”，Software Considerations in Airborne Systems and EquipmentCertification，由RTCA（The Radio Technical Commission for Aeronautics）颁布)，服务器软件在定义阶段应能正确解析合法的DF文件，并对非法的DF文件提示相应的错误信息。具体依据如下：

a.根据ARINC661规范4.4.2章节的要求，服务器软件应具有错误提示功能，包括在定义阶段和运行时阶段，其中，在定义阶段，服务器软件应对DF文件中错误的命令以及错误的参数值进行提示；

b.根据DO-178C的6.1章节的要求，软件测试的目标之一是“软件可执行目标码对于软件需求应是健壮的，可以正确地处理异常/非法的输入和条件”。适航必须满足这个目标。

然而，现有的测试输入（DF文件）和测试期望结果（期望错误信息）主要由测试人员手动编写，此种方式具有如下缺点：

（1）工作量很大，需要大量的重复劳动，特别是在DF文件的生成上，并且工作效率低，从而导致测试周期较长；

（2）手动生成测试输入和测试期望结果出错的概率较大；

（3）二进制格式的DF文件可读性差，导致同行评审的工作量和压力都很大，并且难以被重用。

【发明内容】

本发明的目的在于提供一种符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，用以克服符合ARINC661规范的CDS服务器软件手动测试效率低、正确率低的问题。

为实现上述目的，实施本发明的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法包括如下步骤：

步骤一：提取测试依据；

步骤二：确定测试方式；

步骤三：如为手动测试方法则接收用户设计的DF文件结构；如为自动测试方式则进行自动化测试；

步骤四：生成测试输入及测试期望结果。

依据上述主要特征，其中提取测试依据为使用者使用可扩展标记语言XML文件存储ARINC661规范中定义的关键字及其值、组件创建结构及组件间父子关系约束。

依据上述主要特征，每个组件的创建结构也用一个XML文件存储，该文件用于描述组件的名称以及组件中每个参数的名称、类型和合法性约束等。

依据上述主要特征，本方法在生成二进制格式的DF文件的同时，生成相应的文本格式的DF文件，包含的是符合ARINC661规范的文本格式的十六进制码以及相应的注释。

依据上述主要特征，DF文本文件的相应位置增加有测试用例信息，包括测试需求号、测试用例号、测试用例描述及错误码。

依据上述主要特征，测试期望结果通过以下方法生成：在生成DF文件时，需要递归遍历树形控件的节点，定义一个整型变量用于记录当前已经写入DF文件的字节数；每当向DF文件中写入数据时，该变量自加写入的字节数，并且遍历每个属性的同时，如果该属性包含错误码，则生成一条错误信息，其中，“DF文件名”、“错误码”通过获取用户的输入得到，“偏移位置”即为整型变量的值，期望错误信息在DF文件生成完毕的同时生成。

依据上述主要特征，自动化测试包括组件创建结构自动化测试和父子关系自动化测试。

依据上述主要特征，组件创建结构自动化测试是指测试组件所有参数的合法范围，首先需要根据具体项目的要求确定生成策略，对于简单类型且取值无其他特殊要求的参数，设置三个用例即可，分别取最小值、中间值和最大值；对于枚举类型，用例的个数等于枚举值个数加2，分别取各个枚举值、其中的最小值减1以及最大值加1。

依据上述主要特征，本发明提供用于定制参数合法范围的便捷接口，由用户在XML文件中定制参数的合法范围，之后根据该文件进行组件创建结构进行自动化测试。

与现有技术相比较，本发明提供快速方便生成测试输入和测试期望结果的方法，以提高软件测试的效率和正确率，从而缩短测试周期，降低测试开销。

【附图说明】

图1为实施本发明的飞机座舱显示系统服务器软件的测试方法的整体流程图。

图2ARINC661定义的Basic Container的组件创建结构。

图3为DF文件的逻辑结构。

图4为DF文件的设计结构。

图5为DF文件生成流程图。

图6为TreeNodeData、TreeViewData、TreeNode和TreeView的类图。

图7为组件创建结构自动化测试流程图。

图8为Basic Container父子关系自动化测试的逻辑结构示意图。

图9为父子关系自动化测试流程图。

图10为GpLine的StyleSet参数自动化测试的逻辑结构图。

【具体实施方式】

实施本发明的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法包括如下步骤：

步骤一：提取测试依据；

步骤二：确定测试方式：

步骤四：生成测试输入及测试期望结果。

其中步骤一提取测试依据为使用者使用可扩展标记语言XML文件存储（1）ARINC661规范中定义的关键字及其值、（2）组件创建结构、（3）组件间父子关系约束，作为本发明的依据和输入。

其中ARINC661定义的关键字及其值用XML描述如下（省略了部分内容）：

每个组件的创建结构也用一个XML文件存储，该文件用于描述组件的名称以及组件中每个参数的名称、类型和合法性约束等。以Basic Container为例，ARINC661规范中定义的组件创建结构如图2所示。

使用XML描述如下：

对于组件间的父子关系约束，ARINC661定义了组件间严格的父子关系约束（具体可参考ARINC661），使用XML描述父子关系约束如下（省略了部分内容）：

对于第二步，测试方式的选取是通过使用者的选择确定，如果使用者选择进行手动测试，则进入生成DF文件结构的步骤，而如果使用者选择自动测试，则进入自动化测试。

第三步中如果选择手动测试，则接受用户的输入形成DF文件的逻辑结构，其中DF文件包含文件头（File Header）、符号块（Symbol Block）、图片块（Picture Block）、用户层定义块（User Application Layer Block）和文件尾（File Footer），其逻辑结构如图3所示。其中，“A661_Definition_File”节点代表整个DF文件，它包含“Header”（1个）、“Symbol Block”（0或1个）、“PictureBlock”（0或1个）、“Layer Block”（1或多个）和“Footer”（1个），图中的叶子节点（如“AppliIdent”、“SymbolId”、“WidgetType”等）是其各自父节点的属性，例如“{A661_Block_Structure_DT}+”包含“A661_BEGIN_LAYER_BLOCK”、“LayerIdent”、“Context Number”、“BlockSize”、“A661_END_LAYER_BLOCK”和“UnusedPad”等6个属性。ARINC661规范定义了每个属性的类型，例如，图中的“A661_DF_MAGIC_NUMBER”属性为“ushort”类型，占据两个字节。

在对DF文件的结构进行设计时，本发明提供一个树形结构的设计界面，用户根据需要设计DF文件的结构，然后根据该结构生成相应的DF文件。如图4所示，为DF文件的设计结构，其中每个节点包含相应的属性，例如，“Layer1”节点表示一个“Layer Block”，它包含的属性有“A661_BEGIN_LAYER_BLOCK”、“LayerIdent”、“Context Number”、“BlockSize”、“A661_END_LAYER_BLOCK”、“UnusedPad”，用户可以设置每个属性的值。该结构与DF文件的逻辑结构是对应的，所不同的是，将DF文件头和文件尾的属性作为根节点（即名为“A661_DF”的节点）的属性，即根节点包含“A661_DF_MAGIC_NUMBER”、“LibraryVersion”、“SuppVersion”、“AppliIdent”、“Size of the OEM free data”、“OEM_Free_Data”、“A661_DF_FOOTER”和“UnusedPad”等8个属性。

当根据使用者的输入完成DF文件结构的设计之后，需要根据该树形结构中节点的顺序完成DF文件的生成，但并不能直接依次将每个节点的属性写入DF文件中，例如对于根节点来说，前几个属性写在文件的开头，而最后两个属性（“A661_File_Footer”和“UnusedPad”）却应写在文件的最后，所以可以在“A661_File_Footer”属性中加上一个bool类型的标志（下文称为“pause flag”），用于说明将该属性写入文件之前，必须先写入当前节点（此时是根节点）所有子节点的属性。

考虑到某些属性的值的特殊性，例如图3中

“{A661_Block_Structure_DT}+”下的“Block Size”节点，它表示对应的“LayerBlock”结构的总字节数，需要计算出该结构中所有属性的字节数之和，如果让DF文件设计人员手动输入，计算既费时又容易出错，从而导致生成非法的DF文件，解决的方法是在“Block Size”属性中添加一个枚举类型的标志（下文称为“auto flag”），用于说明其值并不需要用户手动输入，而是根据这个标志以及DF文件的结构自动计算，该枚举类型的定义如下：

其中，NodeSize表示该属性的值等于相应节点所有属性的字节数之和，NodeAndChildrenSize表示该属性的值等于相应节点及其后代节点所有属性的字节数之和，ChildrenCount表示该属性的值等于相应节点子节点的个数。“auto flag”设置为三者中的哪一个需要根据具体情况而定，显然，“Block Size”属性的“auto flag”应设置为NodeAndChildrenSize。

在具体实施时，可采用递归的方式实现DF文件的生成。假设treeView代表DF文件设计结构对应的树形控件；binFile表示二进制格式的文件，即DF文件；hexFile表示每行为十六进制数据的文本文件，即DF文本文件。那么生成DF文件的伪代码如下：

FOREACH rootNode as a root node of treeView

WriteProperty(binFile,hexFile,rootNode);

END FOREACH

其中，函数WriteProperty的伪代码如下（node表示树形控件中的一个节点，函数的功能是将node节点及其所有后代节点的属性写入file）：

PROCEDURE WriteProperty(File binFile,File hexFile,TreeNode node)

bool isPaused=FALSE;

write the test case information to hexFile;

FOREACH p AS a property of node/*property表示树形节点的属性*/

IF isPaused==FALSE

IF pause flag of p==FALSE

write binary value of p to binFile;

write hexadecimal value of p and corresponding annotation to hexFile;

ELSE

isPaused=TRUE;

END IF

IF(isPaused==TRUE）or(p is the last property of node)

FOREACH childNode as a child of node

WriteProperty(binFile,hexFile,childNode);

END FOREACH

END IF

ELSE

write binary value of p to binFile;

write hexadecimal value of p and corresponding annotation to hexFile;

END IF

END FOREACH

END PROCEDURE

生成DF文件的具体流程如图5所示。首先读取DF文件结构，设置当前节点为根节点，并将根节点属性写入DF文件中；然后如果存在下一个节点就设置当前节点为下一个节点并将属性信息写入DF文件，直到遍历完毕全部节点。

另外，为了提高测试输入的可读性以及可重用性，本发明在生成二进制格式的DF文件的同时，生成相应的文本格式的DF文件，即DF文本文件。DF文本文件中包含的是符合ARINC661规范的文本格式的十六进制码以及相应的注释，使用文本格式以及添加注释是为了提高DF文件的可读性。

一个DF文件可以包含多个测试用例，本发明在DF文本文件的相应位置增加了测试用例信息（testcase information），包括以下内容：测试需求号、测试用例号、测试用例描述（用以描述该测试用例的功能，例如，测试某父子关系组合，或者某组件中某参数的合法/非法值等）及错误码。这些信息实现了测试用例和测试需求的可追踪性，进一步提高了DF文件的可读性，同时也方便了DF文件的同行评审。

再者，为了下次打开本工具后可以方便修改已有的DF文件，需要考虑如何保存DF文件的设计结构，即如何保存DF设计结构对应的树形控件。

序列化是比较常用的树形控件保存方式，执行高效并且开销较低，通过反序列化的方式读取保序列化保存的树形控件数据。所谓序列化，就是将一个对象转换成便于传输的具有该对象所有或部分成员信息的数据，而反序列化是它的逆过程。

考虑到C#对序列化和反序列化保存和读取数据的支持非常好，以下用C#实现DF文件可视化结构的保存。C#序列化有两种方式，一种是二进制序列化，另一种是XML序列化，前者转换后的数据是二进制格式，后者是XML形式的文本格式，在转换的效率上二进制序列化比XML序列化高，但是XML格式比二进制格式易读，可以通过修改转换后的数据达到修改原始对象的目的。为实现将对象序列化到文件中，需要用到.NET类库中的BinaryFormatter和XmlSerializer类，序列化和反序列化时分别调用它们的Serialize和Deserialize方法。但是C#对序列化是有限制的，必须保证要被序列化的对象可序列化，即该对象所属类型的IsSerializable成员为true，而树形控件TreeView类是不可序列化的，所以无法直接将树形控件转换为便于传输的数据从而保存到文件中。

由于TreeView类不可序列化，可以考虑将其转换为可序列化的类。对于本工具而言，关心的只是树形控件所有节点（TreeNode）的树形结构关系，以及每个节点的文本（Text）、附加内容（Tag），而树形控件的长宽、背景颜色等并不重要。所以定义两个可序列化的类TreeNodeData和TreeViewData，前者代表节点信息，包含Text，Tag和Nodes三个成员变量，其中，Nodes成员表示该节点所有子节点间的树形结构关系；后者代表树形控件的信息，只包含一个成员Nodes，表示树形控件所有节点间的树形结构关系。TreeNodeData，TreeViewData，TreeNode和TreeView的类图如图6所示，其中TreeNode和TreeView类是.NET类库中的类，TreeNodeData类的构造函数TreeNodeData(TreeNode node)和函数ToTreeNode()用于TreeNode和TreeNodeData的相互转换，TreeViewData类的构造函数TreeViewData(TreeView treeView)和函数ToTreeView()用于TreeView和TreeViewData的相互转换。为了保存树形控件TreeView的对象，将其转换为可序列化的TreeViewData类的对象，并将该对象通过二进制序列化或者XML序列化的方法保存到文件中，加载时，反序列化该文件得到TreeViewData类的对象，然后转换为TreeView类的对象即可。

以下介绍测试期望结果生成的方法。

测试期望结果即期望错误信息。在定义阶段，服务器软件应对DF文件中错误的命令以及错误的参数值进行提示，即产生实际错误信息，其格式由原始设备制造商自行规定。为了能通过实际错误信息定位到DF文件中出错的位置，假设实际错误信息包含“DF文件名”、“偏移位置”和“错误码”，并且每当服务器软件遇到错误时在实际错误信息中添加一条相应的错误信息。为了便于比较期望结果和实际结果是否相同，即判断测试用例是否通过，设计期望错误信息的格式和实际错误信息保持一致。

本发明在生成DF文件的同时生成相应的期望错误信息。其中，“DF文件名”是用户在设计DF文件结构之前设置的；“错误码”和每个属性相关联，用户设置每个属性的值之后可以设置该属性的错误码；“偏移位置”指错误参数在DF文件中的偏移字节，由工具自动生成。期望错误信息的生成方法如下：在生成DF文件时，需要递归遍历树形控件的节点，定义一个整型变量curBytes用于记录当前已经写入DF文件的字节数；每当向DF文件中写入数据时，该变量自加写入的字节数，并且遍历每个属性的同时，如果该属性包含错误码，则生成一条错误信息，其中，“DF文件名”、“错误码”通过获取用户的输入得到，“偏移位置”即为curBytes的值。期望错误信息在DF文件生成完毕的同时生成。

如果步骤三中选择自动化测试方式，则进入自动化测试，自动化测试指的是全自动化生成测试输入和测试期望结果，而无需手动设计DF文件的结构，主要包括组件创建结构自动化测试和父子关系自动化测试，并且提供用户对参数合法范围，使得自动化测试更加灵活。

其中组件创建结构自动化测试是指测试组件所有参数的合法范围。

为了实现组件创建结构测试输入和测试期望结果的自动化生成，需要根据具体项目的要求确定生成策略，即需要对参数的哪些值进行测试。一般来说，对于简单类型（例如int,short,float等）且取值无其他特殊要求的参数，设置三个用例即可，分别取最小值、中间值和最大值；对于枚举类型，用例的个数等于枚举值个数加2，分别取各个枚举值、其中的最小值减1以及最大值加1。

确定生成策略后即可生成测试输入和测试期望结果，为每个组件生成一个用于测试该组件创建结构的DF文件，并且根据生成策略为组件的每个参数生成多个测试用例。在每个测试用例中，如果所有参数的取值合法，那么该用例为正常用例，否则为异常用例。组件创建结构自动化测试的流程如图7所示。

父子关系自动化测试为测试ARINC661定义的组件间的父子关系约束。

以测试BasicContainer组件的父子关系为例，首先从描述父子关系约束的XML文件读取BasicContainer的60个合法孩子，8个非法孩子，共68个组件，为每个组件生成一个用于测试BasicContainer和该组件的父子关系合法性的测试用例。每个用例的父节点都是BasicContainer，子节点分别是这68个组件中的一个，如果该子节点是BasicContainer合法的孩子，那么该用例为正常用例，否则为异常用例。

BasicContainer父子关系自动化测试的逻辑结构如图8所示（只显示了前7个测试用例）。

父子关系自动化测试的流程如图9所示。首先从约束定义XML文件中读取所有父子关系约束，保存所有父类组件的全部合法子类组件。然后依次遍历所有的组件类型，如果当前组件类型是XML约束定义文件中被测父类组件的合法子类组件那么就是正常的测试用例，否则就是异常的测试用例并生成相应的错误信息。

另外，针对不同CDS服务器软件对组件参数合法范围的约束可能不同，本发明提供用于定制参数合法范围的便捷接口，即用户在XML文件中定制参数的合法范围，本发明根据该文件进行组件创建结构自动化测试。以下以一例子进行说明。

假设要定制参数STYLESET的合法范围，其实施步骤如下：

a.用XML文件描述所有组件的STYLESET参数的合法范围；

例如，对于GPLINE组件，如果STYLESET参数只能取3，4，5，6四个值，那么，其合法范围描述如下：

b.读取该文件来确定参数的合法范围；

c.确定测试用例生成策略。对于GPLINE组件来说，根据合法范围约束可以看出，STYLESET参数属于枚举类型，生成的用例数等于枚举值个数加2，分别取各个枚举值、最小值减1以及最大值加1，即取3，4，5，6，2和7，其中，前四个用例为正常用例，最后两个为异常用例。如图10所示，为GPLINE的STYLESET参数自动化测试的逻辑结构。

与现有技术相比较，本发明通过手动设计DF文件结构或自动化方法生成测试输入和测试期望结果，大幅降低了测试人员的工作量，提高了测试的效率和准确率，从而达到了降低软件测试开销的目的。同时，本发明也提供了参数合法范围及父子关系约束定制接口，支持用户根据自己的需求定制自动化测试用例，具有良好的可扩展性。

可以理解的是，对本领域普通技术人员来说，可以根据本发明的技术方案及其发明构思加以等同替换或改变，而所有这些改变或替换都应属于本发明所附的权利要求的保护范围。

Claims

1.一种符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，包括如下步骤：

步骤一：提取测试依据；

步骤二：确定测试方式；

步骤四：生成测试输入及测试期望结果。

2.如权利要求1所述的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，其特征在于：提取测试依据为使用者使用可扩展标记语言XML文件存储ARINC661规范中定义的关键字及其值、组件创建结构及组件间父子关系约束。

3.如权利要求1所述的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，其特征在于：每个组件的创建结构也用一个XML文件存储，该文件用于描述组件的名称以及组件中每个参数的名称、类型和合法性约束等。

4.如权利要求1所述的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，其特征在于：本方法在生成二进制格式的DF文件的同时，生成相应的文本格式的DF文件，包含的是符合ARINC661规范的文本格式的十六进制码以及相应的注释。

5.如权利要求4所述的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，其特征在于：DF文本文件的相应位置增加有测试用例信息，包括测试需求号、测试用例号、测试用例描述及错误码。

6.如权利要求1所述的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，其特征在于：测试期望结果通过以下方法生成：在生成DF文件时，需要递归遍历树形控件的节点，定义一个整型变量用于记录当前已经写入DF文件的字节数；每当向DF文件中写入数据时，该变量自加写入的字节数，并且遍历每个属性的同时，如果该属性包含错误码，则生成一条错误信息，其中，“DF文件名”、“错误码”通过获取用户的输入得到，“偏移位置”即为整型变量的值，期望错误信息在DF文件生成完毕的同时生成。

7.如权利要求1所述的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，其特征在于：自动化测试包括组件创建结构自动化测试和父子关系自动化测试。

8.如权利要求7所述的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，其特征在于：组件创建结构自动化测试是指测试组件所有参数的合法范围，首先需要根据具体项目的要求确定生成策略，对于简单类型且取值无其他特殊要求的参数，设置三个用例即可，分别取最小值、中间值和最大值；对于枚举类型，用例的个数等于枚举值个数加2，分别取各个枚举值、其中的最小值减1以及最大值加1。

9.如权利要求1所述的符合ARINC661规范的飞机座舱显示系统服务器软件的测试方法，其特征在于：本方法还提供用于定制参数合法范围的便捷接口，由用户在XML文件中定制参数的合法范围，之后根据该文件进行组件创建结构进行自动化测试。