性能测试与性能测试规范.pptVIP

性能测试与性能测试规范 段念 2006-3-7 性能的不同视角 用户视角 响应时间 系统视角 并发用户数 吞吐量 开发视角 架构 数据库 应用服务器 代码 性能测试的主要关注内容 响应时间 响应时间的特点 用户视角最关心的性能指标，也是用户的唯一直接感受 与并发数、吞吐量等有直接的联系 没有普适的“可接收”与“不可接受”的原则 响应时间具有一定的用户主观性 并发用户数 “同时”访问系统的用户 同时的两个不同含义 同时在线（业务并发） 同时发出请求（服务器并发） 吞吐量 吞吐量描述的是系统的处理能力 不同层次的吞吐量 Hits / sec Page view / sec 字节数 / 秒 交易数 / 秒 性能测试的四个应用领域 能力验证 容量规划 性能调优 错误发现 能力验证中的性能测试 主要应用场景 验收时的性能测试 上线时的性能测试 产品发布前的性能测试 容量规划中的性能测试 主要应用场景 为产品给出对应的解决方案 售前支持需要了解系统能力 为将要到来的特殊场景进行验证 性能调优中的性能测试 主要应用场景 针对上线系统进行的性能调整 针对产品进行的性能调整 缺陷发现中的性能测试 主要应用场景 定位由于并发引起的问题 定位由于内存泄漏引发的问题 结论 性能测试不仅仅用来衡量系统是否具有某种能力，还能用于对已有系统进行性能的调整，或是发现系统中隐藏的错误。 性能测试需要过程的支持 性能测试不是随意和随机进行的测试 性能测试与一个完整的功能测试过程一样，也需要经历几个阶段 测试准备 测试设计 测试执行 测试分析 一个一般的性能测试过程 过程模型GPTM 工作启动 获取性能测试需求 分析典型交易 准备测试环境需求 确定测试工具 性能测试需求 来自约束的文档和隐藏的“潜规则” 2/5/8原则 来自对已运行系统的分析 应用服务器日志分析 系统日志分析 来自对用户行为的分析 测试模型 根据典型事务确定场景模型 确定需要监控的具体性能指标 用例和场景设计 原则1：选择实际的和有代表性的业务 原则2：用场景反映用户对系统的实际使用剖面 原则3：选择的场景要得到用户的认可 测试计划 时间计划 测试设计 测试设计 环境设计 原则1：尽量使用真实的运行环境 原则2：确保环境的每个环节可控 原则3：要保证环境中各设备的时间同步 数据设计 负载数据 便于识别的数据——探测数据 测试准备与测试执行 准备环境 部署工具和脚本 部署监控器 执行测试场景 收集测试过程中的性能指标 测试结果分析 根据需求分析结果 重点在分析 ，而不是出报表 测试结果分析 性能测试的结果分析是性能测试过程中最关键、但同时也是最难把握的一个步骤 “拐点”原则——曲线上的拐点就是系统性能瓶颈可能存在的地方 性能关联分析 性能测试结果分析的原则 原则1：准确知道每个测量数据的含义 原则2：在得出结论时要排除测试过程中引入的可能带来误导的因素 改善系统的不可测试性 导致系统性能不可测试的原因 非标准协议 不合理的分层 自行开发测试工具 在代码中增加日志或输出 注意修改代码对性能的影响 时间戳等技巧 对性能测试的思考 性能测试的局限性 性能测试不能提升产品性能 性能测试中发现的性能问题的修复开销巨大 问题 对软件性能的控制应该从哪个阶段介入？ 如何才能提升软件性能？ 软件性能工程SPE SPE（Software Performance Engineering）是一种系统的、定量的方法，用于构建能够符合性能目标的软件系统 Software performance engineering (SPE) is a method for constructing software systems to meet performance objectives SPE的特点 SPE是一个系统的方法 SPE是一种定量的方法 SPE是一种工程的方法 SPE是一种主动的性能管理方法 SPE基于的几个基本事实 一个系统是否能表现出期望的性能，在选择体系结构时就已经基本确定了 软件性能的几个误区 在拥有待测的执行代码之前，不可能做任何与性能相关的事 即使能通过建模控制系统性能，建模也是很复杂且成本很高 SPE的一般步骤 评估性能风险 确定关键用例 选择关键性能场景 建立性能目标 构造性能模型 确定软件资源需求 增加计算机资源需求 评价模型 验证和确认模型 SPE项目成功的关键因素 达成对性能目标的共识 确保在性能场景上达成一致 产生可信的模型结果 尽早测量关键构件并经常验证模型 用定量的数据对可选方案进行评估 SPE引入的其他特性 面向性能的设计 性能模式 性能反模式 讲座结束，谢谢！ * * 性能测试是什么？ 为什么要做性能测试？ 性能测试过程 工作启动 测试模型 测试计划 测试准备 测试执行 测试报告