上表中可以分析出此邮件系统中最主要的应用是webmail,smtp,pop,其中webmail方式大约为活跃用户的70%,而其它方式则占30%,同时它还给出了平时的参数指标,与峰值的时间与指标。这样你后面的场景设计则重点会很清楚,三种方式是测试的重点,用户的分布也很清晰。从上表中还可以看出,此场景的需求人员做了大量的细致的性能分析工作,在国内这样专业的需求人员不是很多,有时候只能靠性能测试人员不断的沟通来获得必要的性能信息,同时在这个阶段也最好与有经验的架构师多沟通,了解系统可能存在的性能瓶颈,以便使自己设计的场景更有针对性。
场景设计完成之后就进入了脚本的编写,在这个阶段,主要是性能测试人员的程序能力。在这一方面,测试工具是比较多的,我所熟知的就有ACT,WAS,LoadRunner等工具。从原理看,其实都是一样的,不过如果是测试复合协议的应用,LoadRunner 则是首选,特别是在几个协议同时使用的应用,比如类似于QQ这样的应用可能会用到多个协议来进行录制。其实在录制脚本的第三个阶段也是需要跟程序员配合的,比如在录制web应用程序中,对session,cookie的处理,对业务上一些请求的处理,这些都需要程序员协助,同时他们也能够帮你确认某一阶段,用什么样的技术,选什么样的协议,从而帮助你更好的编写模拟应用场景的脚本,在这里测试人员经常会认为只要掌握了工具就行了,其实在这里需要很好的编程功底,希望大家多多关注这些脚本的编程,而不是用一两个工具。
脚本的运行与监控,还有分析结果也是重中之重,在运行时,可能会跟据不同的应用选择监控的参数,比如在程序运行中,是否有大量的IO读写,网络交互,或是线程切换,在数据库,是不是有大量的逻辑读写的操作,或是执行频度特别高的SQL执行,这些有可能你是了解的,但是如果身边有DBA的专家,与架构师,他们会更了解应用程序的性能瓶颈,会需要一些有效的监控指标,这时你在选择性能监控指标时,要多听他们的意见。特别是发现性能问题时,可能需要程序员与DBA参与进来时,再次运行场景时,更需要增加一些他们认为可能出问题的监控指标。当然作为测试人员也要了解,这些指标的异常,可能是由于应用程序那一方面不合理的,为研发提出合理的意见。