Loadrunner实战教程第2章.ppt

软件性能测试与LoadRunner实战教程 第2章 性能测试过程概述 2.1 性能测试的基本过程 2.2 性能测试需求分析 2.3 性能测试计划 2.4 性能测试用例 2.5 测试脚本编写 2.6 测试场景设计 2.7 测试场景运行 2.8 场景运行监控 2.9 运行结果分析 2.10 系统性能调优 2.11 性能测试总结 2.1 性能测试的基本过程 性能测试的实施过程是招聘公司经常会问道的一个问题； 必须要清楚性能测试这个职位是具体做哪些工作的，并且按照工作的流程把每一个环节都表述清楚。 2.1 性能测试的基本过程 2.2 性能测试需求分析 性能测试的目的就是把客户的真正需求搞清楚，这是性能测试最关键的过程。 典型问题 我们需要贵单位对所有的功能都进行性能测试； 系统用户登录响应时间小于3秒钟； 系统支持10万用户并发访问。 2.3 性能测试计划 性能测试计划是性能测试的重要过程。在对客户提出的需求经过认真分析后，作为性能测试管理人员，需要编写的第一份文档就是性能测试计划，性能测试计划非常重要，在性能测试计划中，需要阐述产品、项目的背景，将前期的需要测试性能需求明确，并落实到文档中。 2.4 性能测试用例 客户的性能测试需求最终要体现在性能测试用例设计中，性能测试用例应结合用户应用系统的场景，设计出相应的性能测试用例，用例应能覆盖到测试需求。 2.4 性能测试用例 用例设计 明确系统经常处理那些业务； 明确系统预期的用户规模、并发用户数、在线用户数； 明确系统业务的处理能力要求，如：TPS、响应时间、系统资源利用率等； …… 2.5 测试脚本编写 性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。 测试脚本编写: 协议的正确选用; 脚本进行完善，保证其正确性，去除冗余代码; 注重编码的规范和代码的编写质量； 注重脚本的存储、备份工作等。 2.6 测试场景设计 测试场景的设计一个重要的原则就是依据测试用例，把测试用例设计的场景展现出来。 测试场景的设计需关注： 工具是以进程还是线程方式来模拟虚拟用户； 场景是否存在有执行次序依赖关系的脚本； 场景的相关设置项也是需要关注的重要内容，如：集合点策略的设置。 2.7 测试场景运行 测试场景运行是关系到测试结果是否准确的一个重要过程。 经常有很多做测试的人员花费了大量的时间和精力去做性能测试，可是做出来的测试结果不理想。 原因包括： 负载的测试机不能够运行设定的虚拟用户数； 没有“预热”过程； 没有模拟用户的真实环境； 没有同各个部门保持良好的沟通； 性能用例运行次数过少。 2.8 场景运行监控 场景运行监控，可以在场景运行时决定要监控那些数据，便于后期分析性能测试结果。应用性能测试工具的重要目的就是可以提取到本次测试关心的数据指标内容，性能测试工具利用应用服务器、操作系统、数据库等提供的接口，取得在负载过程中相关计数器的性能指标。 2.8 场景运行监控 场景的监控需要注意： 负载机的时钟要一致，保证在监控过程中的数据是同步的； 尽量搜集与系统测试目标相关信息，无关内容不必进行监控； 要以管理员的身份登录后，如果监控不了相关指标，再去查找原因，不要耗费过多精力在做无用功； 深入学习这些知识，不断积累经验。 2.9 运行结果分析 性能测试执行过程中，性能测试工具搜集相关性能测试数据，待执行完成后，这些数据会存储到数据表或者其他文件中。为了定位系统性能问题，我们需要系统分析这些性能测试结果。 “拐点分析”方法是一种利用性能计数器曲线图上的拐点进行分析的方法。基本思想就是性能产生瓶颈的主要原因就是因为某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能却出现急剧下降，就产生了“拐点”现象。 2.10 系统性能调优 性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。这时相关开发人员、数据库管理员、系统管理员、网络管理员等就需要根据性能测试分析人员提出的意见同性能分析人员共同分析确定更细节的内容，相关人员对系统进行调整以后，性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。 2.10 系统性能调优 系统调优由易到难的先后顺序如下： 硬件问题； 网络问题； 应用服务器、数据库等配置问题； 源代码、数据库脚本问题； 系统构架问题。 2.11 性能测试总结 性能测试工作完成以后，需要编写性能测试总结报告。 性能测试总结不仅使我们能够了解到如下内容：性能测试需求覆盖情况，性能测试过程中出现的问题，我们又是如何去分析、调优、解决的，测试人员、进度控制与实际执行偏差，性能测试过程中遇到的各类风险是如何控制的，而且，还能描述经过该产品