• 1. 软件测试培训 -性能压力测试郑承夏 2009-02-09
  • 2. 测试概念 性能测试 性能测试指标 性能测试流程 性能测试VS压力测试 性能测试人员要求 压力测试 系统调优 测试工具 实例说明 2Presentation Title | Confidential 2005-11-28 |
  • 3. 测试概念 3Presentation Title | Confidential 2005-11-28 |
  • 4. 一、性能测试 评价系统或部件是否满足规定的性能需求,并且检测在该性能下资源的使用情况。 二、压力测试 检查在系统运行环境从正常到超压发生故障的情况下,系统可以运行到何种程度的测试,评价系统或部件在规定的需求限度或超出时的情况。 三、系统调优 在定位系统瓶颈以后,对系统进行优化的手段。 测试概念(一)4Presentation Title | Confidential 2005-11-28 |
  • 5. 一、Scenario testing 情景测试 模拟真实的场景 二、Benchmark testing 基准测试 记录基准数据,用于比较软硬件变化带来的性能影响 三、Availability testing 可用性测试 Duration testing 持续测试 长时间使用测试 Exception testing 异常测试 系统在各种异常情况下的测试 四、Load testing 负载测试 Volume testing 大流量测试 大文件处理,稳定的快速输入 Stress testing 压力测试 短时间内的突然爆发 Storage testing 存储测试 研究程序使用多少内存和硬盘空间测试概念(二)5Presentation Title | Confidential 2005-11-28 |
  • 6. 性能测试 6Presentation Title | Confidential 2005-11-28 |
  • 7. 一、通讯协议:TCP/IP,HTTP,FTP...... 二、并发用户数:同时访问的用户量,用户量变化策略 三、持续时间:1小时,1天, ...... 四、使用用例:记录测试步骤和测试数据 五、思考时间:模拟用户操作的思考时间性能测试指标(一):压力指标7Presentation Title | Confidential 2005-11-28 |
  • 8. 一、服务器数量 二、服务器规格 三、网络带宽 四、系统配置性能测试指标(二):配置指标8Presentation Title | Confidential 2005-11-28 |
  • 9. 客户端指标: 1)交易:定义交易的开始/结束点 2)交易成功率/可用率 3)平均交易响应时间:0.1秒,8秒…… 4)平均交易响应时间分解:按模块分解,按步骤分解 5)流量:系统运行过程中的网络,I/O等流量 6)每秒交易数/交易吞吐量:每秒处理的交易数性能测试指标(三):性能指标9Presentation Title | Confidential 2005-11-28 |
  • 10. 服务器端指标: 1)CPU使用率 2)内存使用量 3)硬盘使用量 4)其他特定服务器(譬如:web服务器,数据库服务)的指标性能测试指标(四):性能指标10Presentation Title | Confidential 2005-11-28 |
  • 11. 服务器端指标: 1)CPU使用率 2)内存使用量 3)硬盘使用量 4)其他特定服务器(譬如:web服务器,数据库服务)的指标性能测试指标(四):性能指标11Presentation Title | Confidential 2005-11-28 |
  • 12. 性能测试流程(一):流程图12Presentation Title | Confidential 2005-11-28 |
  • 13. 收集需求 确认测试范围 定义测试目标 一般的性能测试需求 分析系统的性能 根据观察到的特征确定容量极限或者是性能瓶颈 衡量系统在预测的条件下的性能或可用性 比较不同的可能的设计或者是硬件配置 收集一段时期内的指定性能或者用户性数据作为将来分析的输入性能测试流程(二):测试需求分析13Presentation Title | Confidential 2005-11-28 |
  • 14. 确定测试策略 定义方法 确定测试场景 确定性能测试指标 制定测试时间表 计划测试资源 硬件 软件 人员 备注:尽测试计划和测试方案设计在实践中通常是紧密结合在一起的性能测试流程(三):测试计划14Presentation Title | Confidential 2005-11-28 |
  • 15. 设计测试场景/用例 详细测试步骤,包括期望的结果和检查点 测试/压力设定,包括并发用户数,测试持续时间,压力策略,思考时间,客户特征等 先决条件 测试数据 基于测试用例开发测试脚本 测试方案示例:SVTC_性能测试方案编写指南.doc性能测试流程(四):测试方案设计15Presentation Title | Confidential 2005-11-28 |
  • 16. 准备/验收测试先决条件 准备测试数据 运行测试脚本 监视执行流程 测试结果的预处理性能测试流程(五):测试执行16Presentation Title | Confidential 2005-11-28 |
  • 17. 生成并发布测试报告 分析测试结果 测试结论(测试结果是否达到测试目标) 预计产品上线后的性能 研究性能瓶颈 根据经验作为建议/推荐性能测试流程(六):测试报告17Presentation Title | Confidential 2005-11-28 |
  • 18. 性能测试 模拟真实用户场景 设置用户思考时间 渐进地增加/减少用户数 注重性能指标的绝对值性能测试VS压力测试(一)压力测试 模拟大压力的非真实场景 忽略用户思考时间 突然增加/减少用户数 注重性能指标的相对值检查点 参数表18Presentation Title | Confidential 2005-11-28 |
  • 19. 性能测试的真实性模拟 用户操作的真实数据 用户思考时间的模拟 用户数和用户数变化的真实数据 数据的真实模拟 用户压力分布的真实模拟 真实系统环境的模拟 期望性能指标的真实性性能测试VS压力测试(二)19Presentation Title | Confidential 2005-11-28 |
  • 20. 测试人员应具备以下条件: IT行业工作经验 编程经验 测试经验 熟悉网络,网络协议,数据库等 熟悉测试工具的使用性能测试人员要求20Presentation Title | Confidential 2005-11-28 |
  • 21. 压力测试 21Presentation Title | Confidential 2005-11-28 |
  • 22. 从前面压力测试的定义我们可以得知,压力测试是性能测试的一种极端测试手法。因此压力测试的分析方法与性能测试类似,但是在压力指标的设计上会有一定的差异,详情参见“性能测试VS压力测试” 与性能测试的发现问题的范围相比,它还可以发现以下问题: 系统崩溃 内存泄露 可扩展性压力测试(一)22Presentation Title | Confidential 2005-11-28 |
  • 23. 系统崩溃的想象就是系统失去反应能力。 造成系统崩溃的原因有很多,一般在实践中造成系统的原因大多集中在:服务硬件设备配置低,无法处理大量计算;应用服务软件由于配置原因或者本身性能的问题导致无法处理大量请求;数据库方面的配置问题或者本身性能情况导致无法处理大量请求;网络方面带宽太小,导致网络拥塞;系统关键资源不释放,譬如:线程池的线程,数据库连接池的连接等。 上述列举了一些系统崩溃的原因,但在我们公司造成系统崩溃的原因大部分出现应用程序的数据库连接的管理上。压力测试(二):系统崩溃23Presentation Title | Confidential 2005-11-28 |
  • 24. 压力测试中有可能发现的一个问题就是内存泄露。可以通过对服务器内存使用情况的监视来发现。一般的现象是内存非正常使用量曲线或者由特定检测工具(譬如,JProfiler)识别。 一般来说,对C,C++等可以进行内存直接操作的语言,代码缺陷容易导致内存泄露。 对于Java,C#等不可以对内存进行直接操作的语言,一般垃圾回收由系统完成,很少出现内存泄露。但是代码缺陷也会造成系统的垃圾回收缺乏效率。在压力之下,就会产生内存泄露相同的结果。 注意:对于部署到像Apache、Tomcat等可以将日志打印到终端屏幕的服务器的系统来说,如果大量将日志打印到终端屏幕(尤其是系统异常时会抛出大量的日志)会导致终端的内存泄露从而使服务器崩溃,因此统一和规范的日志管理是很必要的。压力测试(三):内存泄露24Presentation Title | Confidential 2005-11-28 |
  • 25. 压力测试由于使用超过真实场景的压力,因此可以比较容易根据压力测试的结果进行可扩展性预测。 可扩展性预测包括: 现有配置的性能极限 配置变更的可扩展性压力测试(四):可扩展性预测25Presentation Title | Confidential 2005-11-28 |
  • 26. 系统调优 26Presentation Title | Confidential 2005-11-28 |
  • 27. 系统调优,在定位系统瓶颈以后,对系统进行优化的手段,是性能测试中难度最大的一部分。 在系统调优的过程中,测试人员一般不起主导作用。 测试人员在系统调优的过程中,可以根据测试结果作出系统瓶颈的分析。利用基准测试来,验证系统调优的有效性。系统调优(一)27Presentation Title | Confidential 2005-11-28 |
  • 28. 硬件瓶颈 CPU 内存 硬盘(容量,I/O) 网络宽带 优化手段: 添加/升级硬件 负载均衡 优化人员:硬件/软件工程师系统调优(二)-- 硬件级28Presentation Title | Confidential 2005-11-28 |
  • 29. 应用瓶颈 内存池大小 连接池大小 缓冲开关 操作系统/应用设置 优化手段: 更改配置 优化人员:系统架构师/软件工程师系统调优(三)-- 应用级29Presentation Title | Confidential 2005-11-28 |
  • 30. 代码瓶颈 算法 数据结构 设计模式 预编译/宏 优化手段: 代码优化 优化人员:系统架构师/软件工程师系统调优(四)-- 代码级30Presentation Title | Confidential 2005-11-28 |
  • 31. 测试工具 31Presentation Title | Confidential 2005-11-28 |
  • 32. 培训材料:SVTC_LoadRunner使用指南.doc 培训方式:根据培训材料,实例性操作展示测试工具 -- LoadRunner32Presentation Title | Confidential 2005-11-28 |
  • 33. 性能测试实例讲解 33Presentation Title | Confidential 2005-11-28 |
  • 34. 原始材料:IBP事务不一致分析.doc 测试流程 测试需求分析:交流->起草->确认 测试方案设计:起草->评审->确认->执行中调整,IBP事务问题测试方案.doc 测试执行:脚本维护->执行->收集数据->初步结果分析->调整方案->继续执行;scripts 测试报告:测试数据分析->测试报告整理,IBP事务问题测试报告.doc 在该次测试中的几个关键因数: 开发人员对于问题出现范围和场景的信息的收集 在测试过程中通过初步分析后,对测试方案的调整(参考测试报告中的测试方案和测试方案中的测试方案的差异) 针对不一致问题的判断采用了更直观、明了的方法(原方法:通过查看日志方法判断;新方法:通过数据统计比较方法)测试实例 – IBP系统事务不一致问题测试34Presentation Title | Confidential 2005-11-28 |
  • 35. 结束谢 谢!35Presentation Title | Confidential 2005-11-28 |