/20该会员上传的其它文档：21 p.14 p.0 p.0 p.0 p.25 p.27 p.34 p.3 p.3 p.3 p.58 p.12 p.3 p.3 p.3 p.20 p.10 p.10 p.3 p.4 p.33 p.18 p.13 p.高考化学实战策略【高考展望】学科思想方法及学习能力【】1、调整心态对待高考心..高考化学实战策略【高考展望】学科思想方法及学习能力【】1、调整心态对待高考心态要平和、坚定而自信，有一种跃跃欲试、期待高考检验的良好心境。在高考中，要保持一颗平常的心，把高考当做是众多考试中的某一次，没什么大不了的；自己与自己去比，认真对待知识讲解2015高考化学实战策略相关文档docdocdocdocdocdocdocdocdocdocdocdocdocdocdocdocdocdocdocdoc关于我们常见问题关注我们官方公共微信Web 性能测试实战读书笔记测试人员的要求： 1） 掌握常见自动化测试工具的使用。 2） 具备一定的编程能力。 3） 掌握基础数据库知识。 4） 掌握常见的操作系统知识。 5） 掌握一些 Web 应用服务器例如 Weblogic 和 Websphere 等的使用。 6） 具有综合分析问题的能力，例如通过综合分析测试结果来确定系统瓶颈。 7） 制定合适的性能测试策略以及
性能测试方案并按照方案对系统进行全面的测试和分析。1.1 性能测试的主要术语1. 并发用户: 1） 严格意义并发：即所有用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。 2） 广义范围并发：多个用户对系统发出请求或者进行操作，但是这些请求或者操作可以是相同的，也可以是不同 的，但是对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴 3） 两者的区别与联系：后者包括前者，后者更加接近用户的实际使用情况。对于 Web 性能测试而言，这两种的 并发都需要进行测试，通常是先进性严格意义上的并发测试（模块的选择一般选择发生使用比较频繁的模块 中） ，再进行广义范围并发测试。严格意义并发，一般和功能测试关联起来，因为并发功能遇到异常都是程序 的问题，这种测试也是健壮性和稳定性测试的一部分。 2. 并发用户数量：同以时刻与服务器进行交互的在线用户数量.公式（使用系统的用户数量*(5％~~~~20％)＝并发用户 数） 错误理解 1） 并发用户数量理解为使用系统的全部用户数量 2） 并发用户数量理解为在线用户数量（浏览网页信息的用户） 3. 请求相应时间：客户端发出请求到得到响应的整个过程时间。 （等于网路相应时间＋应用程序与系统响应时间） 4. 事务相应时间： 5. 吞吐量：指的是在一次性能过程中，网络上传输的数据量的总和 6. 吞吐率：吞吐量/传输时间，即：单位时间内网路上传输的数据量，也可以指单位时间内处理的客户端请求数量。 它是衡量网络性能的重要指标。 7. TPS：每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要指标。 8. 点击率：每秒钟用户向 Web 服务器提交的 HTTP 请求数。 9. 资源利用率：指的是对不同系统资源的使用程度（CPU 利用率、磁盘利用率、内存利用率、缓存利用率） 。主要针 对 Web 服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参考。1.2Web 性能测试种类1. 压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收用请求的性能点，来获得系统能 提供的最大服务级别的测试 2. 负载测试：通过在被测系统上不断增加压力，直到性能指标达到极限。这种测试为系统调优提供依据。 3. 强度测试： 强度测试主要是为了检查程序对异常情况的抵抗能力。 强度测试总是迫使系统在异常的资源配置下运行。 强度测试是一种特别重要的测试， 对测试系统的稳定性以及系统未来的扩展空间均具有重要意义。 因为在这种情况 下进行的测试，更容易发现系统是否稳定以及性能方面是否容易扩展。 4. 并发测试： 主要指测试多个用户同时访问同一个应用程序、 同一个模块或者数据记录时是否存在死锁或者其他性能 问题 5. 大数据量测试： 1） 一种针对某些系统存储、传输、统计查询等业务进行大数据量的测试。 2） 另一种是与并发测试相结合的极限状态下的综合数据测试。6. 配置测试：主要时通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。 7. 可靠性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。 8. 狭义性能测试： 主要用于描述常规的性能测试， 通过模拟生产运行的业务压力和使用场景组合来测试系统的性能是 否满足生产要求。1.3 性能测试常见的认识误区1. 2. 3. 4. 5. 6. 7. 提高一下硬件配置就可以提高性能了，因此性能测试不重要。 性能测试在所有其它测试完成后，测试一下看看就可以了。 性能测试独立于功能测试。 性能测试就是用户并发测试。 在开发环境下进行一下性能测试就可以了。 系统存在瓶颈，就不能使用。 不切实际的性能指标。1.4 性能调优基础知识性能调整的步骤： 1） 确定问题 应用程序代码：通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一 下代码。 数据库配置：数据库配置经常引起整个系统运行缓慢，一些诸如 Oracle 的大型数据库都是需要 DBA 进行正确 的参数调整才能投产的。 操作系统配置： 操作系统配置不合理也可能引起系统瓶颈。 硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。 网络：网络负载过重导致网络冲突和网络延迟。 2） 确定原因 问题的影响是什么：响应时间还是吞吐量，或者其他问题？ 是大多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不同？ 系统资源监控的结果时候正常：CUP 的使用时候到了极限？I/O 情况如何？ 问题时候集中在某一类模块中。 是客户端还是服务器出现问题？ 系统硬件配置是否够用？ 是否实际负载超过了系统的负载能力？ 是否未对系统进行优化? 通过这些分析及一些具体系统相关的问题，可以对系统瓶颈有更深入的了解，进行分析出真正的原因。 3） 确定调整目标和解决方案 提高系统吞吐量。 缩短响应时间。 更好地支持并发。 4） 测试解决方案 5） 分析调整结果 系统调整是否达到或者超出了预定目标。 系统是整体性能得到了改善，还是以牺牲某部分性能来解决问题的。 调整是否可以结束了。 最后，如果达到了预期目标，调整工作就基本可以结束了。Web 全面性能测试模型2.1Web 全面性能测试模型包括如下内容Web 性能测试策略制定原则 Web 性能测试用例设计模型 Web 全面性能测试模型使用方法 1) Web 全面性能测试模型中，把 Web 性能测试分为 8 个类别 1. 预期指标的性能测试：系统在需求分析和设计阶段都会提出一些性能指标。 2. 独立业务性能测试：一些核心业务模块对应的业务，这些模块通常具有功能比较复杂、使用比较频繁、属于核 心业务特点。核心业务模块在需求阶段就可以确定，用户并发测试是核心业务模块的重点测试内容。 3. 组合业务性能测试：多用户不同（对一个或者多个模块的不同功能进行操作）操作，组合业务性能测试是最接 近用户实际使用情况的测试，也是性能测试的核心内容。 4. 疲劳强度性能测试：在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确 定系统长时间教大业务量时的性能。可以判断系统运行一段时间后是否稳定。 5. 大数据量性能测试：分三种， 第一种：针对某些系统存储、传输、统计查询等业务进行大数据量的测试。 第二种：极限状态下的数据测试，主要时指系统数据量达到一定程度时，通过性能测试来评估系统的响应 情况，测试的对象也是某些核心业务或者常用的组合业务。 第三种：结合前两种情况进行的大数据量测试。 6. 网络性能测试：主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。 7. 服务器（操作系统、Web 服务器、数据库服务器）性能测试：分为初级和高级两种形式 初级形式： 主要是指在业务系统工作或者进行前面其他种类性能测试的时候， 监控服务器的一些计数器信 息，通过这些计数器对服务器进行综合性能分析，找出系统瓶颈，为调优或者提高性能提供依据。 高级形式：一般不由测试人员进行，而是由专门的系统管理来进行。 8. 一些特殊测试：指配置测试、内存泄漏测试等一些特殊的 Web 性能测试 Web 全面性能测试模型包括以下三部分 第一部分：Web 性能测试策略模型 第二部分：Web 性能测试用例设计模型：性能测试的 8 项归纳形成五类测试用例 1． 预期指标的性能测试 2． 并发用户的性能测试 3． 疲劳强度和大数据量的性能测试。 4． 服务器性能测试。 5． 网络性能测试。 第三部分：模型使用方法 （一） 独立核心模块用户并发性能的测试用例设计 1） 发现一些核心算法或者功能方面的问题。一些多线程、同步并发算法在但用户模式下测试是很难发现问题的， 通过模拟多用户的并发操作，更容易验证是否正确和稳定。 2） 尽早发现性能问题以降低修复缺陷的成本。 核心模块并发性能测试包含三方面的内容 完全一样功能的并发测试 完全一样操作的并发测试 相同/不同的子功能并发 核心模块的性能测试用例示例 当在线用户到达高峰时， 发送和接收普通邮件正常。 保证 2000 个以内用户可以同时访问邮件系统， 功能 能够正常发送和接收邮件。 测试系统 2000 个以内的用户同时在线时能否正常发送邮件。 目的 采用 LoadRunner 的录制工具录制一个邮件发送过程，然后利用其完成测试，要监视数据库服务器 方法 和 Web 服务器的性能。其中发送的邮件为普通的邮件，附件大小不超过 1MB 并发用户数与事务执行情况并发用户数 100 …… 150 200 并发用户数 100 …… 150 200事务平均响应 时间事务最大响应 时间平均每秒处理 事务数事务成功率每秒点击率平均流量(B/s)CPU 利用率并发用户数与数据库主机 MEM 利用率 磁盘 I/O 参数DB 参数 1其它参数并发用户数 100 …… 150 200并发用户数与应用服务器的关系表 CPU 利用率 MEN 利用率磁盘 I/O 参数（二）组合模块用户并发性能测试的用例设计 组合模块的性能测试是最能反映用户实际使用情况的测试。它是在前面哥哥核心模块运用良好的基础商，把系统的一 些具有耦合关系的模块组合起来的测试，因此可以理解成是“集成性能测试” 。组合模拟用户并发测试最重要的是模拟 实际用户较常见的场景，只有这样才可以真实的反映用户使用系统的情况，进而发现系统的瓶颈和其他一些性能问题。 典型用户场景主要通过下面几种方法得到。 需求、设计文档：系统的需求、设计文档会反映出有多少用户类型，这为用户分组提供了可靠的依据。在大多数 的系统设计文档中都会涉及到系统的组织结构管理或者权限管理，根据这些资料可以设计各个模块的用户群体分 类。 现场调查：去用户现场调查是最直接的方法，通过和用户进行交谈或者正式的交流可以取得所需的信息。最有效 的方法就是拿到用户单位的通讯录，通讯录里面有各个部门的人员情况，自然就可以统计出系统各类用户的使用 情况。通过这些资料很容易对不同业务模块的用户数量进行评估。 通过系统来采集数据：通过系统手机资料也是一种有效的辅助手段，适用于系统试运行或者投产阶段的性能测试。 1） 发现接口方面的功能问题。 2） 尽早发现综合性能问题。 组合模块并发性能测试包含三方面的内容 具有耦合关系的核心模块进行组合并发测试。 彼此独立的，内部具有耦合关系的核心模块组的并发测试 基于用户场景的并发测试。 组合业务性能测试用例 组合业务性能测试用例 在线用户达到高峰时，用户可以正常使用系统，目标是满足 500 个以内用户同时在线使用系统。 功能 测试系统 500 个以内的用户同时在线时能否使用比较常见的模块：公文系统、电子公告、网上论 目的 坛。 采用 LoadRunner 的录制工具录制三项业务： 业务 1：在公文系统内，进行打开，修改等操作。 业务 2：在电子公告系统内，查看、发布公告。 方法 业务 3：在网上论坛系统内发布贴子，查看文章。 每项业务分配一定数目的用户，利用 LoadRunner 来完成相关参数的测试。 并发用户数与事务执行情况 并发用 平均每秒处理事务 每秒点 平均流 事务平均响应时间 事务最大响应时间 事务成功率 户数 数 击率 量(B/s) 300 业务 业务 业务 业务 业务 业务 业务 业务 业务 业务 业务 业务1 …… 400 50023123123123并发用户数与数据库主机 并发用 户数 300 …… 400 500 并发用 户数 300 …… 400 500 CPU 利用率 MEM 利用率 磁盘 I/O 参数 DB 参数 1 其它参数CPU 利用率并发用户数与应用服务器的关系表 MEN 利用率磁盘 I/O 参数产品类型项目背景 用户要求性能测试策略某银行项目性能测试策略案例 银行卡审批业务系统，使用非常频繁，业务量每年达到 200 万次左右，属于银行领域的特殊应用 软件。 系统属于第二次重新开发， 前一开发商在系统开发完成后没有通过性能测试， 100 个左右用户并发 访问系统时数据库服务器崩溃。因此新的系统从项目启动开始，性能测试已经成为用户关注的焦 点。 用户提出性能方面首先要过关，否则功能再好也不会投产。 从系统设计阶段开始进行性能测试准备工作，测试人员主要时参加系统的设计，评审。因为前以 开发商失利的重要原因是数据库设计不合理，所以这次重点讨论了数据的设计。 系统设计阶段完成了性能测试方案的设计。 单元测试阶段通过测试工具对一些重要模块的算法进行测试。主要是一些并发控制算法的性能问 题，测试对象是一些核心业务模块。 集成测试阶段进行组合模块的性能测试。 整个系统测试阶段都在进行性能测试，并和功能测试同步进行。功能测试引起的一些相关修改， 应立刻进行性能测试。 验收测试阶段，应在用户现场的投产环境中进行性能测试，根据形式结果对系统运行环境进行调 优，达到较佳的运行效果。 某 OA 项目性能测试策略案例 企业办公系统，用户数目在 1000 人以内，主要是一些信息的发布，以及公文流转，收发邮件等功 能。软件系统的地位属于辅助办公功能。因此该类软件属于议案类型的应用软件，对性能要求不 高，性能测试不属于重要工作。 已有稳定产品。主要是按照客户的个性化需求进行二次开发。 要求系统响应时间不要过慢，可以满足 2000 个用户来使用。 系统测试阶段开始进行性能测试准备工作，完成测试用例设计。目标主要是评估系统性能，根据 测试结果对系统进行一定的优化。 验收测试阶段在用户现场执行性能测试用例，根据测试结果进行一定的调优工作，提交测试报告 给用户以便进行系统验收。产品类型 项目背景 用户要求性能测试策略性能测试策略制定基本原则 软件类别 应用类软件 系统类软件 用户重视程度 一般应用 设计阶段开始进行一些讨 论工作，主要在系统测试 阶段开始进行性能测试实 施。 从设计阶段就开始针对系统架构、数据库 可以在系统测试阶段的功 设计等方面进行讨论， 从跟原来提高性能。 能测试结束后进行性能测 试。 系统类软件一般从单元测试阶段开始性能 可以在系统测试阶段的功 测试实施工作，主要是测试一些和性能相 能测试结束后进行性能测 关的算法或者模块 试。 可以在软件发布前进行性 能测试，提高测试报告即 可 特殊应用高度重视从 设 计 阶 段开 始 针对 系 统构架、数据库设计等方 面进行讨论，从根源来提 高性能； 特 殊 应 用 类软 件 一般 从 单 元 测 试 阶段 开 始性 能 测试实施工作，主要是测 试 一 些 和 性能 相 关的 算 法或者模块。中等重视一般重视不怎么重视疲劳强度与大数据量测试 疲劳强度测试用例 200 个用户同时使用系统的三个模块。 极限名称 测试用的客户端要有足够的资源，否则客户端 down 机失去测试意义。 前提条件 连续运行 16 小时。 运行方法 采用 loadRunner 录制三个任务，然后开始对系统施压。 测试方法 输入/动作 输入 动作 用户数量 任务 1:进入邮件系统，进行发送、接收、删除等操作。 100 50 任务 2：进入公告系统，查看公告。 50 任务 3：查看网上论坛，阅读、发布帖子。 任务 1：20 小时 28 分 邮件发送事务开始出现 “网络超时不能发送” 的现象。 无故障 无 任务 3：18 小时 36 分 阅读帖子事务超时 大数据量测试用例 数据库中的短信息表可以保存所有不能及时发送的短信息，用户上线后又能及时发送已经保存 的信息。功能 目的 方法输入说明 模拟 8000 个用 户不在线的情 况：并发向数 据库中输入 8000 条记录 模拟 8000 个用 户在线的情 况：并发向数 据库中删除 8000 条记录 ……事务平均响 应时间/s并发用户数与事务执行情况 事务最大响 平均每秒处 事务功能率/s 应时间/s 理事务数/s每秒点击率平均流量 （KB/s）1.9882.0783980100％无2361.0092.0685036100％无278………………………………3.1 性能测试实施与管理性能测试流程如下： 测试需求分析-& 测试需求分析 测试计划制定与评审-& 测试计划制定与评审 测试用例设计与开发-& 测试用例设计与开发 测试执行与监控-& 测试执行与监控 分析测试结果-& 分析测试结果 编写性能测试报告-& 编写性能测试报告 测试经验总结。 测试经验总结。 第一步：测试需求分析：测试负责人要和项目干系人进行沟通，同时收集各种项目资料，尤其要搞清楚用户对待性能 测试的态度。其干系人有 客户代表（客户是否关注性能测试，客户在软件性能方面的需求等） 、项目经理（大概确定 性能测试的一些里程碑要求，进而确定需要多少人力资源以及一些重要环节的优先级） 、产品经理（通常会比较明确提 出性能需求，通过产品经理确定原始的性能需求，可以避免在后来设计过程中产生的一些误差） 、销售经理（在初期投 标或者给客户的系统解决方案中，通常都会承诺一些性能指标，这些性能指标是性能测试首要完成的任务，也是预期 指标性能测试用例设计的主要内容） 、需求分析员（可以了解基本的业务需求以及一些更加明确的性能指标，由于需求 人员是需求文档的主要作者，因此通过需求分析员还可以确定哪些业务是核心业务，为后面编写核心业务模块的测试 用例打下良好的基础） 第二步：测试计划制定与评审：计划主要包含测试范围、测试环境、测试方案简介、风险分析等。 第三步：测试用例设计与开发：测试脚本开发主要指开发和用例相关的测试程序，测试脚本开发比较常见的做法是先 通过测试工具录制用户的操作，然后进行修改（进行必要的代码修改和参数化） 。特殊项目的测试程序可能完全由测试 人员自己编写。 第四步：测试执行与监控：主要包括性能测试实施和过程监控。测试实施包括：创建测试场景、执行测试场景、监视 测试场景等。监控测试项目是测试经理的主要职责，在执行过程中，通常会根据项目具体情况进行测试内容的调整。 第五步：分析测试结果：根据前面的测试数据来分析测试结果，为优化和调整系统提供依据。分析的对象包括：应用 服务器、Web 服务器、数据库服务器、操作系统、硬件资源等。 第六步：编写性能测试报告：包括：测试过程记录、测试分析结果、系统调整建议等。 第七步：测试经验总结：通过总结本次工作经验和一些教训，能为以后的测试工作提供借鉴。 性能测试整体规划 1. 测试环境规划 网络环境设计 操作系统环境规划： 当目标测试产品的服务器端在多种操作系统平台上运行时， 就需要规划操作系统的测试环 境。 不过很多应用系统在性能方面与操作系统关联不大， 因此在性能测试中对操作系统进行规划的情形不是特 别多。 数据库环境规划：数据库环境规划与操作系统环境规划类似，主要是指产品开发中，由于目标测试系统可能在 不同数据库平台上运行，因此需要针对将要测试的数据库种类进行规划。 Web 服务器环境规划： Web 服务器环境规划很少见， 一般某一产品基本会有相对固定的 Web 服务器， 不过 J2EE 平台的应用系统可能要对多种 Web 平台进行测试规划。 硬件资源环境规划：软件性能离不开硬件的支持，为了保证系统投产后性能稳定，首先对开发环境提供一定的 硬件资源进行评估。硬件规划一般分为两类：一类是开发出的产品要在不同的硬件环境上进行如小型机（Unix 系统）和 PC Server（Windows 系统）因此需要进行和性能测试相关的硬件资源规划；另一类是开发出的产品 对投产环境的硬件配置要求较高，这个时候做性能测试规划就要对硬件资源环境进行规划。 2. 测试环境维护方面的规划 常见方法： 用 Ghost 软件保证环境：反复用 Ghost 类维护一些环境 用 VMWare 保证环境：VMWare 可以在同一台电脑上构建出多个测试平台，能节约一定的成本，缺点是对机器 硬件配置要求较高 备份/恢复策略：备份/恢复主要针对数据库，通过反复的备份/恢复可以重现测试中发现的性能问题，为调优 提供有力的依据。 3. 测试工具规划： 1） 常见的性能测试工具 (1) LoadRunner:(2) Rational Performance (3) QALoad (4) WebLoad： 专门用于 Web 性能测试的工具， 使用比较简单。 WebLoad 支持基本的代码录制与资源监控功能。 (5) WAS：微软提供的免费性能测试工具 (6) Apache JMeter：开源性能测试工具 (7) OpenSTA：开源性能测试工具 2） 选择工具策略：主要从工具特性、工具核心功能、购买价格三个方面来考虑 了解测试工具特点 了解工具的主要功能 了解工具的价格 3） 自己开发性能测试程序 4. 人力资源规划 性能测试团队角色与性能测试团队角色与职责 性能测试团队角色与性能测试团队角色与职责 角色名称 主要职责 确定性能测试策略与目标，制定性能测试计划。负责测试工作的整体协调，与开发、支 项目经理 持等其他团队成员进行协作和沟通，保证性能测试工作的顺利进行。 协助测试设计人员进行系统功能分析，找出系统的压力点，尤其是分析压力下核心业务 系统架构设计师 模块的运行情况。 测试设计人员 分析性能测试任务，根据性能测试需求设计相关的测试用例。 使用测试工具开发脚本、创建测试场景、运行测试、实时监控数据等，并提供测试结果 测试工具专家 数据，协助其他人员进行性能分析。 数据库系统分析员 根据测试结果数据分析库瓶颈，并对数据库进行系统性能调优。 Web Server 系统分析员 根据测试结果数据分析 Web Server 瓶颈，并对 Web Server 进行系统性能调优。 操作系统专家 为测试提供支持。主要是分析操作系统的运行情况，发现操作系统瓶颈并进行优化。性能测试计划制定 1. 明确性能测试策略和测试范围 2. 确定性能测试目标、方法、环境、工具 3. 确定性能策思团队成员以及职责 测试计划的人员安排 测试计划的人员安排 姓名 A B C D 角色 项目经理 测试设计员、工具专家 DBA、Weblogic 专家、系统管理员 用户代表 职责 负责真个测试项目的管理与协调工作。 。 设计并执行测试，分析系统瓶颈。 对系统进行调优。 在用户现场进行测试时，提供一些办公方面的支持。4. 确定时间进度安排 任务描述 编制性能测试计划 设计性能测试用例 设计阶段小结 设计阶段小结 执行测试用例 分析测试结果 执行阶段小结 编写测试报告 收尾阶段小结 人员 A B B、C B、C 测试计划的时间安排 角色 职责 项目经理 负责测试项目的管理与协调工作。 测试设计人员 设计并执行测试分析系统瓶颈 时间 工作量工具专家 测试设计人 员、工具专家执行测试 分析系统瓶颈A项目经理负责测试项目的管理与协调工作任务 性能测试需求分析 性能测试计划工作内容测试计划的里程碑 开始时间 成果结束时间负责人性能测试用例 设计与开发测试脚本 测试环境准备 执行测试 测试评估总结 5. 确定性能执行标准： 启动标准：主要指在什么情况下可以开始性能测试工作。e.g：系统功能测试结束、性能测试用例编制完成、 测试环境具备。 终止标准：主要指在什么情况下性能测试工作异常退出。e.g：性能用例通过率低于 20％、系统频繁崩溃。终 止是为了防止“为了测试而测试” ，提前结束无意义的性能测试可以避免浪费人力物力。 结束标准：主要指系统达到什么性能目标。e.g：性能达到或者性能方案中的预期指标。 6. 测试技能培训 7. 确定性能测试中的风险 新购买的测试工具不能完成某些特定的测试任务 如果自己开发测试工具，可能在规定的时间内完不成开发任务 系统新能太差，导致测试周期较长 某些核心的测试人员离职 执行测试的硬件环境步具备 …… 性能测试计划注意事项 1） 根据项目要求对上面的内容裁减。 2） 根据用户需求进行内容的调整与重组。 3） 计划要得到全部项目干系人的认可。 性能测试用例的设计 性能测试用例的设计是根据场景的不同进行设计的 普遍的三类测试场景 1． 一天内不同时间段的使用场景：在同一天内，大多数系统的使用情况都会随着时间发生变化。e.g：对于新浪、网 易等门户网站，在周一到周五早上刚一上班时，可能邮件系统用户比较多，而上班前或者中午休息时间则浏览新闻 的用户较多，而对于一般的 OA 系统则早上阅读公告的较多，其他时间可能很多人没有使用系统或者仅有少量的秘 书或领导在起草和审批公文。这类场景的任务是找出对系统产生压力较大的场景进行测试。 2． 系统运行不同时期的场景：系统运行不同时期的场景是大数据量性能测试用例设计的依据。随着时间的推移，系统 历史数据将会不断增加，这将对系统响应数度产生很大的影响。大数据量性能测试通常会模拟一个月、一季度、半 年、一年……的数据量进行测试，其中数据量的上限是系统历史记录转移前可能产生的最大数据量，模拟的时间点 是系统预计转移数据的某一时间。 3． 不同业务模式下的场景：同意系统可能会处于不同的业务模式，e.g：很多电子商务系统在早上 8 点到 10 点以浏览 模式为主，10 点到下午 3 点以定购模式为主，而在下午 3 点以后可能以混合模式为主，因此，需要分析哪些模式 是典型的即压力较大的模式，进而对这些模式单独进行测试，这样做可以有效地对系统瓶颈进行隔离定位。与“一 天内不同时间段场景测试”不同， “不同业务模式下的场景测试”更专注于某一种模式的测试，而“一天内不同时 间段的场景从测试”则多数是不同模式的混合场景，更接近用户的实际使用情况。 以上三种典型的场景，实际项目中分析场景时一般不会孤立地分析某以特定类型场景，而是把两种或者集中场景结合 起来进行分析设计，这样做主要是为了选择更典型的场景和节省一些测试版本。 各类测试用例的细节 1． 确定用户使用系统情况的方法。 ． 用户现场调查 分析系统日志 2． 并发用户数据量设计 ． 极限法： 取最大在线用户数作为对答并发数， 这种方法适用于系统已经投产或者目标用户群体不确定的门户网 站，可以通过分析日志来进行测试；也可以使用系统已经注册的用户数量作为系统的用户数量，然后按照经验 公式来估算最大并发用户数量。 用户趋势分析：对软件生存周期内的用户未来走势数目，这种方法多用系统用户数目逐渐增加的情况。 经验评估法： 按照经验来评估系统可能的最大并发用户数， 这种方法多用于系统的使用用户数目相对稳定并且比较明确的系统。 在具体的项目中，通常是其中的两种或者三种方法结合起来估计系统的最大用户数量。如下例子。 1） 某 OA 系统的使用用户为 600，预计使用周期内不会发生大的变化，通过分析日志得出最大在线数目为 200 左右 步骤 1：OA 系统得使用用户数目一般在系统使用人数得 5％~~20％之间，此系统得使用频度不高，因此我们估计最大 并发用户数量为总使用人数得 15％，根据经验得出第一个最大并发用户数 90（600×15％＝90） 步骤 2：通常 OA 系统的并发数为在线数的 30％左右，我们根据经验得出第二个最大并发用户数 60（200×30％＝60） 步骤 3：比较前面的结果，最后取 90 作为最大并发用户数目。 2） 对网上视频点播系统，可以看出系统最大在线用户数为 1000，系统假设使用一年，按照每年 200％的数度递增，则 最大在线用户数 3000，电影网站的并发数量一般为在线数的 50％左右，因此最大并发用户数量为 1500。 完成最大并发用户数量的评估后，接下来就可以设计每个用例要模拟的用户数量。 性能测试用例并发用户设计示例 性能测试用例并发用户设计示例 系统支持多个用户同时进行登陆邮件系统的操作。 功能 测试多用户访问邮件模块时系统的处理能力。 目的 模拟多个用户在不同客户端登录邮件，然后进行并发进入邮件系统的操作。 方法 并发用户数与事务执行情况 并发用户数 事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒） 100 200 300 可以看出并发用户数量的设计很简单，基本是按照最大并发数量的百分比来设计的，e.g：可以按照最大用户的 20％不 断增加来设计并发用户数量，直到达到最大并发用户数量。对于某一特定的用例，设计用户数量需要注意下面三点： 1） 按照各类用户同时递增的方式来设计用户数量， 按照递增的顺序设计测试用例是为了按照由浅入深的方法来发现系 统的瓶颈，因此系统的各类用户应该同时增加。 2） 并发用户数的最大值一般不会超过前面计算的最大用户数量的 20％，除非为为了测试系统能支持的最大并发用户 数量。 3） 设计用户数量时要考虑成本，因为每组用户数都意味着至少执行一次测试。 3． 系统不同时间段场景的设计： ． 不同时间段场景分析的数据来源主要时前面的需求分析和日志分析结果。 不同时间段 场景设计的基本原则有两个： 1． 选择典型的场景进行测试，尤其要选择场景中并发用户数目较大的场景。 2． 覆盖全面，即设计出的用例要覆盖到压力可能较大的时间段 4． 业务模式的设计： 也为模式的设计时不同时间段场景设计的特例， 也是设计核心模块和组合模块并发性能测试用例 ． 的基础，设计也为模式的目的是专注于某些功能模块的组合。 5． 大数据量测试用例的设计：主要分为 1．历史数据引起的大数据量测试和运行时大数据量测试两种。 ．3.2 性能测试实施和监控1.实施性能测试 1) 开发阶段的性能测试实施 本阶段性能测试范围：开发阶段性能测试主要软件试运行前的性能测试。 测试环境管理与维护：测试环境对性能测试影响很大，直接决定着性能测试能否顺利进行。测试环境管理与 维护主要包含两个任务：1.根据项目需要协调各种资源，保证测试顺利进行；2.按照性能测试规划阶段制定的环境方案 来管理与维护环境。 测试执行-----录制、修改、运行脚本：测试执行大多借助工具完成，因此执行过程主要是按照工具的测试流程 来执行测试用例。 测试结果记录：应该在测试过程认真记录全部执行结果，这些测试结果数据是分析系统瓶颈的主要依据 以 LoadRunner 为例的性能测试执行流程 1． 创建虚拟用户脚本：实际上就是录制或者编写测试脚本 2． 参数化、修改脚本：脚本录制完成后的首要工作就是参数化，通过参数化实现虚拟用户的差异化操作。 3． 设计测试场景：测试场景主要在 LoadRunner 的 Controller 里完成。 4． 执行与监控测试场景：通过 LoadRunner 的 Controller 来完成执行与监控测试场景。 5． 分析测试结果：LoadRunner 通过 Analysis 完成最后的分析工作。分析对象主要是场景运行过程的数据。6． 对系统进行优化： 7． 优化后的测试： 2) 用户现场性能测试的实施 本阶段性能测试范围：用户现场性能测试主要是为了验收与调优，因此对于系统软件和特殊应用系统，性能 测试应该尽可能全方面覆盖。而对于一般应用系统，由于风险很低，则测试范围越小越好，这样做主要是为了节省成 本。用户现场的性能测试主要基于投产环境，测试对象多是即将准备投产的系统，甚至可能已经投产的系统。投产环 境的硬件资源配置通常较高，因此各类性能基本都可以开展。对于系统软件和特殊应用系统，这一阶段的性能测试主 要包括预期指标性能测试、并发用户性能测试、各类服务器性能测试、疲劳强度测试与大数据量性能测试等内容，基 本覆盖了“Web 全面性能测试模型”的各个方面。与开发阶段的性能测试相比，本阶段执行的性能测试用例通常会少 些。一般应用系统在用户现场的性能测试通常包含预期指标性能测试与用户并发性能测试，可能会对服务器进行一定 的测试，不过内容比较简单。一般应用系统发生性能问题的风险通常不会太高，因此只要通过验收测试即可。 测试环境管理与维护： 。用户现场性能测试环境管理与维护比较特殊，由于用户现场基本是投产或者即将投产 的环境，因此执行性能测试尽量不要破坏用户环境，而且要预先制定相应的备份/恢复策略，以便系统发生意外时可以 恢复到测试前的状态。用户现场测试环境管理与维护比较复杂，因该根据实际情况制定管理与维护方案，而且要保证 系统的正常运行或者试运行。 测试执行与测试结果记录：本阶段的测试执行过程和开发阶段性能测试执行过程大体一致 重点关注系统的整体性能 注意保护用户运行环境 可能受到用户的一些干扰 适时结束测试。 3) 监控性能测试执行过程 并发用户信息：主要监控用户是否能够正常登陆系统，登陆后是否能正常执行业务，如果用户运行不正 常可以考虑停止测试。 场景状态：主要监控运行时测试工具是否报错，发现错误时要对其认真分析。如果错误较多可以考虑停 止测试。 Web 服务器和数据库服务器：Web 服务器和数据库服务器的计数器是各阶段性能测试都要监控的重点。 当见识到一些异常时，很有可能时系统出现了瓶颈。 操作系统和硬件资源：资源不够用也是系统瓶颈的重要原因之一，当操作系统和硬件资源监控到异常时， 通常停止测试，并对原因进行分析。 尤其要注意，测试时还要监控测试机的使用情况，除非保证场景消耗的资源不会超出测试机的负载能力，否 则就应该认真监控测试机，因为一旦测试机发生瓶颈，所有测试结果均无实际意义。3.4 性能测试总结性能测试规划总结 1. 测试环境规划是否合理 2. 人力资源安排是否合理 安排的人力是否保证项目的进度。 团队成员是否胜任工作。 3. 测试工具规划是否合理 工具是否按照预期完成任务 工具的学习成本是否很高 2. 测试用例设计总结 测试用例设计总结 1. 测试用例可用性总结 2. 用例执行效果总结 3. 用例执行时间分析 3. 测试工具与技术总结 1. 测试过程的一些技术方面的总结 2. 测试工具的使用经验总结 4. 瓶颈分析方法总结 1. 应用系统瓶颈分析经验 2. 数据库瓶颈分析经验 3. Web 服务器分析 1.4.1 性能分析的基本原则任何复杂的系统无非分为网络和服务器两个部分，所以系统的瓶颈其实可以先确定在网络环节，还是服务器环节。如图 1，用户从客户端发起的请求数据包经过网路，传递到应用服务器，最后到达数据库服务器，服务器处理完毕 后按原路返回到客户端。这个处理过程中，可以把整个时间分为两段：一段是 Tn，即网路的响应时间；一段是 Ts，即 服务器的响应时间，包括应用服务器和数据库服务器的响应时间。对比 Tn 和 Ts，就很容易知道系统花在什么环节的响 应时间占大多数。判断系统的瓶颈是出现在网络段还是服务器段后，就可以进一步层层推进，判查相应环节的更细组 件的相应时间，知道最后找到造成性能问题的根本原因。所以性能分析的基本原则是“由外而内，由表及里，层层深 入”的原则。4.2 Web 应用程序分析1. 用户事务分析： 用户事务分析：是站在用户角度进行的基础性能分析。 loadRunner Analysis 和事务相关的分析图表有 事务综述、事务平均响应时间、每秒通过事务(总)数、事务性能 摘要、事务响应时间与负载分析、事务响应时间(百分比模式)、事务响应时间分布情况分析等 LoadRunner 有两种和事务相关的概念：Action 和 Transaction。Action 是用户的一系列操作的组合；Transaction 是用户某一具体的动作。 LoadRunner 中，事务有三种执行结果：1.通过(Pass)；2.失败(Fail)；3.停止(Stop) 1) 事务综述图(Transaction Summary) 2) 事务平均响应时间分析图(Average Transaction Response Time) 3) 每秒通过事务数(Transaction per Second：TPS) 4) 每秒通过事务总数分析图(Total Transaction per Second) 5) 事务性能摘要图(Transaction Performance Summary) 6) 事务响应时间与负载分析图(Transaction Response Time Under Load) 7) 事务响应时间(百分比)图(Transation Response Time(Percentile)) 8) 事务响应时间分布情况分布图(Transaction Response Time(Distribution)) Web 资源分析：是从服务器入手对 Web 服务器的性能进行分析。LoadRunner Analysis 主要通过 Web 资源图来分析 资源分析： 场景运行期间点击率、吞吐率、每秒 HTTP 响应数、每秒连接数据等测试数据。 1) 点击率： “每秒点击次数” 即点击率图显示在场景运行过程中虚拟用户每秒向 Web 服务器提交的 HTTP 请求数， 可依据点击数来评估虚拟用户产生的负载量，还可将其与“平均事务响应时间”图进行比较，以查看点击次数 对事务性能产生的影响。 2) 吞吐率：显示场景运行过程中服务器每秒的吞吐量。吞吐量的度量单位是字节，表示虚拟用户在任何给定的某 一秒上从服务器获得的数据量。可以依据服务器吞吐量来评估虚拟用户产生的负载量。 “吞吐率”与“点击率” 图形基本类似，区别是“点击率”图是每秒服务器处理的 HTTP 申请数， “吞吐率”图是客户端每秒从服务器 获得的总数量。 流量是服务器处理能力的重要体现， 当超过系统能够处理的最大流量时， 服务器就会发生异常。 通过吞吐率图，可以看出服务器在流量方面的处理能力以及是否存在瓶颈。 3) 每秒 HTTP 响应数：显示场景运行过程中每秒从 Web 服务器返回的不同 HTTP 状态代码的数量。 4) 每秒连接数图：在运行过程中每秒新建立的 TCP/IP 连接数。 网页元素细分 1) 页面元素细分：可以显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。可以以四2.3.种方式进一步细分。 下载时间细分：可以显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的 颜色来显示 DNS 解析时间、建立连接时间、第一次缓冲时间等各自所占的比例。 组件细分：显示选定网页的页面组件随时间变化的细分图 下载时间细分(随时间变化)：选定网页的页面元素下载时间细分。 第一次缓冲时间细分(随时间变化)：显示选定网页的第一次缓冲时间细分 2) 页面组件细分：每个网页及其组件的平均下载时间(以秒为单位) 3) 页面组件分解：显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间(以秒为单位)。要确定那些 组件引起了响应时间延迟，可以通过在网页细分树中双击有问题的组件，对其进行一步细分。通过进一步细分 的“页面组件分解”可以跟踪主要组件中哪些问题最严重，以及在方案运行期间出现的时间，有助于隔离有问 题的组件。 4) 页面下载时间细分： 显示每个页面组件下载时间的细分， 可以根据它确定在网页下载期间事务响应时间缓慢是 由网络错误引起还是由服务器错误引起。页面下载时间细分图根据 DNS 分析时间、连接时间、第一次缓冲时 间、SSL 握手时间、接收时间、FTP 验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。 5) 页面下载时间细分：显示方案运行期间，每一秒内每个页面组件下载时间的细分 6) 第一次缓冲时间细分：显示成功收到从 Web 服务器返回的第一次缓冲之间的这段时间内的每个网页组件的相 关服务器/网络时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有 关。网络时间定义为从发送第一个 HTTP 请求那一刻开始，直到收到确认为止所经过的平均时间。服务器时间 定义为从收到初始 HTTP 请求确认开始，直到成功收到来自 Web 服务器的第一此缓冲为止所经过的平均时间。 7) 第一次缓冲时间细分(随时间变化)： 显示成功收到从 Web 服务器返回的第一此缓冲之前的这段时间内， 场景运 行的每秒中每个网页组件的服务器时间和网络时间。 可以使用此图确定运行期间服务器或网络出现问题的时间 点。由于要从客户端测定服务器时间，因此，从发送初始 HTTP 请求到发送第一个缓冲区数据这一段时间内如 果网络性能发生变化，则可能会影响分析结果。 8) 已喜爱在组件大小图： 显示每个已经下载的网页组件的大小。 通过它可以直接看出哪些组件比较大并需要进一 步优化提高性能。 以上介绍了 loadRunner Analysis 的网页细分方法， 网页元素细分技术是分析应用程序本身引起性能问题的非常 有效的方法。在实际性能分析工作中，通常不会孤立地分析某一“网页细分图”而是把各种“网页细分图”结合 起来进行分析，同时还要综合用户事务、Web 资源、数据库以及 Web 服务器等的测试结果进行分析 对 Web 应用程序进行分析时，还要对服务器进行分析，即对 Web 服务器、数据库服务器、操作系统以及软硬 件资源进行分析。服务器分析通常从 Web 服务器和数据库服务器入手。 服务器分析的第一步，就是分析测试工作对 Web 服务器和数据库服务器相关计数器的监控结果，然后确定在 压力下是 Web 服务较慢还是数据处理较慢 对于 Web 服务较慢的情况，首先要查看 Web 服务器的各种参数配置，e.g：最大连接数、最大内存等是否设 置的合理。Web 服务器基于操作系统运行，因此可以间接的了解到硬件资源是否够用，如果存在内存、CPU、硬 盘任何一个性能瓶颈，服务器都可能运行不正常。 对于数据处理比较慢的情况，通常都是数据库配置发生了问题，或者是硬件资源配置太低。数据库问题也是 首先要查看各种参数配置，e.g：Oracle，则要查看内存配置、运行模式等信息。通过数据库服务器的一些计数器， 也可以反应出其硬件资源是否够用。 性能测试的目的及时通过对测试结果的分析发现应用系统的性能瓶颈，同时找出引起性能下降的原因，为优 化系统提供依据。因此，分析系统性能瓶颈是性能测试最后的“攻坚战” 。实战5.1 构架设计阶段的性能测试案例描述：对象是四家国产数据库 案例重点关注下面三个方面： 如何根据项目需要来设计与开发测试程序 测试工具在性能测试中的作用与地位 针对数据库本身进行性能测试的方法项目背景： 本项目是一个国家投资开发的大型网上税务综合管理信息系统。出于信息安全的需要，同时也为了更好 地支持国产软件地发展，经项目管理委员会研究，该系统的操作系统、数据库、中间件、资处理系统等支持 平台均采用国产软件。 系统有一个基于 Windows 平台的原型系统， 已经使用了近五年的时间， 里面有 100 万条左右的数据记录。 原型系统可以作为新系统开发时的参照， 其业务模型可以作为测试设计分析时的参考， 100 万条数据记录可以 作为测试时的示例数据。 新项目提出了较高的性能需求----要求 50 个用户并发时系统响应时间不得高于 2 秒， 系统得响应速度不能 因数据数据量得增加而下降，在性能方面给系统架构设计组提出了较高的要求。系统架构组觉得设计难度较 大，因此首先提出国产数据库能否有如此快的响应速度，如果数据库较慢，将不可能设计出符合的目标的系 统。 在这种背景下，首先进行国产数据库的测试评估就在所难免了，进行评估主要有两个目的：一是了解国 产数据库的性能，为系统架构设计提供参考；二是选择整体性能相对优异的数据库。通过评估选择性能优异 的数据库进行支持，不但保证了整个系统的性能，还节省了一定的开发成本。 2. 性能测试策略、目标、范围、环境 本案例的性能测试策略很简单，就是按照架构组提出的要求在规定的时间内完成测试工作，提交数据库 评测报告。 测试目标就是在各家数据库厂商的配合下，对数据库进行综合性能调优，使之符合项目的特定需求，即 数据库查询的响应时间小于 2 秒。 性能测试范围主要包括两个过程： 1） 四家国产数据库系统调优前的查询性能。 2） 四家国产数据库系统调优后的查询性能， 同时还要测试国外 S 数据库同等条件下查询性能， 并与之进 行比较。 数据库服务硬件环境：Dell PC Server（CPU-----2×2.8G，RAM------2G，硬盘------3X36G（RAID5） ） 操作系统：Red Flag Linux DstaCenter4.1 3. 性能测试分析与设计 系统架构组对数据库提测试出了如下要求 1） 测试数据库对复杂 SQL 语句的支持，尤其使一些长 SQL 语句的支持 2） 测试数据库对二进制等格式类型存储的支持 3） 测试系统在数据量较大时的多用户并发查询的响应时间----查询响应时间为 Web 服务器对数据库响应时间， 不包括应用系统响应时间。 通过分析可以看出，前两项属于对数据库的功能进行测试，也是出于对国产数据库的不信任而提出的。因为这两 项都属于数据库的基本功能，而几家国产数据库至少拥有十年历史的成熟产品，没有必要进行专门的测试，最后一项 才是性能测试需求。 对于前两项关于数据的功能测试，很容易编写程序进行验证，因此本案例不作为重点进行讨论。本案例的性能测 试内容在最后一项，也就是并发查询的性能测试，在接下来的内容里，将重点讨论如何对四家国产数据以及 S 数据库 进行并发查询性能的测试。 首先讨论一下本案例的性能测试设计思路。 1） 由于是没有应用的纯粹数据库测试，需要自己开发简单的程序。 2） 由于测试结果要求显示的数据响应时间为从 WebServer 发出申请到数据库返回结果的时间， 因此开发的程序不 应该包含过多的无关功能。 3） 新开发的系统为 J2EE 构架，所以测试程序也应该基于 J2EE 构架 根据上面的测试要求的分析，设计出如下性能测试方案。 1） 测试体系采用 B/S 架构方式，对数据库的查询操作封装在 Servlet 中，Servlet 运行于 TomCat5.0 上，前端采用 JSP 网页调用 Servlet 并输出执行结果(数据库执行查询的时间)和查询结果(数据库返回的查询结果)1.JSP 客户 端Servlet 运 行于 TomCat5.0目标测试数 据库数据库测试示意图 2） 利用原型系统后台数据库的数据作为测试数据，保证测试结果更加真实。 3） 测试采用的查询语句用原型系统的业务语句，保证测试兼顾实际应用。4） 通过测试工具 LoadRunner 来创建虚拟用户，实现用户并发查询。 5） 通过测试结果来综合分析各家数据库的性能。 下面是性能测试的主要场景设计。 1） 1 到 50 个用户的并发查询场景设计 测试采集的数据分为两类，一类是数据库响应时间，通过程序中的 JSP 页面输出，具体方法是在测试工具施加 压力的同时，手工通过 IE 打开网页，Servlet 在页面上输出数据库响应时间；另外一类是页面响应时间，即从页面 调用 Servlet 开始到得到查询结果的时间（不包含在页面上输出结果的时间） ，可以通过测试工具直接查看测试结 果； 下面是设计的测试用例以及场景。 数据库优化前场景：系统总数数据量----10 万逐渐加到 100 万，主表数据量-----7 万，返回记录数-----20，不断 增加用户数进行测试； 数据库优化后场景：系统总数据量------100 万，主表数据量-----70 万，返回记录数----20，不断增加用户数进行 测试。 测试结果记录表格 页面响应时间 数据库响应时间 用户数 D R O G S D R O G S 1 5 10 50 2） 数据库系统稳定性场景设计 预计系统并发查询一般在一分钟以内结束，最大并发用户数小于 50，因此设定如下表所示的场景来测试各家数据 库系统的稳定性 数据库稳定性场景设计 组号 并发用户数 开始执行查询时间 执行查询时间 1 50 场景开始时执行 1 分钟 2 50 场景开始 3 分钟后执行 1 分钟 3 50 场景开始 6 分钟后执行 1 分钟 4 50 场景开始 9 分钟后执行 1 分钟 5 50 场景开始 12 分钟后执行 1 分钟 6 50 场景开始 15 分钟后执行 1 分钟 7 50 场景开始 18 分钟后执行 1 分钟 8 50 场景开始 21 分钟后执行 1 分钟 9 50 场景开始 24 分钟后执行 1 分钟 10 50 场景开始 27 分钟后执行 1 分钟 稳定性能测试安排在各个阶段的常规性能测试结束后进行，系统总数据量----100 万，主表数据量-----70 万，返回记 录数 20。 性能测试分析与设计完成后，就进入到后面的性能测试实验阶段。 性能测试实施 1． 测试脚本的开发与修改：通过 LoadRunner 的 Virtual User Generator 录制脚本，脚本包含的内容为直接调用 Servlet。 2． 数据库系统调优前的测试：系统调优前，各家数据库分别从原有系统导入了业务数据库三个表的数据，共计 10 条， 同时还导入了系统权限管理数据库的相关表的数据。 调有钱的测试基本属于一种试探测试， 原来计划分别执行的数 据量为 10 万、30 万、50 万、100 万的性能测试，但是在执行 10 万条记录查询的结果就已经不符合系统期望目标， 测试工作临时终止。 3． 数据库系统调优后的测试：调优前的性能测试给几个国产数据库厂商很大的压力，因为按照目前的性能，各家数据 库都是不符合项目的性能需求的， 很有可能各家均被淘汰， 于是各家数据库厂商投入了较大的人力对系统进行优化。 系统调优后，各家数据库性能都有显著提高，其中有三家的数据库符合了项目的需求 测试结果分析 1． 各家国产数据库调优前的测试结果及分析 页面响应时间 数据库响应时间 用户数 D R O G S D R O G S 1 526 491 508 1885 null 515 485 484 1859 null 5 42 9876 null 16 7688 null 10 21 15121 null 84 13656 null20 476 30181 null 265 25250 null 50
null 通过上面的测试结果可以看出，即使最快的 D 数据库，10 个用户并发的平均响应时间已经超过了 3 秒，如果和应 用结合起来，在性能方面肯定是不符合项目要求的。 因此，性能测试直接进入了到调优阶段，如果各家数据均达不到项目需求，很有可能均不采用。 2． 数据库调优策略 各家主要采用了三种常见方法对数据库优化：一是修改 SQL 语句中影响速度的写法；二是增加或者修改索引，三是 调整相应数据库的系统参数。 3． 各家国产数据库调优后的测试结果分析 调优后各家数据库查询测试结果 数据库响应时间/页面响应时间 毫秒） 页面响应时间（ 数据库响应时间 页面响应时间（毫秒） 用户数 G D R O S 1 24 43 43 59 49 63 55 61 21 40 5 168 219 233 270 271 335 373 432 169 219 10 229 328 343 441 420 556 615 740 228 322 20 347 545 520 768 679 978 4 489 50 724 93 90 6 调优后的国产数据库性能排名由原来的 D、R、O、G 变成了 G、D、R、O，各家数据库性能均有较大的提高，综合 起来可以得出下面的测试结论。 1) G、D、R 三家数据库在 50 个用户并发查询时，响应时间小于 3 秒，符合项目的测试目标。 2) 国产数据库的性能均没有超过 S 数据库，说明国产数据库在性能等方面仍然与国外数据库存在差距。 3) 国产数据自动配置能力很差，需要进行较大的调整才可以达到一定的稳定状态，这意味着后面实施具体的项 目时仍然需要对数据进行适当的配置调整。 4． 稳定性测试场景分析 各家数据库综合测试结果 大对象功能支 …… 数据库名称 复杂语句支持 并发查询性能 吞吐量 数据迁移 持 D …… 通过 通过 通过 通过 通过 R …… 通过 通过 通过 通过 通过 O …… 通过 通过 未通过 未通过 通过 G …… 通过 通过 通过 通过 未通过 通过上表可以看出，D、R 数据库在功能、性能、吞吐量等方面通过了测试，而 O、G 数据库则没有通过全部的测 试项。 5． 案例点评 1） 体现了模型裁减与具体化原则 本案例涉及了“Web 全面性能测试模型”两部分内容：用户并发测试与大数据量测试。其中用户并发测试可以 理解为核心业务性能测试，因为用户并发测试执行的查询语句采用的是和原型系统核心业务的某些关键语句； 而大数据量测试仅仅包含了静态大数据量的测试，即系统运行一定时间的大数据量测试，不涉及其他内容。 2） 节约了一定的开发成本 3） 仅仅有测试工具是不够的 4） 调优不能解决一切问题5.2 某企业 OA 系统测试案例1． 项目背景、测试策略、范围 ． 项目背景、测试策略、 用户仅提出的一项性能要求是系统要满足 2000 人正常视同。更具经验，2000 人使用的 OA 系统，预计并发用户数 量约在 200―400 之间，而在客户的小型机平台上，OA 系统是很容易满足 200―400 个用户并发即 2000 个用户的使用 的。所以性能测试的主要目标是向客户证明满足合同要求，进而顺利地拿到“合同款” 。 根据 Web 性能测试策略模型，制定如下的性能测试策略：在系统测试阶段开始着手性能测试工作，然后在验收阶 段和用户一起实施性能测试，以尽可能低的成本来完成测试任务。 根据用户的要求，性能测试的内容主要就是用户并发测试（也可以说是预期指标性能测试，因为并发用户数量范围是用户提出的） ，其他方面的测试为了节省可以忽略。 2． 性能测试用例设计 ． 根据前面的性能测试策略，性能测试用例没有必要覆盖全部的功能模块，只要抽测一些核心模块即可。分析整个系 统，可以看出使用最频繁的就是邮件系统，因此选择邮件系统作为典型模块来做并发用户性能测试。 虽然预计并发用户数在 200~~~400 之间， 但是我们测试时的最大用户数量应该更大一些， 因此设计的用例把最大用 户并发数量定为 500。 （在本案例后面的内容中，读者可以看到测试的最大用户书量实际已经达到了 800 个，这样做主 要是为了充分得到用户的认可，提高其对产品的满意度。 ） 根据前面的分析，我们设计用例应该力求简单，因此重点设计一些典型用户的操作。执行测试时每个用例对应一组 脚本，通过测试工具对这些脚本进行组合，实现了用户并发操作的差异化。 测试用例设计涉及的内容主要有登陆、查看邮件、接收邮件、上传文件、删除等邮件模块的功能，这样设计的目的 是为了使测试用例覆盖 OA 系统用户的基本操作----增加、删除、修改、查看等。 测试用例详细内容如下。 1. 登录办公系统 登陆 OA 系统测试用例 系统支持多个用户并发登陆 功能 测试多用户登录时候系统的处理能力 目的 模拟多个用户在不同客户端登录，然后进行并发进入系统的操作 方法 并发用户数与事务执行情况 并发用户数 事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒） 100 200 500 2. 进入邮件系统 登录邮件系统测试用例 系统支持多个用户同时进行登录邮件系统的操作 功能 测试多用户访问邮件模块时系统的处理能力 目的 模拟多个用户在不同客户端登录邮件模块，然后进行并发进入邮件系统的操作 方法 并发用户数与事务执行情况 并发用户数 事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒） 100 200 500 3. 接收邮件 接收邮件测试用例 系统支持多个用户同时进行在线接收邮件的操作 功能 测试多用户接收邮件时系统的处理能力 目的 模拟多个用户在不同客户端登录邮件模块，然后进行并发接收邮件的操作 方法 并发用户数与事务执行情况 并发用户数 事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒） 100 200 500 4. 阅读邮件 阅读邮件测试用例 系统支持多个用户同时进行在线阅读邮件的操作 功能 测试多用户阅读邮件时系统的处理能力 目的 模拟多个用户在不同客户端登录邮件模块，然后进行并发阅读邮件的操作。 方法 并发用户数与事务执行情况 并发用户数 事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒） 100 200 5005.发送邮件（无附件） 发送无附件的邮件测试用例 系统支持多个用户同时进行在线发送邮件（无附件）的操作 测试多用户发送邮件（无附件）时系统的处理能力 模拟多个用户在不同客户端登录邮件模块，然后进行并发发送邮件的操作 并发用户数与事务执行情况 事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒）功能 目的 方法并发用户数 100 200 500 6.发送邮件（带 1M 附件） 功能 目的 方法 发送带 发送带附件的邮件测试用例 系统支持多个用户同时进行在线发送邮件（带 1M 附件）的操作 测试多用户发送邮件（带 1M 附件）时系统的处理能力 模拟多个用户在不同客户端登录邮件模块，然后进行并发发送邮件的操作 并发用户数与事务执行情况 事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒）7.并发用户数 100 200 500 删除邮件 功能 目的 方法8.并发用户数 100 200 500 退出系统 功能 目的 方法删除邮件测试用例 删除邮件测试用例 系统支持多个用户同时进行在线删除邮件的操作 测试多用户阅读邮件时系统的处理能力 模拟多个用户在不同客户端登录邮件模块，然后进行并发删除自己邮件的操作 并发用户数与事务执行情况 事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒）并发用户数 100 200 500 3． 性能测试实施 ． 模拟用户数量退出 OA 系统的测试用例 系统在多个用户同时进行退出系统时运行正常 测试多用户退出系统时系统的处理能力 模拟多个用户在不同客户端登录，然后进行并发退出系统的操作 并发用户数与事务执行情况 事务平均响应时间 事务最大响应时间 事务成功率平均流量（字节/秒）50100OA 系统的测试测试实施过程 测试内容 测试结果 模拟的用户全部登陆后，自由接收、发送、 浏览邮件，使用邮件系统的常用功能。 通过测试。 模拟 20 个用户在同一时刻进行同一操作的 并发测试 模拟的全部用户登录后，自由接收、发送、 浏览邮件。 通过测试。 模拟 50 个用户在同一时刻进行同一操作的 并发测试。备注按照用例进行测试按照用例进行测试通过测试用具评估系统是否支持 200～300 根据用户要求调整了 个用户用户并发访问系统。 测试用例：用户要求 模拟用户的操作有： 不要测试单一模块。 200～300 通过测试。 因此增加了公文模 邮件模块：发送 1M 邮件、接收邮件； 公文模块：查看文件、查看稿纸、起草文件、 块，进行组合模块并 上传文件。 发测试 通过测试用具评估系统是否支持 300～500 个用户用户并发访问系统。 通过测试，多数操作 模拟用户的操作有： 的响应时间在 10 秒 至此已经证明系统符 300～500 邮件模块：发送 1M 邮件、接收邮件； 左右，属于用户可以 合用户的要求 公文模块：查看文件、查看稿纸、起草文件、 接受的范围。 上传文件。 通过测试用具评估系统是否支持 500～800 由于前面测试结果较 个用户用户并发访问系统。 没有通过测试，系统 好，因此用户想知道 模拟用户的操作有： 能支持 752 个用户的 500～800 系统能够支持的最大 邮件模块：发送 1M 邮件、接收邮件； 并发操作，但是运行 并发用户数量，于是 公文模块：查看文件、查看稿纸、起草文件、 速度下降很多。 进行了这项测试 上传文件。 以上的性能测试实施内容都是和用户一起进行的，因此直接得到了用户的认可。尤其是后面的一些测试，测 试人员按照用户的要求进行了合理的调整，使测试结果的可信度更高，最后用户十分满意地接受了性能测试结果。 4． 测试结果分析 ． 1. 200～300 个用户并发 200～300 个用户部分测试结果数据 ～ Transaction Name Minimum Average Maximum 90 Percent 0.358 7.097 31.887 8.535 上传文件 0.013 1.713 12.967 8.245 发送 1M 邮件 0.056 5.8 35.091 6.274 接收邮件 接收邮件 0.246 6.625 67.535 7.699 查看文件 0.007 2.062 13.814 8.256 查看稿纸 1.937 8.124 20.316 8.29 起草文件 结果分析： 通过上面的测试结果数据可以看出系统在 200～300 用户范围内响应时间正常，大多数操作响应基本在 8 秒左右，说明系统能够支持 1000 到 1500 以上的使用人数 2. 300～500 个用户并发 300～500 个用户部分测试结果数据 ～ Transaction Name Minimum Average Maximum 90 Percent 0.359 10.72 36.74 9.467 上传文件 0.013 10.451 23.326 10.647 发送 1M 邮件 0.056 7.808 52.926 80.1 接收邮件 0.253 9.079 80.012 10.506 查看文件 0.007 1.996 23.38 6.79 查看稿纸 2.124 10.264 25.332 10.75 起草文件 结果分析： 响应时间有些变慢，大多数操作响应基本在 10 秒左右 系统能够支持 1500 到 2500 以上的用户 本测试可以证明系统符合用户的需求，大多数操作系统在用户可以接收的范围之内 3. 500～800 个用户并发 Transaction Name 上传文件 发送 1M 邮件 接收邮件 查看文件 500～800 个用户部分测试结果数据 ～ Minimum Average 0.359 10.72 0.013 10.451 0.056 7.808 0.253 9.079 Maximum 36.74 23.326 52.926 80.012 90 Percent 9.467 10.647 80.1 10.506查看稿纸 起草文件0.007 2.1241.996 10.26423.38 25.3326.79 10.75结果分析： 可以看出用户超过 500 之后系统响应时间变长，多数操作超过了 10 秒，而这种响应时间使用户不可以忍 受的 最大并发用户数约在 700 左右（结果数据来源于测试过程记录） 5． 案例点评 ． 本案例的测试项目可以说使一个技术难度相对较低的项目，主要进行了一些关于并发用户的性能测试，强度、大数 据量等难度较大测试都没有涉及，测试的业务也仅涉及一两个模块。 虽然本项目很容易完成，但是仍然在执行过程重贯穿着“Web 全面性能测试模型”的使用原则，按照模型来执行 性能测试任务。e.g：在测试用例设计重，充分体现了节省成本、对模型进行裁减等原则。 尤其值得一提的是测试执行过程中，充分体现了对客户的尊重----按照客户的意见适当调整了测试方案，最后完成 了验收测试任务。 下面详细介绍一下本案例的执行特色 1） 体现了成本节约原则 本软件属于一般应用软件，这个特点决定了软件自身方面对性能要求不高，因此就没有必要投入过大的成本，节约 成本主要体现在以下三个方面。 只进行了必要的测试。该项目属于产品的二次开发，因此对产品的质量很有信心，只花了大约 1 个用作来设计测试 用例，节省了大量的测试设计时间。 测试实施在验收阶段开始。 只和用户进行一些满足预期指标的并发用户测试， 最大限度地压缩了性能测试的工作量， 实际真个项目测试实施大概花了 3 个工作日左右。 执行测试时进行适当的调整。可以看出执行性能测试用例时，一些不是特别重要的测试用例没有执行，e.g：登录 并发用例。 2） 体现了尊重用户的服务态度 3） 按照策略对测试用例进行了适当的裁减 本项目设计的测试用例与 Web 全面性能测试模型中的用例设计模型相比，只包含了与预期性能指标相关的测试用 例和部分并发用户测试用例，充分体现了用例设计服从整体测试策略的模型思想。 适当裁减原则时 Web 全面性能测试模型重要使用原则之一，通过这种手段使测试用例更加满足具体项目的特殊需 求，从而达到节约测试成本的目的。模板性能测试计划模板A.1 项目背景 A.2 测试方案简介 A.2.1 测试策略与目标 明确测试策略与目标 A.2.2 测试范围描述 描述本次性能测试涉及的范围 A.2.3 测试工具描述 描述用到了什么性能测试工作 A.3 测试环境与资源 A.3.1 硬件资源 描述性能测试过程中需要的硬件资源 A.3.2 人力资源 明确性能测试团队的人员安排和职责 A.4 项目里程碑 任务 工作内容 成果开始时间结束时间负责人A.5 技能培训计划培训内容参加人员时间A.6 风险分析 分析本次性能测试过程中的风险 A.7 计划结束标准 性能测试计划结束标准性能测试用例模板A.1 文档介绍 A.1.1 文档目的 A.1.2 文档范围 A.1.3 读者对象 A.1.4 参考对象 A.1.5 术语与解释 缩写、 缩写、术语解释A.2 测试需求分析 A.2.1 被测试对象的介绍 A.2.2 测试范围与目的 A.2.3 测试环境与测试辅助工具的描述 A.3 性能测试用例 A.3.1 预期性能指标测试用例 1． 指标 A 描述 001 用例编号 性能描述 用例描述 前提条件 特殊的规程说明 用例间的依赖关系 输入/动作 步骤 输入 动作 1 示例：典型值 2 示例：典型值 2． 指标 2 描述 002 用例编号 性能描述 用例描述 前提条件 特殊的规程说明 用例间的依赖关系 输入/动作 步骤 输入 动作 1 示例：典型值 2 示例：典型值 A.3.2 用户并发测试：核心模块 1． 核心模块 A 测试内容描述 功能 目的 方法期望的性能（平均值） 期望的性能（平均值）实际性能（平均值） 实际性能（平均值）回归测试期望的性能（平均值） 期望的性能（平均值）实际性能（平均值） 实际性能（平均值）回归测试并发用户数事务平均响 事务平均响并发用户数与事务执行情况 事务最大响 平均每秒处 事务成功率每秒点击率平均流量（ 平均流量（字应时间 20 25 30 35应时间理事务数节/秒） 秒并发用户数与事务执行情况 40 45 50 并发用户数 20 25 30 35 40 45 50 CUP 利用率 并发用户与数据库主机 MEM 利用率 磁盘 I/O 情况 DB 参数 1 其他参数并发用户数 20 25 30 35 40 45 50 A.4 核心模块 A 测试内容描述 A.4.1 用户并发测试：组合模块 1． 模块组合描述 A 功能 目的 方法并发用户数与应用服务器 并发用户数与应用服务器 CUP 利用率 MEM 利用率磁盘 I/O 情况事务平均响应时间 并发 用户 数 20 25 30 35 40 并发用户数 20 25 30 40 并发用户数 业务 1 业务 2 业务 3并发用户数与事务执行情况 平均每秒事务数 事务最大响应时间 业务 1 业务 2 业务 3 业务 1 业务 2 业务 3事务成功率 业务 1 业务 2 业务 3 每秒 点击 率平均 流量 （字 节/ 秒）CPU 利用率并发用户数与数据库主机 MEM 利用率 磁盘 I/O 情况DB 参数 1其他参数并发用户数与应用服务器的关系 CUP 利用率 MEM 利用率磁盘 I/O 情况20 25 并发用户数与应用服务器的关系表 30 35 40 2． 模块组合描述 B A.4.2 大数据量测试 1． 大数量场景 A 描述 功能 目的 方法 并发数用数与事务执行情况 事务最大响 平均每秒处 事务成功率 应时间 理事务数输入说明事务平均响 应时间每秒点击率平均流量 （字 节/秒）2． 大数量场景 B 描述 功能 目的 方法 并发数用数与事务执行情况 事务最大响 平均每秒处 事务成功率 应时间 理事务数输入说明事务平均响 应时间每秒点击率平均流量 （字 节/秒）A.4.3 疲劳强度测试 1． 疲劳强度测试场景 A 描述 极限名称 A 前提条件 运行时间 输入动作 例如 10 个用户并发操作 例如 20 个用户并发操作 …… 故障发生的时刻 任务 A 无故障运行的平均时间间隔 任务 A 无故障运行的最小时间间隔 任务 A 无故障运行的最大时间间隔输出响应是否能正常运行故障描述（CUP 小时） （CUP 小时） （CUP 小时）2． 疲劳强度测试场景 B 描述 A.4.4 网络性能测试 1． 网路测试场景 A 描述 测试广域网网络资源在不同并发用户条件下的使用情况 目的 在不同的广域网宽带下（64K、128K、256K……）使用 LoadRunner 录制的日常业务 的应用脚本，以不同的并发数进行性能测试，记录各种用户连接数下，不同并发 方法 请求的性能变化；同时记录路由器端口的流量和其他数据。 运行时间用户并发数事务响应时间端口流量丢包率性能测试报告模板A.1 文档介绍 A.1.1 目的 描述测试目的 A.1.2 预期读者 报告的读者 A.1.3 术语定义 报告中的属于说明 A.1.4 参考资料 报告用到的参考资料 A.2 测试环境描述 A.2.1 服务器软硬件环境 数据库服务器、应用服务器以及执行性能测试的机器软件和硬件配置情况 A.2.2 网络环境 描述本次性能测试涉及的网络环境 A.2.3 测试工具 测试采用的相关工具 A.2.4 测试人员 本次测试涉及的测试人员以及职责 A.3 性能测试用例执行分析 详细描述每个测试用例的执行情况以及测试结果分析 A.4 测试结果综合分析建议 本次性能测试的综合分析结果以及调整建议 A.5 测试经验总结 总结本次测试的经验教训
性能实战读书笔记―汇集和整理大量word文档,专业文献,应用文书,考试资料,教学教材,办公文档,教程攻略,文档搜索下载下载,拥有海量中文文档库,关注高价值的实用信息,我们一直在努力,争取提供更多下载资源。