负载测试与性能测试.doc

由安博测试空间技术中心 /提供 1.什么是负载测试？什么是性能测试？性能测试（或称多用户并发性能测试） 、负载测试、强度测试、容量测试是性能测试领域里的几个方面，但 是概念很容易混淆。下面将几个概念进行介绍。 性能测试（Performance Test） ：通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使 用。 关注点：how much 和 how fast 负载测试（Load Test） ：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。 关注点：how much 强度测试（Stress Test） 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况， ： 目的是找到系统在哪里失效以及如何失效的地方。包括 Spike testing：短时间的极端负载测试 Extreme testing：在过量用户下的负载测试 Hammer testing：连续执行所有能做的操作 容量测试(Volume Test)：确定系统可处理同时在线的最大用户数 关注点：how much（而不是 how fast） 容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。 其中，容量测试、负载测试、强度测试的英文解释为： Volume Testing = Large amounts of data Load Testing = Large amount of users Stress Testing = Too many users, too much data, too little time and too little room2.性能测试包含了哪些测试（至少举出 3 种）包含以下测试类型： 基准测试 - 比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。 争用测试： - 核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理 是否可以接受。 性能配置 - 核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的 可接受性。 负载测试（Load Test） -是一种性能测试，指数据在超负荷环境中运行，程序是否能够承 担。核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下 性能行为的可接受性。 强度测试 Stress Testing -核实测试对象性能行为在异常或极端条件（如资源减少或用户数 过多）之下的可接受性。3.简述性能测试的步骤性能测试的过程应该为六个阶段，分别是b发现、探究、提案、执行、复查、收尾/b。原文如下： 1， Discover the problem： 发现问题。 这个步骤最重要的就是发现(Discover)问题，详述问题(Discribe),并且正确而详细地记录(Document)下来。 在进入下一步骤前，我们测试人员应该问问自已以下这些问题： b 对于问题是否已经有简明的描述 用户的基线与期待在哪 /b Explore the conditions： 探究原因，为问题提供明确的定义与定位。2，这个步骤的主要任务：是广泛搜集相关数据，尽量了解系统的每一个方面，避免深入分析时，漏了某个关 键的现象而误入歧途； 重点：是探索(Explore)，寻找证据(Evidence),建立(Establish)整个问题的来龙去脉 的假设。 有的时候在这个阶段就可以发现重大问题，一眼就看出关键点，例如硬件毁损，某个硬盘区块或内存块不 稳，或某个其他程序吃掉所有的内存，让 SQL Server 无内存可用，或是该程序常常死当，拖垮 CPU 等等。3，Track down possible approaches：提供可能的解决方案。这个步骤的主要任务：深入分析数据间的关联性，并对整个问题的前因后果提出假设，最后拟定出相应的 策略(计划)。如果前一个步骤做得不够详实，在这个步骤我们可能就会误判，导致努力的半天，但就是找 不到瓶颈点。 这个步骤的最重要的动作：是拟定计划。一个好的计划，你才能知道方向与步骤。4，Execute the most likely approach：执行最有可能的解决方案。这是 DETECT 方法中最简单的一步，因为只要执行上一步中所拟定的计划就行了。但是在执行计划时，仍 然要注意系统的反应（随时都可能会要放弃当前的计划，因为新的证据可能证明你先前的判断错误，因而 要修正计划，甚至是退回到上一步以重新拟定计划。这时切勿躁，因为整个性能测试的过程就是在考验团 队的细心与耐力、知识的广度与深度！，同时还要小心观察会不会有新的问题出现并严重影响当前系统的 ） 执行，不要原来系统迟缓，而你的测试却成为压垮骆驼的最后一根稻草。5，Check for success(如果需要的话，重复之前的步骤)：确认解决方案成功与否。这一步骤主要任务是：重新收集数据，以验证该计划的成功与否。如果证实假设是对的，则继续搜集相关 数据，以确立接下来的步骤；如果到这一步发现执行的结果不如预期，证明我们的假设错误。这会非常让 人气 tuo,进而放弃这个性能测试的方法，因为无法忍受整个时间的流失。其实，定错性能的目标是常有的 事，这个方法论就是要你在错误的当前，停下来好好思考，重新理出头绪，最重要的是要清楚知道这一回 是错在哪，如此新的步骤就能更逼近目标。有系统的犯错，是整个计划的一部分，踩着错误走向成功是性 能测试的常态。 6， Tie up loose ends：完成收尾工作。 重复前五个步骤直到达到目标。但当我们完成目标后，依然要注意以下的问题： b 解决的方式是否有边际效应，造成其他的问题/b 事后原本正常的新建、修改、删除都出现了性能问题。 b 是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚/b建立问题的假设时，很容易将问题 特殊化，仅局部地解决该现象。例如：加了某个索引或稍稍改变查询语法，舒缓了当前的瓶颈，但当用户 稍微增加，或是采用了不同的查询方式，就老问题复发。 b 是否要建立持续跟踪的计划/b 例如：为了某类的查询工作建立了大量的索引，4.简述使用 Loadrunner 的步骤1、用户确定需要进行性能测试的业务或交易，通过用户操作和 Vuser Generator 的录制功能来记录并生成 虚拟用户脚本。 2、手工修改虚拟用户脚本，确定脚本能够回放成功。 3、 Controller 中对场景进行培植后， 在 就可以启动测试了。 在测试过程中， Controller 控制 Load Gernerator 对被测系统的加压方式和行为。 4、Controller 同时负责搜集被测系统各个环节的性能数据。各个 Load Generatro 会记录最终用户响应时 日志。 间和脚本执行的日志 日志 5、压力运行结束以后，Loa