性能测试之场景设计思想
性能测试场景分析
性能测试场景分析性能测试过程中，⾸先应该设计测试场景，模拟真实业务发⽣的情境，然后是针对场景设计脚本。
为了真实的反映被测对象可能存在的性能问题，需要尽可能模拟被测对象可能发⽣瓶颈的业务场景。
测试需求分析过程中已经确定了需要测试的业务类型，在此，则需要设计针对每种或综合业务的测试场景。
⼀、应⽤性能测试场景的设计在了解了相关背景之后，我们开始进⼊正题。
性能场景的设计主要包括：业务场景建模、测试数据准备、监控指标确认三个关键步骤。
下⾯我们⽤实战的⽅式说明每个步骤的常见做法。
1.1.业务场景建模确定压测场景范围：⼈的⾏为是不可预测的，在性能测试中模拟每个⽤户可能的操作场景基本上是不可能实现的。
⼀般情况下我们必须要关注的性能场景包括但不限于：⾼频使⽤的场景关键的业务场景最耗性能的场景曾经出现过问题的场景……在测试具有⼤量新功能的业务时，往往需要与业务⽅⼀起确认预期内有哪些功能点可能会被⾼频使⽤，需要与研发⼈员确认哪些功能虽然使⽤频率不⾼，但是存在性能隐患、容易引起雪崩效应；在测试已经上线的功能时，还可以通过业务监控、系统⽇志来分析现有⽤户的⾏为模式，得到更加逼近真实⽤户⾏为的业务场景。
业务场景的操作路径：业务场景的操作路径可以借助⼀些可视化的⼯具来描述，这部分⼯作相对⽐较简单，不再详细深⼊。
我们详细说明⼀下⽐较常见的延时策略。
思考时间：思考时间模拟的是⽤户在等待响应、阅读页⾯内容、表单填写等延迟操作的场景。
每个⼈的阅读速度、输⼊速度都存在⾮常⼤的差异，决定了每个⼈的思考时间也是不⼀样的，在性能测试配置中有常见的四种延时模型覆盖了绝⼤部分的延时场景：固定时间：顾名思义，设置⼀个固定的思考时间。
均匀分布：均匀分布在范围的上限和下限之间的随机数。
正态分布：根据中⼼极限定理，如果⼀个事物受到多种因素的影响，不管每个因素本⾝是什么分布，它们加总后，结果的平均值就是正态分布。
负指数分布：该模型将延迟时间的频率强烈地偏向该范围的⼀端。
软件测试之服务器稳定性测试方法
服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。
正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。
重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。
一些测试方法主要分以下几种：压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。
系统各性能指标在这种压力下是否还在正常数值之内。
系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。
Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。
一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。
以事务通过率与错误率衡量实际加载方式。
Ramp Up增量设计目标：寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。
模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。
另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。
加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。
以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。
稳定性测试：已知系统高峰期使用人数、各事务操作频率等。
设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。
并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。
事务响应时间是否会出现波动或随测试时间增涨而增加。
系统是否会在测试期间内发生如宕机、应用中止等异常情况。
根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。
仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。
性能测试用例（转载）
性能测试⽤例（转载） ⼀、WEB 全⾯模型 Web 性能测试模型提出的主要依据是：⼀种类型的性能测试可以在某些条件下转化成为另外⼀种类型的性能测试，这些类型的性能测试的实施是有着相似之处的； 1. 预期指标的性能测试 系统在需求分析和设计阶段都会提出⼀些性能指标，完成这些指标的相关的测试是性能测试的⾸要之⼀，这些指标主要诸于“系统可以⽀持并发⽤户200个；”系统响应时间不得超过20秒等，对这种预先承诺的性能要求，需要⾸先进⾏测试验证； 2. 独⽴业务性能测试 独⽴业务实际是指⼀些核⼼业务模块对应的业务，这些模块通常具有功能⽐较复杂，使⽤⽐较频繁，属于核⼼业务等特点。
⽤户并发测试是核⼼业务模块的重点测试内容，并发的主要内容是指模拟⼀定数量的⽤户同时使⽤某⼀核⼼的相同或者不同的功能，并且持续⼀段时间。
对相同的功能进⾏并发测试分为两种类型，⼀类是在同⼀时刻进⾏完全⼀样的操作。
另外⼀类是在同⼀时刻使⽤完全⼀样的功能。
3. 组合业务性能测试 通常不会所有的⽤户只使⽤⼀个或者⼏个核⼼业务模块，⼀个应⽤系统的每个功能模块都可能被使⽤到；所以WEB性能测试既要模拟多⽤户的相同操作，⼜要模拟多⽤户的不同操作；组合业务性能测试是最接近⽤户实际使⽤情况的测试，也是性能测试的核⼼内容。
通常按照⽤户的实际使⽤⼈数⽐例来模拟各个模版的组合并发情况；组合性能测试是最能反映⽤户使⽤情况的测试往往和服务器性能测试结合起来，在通过⼯具模拟⽤户操作的同时，还通过测试⼯具的监控功能采集服务器的计数器信息进⽽全⾯分析系统瓶颈。
⽤户并发测试是组合业务性能测试的核⼼内容。
组合并发的突出特点是根据⽤户使⽤系统的情况分成不同的⽤户组进⾏并发，每组的⽤户⽐例要根据实际情况来匹配； 4. 疲劳强度性能测试 疲劳强度测试是指在系统稳定运⾏的情况下，以⼀定的负载压⼒来长时间运⾏系统的测试，其主要⽬的是确定系统长时间处理较⼤业务量时的性能，通过疲劳强度测试基本可以判定系统运⾏⼀段时间后是否稳定； 5. ⼤数据量性能测试 ⼀种是针对某些系统存储，传输，统计查询等业务进⾏⼤数据量时的性能测试，主要针对某些特殊的核⼼业务或者⽇常⽐较常⽤的组合业务的测试； 第⼆种是极限状态下的数据测试，主要是指系统数据量达到⼀定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核⼼业务或者常⽤的组合业务。
《性能测试》课程设计讲解
《性能测试》课程设计90%《性能测试》课程设计题目B2B电子商务站点性能测试姓名：余婷学号：2013030051班级：1302时间：2015 年11 月20 日、测试项目简介B2B商务网站管理系统作为一个供个人和公司使用的商务平台，在这个平台上我们可以发布各类信息，个人可以在网站上发布求职简历、供应各类商品、寻求工作，公司可以在这个平台上提供工作岗位、寻找各类信息和人才，在这个平台上我们能找到我们需要的各类求职信息。
二、测试项目参考技术文档Loadru nner 性能测试教材三、性能测试需求分析1. 可支持300个用户同时访问网站首页，平均CPU占用率不超过90%2. 可保证200个用户并发登录和同时发送站内信息，平均事务响应时间低于12秒3. （疲劳测试）持续5分钟的时间重复浏览供应和求购信息（操作按2:3比例化），事务成功率不低于95%4. 支持最大200个会员同时在线充值成功5. （分组加压测试）模拟高峰段在5分钟内进行1000IP的用户访问，应保证总事务成功率不低于6. （网络性能测试）2M带宽的用户同时提交评论，应保证最大网络带宽不超过50Mb,同时平均事务响应时间不超过12秒7. 同时进行打开首页、登录、发站内信件、发布评论和提交简历（操作比例为321:1:1 ），在其总事务成功率不低于90%的情况下，可保证并发用户数不低于100个。
四、性能测试用例设计（详见测试报告）五、性能测试实施方案（列举用例之一，包括脚本录制、场景设置和结果分析的基本步骤）1.并发测试实施方案事务名称：发送信息脚本录制:打开首页-用户登录-商务中心-站内信-发送信件-完成发送-退出，在脚本中插入集合点test事务login场景设置:默认场景设置结果分析：平均事务响应时间为11s，低于12s，满足系统性能要求2.疲劳性测试实施方案事务名称：供求浏览信息脚本录制：a ction：打开首页-点击供应分类（搜索）acti on 1:点击供应信息-点击求购分类（搜索）-点击求购信息场景设置:设置场景持续五分钟，其他默认设置结果分析：事务成功率为99%高于95%，满足系统性能要求3.分组加压测试实施方案事务名称：供求浏览组供求发布组询价报价组脚本录制：1、供求浏览组action1：打开首页-点击供应分类（搜索）-点击供应信息action2：打开首页-点击求购分类（搜索）-点击求购信息action3:打开首页-点击商务中心-点击供应信息发布-点击提交action4：打开首页-点击商务中心-点击求购信息发布-点击提交action5:打开首页-用户登录--点击供应分类-点击供应信息-询价-提交-退出2、 供求发布组3、 询价报价组action6:打开首页-用户登录-点击求购分类-点击求购信息-报价-提 交-退出其他默认场景设置结果分析： 总事务成功率为 71.5%低于90%，不满足性能要求4. 网络性能测试实施方案 事务名称：发表评论脚本录制：打开首页-用户登录-点击供应分类-点击供应信息-退出 场景设置：运行时设置网络带宽为 2000000kpbs ，其他默认设置 结果分析：平均事务响应时间为8.7s<15s ，满足系统性能需求六、性能测试报告第一章系统概述场景设置:拟制人日期余婷Prepared ByDate审核日期2015年11月20号Reviewed ByDate第二章方案设计 (5)性能测试环境 ......................................................................................... 5 性能测试用例设计 (5)第三章测试结果 (8)第四章综述 (8)系统名称：B2B 电子商务系统 系统组成（前后台）：前后台系统用户（类型）：个人会员，企业会员系统简述（功能）：会员登录，发布评论，发送站内信息，在线充值，浏览供应求购信息等 测试目标（测试需求）：1. 可支持300个用户同时访问网站首页，平均 CPU 占用率不超过90%2. 可保证200个用户并发登录和同时发送站内信息，平均事务响应时间低于 12秒3. （疲劳测试）持续5分钟的时间重复浏览供应和求购信息（300个用户操作按2:3比例化），事务成功率不低于 95%4. 支持最大200个会员同时在线充值成功5.（分组加压测试） 模拟高峰段在5分钟内进行1000I P 的用户访问，应保证总事务成功率不低于 90%测试分组 供应和求购的比例 用户比例 加压设置供求浏览组 1 1 3 6vuser/5s 供求发布组1 12 5vusers/5s 询价报价组1 114vusers/5s6. （网络性能测试）2M 带宽的用户同时提交评论，应保证最大网络带宽不超过50Mb,同时平均事 务响应时间不超过 12秒7. 同时进行打开首页、登录、发站内信件、发布评论和提交简历（操作比例为321:1:1 ），在其总事务成功率不低于90%的情况下，可保证并发用户数不低于100个。
loadrunner用例设计
loadrunner用例设计关于LoadRunner用例设计的主题，我将从以下几个方面逐步回答：1. LoadRunner是什么？为什么需要用例设计？2. 用例设计的基本原则和步骤。
3. 用例设计中需要考虑的关键因素。
4. 用例设计中的一些常见技巧和建议。
5. 实例：如何设计一个基于LoadRunner的用例。
1. LoadRunner是什么？为什么需要用例设计？LoadRunner是一款性能测试工具，由微软公司开发。
它可以模拟大量用户对一个系统进行性能测试，并能够检测系统在负载压力下的表现。
用例设计是为了保证性能测试的准确性和完整性。
通过设计合理的用例，能够有效地模拟实际用户行为，确定系统的瓶颈和性能问题，提高系统的稳定性和性能。
2. 用例设计的基本原则和步骤。
用例设计的基本原则是全面、准确、可重复和可验证。
具体步骤包括：(1) 确定测试目标和范围：明确需要测试的系统功能和性能指标。
(2) 收集需求和分析业务场景：了解用户的使用习惯和行为，并分析相关的业务场景。
(3) 制定测试策略和计划：根据测试目标，制定测试的策略和计划，确定测试环境和数据准备等方面的要求。
(4) 根据业务场景设计用例：根据已收集的业务场景，设计符合实际用户行为的用例，包括各种不同的场景和负载模式。
(5) 编写测试脚本：将设计好的用例翻译成LoadRunner支持的脚本语言。
(6) 运行和监控测试：在测试环境中运行用例，并监控和收集测试结果。
(7) 分析和报告结果：根据测试结果进行分析，找出性能瓶颈和问题，并生成详细的测试报告。
3. 用例设计中需要考虑的关键因素。
用例设计中需要考虑的关键因素包括：(1) 负载模式和场景：根据实际用户行为，设计不同的负载模式和场景，以模拟真实的用户使用情况。
(2) 数据准备：测试环境中需要准备符合业务场景和负载要求的数据，以确保测试的准确性和可重复性。
(3) 性能指标和阈值：根据系统的性能指标和要求，设计测试用例，并设置性能阈值，用于判断系统是否达到了预期的性能要求。
性能测试方案
性能测试⽅案前⾔性能测试⽅案需包含测试测试需求分析、测试对象分析、测试重点分析、测试环境分析、测试场景构建⼏个关键点，其中：测试需求分析：测试中涉及的性能指标的定义测试对象分析：测试中涉及的业务及系统内部模块的定义测试重点分析：测试执⾏策略、测试监控策略、测试风险的定义测试环境分析：测试中涉及到的服务器资源、测试软件、测试数据、测试桩定义测试场景构建：从性能负载、接⼝、疲劳⾓度定义测试场景定义测试场景构建：从性能负载、接⼝、疲劳⾓度定义测试场景项⽬：我们先定义⼀个性能测试项⽬，⽤户⼿机连上wifi，然后打开浏览器链接任意⼀⽹址，页⾯被刷新到登录页⾯，⽤户输⼊⽤户名加密码后点击登录，以此进⾏下⾯的性能⽅案讲解。
1、测试需求分析可从需求⽂档、市场调研去收集性能测试指标1.1、需求⽂档1.1.1、客户明确需求通常情况，客户有明确的需求，定义⼀些性能测试指标，例：每秒⽤户登录页⾯刷新多少、每秒登录⽤户量多少，⽤户在线总量多少，我们明确性能测试指标。
1.1.2、客户隐形需求基于客户明确指标下，会有⼀些隐性指标，例：100万在线⽤户的查询在5秒响应，我们也许纳⼊性能测试指标内。
1.1.3、⽤户模型确定有了以下的性能测试指标后，我们可以创建我们的⽤户模型，如下：1. ⽤户指标：⽤户登录TPS需达到50、⽤户登录页⾯刷新TPS需达到250；2. ⽤户总量：总⽤户量100万；3. ⽤户模型：系统每天⽤户在线量在100万左右，平均在早晨8、11点期间登录，其中登录页⾯刷新与登录⽐例为5:1。
1.2、市场调研1.2.1、客户⽆明确需求也有特殊的情况，客户只会提供⼀些基础数据，例：2000个机构下，500万的⽤户总量，我们需要根据这些基础数据提炼出我们的性能指标。
1.2.2、市场调研需求有了基础数据后，还需要对我们所关⼼的性能指标做市场调研，最终得出我们的性能指标例：对其中1个机构1个⽉的⽤户登录数进⾏数据采集（每天早晨8-9点是登录⾼峰期，每天⼤约是1⼩时内登录100⼈次，平均到每秒100÷3600约为0.027次/秒），然后在推算2000个机构下，⽤户每秒登录0.027*2000约50次，在根据后台⽇志推算出，登录与登录页⾯刷新⽐例为1:5，登录页⾯刷新TPS为2500。
基于场景的性能测试设计
问题 是 由软件 系统 本身 产 生的 ， 可能 会 无法
根 治性 能 问题 。例 如 架构 设 计 方 面 的失 误 ， 可能 意味 着软 件 系统 将被 废掉 。 当然 这并 不意味 所有 的性能 预试 都要尽 ４ 早 进 行 ， 能 测 试 的启 动时 间要 由软 件 特 点 性
数 据 量 测 试 等许 多 内 容 。
统 本 身 也要 进 行优 化 ， 以便 全 面提 高 性 能 。
误 区 ５ 在 开 发 环 境 下 进 行 性 能 测 试 ： 误 区 ２ 在 其 它 测 试 完 成后 进 行 性 能 测试 ： 很 多时 候 ， 在软 件 开发 完 成后 进 行性 能
口陈绍英
很 多企业 在性 能测试 工作 中存在 一些 常
流 行 的 初期 ， 件 规模 一 般 较 小 ， 软 而硬 件 的 的 。如 果 应 用 系统 功 能 不 完 善 或 者 代码 运 行 效 率 低 下 ，通 常 会 带 来 一 些 性 能 问题 。
见误 区 ， 中部 分 企业 选 择基 于 场景 的设 计 更 新 却是 日新 月异 ， 件 性能 一 般 不是 突 出 其 软 性 能 测试 来 避 免这 些 误 区 ， 因为这 样 可 以大 幅 度降 低执 行 成 本 ， 同时 提 高性 能 测 试执 行 效率 。
维普资讯
Ｓ。 ａ ｇｅ ｇ 瞄 ｆ ｒ ｎｎ 团 盈 ｔ ｅ ｉｅ ｗ Ｅ
基于场景 的性 能测 试设计
性能 测试 在 测试 中往 往 不被 重视 ，而项 目中 由于 系统性 能 不合格 会 给 企 业带 来 巨大 的 损 失 。基 于 场景 的性 能测 试设 计 能 避免 性 能 测试 的 误 区 。
因此性能 测试 要尽量 在高 配置的 用户投
如何进行医疗健康应用的性能测试
如何进行医疗健康应用的性能测试医疗健康应用在近年来的快速发展中，为人们的健康管理和医疗服务提供了便利。
随着越来越多的人开始使用这些应用，保证其性能的可靠性和准确性显得尤为重要。
本文将介绍如何进行医疗健康应用的性能测试，以确保其在不同场景下的稳定和可靠性。
一、测试目标确定在进行性能测试之前，我们需要明确测试的目标和需求。
根据医疗健康应用的特点，我们应关注以下几个方面：1. 响应时间：测试应用在不同负载下的响应速度，确保用户能够迅速获取所需信息。
2. 并发用户数：测试应用在同时处理多个用户请求时的负载能力，以确定应用在高峰期的稳定性。
3. 可用性：测试应用在长时间连续运行下的稳定性，确保不存在崩溃或意外停机的情况。
4. 数据传输安全性：测试应用对用户个人信息的保护程度，确保数据传输过程中的安全性和隐私保护。
二、测试环境配置在进行性能测试之前，我们需要搭建适当的测试环境。
首先，选择一台或多台与真实生产环境相似的服务器作为测试服务器，确保测试的准确性。
其次，配置与真实生产环境相似的网络环境，包括网络带宽、延迟等。
最后，创建测试数据库和模拟用户数据，以模拟真实用户的使用场景。
三、测试工具选择根据测试的目标和需求，选择合适的性能测试工具。
市面上常用的工具有Apache JMeter、LoadRunner等，它们提供了丰富的功能和插件，可以实现对医疗健康应用的全方位性能测试。
四、性能测试方案设计在进行性能测试之前，我们需要设计一套完备的测试方案。
方案应包含以下内容：1. 测试场景设计：根据实际使用情况和需求，设计一系列模拟真实用户行为的场景。
例如，用户注册、登录、浏览医疗资讯、查询病历等。
2. 负载模型设计：根据真实场景的负载情况，设计不同的负载模型。
例如，模拟每日高峰期的用户请求，确保应用在高负载情况下的稳定性。
3. 性能指标定义：定义一系列合适的性能指标，如平均响应时间、吞吐量、并发用户数等。
这些指标将用于评估应用的性能表现。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
验证测试是用于验证在特定的场景、时间、压力、环境和操作方式下系统能够正常的运行，服务器、应用系统和网络环境等软硬件设施还能否良好的支撑这些情况下用户的使用。
验证性测试主要针对有明确的压力目标和预期结果，验证系统在这种压力下的各方面反映能够达到预期结果。
主要分以下几种：
压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。
系统各性能指标在这种压力下是否还在正常数值之内。
系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。
Ramp Up 增量设计如并发用户为75人系统注册用户为1500人已5％－7％作为并发用户参考值。
一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。
已事务通过率与错误率衡量实际加载方式。
Ramp Up增量设计目标寻找已增量方式加压系统性能瓶颈位置抓住出现的性能拐点时机一般常用参考
Hits点击率与吞吐量、CPU、内存使用情况综合判断。
模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。
另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。
加压方式不变，在各脚本事务点中设置同集合点名称（如：
lr_rendzvous("same");）
在场景设计中，使用事务点集合策略。
以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser.
稳定性测试：已知系统高峰期使用人数、各事务操作频率等。
设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。
并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。
事务响应时间是否会出现波动或随测试时间增涨而增加。
系统是否会在测试期间内发生如宕机、应用中止等异常情况。
根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。
仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。
场景设计思想：从稳定性测试场景的设计意义，应分多种情况考虑：
针对同一个场景为例，以下已公文附件上传为例简要分析场景设计思想：
1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。
2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。
测试方法：采用1)Ramp Up-Load all Vusers simultaneously
2)Duration-Run Indefinitely
3)在Sechedule-勾选Initalize all Vusers before Run
容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。
如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。
验证其能否有效触发保护措施。
问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。
验证这些模块是否还会发生同样的性能问题。
如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。
测评测试是用于获取系统的关键性能指标点，而进行的相关测试。
主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）
评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。
通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。
评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。
通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。
判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）
评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。
通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。
模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。
判定标
准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。
取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。
评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。
得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。
问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。
需通过响应的测试场景重现问题或定义问题。
如有可能，可以直接找出引起性能问题所在的代码或模块。
该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。
并在场景运行过程中辅以手工测试。