CN100337216C

CN100337216C - 一种软件测试方法

Info

Publication number: CN100337216C
Application number: CNB2004100790410A
Authority: CN
Inventors: 卢庆明
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2004-09-04
Filing date: 2004-09-04
Publication date: 2007-09-12
Anticipated expiration: 2024-09-04
Also published as: CN1744055A

Abstract

本发明有关一种软件测试方法，包括：A)编写一动态加载模块，包含测试用例和资源指针定义，所述资源指针为测试用例中需要用到的指向被测试系统的资源；B)在被测试系统中加入加载测试桩模块，该加载测试桩模块将编译后的动态加载模块加载到被测试系统中；C)生成上述已加入加载测试桩模块的被测试系统的MAP文件，用该MAP文件中的资源定位信息对上述资源指针赋值，实现资源映射；D)动态加载模块从加载测试桩模块接收测试命令，执行测试。采用本发明方法能实现软件黑白盒测试，测试用例管理和维护方便灵活，测试实现复杂度低。

Description

一种软件测试方法

技术领域

本发明涉及电子或通信领域的测试技术，尤指一种软件测试方法。

背景技术

在电子或通信领域，为实现各种功能或应用，都需要建设各种相应的系统或网络，在所述的系统或网络中，除了必需的硬件以外，还配备了各种相应的软件，为了保证所述系统及网络的正常运用，除了保证硬件的正常工作外，还必须保证软件的正常工作，为此就有必要在系统或网络正式运用前，对其中的软件进行测试。

目前实现软件测试的方法很多，但基于测试实现方法(单元测试，集成测试和系统测试)的考虑，测试技术分为系统内测试(被测试系统和测试用例运行在同一应用程序内)和系统外测试(被测试用例运行在被测试系统外)两类，各自有其优点和缺点，下面简单进行说明：

系统外测试在被测试系统外部独立运行，系统内部信息不能直接得到，只能通过系统外部接口(如界面，网络接口等)进行操作来达到测试目的。测试用例的改变不影响被测试系统，但对系统内部运行一无所知，不能实现白盒测试。

系统内测试方法需要和被测试系统进行联合编译(如极限编程eXtremeProgramming所提出的CPPUNIT和JUNIT，DUNIT，CUNIT等方法)，或者在被测试系统内部做统一桩模块(类似计算机病毒)，由外部程序通过某种通信方式控制桩模块进行操作。

联合编译测试的特点是用例对系统内部的存取很方便，但测试用例的修改将停止系统运行，将修改后的测试用例和被测试系统一起进行编译和链接，然后再运行，这样将一次次的关闭系统，达不到对被测试系统的连续和长时间测试的目的，同时使测试过程过于繁杂，操作不便。

在被测试系统外边界实现的黑盒测试如图1所法，被测试系统对外有若干个接口，如果对被测试系统进行测试，需要在不同接口处进行模拟和观察，通过模拟被测试系统对外的交互和观察验证实现测试目的。

这种黑盒测试的缺点如下：

1、测试实现难度大：由于是针对被测试系统(System Under Test，SUT)外部接口进行验证，而被测试系统SUT的外部接口种类繁杂，因此测试接口的编写是一项非常庞大的工作，例如该接口是E1接口，测试用例需要验证从E1发来一条消息，则测试过程的实现只能是，在连接被测试系统E1接口的设备上通过某种手段发送来此消息，有时候需要做专门的E1测试接口，实现起来比较麻烦，很多时候需要独立硬件的支持。

2、测试验证充分度不够：由于是在外部实现对被测试系统的黑盒测试，被测试系统内部的情况一无所知，因此针对内部接口的测试无法实现，必须通过在被测试系统内部增加有关的额外代码将所需要的内部信息输出来，才可以验证外部测试执行对被测试系统的影响，这样就增加了被测试系统的复杂度。

3、部分异常测试难以实现：由于是在被测试系统外部进行测试，部分异常情况难以模拟，如时序测试等，则这种测试模型下由于系统结构限制基本很难成功实现。

现有技术中，还有一种白盒测试方法，如图2、图3所示，此种测试模型中，所有的测试用例在测试代码桩中实现，测试代码桩中实现了测试逻辑，并且受测试控制中心的控制来执行测试，测试控制中心和测试代码桩连接，并且向它下发测试用例执行命令，可带有简单的参数，测试结果通过测试控制中心输出出来，如果只需要无选择的测试，也可不需要测试控制中心，程序启动自动执行测试，并将结果通过被测试系统提供的接口输出出来。

在编译过程中需要被测试系统的源代码或者是库文件，连同被测试代码桩一起进行编译和链接，测试代码桩需要和被测试系统的编译和链接选项一致，如果不一致将导致错误出现。

白盒测试的缺点如下：

1、维护麻烦：需要和被测试系统进行联合编译和链接，如果需要补充测试用例，还需要将系统停掉，然后修改被测试代码，并同被测试系统进行联编，运行联编后得到的可执行程序执行测试。如果系统在单板上运行，则加载的时间可能会非常长，这样将大大影响测试效率。

2、两类程序相互影响：有可能测试代码和被测试系统(SUT)采用不同的相互影响的编译选项，导致编译或者链接不能通过，公共资源(如函数，变量等)有可能冲突等都属于这种情况。或者测试代码引进了其他的第三方软件模块和SUT编译链接存在冲突，导致测试不能进行下去。

3、目标代码大：由于所有的测试用例都被联编，这样将导致联编后的目标程序非常大，相当不灵活，对系统的加载和启动等也带来很大的麻烦。如果将测试用例分开，则将分别联编，这样测试执行将只能不断启停系统，也很麻烦，且做不到连续测试的目的，对于一些需要连续测试观察的应用场合不适用。

发明内容

本发明提供一种软件测试方法，结合上述黑盒测试模型和白盒测试模型的优点，在实现白盒测试的基础上实现测试用例与被测试系统相互独立，测试用例的生成也不受被测试系统影响。

本发明提供的软件测试方法，包括下列步骤：

A)编写一动态加载模块，包含测试用例和资源指针的定义，所述资源指针指向测试用例中需要用到的被测试系统的资源；

B)在被测试系统中加入加载测试桩模块，该加载测试桩模块的作用是将编译后的测试用例的动态加载模块加载到被测试系统中；

C)生成上述已加入加载测试桩模块的被测试系统的MAP文件，用该MAP文件中的资源定位信息对所述资源指针赋值，实现资源映射；

D)动态加载模块从加载测试桩模块接收测试命令，执行测试。

根据本发明的上述方法，所述步骤B中的加载测试桩模块用源代码或者链接库的方式加入到被测试系统中。

根据本发明的上述方法，所述步骤C中实现资源映射的具体方法为：将MAP文件中需要映射的资源地址解析出来放在一个独立文件中，所述动态加载模块读取该独立文件进行解析，实现资源映射。

根据本发明的上述方法，所述步骤C中实现资源映射的具体方法为：将MAP文件中需要映射的资源地址解析出来直接加入到动态加载模块代码中编译，直接实现资源映射。

根据本发明的上述方法，其特征在于：所述步骤B中在被测试系统中加入加载测试桩模块后还包括有一加载控制中心与所述加载测试桩模块实现通信，实现通信的过程为：该加载控制中心发起加载/卸载命令和测试操作命令；所述加载测试桩模块接收并解析加载控制中心发出的加载/卸载命令，将动态加载模块加载到被测试系统或从被测试系统中卸载动态加载模块；所述加载测试桩模块将加载控制中心发来的测试操作命令传递给动态加载模块，控制所述动态加载模块实现测试。

根据本发明的上述方法，所述加载测试桩模块控制所述动态加载模块运行于独立任务或统一任务模式实现测试过程。

根据本发明的上述方法，所述加载控制中心还实现与其它用户测试模块的通信，其过程为：接收其它用户测试模块发出的命令，将接收的命令发往所述加载测试桩模块，并将测试结果信息显示给用户。

根据本发明的上述方法，所述加载控制中心还与用户直接进行信息交互，其过程为：接收用户发出的命令，将接收的命令发往所述加载测试桩模块，并将测试结果信息显示给用户。

根据本发明的上述方法，所述测试用例采用与被测试系统不同的编译型编程语言实现。

本发明技术方案带来的有益效果如下：

1、方便实现软件测试的黑白盒测试，使测试用例可以同时实现黑盒测试和白盒测试所具有的益处，包括黑盒测试的相对独立性和白盒测试对于SUT内部资源的可视化和可操作性。使测试过程和被测试系统(SUT)的关联和耦合程度可以由测试人员灵活掌控。

2、测试用例管理和维护方便灵活，独立于具体的被测试系统(SUT)，便于实现测试模块的组件化和标准化。

3、测试设计和实现的复杂度降低，提供给测试人员在用例设计编码语言上更多的选择，以及在测试过程中的多任务实现。

附图说明

图1为现有技术中的黑盒测试示意图。

图2为现有技术中的白盒测试被测系统运行过程示意图。

图3为现有技术中的白盒测试被测系统编译过程示意图。

图4为本发明方法测试过程示意图。

具体实施方式

参见图4，为本发明方法测试过程示意图。如图所示，在被测试系统(SUT)中加入加载测试桩模块(LTM)，该LTM模块在SUT编译前加入，作为一个独立的模块，可用源代码或者链接库的方式加入到被测试系统中，它的功能是如下：

1、管理多个动态加载模块(DLM)的加载和卸载过程，每个DLM实现不同的测试目的，相互独立，并实现这些加载模块运行于独立任务/统一任务模式的支持。所述独立任务不占用SUT本身任务的执行时间，即一般的独立线程模式，统一任务需要占用SUT任务来执行。

2、受加载控制中心(LCC)的操作控制，将动态加载模块文件加载到被测试系统中，并实现动态加载模块和加载控制中心之间的通信。LTM通过解析加载控制中心发来的加载/卸载命令实现将动态加载模块文件加载到被测试系统中或从被测试系统中卸载动态加载模块。

加载测试桩模块(LTM)的具体实现如下：

1、通过某种进程间通信机制(如网络各种方法、RPC，DCOM等，或者操作系统支持的如IPC、命名管道等)和加载控制中心LCC进行通信，通过某种机制(如网络通过不同的端口，不同的命名管道名等)将LCC发来的连接通道作为统一任务/独立进程通道(根据测试需要和目的而定，如果针对的是被测试系统内部的集成测试和单元测试，可采用统一任务，如果需要模拟被测试系统外部的其他实体即系统之间的交互测试，可采用独立任务)，如果是统一进程，则收到LCC发来的命令后直接执行，如果是独立任务，则需要生成新任务，将该通道转到新任务中执行和LCC的通信。

2、接收LCC发来的命令，解析其中的LOAD和UNLOAD命令，实现动态加载模块的装载和卸载。

3、LTM如果判断和LCC的通道中断，则执行加载模块卸载，同时释放该通道(可选的异常处理)。

动态加载模块(DLM)，包括测试用例，实现的功能如下：

1、设置被测试系统中的资源(包括函数和变量)指针定义原型。

2、在初始化时读入被测试系统(包括加载测试桩模块)的MAP文件，根据MAP文件中的资源定位信息设置DLM中资源指针，使DLM中的资源指针指向实际的SUT内资源，实现资源映射。

3、响应加载控制中心发来的测试操作命令，执行DLM中定义的接口函数实现测试。

动态加载模块(DLM)的具体实现如下：

1、首先编写动态链接模块，在其中制订SUT中的资源指针定义，如下：

void(^*fln1)(VOS_INT32iNum)＝0；

struct StructList^*list；

其中fln1为SUT中存在的函数，list是SUT中的StructList全局变量list指针，当然也可以包括其他类型资源，如类实例，数组等等。

2、定义指针变量映射数组，如果在DLM中包括的头文件中已经存在有函数的定义，则需要进行函数实体的空定义如下：

FucMap 1Map[]＝{

{(unsigned long^*)&fln1，″fin1″}，

{(unsigned long^*)&list，”list”}

…

}

3、提供MAP文件将这些指针进行静态映射的手段：

读取map文件中fln1的描述，将SUT MAP中的fln1的地址给fln1指针，这样在动态加载模块中对fln1的引用将实现直接调用SUT中的引用。

注意：需要在DLM和SUT中定义函数原型要一致，如果采用不同的编程语言则要保证函数的参数出入栈顺序是一致的，即在函数定义前加入函数类型标识符，如_fastcall，_stdcall等等。

4、提供函数补丁功能，将被补丁的函数地址保存，加入跳转到新函数的指令，同时提供被补丁函数恢复功能。

动态加载模块可以实现预定义的接口函数，LTM在加载进来后执行这些预定义接口函数，将MAP文件中的资源映射关系(资源如函数和全局变量与SUT内的地址对应关系)映射进动态加载模块的指针中。具体的实现过程：用MAP文件中定义的地址对指针赋值。

在DLM实现SUT MAP文件的映射可以采取多种实现方式，包括但不限于下述方法：

将MAP中需要映射的资源地址解析出来放在一个独立文件中，在DLM中读取文件解析，实现映射。

将MAP中需要映射的资源地址解析出直接放在DLM代码中编译。

加载控制中心(LCC)实现功能如下：

1、实现和SUT中LTM的通信功能，发起加载/卸载动态模块的命令，以及发起测试操作命令。该模块外部可以和用户直接进行交互，也可以和其他用户测试模块通信，接收命令发往LTM。

2、将动态加载模块(DLM)中测试执行结果信息显示给用户，或者发回给其他用户测试模块。

加载控制中心(LCC)的具体实现如下：

1、加载控制中心根据配置信息或者用户/其他测试工具的命令，通过和LTM之间的通信机制，发起建立和LTM的连接通道。

2、LCC根据用户命令和LTM进行交互，实现测试目的。并将DLM中测试用例执行过程中返回的信息显示出来。

LCC和LTM之间的通信可以采用任何系统间/系统内进程间通信的机制，包括但不限于网络，RPC，IPC等方法。

LCC是可选的，用户可以直接通过连接到LTM发命令实现相同功能。

LCC和LTM之间的通信如软件协议可以采取任何协议形式，也可以采用现有的脚本技术实现(如PYTHON和TCL等)。

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

Claims

1、一种软件测试方法，包括下列步骤：

2、如权利要求1所述的方法，其特征在于：所述步骤B中的加载测试桩模块用源代码或者链接库的方式加入到被测试系统中。

3、如权利要求2所述的方法，其特征在于：所述步骤C中实现资源映射的具体方法为：将MAP文件中需要映射的资源地址解析出来放在一个独立文件中，所述动态加载模块读取该独立文件进行解析，实现资源映射。

4、如权利要求2所述的方法，其特征在于：所述步骤C中实现资源映射的具体方法为：将MAP文件中需要映射的资源地址解析出来直接加入到动态加载模块代码中编译，直接实现资源映射。

5、如权利要求1、2、3或4所述的方法，其特征在于：所述步骤B中在被测试系统中加入加载测试桩模块后还包括有一加载控制中心与所述加载测试桩模块实现通信，实现通信的过程为：该加载控制中心发起加载/卸载命令和测试操作命令；所述加载测试桩模块接收并解析加载控制中心发出的加载/卸载命令，将动态加载模块加载到被测试系统或从被测试系统中卸载动态加载模块；所述加载测试桩模块将加载控制中心发来的测试操作命令传递给动态加载模块，控制所述动态加载模块实现测试。

6、如权利要求5所述的方法，其特征在于：所述加载测试桩模块控制所述动态加载模块运行于独立任务或统一任务模式实现测试过程。

7、如权利要求5所述的方法，其特征在于：所述加载控制中心还实现与其它用户测试模块的通信，其过程为：接收其它用户测试模块发出的命令，将接收的命令发往所述加载测试桩模块，并将测试结果信息显示给用户。

8、如权利要求5所述的方法，其特征在于：所述加载控制中心还与用户直接进行信息交互，其过程为：接收用户发出的命令，将接收的命令发往所述加载测试桩模块，并将测试结果信息显示给用户。

9、如权利要求1所述的方法，其特征在于：所述测试用例采用与被测试系统不同的编译型编程语言实现。