银行系统中应用程序的性能测试方法、装置、设备和介质与流程

文档序号:30445794发布日期:2022-06-18 00:35阅读:126来源:国知局
银行系统中应用程序的性能测试方法、装置、设备和介质与流程

1.本技术涉及网络安全技术领域,尤其涉及一种银行系统中应用程序的性能测试方法、装置、设备和介质。


背景技术:

2.随着终端电子产品的普及,依托终端开发的应用程序也越来越多,在应用程序上线之前,一般需要进行性能测试。尤其是涉及金融属性的银行系统中的应用程序,为了保证应用程序的安全性和稳定性,更需要进行性能测试。
3.在相关技术中,通过手动设置测试场景,然后手动执行测试场景,并通过测试工具获取性能数据,并在测试完成后将各种性能数据整理成报告。对于同一个测试场景,一般需要重复执行3至5次,以减少性能数据的误差。然而,手动重复执行场景对应用程序进行性能测试的方式,测试效率较低。


技术实现要素:

4.本技术提供了一种银行系统中应用程序的性能测试方法、装置、设备和介质,以解决现有技术中手动重复执行测试场景对于程序进行性能测试的测试效率较低的问题。
5.为达到上述目的,本技术采用如下技术方案:
6.第一方面,本技术提供一种银行系统中应用程序的性能测试方法,该方法包括:根据银行系统中的应用程序的至少一个测试场景,生成自动化测试脚本;获取测试参数,测试参数包括测试起始时间,测试终止时间,预置测试执行次数,以及至少一个测试场景中各个测试场景的测试执行顺序;根据测试参数,执行自动化测试脚本,获取每个测试场景的性能参数,性能参数包括以下至少一项:响应时间、耗电量、中央处理器cpu消耗量、网络流量消耗量和渲染帧率;根据性能参数,生成性能测试报告。
7.由上述可知,本技术提供的银行系统中应用程序的性能测试方法,能够生成与银行系统中应用程序的测试场景对应的自动化测试脚本,结合获取的测试参数,即可实现对银行应用程序的自动性能测试,无需手动重复执行测试场景,能够提高性能测试的效率,节约人力成本,并且能够减少测试人员的主观能力对测试到的性能参数的影响,提高测试结果的准确度。
8.可选的,获取每个测试场景的性能参数,包括:根据应用程序的数据监听接口,获取每个测试场景的性能参数。
9.由上述可知,对于银行系统中的应用程序而言,其数据安全性尤其重要,应用程序运行过程产生的数据不能进行数据传输,因此,通过数据监听接口监听,直接获取应用程序在运行过程中的性能参数,能够提高性能参数的准确性。
10.可选的,根据银行应用程序的数据监听接口,获取每个测试场景的性能参数,包括:在应用程序的程序代码中,根据预置关键字查找数据监听接口;将数据监听接口的监听状态更改为可监听状态,开放数据监听接口的监听权限;在数据监听接口开放监听权限的
情况下,通过监听数据监听接口获取每个测试场景的性能参数。
11.由上述可知,在查找到数据监听接口后,通过强制更改数据监听接口的监听状态,以便于对应用程序进行监控,以确保能够获取性能参数,并且能够提高性能参数的准确性。
12.可选的,根据测试参数,执行自动化测试脚本,包括:当前时间在测试终止时间之前,且自动化测试脚本的已执行次数小于预置测试执行次数的情况下,继续执行自动化测试脚本;当前时间在测试终止时间之前,且自动化测试脚本的已执行次数等于预置测试执行次数的情况下,停止执行自动化测试脚本;当前时间等于测试终止时间或在测试终止时间之后的情况下,停止执行自动化测试脚本。
13.由上述可知,根据测试参数中的测试终止时间和当前时间的比较结果,以及已执行测试和预置测试执行次数的比较结果,判断是否继续执行自动化测试脚本,即,判断是否完成对银行系统中应用程序的性能测试,以便于尽量缩短完成性能测试的测试时间或测试次数,以便于提高对银行应用程序的测试效率。
14.可选的,根据测试参数,执行自动化测试脚本,获取每个测试场景的性能参数之后,上述方法还包括:在预置测试执行次数大于预置次数阈值的情况下,统计每个性能参数的标准差;在标准差大于预置偏差阈值的情况下,生成提示信息,提示信息用于提示应用程序需要重新测试。
15.由上述可知,在性能测试过程中,可能存在硬件故障、掉电等被迫中断的情况,可能导致不同预置测试执行次数对应的性能参数相比差别较大,通过统计不同预置测试执行次数对应的性能参数之间的标准差,判断上述特殊情况对性能参数的影响,以便于提示重新进行性能测试。
16.第二方面,本技术提供一种银行系统中应用程序的性能测试装置,包括生成单元、获取单元和处理单元;生成单元,用于根据银行系统中应用程序的至少一个测试场景,生成自动化测试脚本;获取单元,用于获取测试参数,测试参数包括测试起始时间,测试终止时间,预置测试执行次数,以及至少一个测试场景中各个测试场景的测试执行顺序;处理单元,用于根据获取单元获取的测试参数,执行生成单元生成的自动化测试脚本,获取每个测试场景的性能参数,性能参数包括以下至少一项:响应时间、耗电量、中央处理器cpu消耗量、网络流量消耗量和渲染帧率;生成单元,还用于根据处理单元得到的性能参数,生成性能测试报告。
17.可选的,处理单元,用于:根据应用程序的数据监听接口,获取每个测试场景的性能参数。
18.可选的,处理单元,具体用于:在应用程序的程序代码中,根据预置关键字查找数据监听接口;将数据监听接口的监听状态更改为可监听状态,开放数据监听接口的监听权限;在数据监听接口开放监听权限的情况下,通过监听数据监听接口获取每个测试场景的性能参数。
19.可选的,处理单元,具体还用于:当前时间在测试终止时间之前,且自动化测试脚本的已执行次数小于预置测试执行次数的情况下,继续执行自动化测试脚本;当前时间在测试终止时间之前,且自动化测试脚本的已执行次数等于预置测试执行次数的情况下,停止执行自动化测试脚本;当前时间等于测试终止时间或在测试终止时间之后的情况下,停止执行自动化测试脚本。
20.可选的,上述装置还包括:统计单元;统计单元,用于处理单元根据测试参数,执行自动化测试脚本,获取每个测试场景的性能参数之后,在预置测试执行次数大于预置次数阈值的情况下,统计每个性能参数的标准差;生成单元,还用于在统计单元统计的标准差大于预置偏差阈值的情况下,生成提示信息,提示信息用于提示应用程序需要重新测试。
21.第三方面,提供一种电子设备,包括:处理器;用于存储该处理器可执行指令的存储器;其中,该处理器被配置为执行指令,以实现如上述第一方面提供的方法。
22.第四方面,本技术提供一种计算机可读存储介质,包括指令。当指令在计算机上运行时,使得计算机执行如上述第一方面提供的方法。
23.第五方面,本技术提供一种计算机程序产品,当计算机程序产品在计算机上运行时,使得计算机执行如上述第一方面提供的方法。
24.需要说明的是,上述计算机指令可以全部或者部分存储在第一计算机可读存储介质上。其中,第一计算机可读存储介质可以与接入网终端设备的处理器封装在一起的,也可以与接入网终端设备的处理器单独封装,本技术对此不作限定。
25.本技术中第二方面、第三方面、第四方面和第五方面的描述,可以参考第一方面的详细描述;并且,第二方面、第三方面、第四方面和第五方面描述的有益效果,可以参考第一方面的有益效果分析,此处不再赘述。
26.在本技术中,上述名字对银行系统中应用程序的性能测试装置或功能单元本身不构成限定,在实际实现中,银行系统中应用程序的性能测试装置或功能单元可以以其他名称出现。只要银行系统中应用程序的性能测试装置或功能单元的功能和本技术类似,属于本技术权利要求及其等同技术的范围之内。
27.本技术的这些方面或其他方面在以下的描述中会更加简明易懂。
附图说明
28.为了更清楚地说明本技术实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本技术的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
29.图1是根据本技术实施例中一种银行系统中应用程序的性能测试方法的流程示意图之一;
30.图2是根据本技术实施例中一种银行系统中应用程序的性能测试方法的流程示意图之二;
31.图3是根据本技术实施例中一种银行系统中应用程序的性能测试方法的流程示意图之三;
32.图4是根据本技术实施例中一种银行系统中应用程序的性能测试方法的流程示意图之四;
33.图5是根据本技术实施例中一种银行系统中应用程序的性能测试方法的流程示意图之五;
34.图6是根据本技术实施例中银行系统中应用程序的性能测试方法的结构示意图;
35.图7是根据本技术实施例中的测试报告示意图;
36.图8是根据本技术实施例中一种银行系统中应用程序的性能测试装置的结构示意图;
37.图9是根据本技术实施例中一种电子设备的结构示意图。
具体实施方式
38.下面将结合本技术实施例中的附图,对本技术实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本技术一部分实施例,而不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本技术保护的范围。
39.需要说明的是,本技术实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
40.为了便于清楚描述本技术实施例的技术方案,在本技术实施例中,采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分,本领域技术人员可以理解“第一”、“第二”等字样并不是在对数量或执行次序进行限定。
41.为了解决现有技术中手动重复执行测试场景对于程序进行性能测试的测试效率较低的问题,本技术提供了一种银行系统中应用程序的性能测试方法。该方法的执行主体可以是电子设备。电子设备可以是终端设备,也可以是服务器设备。示例性的,终端设备可以是手机、平板电脑、笔记本电脑、台式计算机、自助终端、智能柜台等设备,服务器可以是银行系统中的单个设备或服务器集群。电子设备可以测试银行系统中应用程序,例如银行系统中的应用程序可以是储蓄类应用程序,理财类应用程序,或者保险类应用程序等。
42.下面将结合本技术实施例中的附图,对本技术实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本技术一部分实施例,而不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本技术保护的范围。
43.图1是根据一示例性实施例示出的银行系统中应用程序的性能测试方法的流程示意图。以银行系统中应用程序的性能测试装置(以下简称性能测试装置)为执行主体进行说明,如图1所示,该方法包括步骤101至步骤104。
44.步骤101、性能测试装置根据银行系统中应用程序的至少一个测试场景,生成自动化测试脚本。
45.在本技术实施例中,银行是指依法成立的经营货币信贷业务的金融机构,在此基础上,可以理解,银行系统是指金融机构经营的所有业务构成的软件处理系统。在银行系统中包括多个应用程序,为储蓄用户提供的账户信息查询应用程序,为理财用户提供的能够对理财产品进行交易的应用程序。
46.在本技术实施例中,测试场景也可以称为测试条件或者测试可能性,即,模拟用户使用应用程序的过程。为了确保应用程序的测试覆盖率,可以获取应用程序的所有功能对应的测试场景,每个应用程序至少包括一个测试场景。
47.可以理解的是,测试场景,即模拟在特定场景下,通过事件来触发某个动作的发
生,并观察事件的最终结果,监测事件发生过程中的性能参数,从而用来发现应用程序中存在的问题。
48.可以理解的是,测试场景通常包括正常的用例场景、备选的用例场景、异常的用例场景和假定推测的用例场景。
49.在本技术实施例中,每个应用程序能够实现的功能是有限制的,因此,对于特定的应用程序而言,其对应的测试场景也是有限制的。
50.在本技术实施例中,自动化测试脚本用于模拟用户手动操作实现各个测试场景的过程。需要说明的是,自动测试脚本中对于模拟手动操作的点击、滑动、机械按键等操作,能够通过预先设置的函数实现。
51.步骤102、性能测试装置获取测试参数。
52.在本技术实施例中,测试参数包括测试起始时间,测试终止时间,预置测试执行次数,以及所述至少一个测试场景中各个测试场景的测试执行顺序。
53.在本技术实施例中,测试参数的获取来源可以为以下任一项:通过外接设备由用户输入的,也可以是通过网络传输的,还可以是预先设置的。本技术实施例对测试参数的具体来源不予限定。
54.可以理解的是,测试起始时间是指对应用程序进行测试的开始时间,测试终止时间是指对应用程序进行测试的结束时间,不论是否实际的测试执行测试是否达到测试执行次数都结束对应用程序的测试。测试执行顺序是指至少一个测试场景中各个测试场景对应的自动化测试脚本的执行顺序。
55.在本技术实施例中,通过测试参数的限制,可以能够防止一旦应用程序在测试过程中出现故障反复循环执行自动化测试脚本,能够及时停止测试。
56.步骤103、性能测试装置根据测试参数,执行自动化测试脚本,获取每个测试场景的性能参数。
57.在本技术实施例中,性能参数包括以下至少一项:响应时间、耗电量、中央处理器cpu消耗量、网络流量消耗量和渲染帧率。可以理解的是,响应时间是指执行一个操作(或一个测试场景)所需的时间,包括从发出请求开始到最后收到响应所需要的时间。耗电量是指执行一个测试场景所消耗的电量。cpu消耗量是指执行一个操作(或一个测试场景)所消耗的cpu资源。网络流量消耗量是指执行一个操作(或一个测试场景)需要传输的数据量。渲染帧率即每秒渲染的帧数,也就是指,在利用自动化测试脚本测试应用程序的过程中页面渲染的速度。
58.需要说明的是,cpu作为一种资源,主要用途在于完成运算任务,完成运算任务的能力与cpu资源消耗之间存在着可量化的制约关系,即,通过衡量c pu完成运算任务的能力来衡量cpu资源的消耗情况。cpu消耗量对应的测量维度包括处理器的利用率、cpu的时钟频率和cpu的核数。
59.在本技术实施例中,在测试参数的限定范围内,执行自动化测试参数。在执行自动化测试脚本的过程中,检测对应的性能参数。由于不同的测试场景所对应的性能参数差距较大,不适合合并处理,因此,在检测过程中可以针对每个测试场景,获取性能参数。
60.需要说明的是,由于部分性能参数与硬件的运行性能参数相关,因此,性能测试装置还可以设置开发全部的硬件运行参数的获取权限,无需通过第三方即可直接获取硬件运
行参数,能够确保性能参数的准确性。
61.步骤104、性能测试装置根据性能参数,生成性能测试报告。
62.在本技术实施例中,性能测试报告用于记录测试场景,以及测试场景对应的性能参数,其中,性能参数可以通过文字,表格或图形进行表征,图形表征方式可以为统计图或实时检测图。
63.在本技术实施例中,性能测试装置可以将生成的性能测试报告发送至预置邮箱、云计算中心或应用程序所属的网络测试平台。其中,该预置邮箱可以是应用程序开发者的邮箱,或者应用程序测试者的邮箱,或其他相关人员的邮箱。
64.在本技术实施例中,性能测试装置还可以将性能参数与预置标准参数进行比较,并根据性能参数和比较结果,生成性能测试报告,以便于提示何种性能参数需要作为改进应用程序的考虑方向。
65.在本技术实施例中,性能测试装置还可以与打印机连接,以便于打印性能测试报告。
66.由上述可知,本技术提供的银行系统中应用程序的性能测试方法,能够生成与银行系统中应用程序的测试场景对应的自动化测试脚本,结合获取的测试参数,即可实现对银行应用程序的自动性能测试,无需手动重复执行测试场景,能够提高性能测试的效率,节约人力成本,并且能够减少测试人员的主观能力对测试到的性能参数的影响,提高测试结果的准确度。
67.可选的,在本技术实施例中,如图2所示,上述步骤103中的获取每个测试场景的性能参数,还可以通过下述步骤201实现。
68.步骤201、性能测试装置根据应用程序的数据监听接口,获取每个测试场景的性能参数。
69.在本技术实施例中,对于银行系统的应用程序而言,在其中保存的数据,以及在运行过程中产生的数据,是不能被随意获取的。为了保证数据的安全性和可读性,可以在应用程序中设置数据监听接口,并通过该监听接口的监听状态,标识其他装置或程序能够通过数据监听接口监听应用程序的运行状态。
70.可以理解的是,数据监听接口仅仅能够用于监听数据,即,对数据信息的复制,不能改变应用程序内部的数据信息。并且,为了进一步保证数据的安全性,还可以对数据信息的敏感信息进行脱敏处理。
71.进一步可选的,在本技术实施例中,如图3所示,上述步骤201可以通过下述步骤301至步骤303实现。
72.步骤301、性能测试装置在应用程序的程序代码中,根据预置关键字查找数据监听接口。
73.步骤302、性能测试装置在应用程序的程序代码中,根据预置关键字查找数据监听接口。
74.步骤303、在数据监听接口开放监听权限的情况下,通过监听数据监听接口获取每个测试场景的性能参数。
75.在本技术实施例中,数据监听接口可以通过接口名称、接口参数名称、接口参数类型,接收参数数量等进行标识。为了查找数据监听接口,可以通过能够区别数据监听接口的
关键字进行查询。可以理解的是,预置关键字与应用程序相适应。
76.在本技术实施例中,在数据监听接口为可监听状态的情况下,性能测试装置通过数据监听接口获取性能参数。
77.由上述可知,在查找到监听接口后,通过强制更改监听接口的状态对银行应用程序进行监控,以使得能够获取准确的性能参数。
78.由上述可知,对于银行系统中的应用程序而言,其数据安全性尤其重要,应用程序运行过程产生的数据不能进行数据传输,因此,通过数据监听接口监听,直接获取应用程序在运行过程中的性能参数,能够提高性能参数的准确性。
79.可选的,在本技术实施例中,如图4所示,上述步骤103中的根据测试参数,执行自动化测试脚本,可以通过下述步骤401至步骤403实现。
80.步骤401、性能测试装置当前时间在测试终止时间之前,且自动化测试脚本的已执行次数小于预置测试执行次数的情况下,继续执行自动化测试脚本。
81.步骤402、性能测试装置当前时间在测试终止时间之前,且自动化测试脚本的已执行次数等于预置测试执行次数的情况下,停止执行自动化测试脚本。
82.步骤403、性能测试装置当前时间等于测试终止时间或在测试终止时间之后的情况下,停止执行自动化测试脚本。
83.在本技术实施例中,根据测试执行顺序,依次执行测试场景对应的自动化测试脚本,在执行自动化测试脚本的过程中,还需要根据预置测试执行次数和测试终止时间,确定停止执行自动化测试脚本的时机,以避免通过手动控制方式才能停止执行自动化测试脚本,以使得性能测试装置可以自动生成性能测试报告。
84.在本技术实施例中,能够控制是否停止执行自动化测试脚本对应的测试参数包括:测试终止时间和预置测试执行测试。测试终止时间是指停止执行自动化测试脚本,预置测试执行次数是指重复执行自动化测试脚本的次数。已执行次数是指执行完成自动化测试脚本的次数。
85.需要说明的是,性能测试装置在统计已执行次数时,通常采用每执行完成一次自动化测试脚本的测试,已执行次数加1。然后执行一次自动化测试脚本可能需要几分钟、十几分钟、几十分钟、甚至几小时等更长的时间,因此为了保证能够即时确定自动化测试脚本的停止执行条件,则比较当前时间与测试终止时间。
86.在本技术实施例中,从测试开始时间开始执行自动化测试脚本,然后当前时间与测试终止时间的比较结果,以及已执行次数与预置测试执行测试的比较结果,分情况判断继续执行或者停止执行自动化测试脚本。
87.在本技术实施例中,对于自动测试脚本的是否停止执行,具体可以包括以下情况:
88.在一种情况下,性能测试装置当前时间在测试终止时间之前,且自动化测试脚本的已执行次数小于预置测试执行次数的情况下,继续执行自动化测试脚本。在当前时间没有达到测试终止时间,且已执行次数小于预置测试执行次数的情况下,应用程序的当前测试状态不足以反映应用程序的实际运行状态,还需要继续执行自动化测试脚本,对应用程序继续测试。
89.在另一种情况下,性能测试装置当前时间在测试终止时间之前,且自动化测试脚本的已执行次数等于预置测试执行次数的情况下,停止执行自动化测试脚本。由于执行自
动化测试脚本过程中,不能提前确定所花费的时间,因此,测试参数中的测试终止时间可能晚于按照预置执行测试次数完成自动化测试加班的实际执行时间。为了提高测试效率,性能测试装置在当前时间未达到测试终止时间的情况下,如果自动化测试脚本的已执行次数等于预置测试执行次数,那么停止执行自动化测试脚本。
90.在再一种情况下,性能测试装置当前时间等于测试终止时间或在测试终止时间之后的情况下,停止执行自动化测试脚本。如果当前时间等于测试终止时间,无论自动化测试脚本的已执行次数是否达到预置测试测试,均停止执行自动化测试脚本。
91.由上述可知,根据测试参数中的测试终止时间和当前时间的比较结果,以及已执行测试和预置测试执行次数的比较结果,判断是否继续执行自动化测试脚本,即,判断是否完成对银行系统中应用程序的性能测试,以便于尽量缩短完成性能测试的测试时间或测试次数,以便于提高对银行应用程序的测试效率。
92.可选的,在本技术实施例中,如图5所示,上述步骤103之后,本技术实施例提供的银行系统中应用程序的性能测试方法还包括下述步骤501和步骤502。
93.步骤501、在预置测试执行次数大于预置次数阈值的情况下,性能测试装置统计每个性能参数的标准差。
94.步骤502、在标准差大于预置偏差阈值的情况下,性能测试装置生成提示信息。
95.在本技术一些实施例中,提示信息用于提示应用程序需要重新测试。
96.在本技术实施中,由于统计数据只有在数据量比较大的情况下,才能体现数据之间的统计关系,为了保证标准差能够反映性能参数的波动情况,性能测试装置设置预置次数阈值,在预置测试执行次数大于预置次数阈值的情况下,统计性能参数的标准差。
97.在本技术实施例中,由于在性能测试过程中,可能存在硬件故障、掉电等被迫中断的偶发情况,可能导致不同预置测试执行次数对应的性能参数相比差别较大,为了避免偶发情况对性能测试的影响,可以设置在测试过程中,计算性能参数的标准差。可以理解的是,标准差能反映一个数据集的离散程度,即反映是否出现偶发情况。
98.在本技术实施例中,由于偶发情况可能由于性能测试装置本身的硬件故障,供电系统故障,或者时钟故障导致的,也可以是由于应用程序本身不稳定导致的,因此,在标准差大于预置偏差阈值的情况下,生成提示信息,提示应用程序需要重新测试。并在后续人工判断是否需要重新测试。
99.在申请实施例中,在生成提示信息后,性能测试装置可以通过弹窗方式显示提示信息,并暂停执行自动化测试脚本,等待测试人员指示继续执行自动化测试脚本或重新执行自动换化测试脚本。
100.在本技术实施例中,在生成提示信息后,继续执行自动化测试脚本,但是性能测试装置可以将当前的执行测试以及标准差进行汇总,生成信息比较表,并将该信息比较表添加至性能测试报告中。
101.由上述可知,在性能测试过程中,可能存在硬件故障、掉电等被迫中断的情况,可能导致不同预置测试执行次数对应的性能参数相比差别较大,通过统计不同预置测试执行次数对应的性能参数之间的标准差,判断上述特殊情况对性能参数的影响,以便于提示重新进行性能测试。
102.由上述可知,在性能测试过程中,可能存在硬件故障、掉电等被迫中断的情况,可
能导致不同预置执行次数对应的性能参数相比差别较大,通过统计不同预置执行次数对应的性能参数之间的标准差,判断上述特殊情况对性能参数的影响,以便于提示重新进行性能测试。
103.综上所述,如图6所示,本技术提供的银行系统中应用程序的性能测试方法,包括:分析应用程序中的所有测试场景,根据所有的测试场景生成自动化测试脚本,再根据测试参数,执行自动化测试脚本,在执行自动化测试脚本的过程中,获取性能参数,最后根据性能参数生成自动测试报告。示例性的,如图7所示,以一个测试场景为例,在测试报告中包括响应时间、耗电量、中央处理器cpu消耗量、网络流量消耗量和渲染帧率。
104.以上结合图1-图7详细说明了本技术实施例提供的方法。为了实现上述功能,银行系统中应用程序的性能测试装置包含了执行各个功能相应的硬件结构和/或软件模块,这些执行各个功能相应的硬件结构和/或软件模块可以构成一个电子设备。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的算法步骤,本技术能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本技术的范围。
105.本技术实施例可以根据上述方法,示例性的对电子设备进行功能模块的划分,例如,电子设备可以包括银行系统中应用程序的性能测试装置,银行系统中应用程序的性能测试装置可以对应各个功能划分各个功能模块,也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。需要说明的是,本技术实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
106.以下,结合图8详细说明本技术实施例提供的银行系统中应用程序的性能测试装置。应理解,装置实施例的描述与方法实施例的描述相互对应,因此,未详细描述的内容可以参见上文方法实施例,为了简洁,这里不再赘述。
107.图8是根据一示例性实施例示出的一种银行系统中应用程序的性能测试装置的结构示意图,该银行系统中应用程序的性能测试装置可以用于执行图1所示的银行系统中应用程序的性能测试方法。作为一种可实现方式,该装置可以包括生成单元81、获取单元82和处理单元83;
108.生成单元81,用于根据银行系统中应用程序的至少一个测试场景,生成自动化测试脚本;例如,结合图1,生成单元81可用于执行步骤101。
109.获取单元82,用于获取测试参数,测试参数包括测试起始时间,测试终止时间,预置测试执行次数,以及至少一个测试场景中各个测试场景的测试执行顺序;例如,结合图1,获取单元82可用于执行步骤102。
110.处理单元83,用于根据获取单元82获取的测试参数,执行生成单元81生成的自动化测试脚本,获取每个测试场景的性能参数,性能参数包括以下至少一项:响应时间、耗电量、中央处理器cpu消耗量、网络流量消耗量和渲染帧率;例如,结合图1,生成单元81可用于执行步骤103。
111.生成单元81,还用于根据处理单元83得到的性能参数,生成性能测试报告。例如,
结合图1,生成单元81可用于执行步骤104。
112.可选的,处理单元83,用于:根据应用程序的数据监听接口,获取每个测试场景的性能参数。例如,结合图2,处理单元83可用于执行步骤201。
113.可选的,处理单元83,具体用于:在应用程序的程序代码中,根据预置关键字查找数据监听接口;将数据监听接口的监听状态更改为可监听状态,开放数据监听接口的监听权限;在数据监听接口开放监听权限的情况下,通过监听数据监听接口获取每个测试场景的性能参数。例如,结合图3,处理单元83可用于执行步骤301至步骤303。
114.可选的,处理单元83,具体还用于:当前时间在测试终止时间之前,且自动化测试脚本的已执行次数小于预置测试执行次数的情况下,继续执行自动化测试脚本;当前时间在测试终止时间之前,且自动化测试脚本的已执行次数等于预置测试执行次数的情况下,停止执行自动化测试脚本;当前时间等于测试终止时间或在测试终止时间之后的情况下,停止执行自动化测试脚本。例如,结合图4,处理单元83可用于执行步骤401至步骤403。
115.可选的,上述装置还包括:统计单元84;
116.统计单元84,用于处理单元83根据测试参数,执行自动化测试脚本,获取每个测试场景的性能参数之后,在预置测试执行次数大于预置次数阈值的情况下,统计每个性能参数的标准差;例如,结合图5,统计单元84可用于执行步骤501。
117.生成单元81,还用于在统计单元84统计的标准差大于预置偏差阈值的情况下,生成提示信息,提示信息用于提示应用程序需要重新测试。例如,结合图5,生成单元81可用于执行步骤502。
118.图9是根据一示例性实施例示出的一种电子设备的硬件结构示意图。该计算机设备可以包括处理器902,处理器902用于执行应用程序代码,从而实现本技术中的银行系统中应用程序的性能测试方法。
119.处理器902可以是一个中央处理器(central processing unit,cpu),微处理器,特定应用集成电路(application-specific integrated circui t,asic),或一个或多个用于控制本技术方案程序执行的集成电路。
120.如图9所示,计算机设备还可以包括存储器903。其中,存储器903用于存储执行本技术方案的应用程序代码,并由处理器902来控制执行。
121.存储器903可以是只读存储器(read-only memory,rom)或可存储静态信息和指令的其他类型的静态存储设备,随机存取存储器(random access memory,ram)或者可存储信息和指令的其他类型的动态存储设备,也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory,eeprom)、只读光盘(compact disc read-only memory,cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器903可以是独立存在,通过总线904与处理器902相连接。存储器903也可以和处理器902集成在一起。
122.如图9所示,计算机设备还可以包括通信接口901,其中,通信接口901、处理器902、存储器903可以相互耦合,例如,通过总线904相互耦合。通信接口901用于与其他设备进行信息交互,例如支持计算机设备与其他设备的信息交互。
123.需要指出的是,图9中示出的设备结构并不构成对该计算机设备的限定,除图9所示部件之外,该计算机设备可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
124.在实际实现时,生成单元81、获取单元82和处理单元83所实现的功能可以由图9所示的处理器902调用存储器903中的程序代码来实现。其具体的执行过程可参考图1所示的银行系统中应用程序的性能测试方法部分的描述,这里不再赘述。
125.本技术还提供了一种包括指令的计算机可读存储介质,计算机可读存储介质上存储有指令,当计算机可读存储介质中的指令由计算机设备的处理器执行时,使得计算机能够执行上述所示实施例提供的银行系统中应用程序的性能测试方法。例如,计算机可读存储介质可以为包括指令的存储器903,上述指令可由计算机设备的处理器902执行以完成上述方法。可选地,计算机可读存储介质可以是非临时性计算机可读存储介质,例如,非临时性计算机可读存储介质可以是rom、ram、cd-rom、磁带、软盘和光数据存储设备等。
126.在示例性的实施例中,本技术实施例还提供了一种计算机程序产品,当计算机程序产品在计算机上运行时,使得计算机实现上述实施例中的银行系统中应用程序的性能测试方法。
127.通过以上的实施方式的描述,所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全分类部或者部分功能。
128.在本技术所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个装置,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
129.作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是一个物理单元或多个物理单元,即可以位于一个地方,或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全分类部单元来实现本实施例方案的目的。
130.另外,在本技术各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
131.集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个可读取存储介质中。基于这样的理解,本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全分类部或部分可以以软件产品的形式体现出来,该软件产品存储在一个存储介质中,包括若干指令用以使得一个设备(可以是单片机,芯片等)或处理器(processor)执行本技术各个实施例方法的全分类部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
132.以上,仅为本技术的具体实施方式,但本技术的保护范围并不局限于此,任何在本技术揭露的技术范围内的变化或替换,都应涵盖在本技术的保护范围之内。因此,本技术的保护范围应以权利要求的保护范围为准。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1