性能测试 Performance Testing method by Chinese Tester contact: qgn2007@gmail.com

1. 1 性能测试技术 钱茛南 qgn2007@gmail.com

2. 2 培训内容 基础篇： 1.软件性能概念 2.性能测试目的 3.性能测试类型 4.性能测试策略 5.性能测试流程 实践篇： 1.案例分析2.LoadRunner工具介绍 3.操作演示

3. 3 基础篇 软件性能概念 性能测试目的 性能测试类型 性能测试策略 性能测试流程

4. 4 一、性能测试概念----定 义

6. 软件性能的生命周期

7. 不同角度对软件性能的认识

9. 7 一、性能测试概念----软件性能的生命周期 全新系统 开发 需求 分析 概要 设计 详细 设计 编码 实现 上线 运营维护 性能基点 投资预测 性能实现 性能调整 性能 验收 性能 保持提升

11. 系统管理员角度

12. 开发人员角度一、性能测试概念--不同角度对软件能的认识

13. 9 一、性能测试概念--不同角度对软件能的认识 软件性能的认识－用户角度 软件对用户操作的响应时间，如用户提交一个查询操作、打开一个web页面的链接等 业务可用度，或者系统的服务水平如何

14. 10 一、性能测试概念---- 用户角度 所有设备运转正常! 业务排队等待 业务是否可用?? 极慢的响应时间 发怒的用户

15. 11 一、性能测试概念----系统管理员角度 并发压力 服务器端资源使用情况 是否存在性能瓶颈 系统可扩展性如何

16. 12 一、性能测试概念----开发人员角度 架构设计是否合理 数据库设计是否存在问题 代码是否需要优化，如SQL语句 如何通过调整设计和代码实现，或如何通过调整系统设置提高软件的性能表现

18. 响应时间

19. 吞吐量

21. 响应时间

22. 吞吐量

23. 资源占用率同一时刻与服务器有交互的在线用户数量 详细可以分为广义的和狭义的并发，同时做一项业务、同时做一项操作 客户端的响应时间实际可分解为客户端呈现的响应时间＋系统处理的时间 单位时间内系统处理的客户请求的数量(对于非交互式系统更多考查的内容) 网络的角度，单位时间内网络上的流量，对于web系统，可以看作请求数/s

24. 15 基础篇 软件性能概念 性能测试目的 性能测试类型 性能测试策略 性能测试流程

25. 16 为什么要进行性能测试 系统是否满足用户响应时间的要求 系统是否可以承受当前用户负载，扩展性 系统能否处理业务所需的事务数量 在负载下，系统是否稳定 用户体验是否满意

26. 17 二、性能测试----目 的 系统刚上线，处于试运行，用户需要确定当前系统是否满足验收要求 系统已经运行一段时间，如何保证能够一直具有良好的运行性能

27. 18 二、性能测试----目 的 用户提出业务操作响应时间长，如何定位问题，调整性能 系统运行一段时间后，速度变慢，如何寻找瓶颈，进而优化性能

28. 19 二、性能测试----目 的 表象--内因

29. 20 二、性能测试----目 的 据了解，官方票务网站的浏览量在第一个小时达到800万次，每秒钟从网上提交的门票申请超过20万张；票务呼叫中心热线从9点到10点的呼入量超过了200万人次。 勉强运行一小时后，被迫下线

30. 21 二、性能测试----目 的 第三阶段的售票系统运营模式，由以前的抽签式改为实时售票式，票务系统的相应功能也进行了扩充。通过测试，系统的业务逻辑、处理流程等各方面得到了优化，并获取了系统的峰值售票能力以及系统在不同用户数访问下的等待时间数据；同时，完成了在线售票打票测试以及网站混合压力测试，有效的模拟了系统的真实使用情况。

31. 22 二、性能测试----目 的

32. 23 二、性能测试----目 的 6月30日消息，据国外媒体报道，亚马逊网站周二出现大范围宕机，在超过3个小时的时间里，很多用户只能浏览到空白或部分页面。 陶宝订的奶 去哪里了？！ 一旦网站宕机，平均每秒钟将面临900美元的损失。 亚马逊股价周二下跌7.8%，远高于当天纳斯达克综合指数的跌幅。

33. 24 基础篇 软件性能概念 性能测试目的 性能测试类型 性能测试策略 性能测试流程

34. 25 三、性能测试----类 型 系统的性能是一个很大的概念，覆盖面非常广泛，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。 正因为多样性，才衍生出多种从不同角度出发的性能测试类型

35. 26 三、性能测试----类 型

36. 27 三、性能测试----类 型 容量测试 在给定的测试环境中，通过逐步增加系统负载，直到性能指标超过预定值。 特征：在限定条件下 volume capacity 拉钩上吊一百年不变吗？----能否满足设计需求 那…那好吧 100并发不超过10秒 ，不，8秒吧

37. 28 三、性能测试----类 型 骆驼背上最后一根稻草----但我想知道系统的极限，哪怕机器冒烟也不要紧 极限测试 通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，以获得系统能提供的最大服务级别的测试。 特征：监测系统极限条件下表现

38. 29 三、性能测试----类 型 并发测试 使用自动化测试工具，模拟大规模用户的同时访问行为，以验证是否存在线程分配、进程锁（latch、lock）、内存泄漏、资源争用等问题。 特征：同时(concurrent) 什么，你的业务已经提交几个小时还没被 处理----我们需要千手观音

39. 30 三、性能测试----类 型 疲劳测试（Fatigued Testing） 在最大用户数量、长时间情况下，保持一定的压力运行测试。 特征：时间长（每轮8小时） 运行三轮以上 系统也有黑眼圈？熬夜的测试

40. 吃…吃… 31 三、性能测试----类 型 大数据量测试 基于已有的一定数据基础（库中已有10万用户数据） 定时传送大量数据 （数据洪峰） 每一次与服务器交互，请求大数据量（微观 Request form 容量） 开店不怕大肚汉----今天提供自助餐

41. 32 三、性能测试----类 型 失效恢复测试是针对有冗余备份或负载均衡的系统来说，检验如果系统局部发生故障，系统灾备措施是否可以正常启动，用户是否可以继续使用。 目标：通过实施失效恢复测试，评估系统的健壮性和可恢复性。

42. 33 基础篇 软件性能概念 性能测试目的 性能测试类型 性能测试策略 性能测试流程

43. 34 四、性能测试----性能测试策略 问题的根源是什么? 在多种平台上的数百个服务器 异构系统、多种应用 数千个工作站 局域网、广域网和其它分类型的分布式 网络体系结构交错的故障点

44. 35 四、性能测试----性能测试策略 按应用部署的方式分为以下三种策略： 应用在客户端性能的测试 应用在网络性能的测试 应用在服务器端性能的测试

45. 36 四、性能测试----应用在客户端性能的测试 测试方法 实现机制

46. 37 考察客户端应用的性能，测试的入口是客户端 客户端性能测试也是并发性能测试的过程，即逐渐增加并发虚拟用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。 四、性能测试----应用在客户端测试方法

47. 38 疲劳强度 测试 负载& 压力 失效恢复测试 大数据量测试 四、性能测试----应用在客户端测试方法 客户端性能测试 各方法之间相互关联，而不是独立的

49. 41 Rational Robot －IBM 公司 包括以下几类缺省协议：SQL、HTTP、Socket、TUXEDO、IIOP、Flow Control，其它测试协议要单独购买 性能测试与功能校验相结合 报告分三种状态：new、open及run 四、性能测试----应用在客户端测试方法

50. 42 QALoad－美国Compuware(康博)公司 测试接口：DB2，DCOM，ODBC，ORACLE，NETLoad，Corba，QARun，SAP，SQLServer，Sybase，Telnet，TUXEDO，UNIFACE，WinSock，WWW 性价比较高 可以和本公司的其它产品集成 ，形成完整的系统性能测试方案 四、性能测试----应用在客户端测试方法

51. 43 Benchmark Factory－美国Quest软件公司 可以测试服务器集群的性能 基准测试 高级脚本 现在开发侧重方向为数据库性能 四、性能测试----应用在客户端测试方法

52. 44 Web Capacity Analysis Tool Version－美国Microsoft 公司 免费使用的Web应用性能测试工具 测试指标主要有： Number of hits：测试间隔内虚拟用户点击页面的总次数 Requests per second：每秒客户端的请求次数 Threads：线程数 TTFB Avg：从第一个请求发出到测试工具接收到服务器应答数据的第一个字节之间的平均时间 TTLB Avg：从第一个请求发出到测试工具接收到服务器应答数据的最后一个字节之间的平均时间 四、性能测试----应用在客户端测试方法

53. 45 SILK PERFORMER V 美国Segue 公司 在工具中融合了功能测试的方法，即内容校验 脚本采用PASCAL，资源消耗较小，支持一些底层访问 错误可精确定位 提供数据池模板，并可定制 四、性能测试----应用在客户端测试方法

54. 46 四、性能测试----应用在客户端测试方法

55. 47 测试方法 实现机制 四、性能测试----应用在客户端性能的测试

56. 48 测试工具实现机制 通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，通过可重复的、真实的测试能够彻底地度量应用的性能，确定问题所在。工程项目实践证明，其测试结果与实际情况完全符合。

57. 49 测试工具实现机制

59. 修改调试脚本

61. 52 性能测试策略 应用在客户端性能的测试 应用在网络性能的测试 应用在服务器端性能的测试

62. 53 应用在网络性能的测试 四、性能测试----应用在网络性能的测试 由于网络应用中越来越多的用到多媒体、视频以及图像传输等技术，所以网络的带宽需求非常紧张。当网络负载很轻时，信息传输的效率会比较高，当流量增长的很快时，碰撞就增加很多并使网络性能下降。网络路径的延时特性和传输速率越来越受到人们的重视。网络延时和有效带宽直接反映了路径的性能和对端主机提供的服务等级水平。

63. 54 应用在网络性能的测试 四、性能测试----应用在网络性能的测试

64. 55 四、性能测试----应用在网络性能的测试 应用网络故障分析 测试网络带宽、延时、负载和TCP端口的变化如何影响用户的响应时间 网络应用性能监控

66. 预测系统响应时间

67. 确定网络带宽需求

68. 定位应用程序和网络故障四、性能测试----应用在网络性能的测试

69. 57 应用网络故障分析 网络测试监控工具 Compuware：Network Vantage HP：Network Node Manager IBM:Tivoli 开源:Ethereal 工作原理 多个捕捉点，一个分析 捕捉点：Agent被动监听数据包来实现实时数据采集 分析：Agent Manager完成对所跟踪到的数据的分析

70. 58 gif Request [SND] [T=00:00] Protocol Layer Responses [T=01:00] gif [RCV] [T=03:00] Total RT= Internet Time + Server Time [3 sec] [estimate 1 sec] [estimate 2 sec] 计算响应时间：单点数据获取 Capture Point Internet Web Servers

71. 59 OSA OSA Capture Point Capture Point gif Request [SND] [T=00:00] gif Request [RCV] [T=00:31] Client Server T= 0.31 sec gif [SND] [T=02:11] Client Server T= 0.89 sec gif [RCV] [T=03:00] Total RT= Internet Time + Server Processing/Sending Time [3 sec] [0.89 sec + 0.31 sec] [1.8 sec + 0 sec] bandwidth effect%, Latency effect % server processing effect %, Server Sending effect % 计算响应时间：两点数据获取 Internet Web Servers

72. 60 OSA OSA OSA OSA DNS Time R Web Server R Internet R R Client Time Backend Systems Time Firewall Time Web Server Time Internet Time 典型的故障诊断策略：设置多点代理服务 在应用逻辑路径上多点数据采集 在任何两个节点间进行数据整合，测量分段的响应时间，分析应用故障。

73. 61 应用在网络性能的测试 网络应用性能监控 用户关心的问题： 分析关键应用程序的性能 定位问题的根源是在客户端、服务器、应用程序还是网络 哪些应用程序占用大量带宽 哪些用户产生了最大的网络流量。

74. 62 应用在网络性能的测试 网络应用性能监控 测试目标 在系统试运行之后，我们需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争

76. 64 网络应用性能监控体系结构

77. 65 性能测试策略 应用在客户端性能的测试 应用在网络性能的测试 应用在服务器端性能的测试

78. 66 服务器管理面临的风险 一般系统具有多台服务器，有不同服务器类型，管理起来很困难 服务器的性能问题很难诊断 没有发现的简单问题可能引起许多用户的巨大问题 四、性能测试----应用在服务器上性能的测试

79. 67 测试关键点 资源的占用情况 数据库性能 故障报警 四、性能测试----应用在服务器上性能的测试

80. 68 测试实现：利用工具监控服务器端性能 利用工具监控的优点： 减少故障诊断和分析时间 减少手工定位的时间和避免误诊 在问题发生前定位故障 验证可达到的性能水平和服务水平协议 持续的服务器、数据库和应用性能和可用性监控 故障诊断和恢复: 自动报警、故障恢复程序、故障恢复信息。 服务器、应用可用性和性能报告 四、性能测试----应用在服务器上性能的测试

81. 69 监控内容 对服务器操作系统的监控 对数据库的监控 对中间件的监控 四、性能测试----应用在服务器上性能的测试

82. 70 对服务器操作系统的监控内容如下 ： CPU 内存& SWAP 磁盘管理 网络 文件系统 活动的进程 四、性能测试----应用在服务器上性能的测试

83. 71 操作系统监控方法 监控工具 spotslight、tivoli、openview 操作系统本身自带命令 如：vmstat ,iostat,netstat 四、性能测试----应用在服务器上性能的测试

84. 72 spotslight使用方法： 一。下载 http://www.quest.com/spotlight-on-windows/ 四、性能测试----应用在服务器上性能的测试

85. 73 spotslight使用方法： 二。安装 四、性能测试----应用在服务器上性能的测试

86. 74 spotslight使用方法： 二。安装 四、性能测试----应用在服务器上性能的测试

87. 75 spotslight使用方法： 三。使用 四、性能测试----应用在服务器上性能的测试

88. 76 spotslight使用方法： 三。使用 四、性能测试----应用在服务器上性能的测试

89. 77 spotslight使用方法： 三。使用 四、性能测试----应用在服务器上性能的测试

90. 78 spotslight使用方法： 三。使用 四、性能测试----应用在服务器上性能的测试

91. 79 spotslight使用方法： 三。使用 四、性能测试----应用在服务器上性能的测试

92. 80 spotslight使用方法： 三。使用 进程情况 四、性能测试----应用在服务器上性能的测试

93. 81 spotslight使用方法： 三。使用 CPU情况 四、性能测试----应用在服务器上性能的测试

94. 82 spotslight使用方法： 三。使用 内存情况 四、性能测试----应用在服务器上性能的测试

95. 83 spotslight使用方法： 三。使用 磁盘占用率 四、性能测试----应用在服务器上性能的测试

96. 84 spotslight使用方法： 三。使用简洁，上手快速 但对系统资源占用高 四、性能测试----应用在服务器上性能的测试

97. 85 另一种选择Procmon.exe： 三。对系统资源占用相对较低 四、性能测试----应用在服务器上性能的测试

98. 86 vmstat

99. 87 iostat

100. 88 四、性能测试----应用在服务器上性能的测试 对数据库的监控内容如下 ： 监控数据库系统中关键的资源 监测读写页面的使用情况 监控超出共享内存缓冲区的操作数 监测上一轮询期间作业等待缓冲区的时间 跟踪共享内存中物理日志和逻辑日志的缓冲区的使用率 监控磁盘的数据块使用情况以及被频繁读写的热点区域 监控用户事务或者表空间监控事务日志 监控数据库锁资源 监测关键业务的数据表的表空间增长 监控SQL执行情况

101. 89 性能测试策略小结 应用在客户端性能的测试 应用在网络性能的测试 应用在服务器端性能的测试

102. 90 基础篇 性能测试概念 性能测试目的 性能测试类型 性能测试策略 性能测试流程

103. 91 疲劳强调 测试 大数据量 测试 失效恢复测试 负载&压力 测试 四、性能测试----性能测试流程 测试流程 测试执行 测试设计与开发 测试需求&计划 结果分析，报告

106. 测试调试开发

107. 负载压力场景设计

108. 结果分析

109. 问题定位

111. 部署测试场景

112. 执行测试3.测试执行

114. 测试用例也必须覆盖所有的测试需求

117. 尽量模拟真实使用情况(请看附件中8020__并发模式)

118. 96 测试需求分析 测试强度估算 80～20原理：每个工作日中80％的业务在20％的时间内完成。 举例： 每年业务量集中在8个月，每个月20个工作日，每个工作日8小时 即每天80%的业务在1.6小时完成 去年全年处理业务约100万笔，其中15％的业务处理中每笔业务需对应用服务器提交7次请求；其中70％的业务处理中每笔业务需对应用服务器提交5次请求；其余15％的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15％，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。

119. 97 测试需求分析 测试强度估算 每年总的请求数为： (100x15%x7+100x70%x5+100x15%x3)x2=1000万次/年 每天请求数为：1000/160=6.25万次/天 每秒请求数为：(62500x80%)/(8x20%x3600)=8.68次/秒 即服务器处理请求的能力应达到9次/秒

120. 98 测试需求分析

121. 99 测试需求分析 测试需求分析方法 充分分析系统有价值的信息 任务分布图 交易混合图 用户概况分析

122. 100 测试需求分析 任务分布图 有哪些交易任务 在一天的某些特定时刻系统都有哪些主要操作

123. 101

124. 102 测试需求分析 交易混合图 高峰期有哪些操作？ 中间件操作有多少？数据库操作有多少？ 如果任务失败，那么商业风险有多少？

125. 103 交易名称 日常业务 高峰期业务 Web服务器负载 数据库服务器 负载 风险 登陆 70/hr 210/hr 高 低 大 开一个 新帐号 10/hr 15/hr 中等 中等 小 生成订单 130/hr 180/hr 中等 中等 中 更新订单 20/hr 30/hr 中等 中等 大 发货 40/hr 90/hr 中等 高 大 选择的标准： 高吞吐量 高数据库I/O 高商业风险

126. 104 测试需求分析 用户概况分析 哪些任务是每个用户都要执行的? 针对不同角色的用户，他们的任务是什么? 针对每个用户，不同任务的比例如何?

127. 105 测试需求分析 定票窗口 经营部门 经理 输入订单 100 25 更新订单 50 10 计算飞行里程 70 5 计算销售 8 任务频率

128. 106 测试需求分析 请看附件中需求分析例子 并发规模： 一。从数据规模角度考虑 二。任务分布情况考虑

129. 107 测试计划制定 要素： 测试案例 测试成员 测试时间 测试环境

130. 108 测试方案制定 设计测试案例 好的案例具有以下几个性质： 有效性：可以发现缺陷 可重用性：可以重复使用的案例，保证测试的一致性 可维护性：当测试环境、测试数据发生变化后，测试案例经过简单维护，可以继续使用

131. 109 测试方案制定—测试案例

132. 110 测试方案制定—测试案例 请看性能测试用例

133. 111 测试计划制定 要素： 测试目标 测试案例 测试成员 测试时间 测试环境

134. 112 测试方案制定—测试成员

135. 113 测试方案制定—测试成员

136. 114 测试计划制定 要素： 测试目标 测试案例 测试成员 测试时间 测试环境

137. 115 测试方案制定—测试时间

138. 116 测试方案制定—测试时间 请看附件中：参数化数据--需求和数据__总中心A系统压力测试计划：5.压力测试时间安排

139. 117 测试计划制定 要素： 测试目标 测试案例 测试成员 测试时间 测试环境

140. 118 测试方案制定—测试环境

141. 119 测试方案制定—测试环境 测试环境的基本原则 符合软件运行的最低要求，不一定选择将要部署的环境 选用比较普及的操作系统和软件平台 营造相对简单、独立的测试环境 无毒的环境

143. 保证达到测试执行的技术需求

145. 122 测试方案制定—测试环境 好的测试环境的标准： 独立的网络环境（防止network collisions） 局域网（LAN）（100M） 不要让网络成为瓶颈 （网线质量、switcher）

146. 123 测试方案制定—测试环境

147. 124 测试方案制定—测试环境 基本量（已有用户，使业务可以正常进行） 参数池（运行中会使用大量的唯一值） 仿真度（不是使用你系统的用户都是张三李四，不是所有人的电话都是66666666） 数据分布、密度 测试数据

148. 125 测试方案制定—测试环境 怎样准备测试数据 手工操作方法（Excel、sql） 利用工具的自动化方法

149. 126 测试方案制定—测试环境 依靠工具准备测试数据的方法 自动生成测试数据 测试数据管理

150. 127 测试方案制定—测试环境 自动生成测试数据 利用数据库测试数据自动生成工具—TESTBytes，确定需要生成的数据类型和生成规则，通过与数据库的连接来自动生成数百万行的测试数据 利用LoadRunner的黑盒方法

151. 128 测试方案制定—测试环境 请看参数化数据

152. 129 测试计划制定－小结 要素： 测试案例 测试成员 测试时间 测试环境

155. 测试调试开发

156. 负载压力场景设计

157. 结果分析

158. 问题定位

160. 部署测试场景

161. 执行测试3.测试执行

162. 131 测试设计&开发 开发测试工具 利用成熟的商业测试工具 LoadRunner, SilkPerformer

163. 132 测试设计&开发－测试脚本录制调试 以测试工具Load Runner为例

165. 测试指标的目标

169. 测试调试开发

170. 负载压力场景设计

171. 结果分析

172. 问题定位

174. 部署测试场景

175. 执行测试3.测试执行

176. 136 测试执行 搭建测试环境 1 2 执行测试和记录结果 3 部署测试场景

177. 137 LR使用----5.监控指标

178. 138 LR使用----5.CPU指标

179. 139 LR使用----5.内存指标

180. 140 LR使用----5.硬盘指标

181. 141 测试执行－性能指标和资源监控设置 请看监控指标解释 Windows部分

184. 测试调试开发

185. 负载压力场景设计

186. 结果分析

187. 问题定位

189. 部署测试场景

190. 执行测试3.测试执行

191. 143 结果分析&报告 对测试结果进行分析，依据测试的目标给出测试结论 结果分析（借助工具分析图） 问题定位 测试报告与评估

192. 144

193. 145

194. 146

195. 147 一、性能测试----特 性

196. 148 性能测试是富有挑战性的 一、系统构成是复杂的 系统 由客户端、 网络、 防火墙、 负载均衡器、We b服务器、 应用服务器 (中间件 )、 数据库服务器等环节组成。 每个环节都是一个复杂的子系统

197. 149 性能测试是富有挑战性的 在多种平台上的数百个服务器 异构系统、多种应用 数千个工作站 局域网、广域网和其他分类型的分布式网络体系结构 交错的故障点

198. 150 性能测试是富有挑战性的 二、寻找性能问题的起因是复杂的 功能测试：黑暗中寻找黑猫（需要灵感） 性能测试：白猫中寻找黑猫的爸爸（需要推理） 找寻推断，追本溯源 由表象到内因

199. 151 一、性能测试----特 性

200. 152 “拿来主义”不适用 系统硬件的异构性 业务的差异性 需求的变化性 测试角度（Stakeholder）多样性 。。。 。。

201. 153 Q&A