最近看了《捉虫记——大容量Web应用性能测试与LoadRunner实战》,关于Web端测试和LoadRunner的基本使用做一点笔记,后面可以再补充学习。
强调一点,平台测试也很重要,就是指不同操作系统下的不同版本,eg:windows下不同版本对于浏览器播放插件的兼容、支持方式等都会有差别,所以这不仅仅是浏览器的测试,平台测试也很重要
Web性能测试方法(这里是广义的性能测试)
-
性能测试(这里是狭义的性能测试):
- 响应时间:业界标准——3/5/10原则,即在3s内响应并显示是”不错的“;在3-5s内响应并显示是”好的“;在5-10s内是”勉强可以接受的“;超过10s一般用户会放弃等待 2.
- 压力测试:对系统施压,是系统资源占有保持在一个事先约定的水平(eg:cup占比:75%),来检验系统的表现
- 负载测试:不断对系统增加负荷,直到找到系统不可用临界点的过程,即找到系统处理能力的极限
- 并发测试:重点关注内存泄漏、资源争用、线程控制(锁)
- 配置测试:不断调整软硬件参数,最终定位最优配置
- 可靠性测试/耐久度测试
- 尖峰冲击测试:针对某一时刻,用户数量突然暴增的情形,一般用工具LoadRunner模拟
- 失败恢复测试:针对网站突然访问故障的情形,一般采用冗余备份、负载均衡来改善
性能测试计数器
- windows下输入perfmon,查看性能计数器
-
内存泄漏:性能测试的重点
- 使用性能计数器观察数据变化
- 专业软件:CLRProfiler、Pfmon(page fault monitor)等
- 怎么判断是否产生内存泄漏?
LoadRunner的使用:VuGen + 控制器 + 分析器
-
Virtual User Generator(VuGen)虚拟用户生成器
- 录制Recording:记录一个真实用户的行为,会生成脚本。提供两个录制协议:HttP/HTML、Click and Script;录制过程要考虑Think Time,加入等待时间。
- 验证Replay:运行验证录制所得脚本。可能会出现验证失败,原因:因为录制时生成一个SessionID,录制结束,会话失效,验证播放时,使用录制时的SessionID,会被系统拒绝,导致报错。解决方案:利用关联Correlation,一般SessionID会以隐藏域的形式存在网页中,通过关联选取出此隐藏域的数据,并用脚本参数的形式存放,避免成为硬编码(“写死”),当需要使用SessionID时,用脚本参数替换即可。
- 强化Enhancements:修改脚本
- 准备负载工作:模拟真实用户,虚拟出多个用户
- 迭代:General 》 Run Logic node,同一个操作不断循环
- 并发:常用这个,通过设置不同的场景来完成,同时请求web应用的用户数量,与场景密切相关
- 完成阶段
-
控制器Controller:场景和虚拟用户组的生成和配置:设置场景并添加监控,为脚本添加函数
- Manual Scenario人工场景(自定义模式)和 Goal Oriented Scenario面向目标场景(向导模式)
- 面向目标场景的测试目标:虚拟用户数、每秒点击数、每秒事务数、每分钟访问页面数、事务响应时间
- 手工场景(先design设计再run运行):两种方式设置:用户组方式、分布百分比方式
- 集合点:测试并发操作性能,直接在录制后生成的脚本中,对应action部分,放置光标,插入集合点。集合点发挥作用,一般是规定在这个集合点上要集合多少个虚拟用户
分析器Analysis:用于分析场景运行结果:LoadRunner会自动生成测试结果概要Analysis Summary页面并自动打开分析器,分析概要包括SLA(服务质量协议,实际上是某项指标的期望值)概要、事务概要、HTTP响应概要等