性能测试用例

如何编写性能测试场景⽤例（如何编写性能测试⽤例）单场景前⾔写测试⽤例，是测试绕不开的⼯作内容，不管是功能、⾃动化，还是性能。

先来回顾⼀下功能测试⽤例主要包含的要素：测试⽤例编号、测试标题、所属模块、测试需求项编号、案例状态、预置条件、优先级、测试输⼊、操作步骤、预期输出、实际结果、案例设计者、设计⽇期、案例性质等。

性能测试⽤例（有的称为场景⽤例）的设计，有别于功能测试⽤例、⾃动化测试⽤例的设计，毕竟，考虑的点不⼀样。

对于性能测试来说，⼀般要考虑这4种场景：单场景、混合场景、稳定性场景、异常场景。

下⾯，结合笔者实际⼯作，分享下单场景的⽤例是如何设计的。

单场景的定义 有的称为接⼝基准（Benchmark）、或者单交易的容量，总之，这个不是真实的业务原型（可以简单理解为不同业务的使⽤情况）。

单场景压测的⽬的 既然单场景不是真实的业务原型，为什么不直接做混合场景的压测呢？其实，做单场景压测的⽬的是测试出这个单业务的最⼤tps，⽅便判断瓶颈，⽐如，业务部门给的混合场景的tps（假设这个tps值是合理有效的），根据业务原型⽐例计算后，业务A的⽬标tps都⽐你单场景的最⼤tps还要⼤，那是不是应该让开发提前优化了？如果在混合场景压测中，发现业务A的tps已经到达或者接近其单场景最⼤tps，但是混合场景还没有达标，那说明瓶颈在业务A。

单场景的来源 有⼈可能要问，单场景从哪⾥来？如果你们业务部门或者其它部门能给，那最好，如果不能给，你作为性能测试⼈员，要引导相关⼈员给，总之，我觉得这个不能性能测试单独定，否则后期出问题可能你独⾃背锅哦，要尽最⼤努⼒保证不出问题，哪怕出问题，也要⼀起背锅。

单场景是来⾃于业务原型，但是不是每个业务接⼝都需要做压测，所以，我们这⾥说的业务原型，是混合场景的业务原型，混合场景⾥⾯，每个业务接⼝都需要做单场景压测。

⾄于业务原型如何获取，这是⼀个⼤话题，本次分享暂不讨论，如果想交流，欢迎微信留⾔。

性能测试之测试用例（方案篇）性能测试在软件测试中占有重要的地位，而性能测试又关联很多容。

例如压力和强度测试就与性能测试密切相关：针对一个进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试，如果同时对系统进行大量的数据查询操作，就包含了强度测试。

为了便于性能测试工作的实施，这里的性能测试综合了性能、强度、压力、负载等多方面的测试容，主要包含的容有：预期性能指标测试、用户并发性能测试、疲劳强度测试、大数据量测试和速度测试、网络、服务器等方面的容。

性能测试不同的系统有不同的要求，编写方法要根据实际要求进行编写，本文提出一个常见的参考方案，在实际工作中，可以根据需要加入其它例如存泄露等和性能相关的测试用例。

下面介绍各个部分性能测试用例包含的容：1.1预期性能指标测试用例通常系统在设计前都会提出一些性能指标，这些指标是性能测试要完成的首要工作之一。

针对每个指标都要编写多个测试用例来验证是否达到要求，并根据测试结果来改进系统的性能。

这类通常以单用户为主，如果遇到并发用户的情况，可以归到并发用户测试用例中。

这类用例通常都是可以通过手工来执行的用例，例如示例中的上传一份文件，期望的性能为2M/S，完全可以手动上传文件，同时用秒表计时。

这些容通常在需求说明书中可以显而易见的查到。

不过当看到如支持并发用户300人，就应该放到后面进行。

测试结果也是直接记录是否达到要求，如果系统没有达到要求则进行改善。

1.2用户并发性能测试用例用户并发测试是性能测试的最主要部分，包含了负载测试和压力测试的过程。

主要是逐渐增加用户数量来加重系统负担，直到出现不能接收的性能点或者瓶颈。

一般要测试正常数量的用户并发和极限数量下用户并发的情况。

并发用户测试主要是对系统的核心功能和重要业务进行测试，要以真实的业务数据作为输入，选择有代表性和关键的业务操作来设计测试用例。

主要编写以下两个方面的用例：核心模块的测试（可以理解为“单元性能测试”）：对核心功能模块进行并发用户测试，测试系统是否能够稳定运行。

性能测试用例
性能测试用例是指在软件开发过程中，通过各种预先定义的测试条件，对软件系统或服务进行测试，以确定其能够满足特定性能要求的一系列测试。

性能测试用例主要包括以下内容：
1. 测试目标和范围：明确测试的目标和范围，如性能测试的类型、平台、测试时间、测试范围等；
2. 计划：明确测试步骤和测试环境，如测试数据准备、测试工具、测试环境等；
3. 执行：执行测试，记录测试结果；
4. 结果分析：分析测试结果，如测试报告、数据分析、性能报告等；
5. 验收：验证测试结果，确保其满足要求。

性能测试⽤例（转载）　⼀、WEB 全⾯模型 Web 性能测试模型提出的主要依据是：⼀种类型的性能测试可以在某些条件下转化成为另外⼀种类型的性能测试，这些类型的性能测试的实施是有着相似之处的； 1. 预期指标的性能测试 系统在需求分析和设计阶段都会提出⼀些性能指标，完成这些指标的相关的测试是性能测试的⾸要之⼀，这些指标主要诸于“系统可以⽀持并发⽤户200个；”系统响应时间不得超过20秒等，对这种预先承诺的性能要求，需要⾸先进⾏测试验证； 2. 独⽴业务性能测试 独⽴业务实际是指⼀些核⼼业务模块对应的业务，这些模块通常具有功能⽐较复杂，使⽤⽐较频繁，属于核⼼业务等特点。

⽤户并发测试是核⼼业务模块的重点测试内容，并发的主要内容是指模拟⼀定数量的⽤户同时使⽤某⼀核⼼的相同或者不同的功能，并且持续⼀段时间。

对相同的功能进⾏并发测试分为两种类型，⼀类是在同⼀时刻进⾏完全⼀样的操作。

另外⼀类是在同⼀时刻使⽤完全⼀样的功能。

3. 组合业务性能测试 通常不会所有的⽤户只使⽤⼀个或者⼏个核⼼业务模块，⼀个应⽤系统的每个功能模块都可能被使⽤到；所以WEB性能测试既要模拟多⽤户的相同操作，⼜要模拟多⽤户的不同操作；组合业务性能测试是最接近⽤户实际使⽤情况的测试，也是性能测试的核⼼内容。

通常按照⽤户的实际使⽤⼈数⽐例来模拟各个模版的组合并发情况；组合性能测试是最能反映⽤户使⽤情况的测试往往和服务器性能测试结合起来，在通过⼯具模拟⽤户操作的同时，还通过测试⼯具的监控功能采集服务器的计数器信息进⽽全⾯分析系统瓶颈。

⽤户并发测试是组合业务性能测试的核⼼内容。

组合并发的突出特点是根据⽤户使⽤系统的情况分成不同的⽤户组进⾏并发，每组的⽤户⽐例要根据实际情况来匹配； 4. 疲劳强度性能测试 疲劳强度测试是指在系统稳定运⾏的情况下，以⼀定的负载压⼒来长时间运⾏系统的测试，其主要⽬的是确定系统长时间处理较⼤业务量时的性能，通过疲劳强度测试基本可以判定系统运⾏⼀段时间后是否稳定； 5. ⼤数据量性能测试 ⼀种是针对某些系统存储，传输，统计查询等业务进⾏⼤数据量时的性能测试，主要针对某些特殊的核⼼业务或者⽇常⽐较常⽤的组合业务的测试； 第⼆种是极限状态下的数据测试，主要是指系统数据量达到⼀定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核⼼业务或者常⽤的组合业务。

测试用例的颗粒度划分在软件测试中，测试用例的颗粒度划分是非常重要的，它直接影响到测试的覆盖率和效果。

一个好的测试用例应该能够尽可能地覆盖到软件的各个功能和边界情况，以确保软件的质量和稳定性。

而测试用例的颗粒度划分就是将软件的各个功能和边界情况拆分成一个个小的测试点，以便进行详细的测试。

一、整体功能测试用例的颗粒度划分整体功能测试用例是对软件的整体功能进行测试的，它是测试用例的最高颗粒度。

在整体功能测试用例中，可以包括软件的各个功能模块、功能点和交互操作等。

例如，在一个电商网站的整体功能测试用例中，可以包括用户登录、商品浏览、购物车管理、订单管理、支付功能等。

二、模块功能测试用例的颗粒度划分模块功能测试用例是对软件的各个模块进行测试的，它是测试用例的中等颗粒度。

在模块功能测试用例中，可以包括模块的各个功能点、输入输出和异常情况等。

例如，在一个电商网站的用户登录模块功能测试用例中，可以包括正确的用户名和密码登录、错误的用户名和密码登录、用户名为空登录等。

三、接口测试用例的颗粒度划分接口测试用例是对软件的各个接口进行测试的，它是测试用例的较小颗粒度。

在接口测试用例中，可以包括接口的输入输出、参数验证、异常情况等。

例如，在一个电商网站的支付接口测试用例中，可以包括正常支付、支付金额为空、支付密码错误等。

四、边界测试用例的颗粒度划分边界测试用例是对软件的边界情况进行测试的，它是测试用例的最小颗粒度。

在边界测试用例中，可以包括边界值、边界条件和边界情况等。

例如，在一个电商网站的商品库存管理功能的边界测试用例中，可以包括库存为0、库存为1、库存为最大值等。

五、异常测试用例的颗粒度划分异常测试用例是对软件的异常情况进行测试的，它是测试用例的较小颗粒度。

在异常测试用例中，可以包括各种异常情况和错误处理等。

例如，在一个电商网站的订单管理功能的异常测试用例中，可以包括订单不存在、订单已取消、订单已完成等。

六、性能测试用例的颗粒度划分性能测试用例是对软件的性能进行测试的，它是测试用例的较小颗粒度。

同预期
备注
样品编号 测试用例总数 序号 用例标识
模块名称
功能点
1
WW1
统一登录模 用户100并
块
发登录
2
WW2 ***平台 单用户3源自WW3****平台
用户100并 发
性能测试
性能测试用例
操作步骤
1.编写接口测试脚本； 2.对脚本进行调优（关联接口、请求参数参数化、设置思考时间1S、设置响应文本检查 点）； 3.设置脚本执行场景，模拟100并发用户数执行“统一登录”业务操作，并根据测试结果 数据分析系统的性能状况 41..查编看写接接口口成测功试率脚、本响；应时间、吞吐量和系统资源消耗情况； 2.对脚本进行调优（关联接口、请求参数参数化、设置思考时间1S、设置响应文本检查 点）； 3.设置脚本执行场景，模拟单用户执行“大数据分析平台”业务操作，并根据测试结果数 据分析系统的性能状况 4.查看接口成功率、响应时间、吞吐量和系统资源消耗情况； 1.编写接口测试脚本； 2.对脚本进行调优（关联接口、请求参数参数化、设置思考时间1S、设置响应文本检查 点）； 3.设置脚本执行场景，模拟100并发用户数执行“大数据分析平台”业务操作，并根据测 试结果数据分析系统的性能状况 4.查看接口成功率、响应时间、吞吐量和系统资源消耗情况；
能测试用例
期望结果
实际结果 设计者
检查人
执行人
100用户并发进行“统一登录”操作，系统响应时间≤5S，峰值≤ 15S、接口失败率<5%。
同预期
单用户并发进行“大数据分析平台”业务操作，系统响应时间控制在 平均值≤2S、峰值≤15S、接口失败率<5%。
同预期
100用户并发进行“大数据分析平台”业务操作，系统响应时间控制 在平均值≤2S、峰值≤15S、接口失败率<5%。

性能测试之测试用例（方案篇）性能测试在软件测试中占有重要的地位，而性能测试又关联很多内容。

例如压力和强度测试就与性能测试密切相关：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试，如果同时对系统进行大量的数据查询操作，就包含了强度测试。

为了便于性能测试工作的实施，这里的性能测试综合了性能、强度、压力、负载等多方面的测试内容，主要包含的内容有：预期性能指标测试、用户并发性能测试、疲劳强度测试、大数据量测试和速度测试、网络、服务器等方面的内容。

性能测试不同的系统有不同的要求，编写方法要根据实际要求进行编写，本文提出一个常见的参考方案，在实际工作中，可以根据需要加入其它例如内存泄露等和性能相关的测试用例。

下面介绍各个部分性能测试用例包含的内容：1.1预期性能指标测试用例通常系统在设计前都会提出一些性能指标，这些指标是性能测试要完成的首要工作之一。

针对每个指标都要编写多个测试用例来验证是否达到要求，并根据测试结果来改进系统的性能。

这类通常以单用户为主，如果遇到并发用户的情况，可以归到并发用户测试用例中。

这类用例通常都是可以通过手工来执行的用例，例如示例中的上传一份文件，期望的性能为2M/S，完全可以手动上传文件，同时用秒表计时。

这些内容通常在需求说明书中可以显而易见的查到。

不过当看到如支持并发用户300人，就应该放到后面进行。

测试结果也是直接记录是否达到要求，如果系统没有达到要求则进行改善。

1.2用户并发性能测试用例用户并发测试是性能测试的最主要部分，包含了负载测试和压力测试的过程。

主要是逐渐增加用户数量来加重系统负担，直到出现不能接收的性能点或者瓶颈。

一般要测试正常数量的用户并发和极限数量下用户并发的情况。

并发用户测试主要是对系统的核心功能和重要业务进行测试，要以真实的业务数据作为输入，选择有代表性和关键的业务操作来设计测试用例。

主要编写以下两个方面的用例：核心模块的测试（可以理解为“单元性能测试”）：对核心功能模块进行并发用户测试，测试系统是否能够稳定运行。

测试用例之性能测试用例注：本文摘自作者正在编写的《Web性能测试实战》一书，曾经在程序员杂志2004年第10期上发表过。

性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试……,这么多眼花缭乱的测试类型名称，估计很少有人能准确的区分并说出定义来，至于对应的测试用例如何编写和执行，就更不用说了。

如果问测试工程师测试用例如何编写，就象是问程序员如何编写代码得到的答案一样，每个人都会给出不同的编写方法，但实用的测试用例却象优秀的程序一样难以编写。

目前国内，测试工程师却时常要面对“已经延期几倍计划时间的项目”，测试用例如何发挥更大的作用，是一个迫切需要解决的问题。

事实上，完全可以把测试用例看成是测试工程师编写的程序：这个“程序”是为了辅助测试工作的进行而开发的，目的是为了发现软件问题，同时“顺便”证明软件功能是否符合要求。

本文针对上面的问题，以设计性能测试用例为示范，讲解在企业实际工作中，如何有效划分测试种类和编写对应的测试用例，使测试工作更加合理、高效率的开展。

1测试种类和阶段1.1 测试种类对于测试种类的说法多种多样，最多的能达到30多种测试类型。

而实际工作中很多测试是互相包含的。

按照企业中实际工作需要，通常主要进行下面几种类型的测试：功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、文档测试。

下面介绍几种重要的测试种类及其测试的内容：功能测试：功能测试主要针对产品需求说明书的测试，是验证功能是否否合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。

这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作，他们也需要进行基本功能的测试。

接口测试：程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。

这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。

由开发人员进行。

性能测试需求分析及⽤例5.1.2性能测试需求提取复习了⼀些常见的理论概念后，我们开始性能测试需求的提取。

这个过程是⾮常重要的，往往测试失败，就是因为在这个过程中不知道如何得到确切的性能指标，⽽导致测试⽆法正常开展。

性能测试需求提取⼀般的流程如图5- 1所⽰。

图5- 1性能测试需求提取流程分析提取指标在⽤户需求规格说明书中，会给出系统的功能、界⾯与性能的要求。

规范的需求规格说明书都会给出明确的性能指标，⽐如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗⽤要在⼀个合理的范围中，这些指标都会以可量化的数据进⾏说明。

如果，实际项⽬并没有这些正规的⽂档时，项⽬经理部署测试任务给测试组长时，⼀般就会说明是否要对项⽬的哪些业务模块进⾏性能测试，以及测试的要求是什么的。

最⿇烦的就是项⽬经理或者客户要求给出⼀个测试部门认为可以的数据，这样⾮常难做的。

可是“甲⽅”往往都是提要求的，“⼄⽅”只能“⽆条件”接受！对于正规的项⽬，⽤户需求规格说明书中⼀般会给出类似表5- 1的性能测试要求：测试项响应时间业务成功率并发数CPU使⽤率内存使⽤率⽤户登录<=3秒>98% 20 <75% <75%表5- 1需求规格说明书中的性能要求表5- 1给出的指标⾮常明确，在测试过程中，我们只需收集⽤户登录模块的响应时间、登录成功率、并发数、CPU使⽤率、内存使⽤率的数据，然后与表5- 1的指标进⾏⽐较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。

⼤多数是没有明确的需求，需要我们⾃⼰根据各种资料、使⽤各种⽅法去采集测试指标。

以OA系统为例，假设《FIX OA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试⼯程师⾃⼰分析被测系统及采集性能衡量指标。

分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终⽤户经常使⽤的业务点，那么我们的重点应该在放在该模块上。

参数设置 运行时设置 事物设置 集合点设置 检查点设置 Scenario Type
Manual Scenario Scenario 非百分比模式
场景编号 1 系统登录
业务名称
场景编号 1 系统登录
业务名称
业务名称
录制步骤
系统登录 1、启动VuGen，按照录制设置设置录制前提条件； 2、切换至Action，在被测系统操作系统登录流程，按照事物设置插入事物； 3、切换至vuser_end，操作退出系统流程
脚本设置 参数策略 迭代次数 Sequential+Each iteration 参数值个数 Same line as username 参数值个数 Pacing迭代间隔 Log是否启动日志 5秒 启动标准日志 起始位置 结束位置 初始化页面前 跳转至欢迎页面后 起始位置 单击登录按钮前 检索内容 检索范围 Text=Welcome, <b>jojo</b>,Search=Body 场景设置 Run Mode Basic schedule Action Initialize Start Vusers Duration 预期结果 并发数 1 事物平均响应时间 <=3s001 应用类型：Internet Applications URL地址：http://127.0.0.1:1080/WebTours/ 录制起始存放函数：Action 录制协议：Web(HTTP/HTML) 录制模式：URL-based script 参数名 username password Run Logic迭代次数 参数值个数 事物名称 transaction_login 集合点名称 rendezvous_login 检查点类型 文本 Schedule by

性能测试⽤例设计性能测试⽤例的设计，有别于功能测试⽤例的设计，毕竟，考虑的点不⼀样。

在有了性能测试⽅案后，我们就可以设计我们的性能测试⽤例了，⼀般考虑：单场景、混合场景、稳定性场景下⾯给出笔者在实际⼯作中，单场景的⽤例（之前⽤loadrunner做压测的⽤例），供⼤家参考：⽤例编号：PT001场景描述：模拟⽤户进⾏登录操作并发量：分别模拟并发⽤户数为1000、1500、2000等多种情况进⾏测试（除了压测能否达到⽬标，还要压测出最⼤的并发和tps，参考：）压测时间：每次600s数据量：oracle数据库user表有100万存量账户脚本设置关键点：参数化⽤户名、封装登录事务、添加思考时间集合点：不使⽤加压减压⽅式：全部初始化爬坡加压、全部退出场景运⾏时设置：think time=1s、continue when error、log选择Send messages only when an error occurs重点关注指标：响应时间、tps，事务成功率，各个服务器资源使⽤情况（CPU、内存、磁盘I/O、磁盘容量）、⽹络、是否频繁fgc、是否线程阻塞、线程死锁、连接池未释放、数据库死锁、慢sql等等预期指标：并发>=1000，响应时间<=1s，tps>=600，事务成功率为99.5%（涉及资⾦的，要求100%），应⽤服务器、数据库服务器CPU和内存使⽤率<=90%，没有内存泄漏现象、没有死锁等各种性能问题。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21⽤例编号：PT001场景描述：模拟⽤户进⾏登录操作并发量：分别模拟并发⽤户数为1000、1500、2000等多种情况进⾏测试（除了压测能否达到⽬标，还要压测出最⼤的并发和tps，参考：https:///uncleyong/p/11543488.html）压测时间：每次600s数据量：oracle数据库user表有100万存量账户脚本设置关键点：参数化⽤户名、封装登录事务、添加思考时间集合点：不使⽤加压减压⽅式：全部初始化爬坡加压、全部退出场景运⾏时设置：think time=1s、continue when error、log选择Send messages only when an error occurs重点关注指标：响应时间、tps，事务成功率，各个服务器资源使⽤情况（CPU、内存、磁盘I/O、磁盘容量）、⽹络、是否频繁fgc、是否线程阻塞、线程死锁、连接池未释放、数据库死锁、慢sql等等预期指标：并发>=1000，响应时间<=1s，tps>=600，事务成功率为99.5%（涉及资⾦的，要求100%），应⽤服务器、数据库服务器CPU和内存使⽤率<=90%，没有内存泄漏现象、没有死锁等各种性能问题。

测试用例实例含：功能测试用例、性能测试用例、兼容性测试用例）一、功能测试用例-2-二、性能测试-11-2.1预期性能测试用例-11-2.2用户并发测试用例-12-2.3大数据量测试用例-12-2.4疲劳强度测试用例-13-2.5负载测试测试用例-13-三、兼容性测试-.14-用例编号TestCase_LinkWorks_WorkEvaluate项目名称LinkWorks模块名称WorkEvaluate模块项目承担部门研发中心-质量管理部用例作者完成日期2005-5-27本文档使用部门质量管理部评审负责人审核日期批准日期注：本文档由测试组提交，审核由测试组负责人签字，由项目负责人批准。

历史版本：版本/状态作者参与者起止日期备注一、功能测试用例此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。

这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。

主要测试技术方法为用户通过GUI（图形用户界面）与应用程序交互，对交互的输出或接受进行分析，以此来核实需求功能与实现功能是否一致。

二、性能测试性能测试是一种对响应时间、事务处理速率和其他与时间相关的需求进行测试和评估。

性能测试的目标是核实性能需求是否都已满足。

可以分为以下几种进方式来组织进行测试。

2.1预期性能测试用例通常系统在设计前会提出一些性能指标，这些指标是性能测试要完成的首要工作，针对每个指标都要统写多个测试用例来验证是否达到要求，根据测试结果来改进系统的性能。

预期性能指标通成以单用户为主。

2.2 用户并发测试用例用户并发测试是性能测试最主要的部分，主要是通过增加用户数量来加重系统负担，以检验测试对象能接收的最大用户数来确定功能是否达到要求。

2.3 大数据量测试用例大数据量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。

大数据量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

性能测试用例1、单用户测试2、用户并发测试:核心模块并发用户数与数据库主机并发用户数300人CPU利用率MEM利用率磁盘I/O情况DB参数1 其它参数并发用户数与应用服务器的关系表并发用户数CPU利用率MEM利用率磁盘300人功能巡检目的方法测试多人同时入库的性能情况多人登录系统，采用LOADRUNNER录制任务，然后开始对系统加压；持续时间120分钟，用户数量为500个。

并发用户数与事务执行情况并发用户数事务平均响应时间事务最大响应时间平均每秒处理事务数事务成功率每秒点击率平均流量（字节/秒）500并发用户数500人CPU利用率MEM利用率磁盘I/O情况DB参数1 其它参数并发用户数500人CPU利用率MEM利用率磁盘并发用户数与数据库主机并发用户数与应用服务器的关系表功能出库目的测试多人同时查询出库的性能情况方法多人登录系统，米用LOADRUNNER录制任务，然后开始对系统加压；持续时间20分钟，用户数量为100个。

并发用户数与事务执行情况目测试100人同时对系统操作，系统的性能情况方法米用LOADRUNNER 录制任务，然后开始对系统加压；持续时间40 分钟，用户数量100个并发用户数 事务平均响 应时间 事务最大响应时间 平均每秒事务数事务成功率平均流入库查询出库查询巡检查询登陆入库查询出库查询巡检查询登陆巡检查询登陆库查询 入库查询出库查询巡检查询登陆入库查询秒点击率佇/#) 量节并发用户CPU 利用MEM 利用磁盘DB 参数1其它参3用户并发测试:组合模块功能100人同时操作：30人登陆，20人巡检查询，20出库查询，30 入库查询，30人登陆，20人巡检查询，20出库查询，30 入库查询 30人登陆，20人巡检查询，20出库查询，30 入库查询并发用户数CPU 利用率MEM 利用率磁盘I/O 情况 30人登陆，20人巡检查询，20 出库查询，30入库查询目测试300人同时对系统操作，系统的性能情况方法米用LOADRUNNER 录制任务，然后开始对系统加压；持续时间100分钟，用户数量300个并发用户数事务平均响 应时间 事务最大响应时间 平均每秒 事务数事务成功率平均流入库查询出库查询巡检查询登陆入库查询出库查询巡检查询登陆巡检查询登陆库查询 入库查询出库查询巡检查询登陆入库查询秒点击率佇/#) 量节CPU 利用MEM 利用磁盘DB 参数1功能300人同时操作：50人登陆，100人巡检查询，70出库查询，80入库查询，50人登陆，100人巡检查询，70出库查询，80入库查询 50人登陆,100人巡检查询，70出库查询，80 入库查询并发用户数CPU 利用率MEM 利用率磁盘I/O 情况50人登陆，100人巡检查询，70出库查询，80入库查询4大数据量测试5疲劳强度测试。

1. 如何写性能测试用例由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。

性能测试的目的：为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

性能测试指标的来源：用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。

（需求+经验）主要的性能指标：服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。

BUG观点：1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）；2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）；3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。

HTTP观点：1、负载测试是正常情况下持续的加压；2、压力测试是直接加压达到一个极限值。

大家统一的观点：性能测试、压力测试、负载测试密不可分，可统称为性能测试。

性能测试要点：1、性能测试是在功能测试完成之后进行。

2、性能测试计划、方案一般与测试用例统一在一个文档里。

3、测试环境应尽量与用户环境保持一致。

4、性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。

5、性能测试的重点在于前期数据的设计与后期数据的分析。

6、性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。

（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。

但是如果某个功能有较大的修改，性能测试也应该进行重新测试。

）2. Loadrunner性能测试一个实例（经典）随着测试越来越重要，其中的性能测试也受到越来越多的关注。

比较普遍的性能测试工具是Loadrunner7.51，但是很多人对此性能工具不是很熟悉。

目录一、性能测试要点及用例模板 (2)1、性能测试团队成员职责技能描述 (2)2、性能测试工具需求规划表 (3)3、性能测试环境调查表 (3)4、典型业务列表 (3)5、业务用例描述 (4)6、场景列表 (4)7、测试计划 (4)8、测试环境检查 (5)9、测试执行记录日志 (5)10、性能测试分析报告 (6)11、性能测试应用领域与测试方法的关联 (6)12、常用的性能测试过程 (7)13、并发测试主要关注的问题（常用的测试方法） (8)14、性能调优的标准过程示例图 (8)15、性能测试脚本录制时的协议类型 (9)16、不同应用领域的性能测试目标和性能目标 (10)17、Windows操作系统主要计数器 (10)18、Unix常用计数器 (12)一、性能测试要点及用例模板1、性能测试团队成员职责技能描述2、性能测试工具需求规划表3、性能测试环境调查表4、典型业务列表5、业务用例描述6、场景列表7、测试计划1．引言1.1编写目的2．参考文档3．测试目的4．测试范围4.1测试对象4.2需要测试的特性4.3无需测试的特性5．测试启动与结束准则5.1启动准则5.2结束准则6．测试方法6.1测试工具6.2测试设计6.3测试用例与测试场景7．测试类型7.1能力验证测试7.2容量规划测试7.3稳定性测试8．测试环境维护原则9．测试输出10．测试资源需求与时间计划8、测试环境检查9、测试执行记录日志10、性能测试分析报告1．测试背景2．测试目的3．测试概要描述3.1被测系统描述3.2测试时间3.3测试地点3.4测试人员3.5测试工具和环境3.6测试方案简介4．测试结果和结论4.1测试结论4.2测试结论的限制4.3对系统的建议5．原始数据和报告5.1测试执行记录5.2原始数据文件5.3测试工具生成的报告11、性能测试应用领域与测试方法的关联12、常用的性能测试过程13、并发测试主要关注的问题（常用的测试方法）14、性能调优的标准过程示例图15、性能测试脚本录制时的协议类型16、不同应用领域的性能测试目标和性能目标17、Windows操作系统主要计数器18、Unix常用计数器。

能正常运行
测试（并发用户登录网站的时间）
测试项编号
JWXN-003
测试项描述
测试50个并发用户同时登陆网站的时间
前置条件
测试客户端要有足够的资源,用户都合法并存在，同时能够成功登陆教务网
用例序号输入/动作来自输出/响应能否正常运行
001
采用LOADRUNNER录制任务，然后开始对系统加压；
任务2，持续时间10分钟，用户数量为50个
前置条件
用户合法并存在，同时能够成功登陆教务网
用例序号
输入/动作
输出/响应
能否正常运行
001
1.输入<地址>，打开教务网的登陆首页
2．输入用户名
3．输入密码
4．点击登陆
5．点击首页中的其中一条通知
6．点击的同时开始计时
点击通知以后页面成功打开，
同时页面打开所要的时间小于1S
能正常运行
测试（并发用户登录网站的时间）
001
采用LOADRUNNER录制任务，然后开始对系统加压；
任务4，持续时间20分钟，用户数量为100个
100个并发用户登录网站的时间<60s
能正常运行
测试项编号
JWXN-002
测试项描述
测试25个并发用户同时登陆网站的时间
前置条件
测试客户端要有足够的资源,用户都合法并存在，同时能够成功登陆教务网
用例序号
输入/动作
输出/响应
能否正常运行
001
采用LOADRUNNER录制任务，然后开始对系统加压；
任务1持续时间5分钟，用户数量为25个
100个并发用户登录网站的时间<60s
100个并发用户登录网站的时间<60s

性能测试场景用例(仅供内部使用)拟制: 日期：审核: 日期：审核: 日期：批准: 日期：修订记录目录1概述 (4)2测试目的 (4)3测试设计 .............................................................................................................错误!未定义书签。

3.1对象分析 ........................................................................................................ 错误!未定义书签。

3.2测试策略 ........................................................................................................ 错误!未定义书签。

3.3测试模型 ........................................................................................................ 错误!未定义书签。

3.3.1测试环境描述......................................................................................... 错误!未定义书签。

3.4详细测试方法 ................................................................................................ 错误!未定义书签。

3.4.1测试方法综述......................................................................................... 错误!未定义书签。