性能测试基础

1、通过性能测试定位通过性能测试定位ORACLE性能瓶性能瓶颈并优化颈并优化性能测试基础性能测试基础中程在线(北京)科技有限公司内部教程注意保密电子支付流程主要介绍内容性能测试是什么（性能测试是什么（what）为什么要做性能测试（为什么要做性能测试（why）性能测试什么时候做（性能测试什么时候做（when）性能测试人力资源组成（性能测试人力资源组成（who）性能测试环境搭建（性能测试环境搭建（where）性能测试怎么做（性能测试过程）（性能测试怎么做（性能测试过程）（How）性能测试工具简介性能测试工具简介性能测试中的关键点性能测试中的关键点性能测试是什么？定义：定义：性能测试是指通过特定方式，对

2、被测系统按照一定策略施加压力，获取系统响应时间、TPS、吞吐量、资源利用率等性能指标，以期保证生产系统的性能能够满足用户需求的过程。性能测试是什么-性能测试分类 并发性能测试 负载压力测试 疲劳强度测试（稳定性测试） 高可用性测试（如RAC高可用性） 大数据量测试6性能测试是什么-性能测试分类并发性能测试 通过模拟多个并发用户同时进行某个操作，验证系统是否存在并发性的问题。如现在比较流行的秒杀、订票等。 性能测试是什么-性能测试分类 负载压力测试 负载压力测试是按照测试模型确定的测试比例，逐步增加系统压力，获得系统各项性能指标的变化情况，并获得系统的最大性能容量。8性能测试是什么-性能测试分类

3、疲劳强度测试 通常是采用系统稳定运行情况下能够支持的最大并发用户数的80%的压力持续运行一段时间，验证系统在一定压力下长时间稳定运行的能力，并检查是否有内存泄露。 性能测试是什么-性能测试分类 高可用性测试 验证在一定压力下服务器集群（如oracle rac）中的某一节点发生故障时，另一节点能自动接收全部的请求。10性能测试是什么-性能测试分类 大数据量测试 验证OLTP系统在大数据量的情况下增删改查的性能； 验证 OLAP系统在不同数据量下的系统处理情况。性能测试是什么不同角度对性能的认识 用户角度 系统管理员角度 开发人员角度性能测试是什么不同角度对性能的认识 用户角度软件对用户操作的响应

4、时间，如用户提交一个查询操作、打开一个web页面的链接等业务可用度，或者系统的服务水平如何？性能测试是什么不同角度对性能的认识 系统管理员角度 并发压力 服务器端资源使用情况 是否存在性能瓶颈 系统可扩展性如何性能测试是什么不同角度对性能的认识 开发人员角度 架构设计是否合理 数据库设计是否存在问题 代码是否需要优化，如SQL语句 如何通过调整设计和代码实现，或如何通过调整系统设置提高软件的性能表现性能测试是什么？-性能测试术语命名用户数 命名用户数是指在应用系统中注册的所有系统用户。该用户数取决于系统应用范围和业务范围，可以通过统计应用系统数据库中用户登记表获取。对于类似网站浏览式应用一般通

5、过类似系统的类比估算获得。在线用户数 在线用户数是指同时登录应用系统的用户数量该数量可通过检查系统应用与数据库连接获得在线用户数量取决于系统命名用户数。对于已投产系统，该数量一般通过系统跟踪监控获取新投产系统通过经验值进行估算。性能测试是什么？ -性能测试术语并发用户数 并发用户数是指在系统运行期间同一时刻进行业务操作的用户数量。该用户取决于用户操作习惯、业务操作间隔和单笔交易的响应时间。在性能测试中通过对Thinktime、interval等参数的设置测算。使用频度较低的应用系统并发用户数一般为在线用户数的5%左右使用频度较高的应用系统并发用户数一般为在线用户数的10%左右。交易 交易分为业

6、务层面和技术层面两种定义。业务层面交易是指完成一次完整的业务操作，例如进行一次取款、查询操作。技术层面的交易是指进行一次应用程序至应用程序、或者应用程序至数据库的系统操作。一般的一笔业务交易由多笔技术交易组成，根据业务交易的复杂度和系统应用架构的不同，其比例大致为1：2-1：10。性能测试是什么？ -性能测试术语交易处理能力（TPS与HPS） TPS 是估算应用系统性能的重要依据其意义是应用系统每秒钟处理完成的交易数量。一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS 值。依据经验，应用系统的处理能力一般要求在10-100左右。不同应用系

7、统的TPS有着十分大的差别，一般需要通过性能测试进行准确估算。HPS：Hits per Second 每秒点击次数，是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和它一般和TPS成正比关系，是B/S系统中非常重要的性能指标之一。交易响应时间 交易响应时间是指完成一笔业务交易所需的时间。传统上是指统计“端到端”的交易完成时间。简单交易的响应时间一般不得高于5秒，复杂交易的响应时间一般在20秒左右。性能测试是什么？ -性能测试术语资源使用率 资源使用率是指在系统负载运行期间，数据库服务器、应用服务器、Web服务器的CPU、内存、硬盘，外置存储，网络带宽的使用率。据经验，低于20%的使

8、用率为资源空闲，20%-60%的使用率为资源使用稳定，60%-80%的使用率表示资源使用饱和，超过80%使用率的资源使用率必须尽快进行资源调整和优化。批量处理时间 批量处理时间是指应用系统完成批量操作所消耗的时间资源批量处理完成时间取决于业务接受程度一般的批量处理时间应在数小时内完成。其他指标 在性能测试过程中还有大量与软件产品或者硬件设备相关的测算指标这些指标随着设备或者软件的不同有着较大差别随着性能测试的深入将逐渐积累汇总这些指标。性能测试是什么？ -性能测试术语响应时间：响应时间：n响应时间指的是从客户端发起一个请求开始，到客户端接收到从服响应时间指的是从客户端发起一个请求开始，到客户端

9、接收到从服务器端返回的响应结束，这个过程所耗费的时间。务器端返回的响应结束，这个过程所耗费的时间。响应时间响应时间 = 网络响应时间网络响应时间 + 应用程序响应时间应用程序响应时间性能测试是什么？ -性能测试术语吞吐量：吞吐量：为什么要做性能测试？未作性能测试失败实例为什么要做性能测试？编码阶段：防微杜渐-在编码阶段就进行开发员级的单元性能测试，尽早发现性能问题，降低缺陷修复的成本系统运营维护阶段：整体保障-当代码被修改、数据库配置改变、应用服务器配置改变等情况发生后，不仅需要功能回归测试，还要进行性能回归测试，避免由于一个小小的SQL语句缺陷而导致严重的系统性能问题性能测试什么时候做？新系

10、统上线新系统上线新系统上线后，全国推广前新系统上线后，全国推广前已有系统版本更新后或者已发现性能问题后已有系统版本更新后或者已发现性能问题后已有系统硬件更换或者升级后已有系统硬件更换或者升级后*准入评审：准入评审：在性能测试正式启动之前，需要对两个方面进行评审被测系统是否符合准入标准实施性能测试的可行性和必要性目的：考察被测系统是否具备性能测试的条件。不符合测试条件的系统会导致测试难以实施，或者测试结果严重失真勉强测试会使测试工作失去意义，浪费大量的时间、人力和软硬件资源。性能测试人力资源组成？性能测试人力资源组成？限制因素：参与人员杂技术难度高实施时间紧工作压力大需要一支层次分明、责任明确、

11、执行力强的队伍明确规定各角色人员的工作职责定期召开工作分析和工作总结会，确认阶段工作结果建立协调上级领导进行决策的机制建立协调上级领导进行强制执行的机制建立测试组工作时间共享的机制建立项目组工作过程文档/结果共享的机制性能测试环境搭建，包括被测应用系统、压力发生系统、监控系统、网络系统的配置，根据业务模型确定典型交易列表和场景。对于无法采用压力发生工具直接发起交易的性能测试，要设计开发压力传递系统，将交易压力正确、有效地加载至被测系统，包括测试脚本的开发，包括基础数据的获得、数据量评估和基础数据改造。，根据脚本参数化字段，从基础数据中抽取有效的、正确的交易发起数据。包括获得抽取规则、抽取执行和

12、数据验证，保证所有数据可以通过脚本正确执行。，保证参数化的测试脚本与基础数据结合能够在测试执行环境下正确运行。对于测试方案中确定需要通过时间戳系统记录交易在某个交易路径上的相应时间的情况，需要开发针对性的时间戳程序和相应的时间戳日志分析程序。包括挡板程序的设计、开发、部署和调试。另一方面，需要为挡板准备返回报文 性能测试环境搭建被测应用的主机和应用环境的申请、部署压力发生环境准备网络环境申请和部署监控系统准备测试人员办公网络环境性能测试怎么做？规划阶段：测试时间、测试目标、测试组织建模阶段：收集数据、性能指标、测试范围预验证阶段： 风险评估、技术验证准备阶段：测试环境、测试数据、测试脚本、测试

13、程序执行阶段：响应时间基准测试、负载测试、压力测试、容量测试、Benchmark测试、稳定性测试调优阶段：收集/分析测试结果数据、性能调优报告阶段：测试成果确认、测试目标完成确认、收集测试环境最终配置信息、测试报告编制性能测试怎么做？性能测试中的关键点获取测试需求获取测试需求确定测试目标确定测试目标进行业务调研进行业务调研建立测试模型建立测试模型测试模型数据模型业务模型监控模型风险模型执行模型性能测试中的关键点性能测试中的关键点性能测试中的关键点一、一、测试目的测试目的验证*系统架构改造后服务器的响应情况和最大处理能力；验证*系统架构改造后对系统的稳定性是否产生影响；验证*系统的负载均衡机制在

14、压力下是否正常工作；验证*系统应用的核心参数（核心处理繁忙阀值）在调整后是否对系统产生影响；验证*系统的数据库切换是否有异常性能测试中的关键点性能测试中的关键点按按8月份交月份交易量统计：易量统计：业务总交易量7697540.5券商=6571752.3，525476.2，600312券商：银行5.84：1券商=6571752.3，银行=1125788.21.13：16.83%，7.8% 业务模型：业务模型：测试模型：测试模型：（8组模型）组模型）模型比例模型比例1 1：券商端：查询:转帐1:4；转入:转出1:1; A股：B股=9：1； 高 (8月生产数据模型)模型比例模型比例2 2：券商端：查

15、询:转帐1:3；转入:转出1:1; A股：B股=9：1； 高 （6月生产数据模型）性能测试中的关键点 新开发系统性能测试需求分析（1）标识需求规格中的性能指标（2）将需求规则中的业务需求转化为性能测试需求（3）分析系统的技术架构及特点（4）分析系统的数据规模及数据增长速度（5）确定系统的测试目的及测试范围（6）分析应用系统中待测交易的业务规则（7）分析应用系统中待测交易的业务流程（8）根据待测交易的业务占比设计业务模型（9）根据业务模型设计测试模型性能测试中的关键点 已投产系统性能测试需求分析（1）收集生产运维日志或性能故障发生时的相关数据（2）分析生产环境的部署关系图（3）分析连续多天的生产

16、运维日志（4）确定高峰日期高峰时段的交易量（5）分析需求和设计文档（6）根据生产统计信息设计待测交易的业务模型（7）根据业务模型设计测试模型性能测试中的关键点 真实宕机事故分析 *银行柜面交易系统在某天突然发生宕机，造成营业中断近30多分钟，为了不影响交易，系统运维人员收集了相关日志、CORE DUMP等资料后重启应用系统。 分析思路 首先分析应用系统日志、中间件日志、数据库日志； 其次分析系统CORE DUMP文件； 第三在测试环境中复现问题。对CORE文件的初步分析结果一、事件时序重组：15:24:46 15:38:52 POSB coredump开始 POSB coredump结束 |

17、|- | | | | 15:24:55 15:27:07 15:41:52 15:47:31 系统资源异常 checkpoint开始 checkpoint结束 系统资源恢复 从上图可以看出，core dump的时间、checkpoint的时间存在一定重叠，系统资源异常的情况则持续时间较长。二、事件待查疑点：1、core dump的时间为何持续了14分钟？在测试环境（通过压力测试工具模拟了生产环境正常交易压力）多次模拟触发了POSB switch及其他进程的coredump场景，发现coredump文件的生成时间都非常快，在毫秒级完成。同时，我们看到生产环境的core文件只有36K，理论上这么小

18、的core文件dump到硬盘上不可能耗时14分钟之久。（日志来源：Daemon.log）对CORE文件的初步分析结果2、是否由coredump操作引起系统资源异常？从事件时序可以看出，core产生时间和系统资源异常基本同时发生，但由于sar -q命令看到的系统资源异常由于是几秒钟采样一次，比core产生的时间晚个几秒不能说明一定是由core dump引起。同时，core dump及checkpoint都结束之后，系统资源仍在6分钟之后才全面恢复，建议系统专家进一步分析这一段时间操作系统有何操作？在测试环境多次测试也发现，core dump时间瞬时完成，系统资源采样没有监控到系统资源的异常。三、

19、初步结论通过日志及对core文件的分析，可以确定的信息是：1、core文件是由于informix问题引起；2、informix的checkponit时间长是由于swap区耗尽引起；3、swap区的故障时间比core和checkpoint都要长；初步推断，由于informix数据库的BUG及swap区异常（可能也是由于数据库bug导致），导致了posb core，以及导致了core dump和checkpoint的时间过长。性能测试中的关键点月份业务量1 122043220432 222123221233 322143221434 422122221225 520342203426 619873

20、198737 716543165438 837643376439 92983229832101024212242121111209822098212122109821098业务调研例：年业务量调研业务调研例：年业务量调研性能测试中的关键点业务调研例：月业务量调研业务调研例：月业务量调研日期业务量日期业务量1 1112111211717134513452 2103710371818167816783 3102310231919178617864 49879872020154315435 5154315432121123112316 6102210222222109410947 712671267

21、23239879878 81098109824248998999 913761376252510221022101016751675262610341034111113241324272712131213121210991099282811121112131312561256292913451345141410981098303012741274151510211021313110121012161611211121性能测试中的关键点业务调研例：日业务量调研业务调研例：日业务量调研时间时间交易量交易量0 05 51 11 12 20 03 30 04 40 05 52 26 623237 74

22、3438 864649 997971010212212111132432412122432431313211211141416716715151431431616122122171790901818111119197 720209 921215 522223 323234 4业务名称自定义搜索自定义搜索分类搜索分类搜索新建帐户新建帐户新建订单新建订单更新订单更新订单业务量122122101101202072729 9业务配比37.65%37.65%31.17%31.17%6.17%6.17%22.22%22.22%2.78%2.78%性能测试中的关键点 性能测试方案 性能测试方案是指导性能测试

23、的纲领，在性能测试方案中应该对测试目的、测试范围、测试需求、测试策略等进行说明。性能测试中的关键点方案设计目的 反映需求 目的条理化 语言描述 指标需求范围 被测对象 测试特性 非测试特性策略 加压 挡板 执行策略指标 容量验证 指标描述模型 交易线测试 交易比例内容 测试工作内容 性能调优 回归测试计划 历程碑，完成标志 准备工作项 测试执行安排风险及变更 预期风险 应对措施 变更流程约定性能测试中的关键点 性能测试案例 性能测试案例是指导测试实施的具体说明，在性能测试案例中应该对测试场景、加压方式、具体步骤、测试数据、预期结果等进行说明。 真实测试案例分析性能测试中的关键点案例设计规范设计

24、基础 测试目的 测试内容 轮次策略 优先级别目的性 目的明确 案例集合颗粒度 执行人员 可理解 可对应监控项 监控点 监控目的预期结果 预期状况 对比测试数据 数据量敏感系统 数据类型 数据量参数配置 参数调优 挡板延时调整执行时间 场景执行 案例持续时间优先级 案例间优先级性能测试中的关键点脚本开发脚本开发脚本增强脚本增强脚本脚本开发指南开发指南AB脚本脚本/数据验证数据验证D脚本调试脚本调试Cl 编写方式编写方式l 录制方式录制方式l 事务事务l 检查点检查点l 参数化参数化l 关联关联l 集合点集合点l 注释注释l Run Time Settingl 设置断点与设置断点与单步调试单步调试l 增加增加Logl 应用系统日应用系统日志志l 常见错误常见错误l 验证函数验证函数l 返回值验返回值验证证