CN103678102A - 包含中间层的测试系统及程序测试方法 - Google Patents

Abstract

一种包含中间层的测试系统，运行于数据处理设备，该测试系统包括基础测试类层、标准测试类层及用户层，在标准测试类层及用户层之间，该测试系统还包括：第一中间层，用于定义抽象类，该抽象类继承自标准测试类层的测试类；第二中间层，用于定义测试类，该测试类继承自第一中间层的抽象类，且该测试类指定具体的测试类型；所述第一中间层，还用于实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作，及实现在第二中间层的测试类中的最后一个测试用例执行后插入扩展操作。利用本发明可以增加测试系统的可扩展性。

Description

包含中间层的测试系统及程序测试方法

技术领域

本发明涉及一种测试系统及程序测试方法，尤其涉及一种包含中间层的测试系统及程序测试方法。

背景技术

在软件实际开发的过程中，需要不断地进行测试（例如，单元测试、整合测试及系统测试等），以检测所开发的软件是否合格。一般而言，测试人员都会使用某种测试系统对所开发的软件进行测试，由于测试系统集成了很多测试接口，测试人员只需编写测试用例就可以对所需要测试的任务（如，应用程序、用户界面等）进行测试，如此一来，提高了测试效率，例如，通过Junit测试系统得到组件，模拟发送事件和检测程序处理的正确性。

然而，以往的测试系统提供的API接口比较基础，提供的扩展点只有初始化函数setup()、运行函数runBare()和结束函数teardown()。例如，由针对Android环境扩展了JUnit（JUnit3）测试系统得到的AndroidUnit测试系统，该测试系统可以进行从用户界面（user-interface）到单元测试等不同层次的测试。而AndroidUnit测试系统提供的API接口也比较基础，提供的扩展点也只有setup()、runBare()和teardown()，如此一来，限制测试系统的可扩展性。

此外，更大的局限在于，以往的测试系统系统提供的测试类指定默认的模版参数，这种默认方式指向被测的Application或Activity，如果需要一个能够扩展通用的、与默认的模板参数无关的操作，以往的测试系统中没有提供做这些操作的明确位置和规范。例如，AndroidUnit测试系统提供的测试用例都有模版参数，这样AndroidUnit系统直接使用时，测试类需要直接继承自如ApplicatonTestCase<T extends Application>或ActivityInstrumentationTestCase2<T extends Activity>这些带<T>的测试类，这种默认方式立即就指向被测Application或Activity了，如果需要一个能够扩展通用的、与具体<T>无关的操作的地方，AndroidUnit系统中没有提供做这些事的明确位置和规范。

具体而言，以AndroidUnit测试系统为例，直接使用该测试系统进行测试，其方法调用顺序如图1所示，从图1中可以看出，扩展点除了需要实现的测试用例方法之外，只有setup()、runBare()和teardown()，同时测试类直接指定模板参数<T>,若测试人员想做一个与指定模板参数<T>无法通用的操作，并扩展一个中间层，使得该中间层与AndroidUnit测试系统解除直接耦合是无法实现的。

发明内容

有鉴于此，有必要提供一种包含中间层的测试系统，其包括中间层，增加了测试系统的可扩展性。

此外，还有必要提供一种基于测试系统的程序测试方法，增加了测试系统的可扩展性。

一种包含中间层的测试系统，运行于数据处理设备，该测试系统包括基础测试类层、标准测试类层及用户层，在标准测试类层及用户层之间，该测试系统还包括：第一中间层，用于定义抽象类，该抽象类继承自标准测试类层的测试类；第二中间层，用于定义测试类，该测试类继承自第一中间层的抽象类，且该测试类指定具体的测试类型；所述第一中间层，还用于实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作，及实现在第二中间层的测试类中的最后一个测试用例执行后插入扩展操作。

一种基于测试系统的程序测试方法，该测试系统运行于数据处理设备，包括基础测试类层、标准测试类层及用户层，该测试方法包括：在标准测试类层及用户层之间创建第一种层及第二中间层；第一中间层定义抽象类，该抽象类继承自标准测试类层的测试类；第二中间层定义测试类，该测试类继承自第一中间层的抽象类，且该测试类指定具体的测试类型；第一中间层实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作；第一中间层实现在第二中间层的测试类中的最后一个测试用例执行后插入扩展操作。

本发明有益效果是，增加了测试系统的可扩展性，可以让测试人员做与指定模板产生无法通用的操作，并加入了中间层，实现了中间层与标准测试层直接耦合的解除，方便了测试人员，提高了测试效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其他目的、特征和优点能够更明显易懂，以下特举较佳实施例，并配合附图，详细说明如下。

附图说明

图1是本发明实施例中包含中间层的测试系统的运行环境图。

图2是使用现有技术中的测试系统进行测试的方法调用顺序的统一建模语言（UML，Unified Modeling Language）图。

图3是本发明实施例中包含中间层的测试系统的结构示意图。

图4A至图4B是本发明实施例中使用包含中间层的测试系统进行测试的方法调用顺序的UML图。

图5是本发明实施例中基于测试系统的程序测试方法的流程图。

具体实施方式

为更进一步阐述本发明为达成预定发明目的所采取的技术手段及功效，以下结合附图及较佳实施例，对本发明的具体实施方式、结构、特征及其功效，详细说明如后。

如图1所示，是本发明实施例中包含中间层的测试系统的运行环境图。该包含中间层的测试系统100运行于数据处理设备1中，确切的说，该包含中间层的测试系统100运行于安装有开发环境软件10的数据处理设备中。该数据处理设备1还包括一处理器11，该处理器11用于启动开发环境软件10，并在开发环境软件中运行所述包含中间层的测试系统100。所述数据处理设备1可以是计算机、手机或个人数字助理等。所述开发环境软件10可以是Eclipse开发环境软件、Jbuilder开发环境软件或其它任意能够集成包含中间层的测试系统100的开发环境软件。

如图3所示，是本发明实施例中包含中间层的测试系统的结构示意图。该包含中间层的测试系统100包括五层结构，分别为基础测试类层110、标准测试类层120、第一中间层130、第二中间层140及用户层150。

所述基础测试类层110定义的测试类是最基础的，该基础测试类层110定义的测试类由标准测试类层120继承，在本较佳实施例中，所述基础测试类层是指Junit，该Junit定义的测试类为TestCase类。

所述标准测试类层120定义的测试类继承自基础测试类层110所定义的测试类，且该标准测试类层120定义的测试类中指定模板参数，所述模板参数对应指定的测试类型（例如，Application或Activity）。在本较佳实施例中，所述基础测试类层是指AndroidUnit，该AndroidUnit定义的测试类为AndroidTestCase类及InstrumentationTestCase类，所述AndroidTestCase类及InstrumentationTestCase类都继承自JUnit的TestCase类。其中AndroidTestCase类及InstrumentationTestCase类下面都包括一个或多个子类，每个子类都指定测试类型（例如，Application或Activity）。具体而言，AndroidTestCase类包括ApplicationTestCase子类，该ApplicationTestCase子类指定模板参数为应用程序，则该ApplicationTestCase子类为测试整个应用程序（Application）的类。InstrumentationTestCase类包括ActivityTestCase子类，该ActivityTestCase子类指定模板参数为活动（Activity），则该ActivityTestCase子类为测试活动（Activity）的类。此外，该标准测试类层120还提供初始化setup()、运行函数runBare()和结束teardown()，测试人员可以通过提供的初始化setup()、运行函数runBare()和结束teardown()对测试系统中的代码进行扩展，以实现扩展操作。其中，setup()函数用来初始化设置，如启动一个Activity或Application，或初始化资源等，teardown()函数则用来垃圾清理与资源回收，runBare()函数用来运行，如运行一个Activity或Application。

所述第一中间层130定义抽象类，该抽象类继承自标准测试类层120所定义的测试类，该抽象类不指定模板参数，即不指定测试类型。在本较佳实施例中，该抽象类的名称为即MiddleWareTestCase类。

所述第二中间层140定义测试类，该测试类继承自第一中间层130所定义的抽象类，该测试类指定模板参数，即指定测试类型。测试人员通过第二中间层140定义的测试类，可以创建具体的测试用例，以检测测试人员所设定的测试任务（例如，某一个用户界面是否合格等）。在本较佳实施例中，该抽象类的名称为即xxxAppTestCase类。

此外，第一中间层130在扩展时机上增加了doBeforeFirstCase和doAfterLastCase这两个扩展点，其中doBeforeFirstCase可以实现在第二中间层140的测试类中的第一个测试用例执行前插入扩展操作，doAfterLastCase可以实现在第二中间层140的测试类中的最后一个用例执行后插入扩展操作。由于第一中间层130的抽象类并没有指定测试类型，且增加了两个扩展点，因此，测试人员可以利用上述两个扩展点在该第一中间层130中执行一些与指定的测试类型无关的通用操作，例如，自有格式的结果统计工作等操作。

所述用户层150定义测试类，该测试类继承自第二中间层140的测试类，即DemoTestCase类，测试人员可以通过该测试类创建具体的方法，在调用通过该测试类创建具体的方法时可以在显示器（未示出）上显示所检测的测试任务的效果。例如，测试人员测试某一个应用程序，通过调用该测试类所创建的方法，可以在显示器上看到该应用程序的效果。

上述五层结构的包含中间层的测试系统100中，层与层之间是继承关系，即标准测试类层120定义的测试类继承自基础测试类层110的TestCase类，第一中间层130定义的抽象类继承自标准测试类层120所定义的测试类，第二中间层140定义的测试类继承自第一中间层130的抽象类，用户层的测试类150继承自第二中间层140的测试类。

图4A至图4B是本发明实施例中使用包含中间层的测试系统进行测试的方法调用顺序的UML图。从图4A至图4B中可以看出，第一中间层130的测试类（即MiddleWareTestCase类）可以和标准测试类层（即AndroidUnit）进行解耦，而MiddleWareTestCase类可以继承自AndroidUnit的测试类，也可以继承自其它基于Junit的测试类，如此一来，可以在兼容Java代码的体系内做移植和扩展，仍然复用Junit的测试用例执行组件，所以很轻量。同时，MiddleWareTestCase类不需要直接指定测试类型，而把指定具体测试类型的任务交给了第二中间层140，即在第二中间层140中指定测试类型，如此一来，第一中间层130成为一个与指定的测试类型无关的层。而相比标准测试类层120，第一中间层130增加了两个扩展点，用户可以通过这两个扩展点加入一些与指定的测试类型无关的操作。

图5是本发明实施例中创建包含中间层的测试系统的方法的流程图。

步骤S10，第一中间层130定义抽象类，该抽象类继承自标准测试类层120的测试类。该抽象类不指定模板参数，即不指定测试类型。在本较佳实施例中，该抽象类的名称为即MiddleWareTestCase类。MiddleWareTestCase类的实现方法所对应的代码如下：

public QLApplicationTestCase(Class app){

super(app);

}

上述代码中是以基于ApplicationTestCase<T>的实现为例，第一中间层130抽象类起名为QLApplicationTestCase，该抽象类不指定测试类型，而以super(app)的形式处理。

步骤S20，第二中间层140定义测试类，该测试类继承自第一中间层130的抽象类，且该测试类指定测试类型。第二中间层140定义的测试类指定测试类型所对应的代码如下：

public QXinTestCase(){

super(TpfDemoApp.class);

}

上述代码中，指定测试类型为TpfdemoApp.class，该TpfdemoApp.class对应某一个Application。

步骤S30，第一中间层130实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作。所述实现在第二中间层140的测试类中的第一个测试用例执行前插入扩展操作的方式是在标准测试类层120的初始化函数setup()中使用静态测试用例计数器的方式来实现。具体实现方式所对应的代码如下：

可以理解，上述代码中Thread.sleep(3000)，是等待应用创建过程的一个简化写法，一般的应用3秒（3000毫秒）基本也完成onCreate()操作了。然而可以理解，还可以采用以下的方式实现：

步骤S40，第一中间层130实现在第二中间层140的测试类中的最后一个测试用例执行后插入扩展操作。所述实现在第二中间层140的测试类中的最后一个测试用例执行后插入扩展操作的方式是在标准测试类层120的结束函数teardown()中使用静态测试用例计数器的方式来实现。具体实现方式所对应的代码如下：

if(mTestCaseCount>=countTestCases())

//在最后一个测试用例执行结束之后在执行

{

doAfterLastCase();

}

super.teardown();

可以理解，在部分测试环境如Junit3/AndroidUnit中countTestCases()是总是返回1，所以直接通过countTestCases()判断本次被执行用例总数是不行的，此时可以通过覆写默认的测试执行器android.test.InstrumentationTestRunner进行解决，用自己的执行器进行替换，在执行器中可以获取本次执行用例的总数，之后可覆写countTestCases()或直接调用新执行器中对本次执行用例总数。覆写默认的测试执行器后，在工程的AndroidManifest.xml中替换为覆写后的执行器，即可使用新的测试执行器了，例如：

<instrumentation

android:name="com.tencent.wstt.ql.android.testrunner.QLTestRunner"

android:targetPackage="com.tencent.wstt.android.fakeapp"/>。

进一步地，除了上述的doBefore Firstcase()以及doAfterLastCase()扩展操作外，还可进一步提供其他的扩展操作，例如提供doBeforeClass()和doAfterC lass()操作。

doBeforeClass()定义为新执行一个具体测试类中第一个用例之前执行。在一次执行的第一个用例前，执行顺序是doBeforeFirstCase()->doBeforeClass()->setup()。

doAfterClass()定义为执行一个具体测试类中最后一个用例之后执行。在一次执行的最后一个用例后，执行顺序是tearDown()->doAfterClass()->doAfterLastCase()。

其具体的实现方式是：保留JUnit执行体系底层逻辑，在系统层（ApplicationTestCase<T>）通过用静态属性记录每次执行的用例所属类名，当上一次执行用例类名和本次执行用例类名相同时，则判断为在同一个测试类，不会触发doBeforeClass()和doAfterClass()方法；当上一次执行用例类名和本次执行用例类名不同时，则说明有测试类的切换，此时即可执行前一测试类的doAfterClass()和当前测试类的doBeforeClass()。

可以理解，JUnit体系主要是针对单元测试的系统，所以其比较强调用例的独立性。事实上JUnit虽然每个测试类中可以包含多个测试用例方法，但是每个测试用例执行时都是一个新的测试类实例，所以会发现执行同一个测试类的下一个测试用例时，前一个用例修改过的非静态属性都会回到初始默认值。这对实现doBeforeClass()和doAfterClass()是一个难点。而在上述的方式中，通过用静态属性记录每次执行的用例所属类名，可以克服这个问题，从而实现上述的doBeforeClass()和doAfterClass()操作。

此外，本发明实施例还提供一种计算机可读存储介质，其内存储有计算机可执行指令，上述的计算机可读存储介质例如为非易失性存储器例如光盘、硬盘、或者闪存。

上述的计算机可执行指令用于让计算机或者类似的运算装置完成以下操作：

在标准测试类层120及用户层150之间创建第一种层130及第二中间层140；

第一中间层130定义抽象类，该抽象类继承自标准测试类层120的测试类。该抽象类不指定模板参数，即不指定测试类型。在本较佳实施例中，该抽象类的名称为即MiddleWareTestCase类。MiddleWareTestCase类的实现方法所对应的代码如下：

public QLApplicationTestCase(Class app){

super(app);

}

上述代码中是以基于ApplicationTestCase<T>的实现为例，第一中间层130抽象类起名为QLApplicationTestCase，该抽象类不指定测试类型，而以super(app)的形式处理。

第二中间层140定义测试类，该测试类继承自第一中间层130的抽象类，且该测试类指定测试类型。第二中间层140定义的测试类指定测试类型所对应的代码如下：

Public QXinTestCase(){

super(TpfDemoApp.class);

}

上述代码中，指定测试类型为TpfdemoApp.class，该TpfdemoApp.class对应某一个Application。

第一中间层130实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作。所述实现在第二中间层140的测试类中的第一个测试用例执行前插入扩展操作的方式是在标准测试类层120的初始化函数setup()中使用静态测试用例计数器的方式来实现。所述扩展操作包括：统计测试结果并按预定格式输出统计结果。具体实现方式所对应的代码如下：

第一中间层130实现在第二中间层140的测试类中的最后一个测试用例执行后插入扩展操作。所述实现在第二中间层140的测试类中的最后一个测试用例执行后插入扩展操作的方式是在标准测试类层120的结束函数teardown()中使用静态测试用例计数器的方式来实现。所述扩展操作包括：统计测试结果并按预定格式输出统计结果。具体实现方式所对应的代码如下：

而标准测试类层120定义的测试类继承自基础测试类层110的TestCase类，第一中间层130定义的抽象类继承自标准测试类层120所定义的测试类，第二中间层140定义的测试类继承自第一中间层130的抽象类，用户层的测试类150继承自第二中间层140的测试类。

此外，本发明实施例还提供一种计算机可读存储介质，其内存储有计算机可执行指令，上述的计算机可读存储介质例如为非易失性存储器例如光盘、硬盘、或者闪存等。

上述的计算机可执行指令用于使计算机或者类似的运算装置进行以上基于测试系统的程序测试方法中的各操作。

最后所应说明的是，以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明，任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。

Claims (10)

1.一种包含中间层的测试系统，运行于数据处理设备，该测试系统包括基础测试类层、标准测试类层及用户层，在标准测试类层及用户层之间，该测试系统还包括：

第一中间层，用于定义抽象类，该抽象类继承自标准测试类层的测试类；

第二中间层，用于定义测试类，该测试类继承自第一中间层的抽象类，且该测试类指定具体的测试类型；及

所述第一中间层，还用于实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作，及实现在第二中间层的测试类中的最后一个测试用例执行后插入扩展操作。

2.如权利要求1所述的包含中间层的测试系统，其特征在于：所述实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作的方式是在标准测试类层的初始化函数中使用静态测试用例计数器的方式来实现。

3.如权利要求1所述的包含中间层的测试系统，其特征在于：所述实现在第二中间层的测试类中的最后一个测试用例执行后插入扩展操作的方式是在标准测试类层的结束函数中使用静态测试用例计数器的方式来实现。

4.如权利要求1所述的包含中间层的测试系统，其特征在于：所述扩展操作包括：统计测试结果并按预定格式输出统计结果。

5.如权利要求1所述的包含中间层的测试系统，其特征在于：标准测试类层的测试类继承自基础测试类层的测试类，第一中间层的抽象类继承自标准测试类层的测试类，第二中间层的测试类继承自第一中间层的抽象类，用户层的测试类继承自第二中间层的测试类。

6.一种基于测试系统的程序测试方法，该测试系统运行于数据处理设备，包括基础测试类层、标准测试类层及用户层，该测试方法包括：

在标准测试类层及用户层之间创建第一种层及第二中间层；

第一中间层定义抽象类，该抽象类继承自标准测试类层的测试类；

第二中间层定义测试类，该测试类继承自第一中间层的抽象类，且该测试类指定具体的测试类型；

第一中间层实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作；及

第一中间层实现在第二中间层的测试类中的最后一个测试用例执行后插入扩展操作。

7.如权利要求6所述的基于测试系统的程序测试方法，其特征在于：所述实现在第二中间层的测试类中的第一个测试用例执行前插入扩展操作的方式是在标准测试类层的初始化函数中使用静态测试用例计数器的方式来实现。

8.如权利要求6所述的基于测试系统的程序测试方法，其特征在于：所述实现在第二中间层的测试类中的最后一个测试用例执行后插入扩展操作的方式是在标准测试类层的结束函数中使用静态测试用例计数器的方式来实现。

9.如权利要求6所述的基于测试系统的程序测试方法，其特征在于：所述扩展操作包括：统计测试结果并按预定格式输出统计结果。

10.如权利要求6所述的基于测试系统的程序测试方法，其特征在于：标准测试类层的测试类继承自基础测试类层的测试类，第一中间层的抽象类继承自标准测试类层的测试类，第二中间层的测试类继承自第一中间层的抽象类，用户层的测试类继承自第二中间层的测试类。

Images