LoadRunner性能测试脚本的开发是一个系统过程,是通过模拟真实用户行为,生成能够承受高压且有可信度的测试数据。
脚本录制
录制质量直接决定后续增强的可行性和测试的真实性。
协议选择:这是最容易出错的步骤。必须精确分析被测应用的技术架构。
Web应用:第一选择 Web - HTTP/HTML 协议。对于单页应用或大量使用AJAX/WebSocket的应用,需考虑 WebSocket、HTTP/2 或 TruClient 协议以获得更准确的录制。
数据库应用:如果测试存储过程或SQL性能,直接使用 ODBC、Oracle NCA 等数据库协议。
中间件/服务:对于根据Java、.NET、WCF、Rest/SOAP API的后端服务,应选择对应的专用协议进行录制,避免无关的UI层干扰。
方法:使用Protocol Advisor工具进行自动分析,并结合开发人员确定的技术栈进行证实。
录制配置和操作:
录制方式:HTML-based script 适用于大多数根据页面的Web应用,它将页面资源请求组织在相应页面上下文中;URL-based script 则录制所有原始HTTP请求,适用于非标准控件或资源加载复杂的情形。
录制选项:在 Recording Options 中,开启 Record the application startup 以保证登录流程完整。合理设置 Content Types to record 以过滤掉不必要的静态资源(如.png、.css),但需保留对性能有影响的资源(如大的.js、视频文件)。
操作规范:在录制前清空浏览器缓存。操作时应模拟典型用户行为,步骤清晰、连贯,并在操作间预留自然的间隔。录制必须包含完整的登录和注销流程。
脚本增强
录制后的原始脚本是死的,增强方法的目的是为其注入活力,使其能真实、灵活、健壮地模拟多用户并发。
参数化:解决脚本中硬编码数据的问题,是模拟不同用户行为的重要。
数据源识别:识别所有需要动态变化的数据,包括:登录用户名/密码、查询重点字、提交的表单内容(如订单号)、会话ID等。
数据文件设计:使用外部数据文件(如.dat或.csv)。数据应贴近生产环境分布,如,查询重点词的频率、用户类型的比例。对于大容量测试,数据量至少为 (虚拟用户数 * 迭代次数) + 缓冲。
更新分配方式:
唯一性:对如用户ID等重点字段,设置 Unique 和 Each iteration。
顺序/随机:常规数据可使用 Sequential 或 Random。
情形分配:在情形中设置为 Each Vuser gets a new line on allocation,保证数据不重复使用。
关联:处理服务器返回的动态值,是脚本能否成功回放的生命线。
自动关联:录制后立即执行一次“扫描关联”,使用 Scan for Correlation 功能。但此方法一般不完整。
手动关联:
录制两份相同业务流程但数据不同的脚本。
使用对比工具(如 WinDiff)比较两份脚本,找出不同之处。
分析该动态值的来源,确定其是由之前哪个请求的响应所产生。
使用 web_reg_save_param_ex 函数(功能最强、最灵活)在响应中捕获该值,存放到一个参数中。
用该参数替换后续请求中所有出现该硬编码值的地方。
方法:注意带有 Session、Token、ID、ViewState 等的响应,并检查返回值为数字或长字符串的JSON/XML节点。
事务和检查点:
事务插入:使用 lr_start_transaction 和 lr_end_transaction 将重点业务操作(如“登录”、“添加商品”、“支付”)包裹起来,来度量其响应时间。保证事务有确定的开始和结束,且结束点位于操作完成的请求之后。
检查点插入:使用 web_reg_find 或 web_reg_save_param_ex 后对参数进行判断,证实重点文本或数值是不是出现在响应中,来判断业务是不是成功,而不是仅仅HTTP请求成功。如,在登录后检查页面是不是包含“欢迎,[用户名]”字样。
思考时间和集合点:
思考时间:录制下来的 lr_think_time 代表单个用户的操作间隔。在情形中,应根据测试目的设置其处理方式:重现实际用户行为(按录制回放) 或 施加最大压力(忽略思考时间)。
集合点:在需要测试瞬间并发压力的操作前(如秒杀、抢购),插入 lr_rendezvous 函数。所有虚拟用户执行到此点时将暂停,直到指定数量的用户到达后同时释放,以制造峰值并发。
错误处理和日志:
错误处理:使用 lr_continue_on_error 设置当非重点错误发生时,脚本可以继续执行,而不是失败退出。在重点业务步骤后,应通过检查点证实结果,如果失败则使用 lr_error_message 记录详细信息并调用 lr_exit 优雅退出。
日志控制:调试时开启完整日志,但在正式负载测试时,使用 lr_set_debug_message 或运行时设置将日志级别调至最低(仅错误或严重消息),避免磁盘I/O成为性能短板。
调试
增强完成后,必须在单用户、无思考时间的方式下,于Controller中多次迭代运行脚本,保证:
无任何关联错误。
所有事务均能成功结束。
检查点证实通过。
参数化数据按预期取值。
只有当单用户脚本完全健壮后,才能将其投入多用户并发情形进行负载测试。