单元性能测试方法及设备与流程

文档序号:11233982阅读:487来源:国知局
单元性能测试方法及设备与流程

本发明涉及计算机领域,尤其涉及一种单元性能测试方法及设备。



背景技术:

传统的单元测试框架如junit等无法执行性能测试,其中junit是一个java语言的单元测试框架。而传统的性能测试工具如jmeter、loadrunner等,一般都要求系统被部署成功才能进行测试,即有明确“入口”的系统,“入口”更多的是指可以被远程访问到的一种方式,比如http、rpc等,另外,传统性能测试工具在执行性能测试时,只返回性能测试结果,而无法对性能测试结果进行评估,需要人工对性能结果进行二次确认并编写性能测试报告,费时费力。



技术实现要素:

本发明的一个目的是提供一种单元性能测试方法及设备,能够解决对未经部署的单元做性能测试和自动对性能测试结果进行评估的问题。

根据本发明的一个方面,提供了一种单元性能测试方法,该方法包括:

定义待测试单元的性能测试的属性和性能测试结果的期望值;

在单元测试框架中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果;

在单元测试框架中,将性能测试结果与所述期望值进行比较,判断测试成功或失败。

进一步的,上述方法中,判断测试成功或失败之后,还包括:

根据判断的结果生成测试报告。

进一步的,上述方法中,所述属性包括:

待测试单元执行的次数、同时执行的线程数、增加线程的间隔时间、加载完毕所有线程的时间及有无集合点。

进一步的,上述方法中,所述属性包括:

在指定时间范围内一直执行测试、同时执行的线程数、增加线程的间隔时间、加载完毕所有线程的时间及有无集合点。

进一步的,上述方法中,定义待测试单元的性能测试的属性,包括:

以注解的方式在待测试单元内定义待测试单元的性能测试的属性和性能测试结果的期望值。

进一步的,上述方法中,所述性能测试结果包括:待测试单元的实际平均吞吐量和待测试单元的实际平均每一次的响应时间中的一种或任意组合。

进一步的,上述方法中,所述性能测试结果包括:待测试单元的所有执行次数中50%次的实际响应时间和待测试单元的所有执行次数中的最大实际响应时间中的一种或任意组合。

进一步的,上述方法中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果,包括:

根据所述属性并启动多线程对所述待测试单元进行测试;

获取测试中待测试单元的采样响应时间;

根据所述采样响应时间计算待测试单元的所有执行次数中50%次的实际响应时间和待测试单元的所有执行次数中的最大实际响应时间中的一种或任意组合。

进一步的,上述方法中,所述响应时间包括测试中待测试单元每一次执行的时长和每1秒内待测试单元执行的次数。

进一步的,上述方法中,所述单元测试框架为基于junit的框架。

根据本发明的另一方面,还提供了一种单元性能测试设备,该设备包括:

定义装置,用于定义待测试单元的性能测试的属性和性能测试结果的期望值;

单元测试框架,用于根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果及将性能测试结果与所述期望值进行比较,判断测试成功或失败。

进一步的,上述设备中,所述设备还包括测试报告装置,用于判断测试成功或失败之后,根据判断的结果生成测试报告。

进一步的,上述设备中,所述属性包括:

待测试单元执行的次数、同时执行的线程数、增加线程的间隔时间、加载完毕所有线程的时间及有无集合点。

进一步的,上述设备中,所述属性包括:

在指定时间范围内一直执行测试、同时执行的线程数、增加线程的间隔时间、加载完毕所有线程的时间及有无集合点。

进一步的,上述设备中,所述定义装置,用于以注解的方式在待测试单元内定义待测试单元的性能测试的属性和性能测试结果的期望值。

进一步的,上述设备中,所述性能测试结果包括:待测试单元的实际平均吞吐量和待测试单元的实际平均每一次的响应时间中的一种或任意组合。

进一步的,上述设备中,所述性能测试结果包括:待测试单元的所有执行次数中50%次的实际响应时间和待测试单元的所有执行次数中的最大实际响应时间中的一种或任意组合。

进一步的,上述设备中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果,包括:

根据所述属性并启动多线程对所述待测试单元进行测试;

获取测试中待测试单元的采样响应时间;

根据所述采样响应时间计算待测试单元的所有执行次数中50%次的实际响应时间和待测试单元的所有执行次数中的最大实际响应时间中的一种或任意组合。

进一步的,上述设备中,所述响应时间包括测试中待测试单元每一次执行的时长和每1秒内待测试单元执行的次数。

进一步的,上述设备中,所述单元测试框架为基于junit的框架。

根据本申请的一个方面,还提供了一种单元性能测试设备,其中,该设备包括:

处理器;以及被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器:

定义待测试单元的性能测试的属性和性能测试结果的期望值;

根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果及将性能测试结果与所述期望值进行比较,判断测试成功或失败。

与现有技术相比,本申请通过在单元测试框架中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果,能够实现对未经部署的单元做性能测试,另外,通过在单元测试框架中,将性能测试结果与所述期望值进行比较,判断测试成功或失败,能够实现自动对性能测试结果进行评估,且本申请可回归执行,方便再次评估,无需人工介入。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显:

图1示出根据本发明一个方面的一种单元性能测试方法的流程图;

图2示出本发明一优选的实施例的原理图;

图3示出根据本发明另一个方面的一种单元性能测试设备的模块图

图4示出根据本发明一种单元性能测试设备一优选的实施例的模块图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本发明作进一步详细描述。

在本申请一个典型的配置中,终端、服务网络的设备和可信方均包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。

如图1所示,本申请提供一种单元性能测试方法,该方法包括:

步骤s1,定义待测试单元的性能测试的属性和性能测试结果的期望值;

步骤s2,在单元测试框架中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果;

步骤s3,在单元测试框架中,将性能测试结果与所述期望值进行比较,判断测试成功或失败。在此,所述待测试单元是包括单独一个方法、或者模块或者未经部署的系统等,本实施例通过在单元测试框架中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果,能够实现对未经部署的单元做性能测试,另外,通过在单元测试框架中,将性能测试结果与所述期望值进行比较,判断测试成功或失败,能够实现自动对性能测试结果进行评估,且本实施例可回归执行,方便再次评估,无需人工介入。

本申请的单元性能测试方法一优选的实施例中,判断测试成功或失败之后,还包括:

根据判断的结果生成测试报告,从而实现根据性能评估,生成可视化更为直观的性能测试报告,直观返回结论。例如,如图2所示,如果比较的结果为符合期望值,则生成成功测试报告s28;如果比较的结果为不符合期望值,可在测试报告中将测试失败的项标红s27。

本申请的单元性能测试方法一优选的实施例中,所述属性包括:

待测试单元执行的次数(invocations)、同时执行的线程数(threads)、增加线程的间隔时间(rampup)、加载完毕所有线程的时间(warmup)及有无集合点(barrier)。具体的,当设置有集合点时,每个线程都会等待其他线程执行完同一待测试单元(test2)后再一起并发执行下一轮的该待测试单元(test2)的测试。

本申请的单元性能测试方法一优选的实施例中,所述属性包括:

在指定时间范围内一直执行测试(duration)、同时执行的线程数(threads)、增加线程的间隔时间(rampup)、加载完毕所有线程的时间(warmup)及有无集合点(barrier)。在此,待测试单元执行的次数(invocations)和指定时间范围内一直执行测试(duration)因为互相矛盾,所以在定义属性时只要择一定义即可。例如,可以定义@perftest(threads=10,duration=60000,rampup=1000,warmup=9000,barrier=true),表示10个线程,跑60s(秒),初始线程是1个,每隔1s增加一个线程,有集合点。

本申请的单元性能测试方法一优选的实施例中,定义待测试单元的性能测试的属性,包括:

以注解的方式在待测试单元内定义待测试单元的性能测试的属性和性能测试结果的期望值。这种定义方式简单、便捷,如图2所示,后续单元测试框架即可通过注解获取定义的待测试单元的性能测试的属性s21,然后通过单元测试框架进行性能测试s22,并且后续单元测试框架通过注解获取定义的性能测试结果的期望值s25,与性能测试结果进行比对s26,实现对性能测试结果进行评估。

本申请的单元性能测试方法一优选的实施例中,在单元测试框架中,所述性能测试结果包括:待测试单元的实际平均吞吐量和待测试单元的实际平均每一次的响应时间中的一种或任意组合。相应的,所述期望值包括待测试单元的期望平均吞吐量(throughoutput),用于后续与待测试单元的实际平均吞吐量进行比较;所述期望值还包括待测试单元的期望平均每一次的响应时间(average),用于后续与待测试单元的实际平均每一次的响应时间进行比较。例如,可以设置@required(throughoutput=20),表示待测试单元的期望平均吞吐量达到20,还可以设置@required(average=20),表示待测试单元的期望平均每一次的响应时间为20m。在此,由于待测试单元执行的次数(invocations)和指定时间范围内一直执行测试(duration)因为互相矛盾,所以在定义属性时只要择一定义即可,所以如果前面设置的属性是待测试单元执行的次数(invocations),那么待测试单元的实际平均吞吐量=待测试单元执行的次数/执行完所有次数所花的时间;如果前面设置的属性是在指定时间范围内一直执行测试(duration),那么待测试单元的实际平均吞吐量=指定时间范围内执行待测试单元的次数/所述指定时间范围。这里完成所有测试所实际完成的总时间可能是由设置的duration确定,也可能是根据设置了的invocation,运行完所有的invocation所得到总的响应时间来确定。另外,待测试单元的期望平均每一次的响应时间(average)为待测试单元的期望平均吞吐量(throughoutput)的倒数。

本申请的单元性能测试方法一优选的实施例中,所述性能测试结果包括待测试单元的所有执行次数中50%次的实际响应时间和待测试单元的所有执行次数中的最大实际响应时间中的一种或任意组合。在此,待测试单元的所有执行次数中50%次的实际响应时间可以根据所有次的实际响应时间的区间得到。对应的,所述期望值包括至少50%执行的响应时间,是指待测试单元的所有执行次数中50%次的响应时间小于等于预设值(median),至少50%执行的响应时间用于与所有执行次数中50%次的实际响应时间进行比较;所述期望值还包括待测试单元的所有执行次数中的最大期望响应时间(max),是指待测试单元的所有的执行次数中最大的响应时间要小于预设值,待测试单元的所有执行次数中的最大期望响应时间用于与待测试单元的所有执行次数中的最大实际响应时间进行比较。例如,可以设置@required(median=20),表示测试单元的所有执行次数中50%次的期望响应时间在20ms以内,还可以设置@required(max=200),待测试单元的所有执行次数中的最大期望响应时间不超过200ms(毫秒)。

本申请的单元性能测试方法一优选的实施例中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果,包括:

根据所述属性并启动多线程对所述待测试单元进行测试;

获取测试中待测试单元的采样响应时间;

根据所述采样响应时间计算待测试单元的所有执行次数中50%次的实际响应时间和待测试单元的所有执行次数中的最大实际响应时间中的一种或任意组合。例如,如图2所示,可在调用junit进行压测s22后,收集junit性能原始测试结果数据s23,这里的junit性能原始测试结果数据即包括测试中待测试单元的采样响应时间。假设测试运行了300s,那么300s里可能运行了1000次的对待测试单元的测试,将每次对待测试单元的测试的所花费的时间都记录下来了,那么就可以统计所有执行次数中50%次的实际响应时间。在此,根据待测试单元的采样响应时间可以精确地得到性能测试结果。

本申请的单元性能测试方法一优选的实施例中,所述响应时间包括测试中待测试单元每一次执行的时长和每1秒内待测试单元执行的次数。

本申请的单元性能测试方法一优选的实施例中,所述单元测试框架为基于junit的框架。在此,基于junit的框架,所有支持junit的持续集成框架都可以运行,每次运行有可视化的结果保存,可以调用junit的断言方法将实际的测试结果与期望值比较,还可以对各次结果进行对比,实现可持续回归的性能测试。

如图3所示,根据本申请的另一面,还提供一种单元性能测试设备,其中,该设备100包括:

定义装置1,用于定义待测试单元的性能测试的属性和性能测试结果的期望值;

单元测试框架2,用于根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果及将性能测试结果与所述期望值进行比较,判断测试成功或失败。在此,所述待测试单元是包括单独一个方法、或者模块或者未经部署的系统等,本实施例通过在单元测试框架中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果,能够实现对未经部署的单元做性能测试,另外,通过在单元测试框架中,将性能测试结果与所述期望值进行比较,判断测试成功或失败,能够实现自动对性能测试结果进行评估,且本实施例可回归执行,方便再次评估,无需人工介入。

如图4所示,本申请的一种单元性能测试设备一优选的实施例中,所述设备100还包括测试报告装置3,用于判断测试成功或失败之后,根据判断的结果生成测试报告,从而实现根据性能评估,生成可视化更为直观的性能测试报告,直观返回结论。例如,如图2所示,如果比较的结果为符合期望值,则生成成功测试报告s28;如果比较的结果为不符合期望值,可在测试报告中将测试失败的项标红s27。

本申请的一种单元性能测试设备一优选的实施例中,所述属性包括:

待测试单元执行的次数(invocations)、同时执行的线程数(threads)、增加线程的间隔时间(rampup)、加载完毕所有线程的时间(warmup)及有无集合点(barrier)。具体的,当设置有集合点时,每个线程都会等待其他线程执行完同一待测试单元(test2)后再一起并发执行下一轮的该待测试单元(test2)的测试。

本申请的一种单元性能测试设备一优选的实施例中,所述属性包括:

在指定时间范围内一直执行测试(duration)、同时执行的线程数(threads)、增加线程的间隔时间(rampup)、加载完毕所有线程的时间(warmup)及有无集合点(barrier)。在此,待测试单元执行的次数(invocations)和指定时间范围内一直执行测试(duration)因为互相矛盾,所以在定义属性时只要择一定义即可。例如,可以定义@perftest(threads=10,duration=60000,rampup=1000,warmup=9000,barrier=true),表示10个线程,跑60s(秒),初始线程是1个,每隔1s增加一个线程,有集合点。

本申请的一种单元性能测试设备一优选的实施例中,所述定义装置1,用于以注解的方式在待测试单元内定义待测试单元的性能测试的属性和性能测试结果的期望值。这种定义方式简单、便捷,如图2所示,后续单元测试框架即可通过注解获取定义的待测试单元的性能测试的属性s21,然后通过单元测试框架进行性能测试s22,并且后续单元测试框架通过注解获取定义的性能测试结果的期望值s25,与性能测试结果进行比对s26,实现对性能测试结果进行评估。

本申请的一种单元性能测试设备一优选的实施例中,所述性能测试结果包括:待测试单元的实际平均吞吐量和待测试单元的实际平均每一次的响应时间中的一种或任意组合。相应的,所述期望值包括待测试单元的期望平均吞吐量(throughoutput),用于后续与待测试单元的实际平均吞吐量进行比较;所述期望值还包括待测试单元的期望平均每一次的响应时间(average),用于后续与待测试单元的实际平均每一次的响应时间进行比较。例如,可以设置@required(throughoutput=20),表示待测试单元的期望平均吞吐量达到20,还可以设置@required(average=20),表示待测试单元的期望平均每一次的响应时间为20m。在此,由于待测试单元执行的次数(invocations)和指定时间范围内一直执行测试(duration)因为互相矛盾,所以在定义属性时只要择一定义即可,所以如果前面设置的属性是待测试单元执行的次数(invocations),那么待测试单元的实际平均吞吐量=待测试单元执行的次数/执行完所有次数所花的时间;如果前面设置的属性是在指定时间范围内一直执行测试(duration),那么待测试单元的实际平均吞吐量=指定时间范围内执行待测试单元的次数/所述指定时间范围。这里完成所有测试所实际完成的总时间可能是由设置的duration确定,也可能是根据设置了的invocation,运行完所有的invocation所得到总的响应时间来确定。另外,待测试单元的期望平均每一次的响应时间(average)为待测试单元的期望平均吞吐量(throughoutput)的倒数。

本申请的一种单元性能测试设备一优选的实施例中,所述性能测试结果包括:待测试单元的所有执行次数中50%次的实际响应时间和待测试单元的所有执行次数中的最大实际响应时间中的一种或任意组合。在此,待测试单元的所有执行次数中50%次的实际响应时间可以根据所有次的实际响应时间的区间得到。对应的,所述期望值包括至少50%执行的响应时间,是指待测试单元的所有执行次数中50%次的响应时间小于等于预设值(median),至少50%执行的响应时间用于与所有执行次数中50%次的实际响应时间进行比较;所述期望值还包括待测试单元的所有执行次数中的最大期望响应时间(max),是指待测试单元的所有的执行次数中最大的响应时间要小于预设值,待测试单元的所有执行次数中的最大期望响应时间用于与待测试单元的所有执行次数中的最大实际响应时间进行比较。例如,可以设置@required(median=20),表示测试单元的所有执行次数中50%次的期望响应时间在20ms以内,还可以设置@required(max=200),待测试单元的所有执行次数中的最大期望响应时间不超过200ms(毫秒)。

本申请的一种单元性能测试设备一优选的实施例中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果,包括:

根据所述属性并启动多线程对所述待测试单元进行测试;

获取测试中待测试单元的采样响应时间;

根据所述采样响应时间计算待测试单元的所有执行次数中50%次的实际响应时间和待测试单元的所有执行次数中的最大实际响应时间中的一种或任意组合。例如,如图2所示,可在调用junit进行压测s22后,收集junit性能原始测试结果数据s23,这里的junit性能原始测试结果数据即包括测试中待测试单元的采样响应时间。假设测试运行了300s,那么300s里可能运行了1000次的对待测试单元的测试,将每次对待测试单元的测试的所花费的时间都记录下来了,那么就可以统计所有执行次数中50%次的实际响应时间。在此,根据待测试单元的采样响应时间可以精确地得到性能测试结果。

本申请的一种单元性能测试设备一优选的实施例中,所述响应时间包括测试中待测试单元每一次执行的时长和每1秒内待测试单元执行的次数。

本申请的一种单元性能测试设备一优选的实施例中,所述单元测试框架2为基于junit的框架。在此,基于junit的框架,所有支持junit的持续集成框架都可以运行,每次运行有可视化的结果保存,可以调用junit的断言方法将实际的测试结果与期望值比较,还可以对各次结果进行对比,实现可持续回归的性能测试。

综上所述,本申请通过在单元测试框架中,根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果,能够实现对未经部署的单元做性能测试,另外,通过在单元测试框架中,将性能测试结果与所述期望值进行比较,判断测试成功或失败,能够实现自动对性能测试结果进行评估,且本申请可回归执行,方便再次评估,无需人工介入。

此外,本申请还提供了一种单元性能测试设备,其中,该设备包括:

处理器;以及被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器:

定义待测试单元的性能测试的属性和性能测试结果的期望值;

根据所述属性并启动多线程对所述待测试单元进行测试得到性能测试结果及将性能测试结果与所述期望值进行比较,判断测试成功或失败。

显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

需要注意的是,本发明可在软件和/或软件与硬件的组合体中被实施,例如,可采用专用集成电路(asic)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中,本发明的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地,本发明的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中,例如,ram存储器,磁或光驱动器或软磁盘及类似设备。另外,本发明的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。

另外,本发明的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本发明的方法和/或技术方案。而调用本发明的方法的程序指令,可能被存储在固定的或可移动的记录介质中,和/或通过广播或其他信号承载媒体中的数据流而被传输,和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此,根据本发明的一个实施例包括一个装置,该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器,其中,当该计算机程序指令被该处理器执行时,触发该装置运行基于前述根据本发明的多个实施例的方法和/或技术方案。

对于本领域技术人员而言,显然本发明不限于上述示范性实施例的细节,而且在不背离本发明的精神或基本特征的情况下,能够以其他的具体形式实现本发明。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本发明的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一,第二等词语用来表示名称,而并不表示任何特定的顺序。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1