首页 » 漏洞 » 服务测试-性能测试(4.6)

服务测试-性能测试(4.6)

 

今天谈下在接口服务测试中的性能测试话题。对于接口的性能测试,相当来说比一个完整业务系统功能的性能测试简单,但是对于性能测试场景的识别,性能测试方案的设计仍然相当重要。


对于接口性能测试,首先需要分析性能测试场景,主要是实际的生产环境所面临的基础设施和软硬件环境是如何的?其中包括了硬件设施,网络带宽必须考虑;同时你还需要考虑基于业务场景分析出来的对应到接口层面的接口服务高峰时期的并发访问量是如何的?接口传输的数据量又是如何的?

这些都必须纳入性能测试场景分析,即性能测试需要回答的问题是,在当前的基础设施,硬件和网络环境下,在业务高峰期,接口服务本身的性能能否满足性能要求。而在基础设施环境确定后,对于性能影响最大的两个因素就是接口服务调用的并发量和接口服务传输消息报文的数据量大小。

当然对于网络环境也必须考虑进去,网络带宽和延迟往往也对接口性能有关键影响,特别是在高峰事情业务系统共享网络带宽的情况下,由于网络I/O原因同样引起性能问题。

性能测试方案设计

对于接口性能测试方案的设计相当来说比较简单,首先还是最简单的单一服务的接口性能测试,对于这种测试则只需要基于并发次数和接口服务消息报文数据量两者进行组合构造测试用例即可,比如:

a. 并发次数:50次,100次,200次,500次

b. 报文数据量:5K,50K,100K,500K

如果我们基于性能测试场景分析得出的最大并发量在500次,最大的报文在500K,那么我们就可以基于上面的场景分析,组合16种测试用例并准备测试数据进行接口性能测试即可。

在前面也谈到过,在性能测试的时候我们还可以模拟和控制带宽,如果实际的业务场景中带宽不确定,我们还可以模拟不同的带宽,进行进一步的组合构建性能测试用例,以分析不同带宽情况下对接口服务性能的影响。

上面只是单一接口服务的性能测试,而实际性能测试往往涉及到多个服务的并发调用,因此为了尽量的模拟真实场景,我们还需要进一步做组合接口服务调用场景下的性能测试,具体组合可以考虑:

a. 将查询服务和导入服务,异步调用和同步调用服务多种类型服务进行组合。

b. 将并发量大而实际数据量小和并发量小而实际传输数据量大的服务进行组合验证。

c. 将执行时间较长的服务和执行时间短的服务进行组合验证。

具体应该如何设计组合场景,我们还是应该根据实际的业务场景需求分析,得出可行的服务性能测试组合,在这种组合测试中,我们对多个组合的服务同时并发执行,但是每个服务都设置独立的服务并发数和调用数据量以进一步模拟真实场景。

在ESB集成平台项目实施过程中,对于接口服务的性能测试还需要注意为了真实的发现接口服务的性能问题,我们往往还需要对业务系统原生提供服务接口,以及已经在ESB进行封装后的服务接口分别进行性能测试。只有这样当测试发现服务性能问题的时候,我们才清楚具体原因究竟在业务系统还是ESB总线平台。

性能测试工具

对于性能测试的工具选择,如果是简单的接口服务性能测试,选择SoapUI就可以完成性能测试,如果是较为复杂特别是组合场景下的性能测试,则可以选择LoadRunner工具进行性能测试。如果是要测试上万并发这种场景,往往还需要借助Jmeter这种轻量大并发压力测试工具进行。

基于SOA的性能测试第一阶段是基准测试,基准测试是用来确定被测应用程序是否存在性能衰退,并且收集可重复性能测试结果以作为性能基准。基准测试的最好方法是每次测试只改变一个参数。基准测试包括了相应时间驱动的测试和吞吐量驱动的测试。

对于响应时间,可以看到当虚拟用户的并发数不断增加的时候,服务调用响应时间也不断增长,那么我们就需要观察在哪个临界点会出现响应数据大幅增长的情况?那么这个点很可能就是系统资源出现了瓶颈,或者说当前的软硬件环境能够支撑的最大并发数点。

对于吞吐量测试,我们比较关注的一个指标就是TPS数据,即单位时间内能够达到的服务请求事务数,可以看到当我们不断增加压力的时候,TPS会先开始增长,但是到了一定阶段,即使再增加并发用户并发量,实际的TPS数值已经很难再上去,那么就说明表明被测应用在测试的硬件环境下达到处理事务的最高能力。

所有引起性能的原因,或者是当前的基础设施硬件和网络环境原因,或者就是软件实现本身的性能有问题,因此对于性能测试问题分析需要从这两方面展开。

原文链接:服务测试-性能测试(4.6),转载请注明来源!

0