性能测试经验之谈（内部培训）.pptxVIP

细节决定成败 --我的性能测试思考不懂不懂很懂略懂认识轨迹阶段表现不懂半年后，刚接触概念，没有实际项目经验，心中没谱，无底气很懂一年后，集中学习相应的理论知识，参加了多个项目，积累了一定的经验，但此时尚未遇到难关不懂二年后，经历过难关，发现掌握的知识面有限，深度有限，无法把握关键点，有茫然感和挫败感略懂三年后，开始有大局观，开始注意细节，认识到能力有限，但凭借经验和习惯，具备充分的信心去解决问题项目测试与产品测试的异同同异思路相同手段相同细节相同要求不同准备不同分析不同环境不同准备工作准备工作环境人员工具思路资料计划准备工作至关重要，越细越好。工具工具：主要指软件检测与软件测试、分析的工具包括：网络/硬盘/CPU/内存等检测如spotlight、nmon等， 执行测试的如Loadrunner/Jmeter等， 分析内存的如MemoryAnalysis等， 分析数据库的如pa等， 网页分析如httpwatch等， 更多、更重要的，那就是基础的错误意识，对基本架构的理解，对cmd/shell的应用等等环境测试环境，包括服务器、测试机、交换机、硬盘、U盘、网线等比较容易出错的地方是，需要搞清楚需要的配置是什么，现有的配置是什么，机器上的软件配置如何，何种操作系统，能提供何种权限的账号访问？资料文件模板原始素材相似文档或报告产品配置或说明资料常见故障处理、配置、调优文档（不是每一个地方都能轻易的上网，不是每一个问题都能及时的找到答案）人员项目方谁负责？测试谁负责？客户方谁负责？要向谁汇报？有没有总协调人？思路测试的思路，包括：测试的时间安排，整体结构如何，是否需要大数据量，是否需要典型的场景，根据经验问题可能出在什么地方？一句话，我该怎么做呢？（参考后面我的思路）计划测试的时间安排测试的产出与完成时间产出物（报告）的审核与提交潜在风险与解决策略我的测试思路1243预测性能了解架构分析解决监控充分 理由1：架构本身可能存在问题。理由2：网络连接往往存在问题。理由3：架构决定性能点。理由4：从架构定义监控位置。架构！架构！！各位同学务必极其重视架构！性能预测虚拟机影响、基本配置衡量可能性 30%硬件交换机带宽限制、双网卡互联办公网与机房的连接关系可能性 60%网络连接数控制、启动内存控制数据库分配资源、数据库调用频率可能性 80%中间件DB监控充分硬件中间件数据库即时性监控：把握当前的变化趋势，及时做出判断；监控记录：把测试过程中的数据记录下来加以分析，得到深度问题。工具方面：spotlightOr nmon均可也分两类，内部与外部，内部指中间件的自有监控后台，可以检查线程，包括jcon之类，外部可以使用类似diagnostics之类数据库的重要性无需多言，测试过程中需从内部、外部对数据库的健康状态进行监测，特别是连接状态与SQL的执行情况 正式测试之前架构了解与计划- 含沟通- 含计划文本基础性能调整- 主要是说服务端的硬件- 还有中间件、数据库预测试- 用httpwatch等看初始性能- 脚本录制与调试监控准备- 完成各个位置的监控布局- 当然还有调试 预测试Httpwatch很重要图片往往很迷惑多余的东西要留意脚本录制要趁早总会出问题多做对比预测试主要的目的是看看系统的情况，在单个或者小并发下的结果如果都不如意，也没有必要做进一步的工作，此时更易检查。Loadrunner报错时间巨慢无法读写磁盘问题分析网络故障了系统无法访问揭开上层的盖子再说吧~~ 透彻理解概念什么叫有问题？我必须说，如果你以为Loadrunner或其他测试软件报错或者系统崩溃才算，那就错了。2/5/10原则端口异常连接异常资源表现异常数据流异常（你看到的不一定就是对的）什么叫没问题？结果好不一定是真的好。结果符合预期吗？你发现问题了吗？系统正常吗？日志正常吗？数据正常吗？我正常吗？一切结果都需要有证据支持。流量守恒定律响应时间Response time并发用户Con users点击率Hits per second交易量Transactions per secondJUMP分析结果图管中窥豹P1P2P3P4P5JUMP分析监控CPU应用网络内存分析多是建立在结果不好的情况下。分析的方式很简单，一个一个查，当然，也有侧重点，原则1监控结果，原则2经验。服务器-检查进程CPU居高不下应用-分析应用行为某进程-分析core文件SQL-跟踪SQL内存泄漏-跟踪分配内存居高不下内存不足-检查初始关联影响-分析进程误差类型-是否cache检查日志，分析堆栈应用异常Httpwatch人工干预应用的配置类如连接应用的数据与数据库总量平衡分析网络带宽？实际带宽确认异常流量输出网卡信息确定连接失败-连接状态异常或连接数耗尽读写慢-IO异常典型分析Loadrunner错误类拒