专利名称：测试处理装置和测试处理方法
技术领域：
本发明涉及软件测试领域，具体而言，涉及ー种测试处理装置和一种测试处理方法。
背景技术：
OSGi (Open Service Gateway Initiative)是面向 Java 的动态模型系统，它为模块化应用的开发定义了ー个基础架构，使得应用程序可以实现定义精炼的、可重用的和可协作的标准组件，井能够灵活地、动态地组装和部署到应用系统中。由于这些特性，OSGi已经得到了业界的广泛应用，成为软件集成和企业开发的首选架构之一。然而由于OSGi环境下采用不同的类加载器来加载程序代码来实现组件的松散耦 合和动态部署，这种机制与传统的应用程序完全不同，使得传统的应用程序开发中所使用的测试方法并不能简单地移植到OSGi环境中。这种矛盾使得目前基于OSGi的软件系统开发存在ー些不同程度的常见问题a、无法进行自动化测试而只能采用效率低下的手工测试，在软件系统发生变更后进行的回归测试耗时费力，测试覆盖率低；b、测试用例代码紧密依赖于测试的目标构件而无法分开部署；c、测试用例只能针对ー些不依赖与系统上下文环境运行的构件进行测试，导致那些依赖于业务上下文环境的构件无法建立自动化测试用例。综上所述，在OSGi环境中对软件构件进行测试面临的主要问题是测试用例运行的上下文环境与测试目标构件的真实环境的差异问题。对于此，现有常见的做法是为每个测试用例建立独立的测试上下文来加载并执行测试用例，如图IA所示。这种方式下执行测试用例的上下文环境是由测试框架本身定义的，并不同于被测试构件在软件系统上执行的真实环境(如图IB所示)，而且每个测试用例的上下文是隔离的，这就要求被测试的构件不能依赖于其所在的软件系统的执行环境。因此这种方法的适用范围比较受限，通常软件系统的功能构件大多都在事务、安全、数据访问、日志等功能方面需要依赖于系统的上下文环境，所以上述测试框架无法支持对这类构件的测试。故需要一种新的技术方案，可以为被测试用例的执行提供与真实环境一致的上下文，避免由于执行环境的不同而导致的测试结果的差异，同时，实现测试用例和测试对象之间的松耦合，测试用例可以批量的方式被执行，进而提高软件系统的测试效率，提升软件系统的开发质量。
发明内容
本发明所要解决的技术问题在于，提供一种新的技术方案，可以为被测试用例的执行提供与真实环境一致的上下文，避免由于执行环境的不同而导致的测试结果的差异，同时，实现测试用例和测试对象之间的松耦合，测试用例可以批量的方式被执行，进而提高软件系统的测试效率，提升软件系统的开发质量。
有鉴于此，本发明提供了ー种测试处理装置，包括测试用例获取模块，获取系统中的测试用例；上下文參数设置模块，将测试目标构件所需的上下文參数设置到所述测试用例的线程上下文中；测试用例执行模块，执行所述测试用例，以测试所述目标构件。在该技术方案中，通过所述上下文參数设置模块，将测试目标构件所需的上下文參数设置到所述测试用例的线程上下文中，从而为被测试用例提供了与真实环境一致的上下文，进而能够避免由于执行环境的不同而导致的测试结果的差异，提高软件测试的质量。在上述技术方案中，优选地，还包括规范设置模块，设置所述测试用例的数据结构、部署方式和/或加载方式；测试用例实现模块，按所述数据结构、所述部署方式和/或所述加载方式在所述系统中实现所述测试用例，所述测试用例获取模块按所述部署方式，从所述系统中获取所述测试用例，和/或所述测试用例执行模块根据所述数据结构，创建所述测试用例的编程对象实例，以测试所述目标构件，和/或按所述加载方式，加载所述测试 用例，以执行所述测试用例来测试所述目标构件。在本技术方案中，测试用例的数据结构，定义了展现或指明一个测试用例时应包含的信息，例如编号、名称、版本、作者等；测试用例的部署和加载方式，定义了测试用例的存在形式，将据此采用对应的方式来查找和加载测试用例。在上述技术方案中，优选地，在所述系统为动态模块系统时，所述测试用例获取模块从所述系统的上下文获取所有启动的模块，并从所述启动的模块取得包含所述测试用例的模块。在该技术方案中，可以根据具体的系统环境来取得测试用例，尤其适用于OSGi(Open Service Gateway Initiative)实现的软件系统,例如，在OSGi环境下,可以从启动的bundle中过滤出包含测试用例的bundle。在上述技术方案中，优选地，还包括模块实现模块，在所述系统中，以模块形式实现所述测试用例和所述目标构件。在该技术方案中，需要在系统中环境中，以模块的形式预先将目标构件和测试用例部署好，有利于减少目标构件与测试用例之间的耦合性，例如，在OSGi环境下，目标构件和测试用例都可以bundle形式实现。在上述技术方案中，优选地，所述上下文參数包括登录用户、数据源、会话标识和/或事务标识。在该技术方案中，本领域技术人员应当理解，上述内容仅为上下文參数的示例，并不对其进行限制，上下文參数可以包含更多类型的内容。本发明还提供了ー种测试处理方法，包括步骤202，获取系统中的测试用例；步骤204，将测试目标构件所需的上下文參数设置到所述测试用例的线程上下文中；步骤206，执行所述测试用例，以测试所述目标构件。在该技术方案中，将测试目标构件所需的上下文參数设置到所述测试用例的线程上下文中，从而为被测试用例提供了与真实环境一致的上下文，进而能够避免由于执行环境的不同而导致的测试结果的差异，提高软件测试的质量。在上述技术方案中，优选地，在所述步骤202之前，还包括设置所述测试用例的数据结构、部署方式和/或加载方式，并按所述数据结构、所述部署方式和/或所述加载方式在所述系统中实现所述测试用例；所述步骤202包括按所述部署方式，从所述系统中获取所述测试用例；和/或所述步骤206包括根据所述数据结构，创建所述测试用例的编程对象实例，以测试所述目标构件，和/或按所述加载方式，加载所述测试用例，以执行所述测试用例来测试所述目标构件。在本技术方案中，测试用例的数据结构，定义了展现或指明一个测试用例时应包含的信息，例如编号、名称、版本、作者等；测试用例的部署和加载方式，定义了测试用例的存在形式，将据此采用对应的方式来查找和加载测试用例。在上述技术方案中，优选地，所述步骤202包括在所述系统为动态模块系统时，从所述系统的上下文获取所有启动的模块，并从所述启动的模块取得包含所述测试用例的模块。
在该技术方案中，可以根据具体的系统环境来取得测试用例，尤其适用于OSGi(Open Service Gateway Initiative)实现的软件系统,例如，在OSGi环境下,可以从启动的bundle中过滤出包含测试用例的bundle。在上述技术方案中，优选地，在所述步骤202之前，还包括在所述系统中，以模块形式实现所述测试用例和所述目标构件。在该技术方案中，需要在系统中环境中，以模块的形式预先将目标构件和测试用例部署好，有利于减少目标构件与测试用例之间的耦合性，例如，在OSGi环境下，目标构件和测试用例都可以bundle形式实现。在上述技术方案中，优选地，所述上下文參数包括登录用户、数据源、会话标识和/或事务标识。在该技术方案中，本领域技术人员应当理解，上述内容仅为上下文參数的示例，并不对其进行限制，上下文參数可以包含更多类型的内容。通过以上技术方案，可以为被测试用例的执行提供与真实环境一致的上下文，避免由于执行环境的不同而导致的测试结果的差异，同时，实现测试用例和测试对象之间的松耦合，测试用例可以批量的方式被执行，进而提高软件系统的测试效率，提升软件系统的开发质量。
图IA示出了相关技术中的OSGi环境下一般的构件测试方法的运行环境示意图；图IB示出了相关技术中的软件系统构件实际的运行环境示意图；图2示出了根据本发明的实施例的测试处理方法的流程图；图3示出了根据本发明的实施例的测试处理装置的框图；图4示出了根据本发明的实施例的测试处理装置的结构示意图；图5示出了根据本发明的实施例的测试处理装置的模块示意图；图6示出了根据本发明的实施例的测试处理装置的工作流程图。
具体实施例方式为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式
对本发明进行进一歩的详细描述。在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明并不限于下面公开的具体实施例的限制。图2示出了根据本发明的实施例的测试处理方法的流程图。如图2所示，本发明还提供了ー种测试处理方法，包括步骤202，获取系统中的测试用例；步骤204，将测试目标构件所需的上下文參数设置到所述测试用例的线程上下文中；步骤206，执行所述测试用例，以测试所述目标构件。在该技术方案中，将测试目标构件所需的上下文參数设置到所述测试用例的线程上下文中，从而为被测试用例提供了与真实环境一致的上下文，进而能够避免由于执行环境的不同而导致的测试结果的差异，提高软件测试的质量。
在上述技术方案中，在所述步骤202之前，还包括设置所述测试用例的数据结构、部署方式和/或加载方式，并按所述数据结构、所述部署方式和/或所述加载方式在所述系统中实现所述测试用例；所述步骤202包括按所述部署方式，从所述系统中获取所述测试用例；和/或所述步骤206包括根据所述数据结构，创建所述测试用例的编程对象实例，以测试所述目标构件，和/或按所述加载方式，加载所述测试用例，以执行所述测试用例来测试所述目标构件。在本技术方案中，测试用例的数据结构，定义了展现或指明一个测试用例时应包含的信息，例如编号、名称、版本、作者等；测试用例的部署和加载方式，定义了测试用例的存在形式，将据此采用对应的方式来查找和加载测试用例。在上述技术方案中，所述步骤202包括在所述系统为动态t旲块系统时，从所述系统的上下文获取所有启动的模块，并从所述启动的模块取得包含所述测试用例的模块。在该技术方案中，可以根据具体的系统环境来取得测试用例，尤其适用于OSGi(Open Service Gateway Initiative)实现的软件系统,例如，在OSGi环境下,可以从启动的bundle中过滤出包含测试用例的bundle。在上述技术方案中，在所述步骤202之前，还包括在所述系统中，以模块形式实现所述测试用例和所述目标构件。在该技术方案中，需要在系统中环境中，以模块的形式预先将目标构件和测试用例部署好，有利于减少目标构件与测试用例之间的耦合性，例如，在OSGi环境下，目标构件和测试用例都可以bundle形式实现。在上述技术方案中，所述上下文參数包括登录用户、数据源、会话标识和/或事务标识。在该技术方案中，本领域技术人员应当理解，上述内容仅为上下文參数的示例，并不对其进行限制，上下文參数可以包含更多类型的内容图3示出了根据本发明的实施例的测试处理装置的框图。如图3所示，本发明提供了ー种测试处理装置300，包括测试用例获取模块302，获取系统中的测试用例；上下文參数设置模块304，将测试目标构件所需的上下文參数设置到所述测试用例的线程上下文中；测试用例执行模块306，执行所述测试用例，以测试所述目标构件。在该技术方案中，通过所述上下文參数设置模块304，将测试目标构件所需的上下文參数设置到所述测试用例的线程上下文中，从而为被测试用例提供了与真实环境一致的上下文，进而能够避免由于执行环境的不同而导致的测试结果的差异，提高软件测试的质量。在上述技术方案中，还包括规范设置模块308，设置所述测试用例的数据结构、部署方式和/或加载方式；测试用例实现模块310，按所述数据结构、所述部署方式和/或所述加载方式在所述系统中实现所述测试用例，所述测试用例获取模块302按所述部署方式，从所述系统中获取所述测试用例，和/或所述测试用例执行模块306根据所述数据结构，创建所述测试用例的编程对象实例，以测试所述目标构件，和/或按所述加载方式，カロ载所述测试用例，以执行所述测试用例来测试所述目标构件。在本技术方案中，测试用例的数据结构，定义了展现或指明一个测试用例时应包含的信息，例如编号、名称、版本、作者等；测试用例的部署和加载方式，定义了测试用例的存在形式，将据此采用对应的方式来查找和加载测试用例。在上述技术方案中，在所述系统为动态模块系统时，所述测试用例获取模块302从所述系统的上下文获取所有启动的模块，并从所述启动的模块取得包含所述测试用例的 模块。在该技术方案中，可以根据具体的系统环境来取得测试用例，尤其适用于OSGi(Open Service Gateway Initiative)实现的软件系统,例如，在OSGi环境下,可以从启动的bundle中过滤出包含测试用例的bundle。在上述技术方案中，还包括模块实现模块312，在所述系统中，以模块形式实现所述测试用例和所述目标构件。在该技术方案中，需要在系统中环境中，以模块的形式预先将目标构件和测试用例部署好，有利于减少目标构件与测试用例之间的耦合性，例如，在OSGi环境下，目标构件和测试用例都可以bundle形式实现。在上述技术方案中，所述上下文參数包括登录用户、数据源、会话标识和/或事务标识。在该技术方案中，本领域技术人员应当理解，上述内容仅为上下文參数的示例，并不对其进行限制，上下文參数可以包含更多类型的内容。以下结合实施例，详细说明本发明的技术方案。本实施例中提出的测试处理装置设计为与被测试的软件系统是在同一环境中运行，这样能够为测试用例的执行提供与真实环境一致的上下文，解决背景技术中所提到的问题，相对于现有技术方案，本实施例的技术方案的测试处理装置的示意图可以如图4所示，测试用例可结合实际的实际运行环境来进行目标构件的测试。本实施例提出的测试处理装置可以如图5所示，由测试管理模块502、测试接ロ模块504、测试用例模块506三部分组成I、测试接ロ模块502 (相当于前述的规范设置模块)此部分定义了测试用例模块506需要遵循的接ロ规范。测试管理模块504和测试用例模块506都依赖于此模块。2、测试管理模块504 (相当于前述的上下文參数设置模块和测试用例获取模块)此部分功能是从运行的OSGi环境中捜索、加载和运行已经部署的测试用例，为测试用例设置代码执行的线程上下文，并收集和输出测试結果。3、测试用例模块506 (相当于前述的模块实现模块)此部分定义了针对特定目标进行测试的测试用例。此模块依赖但独立于被测试的目标构件所在的模块，是ー个可独立部署的单位，可按需部署。测试管理模块504、测试接ロ模块502、测试用例模块506在实现的形态上与测试目标所在的模块在物理形态上都是相同的，都被实现为OSGi的bundle，以相同形式部署到OSGi运行环境中。测试管理模块504、测试接ロ模块502、测试用例模块506之间没有直接依赖，它们之间是依照OSGi运行环境提供的松耦合的方式形成依赖。本发明的装置包括I个测试管理模块504、1个测试接ロ模块502和O、个测试用例模块506。测试用例模块506是可以根据需要进行部署的，测试管理模块504以动态的方式从OSGi上下文中收集测试用例模块506中定义的所有测试用例。 一、测试接ロ模块502 此模块是测试管理模块504和测试用例模块506的公共模块，它的核心是定义测试用例和测试管理模块504都共同遵循的接ロ规范。测试用例遵循该接ロ规范来实现，测试管理模块504也遵循同样的接ロ规范来加载和运行测试用例。测试接ロ模块502是ー个逻辑上抽象的存在，它定义的接ロ规范的实际形式可以表现为编程语言上的接ロ或者类，也可以表现为ー份需要共同遵守的XML文档，或者其它格式的文档。因而，在物理上，测试接ロ模块502可以是ー个包含了构成接ロ规范的编程语言的接ロ、类、XML文档等数据文件的ー个独立的OSGi Bundle，也可以将这些数据文件与测试管理模块一起实现在同一个OSGi Bundle中。接ロ规范定义的要素包括( I)测试用例的数据结构定义了展现或指明一个测试用例时应包含的信息，例如编号、名称、版本、作者等;(2)测试用例的部署和加载方式定义了测试用例的存在形式，测试管理模块504将据此采用对应的方式来查找和加载测试用例。例如，以下是一段关于测试用例接ロ规范的描述测试用例要求都要包含名称、版本、作者、描述等内容，需要实现接ロ类型com.my. test. ITestCase ;测试用例中的测试方法以小写“test”开头，没有返回值和參数；测试断言通过类型com. my. test. Test的一系列静态方法assertEquals判断是否通过测试；测试用例所在的Bundle中以XML文件testbundle. xml配置了测试Bundle中定义的所有的测试用例的ClassName, testbundle. xml文件位于META-INF目录中。同样地,在接ロ模块中定义出接ロ类型com. my. test. ITestCase和Test如下
package com.mv.test; public interface ITestCase {
String getNamei);
String getVersion();
String getAuthoi'O;
String getDescriptionO;
}
package com.my.test;public class Test {public static void assertEquais(int expected,int actual) { //判断expected和actual的值是否相等; if (expected != actual) {
throw new TestException("expected value :" + expected + ", butactual :" + actual +
}
}
public static void assertEquaIsiString expected,String actual){
//判断expected和actual的值是否相等; if (! ex pec ted. equa i s( actual))(
throw new TestException("expected value + expected + ", butactual :" 一 actual + "!")；
}
}
//……
}ニ、测试管理模块504的实现测试管理模块504是本发明的核心模块，实现该模块的关键在于将其实现为OSGiBundle，与测试目标同样地部署于目标系统的OSGi环境中，与测试目标在相同的上下文中执行。这样，在执行测试用例之前，可以将目标系统的上下文參数设置到执行用例的线程上下文中，以此保证了测试用例对测试目标构件的测试调用得以正确进行。一次测试任务的执行主要由以下的几个的操作构成I、收集测试用例从当前的系统环境中查找和收集部署的测试用例是执行测试任务的前提，具体过程要遵循测试接ロ模块定义的接ロ规范来进行实现。
第一歩，从OSGi Bundle上下文获取当前OSGi环境下的所有启动的Bundle。根据OSGi环境提供的BundleContext对象提供了相应的编程方法(例如getBundles())即可获得所有Bundle。第二步，按照测试接ロ规范的定义过滤出包含了测试用例的Bundle。由于定义测试用例的Bundle与测试目标构件的Bundle都是部署在一起的，因此需要从Bundle上下文获得的Bundle列表过滤出包含测试用例的Bundle，过滤的方法遵循测试接ロ模块定义的接ロ规范。以之前所举接ロ规范示例为例，相应地，在此可以按照Bundle中的META-INF目录中是否包含了 testbundle. xml配置文件并且文件中配置了至少ー个测试用例作为过滤条件，对符合条件的Bundle执行后续的处理。第三步，从Bundle中查找获得测试用例的列表；这ー步是需要遵循测试接ロ模块定义的接ロ规范来收集测试用例的信息。以之前所举接ロ规范示例为例，相应地，解析Bundle中META-INF目录下的testbundle. xml配置文件获取在其中配置的测试用例的类型、名称、參数等，这些信息将在执行测试用例时用于创建测试用例的编程对象实例。
2、初始化用例执行上下文这ー过程是将测试目标构件所需要的上下文參数设置到测试用例的线程上下文中，使得测试用例对目标构件的测试调用得以有效运行。上下文的初始化方式与实际的软件系统相关，一般来说包括但不限于当前登录用户、当前数据源、会话ID，事务ID等系统环境參数。3、执行测试用例输出测试结果根据之前操作中收集到的测试用例信息，加载测试用例，执行测试用例中的测试方法，记录并输出这些测试方法的执行結果。对测试用例的加载以及测试方法的执行需要根据测试接ロ模块定义的接ロ规范来实现。以之前所举接ロ规范示例为例，相应地，创建那些实现了 com. my. test. ITestCase接ロ的类型的实例,逐个执行其中以test开头的方法，对于执行完成没有抛出异常的test方法的测试结果输出为通过测试，抛出异常的输出为测试失败，并输出异常信息。三、测试用例模块506:测试用例模块506是用于定义测试用例的，其实现形式为OSGiBundle，依赖于测试接ロ模块502和测试目标构件，与测试目标构件的Bundle —同部署，其对测试目标构件的依赖通过OSGi提供的Service、Package Import等方式引入,对测试目标构件没有入侵性。在测试用例模块506中，测试用例是遵循了测试接ロ模块502定义的接ロ规范并实现针对特定构件进行代码执行结果验证的代码实现类，其具体的实现得视其测试的目标对象的功能而定。以测试接ロ模块502中所举的接ロ规范为例，一个测试用例可以实现为以下的形式package com.my.testcase;
import com.my.test.ITestCase;import com.my.test.Test;
public class CustomerOrderTestCase implements ITestCase {
产*
*测试分发客户订单;
*/
public void testDistributeOrders() { int expectedValue = getExepectedValue(); int aclualVaiue = getTestResuit();
Test.assert.Equais(expecled Value, actual Value);*测试上传客户订单；
*1
public volet testUploadOrdersi){
int ex pec ted Value = jietExepectedVaiue(); int actualValue = getTestResult();
Test.assertEquais(expectedValue, actualValue);
}
(i Override public String getName() {
return ”客户订单测试用例,';
}
(i Override
public Siring getVersion() { return "2.1
}
(i Override
public String getAuthor() { return "john
}
Override
public String tietDescnption() {
return ”测试客户订单的分发和上传”;
}
}对应地在Bundle的META-INF目录中的testbundle. xml的实现示例如下
< xral version=" 1.0" encoding="UTF-8" >
くtest〉
<testcase class="com.my.testcase.CustomerOrderTestCase"/><testcase Class=inCOin.my.tesi:case.OtherTestCase"/>
</test>以上是测试用例实现的ー个示例，该示例遵循接ロ规范实现了接ロ ITestCase，定义了两个测试方法 testDistributeOrders、testUploadOrders。图6示出本发明的实施例的测试处理装置的工作流程。如图6所示，步骤602，从OSGi上下文收集所有Bundle信息；
步骤604，逐个处理收集到的Bundle ；步骤606，判断该Bundle是否是有效测试用例模块，在是时进入步骤608，在否时进入步骤612 ；步骤608，加载测试用例模块中定义的测试用例；步骤610，将测试用例加入执行队列；步骤612，判断是否有未处理的Bundle，有则返回步骤604，没有则进入步骤614 ；步骤614，初始化测试用例执行上下文；步骤616，执行测试用例输出测试結果。通过以上技术方案，可以实现ー种测试处理装置和一种处理方法，提高了软件系统的测试效率，提升了软件系统的开发质量。以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种测试处理装置，其特征在于，包括 测试用例获取模块，获取系统中的测试用例； 上下文参数设置模块，将测试目标构件所需的上下文参数设置到所述测试用例的线程上下文中； 测试用例执行模块，执行所述测试用例，以测试所述目标构件。
2.根据权利要求I所述的测试处理装置，其特征在于，还包括 规范设置模块，设置所述测试用例的数据结构、部署方式和/或加载方式； 测试用例实现模块，按所述数据结构、所述部署方式和/或所述加载方式在所述系统中实现所述测试用例，所述测试用例获取模块按所述部署方式，从所述系统中获取所述测试用例，和/或所述测试用例执行模块根据所述数据结构，创建所述测试用例的编程对象实例，以测试所述目标构件，和/或按所述加载方式，加载所述测试用例，以执行所述测试用例来测试所述目标构件。
3.根据权利要求I所述的测试处理装置，其特征在于，在所述系统为动态模块系统时，所述测试用例获取模块从所述系统的上下文获取所有启动的模块，并从所述启动的模块取得包含所述测试用例的模块。
4.根据权利要求3所述的测试处理装置，其特征在于，还包括 模块实现模块，在所述系统中，以模块形式实现所述测试用例和所述目标构件。
5.根据权利要求I至4中任一项所述的测试处理装置，其特征在于，所述上下文参数包括登录用户、数据源、会话标识和/或事务标识。
6.—种测试处理方法,其特征在于,包括 步骤202，获取系统中的测试用例； 步骤204，将测试目标构件所需的上下文参数设置到所述测试用例的线程上下文中； 步骤206，执行所述测试用例，以测试所述目标构件。
7.根据权利要求6所述的测试处理方法，其特征在于，在所述步骤202之前，还包括设置所述测试用例的数据结构、部署方式和/或加载方式，并按所述数据结构、所述部署方式和/或所述加载方式在所述系统中实现所述测试用例； 所述步骤202包括按所述部署方式，从所述系统中获取所述测试用例；和/或 所述步骤206包括根据所述数据结构，创建所述测试用例的编程对象实例，以测试所述目标构件，和/或 按所述加载方式，加载所述测试用例，以执行所述测试用例来测试所述目标构件。
8.根据权利要求6所述的测试处理方法，其特征在于，所述步骤202包括 在所述系统为动态模块系统时，从所述系统的上下文获取所有启动的模块，并从所述启动的模块取得包含所述测试用例的模块。
9.根据权利要求8所述的测试处理方法，其特征在于，在所述步骤202之前，还包括 在所述系统中，以模块形式实现所述测试用例和所述目标构件。
10.根据权利要求6至9中任一项所述的测试处理方法，其特征在于，所述上下文参数包括登录用户、数据源、会话标识和/或事务标识。
全文摘要
本发明提供了一种测试处理装置，包括测试用例获取模块，获取系统中的测试用例；上下文参数设置模块，将测试目标构件所需的上下文参数设置到所述测试用例的线程上下文中；测试用例执行模块，执行所述测试用例，以测试所述目标构件。相应地，本发明还提供了一种测试处理方法。通过本发明的技术方案，针对基于OSGi(Open Service Gateway Initiative)实现的软件系统，可以为被测试用例的执行提供与真实环境一致的上下文，避免由于执行环境的不同而导致的测试结果的差异，同时，实现测试用例和测试对象之间的松耦合，测试用例可以批量的方式被执行，进而提高软件系统的测试效率，提升软件系统的开发质量。
文档编号G06F11/36GK102819488SQ20121022613
公开日2012年12月12日 申请日期2012年6月29日 优先权日2012年6月29日
发明者黄海泉 申请人:用友软件股份有限公司