基于 STAF/STAX + Autoit 的性能测试方案实现桌面云扩展性测(5)

发表于:2012-03-16来源:IBM作者:董文涛点击数: 标签:性能测试
采用其他免费或者 开源 的框架(如 LiveGraph 等),实现数据的实时动态展现,便于迅速做性能情况做初步评估,在此不做进一步展开。 远程调试 dbgview 的使

  采用其他免费或者开源的框架(如 LiveGraph 等),实现数据的实时动态展现,便于迅速做性能情况做初步评估,在此不做进一步展开。

  远程调试 dbgview 的使用(略)

  编写多种用户类型的组合的 workload 配置文件

  为模拟真实世界中,多种用户类型并存的情况,需要编写的组合型的 XML 文件实现,例如可以抽象出三种用户类型:Light, moderate, heavy,采用 N+3 的测试方法,即从总数为 N 的虚拟用户中选取 3 个用户单独监测其上运行事务的响应,这么做的好处在于提高测试数据的真实度,该测试场景下假定所有的用户的系统配置一样,所以可以通过抽样的方式,从 N 个系统中取三个样本,来代表整体的情况,并且,这么做可以大大程度的减少测试程序本身对系统的 CPU 的占用,因为监测程序在校对程序界面的变化的延迟是通过静态图片比对的方式,比对过程会占用一部分系统 CPU 资源。下面的范例 XML 文件基于灵活性考虑,把模拟每种用户类型行为的接口制作成两套,一套是监测程序响应延迟的(带静态图片比对),一套是不监测的。在实际测试中可以根据需要进行取舍或者整合。

  测试执行

  基准测试

  1. 系统启动时长的基准测试

  重用原来的 workload 框架,并做部分修改,只需要使用 STAF 的'service Ping'命令就可以准确衡量所有机器从开机到所有服务运行起来的时间间隔,这是一个很好的实践:

  XML 脚本实现,如下清单所示:

  清单 5. XML 测试机器启动的示例

				
 <sequence> 
               <message>'VerifyFunSample: ping test on %s' %(machine)</message> 

 <!-- <timer duration="'10s'"> --> 
               <loop 
                until="RC == 0"> 
                  <process 
                   name="'service Ping'"> 
                     <location>'local'</location> 

                     <command 
                      mode="'shell'">'STAF %s ping ping' % machine</command> 

                     <focus 
                      mode="'minimized'" /> 
                  </process> 
               </loop> 

 <!--  </timer> --> 
               <if 
                expr="RC != 0"> 
                  <message>'service Ping of machine %s failed' % machine</message> 

                  <else> 
                  <message>'service Ping of machine %s successfully' % machine</message>
                  </else> 
               </if> 
            </sequence> 

  运行 STAX 脚本,填写所需的测试参数

  执行 STAX 任务

  启动时间的获取 (获得系统开机后到所有的服务都已经运行的时长)

  先同时启动多台虚拟机

  并且同时运行 STAX 脚本,测试便进行起来:

  图 11. STAX 启动时间测试界面

图 11. STAX 启动时间测试界面

  等测试结束,就可以把 Messages 中的内容复制到 Excel 中利用简单的时间戳相减(每个机器启动 successfully 对应的 Timestamp- 脚本启动的时间)既可以得到每个机器准确的启动时间。

  扩展测试中的用户体验测试

  单用户类型的扩展性测试

  以 heavy 用户类型为例,采用客观的评测方法,针对 heavy 类型中的‘ 1 ’(监控响应时间)的用户,采用 XML 的 process-action,在视频播放开始后,延迟适当的时间进行屏幕录制,并且设置录制的时长,然后通过录制的效果作为客观评估的依据。屏幕录制只是记录多媒体播放效果的一种记录方法,亦也可以采用其他的方法。

  混合用户类型的并发测试

  以 N+3 的类型为例,运行效果如下图所示:

  图 12. 混合用户的负载测试界面

图 12. 混合用户的负载测试界面

  测试结果示例

  启动时间

  对脚本进行扩展就可以满足不同的测试需求,比如启动不同数目的虚拟用户在不同的场景下面的启动时间的图例:

  图 13. 启动时间度量结果图例

图 13. 启动时间度量结果图例

  GUI 程序响应延迟

  操作不同的应用程序的响应时间图例:

  图 14. GUI 程序响应延迟度量结果

图 14. GUI 程序响应延迟度量结果

  播放不同的媒体文件的效果评测图例:

  图 15. 媒体文件播放效果度量

图 15. 媒体文件播放效果度量

  改进和建议

  STAX 的在大规模的并发任务和监控(并发超过 100),对 STAX 所运行的机器的 CPU 消耗很高,因而对硬件资源要求较高,建议运行用多台 STAX 和 STAF 分担负载,在大规模的并发测试场景,本方案未经验证,在做性能测试方案的选型的时候应予以评估和验证。

原文转自:http://www.ltesting.net