CN104834590A - 软件测试方法和*** - Google Patents

Abstract

本发明提供了一种软件测试方法，所述方法包括：获取第一配置文件，所述第一配置文件中设有插桩点和对应的用于产生测试场景的插桩代码；根据所述第一配置文件，在被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件；运行所述插桩后的被测软件，当所述插桩后的被测软件中的所述插桩点被触发时，执行与触发的所述插桩点对应的所述插桩代码。采用该软件测试方法，能够模拟各种异常场景且能节省测试时间成本。此外，还提供了一种软件测试***。

Description

软件测试方法和***

技术领域

本发明涉及软件测试技术领域，特别是涉及一种软件测试方法和***。

背景技术

软件在发布之前为确保软件的稳定性，需要对软件进行测试。在软件测试中，为保证软件质量，需要对各种软件可能面临的场景进行覆盖测试，包括正常的和异常的场景，特别是一些异常的场景，比如：机器内存不足、磁盘空间不足、本地文件读写错误和异常数据等。传统技术中，通常会采用基于功能的黑盒测试方法和基于代码的白盒测试方法这两种方案来实现软件测试。

基于功能的黑盒测试方法，如果要覆盖各种异常场景，比如，对于机器内存不足的异常场景，需要开启大量的程序将***的内存耗尽；对于磁盘空间不足的异常场景，则需要通过拷贝文件等方式将本地磁盘空间占满。因此基于功能的黑盒测试方法实现起来比较困难，且需要一定的测试时间成本。并且，对于一些程序内部的异常分支，如某个函数异常返回，基于功能的黑盒测试方法更加难以模拟。

基于代码的白盒测试方法，虽然能够在程序运行时设置断点，通过手动修改程序运行时数据或者临时修改代码来模拟这类异常场景，但是这种方式的测试时间成本同样很高，特别是对于一些涉及到较多代码模块修改的特定场景的模拟，比如，所有new函数调用均要返回NULL的特定场景，这种测试方法的时间成本会更加高。

因此，传统的软件测试方法存在异常场景难以模拟且测试时间成本较高的技术问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能模拟出各种异常场景且能降低测试时间成本的软件测试方法和***。

一种软件测试方法，所述方法包括：

获取第一配置文件，所述第一配置文件中设有插桩点和对应的用于产生测试场景的插桩代码；

根据所述第一配置文件，在被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件；

运行所述插桩后的被测软件，当所述插桩后的被测软件中的所述插桩点被触发时，执行与触发的所述插桩点对应的所述插桩代码。

一种软件测试***，所述***包括：

获取模块，用于获取第一配置文件，所述第一配置文件中设有插桩点和对应的用于产生测试场景的插桩代码；

代码***模块，用于根据所述第一配置文件，在被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件；

代码运行模块，用于运行所述插桩后的被测软件，当所述插桩后的被测软件中的所述插桩点被触发时，执行与触发的所述插桩点对应的所述插桩代码。

相对于传统的基于功能的黑盒测试方法和基于代码的白盒测试方法，本发明所提供的软件测试方法和***，由于能够在被测软件的插桩点处***对应的插桩代码，使得插桩后的被测软件在运行过程中，其中的插桩点被触发时能自动执行与插桩点对应的插桩代码，从而模拟出各种测试场景，不需要人工模拟场景或者手动修改数据或临时修改代码，因此既能模拟出各种异常场景又能降低测试时间成本。

附图说明

图1为一个实施例中软件测试方法的流程示意图；

图2A为一个实施例中软件测试方法的应用场景图；

图2B为另一个实施例中软件测试方法的应用场景图；

图3为一个实施例中软件测试***的结构框图；

图4为一个实施例中代码运行模块的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

除非上下文另有特定清楚的描述，本发明中的元件和组件，数量既可以单个的形式存在，也可以多个的形式存在，本发明并不对此进行限定。本发明中的步骤虽然用标号进行了排列，但并不用于限定步骤的先后次序，除非明确说明了步骤的次序或者某步骤的执行需要其他步骤作为基础，否则步骤的相对次序是可以调整的。可以理解，本文中所使用的术语“和/或”涉及且涵盖相关联的所列项目中的一者或一者以上的任何和所有可能的组合。

如图1所示，在一个实施例中，提供了一种软件测试方法，该方法包括：

步骤102，获取第一配置文件。

第一配置文件也可称为插桩规则文件，其中设有插桩点和对应的用于产生测试场景的插桩代码。所谓插桩点，是指要***插桩代码的代码点，可设为在调用***函数或自定义函数时或者执行某类操作（如创建对象new）时***预设的插桩代码。

依据AOP（Aspect Oriented Programming，面向切面编程，通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术）技术的不同，对于不同语言，可以采用不同的形式来实现第一配置文件。比如，对于Java语言，可使用AspectJ（基于Java平台的AOP工具）源代码文件或者编译后的jar包（JavaArchive，Java归档文件），或者执行时的xml（可扩展标记语言）规则文件来实现第一配置文件。对于c/c++语言，则可使用AspectC（基于C/C++语言的AOP工具）来描述第一配置文件。采用哪种文件实现第一配置文件，由对被测软件***插桩代码的时机（在被测软件编译阶段***还是在被测软件运行阶段***），以及被测软件的开发语言和平台决定。

第一配置文件实际上设置了可以对哪些函数或操作进行插桩以及对应的插桩代码，也就是插桩点和对应的插桩代码。插桩点包括***函数、自定义函数和指定操作的至少一种。例如，第一配置文件中可设置有***函数名和/或自定义函数名。以AspectJ源代码文件为例，其中记录的函数名有：

pointcut getNetworkType():call(int android.net.NetworkInfo.getType())；

pointcut getSubtype():call(int android.net.NetworkInfo.getSubType())；

pointcut getExtraInfo():call(String android.net.NetworkInfo.getExtraInfo())等。表示在调用这些函数时，需要产生对应的测试场景。

步骤104，根据第一配置文件，在被测软件的插桩点处***对应的插桩代码，生成插桩后的被测软件。

所谓插桩代码，是指用于产生各种测试场景的代码，可以在被测软件编译时或者运行时***到被测软件的插桩点处。这样，插桩后的被测软件在触发插桩点时就能够执行该插桩代码，从而得到各种测试场景。

步骤106，运行插桩后的被测软件，当插桩后的被测软件中的插桩点被触发时，执行与触发的插桩点对应的插桩代码。

插桩后的被测软件是指已在插桩点植入了对应的插桩代码的被测软件，它在运行过程中，当其中的插桩点被触发，比如调用指定的函数时，则执行与该触发的插桩点对应的插桩代码。

进一步的，插桩代码可设置为执行时去解析第二配置文件中与插桩点对应的行为程序，从而得到第二配置文件中指定的结果。

仍以第一配置文件为AspectJ源代码文件为例进行举例说明，对应于某一函数的插桩代码可为：

该插桩代码在执行时，会去解析第二配置文件，从第二配置文件中读取android.net.NetworkIfo.getExtraInfo行信息。

作为优选的，执行与触发的插桩点对应的插桩代码的步骤，包括：通过插桩代码读取第二配置文件，第二配置文件中设有插桩点和对应的行为程序；执行与触发的插桩点对应的行为程序，产生测试场景。

第二配置文件可为软件运行时的***配置文件，其中设有插桩点和对应的行为程序，该行为程序定义了对应插桩点应该返回的指定结果或应该执行的操作等。以Java语言为例，在第二配置文件中设定的对应某一插桩点的行为程序为：android.net.NetworkInfo.getExtraInfo=“3gnet”，表示凡是调用“ndroid.net.NetworkInfo.getExtraInfo”这一API函数，则返回结果“3gnet”。又如行为程序为：Thread.run=sleep(random(10))，表示线程执行前，随机挂起（sleep）几秒钟（如10秒以内）。

插桩代码在执行过程中，会去读取和解析指定的第二配置文件中的行为程序，然后执行该行为程序，从而产生各种预先设定的测试场景。比如，插桩代码执行时，从第二配置文件中读取ndroid.net.NetworkIfo.getExtraInfo行信息，得到对应的行为程序为“3gnet”，执行该行为程序，返回结果“3gnet”。

本发明实施例所提供的软件测试方法，可在被测软件编译阶段或者运行阶段***插桩代码。

请参考图2A所示，在被测软件的编译阶段***插桩代码。由插桩编译器获取被测软件以及读取第一配置文件，根据第一配置文件在被测软件中的插桩点处***插桩代码，从而生成插桩后的被测软件。插桩后的被测软件在运行阶段，当其中的插桩点被触发，则对应的插桩代码自动执行，该插桩代码会去读取第二配置文件，从而执行与触发的插桩点对应的行为程序，得到各种测试场景（比如，返回指定的结果、执行指定的操作等）。

以Java语言为例，被测软件可以是java classes（Java中的类），插桩编译器可以是ajc（AspectJ提供的编译器），第一配置文件可以是AspectJ源代码文件或jar包等。

请参考图2B所示，在被测软件的运行阶段***插桩代码。运行被测软件，由运行插桩器获取运行中的被测软件以及读取第一配置文件，根据第一配置文件在被测软件中的插桩点处***插桩代码，生成插桩后的被测软件。该插桩后的被测软件在运行过程中，如果其中的插桩点被触发，其对应的插桩代码自动执行，该插桩代码会去读取第二配置文件，从而执行与触发的插桩点对应的行为程序，得到各种测试场景。整个过程都在被测软件的运行阶段实现。

以Java语言为例，运行中的被测软件可以是java classes，运行插桩器可以是Java Agent（Java虚拟机用来修改应用的组件），第一配置文件可以是xml规则文件或jar包等。

应当说明的是，本发明实施例虽以Java语言进行举例说明，但可以理解的是，对于采用其它语言的被测软件，比如c/c++等，也可以采用本发明实施例所提供的软件测试方法进行测试，其区别仅仅在于所使用的文件类型和程序语言不同。

如图3所示，在一个实施例中，还提供了一种软件测试***，包括：

获取模块302，用于获取第一配置文件，该第一配置文件中设有插桩点和对应的用于产生测试场景的插桩代码。

代码***模块304，用于根据第一配置文件，在被测软件的插桩点处***对应的插桩代码，生成插桩后的被测软件。

代码运行模块306，用于运行插桩后的被测软件，当插桩后的被测软件中的插桩点被触发时，执行与触发的插桩点对应的插桩代码。

在一个实施例中，插桩点包括***函数、自定义函数和指定操作中的至少一种。

进一步的，在一个实施例中，如图4所示，代码运行模块306包括：

插桩代码执行模块316，用于通过插桩代码读取第二配置文件，该第二配置文件中设有插桩点和对应的行为程序。

程序执行模块326用于执行与触发的插桩点对应的行为程序，产生测试场景。

在一个实施例中，代码***模块304为插桩编译器，用于在被测软件的编译阶段，根据第一配置文件在被测软件的插桩点处***对应的插桩代码，生成插桩后的被测软件。

在另一个实施例中，代码***模块304为运行插桩器，用于在被测软件的运行阶段，根据第一配置文件在被测软件的插桩点处***对应的插桩代码，生成插桩后的被测软件。

上述软件测试方法和***，根据第一配置文件来对被测软件中的插桩点（如函数触发点）进行截获并***对应的插桩代码，从而改变了被测软件中的程序的运行行为（如修改函数的指定返回值、修改线程的执行时序等）。在插桩后的被测软件的运行过程中，当插桩点被触发就能运行对应的插桩代码，从而模拟出各种测试场景。比如：对于机器内存不足的场景，可通过第一配置文件设置对应new函数的插桩代码能够读取第二配置文件中对应的行为程序，该行为程序直接抛出out of memory异常（即内存不足异常）。***了该插桩代码的被测软件在运行过程中，当调用new函数时，不再继续该***函数的调用，而是直接抛出out of memory异常，从而模拟出机器内存不足的场景。对于其它测试场景都可以按照这种方式进行模拟，在此则不再一一列举。

由于采用该软件测试方法和***，节省了很多人工操作。比如，不需要像传统的黑盒测试方式那样，需要开启大量的程序将***的内存耗尽或者拷贝文件占本地磁盘空间占满。也不需要像传统的白盒测试方式那样，需要临时修改代码或者手动的修改程序运行时的数据等来模拟各种场景。因此，本发明实施例所提供的软件测试方法和***，能够节省大量的测试时间成本。除了能够模拟一些常用的测试场景外，对于一些涉及较多代码模块修改的特定场景，本发明通过第一配置文件和第二配置文件中设定的内容也容易实现这些特定场景。

并且，对于多线程的测试，传统的白盒测试方法当需要对单个线程设置断电时，则需要将整个进程挂起，影响了被测软件的正常运行。而本发明除了可以在编译阶段对被测软件植入插桩代码，还可以在被测软件的运行阶段植入插桩代码，不会影响被测软件的正常运行。此外，传统的白盒测试方法在修改程序运行是数据或者临时修改代码时都需要有源代码，在一些不能提供源代码的测试场合下则不能实现测试。而本发明由于是通过预先配置好的第一配置文件来对被测软件的插桩点进行截获，从而将插桩代码***被测软件中。因此，本发明不需要提供源代码就能够实现测试。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（Read-Only Memory，ROM）或随机存储记忆体（Random Access Memory，RAM）等。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种软件测试方法，所述方法包括：

获取第一配置文件，所述第一配置文件中设有插桩点和对应的用于产生测试场景的插桩代码；

根据所述第一配置文件，在被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件；

运行所述插桩后的被测软件，当所述插桩后的被测软件中的所述插桩点被触发时，执行与触发的所述插桩点对应的所述插桩代码。

2.根据权利要求1所述的方法，其特征在于，所述执行与触发的所述插桩点对应的所述插桩代码的步骤，包括：

通过所述插桩代码读取第二配置文件，所述第二配置文件中设有插桩点和对应的行为程序；

执行与所述触发的插桩点对应的行为程序，产生测试场景。

3.根据权利要求1所述的方法，其特征在于，所述根据第一配置文件，在被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件的步骤，包括：

在所述被测软件的编译阶段，由插桩编译器根据第一配置文件，在所述被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件。

4.根据权利要求1所述的方法，其特征在于，所述根据第一配置文件，在被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件的步骤，包括：

在所述被测软件的运行阶段，由运行插桩器根据第一配置文件，在所述被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述插桩点包括***函数、自定义函数和指定操作中的至少一种。

6.一种软件测试***，其特征在于，所述***包括：

获取模块，用于获取第一配置文件，所述第一配置文件中设有插桩点和对应的用于产生测试场景的插桩代码；

代码***模块，用于根据所述第一配置文件，在被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件；

代码运行模块，用于运行所述插桩后的被测软件，当所述插桩后的被测软件中的所述插桩点被触发时，执行与触发的所述插桩点对应的所述插桩代码。

7.根据权利要求6所述的***，其特征在于，所述代码运行模块包括：

插桩代码执行模块，用于通过所述插桩代码读取第二配置文件，所述第二配置文件中设有插桩点和对应的行为程序；

程序执行模块，用于执行与所述触发的插桩点对应的行为程序，产生测试场景。

8.根据权利要求6所述的***，其特征在于，所述代码***模块为插桩编译器，所述插桩编译器用于在所述被测软件的编译阶段，根据第一配置文件，在所述被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件。

9.根据权利要求6所述的***，其特征在于，所述代码***模块为运行插桩器，所述运行插桩器用于在所述被测软件的运行阶段，根据第一配置文件，在所述被测软件的插桩点处***对应的所述插桩代码，生成插桩后的被测软件。

10.根据权利要求6至9任一项所述的***，其特征在于，所述插桩点包括***函数、自定义函数和指定操作的至少一种。