• 1. 基于LoadRunner的性能测试实践 讲师:于涌 E_mail:tony.yuy@gmail.com Blog:tester2test.cnblogs.com Msn:win_soft@163.com
  • 2. 性能测试工程师标准及挑战 一名合格性能测试工程师应有的工作目标? 性能测试工程师的挑战?
  • 3. 案例分析造成此次严重故障的原因? 如何避免此类事件的发生?
  • 4. 性能测试相关理论性能测试的概念及其主要指标 主要的性能测试工具 性能测试的主要类别
  • 5. 性能测试的概念及其主要指标性能测试 主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试 。 多线程或多进程的方式模拟多个虚拟用户
  • 6. 性能测试的概念及其主要指标性能测试主要包括 概念 系统的性能是一个很大的概念,覆盖面非常广泛,对一个软件系统而言,包括:执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可扩展性 负载测试 通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足系统的性能指标情况下,系统所能够承受的最大负载量的测试。 压力测试 通过逐步增加系统负载,测试系统性能的变化,并最终确定在什么负载条件下系统性能处于失效状态,并来获得系统能提供的最大服务级别的测试。
  • 7. 几个性能测试的实际应用场景某个产品要发布了,需要对全市的用户做集中培训 (此种情况需模拟真实用户数,如果一台机器性能不够可以考虑部署几套系统,平时不会如此多用户并发) 开发完成,总觉得某部分存在性能问题,但是又说不清楚到底是什么地方存在性能瓶颈 同一系统现可以采用两种构架Java 、.Net,决定用那个 一门户网站能够支持多少用户并发操作(注册、写博客、看照片……)
  • 8. 主要指标 主要指标 响应时间 点击数 吞吐量(单位时间从服务器获得的数据量) 并发用户 资源利用率(内存、CPU等的利用率等)
  • 9. 主要指标-用户角度响应时间(用户最重视的性能体验) 2/5/10原则(很好/还不错/忍受极限) 过长时间的等待会让客户烦躁不安 稳定性(系统的崩溃带来的直接是用户的崩溃) HTTP 500 数据库崩溃 应用服务器崩溃
  • 10. 主要指标-系统角度网络运行情况 硬件配备情况 软件的配置情况(应用服务器/数据库/系统)
  • 11. 主要指标-开发角度系统的框架设计不合理 对应用的技术不熟悉 数据库模型设计不合理 SQL语句实现性能低下 开发人员经验不足(算法、代码烦琐,浪费时间)
  • 12. 实例数据库模型设计不合理 将经常访问的数据放入一个表中(上百字段) 表与表间关系复杂 将很多二进制类型数据存放于数据库中 SQL语句性能 笛卡尔积/通配符会降低效率 ... where column in(select column from ... where ...); ... where column exists (select column from ...where ...);  用那个语句效率更高? select * from employee where salary<>3000; select * from employee where salary<3000 or salary>3000;
  • 13. 主要的性能测试工具商业 Mercury Loadrunner (集成到ide的插件) Rational Performance Tester(集成到ide的插件) WebLoad 免费 Web Application Stress Tool Application Center Test 开源 OpenSTA Jmeter(两个文档) Grinder 自行开发(针对某一个具体的软件的一部分进行测试)
  • 14. 性能测试的主要类别性能测试 负载测试 压力测试 配置测试 并发测试 容量测试 可靠性测试 失败测试
  • 15. 主要类别-性能测试性能测试是一种“正常”的测试,主要是测试正常使用时,系统是否满足要求,同时可能为了保留系统的扩展空间进行一些稍稍超出“正常”范围的测试。
  • 16. 主要类别-负载测试通过在被测系统上不断增加压力,知道性能指标。例如:响应时间超过预定指标或者某种资源已经达到饱和状态。 这种测试考验找到系统的处理极限,为系统调优提供数据。负载测试一般压力要大些。
  • 17. 主要类别-压力测试对系统不断施加压力的测试,是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能够提供的最大服务级别的测试。 例如测试一个web站点的大量的负荷下,何时系统的响应会退化或者失败。
  • 18. 举例例如 在没有负重的情况下,你跑100米需要花多少时间? 在50公斤、100公斤……等情况下,你跑100米需要花多少时间? 在一阵强风的情况下,你在负重或没有负重的情况下,跑100米需要花多少时间?
  • 19. 主要类别-配置测试配置测试主要是通过测试找倒系统各项资源的最分配原则。 Tomcat等web服务器设置(catalina.bat) -Xms  JVM初始化堆的大小  -Xmx  JVM堆的最大值 JAVA_OPTS='-Xms256m -Xmx512m'
  • 20. 主要类别-并发测试 测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题,几乎所有的性能测试都会涉及一些并发测试。
  • 21. 主要类别-容量测试 测试系统能够处理的最大会话能力。确定系统可处理同时在线的最大用户数,通常和数据库有关 。
  • 22. 主要类别-可靠性测试通过给系统加载一定的业务压力(如:Cpu资源在70-90%的使用率)的情况下,运行一段时间,检查系统是否稳定。 因为运行时间较长,通常可以测试出系统是否有内存泄漏等问题。
  • 23. 主要类别-失败测试对于有冗余备份和负载均衡的系统,通过这样的测试来检验如果系统局部发生故障用户是否能够继续使用系统,用户受到多大的影响。 如:几台机器做均衡负载,一台或几台机器垮掉后,系统能够承受的压力。
  • 24. 性能测试的实施过程实施过程 了解被测试项目的性能测试需求 分析被测试项目的性能测试需求 编写性能测试计划/测试用例 相关资源准备 脚本维护(编写程序) 执行脚本(执行程序) 分析结果 性能调优
  • 25. 实施过程-性能测试需求性能测试需求(测试的目标) 响应时间 复杂查询反应时间小于15秒 简单查询反应时间小于5秒 持续运行时间 并发用户量 资源计数器 CPU平均时间不得超过85% 可以使用内存不得低于100M
  • 26. 实施过程-分析性能测试需求分析性能测试需求 响应时间的确定(依据具体的业务) 那些是系统经常用到的业务 并发用户量的确定(可以估计或者通过日志得到) 增加、删除、查询、修改至少都要做一个脚本 可扩展的空间(1年后,用户量增加。。。)
  • 27. 实施过程-性能测试计划/用例性能测试计划/用例 覆盖测试的需求 测试的周期和风险的评估 人力资源、硬件资源、软件资源的配备 测试的手段和工具应在测试计划中有所体现 增加、删除、查询、修改至少都要做一个脚本 可扩展的空间(应依据具体的需求决定取舍测试)
  • 28. 计划/用例-覆盖测试的需求覆盖测试的需求 沟通非常重要(需求人员、客户等) 用例的设计不仅仅是一个脚本的并发,应结合具体的场景设计(如:一个场景仅仅设计用户登录并发) 参见后面例子
  • 29. 举例如: 一个进销存系统,包括登录、货物入库、订单处理、 货物出库、查询五个模块 用例设计:针对模块设计用例 场景设计: 场景1: 10%登录,10%入库,30%订单,20%出库, 30%查询 (1000 用户)—日常 场景2: 10%登录,90%查询(400 用户)—周末盘点
  • 30. 测试的周期和风险的评估测试的周期和风险的评估 时间够用吗? 需要硬件、软件都齐全吗?是否需要提前申请? 性能测试相关人员是否在其他项目组中,如果进行测试遇到其他项目组的任务比自己项目优先级高情况下,如何保证本项目的顺利进行? 需要进行相关人员的技术或者其他内容的培训吗? 需要其他人员介入吗?(如:开发人员,数据库管理员等)
  • 31. 资源的配备人力资源 测试人员(人数,天数),技术能力要求 辅助人员(大数据、访问外网。。。) 硬件资源(最好模拟用户的实际环境) 响应硬件资源申请(Cpu、内存、硬盘、网络设备。。。) 是否需要做集群方面的测试(多太机器的申请) 软件资源的配备 操作系统(winxp/win2000/liunx) 相应的版本 数据库(mysql/sql server/oracle)相应的版本 IIS/TOMCAT/WEBLOGIC相应的版本 Tomcat 5.0安装版和自解压版遇到的问题
  • 32. 测试计划中应体现的内容测试手段/方法 自行开发(谁开发,周期多长) 运用工具 运用工具 关心的指标是否可以得到 对此工具测试组人员的熟悉程度(是否需要培训,特别是开源工具) 是否可以方便快捷的根据测试报告分析定位问题
  • 33. 脚本编写注意内容增加、删除、查询、修改至少都要做一个脚本 通常一个系统采用的处理方式是一致的,所以进行一个就行了 通常可以定位一些数据库方面的问题(如:约束、锁定等)
  • 34. 可扩展的空间 通常考虑随着系统的运行,用户数会有所增加,考虑适当的扩展一下性能测试的指标 并发数 大数据量
  • 35. 实施过程-资源准备所有资源的准备应赶早不赶晚,在做大容量测试时应考虑数据的提前准备,尽量让最擅长的人做最擅长的事。 虚拟用户的操作步骤要尽量与真实用户的操作类似 数据要类似真实用户的实际使用数据,防止应用缓存技术对负载测试带来的负面影响。 在案例设计时要充分考虑到需求中用户对模块的使用频率。
  • 36. 实施过程-脚本维护/编写程序脚本维护(编写程序) 脚本录制 脚本修改/完善 脚本参数化 脚本及其数据的存储 程序的编写通常为多线程来实现(组件的运用要线程安全的)
  • 37. 实施过程-脚本执行/执行程序脚本执行(执行程序) 脚本保存(最好纳入配置管理,起码应用目录管理) 参数文件保存 结果信息保存 条件应相同 每次数据库中记录数应相同,不要在脚本运行后的基础上再进行测试-基准要相同,才可以做对比
  • 38. 影响性能的因素先后顺序 网络状况 硬件设备 系统/应用服务器/数据库配置 数据库设计和数据库访问实现 业务的程序实现
  • 39. 实施过程-分析结果分析结果 测试通常提供问题的定位(应积极和其他人员讨论) 找最擅长的人做最擅长的事 结果信息保存 分析结果的对比 有据可查、可以进行结果的对比 总结性能测试过程中出现的问题、经验 为类似项目提供依据
  • 40. 实施过程-性能调优性能调优 找最擅长的人做最擅长的事 节省时间 节省资源(自己不懂,问不懂的人等于没问,甚至更糟) 应补充多方面的知识(如:系统、数据库、应用服务器等知识) 每次应只调整一方面的配置(更好定位问题)
  • 41. 性能测试主要角色及职责项目经理 计划测试时间,监督项目进度 1、项目经理自己了解性能测试,进行合理的性能测试时间安排; 2、通过“进度”度量获得项目经验数据,据此做出正确的时间安排; 3、指定测试经理根据项目进度,安排性能测试进度; 需求分析工程师 撰写性能测试需求 1、用户可能不能明确提出性能方面的需求,需求分析工程师需要指导用户确定性能需求 A、系统用户数 B、在不用用户数量级别的并发用户数下,系统的响应时间和服务器的资源利用率; C、系统的处理能力;
  • 42. 性能测试主要角色及职责系统架构师 根据需求做出正确的系统架构的设计 开发工程师 根据架构设计的要求进行编码 测试经理 制定并组织评审性能测试计划 组织资源 跟踪项目进度 处理性能测试过程中遇到的各种问题
  • 43. 性能测试主要角色及职责高级性能测试工程师 制定性能测试方案 分析测试结果 性能测试工程师 开发Vuser Script 执行性能测试场景 提交性能测试结果 执行回归测试
  • 44. 附录:性能测试工程师技能要求熟悉软件测试基本理论 掌握软件测试常用方法 熟悉一门编程语言 熟悉一种数据库管理系统 熟悉Web服务器 熟悉常见网络协议 掌握性能测试理论 熟练使用一种性能测试工具 实际工作中需要的其他技能 注:以上技能不含性能调优
  • 45. 性能测试工具LoadRunner Loadrunner几个主要概念解析 Loadrunner的数据的参数化 Loadrunner的几个实例
  • 46. Loadrunner几个主要概念解析LoadRunner工具介绍 事务的概念 集合点的概念 检查点的概念 思考时间的概念
  • 47. LoadRunner工具介绍    LoadRunner 用虚拟用户或 Vuser 代替实际用户。Vuser 通过执行典型业务流程模拟实际用户的操作。对于 Vuser 执行的每个操作,LoadRunner 向服务器或类似的企业系统提交输入信息。增加 Vuser 的数量可以增大系统上的负载。一台工作站只能容纳一个实际用户,而多个 Vuser 可以同时运行在同一台工作站上。
  • 48. 性能测试技术概述序号类型详细描述1用户行为模拟低成本且具有可行性,模拟大量用户操作的一种技术,借助这种技术将被测试系统在测试阶段运行起来,以检测系统工作是否正常不同用户使用不同的数据多用户并发操作用户请求间的依赖关系及请求间的延时时间2性能指标监控通过上面技术模拟用户的行为,在系统运行中需要监控各项性能指标,并分析指标的正确性请求响应时间监控服务器处理能力监控服务器资源利用率监控3性能调优通过指标的监控发现系统存在的性能缺陷,利用分析工具,定位修正性能问题
  • 49. “用户行为模拟”Loadrunner实现录制脚本修改脚本参数化关联事务创建场景执行场景 VuGenController + Load Generator
  • 50. “性能指标监控”Loadrunnner实现配置服务器端监控环境添加服务器地址和计数器监控结果数据统计显示ControllerAnalysis Analysis仅提供监控数据(原始数据、统计数据和图表)和分析工具,数据分析需要人工完成
  • 51. 性能测试工具LoadRunner介绍LoadRunner简介 LoadRunner体系架构
  • 52. LoadRunner简介LoadRunner是业界标准的压力测试工具,占有全球77%的市场份额。 支持最广泛的应用标准,如WEB, RTE,Tuxedo, SAP, Oracle, Sybase, Email,Winsock等,拥有近五十种虚拟用户类型。 自动分析压力测试结果,自动产生word文档的报告,保障了结果的真实性。 界面友好,易于使用,通过图形化的操作方式使用户在最短的时间内掌握LoadRunner。
  • 53. 性能测试工具的组成部分有如下几个: 脚本生成器VuGen 压力调度和监控系统Controller 结果分析工具AnalysisLoadRunner性能测试工具架构
  • 54. Load GeneratorLoadRunner 中央控制器WebServer 1AppserverDatabaseserverLoad balancerWebServer 2脚本脚本Load Generator 1虚拟用户虚拟用户Load Generator 2
  • 55. Vuser Script录制流程创建脚本选择协议设置录制选项开始录制插入命令停止录制
  • 56. Vuser Script录制流程创建脚本选择协议设置录制选项开始录制插入命令停止录制
  • 57. Vuser Script录制流程创建脚本选择协议设置录制选项开始录制插入命令停止录制选择协议 LoadRunner针对不同的网络协议,提供对应类型的Vuser 只有选择正确的协议类型,才能正确录制脚本 从协议列表中选择被测试系统所使用的网络协议 确定系统协议方法 向开发人员询问协议类型 使用网络监控工具,如Sniffer Pro,进行协议分析来确定
  • 58. Vuser Script录制流程创建脚本选择协议设置录制选项开始录制插入命令停止录制
  • 59. Vuser Script录制流程创建脚本选择协议设置录制选项开始录制插入命令停止录制URL:输入被测试系统的URL Record into Action:默认或者使用“New…”新建Action备注:不同的协议类型此窗口不同
  • 60. Vuser Script录制流程创建脚本选择协议设置录制选项开始录制插入命令停止录制新建Action 插入事务、集合点、注释等 修改录制选项
  • 61. Vuser Script录制流程创建脚本选择协议设置录制选项开始录制插入命令停止录制左图为 VuGen自动生成的脚本
  • 62. 认识VuGen的录制原理用VuGen录制业务过程,并生成脚本运行过程录制过程
  • 63. 执行Vuser Script运行选项设置 Runtime Settings(快捷键:F4) General Options中关于脚本运行的设置 运行(Run):F5 单步执行(Run Step By Step):F10 停止(Stop):Ctrl+F5 设置/取消断点(Breakpoint):F9
  • 64. Runtime Settings
  • 65. General Options(运行)
  • 66. 事务的概念可以定义事务以度量服务器的性能。每个事务度量服务器响应指定的 Vuser 请求所用的时间。这些请求可以是简单任务(例如等待对单个查询的响应),也可以是复杂任务(例如提交多个查询和生成报告)。 要度量事务,需要插入 Vuser 函数以标记任务的开始和结束。在脚本内,可以标记的事务不受数量限制,每个事务的名称都不同。 事务是标识要一致 lr_start_transaction(” trans1”); lr_end_transaction("trans1", LR_AUTO);
  • 67. 集合点的概念要在系统上模拟较重的用户负载,需要同步各个 Vuser 以便在同一时刻执行任务。通过创建集合点,可以确保多个 Vuser 同时执行操作。当某个 Vuser 到达该集合点时,Controller 会将其保留,直到参与该集合的全部 Vuser 都到达。当满足集合条件时,Controller 将释放 Vuser。 在 Vuser 执行脚本并遇到集合点时,脚本将暂停执行,Vuser 将等待 Controller 允许继续执行。Vuser 被从集合释放后,将执行脚本中的下一个任务。 lr_rendezvous("rds1");
  • 68. 检查点的概念  因为LR只要检测到网页的响应,就认为是pass而并不管当前网页 内容的正确.在进行压力测试时,为了检查Web服务器返回的网页 是否正确,VuGen允许我们插入Text/Imag 检查点,这些检查点验 证网页上是否存在指定的Text或者Image,还可以测试在比较大的 压力测试环境中,被测的网站功能是否保持正确。
  • 69. 思考时间的概念模拟手工操作的时间 lr_think_time()
  • 70. 参数化介绍参数化目的:模拟真实的用户操作和创建现实的结果录制参数化真实用户不同的输入Vuser Script静态输入真实用户不同的输入
  • 71. 每次运行输入同一组数据都是“软件测试”参数化案例录制脚本用户操作每次运行输入不同组数据进行参数化
  • 72. 参数化步骤确定需要参数化的数据选择数据,鼠标右键选择“Replace with a parameter”Param List中设置参数值和参数更新方式
  • 73. 参数的调试在VuGen验证参数是否正确 Controller中多用户并发情况下,参数是否正确
  • 74. 参数取值方式参数取值方式介绍和演示 Sequential Unique Once
  • 75. 参数与变量定义 参数无需定义 变量需要定义 调用方法 参数需要双引号 变量直接调用,不能使用双引号,否则做字符串处理
  • 76. LoadRunner-数据参数化文本文件 数据库 Excel表格 送你一个小工具
  • 77. LoadRunner-样例程序样例程序安装过程
  • 78. 脚本调试Lr_out_message()函数 断点 单步跟踪
  • 79. 沙盘试验脚本调试 系统动态连接库 自定义动态连接库 应用注意事项
  • 80. 订票系统演示(Web)
  • 81. 订票系统演示(ODBC)
  • 82. 订票系统演示(Socket)
  • 83. 录制脚本过程登陆 得到Session ID (SessinID@1) 继续操作 服务器返回数据服务器程序用户名密码返回Session ID请求系统服务返回信息SessionID@1SessionID@1
  • 84. 回放动态数据脚本登陆 得到Session ID (SessinID@1) 继续操作 服务器返回数据服务器程序 用户名密码返回Session ID请求系统信息返回信息SessionID@2SessionID@1错误SessionID
  • 85. 关联方法VuGen: 手工关联 录制后自动关联 录制过程自动关联
  • 86. 手工关联确定要捕获数据 发现要捕获的数据的文本左右边界 脚本添加函数(web_reg_save_param) 在脚本中参数化动态数据 验证正确的执行
  • 87. 简单和复杂的关联
  • 88. (本页无文本内容)
  • 89. 场景的两种设计方式
  • 90. 集合点的3种策略
  • 91. Windows资源监控
  • 92. Oracle资源监控
  • 93. Weblogic资源监控
  • 94. LoadRunner分析结果 LoadRunner分析框架介绍 Summary图表值含义 Transaction各种图表的分析 Web BreakDown分析 合并图的应用 关联图的应用 常见的分析方法结合图表 运行结果的导出
  • 95. 分析结果-基本方法    查看现有系统中性能与负载间的关系,并确定出现响应时间显著延长的位置 “拐点”。可以确定是否需要增加资源以支持额外的用户。
  • 96. 系统瓶颈分析举例经验举例1 问题:某汽配汽修管理软件系统运行缓慢,进货、销售、查询的响应时间很长,远远超过系统性能需求!
  • 97. 系统瓶颈分析举例经验举例2 问题:某信息管理系统在研发期间,在多用户并发填写个人用户相关信息时,可用内存逐渐减少,最后,服务器端出现内存溢出情况。 解答:个人信息图片上传时未释放内存。 提问:那些情况将导致内存泄漏呢?
  • 98. 系统瓶颈分析举例经验举例3 问题:编写某汽车定损管理系统时,运行程序,出现内存很快被吃光,CPU利用率很快达到100%,最后,死机。 解答:编程过程中,SQL语句出现了“笛卡尔积”。 示例: SELECT au_fname, au_lname, pub_name FROM authors CROSS JOIN publishers ORDER BY au_lname DESC
  • 99. Summary图表值含义
  • 100. Transaction各种图表的分析
  • 101. Web BreakDown分析
  • 102. 合并图的应用
  • 103. 关联图的应用
  • 104. 1.首先查看可用内存(Memory\Available Mbytes)计数器指标。若值较小则可能有内存问题,需进一步分析。 2.注意Pages/sec、Pages Read/sec和Page Faults/sec计数器的值。 Pages/sec和Page Faults/sec的值持续很高,很可能内存问题,若Pages Read/sec的值超过5,则可判断存在内存问题。 3.根据Physical Disk计数器的值分析性能瓶颈。如果磁盘的Average Disk Queue Length计数器增加的同时Pages Read/sec并未降低,则可判断内存有问题。 内存分析方法
  • 105. 1.首先查看System\%Total Processor Time计数器的值。该值体现的是CPU的平均利用率,若超过90%,则说明存在处理器方面的瓶颈。 2.其次查看每个CPU的Processor\%User Time计数器的值。若应用服务器的%User Time值较大,可以考虑是否能通过算法优化等方法降低这个值。若数据库服务器的%User Time值较大,可考虑对数据库系统进行优化。 3.查看System\Processor Queue Length计数器的值。当该值大于CPU数量的总数+1时,说明存在处理器方面的问题。 处理器分析方法
  • 106. 1.查看%Disk Time计数器的值。该值较大,则可能存在磁盘瓶颈问题。 2.与Processor\Privileged Time合并进行分析。若%Disk Time值较大,而Processor\Privileged Time的值适中,则可判断存在磁盘问题。若Processor\Privileged Time较大,持续超过80%,则可能是内存泄漏。 3.根据Disk sec/Transfer进行分析。该值超过60ms,则磁盘存在问题。磁盘I/O分析方法
  • 107. 查看Network Interface\ Bytes Total/sec计数器的值。用Bytes Total/sec计数器的值和网络的带宽进行比较,若超过50%,则说明网络存在性能瓶颈问题。 网络分析方法
  • 108. Gis系统案例 地理信息系统(Geographic Information System,简称 GIS) 问: 1. 某企业需要做一个网上办公系统,已知现在用户数最多只有20个,用户配置的Web应用服务器的配置也不过仅仅是常用的PC机而已,今后10年以内用户数目的增长也不会超过100个用户,那么“系统能够支持200人同时在线”、“最大用户并发数要求在50个用户以上”这样的需求是不是很合理呢? 2.查询响应时间要求在3秒钟以内
  • 109. GIS系统案例分析GIS系统典型的操作
  • 110. GIS系统案例分析
  • 111. GIS系统案例分析-需求指标最大并发用户数为500
  • 112. GIS系统案例分析吞吐量    分析吞吐量的时候同样的应该注意对业务的细分工作。也就是的每个URL产生的吞吐量到底是多大。在多少用户同时点击某个按钮的时候,才能得到想要的峰值吞吐量。在本项目中,会请求图片,所以图片的大小就会造成吞吐量有很大区别的重要因素。
  • 113. GIS系统案例分析
  • 114. GIS系统案例分析业务模型
  • 115. GIS系统案例分析
  • 116. GIS系统案例分析
  • 117. GIS系统案例分析
  • 118. GIS系统案例分析
  • 119. GIS系统案例分析
  • 120. GIS系统案例分析
  • 121. GIS系统案例分析
  • 122. GIS系统案例分析瓶颈分析 在出现性能瓶颈时,经常需要参看一些相关的计数器数据,定位出所有瓶颈,所以在执行阶段最好将要监控的数据数据进行监控。 性能测试工具只能提供数据,自动生成的图表,但数据都是分散的,需要我们有效的把数据组织起来,灵活运用图表的合并功能,定位系统瓶颈。
  • 123. 项目案例(二)P2P项目完整案例
  • 124. 技巧 Vugen中自定义工具条按钮 性能测试自动化
  • 125. (本页无文本内容)
  • 126. 谢 谢!