CN111970172A

CN111970172A - 软件测试需求分析方法及相关组件

Info

Publication number: CN111970172A
Application number: CN202010857078.0A
Authority: CN
Inventors: 王俊杰; 陈媛; 王安邦; 刘逻
Original assignee: Changchun Institute of Optics Fine Mechanics and Physics of CAS
Current assignee: Changchun Institute of Optics Fine Mechanics and Physics of CAS
Priority date: 2020-08-24
Filing date: 2020-08-24
Publication date: 2020-11-20

Abstract

本申请公开了一种软件测试需求分析方法，通过解析目标测试系统的接口通信协议应用数据的字节信息，并根据解析得到的信息按照统一格式存储后，对统一格式存储的数据进行特征项以及特征数据的提取，生成测试驱动数据以及非法驱动数据包，实现了有效的数据整合，可以消除各系统设备工作方式以及应用标准间的差异，同时简化数据项，提炼有用数据，实现对于没有标准格式的协议的高效测试，实现协议测试的全覆盖。本申请还提供了一种软件测试需求分析装置、设备及一种可读存储介质，具有上述有益效果。

Description

软件测试需求分析方法及相关组件

技术领域

本申请涉及接口通信协议测试领域，特别涉及软件测试需求分析方法、装置、设备及一种可读存储介质。

背景技术

目前很多功能性较强的设备(比如航天/航空载荷、武器装备等)一般由多个系统组成，各系统分别实现不同的功能，各系统间协作共同完成设备功能。

而组成设备的各个系统分别使用各自领域的总线，比如飞行控制系统与载荷控制系统之间通过CAN总线连接，载荷控制系统与飞行控制系统之间通过CAN总线连接等。采用串行通信的各系统间在物理层、数据链路层等都按照各自总线标准组建数据，在面向应用的应用层，由于系统设备工作方式千差万别，设计人员在设计应用层通信协议时，无法遵循统一的应用标准，而是根据系统信息交互的需要综合考虑。

而出于设备功能的保证，需要对设备进行软件测试，而针对这种没有标准协议格式的设备系统进行测试，会耗费大量的人力和资源，取得的测试效果也不令人满意，不能达到协议测试的充分覆盖。

因此，如何高效的实现串行、差异性总线标准下的设备多系统软件测试，是本领域技术人员继续解决的问题。

发明内容

本申请的目的是提供一种软件测试需求分析方法，该方法可以提升PCIE设备配置管理效率；本申请的另一目的是提供一种软件测试需求分析装置、设备及一种可读存储介质。

为解决上述技术问题，本申请提供一种软件测试需求分析方法，包括：

解析目标测试系统的接口通信协议应用数据，确定测试驱动数据的字节信息；

将所述字节信息按照目标存储模型建模格式进行存储，得到格式统一后的通信协议数据；

识别所述数据元素的值的特征属性，并根据各所述特征属性对应的标记项对所述数据元素进行标记；

根据所述标记确定所述数据元素中有效数据以及非法数据，生成测试驱动数据；其中，所述测试驱动数据包括：有效驱动数据包以及无效驱动数据包；

根据标记确定所述数据元素的非法取值，生成非法驱动数据包；

根据所述测试驱动数据、所述非法驱动数据包生成测试分析数据。

可选地，在识别所述数据元素的值的特征属性之前，还包括：

补齐所述格式统一后的通信协议数据中各数据元素中空闲位。

可选地，识别所述格式统一后的通信协议中的各数据元素，并根据所述数据元素的值的特征属性对所述数据元素进行标记，包括：

识别所述格式统一后的通信协议中各数据元素的与前序数据元素值重复位、唯一合法值、数据元素重复值、第一个数据元素为重复值的个数以及连续取值；

根据各特征属性值对应的标记项。

可选地，所述目标存储模型建模格式包括：结束字节、起始字节、字节宽、结束位、起始位、位宽、数据项名称、数据项类别、数据项分类关系、数据项值以及数据项值特征。

可选地，确定所述数据元素中有效数据以及非法数据，包括：

确定所述数据元素的类型；

若所述数据元素为乘积关系类型，以所述乘机关系相关元素的取值个数的乘积作为第一总量；

若所述数据元素为参数范围类型，以参数的典型值个数作为第二总量；

若所述数据元素为重复数据类型，以重复数据中的最大值作为第三总量；

根据所述第一总量、所述第二总量以及所述第三总量确定所述测试驱动数据的数据包数量。

可选地，根据所述第一总量、所述第二总量以及所述第三总量确定所述测试驱动数据的数据包数量，包括：

取所述第一总量、所述第二总量以及所述第三总量中的最大值作为所述测试驱动数据的数据包数量，或，取所述第一总量、所述第二总量以及所述第三总量的和作为所述测试驱动数据的数据包数量。

可选地，所述软件测试需求分析方法，其特征在于，还包括：

判断所述数据元素中是否存在校验数据元素；

若存在，根据校验类型计算校验值；

则相应地，根据所述测试驱动数据、所述非法驱动数据包生成测试分析数据，具体为：根据所述测试驱动数据、所述非法驱动数据包以及所述校验值生成测试分析数据。

本申请提供了一种软件测试需求分析装置，该装置包括：

信息解析单元，用于解析目标测试系统的接口通信协议应用数据，确定测试驱动数据的字节信息；

信息存储单元，用于将所述字节信息按照目标存储模型建模格式进行存储，得到格式统一后的通信协议数据；

属性识别单元，用于识别所述数据元素的值的特征属性，并根据各所述特征属性对应的标记项对所述数据元素进行标记；

测试数据包生成单元，用于根据所述标记确定所述数据元素中有效数据以及非法数据，生成测试驱动数据；其中，所述测试驱动数据包括：有效驱动数据包以及无效驱动数据包；

非法数据包生成单元，用于根据标记确定所述数据元素的非法取值，生成非法驱动数据包；

数据组织单元，用于根据所述测试驱动数据、所述非法驱动数据包生成测试分析数据。

本申请提供了一种计算机设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现所述的软件测试需求分析方法的步骤。

本申请提供了一种可读存储介质，所述可读存储介质上存储有程序，所述程序被处理器执行时实现所述软件测试需求分析方法的步骤。

本申请所提供的软件测试需求分析方法，通过解析目标测试系统的接口通信协议应用数据的字节信息，并根据解析得到的信息按照统一格式存储后，对统一格式存储的数据进行特征项以及特征数据的提取，生成测试驱动数据以及非法驱动数据包，实现了有效的数据整合，可以消除各系统设备工作方式以及应用标准间的差异，同时简化数据项，提炼有用数据，实现对于没有标准格式的协议的高效测试，实现协议测试的全覆盖。

本申请还提供了一种软件测试需求分析装置、设备及一种可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的一种软件测试需求分析方法的流程图；

图2为本申请实施例提供的一种软件测试需求分析装置的结构框图；

图3为本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

本申请的核心是提供软件测试需求分析方法，该方法适合于不同厂商不同类型的FPGA加速卡，可以实现产品静态信息的固化；本申请的另一核心是提供一种软件测试需求分析装置、设备及一种可读存储介质。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本实施例提供一种软件测试需求分析方法，请参考图1，图1为本实施例提供的一种软件测试需求分析方法的流程图，该方法主要包括：

步骤s110、解析目标测试系统的接口通信协议应用数据，确定测试驱动数据的字节信息；

对接口通信协议应用数据分析，对通信协议中的涉及的数据项进行分析描述。

无论什么样的应用层协议，都可分解为数据包，数据包可分解为数据元素。数据元素的组成可由二进制的一位到多个字节，依据特定的存储模型建模方法，保存通信协议。其中，协议数据内容为面向应用者的顶层数据的测试数据生成约束。

本实施例中对于待分析的接口通信协议的数据传输方式不做限定，可以为串行数据传输方式，也可以为其他。

以由飞行控制系统S0、载荷控制系统S1、图像处理系统S2与伺服控制系统S3组成的系统为例，飞行控制系统S0：与载荷控制系统S1之间通过CAN总线连接，涉及到双向数据交互，数据交互内容，即接口通信协议应用数据见表1、表2。载荷控制系统S1：与飞行控制系统S0之间通过CAN总线连接，涉及到双向数据交互，数据交互内容见表1、表2；与图像处理系统S2之间通过RS422总线连接，涉及到双向数据交互，数据交互内容见表3、表4；与伺服控制系统S3之间通过RS422总线连接，涉及到双向数据交互，数据交互内容见表5、表6。目标测试系统可以为四个系统中任意一个。

表1飞控系统发往载荷控制系统数据

表2载荷控制系统发往飞控系统

图像处理系统S2：与载荷控制系统之间通过RS422总线连接，涉及到双向数据交互，数据交互内容见表3、表4。

表3载荷控制系统发往图像处理系统

表4图像处理系统发往载荷控制系统

伺服控制系统S3：与载荷控制系统之间通过RS422总线连接，涉及到双向数据交互，数据交互内容见表5、表6。

表5载荷控制系统发往伺服控制系统

表6伺服控制系统发往载荷控制系统波特率

每个表中的内容组成通信协议的一个数据包，共包含6种不同类型的数据包，表格中每一个参数名称为一个数据元素，共有数据元素30个，本实施例中仅以上述格式的接口通信协议应用数据为例进行介绍，其他系统下的接口通信协议应用数据的处理均可参照本实施例的介绍，在此不再赘述。

假设目标测试系统为图1中的载荷控制系统，对其进行测试，涉及到产生测试驱动数据来自其他三个系统发放载荷控制系统的协议，具体为表1、表4、表6。由于表1、表4与表6相类似，为方便介绍，本实施例中只以表6的数据作为测试驱动数据实例说明，其他表下的处理方式均可参照本实施例的介绍，在此不再赘述。

步骤s120、将字节信息按照目标存储模型建模格式进行存储，得到格式统一后的通信协议数据；

其中，目标存储模型建模格式为一种通信协议数据格式特性测试数据自动生成建模方法建立数据存储模型，本实施例中对该模型下的具体格式以及包含的数据项不做限定，以表6为例，将表6按照一种通信协议数据格式特性测试数据自动生成建模方法建立数据存储模型，结果见表7。

表7

结束字节	起始字节	字节宽	结束位	起始位	位宽	名称	分类	关系	值(HEX)	值特征
											1	1	1	7	0	8	帧头1	帧头	7e	1
2	2	1	7	0	8	帧头2	帧头		7e	1
											3	3	1	7	0	8	地址码	地址码	66	1
4	4	1	0	0	1	方位陀螺故障	状态		1	4
											4	4	1	1	1	1	俯仰陀螺故障	状态	2	0
4	4	1	2	2	1	方位电机故障	状态		4	0
											4	4	1	3	3	1	俯仰电机故障	状态	8	0
7	5	3	11	0	12	方位误差	参数		FFF	2
											7	5	3	23	12	12	俯仰误差	参数	FFF000	0
8	8	1	7	0	8	校验	累加和	4,7		1

步骤s130、识别数据元素的值的特征属性，并根据各特征属性对应的标记项对数据元素进行标记；

识别数据元素的值，具体地可以根据字节序号识别存储模型中的各数据元素，分析数据元素的值的特征属性，并根据各特征属性对应的标记项对数据元素进行标记。标记的属性特征标记的目的在于方便后续步骤中快速捕捉数据元素特征。

而本实施例中对于待识别的特征属性项以及对应的标记方式不做限定，可选地，可以识别格式统一后的通信协议中各数据元素的与前序数据元素值重复位、唯一合法值、数据元素重复值、第一个数据元素为重复值的个数以及连续取值；对数据元素进行标记。例如：一种标记方式如下：0-与前序数据元素值重复；1-唯一合法值；x-数据元素重复值，其中，第一个数据元素为重复值个数为x个；空-连续取值。

需要说明的是，在执行步骤s130前，可以进一步执行补齐格式统一后的通信协议数据中各数据元素中空闲位的步骤。根据字节序号，分析存储模型中的数据元素，将数据元素按照字节宽度左侧高位补齐0，以使各数据元素中数据位数统一，方便对于数据元素的统一管理，以表7为例，则需要对表7的4-8行自动补齐位数。本实施例中对于空闲位补齐是否执行不做限定，可以根据实际数据识别的需要进行配置。

步骤s140、根据标记确定数据元素中有效数据以及非法数据，生成测试驱动数据；

根据字节序号，分析存储模型中数据包的数据元素组成个数，本实例为6个元素组成。根据数据包的数据元素组成挑选数据元素，组成测试驱动数据，挑选原则为：选择有效数据组成多个有效驱动数据包，选择含有非法数据元素组成多个无效的驱动数据包，其中，测试驱动数据包括：有效驱动数据包以及无效驱动数据包。

在选择有效测试驱动数据包时，可以根据数据元素关系属性中的乘积关系、参数的范围、重复数据确定合法驱动数据包的个数，本实施例中以设置合法驱动数据包为6个为例。具体地，对于乘积关系的数据元素，可以选择相关元素的取值个数的乘积；对于参数范围的数据元素，可以取参数的典型值(比如7个典型值)个数；对于重复数据，可以取重复数据中的最大值，

确定上述数据后，可以根据上述数据确定最终的驱动数据包个数，具体地，驱动数据包的最终个数存在两种设置模式，简约模式：取上述最大值作为最终的驱动数据包个数。全面模式：取上述数据的和作为驱动数据包的个数，也可以配置其他设置模式，本实施例中对此不做限定。

该种取值设置方式下实现过程简单，且识别难度低，数量范围符合实际使用需求。本实施例中仅以上述有效驱动数据包的个数配置方式为例进行介绍，其他配置方式下的实现方式均可参照本实施例的介绍，在此不再赘述。

步骤s150、根据标记确定数据元素的非法取值，生成非法驱动数据包；

根据标记确定所述数据元素的非法取值，根据各数据元素中的非法取值生成非法驱动数据包，本实施例中对于非法驱动数据包的取值方式以及数量设定不做限定。

具体地，一种非法驱动数据包生成原则如下：至少单独取每个数据元素的非法值一次，如果一个数据包有10个数据元素，那么至少有10个非法驱动数据包，每个非法驱动数据包只有一个数据元素含有非法值。本实例的状态数据元素和参数数据元素无非法数据，所以共有4个非法数据包。本实施例中仅以上述设定方式为例进行介绍，其他实现方式均可参照本实施例的介绍，在此不再赘述。

进一步地，可以判断数据元素中是否存在校验数据元素，如果存在校验数据元素，可以根据校验的类型计算校验值，以便用户的校验。其中，校验值的生成方式包含：累加和校验、异或和校验、CRC8校验、CRC16校验、CRC32校验等，本实施例中对此不做限定，比如可以取4-7字节累加和校验。

步骤s160、根据测试驱动数据、非法驱动数据包生成测试分析数据。

测试分析数据的格式本实施例中具体不做限定，如下表8所示为一种测试分析数据，本实施例中仅以该格式下的测试分析数据为例进行介绍，其他格式可以根据实际使用需要进行设定。

表8

基于上述介绍，本实施例提供的软件测试需求分析方法，通过解析目标测试系统的接口通信协议应用数据的字节信息，并根据解析得到的信息按照统一格式存储后，对统一格式存储的数据进行特征项以及特征数据的提取，生成测试驱动数据以及非法驱动数据包，实现了有效的数据整合，可以消除各系统设备工作方式以及应用标准间的差异，同时简化数据项，提炼有用数据，实现对于没有标准格式的协议的高效测试，实现协议测试的全覆盖。

请参考图2，图2为本实施例提供的一种软件测试需求分析装置的结构框图；该装置主要包括：信息解析单元210、信息存储单元220、属性识别单元230、测试数据包生成单元240、非法数据包生成单元250以及数据组织单元260。本实施例提供的软件测试需求分析装置可与上述软件测试需求分析方法相互对照。

其中，信息解析单元210主要用于解析目标测试系统的接口通信协议应用数据，确定测试驱动数据的字节信息；

信息存储单元220主要用于将字节信息按照目标存储模型建模格式进行存储，得到格式统一后的通信协议数据；

属性识别单元230主要用于识别数据元素的值的特征属性，并根据各特征属性对应的标记项对数据元素进行标记；

测试数据包生成单元240主要用于根据标记确定数据元素中有效数据以及非法数据，生成测试驱动数据；其中，测试驱动数据包括：有效驱动数据包以及无效驱动数据包；

非法数据包生成单元250主要用于根据标记确定所述数据元素的非法取值，生成非法驱动数据包；

数据组织单元260主要用于根据测试驱动数据、非法驱动数据包生成测试分析数据。

本实施例提供一种计算机设备，主要包括：存储器以及处理器。

其中，存储器用于存储程序；

处理器用于执行程序时实现如上述实施例介绍的软件测试需求分析方法的步骤，具体可参照上述软件测试需求分析方法的介绍。

请参考图3，为本实施例提供的计算机设备的结构示意图，该计算机设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processingunits，CPU)322(例如，一个或一个以上处理器)和存储器332。其中，存储器332可以是短暂存储或持久存储。更进一步地，中央处理器322可以设置为与存储器332通信，在计算机设备301上执行存储器332中的一系列指令操作。

计算机设备301还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作系统341，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上面图1所描述的软件测试需求分析方法中的步骤可以由本实施例介绍的计算机设备的结构实现。

本实施例公开一种可读存储介质，其上存储有程序，程序被处理器执行时实现如上述实施例介绍的软件测试需求分析方法的步骤，具体可参照上述实施例中对软件测试需求分析方法的介绍。

该可读存储介质具体可以为U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可存储程序代码的可读存储介质。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的软件测试需求分析方法、装置、设备及可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

Claims

1.一种软件测试需求分析方法，其特征在于，包括：

2.如权利要求1所述的软件测试需求分析方法，其特征在于，在识别所述数据元素的值的特征属性之前，还包括：

3.如权利要求1所述的软件测试需求分析方法，其特征在于，识别所述格式统一后的通信协议中的各数据元素，并根据所述数据元素的值的特征属性对所述数据元素进行标记，包括：

根据各特征属性值对应的标记项。

4.如权利要求1所述的软件测试需求分析方法，其特征在于，所述目标存储模型建模格式包括：结束字节、起始字节、字节宽、结束位、起始位、位宽、数据项名称、数据项类别、数据项分类关系、数据项值以及数据项值特征。

5.如权利要求1所述的软件测试需求分析方法，其特征在于，确定所述数据元素中有效数据以及非法数据，包括：

确定所述数据元素的类型；

6.如权利要求5所述的软件测试需求分析方法，其特征在于，根据所述第一总量、所述第二总量以及所述第三总量确定所述测试驱动数据的数据包数量，包括：

7.如权利要求1所述的软件测试需求分析方法，其特征在于，还包括：

判断所述数据元素中是否存在校验数据元素；

若存在，根据校验类型计算校验值；

8.一种软件测试需求分析装置，其特征在于，该装置包括：

9.一种计算机设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述的软件测试需求分析方法的步骤。

10.一种可读存储介质，其特征在于，所述可读存储介质上存储有程序，所述程序被处理器执行时实现如权利要求1至7任一项所述软件测试需求分析方法的步骤。