CN103605606B - 一种可自动转换的嵌入式软件测试用例批量执行方法 - Google Patents

Abstract

一种可自动转换的嵌入式软件测试用例批量执行方法，能够自动控制半实物仿真测试环境完成批量执行测试用例的任务，并且具有在测试执行过程中根据用例执行条件判断用例是否应该执行的能力，特别在测试用例或测试对象发生改变需要转换测试环境的时候能够按照需求自动转换测试环境。

Description

一种可自动转换的嵌入式软件测试用例批量执行方法

技术领域

本发明涉及一种可自动转换的嵌入式软件测试用例批量执行方法，属于软件自动化测试领域。

背景技术

测试用例是指为了验证软件功能和性能指标，或者在测试过程中能够覆盖软件所有分支路径而设计的一组测试输入、执行条件和预期结果的集合。它是软件测试的基础，测试人员首先按照测试需求编写测试用例，再执行测试。为完成一次测试，往往需要编写和执行大量的测试用例。编写测试用例需要按照一定的原则和方法或者使用辅助工具进行，不在本发明的讨论范围内，本发明旨在提供一种方法在自动化的情况下批量执行测试用例，尤其是针对于嵌入式软件的配置项测试或者系统测试。

在批量执行测试用例的过程中，有的情况下某个测试用例的执行结果可能会影响其他测试用例的执行顺序。例如：用例1是给某模块上电并接收返回的自检正常标志，如果实际结果是自检正常则用例1通过并继续执行后边的用例，如果不返回自检正常标志，也就是说用例1不通过，则停止执行后边的测试用例。故批量执行测试用例并不意味着全部顺序执行测试用例，而是需要提供一种机制，将多个测试用例组织起来，并且按照一定的规则执行，例如分支和条件判断等。

嵌入式软件与普通软件不同，强调实时特性，并且注重在特定硬件载体和运行环境下的功能性能特性，所以针对嵌入式软件的测试比较依赖测试环境，目前针对嵌入式软件测试比较常用的是全实物测试环境和半实物仿真测试环境。其中，半实物仿真测试环境由于灵活性好，开发周期短等优点得到广泛应用。目前应用较广泛的半实物仿真测试环境如ADS2等虽然可以构建测试环境并且按照测试用例执行测试，但是不具备批量执行测试用例的能力。

在实际的测试中，经常会遇到测试过程中需要改变测试环境的情况，例如某一测试项目中，测试人员需要对多个被测件或者一个被测件的多个分组件进行测试，甚至一个被测件的多个工作阶段所需的测试环境也会发生变化，这就要求批量执行测试用例的方法必须具有随着测试用例和测试对象改变自动改变或者说转换测试环境的能力。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是，提供一种可自动转换的嵌入式软件测试用例批量执行方法，这种方法能够自动控制半实物仿真测试环境完成批量执行测试用例的任务，并且具有在测试执行过程中根据用例执行情况改变后续用例执行顺序，以及根据执行条件判断用例是否应该执行的能力。特别的，在测试用例或测试对象发生改变需要转换测试环境的时候能够按照需求自动转换测试环境。

发明内容

本发明技术解决问题：克服现有技术的不足，提供一种可自动转换的嵌入式软件测试用例批量执行方法，能够自动控制半实物仿真测试环境完成批量执行测试用例的任务，并且具有在测试执行过程中根据用例执行条件判断用例是否应该执行的能力；特别的，在测试用例或测试对象发生改变需要转换测试环境的时候能够按照需求自动转换测试环境。

本发明技术解决方案：一种可自动转换的嵌入式软件测试用例批量执行方法，实现过程如下：

本发明所述方法中，引入“测试单元”的概念来表述测试用例与测试环境组成的新的结构，该名称的引入只为方便表述，其本身的意义对本方法的实现没有影响，叫“测试节点”、“测试块”等等其他名称也可，本发明中采用的名称为“测试单元”。

（1）建立测试用例和测试环境之间的映射关系，一个测试用例与一个测试环境组成一个“测试单元”。可以多个测试用例对应一个相同的测试环境；

（2）每个“测试单元”对应唯一的序号，并且记录本“测试单元”执行完后应该执行的下一个“测试单元”的序号，“测试单元”对应的测试用例通过和不通过分别对应一个序号，如果下一个“测试单元”的序号为空则说明本“测试单元”执行完后不需要继续执行测试，停止测试即可。每个“测试单元”记录自己的执行条件，可以根据某个已经执行过的“测试单元”对应的测试用例的执行情况判断本“测试单元”是否应该执行，也可以根据系统中的某个变量的值是否符合预期来判断本“测试单元”是否应该执行。针对不同的情况，如果每个“测试单元”不是记录下一个节点的序号而是记录下一个节点的指针或者引用，对本方法的实现并无影响，只要保证本“测试单元”执行完后可以获得所需信息并顺利执行下一个“测试单元”即可；

（3）使用数据结构保存所有的“测试单元”，数组、链表、STL库中的容器等结构都可以，但是要保证能够通过测试单元的序号获得测试单元的所有信息（得到指针、引用或者实例）；

（4）测试过程开始后，第一个“测试单元”开始执行；

（5）测试用例执行前首先判断测试环境是否需要转换，如果需要转换按照“测试单元”的配置转换测试环境，否则直接开始执行测试用例。针对不同领域的测试，转换测试环境所要进行的工作不尽相同。本发明所述方法特别适用于嵌入式软件的测试，通常嵌入式软件转换测试环境时很可能需要改变测试环境中的硬件接口以及各接口的各通道上的协议配置和数据帧结构的定义，此外，还需要描述本测试环境需要收集哪些硬件接口上的哪些数据。可提前将每个测试环境对应的各接口上的通讯协议进行建模或者封装成一个子程序，在需要转换测试环境的时候进行调用和实现；

（6）执行完判断本测试用例是否通过，以便确定下一个执行的“测试单元”。如果本“测试单元”因为执行条件不符合没有执行，则按照“测试单元”对应的测试用例不通过执行后续的测试过程；

（7）在测试执行过程中将所有用例的执行情况和得到的实际输出记录起来，等待测试人员分析。

所述步骤（5）中按照下列进行测试环境的判断和转换：

（1）检查测试环境要求的接口与当前测试环境中已经初始化的接口是否相同，不相同则打开缺少的接口并关闭多余的接口；如果相同则检查各接口的各个通道配置是否正确；

（2）检查各接口每个通道的工作模式是否与测试环境要求一致，如果不一致按照被测件接口控制文档和通讯协议的要求重新初始化该通道的工作模式；

（3）检查各接口每个通道上的数据帧结构是否与测试环境要求一致，如果不一致则重新定义该通道上的数据帧结构；

（4）检查测试过程中需要收集的测试数据是否有变化，有变化则按照测试环境的要求修改需要收集的值。

本发明与现有技术相比的优点在于：本发明通过将测试用例与测试用例执行需要的测试环境进行映射组成“测试单元”，使得测试用例执行前可以确定本用例需要什么样的测试环境，并与当前的测试环境进行对比，如果需要转换测试环境则按照测试用例的需求自动转换测试环境。另外，本发明所述方法为每一个“测试单元”分配一个唯一的序号，并且每个“测试单元”记录自己执行完毕后下一个执行的“测试单元”的序号，故能够自动完成批量执行测试用例的任务，并且具有在测试执行过程中根据用例执行条件判断用例是否应该执行的能力。

附图说明

图1为本发明实施例中的半实物仿真测试环境的组成模块和基本工作过程；

图2为本发明的实现流程示意图；

图3为本发明实施例中构建“测试单元”的实现过程；

图4为本发明中“测试单元”自动执行的实现过程；

图5为本发明中的实施例中检查并转换测试环境的实现过程。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

本发明一种可自动转换的嵌入式软件测试用例批量执行方法，这种方法能够自动控制半实物仿真测试环境完成批量执行测试用例的任务，并且具有在测试执行过程中根据用例执行条件判断用例是否应该执行的能力。特别的，在测试用例或测试对象发生改变需要转换测试环境的时候能够按照需求自动转换测试环境。

为更清楚的介绍本发明在具体实施例中的应用，首先对发明实施例针对的系统的结构做简单介绍：

本测试系统属于半实物仿真测试环境，本测试系统测试用例是由测试脚本的方式实现的；测试环境由图形化仿真建模模块、收集数据定制模块共同构成，其中，图形化仿真建模模块主要用于描述建立测试环境所需的硬件接口以及各接口的各通道上的协议配置以及数据帧结构的定义，将硬件接口上的数据帧定义为“变量”，在收集数据定制模块配置需要收集哪些变量可以确定本测试环境需要收集哪些测试数据。

如图1、2所示，本发明在实施例中的具体步骤如下：

步骤一：首先建立测试用例和测试环境之间的映射关系，一个测试用例与一个测试环境组成一个“测试单元”，可以多个测试用例对应一个相同的测试环境。本发明实施例针对的嵌入式软件半实物仿真测试平台中，测试用例是使用测试脚本实现的，测试环境由图形化仿真建模模块、收集数据定制模块共同构成。

测试开始之前，用户首先根据ICD文档（接口控制文档）和被测件对外通讯协议进行交联环境建模，建模过程中配置测试环境需要使用那些类型的接口，每种接口需要使用几个通道，以及通道上数据的格式和通道的协议属性信息（例如波特率、校验方式等）等。建模完成后配置本测试环境在测试过程中需要收集哪些硬件接口中的值，以及以何种方式进行接收（轮询、中断）等。然后将测试用例转换为可以在测试环境中执行的测试脚本，通过在测试脚本中操作建模过程中定制好的各硬件接口收发数据完成嵌入式软件测试。

测试用例和测试环境都定制完成后，将测试用例和测试环境映射起来，本实施例中使用一个类CTestUnit将测试用例类（CTestCase）和测试环境类(CTestEnvironment)的实例作为成员管理起来。也可以使用结构体等方式实现，只要能够建立其测试用例和测试环境之间的映射组成“测试单元”即可，对本发明所述方法本身的实现没有影响。

步骤二：每个“测试单元”对应唯一的序号，并且记录本“测试单元”执行完后应该执行的下一个“测试单元”的序号，“测试单元”对应的测试用例通过和不通过分别对应一个序号，如果下一个“测试单元”的序号为空则说明本“测试单元”执行完后不需要继续执行测试，停止测试即可。

在本发明实施例中，为“测试单元”类CTestUnit增加成员变量“ID”，用于记录该“测试单元”的序号，CTestUnit类的实例在构造的时候自动获取当前有多少个实例已经构造，然后在CTestUnit类实例总数的基础上加一，为当前实例的ID。如果实现“测试单元”的方法不相同，则采取别的方式生成ID，只要保证所有“测试单元”的ID都不相同即可，具体的实现方式与本发明所述方法无关。本实施例中，由于生成的所有CTestUnit类的实例都保存在步骤三所述的数据结构中，所以只要获取该数据结构中保存的实例数即可知当前有多少个实例已经构造，当然，也可以通过给CTestUnit类添加静态成员等方法实现。

CTestUnit类中增加成员NextID_1和NextID_2，分别用来记录本“测试单元”中的用例执行通过或者不通过下一个应该执行的“测试单元”的ID，如果为-1则说明本“测试单元”执行后不需要继续执行测试。针对不同的情况，如果每个“测试单元”不是记录下一个节点的序号而是记录下一个节点的指针或者引用，对本发明的实现并无影响，只要保证本“测试单元”执行完后可以顺利获得所需信息并执行下一个“测试单元”即可；

每个“测试单元”记录自己的执行条件，可以根据某个已经执行过的“测试单元”对应的测试用例的执行情况判断本“测试单元”是否应该执行，也可以根据系统中的某个变量的值是否符合预期来判断本“测试单元”是否应该执行。在本实施例中，采用以下方案实现该功能：为CTestUnit增加两个字符串成员ConditionUnit和ConditionValue，ConditionUnit用来记录以某个“测试单元”的执行情况作为判断的执行条件，例如，1:1表示序号为1的“测试单元”对应的测试用例如果通过则执行本“测试单元”；1:0表示序号为1的“测试单元”对应的测试用例如果不通过则执行本“测试单元”；ConditionValue用来记录以某个变量的变量值作为判断的执行条件，例如：Variable_1=1表示如果变量Variable为1则执行本“测试单元”。

为CTestUnit类增加一个成员变量isCasePass，用于记录本“测试单元”对应的测试用例的测试结果，如果用例通过将isCasePass置为1，如果不通过将其置为0，所有CTestUnit在初始化时都将isCasePass置为0；

本发明实施例中构建“测试单元”的具体流程如图3。

步骤三：使用数据结构保存所有的“测试单元”，数组、链表、STL里的容器等结构都可以，但是要保证能够通过“测试单元”的序号获得“测试单元”的所有信息（得到指针或者实例）。

本发明实施例中使用STL标准库中的map保存“测试单元”，构造“测试单元”的时候，首先调用CTestUnit类的构造函数，构造函数会自动生成本“测试单元”的序号，即CTestUnit类的ID成员，将ID作为map的key，新构造的CTestUnit类实例的地址作为map的value插入到map中，这要在需要根据序号获取“测试单元”信息的时候，可以使用map的find函数以很高的效率实现。本发明所述方法应用于其他系统时，如果使用别的结构保存“测试单元”，也可以使用遍历所有“测试单元”比较序号的方式获得所需信息，只对实现效率有影响，与发明方法的实现无关；

步骤四至步骤七为本发明方法中“测试单元”自动执行的实现过程，如图4所示。

步骤四：测试过程开始后，由第一个“测试单元”开始执行。执行前首先判断“测试单元”执行的条件是否符合，如果不符合则不执行本节点，直接执行本节点测试用例不通过时执行的下一个“测试单元”。

对第一个“测试单元”来说，ConditionUnit的条件没有意义，因为本次测试过程中还没有执行过任何“测试单元”；对第一个之后的“测试单元”来说，如果ConditionUnit条件存在，则判断该条件是否符合，通过获取指定“测试单元”的isCasePass成员变量的值并与给定的条件比较，可以明确是否符合ConditionUnit条件，如果符合则继续运行不符合直接跳到步骤六运行下一个“测试单元”；如果ConditionValue的条件存在，则说明本“测试单元”运行前需要检查系统中的某个变量值是否符合条件再运行“测试单元”；在本发明实施例中，测试用例是用测试脚本实现的，故可以将条件的判断添加到测试脚本中，首先获取“测试单元”对应的测试用例，并获取实现测试用例的测试脚本，然后在测试脚本之前添加条件判断语句，例如，ConditionValue为Variable_1=1的情况下，在测试脚本之前添加语句if（Variable_1!=1）{return;}，这样在测试用例开始运行的时候会首先检查条件是否符合，如果不符合直接退出；上文示例中的if（Variable_1!=1）{return;}语句使用C语言语法，本发明实施例中的测试脚本使用C语法，如果应用本方法的其他测试系统使用其他脚本实现，采用类似的结构构建条件检查语句即可；如果针对的测试系统实现测试用例的方法不是测试脚本，只需要在正式执行测试用例之前先判断系统中的变量是否符合条件要求即可，具体的实现方式对本发明没有影响；

步骤五：测试用例执行前先判断测试环境是否需要转换，如果需要转换按照“测试单元”的配置转换测试环境，否则直接开始执行测试用例。在本发明实施例中，可以按照以下流程对测试环境进行判断和转换：首先比较当前测试环境中已经初始化的接口和测试环境要求的接口是否相同，如果不相同则关闭多余的接口，打开缺少的接口，按照测试环境配置中记录的各接口各通道的ICD配置设置好各个硬件接口上的各通道的工作模式。第二步检查各接口上的变量是否和根据通信协议配置的数据帧结构相符，变量的定义是为了方便在测试脚本中操作接口进行数据收发，并不是采用本发明的所有测试系统都需要变量的概念，但是所有系统都需要一种描述接口上的数据帧长度和结构的方法，进行测试环境转换的时候务必保证数据帧的结构和长度与通信协议相符。最后一步是根据测试用例的要求修改本测试环境在测试过程中需要收集哪些硬件接口中的值，以及以何种方式进行接收（轮询、中断）等。

本发明实施例中检查并转换测试环境的实现过程见图5所示。

针对不同的领域的测试，转换测试环境所要进行的工作不尽相同，本发明所述方法特别适用于嵌入式软件的测试，通常嵌入式软件转换测试环境时很可能需要改变测试环境中的硬件接口和通讯协议，也可提前将每个测试环境对应的各接口上的通讯协议进行建模或者封装成一个子程序，在需要转换测试环境的时候进行调用和实现；

步骤六：“测试单元”执行完后根据测试用例的预期输出判断本“测试单元”对应的测试用例是否通过测试，并且将是否通过记录到CTestUnit类的成员isCasePass中。根据本“测试单元”对应的测试用例的执行情况确定下一个执行的“测试单元”，根据CTestUnit类的成员NextID_1和NextID_2，从保存所有“测试单元”的数据结构中获得下一个执行的“测试单元”的所有信息。如果本“测试单元”因为执行条件不符合没有执行，则按照“测试单元”对应的测试用例不通过执行后续的测试过程；

步骤七：在测试执行过程中将所有用例的执行情况和得到的实际输出记录下来，步骤五中已经根据测试用例要求将需要收集哪些接口上的数据以及以什么方式收集定制到了测试环境中，在测试过程中收集到的所有测试数据保存到数据库中，每个“测试单元”对应一个测试数据文件，并且以测试用例的名称命名，以便测试结束后方便测试人员进行分析。

本发明未详细阐述部分属于本领域公知技术。

以上所述，仅为本发明部分具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本领域的人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (4)

1.一种可自动转换的嵌入式软件测试用例批量执行方法，其特征在于实现步骤如下：

(1)建立测试用例和测试环境之间的映射关系，一个测试用例与一个测试环境组成一个测试单元；

(2)每个测试单元对应唯一的序号，并且记录本测试单元执行完后应该执行的下一个测试单元的序号，测试单元对应的测试用例通过和不通过分别对应一个序号，如果下一个测试单元的序号为空，则说明该测试单元执行完后不需要继续执行测试，停止测试即可；每个测试单元均记录自己的执行条件；

(3)使用数据结构保存所有的测试单元，保证能够通过测试单元的序号获得测试单元的所有信息；

(4)测试过程开始后，第一个测试单元开始执行；

(5)测试用例执行前，首先判断测试环境是否需要转换，如果需要转换按照测试单元的配置转换测试环境，否则直接开始执行测试用例；

(6)执行完判断该测试用例是否通过，以便确定下一个执行的测试单元，如果该测试单元因为执行条件不符合没有执行，则按照测试单元对应的测试用例不通过执行后续的测试过程；

(7)在测试执行过程中将所有用例的执行情况和得到的实际输出记录起来，等待测试人员分析；

所述步骤(5)中按照下列进行测试环境的判断和转换：

(1)检查测试环境要求的接口与当前测试环境中已经初始化的接口是否相同，不相同则打开缺少的接口并关闭多余的接口；如果相同则检查各接口的各个通道配置是否正确；

(2)检查各接口每个通道的工作模式是否与测试环境要求一致，如果不一致按照被测件接口控制文档和通讯协议的要求重新初始化该通道的工作模式；

(3)检查各接口每个通道上的数据帧结构是否与测试环境要求一致，如果不一致则重新定义该通道上的数据帧结构；

(4)检查测试过程中需要收集的测试数据是否有变化，有变化则按照测试环境的要求修改需要收集的值。

2.根据权利要求1所述的可自动转换的嵌入式软件测试用例批量执行方法，其特征在于：所述步骤(1)中多个测试用例对应一个相同的测试环境。

3.根据权利要求1所述的可自动转换的嵌入式软件测试用例批量执行方法，其特征在于：所述步骤(2)中每个测试单元记录自己的执行条件时，根据某个已经执行过的测试单元对应的测试用例的执行情况判断该测试单元是否应该执行，或根据系统中的某个变量的值是否符合预期来判断该测试单元是否应该执行；针对不同的情况，如果每个测试单元不是记录下一个节点的序号而是记录下一个节点的指针或者引用，实现并无影响，只要保证该测试单元执行完后获得所需信息并顺利执行下一个测试单元即可。

4.根据权利要求1所述的可自动转换的嵌入式软件测试用例批量执行方法，其特征在于：所述步骤(2)中采用数组、链表、STL库中的容器结构均可。