性能测试管理ppt课件

.,性能测试管理,培训教程,课题内容：性能测试管理主讲人：曾祥鹏,.,大纲,第一章：性能测试启动第二章：性能测试建模第三章：性能测试计划第四章：性能测试准备第五章：性能测试执行第六章：性能测试分析,.,第一章性能测试启动,第一节：技术调研第二节：准入评审第三节：测试启动,.,技术调研,在系统代码开发完成之后和功能测试完成之前测试组织派专人采用现场或非现场的方式调研以下内容被测系统的技术实现与其它系统接口关系及其技术实现本系统测试数据与相关系统测试数据的关系目的：初步确定测试技术方案及相关的测试数据准备方案,.,技术调研-实例,XXX系统技术架构WebSphere+S1+DB2BrowserBaseClient使用EAI/ECTIP/UDI作为外部系统接口,.,技术调研-实例,初步测试技术方案使用LoadRunner作为压力测试工具使用Web/HTTP协议开发测试脚本使用SpotlightforDB2监控数据库使用DiagnosticforJ2EE监控应用服务使用ServerMonitor监控操作系统资源EAI/ECTIP实时交易需要开发相关挡板程序初步测试数据准备方案UDI需事先准备全量数据,.,准入评审,在性能测试正式启动之前，需要对两个方面进行评审被测系统是否符合准入标准实施性能测试的可行性和必要性目的：考察被测系统是否具备性能测试的条件。不符合测试条件的系统会导致测试难以实施，或者测试结果严重失真勉强测试会使测试工作失去意义，浪费大量的时间、人力和软硬件资源。,.,测试启动,确定测试的负责人和组织结构。明确测试的总体目标和范围确认测试所需资源的情况测试主管单位要下发相关调查表，获取业务方或开发方对性能测试的需求信息：典型交易列表性能测试需求性能指标测试环境数据量要求,注意：调查表由实施测试的性能测试组下发给业务方或者开发方，会有什么问题吗？这里为什么说要由测试主管单位下发？,.,第二章性能测试建模,第一节：为什么需要建模第二节：性能测试模型的两种形式第三节：用户行为模型第四节：系统业务模型第五节：性能测试模型的工具实现,.,为什么需要建模,真实模拟实际系统运行状况所有性能测试工作都以此模型作为依据合理控制项目周期,.,并发量与每秒交易量(TPS)的联系,性能测试误区并发量越大系统压力越大并发量与每秒交易量的联系并发量用于考察系统的用户支撑能力每秒交易量才是衡量大多数系统的真实压力的正确指标随着并发量的增加TPS并不是线性增长的,.,性能测试模型的两种形式,用户行为模型描述高峰时期用户行为特点(瞬时模型)优点：对与大多数性能测试工具而言实现简单缺点：用户行为较难统计分析系统业务模型描述高峰时期系统业务特点(时段模型)优点：相对于用户行为模型而言较容易获得缺点：设置复杂，需要较高的工具技能,.,建立性能测试模型-用户行为模型,用户行为模型高峰日高峰时段高峰时段用户行为统计,.,建立性能测试模型-系统业务模型,系统业务模型高峰月高峰日高峰时段高峰时段业务统计,.,建立性能测试模型-系统业务模型,.,建立性能测试模型-系统业务模型,.,建立性能测试模型-系统业务模型,.,性能测试模型的工具实现,用户行为模型的工具实现模型建立困难，实现容易。系统业务模型的工具实现主流模型，详细讨论。,.,系统业务模型的工具实现,用户支撑能力测试/用户体验测试调研用户使用方式，确定ThinkTime基准测试确定各交易基准执行时间调整Interval时间风险系统处理能力测试调研系统处理量需求基准测试确定各交易基准执行时间调整Interval时间风险,.,课堂讨论-新系统上线，且无历史数据参考如何建立性能测试模型：分组讨论，收集意见不做辅导,10分钟,.,第三章性能测试计划,第一节：测试计划第二节：关键文档第三节：风险评估,.,测试计划,测试经理根据测试启动阶段得到的测试模型编写测试方案和测试计划用于指导整个测试实施过程,.,关键文档,性能测试方案性能测试计划典型交易列表性能测试需求表,.,性能测试方案关键点,测试目的（清晰明确，没有歧义）。测试范围（交易列表，路径图等）。性能指标（要可测量，量化指标最好给出具体数值，无法定量的给出说明）。数据量（给出具体数值和参考依据，无法定量的给出说明）。测试环境（分为网络、硬件、软件和拓扑图）。测试工具和监控工具及其相关环境。风险控制（风险描述、严重程度、规避办法、负责人等明确清晰）测试策略（符合项目实际情况，具有可执行性）挡板（根据情况可裁减）时间戳（根据情况可裁减）角色分工（无遗漏，职责描述清楚）测试执行过程等（符合项目实际情况，没有遗漏，具备可执行性）,.,性能测试计划关键点,阶段任务描述（阶段，子阶段划分清晰；阶段关联关系明确；里程碑定义准确）时间安排（满足项目预期周期要求，具有弹性）文档定义（各阶段输入输出文档定义清晰）所需资源（人力资源，资金资源等符合项目要求）,.,典型交易列表关键点,典型交易选取合理（符合关键业务，操作频繁，业务量大，覆盖所有测试需求路径，对性能影响大的原则）相关交易码准确（配置管理最新版本）业务约束和逻辑约束明确给出，无遗漏和错误典型交易数量选取合适，能满足并发分配需求（例如，不能选50个交易，要求测30个并发）具备可测试性（能事先手工验证）,.,测试环境需求表关键点,符合项目实际测试需求情况各项资源需求填写准确，无遗漏，错误或歧义具备可实现性,.,风险评估,可能影响测试过程的因素可能影响测试结果的因素规避方法,.,课堂讨论-性能测试会遇到哪些风险：分组讨论，收集意见不做辅导,10分钟,.,实例,XXX项目性能测试方案XXX项目性能测试计划XXX项目典型交易列表XXX项目环境需求表,.,第四章性能测试准备,第一节：测试环境准备第二节：压力发生环境准备第三节：测试脚本准备及其预验证第四节：测试数据准备第五节：测试工具和监控工具准备第六节：测试场景设计第七节：挡板和时间戳第八节：执行确认,.,测试准备,测试主管单位根据测试方案和计划中所列工作项进行测试准备活动，确保测试可以执行。包括以下工作：测试环境准备，包括被测应用的主机和应用环境的申请、部署，压力发生环境准备，监控系统准备和网络环境申请和部署，提供符合测试需求可使用的测试环境环境配置，包括被测应用系统、压力发生系统、监控系统、网络系统的配置测试场景准备，根据业务模型确定典型交易列表和场景压力发生系统准备。对于无法采用压力发生工具直接发起交易的性能测试，需要设计开发压力传递系统，将交易压力正确、有效地加载至被测系统测试脚本录制，包括测试脚本的开发测试基础数据准备，包括基础数据的获得、数据量评估和基础数据改造。参数化数据抽取，根据脚本参数化字段，从基础数据中抽取有效的、正确的交易发起数据。包括获得抽取规则、抽取执行和数据验证，保证所有数据可以通过脚本正确执行。脚本预验证，保证参数化的测试脚本与基础数据结合能够在测试执行环境下正确运行时间戳系统准备。对于测试方案中确定需要通过时间戳系统记录交易在某个交易路径上的相应时间的情况，需要开发针对性的时间戳程序和相应的时间戳日志分析程序。挡板系统准备。包括挡板程序的设计、开发、部署和调试。另一方面，需要为挡板准备返回报文,.,测试环境准备,参测项目组：提供测试环境需求信息被测系统的部署和配置测试主管单位：明确测试所需环境协调各参测项目组和环境组完成环境准备工作,.,压力发生环境准备,参测项目组：提供环境配置信息（例如，jdk的版本、加密/解密程序版本、路径）测试主管单位：明确软硬件环境需求协调相关方面完成压力发生环境的软硬件条件准备,.,测试脚本准备及其预验证,参测项目组：提供脚本录制时所需数据解决录制过程中出现的系统问题。测试主管单位：录制脚本并调试，确保脚本能在测试环境中正确运行。脚本是否能够真实模拟实际操作ThinkTimeTransaction参数化集合点关联检查点RuntimeSettings脚本是否存在并发问题2X2验证,.,测试数据准备,参测项目组：明确数据量要求提供参数化数据提取脚本配合性能测试组生成基础数据和测试数据进行数据备份和恢复等支持。保持测试过程基准一致-数据恢复策略测试主管单位：明确脚本执行所需参数化字段和数据量协调各参测项目组完成数据准备工作确认数据可用性。,.,测试工具和监控工具准备,参测项目组：提供测试工具的需求信息。测试主管单位：明确测试所需监控工具和测试环境协调各参测项目组完成测试工具准备工作。J2EE深层诊断工具Database诊断工具网络诊断工具服务器监视工具,.,测试场景设计,依据性能测试模型设计场景场景真实性场景调度（运行参数）负载均衡IP欺骗执行策略（下一章讨论）,.,挡板和时间戳,参测项目组：提供挡板和时间戳脚本和说明。测试主管单位：提供挡板和时间戳需求。,.,执行确认,由性能测试小组中的测试工程师完成以下执行前确认工作：用例和场景确认测试环境确认测试数据确认测试脚本确认测试工具和监控工具确认挡板和时间戳的确认,.,实例,XXX项目测试计划,.,第五章性能测试执行,第一节：基准测试第二节：单交易负载测试第三节：混合场景测试第四节：性能表现测试第五节：稳定性测试第六节：测试执行过程中的关键点第七节：诊断与调优,.,测试执行,测试执行阶段主要包括以下工作项：基准测试：获得各个典型交易在无压力条件下性能表现单交易负载测试：获得各个典型交易在负载条件下的性能表现混合场景序列负载测试：按照场景序列一次获得各场景负载条件下的性能表现性能表现测试：根据已知的目标负载压力，获得被测系统的性能表现稳定性测试：通过长时间、较大压力的负载运行，获得被测系统的稳定性表现,.,基准测试,测试环境确认之后，对业务模型中涉及的每种业务做基准测试目的是检查业务本身是否存在性能缺陷同时为将来的混合场景性能测试性能分析提供参考依据测试方法：编写测试客户端向应用服务器发送业务请求并接收返回结果的脚本在系统无压力情况下重复100次，每次迭代间等待1秒取业务的平均响应时间作为衡量指标。,.,单交易负载测试,单交易负载测试是逐一对业务模型中的业务或个别重要交易进行单交易多并发测试目的是考察系统交易编码是否存在性能隐患测试方法：编写测试客户端向应用服务器发送业务请求并接收返回结果的脚本使用20%系统标准并发量进行测试。,.,混合场景测试,混合负载测试是按照业务模型的约定在一定量的并发情况下测试以下指标：业务的平均交易响应时间应用服务器、数据库服务器的资源使用情况、交易正确率等通过性能测试，可以模拟实际生产环境中在业务处理高峰期系统的压力情况，得到此时的系统性能表现数据，为系统的实际上线运行提供可靠的参考。测试方法：按照业务模型比例设置测试场景。逐步增加并发量记录每次测试环境参数：包括数据库配置参数，应用系统配置参数。收集系统性能变化曲线。,.,性能表现测试,性能测试是按照业务模型的约定在一定量的并发情况下测试以下指标：业务的平均交易响应时间应用服务器、数据库服务器的资源使用情况、交易正确率等通过性能测试，可以模拟实际生产环境中在业务处理高峰期系统的压力情况，得到此时的系统性能表现数据，为系统的实际上线运行提供可靠的参考。测试方法：按照业务模型比例设置测试场景约定并发量记录测试环境参数：包括数据库配置参数，应用系统配置参数。收集系统性能参数。,.,稳定性测试,稳定性测试的重点是测试系统日常业务高峰期压力下运行的稳定性。测试方法：采用性能表现测试的脚本及场景设置选取固定运行时间为24小时(根据系统特点定)记录交易平均响应时间、交易正确率，应用服务器、数据库服务器CPU利用率、内存使用情况等参数考察应用服务器、数据库服务器是否出现宕机、交易正确率小于95等情况。,.,测试执行过程中的关键点,执行记录结果搜集数据恢复环境清理,注意：每次性能测试的结果必须要全部收集、合理命名并保存，否则在测试完成后很可能发现某次测试需要重做,.,诊断与调优,分析系统性能瓶颈优化系统性能解决过程中出现的问题开发专家测试专家应用服务器专家数据库专家操作系统专家网络专家存储专家,我们每次测试的时候，都会申请各方面专家到场，哪怕该专家负责的方面没有出现性能问题！,.,课堂讨论-除了前面提到的几种执行策略还有什么别的执行策略：分组讨论，收集意见不做辅导,10分钟,.,第六章性能测试分析,.,性能测试分析,结合有关工具生成的数据报告和测试日志对测试的结果进行分析总结对项目上线、调优方案、系统性能验证等提供参考依据。测试报告的重点在于对测试结果的分析例如测试到的业务响应时间是否满足预期要求？服务器资源使用率是否在预期范围内？对于发现并发问题的业务，需要分析是由于何种原因造成了并发问题，为系统调整提供合理依据。,.,性能测试参数经验值建议,命名用户数命名用户数是指在应用系统中注册的所有系统用户。该用户数取决于系统应用范围和业务范围，可以通过统计应用系统数据库中用户登记表获取。对于类似网站浏览式应用一般通过类似系统的类比估算获得。在线用户数在线用户数是指同时登录应用系统的用户数量该数量可通过检查系统应用与数据库连接获得在线用户数量取决于系统命名用户数。对于已投产系统，该数量一般通过系统跟踪监控获取新投产系统通过经验值进行估算。,.,性能测试参数经验值建议,并发用户数并发用户数是指在系统运行期间同一时刻进行业务操作的用户数量。该用户取决于用户操作习惯、业务操作间隔和单笔交易的响应时间。在性能测试中通过对Thinktime、interval等参数的设置测算。使用频度较低的应用系统并发用户数一般为在线用户数的5%左右使用频度较高的应用系统并发用户数一般为在线用户数的10%左右。交易交易分为业务层面和技术层面两种定义。业务层面交易是指完成一次完整的业务操作，例如进行一次取款、查询操作。技术层面的交易是指进行一次应用程序至应用程序、或者应用程序至数据库的系统操作。一般的一笔业务交易由多笔技术交易组成，根据业务交易的复杂度和系统应用架构的不同，其比例大致为1：2-1：10。,.,性能测试参数经验值建议,交易处理能力（TPS与HPS）TPS是估算应用