性能测试管理.ppt

大纲 第一章：性能测试启动 第二章：性能测试建模 第三章：性能测试计划 第四章：性能测试准备 第五章：性能测试执行 第六章：性能测试分析 第一章 性能测试启动 技术调研 在系统代码开发完成之后和功能测试完成之前 测试组织派专人采用现场或非现场的方式 调研以下内容 被测系统的技术实现 与其它系统接口关系及其技术实现 本系统测试数据 与相关系统测试数据的关系 目的：初步确定测试技术方案及相关的测试数据准备方案 技术调研-实例 XXX系统技术架构 WebSphere + S1 + DB2 Browser Base Client 使用EAI/ECTIP/UDI作为外部系统接口 技术调研-实例 初步测试技术方案 使用LoadRunner作为压力测试工具 使用Web/HTTP协议开发测试脚本 使用Spotlight for DB2监控数据库 使用Diagnostic for J2EE监控应用服务 使用Server Monitor监控操作系统资源 EAI/ECTIP实时交易需要开发相关挡板程序 初步测试数据准备方案 UDI需事先准备全量数据 准入评审 在性能测试正式启动之前，需要对两个方面进行评审 被测系统是否符合准入标准 实施性能测试的可行性和必要性 目的：考察被测系统是否具备性能测试的条件。 不符合测试条件的系统会导致测试难以实施，或者测试结果严重失真 勉强测试会使测试工作失去意义，浪费大量的时间、人力和软硬件资源。 测试启动 确定测试的负责人和组织结构。 明确测试的总体目标和范围 确认测试所需资源的情况 测试主管单位要下发相关调查表，获取业务方或开发方对性能测试的需求信息： 典型交易列表 性能测试需求 性能指标 测试环境 数据量要求 第二章 性能测试建模 为什么需要建模 真实模拟实际系统运行状况 所有性能测试工作都以此模型作为依据 合理控制项目周期 并发量与每秒交易量(TPS)的联系 性能测试误区 并发量越大系统压力越大 并发量与每秒交易量的联系 并发量用于考察系统的用户支撑能力 每秒交易量才是衡量大多数系统的真实压力的正确指标 随着并发量的增加TPS并不是线性增长的 性能测试模型的两种形式 用户行为模型 描述高峰时期用户行为特点(瞬时模型) 优点：对与大多数性能测试工具而言实现简单 缺点：用户行为较难统计分析 系统业务模型 描述高峰时期系统业务特点(时段模型) 优点：相对于用户行为模型而言较容易获得 缺点：设置复杂，需要较高的工具技能 建立性能测试模型-用户行为模型 用户行为模型 高峰日 高峰时段 高峰时段用户行为统计 建立性能测试模型-系统业务模型 系统业务模型 高峰月 高峰日 高峰时段 高峰时段业务统计 建立性能测试模型-系统业务模型 建立性能测试模型-系统业务模型 建立性能测试模型-系统业务模型 性能测试模型的工具实现 用户行为模型的工具实现 模型建立困难，实现容易。 系统业务模型的工具实现 主流模型，详细讨论。 系统业务模型的工具实现 用户支撑能力测试/用户体验测试 调研用户使用方式，确定Think Time 基准测试确定各交易基准执行时间 调整Interval时间 风险 系统处理能力测试 调研系统处理量需求 基准测试确定各交易基准执行时间 调整Interval时间 风险 第三章 性能测试计划 测试计划 测试经理根据测试启动阶段得到的测试模型编写测试方案和测试计划 用于指导整个测试实施过程 关键文档 《性能测试方案》 《性能测试计划》 《典型交易列表》 《性能测试需求表》 性能测试方案关键点 测试目的（清晰明确，没有歧义）。 测试范围（交易列表，路径图等）。 性能指标（要可测量，量化指标最好给出具体数值，无法定量的给出说明）。 数据量 （给出具体数值和参考依据，无法定量的给出说明）。 测试环境（分为网络、硬件、软件和拓扑图）。 测试工具和监控工具及其相关环境。 风险控制（风险描述、严重程度、规避办法、负责人等明确清晰） 测试策略（符合项目实际情况，具有可执行性） 挡板（根据情况可裁减） 时间戳（根据情况可裁减） 角色分工（无遗漏，职责描述清楚） 测试执行过程等（符合项目实际情况，没有遗漏，具备可执行性） 性能测试计划关键点 阶段任务描述（阶段，子阶段划分清晰；阶段关联关系明确；里程碑定义准确） 时间安排（满足项目预期周期要求，具有弹性） 文档定义（各阶段输入输出文档定义清晰） 所需资源（人力资源，资金资源等符合项目要求） 典型交易列表关键点 典型交易选取合理（符合关键业务，操作频繁，业务量大，覆盖所有测试需求路径，对性能影响大的原则） 相关交易码准确（配置管理最新版本） 业务约束和逻辑约束明确给出，无遗漏和错误 典型交易数量选取合适，能满足并发分配需求（例如，不能选50个交易，要求