发明内容
本申请提供了一种测试中的断言处理方法、装置、设备及存储介质,能够解决现有技术中测试断言的使用方式不统一,以及非退出断言需要额外的异常处理函数的问题。
第一方面,本申请提供一种测试中的断言处理方法,包括:
获取测试框架,在所述测试框架中设置至少两个断言,所述至少两个断言包括至少一个静态断言和至少一个动态断言,所述测试框架为基于类的单元测试;
将至少一个静态断言和至少一个动态断言划分到一个测试类;
将每个测试类中的断言的使用方式设置为一致,并将所述多个测试类封装至待测试的应用中;
在编译所述应用或运行所述应用时,执行所述测试框架;
在执行所述测试框架过程中,分别调用所述测试类中的静态断言或动态断言对所述应用进行验证,并监听各测试类中的断言的验证状态信息;
当监听到所述测试类中的静态断言失败时,生成第一断言信息;当监听到所述测试类中的动态断言失败时,生成第二断言信息;执行完所述测试框架后,生成测试报告,并将所述第一断言信息和所述第二描述信息统计到本次测试的测试报告中;所述第一断言信息包括出错信息,所述出错信息包括错误类型和错误位置,所述第二断言信息包括诊断信息和运行逻辑的异常断言点。
一种可能的设计中,在每个测试类中,存在至少一条静态断言成功的描述信息,所述第一断言信息是指每条断言成功的静态断言的描述信息;所述测试报告包括测试类中每条断言成功的静态断言的断言信息、以及每条断言成功的动态断言的断言信息。
一种可能的设计中,所述使用方式包括:被调用次数、断言某方法被调用过、测试通过用例和测试失败用例;
所述测试类包括:所有测试框架测试类的超类、对要运行的测试进行分组的类、制定单个测试方法、用于在测试框架中运行测试的类以及运行测试套件的结果。
一种可能的设计中,所述方法还包括:
生成多个测试用例,所述测试用例是指将软件测试的行为转化成可管理的模式的一组条件或变量,所述测试用例用于确定应用软件或软件系统是否正确工作;
分别将每个测试用例覆盖部分或全部未被覆盖过的测试类,直至所有测试类均被测试用例覆盖。
一种可能的设计中,所述监听各测试类中的断言的验证状态信息,包括:
在断言的各测试类中分别引入hook程序;
通过所述hook程序监听各测试类中变量或条件,以监听测试流程中的断言状态;
当所述hook程序监听到测试类中的变量或条件变化时,获取变量或条件发生变化的所述验证状态信息;
所述方法还包括:
当监听到验证状态信息为非退出断言状态时,不中断所述测试脚本的运行,直到生成所有验证结果;其中,所述非退出断言是指对测试用例中的测试参数使用断言时,退出程序不是因所述测试参数异常而退出程序。
一种可能的设计中,所述执行所述测试框架之前,所述方法还包括:
生成配置文件,所述配置文件指示自动化测试运行的测试环境以及需要进行的测试场景映射关系;所述配置文件包括断言的起始位置、执行的断言操作和执行断言操作得到的期望值,所述断言的起始位置用于判定断言操作在所述应用的文件的起始执行位置,所述期望值用于判定测试执行结果是否符合测试的要求。
解析所述配置文件中的测试场景,获取各测试场景中各测试案例的测试规则、规则参数、测试数据、数据嵌入点、规则校验点及预期结果;其中,所述测试规则是根据参数化规则编制以用于多个测试场景或多个测试案例;
以测试数据为驱动,判断数据嵌入点是否符合测试数据所定义的注入时点,若符合,则将测试数据注入测试对象;
判断规则校验点是否符合测试案例所定义的测试结果校验时点,若符合,则将测试案例的规则参数与测试规则拼装,并获取测试案例的具体规则内容,在已注入测试数据的测试对象中执行具体规则内容,得到实际运行结果;
分别针对各测试案例的实际运行结果和预期结果进行比较,生成校验结果。
一种可能的设计中,所述执行所述测试框架之后,所述生成第一断言信息之前,所述方法还包括:
运行所述目标单元测试,并得到与所述目标单元测试分别对应的测试结果,所述测试结果中包含测试成功结果以及测试失败结果;
在所有测试结果中,统计为所述测试失败结果的目标单元测试的失败总数量;
在所述目标单元测试中查找与目标源代码语句相关联的多个目标单元测试,作为多个关联目标单元测试;
在所有关联目标单元测试分别对应的测试结果中,统计为所述测试失败结果的关联目标单元测试的失败测试数目,并统计为所述测试成功结果的关联目标单元测试的成功测试数目;
根据预设的可疑度函数、所述失败总数量、所述第一数量以及所述第二数量,计算与所述目标单元测试相关联的所述目标源代码语句的出错率。
第二方面,本申请提供一种用于处理测试中断言的装置,具有实现对应于上述第一方面提供的一种测试中的断言处理方法的功能。所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块,所述模块可以是软件和/或硬件。
一种可能的设计中,所述装置包括:
输入输出模块,用于获取测试框架,在所述测试框架中设置至少两个断言,所述至少两个断言包括至少一个静态断言和至少一个动态断言,所述测试框架为基于类的单元测试;
处理模块,用于将至少一个静态断言和至少一个动态断言划分到一个测试类;
所述处理模块还用于将每个测试类中的断言的使用方式设置为一致,并将所述多个测试类封装至待测试的应用中;在编译所述应用或运行所述应用时,执行所述测试框架;在执行所述测试框架过程中,分别调用所述测试类中的静态断言或动态断言对所述应用进行验证;
监听模块,用于监听各测试类中的断言的验证状态信息;
所述处理模块还用于当所述监听模块监听到所述测试类中的静态断言失败时,生成第一断言信息;当所述监听模块监听到所述测试类中的动态断言失败时,生成第二断言信息;执行完所述测试框架后,生成测试报告,并将所述第一断言信息和所述第二描述信息统计到所述测试报告中;所述第一断言信息包括出错信息,所述出错信息包括错误类型和错误位置,所述第二断言信息包括诊断信息和运行逻辑的异常断言点。
一种可能的设计中,在每个测试类中,存在至少一条静态断言成功的描述信息,所述第一断言信息是指每条断言成功的静态断言的描述信息;所述测试报告包括测试类中每条断言成功的静态断言的断言信息、以及每条断言成功的动态断言的断言信息。
一种可能的设计中,所述使用方式包括:被调用次数、断言某方法被调用过、测试通过用例和测试失败用例;
所述测试类包括:所有测试框架测试类的超类、对要运行的测试进行分组的类、制定单个测试方法、用于在测试框架中运行测试的类以及运行测试套件的结果。
一种可能的设计中,所述处理模块还用于:
生成多个测试用例,所述测试用例是指将软件测试的行为转化成可管理的模式的一组条件或变量,所述测试用例用于确定应用软件或软件系统是否正确工作;
分别将每个测试用例覆盖部分或全部未被覆盖过的测试类,直至所有测试类均被测试用例覆盖。
一种可能的设计中,所述监听模块具体用于:
在断言的各测试类中分别引入hook程序;
通过所述hook程序监听各测试类中变量或条件,以监听测试流程中的断言状态;
当所述hook程序监听到测试类中的变量或条件变化时,获取变量或条件发生变化的所述验证状态信息;
所述处理模块还用于:
当所述监听模块监听到验证状态信息为非退出断言状态时,不中断所述测试脚本的运行,直到生成所有验证结果;其中,所述非退出断言是指对测试用例中的测试参数使用断言时,退出程序不是因所述测试参数异常而退出程序。
一种可能的设计中,所述处理模块执行所述测试框架之前,还用于:
生成配置文件,所述配置文件指示自动化测试运行的测试环境以及需要进行的测试场景映射关系;所述配置文件包括断言的起始位置、执行的断言操作和执行断言操作得到的期望值,所述断言的起始位置用于判定断言操作在所述应用的文件的起始执行位置,所述期望值用于判定测试执行结果是否符合测试的要求。
解析所述配置文件中的测试场景,获取各测试场景中各测试案例的测试规则、规则参数、测试数据、数据嵌入点、规则校验点及预期结果;其中,所述测试规则是根据参数化规则编制以用于多个测试场景或多个测试案例;
以测试数据为驱动,判断数据嵌入点是否符合测试数据所定义的注入时点,若符合,则将测试数据注入测试对象;
判断规则校验点是否符合测试案例所定义的测试结果校验时点,若符合,则将测试案例的规则参数与测试规则拼装,并获取测试案例的具体规则内容,在已注入测试数据的测试对象中执行具体规则内容,得到实际运行结果;
分别针对各测试案例的实际运行结果和预期结果进行比较,生成校验结果。
一种可能的设计中,所述处理模块执行所述测试框架之后,生成第一断言信息之前,还用于:
运行所述目标单元测试,并得到与所述目标单元测试分别对应的测试结果,所述测试结果中包含测试成功结果以及测试失败结果;
在所有测试结果中,统计为所述测试失败结果的目标单元测试的失败总数量;
在所述目标单元测试中查找与目标源代码语句相关联的多个目标单元测试,作为多个关联目标单元测试;
在所有关联目标单元测试分别对应的测试结果中,统计为所述测试失败结果的关联目标单元测试的失败测试数目,并统计为所述测试成功结果的关联目标单元测试的成功测试数目;
根据预设的可疑度函数、所述失败总数量、所述第一数量以及所述第二数量,计算与所述目标单元测试相关联的所述目标源代码语句的出错率。
本申请又一方面提供了一种计算机设备,其包括至少一个连接的处理器、存储器、监控器和输入输出单元,其中,所述存储器用于存储程序代码,所述处理器用于调用所述存储器中的程序代码来执行上述第一方面所述的方法。
本申请又一方面提供了一种计算机存储介质,其包括指令,当其在计算机上运行时,使得计算机执行上述第一方面所述的方法。
相较于现有技术,本申请提供的方案中,通过将静态断言和动态断言统一到一个测试类中,使得一个测试类中的断言的使用方式保持一致,即能够将断言的使用方式更为统一。对断言进行统一化封装,即将每一条断言的描述信息统计到结果报告中,通过监听器的方式进行非退出断言的处理过程,实现不侵染用例代码,此外,还能够在结果报告中能够直观的展示断言的验证点。
具体实施方式
应当理解,此处所描述的具体实施例仅用以解释本申请,并不用于限定本申请。本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块,本申请中所出现的模块的划分,仅仅是一种逻辑上的划分,实际应用中实现时可以有另外的划分方式,例如多个模块可以结合成或集成在另一个系统中,或一些特征可以忽略,或不执行。
本申请提供一种测试中的断言处理方法、装置、设备及存储介质,可用于基于类的单元测试,例如对应用程序进行修改或者增加新功能时,可采用本申请的方案执行自动化的单元测试,以保证代码运行无误。
为解决上述技术问题,本申请主要提供以下技术方案:
通过将两个断言统一封装到一个测试类中,保持断言的使用方式保持一致;对断言进行统一化封装,即将每一条断言的描述信息统计到结果报告中,通过监听器的方式,进行非退出断言的处理过程,不侵染用例代码。能够将断言的使用方式更为统一,并且在结果报告中直观的展示断言的验证点。
其中,所述断言(assert)是指一些布尔表达式,用于对程序进行调试,确定某些被测试函数是否工作正常(即比较实际的值和预期的值是否一样),断言是对于执行结构的判断,而不是对于业务流程的判断。断言是单元测试最基本的组成部分,断言相当于一个if()语句,如果满足断言的执行程序,如果不满足则抛错误。每种类型的断言都有两种形式,一种包含接收一个message参数,例如“static public void assertTrue(Stringmessage,boolean condition)”,message表示出错时的提示信息,另外一个则没有message参数。例如,程序员相信在程序中的某个特定点该表达式值为真,可以在任何时候启用和禁用断言验证,在测试时启用断言,在部署时禁用断言。程序投入运行后,用户在遇到问题时可以重新启用断言。使用断言可以创建更稳定、品质更好且不易于出错的代码。当需要在一个值为FALSE时中断当前操作的话,使用断言即可,单元测试必须使用断言(Junit/JunitX)。断言还可用于确定各种特性是否在程序中得到维护的极好。assert(表达式):运行时断言,表达式为false,在运行时打印固定的错误信息,并终止程序。
请参照图1,以下对本申请提供一种测试中的断言处理方法进行举例说明,所述方法可由用于处理测试中断言的装置执行,用于处理测试中断言的装置可以是应用,也可以是安装了应用的测试设备,所述测试设备可以包括个人电脑、平板电脑、笔记本电脑等具有数据测试功能的终端设备。所述方法包括:
101、获取测试框架,在所述测试框架中设置至少两个断言。
其中,所述至少两个断言包括至少一个静态断言和至少一个动态断言,所述测试框架为基于类的单元测试。
本申请中,每条断言(也可称为断言语句)包括变量(也可以称为测试变量)和常量表达式等信息。可以在所述测试框架的测试头文件中设置所述至少两条断言。每条断言语句中的测试变量可对应一个依赖语句。
一些实施方式中,所述在所述测试框架中设置至少两个断言之后,所述所述方法还包括:
从所述测试框架中获取待处理的单元测试,单元测试包括至少一条断言语句;
从所述待处理的单元测试中提取多条断言语句和各断言语句中的测试变量;
获取各断言语句中的测试变量对应的依赖语句;
分别对应合并断言语句和依赖语句,得到各断言语句分别对应的目标单元测试,每个目标单元测试中包含一个断言语句。
其中,所述依赖语句是指在单个的测试单元中所能查找到的对所述断言语句中的测试变量进行修改的赋值语句和/或非赋值语句。其中,能对测试变量进行直接修改的语句称为赋值语句,不属于赋值语句的其他语句均统称为非赋值语句,在本申请中将这些能对所述测试变量进行修改的赋值语句和非赋值语句均作为所述测试变量的依赖语句,以使这些关联语句可以帮助软件开发人员、质量保证人员查找目标源代码语句中存在的结构性错误、安全漏洞等问题。
一些实施方式中,可通过结合静态分析策略和动态分析策略获取与断言语句中的测试变量对应的依赖语句。例如,通过静态分析策略分别得到:与测试变量a’对应的依赖语句为g(a’),与测试变量b’对应的依赖语句为g(b’),与测试变量c’对应的依赖语句为g(c’),与测试变量d’对应的依赖语句为g(d’),与测试变量e’对应的依赖语句为g(e’)。然后,将这5个断言语句分别与这5个断言语句相关联的依赖语句进行组合,组合得到与这5个断言语句分别对应的目标单元测试。
其中,所述静态分析策略可以为Slice静态分析策略,通过对单元测试进行遍历分析,以查找出包含所述测试变量(例如,Assert语句中的测试变量a)的所有关联语句(例如,g(a),f(a),h(a)),并判断所述多个关联语句中是否均为用于修改所述测试变量的赋值语句,若多个关联语句均为用于修改所述测试变量的赋值语句,则将多个关联语句确定为所述测试变量对应的依赖语句。
当采用所述静态分析策略无法直接对所述关联语句进行判断时(即在所述关联语句中存在属于非赋值语句的关联语句),例如,通过所述静态分析策略判断出f(a)、h(a)不是用于修改所述测试变量的赋值语句时,可采用动态分析策略将这两个非赋值语句(f(a)、h(a))作为待检测关联语句,并对所述待检测关联语句中的相关变量进行检测分析,以判断f(a)、h(a)是否为用于修改所述测试变量的非赋值语句。其中,在多个关联语句中,还可将属于用于修改所述测试变量的赋值语句的关联语句g(a)确定为所述目标测试变量对应的依赖语句。
102、将至少一个静态断言和至少一个动态断言划分到一个测试类。
其中,每个测试类包括至少一个静态断言和至少一个动态断言,在同一个测试类中的断言的使用方式相同。使用方式可以称为调用方式,调用方式可包括:被调用次数、断言某方法被调用过、测试通过用例和测试失败用例。本申请中的测试类包括:所有测试框架测试类的超类、对要运行的测试进行分组的类、制定单个测试方法、用于在测试框架中运行测试的类以及运行测试套件的结果。一些实施方式中,使用方式如下表1所示:
addPlugin |
将插件添加到TestRunner对象 |
run |
运行TestSuite数组中的所有测试 |
runInParallel |
并行运行TestSuite数组中的所有测试 |
withNoPlugins |
创建最简单的运行程序 |
withTextOutput |
创建用于命令行窗口输出的TestRunner对象 |
表1
静态断言(static assert)用于在编译时对某些宏定义数值大小,或者,对数据类型大小及一致性的检查,能够在编译时检查错误类型或语法错误,并报错。static_assert(常量表达式,“提示字符串”):编译时断言,例如常量表达式为false,那么在编译时显示给定的出错信息,提示字符串为“想让编译器显示的出错信息”。
动态断言在程序运行时候使用,如果表达式的结果为假,则会中断程序,动态断言需要引用头文件#include<cassert>,函数assert在调试阶段尽早发现“不可能”事件,若真发生,表示代码逻辑有误,程序中止(abort),并产生诊断信息,方便修改程序。例如,诊断信息为“我们断言i不等于227的,但事实上它等于了,违背了我们的断言,所以程序运行到此时会abort”。
103、将每个测试类中的断言的使用方式设置为一致,并将所述多个测试类封装至待测试的应用中。
在将所述多个测试类封装至待测试的应用中之前,还可以分别对每个测试类中的断言进行封装。
一些实施方式中,所述方法还包括:
生成多个测试用例,分别将每个测试用例尽可能多地覆盖未被覆盖过的测试类,直至所有测试类被测试用例覆盖。其中,测试用例是指一组条件或变量,可将软件测试的行为转化成可管理的模式。测试者可以根据它来确定应用软件或软件系统是否正确工作。
104、编译所述应用或运行所述应用时,执行所述测试框架,在执行所述测试框架过程中,分别调用所述测试类中的静态断言或动态断言对所述应用进行验证,并监听各测试类中的断言的验证状态信息。
其中,执行所述测试框架包括运行所述目标单元测试。
一些实施方式中,监听各测试类中的断言的验证状态信息时可采用hook机制,具体来说,所述监听各测试类中的断言的验证状态信息,包括:
在断言的各测试类中分别引入hook程序;
通过所述hook程序监听各测试类中变量或条件,以监听测试流程中的断言状态;
当所述hook程序监听到测试类中的变量或条件变化时,获取变量或条件发生变化的所述验证状态信息。
其中,hook程序是指一个处理消息的程序段,通过系统调用,把hook程序挂入系统,hook程序允许应用程序截获处理window消息或特定事件。应用程序可以在上面设置子程序以监视指定窗口的某种消息,hook程序所监听的窗口可以是其他进程所创建。当消息到达后,在目标窗口的处理函数之前捕获该消息、以及处理该消息。
105、当监听到所述测试类中的静态断言失败时,生成第一断言信息;当监听到所述测试类中的动态断言失败时,生成第二断言信息;执行完所述测试框架后,生成测试报告,并将所述第一断言信息和所述第二描述信息统计到所述测试报告中。
其中,所述第一断言信息包括出错信息,所述出错信息包括错误类型和错误位置。所述第二断言信息包括诊断信息和运行逻辑的异常断言点。
可以理解的是,在每个测试类中,会存在至少一条静态断言成功的描述信息,所述第一断言信息是指每条断言成功的静态断言的描述信息,动态断言同理,不做赘述。
在完成测试后,会得到各目标单元测试分别对应的测试结果,然后根据得到的测试结果生成所述测试报告。所述测试报告包括测试类中每条断言成功的静态断言的断言信息、以及每条断言成功的动态断言的断言信息。所述测试报告还可包括测试场景、测试案例以及在规则校验点指定的校验规则,具体本申请不作限定。
一些实施方式中,所述方法还包括:
当所述hook程序监听到验证状态信息为非退出断言状态时,不中断所述测试脚本的运行,直到生成所有验证结果;其中,所述非退出断言是指对测试用例中的测试参数使用断言时,退出程序不是因所述测试参数异常而退出程序。可见,本申请采用hook程序对断言状态进行监听后,当发生非退出断言时,不需要额外执行一个单独的异常处理函数。
与现有机制相比,本申请实施例中,通过将静态断言和动态断言统一到一个测试类中,使得一个测试类中的断言的使用方式保持一致,即能够将断言的使用方式更为统一。对断言进行统一化封装,即将每一条断言的描述信息统计到结果报告中,通过监听器的方式进行非退出断言的处理过程,实现不侵染用例代码,此外,还能够在结果报告中能够直观的展示断言的验证点。
可选的,在本申请的一些实施例中,所述执行所述测试框架之前,所述方法还包括:
生成配置文件,所述配置文件指示自动化测试运行的测试环境以及需要进行的测试场景映射关系;所述配置文件包括断言的起始位置、执行的断言操作和执行断言操作得到的期望值,所述断言的起始位置用于判定断言操作在所述应用的文件的起始执行位置,所述期望值用于判定测试执行结果是否符合测试的要求。
解析所述配置文件中的测试场景,获取各测试场景中各测试案例的测试规则、规则参数、测试数据、数据嵌入点、规则校验点及预期结果;其中,所述测试规则是根据参数化规则编制以用于多个测试场景或多个测试案例;
以测试数据为驱动,判断数据嵌入点是否符合测试数据所定义的注入时点,若符合,则将测试数据注入测试对象;
判断规则校验点是否符合测试案例所定义的测试结果校验时点,若符合,则将测试案例的规则参数与测试规则拼装,并获取测试案例的具体规则内容,在已注入测试数据的测试对象中执行具体规则内容,得到实际运行结果;
分别针对各测试案例的实际运行结果和预期结果进行比较,生成校验结果。
可选的,在本申请的一些实施例中,在所述步骤104之后,在所述步骤105之前,所述方法还包括:
基于预设的可疑度函数以及各目标单元测试分别对应的测试结果计算与目标单元测试相关联的目标源代码语句对应的出错率。
一些实施方式中,基于预设的可疑度函数以及所述测试结果计算与所述目标单元测试相关联的目标源代码语句对应的出错率,包括:
运行所述目标单元测试,并得到与所述目标单元测试分别对应的测试结果,所述测试结果中包含测试成功结果以及测试失败结果;
在所有测试结果中,统计为所述测试失败结果的目标单元测试的失败总数量;
在所述目标单元测试中查找与目标源代码语句相关联的多个目标单元测试,作为多个关联目标单元测试;
在所有关联目标单元测试分别对应的测试结果中,统计为所述测试失败结果的关联目标单元测试的失败测试数目,并统计为所述测试成功结果的关联目标单元测试的成功测试数目;
根据预设的可疑度函数、所述失败总数量、所述第一数量以及所述第二数量,计算与所述目标单元测试相关联的所述目标源代码语句的出错率。
一些实施方式中,所述可疑度函数是指可以为Ochiai算法,且所述Ochiai算法可用于计算每条目标源代码语句对应的出现率,以目标源代码语句为s语句为例,所述可疑度函数可以参考下述公式:
其中,failed(s)表示失败测试数目,失败测试数目是指与s语句关联的测试结果为失败的目标单元测试的数量,passed(s)表示成功测试数目,成功测试数目是指与s语句关联的为测试成功结果的关联目标单元测试的数量,total_failed表示在所有的目标单元测试中所统计到的所有携带所述测试失败结果的目标单元测试的失败总数量(即所有失败测试的数目)。因此,将所述失败总数量,失败测试数目和成功测试数目作为所述可疑度函数的输入值,可输出与所述目标源代码语句(s语句)对应的出错率suspicious(s),且suspicious(s)的值越大,表明该s语句出错的可能性越大。
上述图1所对应的实施例及各可选的实施方式中所提及的各项技术特征也同样适用于本申请中的图2和图3所对应的实施例,后续类似之处不再赘述。
以上对本申请中一种测试中的断言处理方法进行说明,以下对执行上述测试中的断言处理方法的装置进行描述。
如图2所示的一种用于处理测试中断言的装置20的结构示意图,其可应用于单元测试。本申请实施例中的装置20能够实现对应于上述图1所对应的实施例中所执行的测试中的断言处理方法中的步骤。装置20实现的功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块,所述模块可以是软件和/或硬件。所述装置20可包括输入输出模块201、处理模块202和监听模块203,所述输入输出模块201、处理模块202和监听模块203的功能实现可参考图1所对应的实施例中所执行的操作,此处不作赘述。处理模块可用于控制所述输入输出模块201的收发操作,以及控制监听模块203的监听操作。
一些实施方式中,所述输入输出模块201可用于获取测试框架,在所述测试框架中设置至少两个断言,所述至少两个断言包括至少一个静态断言和至少一个动态断言,所述测试框架为基于类的单元测试;
所述处理模块202可用于将至少一个静态断言和至少一个动态断言划分到一个测试类;
所述处理模块202还用于将每个测试类中的断言的使用方式设置为一致,并将所述多个测试类封装至待测试的应用中;在编译所述应用或运行所述应用时,执行所述测试框架,在执行所述测试框架过程中,分别调用所述测试类中的静态断言或动态断言对所述应用进行验证;
所述监听模块203可于监听各测试类中的断言的验证状态信息;
所述处理模块202还用于当所述监听模块203监听到所述测试类中的静态断言失败时,生成第一断言信息;当所述监听模块203监听到所述测试类中的动态断言失败时,生成第二断言信息;执行完所述测试框架后,生成测试报告,并将所述第一断言信息和所述第二描述信息统计到所述测试报告中;所述第一断言信息包括出错信息,所述出错信息包括错误类型和错误位置,所述第二断言信息包括诊断信息和运行逻辑的异常断言点。
本申请实施例中,所述处理模块202通过将静态断言和动态断言统一到一个测试类中,使得一个测试类中的断言的使用方式保持一致,即能够将断言的使用方式更为统一。对断言进行统一化封装,即将每一条断言的描述信息统计到结果报告中,通过所述监听模块203对断言状态监听的方式进行非退出断言的处理过程,实现不侵染用例代码,此外,还能够在结果报告中能够直观的展示断言的验证点。
一些实施方式中,在每个测试类中,存在至少一条静态断言成功的描述信息,所述第一断言信息是指每条断言成功的静态断言的描述信息;所述测试报告包括测试类中每条断言成功的静态断言的断言信息、以及每条断言成功的动态断言的断言信息。
一些实施方式中,所述使用方式包括:被调用次数、断言某方法被调用过、测试通过用例和测试失败用例;
所述测试类包括:所有测试框架测试类的超类、对要运行的测试进行分组的类、制定单个测试方法、用于在测试框架中运行测试的类以及运行测试套件的结果。
一些实施方式中,所述处理模块202还用于:
生成多个测试用例,所述测试用例是指将软件测试的行为转化成可管理的模式的一组条件或变量,所述测试用例用于确定应用软件或软件系统是否正确工作;
分别将每个测试用例覆盖部分或全部未被覆盖过的测试类,直至所有测试类均被测试用例覆盖。
一些实施方式中,所述监听模块203具体用于:
在断言的各测试类中分别引入hook程序;
通过所述hook程序监听各测试类中变量或条件,以监听测试流程中的断言状态;
当所述hook程序监听到测试类中的变量或条件变化时,获取变量或条件发生变化的所述验证状态信息;
所述处理模块202还用于:
当所述监听模块203监听到验证状态信息为非退出断言状态时,不中断所述测试脚本的运行,直到生成所有验证结果;其中,所述非退出断言是指对测试用例中的测试参数使用断言时,退出程序不是因所述测试参数异常而退出程序。
一些实施方式中,所述处理模块202执行所述测试框架之前,还用于:
生成配置文件,所述配置文件指示自动化测试运行的测试环境以及需要进行的测试场景映射关系;所述配置文件包括断言的起始位置、执行的断言操作和执行断言操作得到的期望值,所述断言的起始位置用于判定断言操作在所述应用的文件的起始执行位置,所述期望值用于判定测试执行结果是否符合测试的要求。
解析所述配置文件中的测试场景,通过所述输入输出模块201获取各测试场景中各测试案例的测试规则、规则参数、测试数据、数据嵌入点、规则校验点及预期结果;其中,所述测试规则是根据参数化规则编制以用于多个测试场景或多个测试案例;
以测试数据为驱动,判断数据嵌入点是否符合测试数据所定义的注入时点,若符合,则将测试数据注入测试对象;
判断规则校验点是否符合测试案例所定义的测试结果校验时点,若符合,则将测试案例的规则参数与测试规则拼装,并获取测试案例的具体规则内容,在已注入测试数据的测试对象中执行具体规则内容,得到实际运行结果;
分别针对各测试案例的实际运行结果和预期结果进行比较,生成校验结果。
一些实施方式中,所述处理模块202执行所述测试框架之后,生成第一断言信息之前,还用于:
运行所述目标单元测试,并得到与所述目标单元测试分别对应的测试结果,所述测试结果中包含测试成功结果以及测试失败结果;
在所有测试结果中,统计为所述测试失败结果的目标单元测试的失败总数量;
在所述目标单元测试中查找与目标源代码语句相关联的多个目标单元测试,作为多个关联目标单元测试;
在所有关联目标单元测试分别对应的测试结果中,统计为所述测试失败结果的关联目标单元测试的失败测试数目,并统计为所述测试成功结果的关联目标单元测试的成功测试数目;
根据预设的可疑度函数、所述失败总数量、所述第一数量以及所述第二数量,计算与所述目标单元测试相关联的所述目标源代码语句的出错率。
上面从模块化功能实体的角度分别介绍了本申请实施例中的用于处理测试中断言的装置20,以下从硬件角度介绍一种计算机设备,如图3所示,其包括:处理器、存储器、监控器、输入输出单元以及存储在所述存储器中并可在所述处理器上运行的计算机程序。例如,该计算机程序可以为图1所对应的实施例中测试中的断言处理方法对应的程序。例如,当计算机设备实现如图2所示的装置20的功能时,所述处理器执行所述计算机程序时实现上述图3所对应的实施例中由装置20执行的测试中的断言处理方法中的各步骤;或者,所述处理器执行所述计算机程序时实现上述图2所对应的实施例的装置20中各模块的功能。又例如,该计算机程序可以为图1所对应的实施例中测试中的断言处理方法对应的程序。
所称处理器可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等,所述处理器是所述计算机设备的控制中心,利用各种接口和线路连接整个计算机设备的各个部分。
所述存储器可用于存储所述计算机程序和/或模块,所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块,以及调用存储在存储器内的数据,实现所述计算机设备的各种功能。所述存储器可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据手机的使用所创建的数据(比如音频数据、视频数据等)等。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器,例如硬盘、内存、插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
所述输入输出单元也可以用输入单元和输出单元代替,可以为相同或者不同的物理实体。为相同的物理实体时,可以统称为输入输出单元。该输入输出单元可以为收发器。
所述存储器可以集成在所述处理器中,也可以与所述处理器分开设置。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM)中,包括若干指令用以使得一台终端(可以是手机,计算机,服务器或者网络设备等)执行本申请各个实施例所述的方法。
上面结合附图对本申请的实施例进行了描述,但是本申请并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本申请的启示下,在不脱离本申请宗旨和权利要求所保护的范围情况下,还可做出很多形式,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,这些均属于本申请的保护之内。