《Web项目测试实战》性能测试需求分析章节样章
web项目测试流程和文档
web项目测试流程和文档Web项目测试流程和文档是确保Web应用程序质量的重要步骤。
以下是一个全面的测试流程和文档的示例：1. 需求分析和测试计划，在开始测试之前，测试团队应该仔细分析需求文档，并制定测试计划。
测试计划应包括测试的范围、测试资源、测试工具、测试时间表等信息。
2. 功能测试，功能测试是验证Web应用程序的各个功能是否按照需求文档的规定正常工作。
测试人员应该编写测试用例，覆盖所有功能，并记录测试结果。
3. 兼容性测试，兼容性测试是确保Web应用程序能在不同的浏览器、操作系统和设备上正常运行。
测试团队需要测试不同的浏览器（如Chrome、Firefox、Safari等）、操作系统（如Windows、Mac、Linux等）和设备（如PC、平板、手机等）。
4. 性能测试，性能测试是验证Web应用程序在各种负载条件下的性能表现。
测试团队应该进行负载测试、压力测试、并发用户测试等，以确保Web应用程序在高负载情况下也能正常运行。
5. 安全测试，安全测试是确保Web应用程序的安全性。
测试团队应该进行漏洞扫描、渗透测试等，以发现并修复潜在的安全漏洞。
6. 用户验收测试，用户验收测试是由最终用户或代表用户的人员进行的测试，以验证Web应用程序是否符合用户的期望和需求。
测试文档应该包括测试计划、测试用例、测试报告等内容。
测试报告应该清晰地记录测试结果，包括已发现的缺陷、缺陷的严重程度、缺陷修复情况等信息。
总之，Web项目测试流程和文档是确保Web应用程序质量的重要步骤，通过全面的功能测试、兼容性测试、性能测试、安全测试和用户验收测试，可以确保Web应用程序的质量和稳定性。
web项目性能测试方案
web项目性能测试方案任务：测试JBOSS环境下UBSS项目的性能目标：测试缴费部分（前台缴费，IC卡充值）在并发数从50-100递增的性能指标，不要求对结果进行分析步骤：1.搭建测试环境，要求与真实环境大概一致（关注在现有license情况下，UBSS系统支持的最大并发数）2.准备数据脚本（SQL和存储过程）3.准备测试脚本（Vuser scrīpts,scenario）4.进行性能测试测试范围针对UBSS项目，抽取对系统影响最大、最为典型的业务交易，构建场景，以此评判系统的整体性能和实际性能表现a.用户前台缴费b.标准用户IC卡充值测试内容1.基准测试概念：检查每个业务的基准响应时间（系统整体空闲，无额外进程运行并占用系统资源）方法：单用户运行业务多次，获取该业务的平均响应时间序号功能名称并发用户数循环次数操作间隔循环间隔1-1 前台缴费 1 100 3 31-2 IC卡充值 1 100 3 32.单个交易负载测试概念：设定负载序列，并发用户数为X｛20,30,50,....｝,收集系统单个交易在不同负载级别的性能表现方法：设置并发用户数等于X，关键步骤处设置并发点，每个用户运行N个iteration，获取平均响应时间和吞吐量用户登陆方式：每2秒登陆2个序号功能名称并发用户数循环次数操作间隔循环间隔2-1 前台缴费 5 50 3 32-2 前台缴费10 50 3 32-3 前台缴费15 50 3 3 注：响应时间超过30S2-4 前台缴费20 50 3 3 注：阻塞，不进行测试2-5 IC卡充值 5 50 3 32-6 IC卡充值10 50 3 32-7 IC卡充值15 50 3 32-8 IC卡充值20 50 3 33.组合交易负载测试概念：多个交易组合在一起，设定负载序列，并发数为X｛20,30,50,....｝，收集系统在不同负载级别的性能表现方法：设置并发总数，各用户数按比例分配，每个用户运行N分钟，获取平均响应时间和吞吐量序号功能名称并发用户总数比例持续时间操作间隔循环间隔3-1 前台缴费，IC卡充值 5 2：3 20m 3 3 3-2 前台缴费，IC卡充值10 2：3 20m 3 3 3-3 前台缴费，IC卡充值15 2：3 20m 3 3 3-4 前台缴费，IC卡充值20 2：3 20m 3 3 性能指标1.主机系统性能指标CPU使用率内存占用率磁盘读写2.数据库性能指标（略），可直接看应用系统所在主机情况3.中间件指标（略），可直接看应用系统所在主机情况4.业务指标平均响应时间最长响应时间吞吐率衩测系统环境描述1.系统架构J2EE架构，多层结构，即展示层、应用服务层、数据服务层 2.主机环境主机名型号主机IP CPU数内存磁盘用途数据库主机 192.168.1.8应用主机 192.168.1.33 1 2G3.软件环境项目信息备注操作系统 window xp 应用主机linux 数据库主机数据库 oracle10G中间件 EOS5.3 for JBOSS测试工具 LoadRunner8.1 破解4.数据库环境数据库实例 orcl数据规模用户数量：837,060客户数量：857,043帐户数量：832,727未缴费帐单：403,839IC卡用户信息：404,607发票数量：1,169,600用户表具信息：846,999计费策略：845,771已缴费帐单：5,593,9515，测试客户机序号 IP 操作系统配置用途1 192.168.1.30 window xp pentium4 3.2GHz memory 1G generator+controoler测试报告由anilys自动生成---------------------------------------------------------------系统性能测试方案1引言1.1编写目的编写本方案的目的是用于指导XXXX系统的性能测试,主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先计划和设计。
《Web性能测试实战》性能测试用例模板
《Web性能测试实战》性能测试用例模板1文档介绍1.1文档目的1.2文档范围1.3读者对象1.4参考文献1.5术语与解释解释缩写、术语2测试需求分析2.1被测试对象的介绍2.2测试范围与目的2.3测试环境与测试辅助工具的描述3性能测试用例3.1预期性能指标测试用例下面的测试方法比较详细，也可以根据实际需要把所有的指标写在一起，简要描述测试方法，以达到节省时间的目的（列出测试对象、期望的性能、实际性能三项即可以）。
1 指标A描述用例编号：001性能描述：用例目的：前提条件：特殊的规程说明：用例间的依赖关系：步骤输入/动作期望的性能（平均值）实际性能（平均值）回归测试1. 示例：典型值…2. 示例：边界值…3. 示例：异常值…4. …5. …6. …2 指标B描述用例编号：002性能描述：用例目的：前提条件：特殊的规程说明：用例间的依赖关系：步骤输入/动作期望的性能（平均值）实际性能（平均值）回归测试1. 示例：典型值…2. 示例：边界值…3. 示例：异常值…4. …5. …6. ………3.2用户并发测试:核心模块1 核心模块A测试内容描述功能目的方法并发用户数与事务执行情况并发用户数事务平均响应时事务最大响应时平均每秒处理事事务成功率每平均流量（字节/间间务数秒点击率秒）20253035404550并发用户数与数据库主机并发用户数CPU利用率MEM利用率磁盘I/O情况DB参数1其它参数20253035404550并发用户数与应用服务器的关系表并发用户数CPU利用率MEM利用率磁盘I/O情况202530354045502 核心模块B测试内容描述……3.3用户并发测试:组合模块1 模块组合描述A功能目的方法并发用户数与事务执行情况并发用户数事务平均响应时间事务最大响应时间平均每秒事务数事务成功率每秒点击率平均流量（字节/秒）业务1业务2业务3业务1业务2业务3业务1业务2业务3业务1业务2业务320253035404550并发用户数与数据库主机并发用户数CPU利用率MEM利用率磁盘I/O情况DB参数1其它参数20253035404550并发用户数与应用服务器的关系表并发用户数CPU利用率MEM利用率磁盘I/O情况202530354045502 模块组合描述B……3.4大数据量测试1 大数据量场景A描述编写用例的格式如下：功能目的方法并发用户数与事务执行情况输入说明事务平均响应事务最大响应平均每秒处理事事务成每秒点击平均流量（字节/时间时间务数功率率秒）2 大数据量场景B描述编写用例的格式如下：功能目的方法并发用户数与事务执行情况输入说明事务平均响应时间事务最大响应时间平均每秒处理事务数事务成功率每秒点击率平均流量（字节/秒）……3.5疲劳强度测试1 疲劳强度测试场景A描述极限名称A例如“最大并发用户数量”前提条件运行时间输入/动作输出/响应是否能正常运行例如10个用户并发操作例如20个用户并发操作…故障发生的时刻故障描述……任务A无故障运行的平均时间间隔（CPU小时）任务A无故障运行的最小时间间隔（CPU小时）任务A无故障运行的最大时间间隔（CPU小时）2 疲劳强度测试场景B描述……3.6网络性能测试1 网络测试场景A描述目的测试广域网网络资源在不同并发用户条件下的使用情况方法在不同的广域网带宽下（64K、128K、256K¡-.）使用LoadRunner录制的日常业务的应用脚本，以不同的并发数进行并发性测试，记录各种用户连接数下，不同并发请求的性能变化；同时记录路由器端口的流量和其他数据。
Web性能测试实战
Web性能测试实战2010年08月29日《Web性能测试实战》作者：陈绍英夏海涛金成姬著（2006年06月第1版第1次）电子工业出版社 Publishing House of Electronics Industry北京市海淀区万寿路173信箱（100036）内容简介本书是一本总结实践经验和成果的作品，主要为测试人员规划、设计、实施web性能测试而编写。
本书既包含web性能测试的基础理论，又包含理论在实践中的应用。
本书第1章介绍了性能测试基础知识和性能测试常见的误区。
第2章专门针对web性能测试提出了“web全面性能测试模型”，把制订性能测试策略、编写测试用例计划以及使用模型的方法融会在一起，提供了规划与设计性能测试的新思路。
第3章进一步讨论了如何在项目中进行性能测试需求分析、设计与实施性能测试，并深入讨论了基于场景设计性能测试用例的方法。
第4章则介绍了针对web应用程序进行性能分析的基本方法。
第5章是案例部分，分别以银行卡、电子政务、门户网站等典型web应用系统为实例，讨论了如何在项目中应用“web全面性能测试模型”。
通过真实的实例，向读者展示了如何在项目中制订性能测试计划、实施与控制性能测试、分析系统瓶颈等内容。
本书主要针对项目经理、测试组长、测试（设计）工程师以及对性能测试感兴趣的开发人员。
通过本书的学习，可以更加规范地做好性能测试设计与实施工作。
陈绍英，北京大学软件工程硕士.拥有多年的软件开发以及测试经验,现在主要从事软件测试工作,研究方向为软件测试过程管理和测试分析技术.性能测试等.拥有大型电子政务系统.银行卡业务系统等软件项目的测试管理及技术经验.善于组织和协调工作,在软件项目管理和测试管理方面拥有很高的能力,在工作中积累了丰富的管理经验.夏海涛，吉林大学计算机系硕士.拥有多个大型金融.电信.税务和电子政务系统等行业软件项目的测试项目管理及技术实施经验.熟悉Mercury系列的测试工具,并曾参与规划和实现基于以上工具的自动化回归测试和性能测试解决方案.曾经自行开发性能测试工具并成功付诸应用.主要研究方向为持续集成与自动化测试框架设计.自动化功能回归测试.大型项目群性能测试等.金成姬，博彦科技本地化工程师,从事日语.韩语等语种软件产品的本地化工作.P5，性能测试的重要概念请求响应时间：指的是客户端发出请求道得到响应的整个过程的时间。
14 Web系统性能测试实战
制定测试案例(续)
3.
4.
5.
6. 7.
在执行上述两种策略之一后，进入流量信息统计查询页面。 每个虚拟用户查询自己IP地址列表所对应的流量信息。 在上述操作完成后，虚拟用户点击页面中的“详细信息”链 接进入下一层查询页面。在这里，由于每个虚拟用户的“详 细信息”链接的内容是不同的。 在上述操作完成后，虚拟用户点击页面中的“详细信息”链 接进入第三层查询页面。同样需要改写测试脚本中“详细信 息”链接里IP地址的值为动态获得的值。 退出系统，整个操作完成。 在本次测试中，并发用户数设置为50，每个虚拟用户只执行 一次脚本而不循环多次。
Page 21
分析应用程序
描述系统配置
连接到系统的用户数 应用程序客户端的配置（硬件，内存，操作系统，软 件和开发工具） 使用的数据库和WEB服务器的类型（硬件，数据库类 型，操作系统和文件系统） 服务器和客户端的通信方式 前端客户端和后台服务器端的中间件配置和应用程序 服务器 可能影响响应时间的其他网络主件（调制解调器等） 通信设备的吞吐量和每个设备可以处理的并发用户数
Page 7
测试计划
制定一个全面的测试计划是负载测试成功的关键。定义明确的 测试计划将确保制定的方案能完成负载测试目标。 负载压力测试计划过程的4个步骤：
分析应用程序 对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的 了解。 定义测试目标 开始测试之前，应精确地定义想要实现的目标。 计划方案实施 确定如何实现测试目标 ，定义性能度量的范围，确定需要的 Vuser 的数量和类型 。 检查测试目标 测试计划应该基于明确定义的测试目标。如：度量最终用户响应 时间、定义最优的硬件配置、检查可靠性、查看硬件或软件升级、 评估新产品、确定瓶颈、度量系统容量等。
Web前端开发实训案例教程初级前端性能分析工具使用
Web前端开发实训案例教程初级前端性能分析工具使用Web前端开发实训案例教程初级前端性能分析工具使用随着互联网的快速发展，网页的性能优化也变得越来越重要。
在Web前端开发中，了解和使用前端性能分析工具，可以帮助开发人员更好地优化网页性能，提升用户体验。
本文将介绍一款初级前端性能分析工具的使用方法，并结合实际案例进行讲解，帮助读者快速上手。
一、什么是前端性能分析工具前端性能分析工具是用于分析网页性能的工具，它可以帮助开发人员找出网页加载速度慢、卡顿等性能问题的原因，并提供相应的优化方案。
常见的前端性能分析工具包括谷歌开发者工具（Chrome DevTools）、Firefox开发者工具（Firefox Developer Tools）等。
二、Chrome DevTools的基本使用方法1. 打开Chrome浏览器，进入需要进行性能分析的网页。
2. 按下键盘上的F12键，或右键点击页面空白处，选择“检查”。
3. 在打开的开发者工具界面中，点击顶部菜单栏的“Performance”选项卡。
4. 点击“Record”按钮，开始记录网页的性能数据。
5. 进行相应操作或加载页面，然后点击“Stop”按钮停止记录性能数据。
6. 在界面下方的性能分析面板中，可以查看网页加载整体耗时、渲染时间、JavaScript执行时间等详细信息。
三、应用实例：页面加载速度优化以一个简单的网页加载速度优化为例，介绍前端性能分析工具的具体使用方法。
1. 打开Chrome浏览器，进入需要优化的网页。
2. 按下键盘上的F12键，或右键点击页面空白处，选择“检查”。
3. 在开发者工具界面中，点击顶部菜单栏的“Performance”选项卡。
4. 点击“Record”按钮，开始记录网页的性能数据。
5. 进行页面加载操作，等待页面完全加载完毕。
6. 点击“Stop”按钮停止记录性能数据。
7. 在性能分析面板中，查看网页加载过程中存在的性能瓶颈。
范例(web系统性能测试报告)
***********系统性能测试报告南海东软信息技术职业学院YYYY年MM月DD日文档说明本文档所涉及到的文字和图表，仅限开发方和需求方内部使用，未经开发方的书面许可，请勿扩散到任何第三方。
目录1. 总述 (1)1.1 测试对象 (1)1.2 测试目的 (1)1.3 测试环境 (1)1.4 测试依据 (2)1.1参考资料 (2)1.2术语及缩写词 (2)1.3计算公式 (2)2. 测试方法 (3)2.1 测试模型 (3)2.2 测试过程简述 (3)2.3 需记录的数据 (3)3. 测试用例 (4)测试编号：1 (4)4. 测试结果 (5)4.1 查看记录内容 .................................................. 错误！未定义书签。
5. 测试结果分析 (6)6. 附件 (7)6.1 原始数据和计算结果 (7)《性能测试技术与实践》南海东软信息技术职业学院1. 总述1.1 测试对象web系统1.2 测试目的目的是在尽可能在模拟生产环境的前提下，实现以下目标：测试交易线处理程序在生产环境的业务和用户量下，性能能否满足业务人员操作的需求；模拟系统在生产能力峰值时的性能状况；通过较长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突，从而修复体系中的薄弱环节。
发现性能瓶颈，为后期性能调优提供参考依据。
验证稳定性与可靠性：在一个生产负荷下执行测试一定的时间来评估系统稳定性和可靠性是否满足要求。
1.3 测试环境1.4 测试依据1.5 参考资料1.6 术语及缩写词●测试时间：一轮测试从开始到结束所使用的时间●平均响应时间：测试线程向被测系统发请求，所有请求的响应时间的平均值。
●处理能力：在某一特定环境下，系统处理请求的速度。
●最大并发用户数：在给定的预期平均响应时间下，系统最多能支持多少个并发用户。
这个数据就是实际可以同时使用系统的用户数。
Web应用功能测试实战
Web应用功能测试实战随着互联网的快速发展，Web应用在我们日常生活中扮演着越来越重要的角色。
为了保证Web应用的质量，功能测试变得尤为重要。
本文将介绍Web应用功能测试的实战方法和注意事项。
一、概述功能测试是验证Web应用的各项功能是否正常工作的过程。
通过功能测试，我们可以发现并修复潜在的Bug，并确保用户可以顺利使用Web应用的各项功能。
在进行功能测试时，我们需要关注以下几个方面：1. 功能完整性：验证功能是否按照设计要求实现。
2. 功能正确性：验证功能是否输出正确的结果。
3. 功能一致性：验证功能在不同的环境和条件下是否一致。
二、测试准备进行Web应用功能测试之前，我们需要进行一些测试准备工作：1. 确定测试目标和范围：明确需要测试的功能和对应的测试范围。
2. 搭建测试环境：建立与实际环境相似的测试环境，包括硬件和软件环境。
3. 准备测试数据：根据测试场景和需求，准备相应的测试数据。
4. 编写测试用例：根据功能需求，编写详细的测试用例。
三、功能测试实战步骤进行Web应用功能测试时，可以按照以下步骤进行：1. 正确性测试：验证Web应用的功能是否按照需求规格说明书中的要求实现。
根据测试用例，逐个测试功能点，并验证其输出结果是否正确。
2. 完整性测试：验证Web应用的所有功能是否都已经实现，没有遗漏。
通过全面的功能测试，确保所有功能点都被覆盖到。
3. 一致性测试：验证Web应用在不同的浏览器、操作系统和网络环境下是否一致。
这是因为Web应用的用户可能使用不同的设备和环境来访问。
4. 兼容性测试：验证Web应用在不同的设备和浏览器上是否正常工作。
测试兼容性时，需要将Web应用在各种环境下进行测试，包括不同分辨率的屏幕、不同版本的浏览器等。
5. 异常处理测试：验证Web应用在异常情况下的处理能力。
例如，测试输入非法数据、网络异常、服务器崩溃等情况下，Web应用的应对措施和提示是否合理有效。
四、注意事项在进行Web应用功能测试时，还需要注意以下几点：1. 测试用例的质量：编写高质量的测试用例是进行功能测试的重要环节。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
5.1.2性能测试需求提取复习了一些常见的理论概念后，我们开始性能测试需求的提取。
这个过程是非常重要的，往往测试失败，就是因为在这个过程中不知道如何得到确切的性能指标，而导致测试无法正常开展。
性能测试需求提取一般的流程如图5- 1所示。
图5- 1性能测试需求提取流程分析提取指标在用户需求规格说明书中，会给出系统的功能、界面与性能的要求。
规范的需求规格说明书都会给出明确的性能指标，比如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，这些指标都会以可量化的数据进行说明。
如果，实际项目并没有这些正规的文档时，项目经理部署测试任务给测试组长时，一般就会说明是否要对项目的哪些业务模块进行性能测试，以及测试的要求是什么的。
最麻烦的就是项目经理或者客户要求给出一个测试部门认为可以的数据，这样非常难做的。
可是“甲方”往往都是提要求的，“乙方”只能“无条件”接受！表5- 1需求规格说明书中的性能要求表5- 1给出的指标非常明确，在测试过程中，我们只需收集用户登录模块的响应时间、登录成功率、并发数、CPU使用率、内存使用率的数据，然后与表5- 1的指标进行比较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。
大多数是没有明确的需求，需要我们自己根据各种资料、使用各种方法去采集测试指标。
以OA系统为例，假设《OA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试工程师自己分析被测系统及采集性能衡量指标。
分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终用户经常使用的业务点，那么我们的重点应该在放在该模块上。
一般我们可以从下面三个方面来确定性能测试点：第一、用户常用的功能。
常用的功能一旦性能无法满足，比如登录功能，从输入用户名与密码点击登录按钮到显示成功登录信息，花了5分钟，这样的速度是人无法忍受的。
而对于用户不常用的，比如年度报表汇总功能，三个季度甚至是一年才使用，等个10分钟也是正常的，这些是跟用户的主观感受相关的，得根据实际情况区分。
第二、系统业务逻辑复杂，数据流转频繁的功能。
这些地方最终用户可能看不到、用不到，但在系统是个关键点，没有它其他功能就不能正常工作，即使用户未提出做性能测试，作为测试部门也应该对这些地方进行性能测试，以保证他们能够正常工作。
第三、与外部系统的接口处。
有时候本系统需要使用其他系统的组件。
我做过的一个项目，B/S结构的企业信息管理系统，其用户管理模块中的用户数据就是使用早期C/S结构的ERP系统。
前一个使用Oracle数据，后一个是用Sybase数据，设定了每三个小时更新一下用户信息，以保证两个系统用户信息是一致的。
这样的功能，也是应该做测试的，特别是涉及到多系统的。
综合考虑，与考勤模块相关的是登录模块，因为登录是考勤的前置条件，所以在实际的测试中不仅要测试考勤的，还应该考察登录模块的性能表现，尽管这不是用户要求的。
OA系统是一个面向广大企业用户的办公自动化系统。
根据大多数公司的作息安排，早上九点基本是公司的上班时间。
那么根据实际业务分析，早上8:40到9:10可能是OA系统登录的高峰期。
因为很多人集中在这个时候达到公司进行考勤业务操作。
这个时候，就可以确定系统测试的一个时间段了。
接下来，需要调查一般会有多少人使用OA系统，这个数据比较难，应该公司的规模不一样，人数也就不一样。
既然是面向公众，那么就可以由开发工程师给出一个参考值，比如开发工程师说可以支持2000 人同时使用，那么我们就将使用系统的人数定为2000人。
既然说是2000人同时使用，我们可以理解为2000人在8:40到9:10这30分钟的时间里都要完成登录、考勤操作，并且不能有失败的业务。
也就是说业务的成功率要求在100%。
这样一来，到目前为止，得到了下面几个数据：1、OA系统使用高峰期为30分钟；2、并发使用人数为2000；3、登录、考勤成功率100%。
接着分析，在满足功能的同时，还需要考虑操作的响应时间。
很多公司都有迟到处罚制度，我原来的公司迟到一分钟扣五块钱，有的公司甚至更狠。
所以，如果应为页面反映慢而导致迟到，会“冤死”一批人，这样的问题绝对不能出现。
那么响应时间为多少算正常呢？说实话，这样的问题本身就是有问题的，何谓快，何谓慢？都是主观判断，你心急的时候觉得它慢，不急的时候觉得它快，所以没有一个定论，按照业内一个经验值，就是2、5、8或者3、5区分。
2秒或者3秒的功能结果响应时间是非常理想，5秒就有点让人觉得不爽了，而8秒，甚至更高很可能导致用户放弃操作，或者再次发起第二次请求。
这样的经验值在实际测试中对我们确定响应时间有很高的参考价值，当然响应时间还应该根据业务类型定，而不能仅从用户的感官考虑。
我们这里就采用常规的3秒为目标，也就是说OA系统处理登录、考勤业务的服务器响应时间不超过3秒。
除了软件的要求外，还应该对硬件资源进行监控，比如应用服务器的CPU使用率、内存使用率、带宽情况、Web服务器的资源使用情况等等，那么如果用户未提出要求，我们就按照常识走，CPU的使用率不超过75%，内存使用率不超过70%，其他指标这里就不列出了。
之所以选择这两数值，是因为他们具有代表性。
CPU的使用率超过75%可以说是繁忙，如果持续在90%甚至更高，很可能导致死机、机器响应超级慢等问题。
如果过低也不好，说明CPU比较空闲，可能存在资源浪费的问题。
对于内存存在同样的问题。
通过上面的分析，最终采集得到本次测试的性能参考指标如表5- 2所示：表5- 2 OA系统性能参考指标得出本次测试的性能参考指标后，我们就可以进行测试模型的建立了。
建立业务模型得到性能测试参考指标后，再次分析OA系统的实际使用情况，我们可以进行测试模型的建立，也就是建模。
所谓建模，就是建立用户业务模型。
建模是性能测试的基础。
只有建立合理有效的业务模型，才能模拟出真实的系统使用情况，才能找到今后可能发生的缺陷，所以建立恰当的业务模型是我们性能测试成功与否的关键。
那如何建立用户业务模型呢？根据上面的测试要求，我们需要测试OA系统登录与考勤两个模块的性能。
这两个模块的使用方法是什么样的？用户又是怎么使用的？相对其他的业务系统而言，这里的功能比较简单了。
登录功能很常见，输入用户名与密码，点击登录按钮即可完成登录操作。
登录成功后，直接进入考勤页面，点击考勤按钮，即可完成考勤操作。
所以，不需做太多的分析就能弄清楚这个过程。
如果用流程图表示，则可表示为图5- 2。
图5- 2 OA系统考勤流程图建立实际的业务模型如表5- 3所示：表5- 3 OA系统考勤业务模型经过分析测试要求与建立业务模型两步，基本上已经确定了本次测试的内容。
大多数项目的性能测试分析都可以使用这样的方法。
在分析与建模过程中，最重要的是要弄清楚当前测试的重点是什么，对应的业务流程是什么，就像我们做功能测试一样的，性能测试也需要在客户的实际应用基础上开展，否则脱离实际的测试是无效的。
评审确定指标前面的两步仅是测试工程师的分析确定过程，并没有取得项目组的审核，要知道，在一个软件生产过程中，评审在每一个过程都应该存在。
得到测试指标与模型后，就需要编写对应的性能测试计划或者性能测试方案，并提交项目进行审批。
如果项目组没有这个要求，测试工程师也需告知项目经理、开发组长与测试组长，并要求得到反馈。
我曾做过的一个移动项目，方案改了三次，局方经理才同意，尽管他们并没有提出什么要求，就是认为不妥，此时我们就必须不断调整，他不同意，我们就不能开展工作。
所以，有时候这个评审可能是个形式，但也得做。
一般在这个阶段会生成性能测试计划或者性能测试方案。
后期的性能测试工作就按照这些文档开展。
5.1.3性能测试用例设计经过性能测试需求提取阶段的努力，测试目的明确了，就需要设计详细的测试用例了。
这个阶段主要考虑的是如何实现性能测试模型。
与功能测试用例设计不同的是，性能测试用例一般仅考虑正常的业务流程，而不会去检查异常流程，但其中的约束条件仍是需要注意的。
比如有些在线投票系统是不允许一个IP 投多次票的，在性能测试过程中特别需要注意这方面的问题。
比如同一个IP仅允许一个用户登录、一个用户仅能操作一次、不允许出现同样的数据，业务操作中存在临时会话ID等等问题。
从功能角度考虑，用户使用OA系统中的考勤功能，只能进行一次到达单位的签到，如果再次点击考勤按钮，则系统不允许提交，给予提示“不能重复考勤”。
这样，在测试过程中，就需要使用不同的用户名。
仔细分析测试数据的约束关系，找出其中容易出问题的地方，然后想办法解决它。
经过分析，了解到考勤功能不允许重复考勤，也就意味着一个用户只能进行一次考勤操作。
除此之外，还需要考虑同一个IP允不允许多个账号登录，在前面的功能测试阶段我们得知，OA系统是允许这样的操作的，那么在测试过程中就不需要进行IP欺骗的操作了。
除此之外，似乎OA系统没有其他的限制了。
再次强调，在设计性能测试用例的时候，一定要弄清楚测试点是否存在约束条件，一般可由该测试点对应的功能测试用例得到。
综上所有，设计出本次性能测试的用例如表5- 4所示：表5- 4 OA系统性能测试用例至此，性能测试需求分析与测试用例设计已经完成，下面就可以利用测试工具进行实际的测试了。
这里使用的是HP公司的LoadRunner 8.1英文版。
LoadRunner是一款专门用于性能测试的测试工具。
该工具可以轻松的模拟百万用户并发使用软件系统的情景，同时可利用场景执行功能模拟真实的业务，场景执行完毕后，LoadRunner还提供了强大的测试结果数据分析功能，以便于测试工程师分析系统中所存在的性能问题。