性能测试
(1)业务学习 :通过查看文档，手工操作系统来了解系统功能
(2) 需求分析 分析系统非功能需求，圈定性能测试的范围，了解系统性能指标。
(3)工作评估:工作量分解，评估工作量，计划资源投入(即需要多少人力，多少工作
日来完成性能测试工作)。
(4) 设计模型 圈定性能测试范围后，把业务模型映射成测试模型。
什么是测试模型呢?比如一个支付系统需要与银行的系统要进行交互〈充值或者转出)，
由于银行不能够提供支持，我们会开发程序去代替银行系统功能(这就是挡板程序， Mock
程序)，保证此功能的性能测试能够开展:这个过程就是设计测试模型。
再比如，后面要讲到的实例项目 Jforum 论坛，根据需求我们了解到一般大家发帖或回帖
前都会先登录，那么我们在开发脚本时就要把登录与发帖或回帖场景绑定在一起进行测试:
这就是测试模型。通俗点说就是性能测试用例设计加性能测试实现方案，用例只关注业务，
模型还需关注如何实现，是否具有可操作性，可验证性等问题最后我们还得根据不同的测试
目的组合成不同的测试场景。
5) 计划编写:计划测试工作，在文档中明确列出测试范围、人力投入、持续时间、工
作内容、风险评估、风险应对策略等。
(6) 脚本开发 录制或者编写性能测试脚本(现在很多被测系统都是无法录制脚本的，
我们需要手工开发脚本)，开发测试挡板程序，开发测试程序等。有时候如果没有第三方工具
可用，甚至需要开发测试程序或者工具。
(7) 测试环境准备 性能测试环境准备包括服务器与负载机两部分，服务器是被测系统
的运行平台(包括硬件与软件，比如应用服务器需要 8Core 32G 内存，中间件是Jboss7 等)，
负载机是我们用来产生负载的机器，用来安装负载工具，运行测试脚本。
(8) 测试数据准备 根据数据模型来准备被测系统的主数据与业务数据(主数据是保
证业务能够运行畅通的基础，比如菜单、用户等数据:业务数据是运行业务产生的数据，
比如订单:订单出库需要库存数据，库存数据也是业务数据。我们知道数据量变会引起性
能的变化，在测试的时候往往要准备一些存量/历史业务数据，这些数据需要考虑数量与
分布〉。
(9) 测试执行:测试执行是性能测试成败关键，同样脚本不同执行人员得出的结果可能
差异较大。这些差异主要体现在场景设计与测试执行上。
(1 0) 缺陷管理 对性能测试过程中发现的缺陷进行管理
(1 1) 性能分析 对性能测出过程中暴露出来的问题进行分析，找出原因
(12) 性能调优 性能测试工程师与开发人员一起来解诀性能问题。
03 )测试报告:测试工作的重要交付件，对测试结果进行报告，主要包括常见的性能指
标说明 (TPS RT Using... .. ，发现的问题等。
性能测试主要交付件
• 测试计划;
• 测试脚本;
• 测试程序;
•测试报告或者阶段性测试报告。
如果性能测试执行过程比较长，换句话说性能测试过程中性能问题比较多，经过了多轮
的性能调优，需要执行多次回归测试，那么在这个过程中需要提交阶段性测试报告
(1 4) 评审 对性能报告中的内容进行评审，确认问题、评估上线风险。有些系统虽然测
试结果不理想，但基于成本及时间的考虑也会在评审会议中通过从而上线。
性能测试相关术语
(1)负载:模拟业务操作对服务器造成压力的过程，比如模拟 100 个用户进行发帖
(2) 性能测试 (Perfonnance Testing): 模拟用户负载来测试系统在负载情况下，系统的
响应时间、吞吐量等指标是否满足性能要求。
(3)负载测试 (Load Testing): 一定软硬件环境下 ，通过不断加大负载 (不同虚拟用
户数〉来确定在满足性能指标情况下能够承受的最大用户数。简单说，可以帮我们对系统进
行定容定量，找出系统性能的拐点，给予生产环境规划建议。这里的性能指标包括 TPS (每
秒事务数)、 RT (事务平均响应时间〉、 CPU Using (CPU 利用率) Mem Using (内存使用
情况)等软硬件指标。从操作层面上来说，负载测试也是一种性能测试手段，比如下面的配
置测试就需要变换不同的负载来进行测试。
(4) 配置测试 (Configuration Testing): 为了合理地调配资源，提高系统运行效率，通过
测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映
出来的不同性能，从而为设备选择、设备配置提供参考
(5) 压力/强度测试 (Stress Testing): 定软硬件环境下，通过高负载的手段来使服务
器资源(强调服务器资源，硬件资源〉处于极限状态，测试系统在极限状态下长时间运行是
否稳定，确定是否稳定的指示包括 TPS RT CPUUsing Mem Using 等。
(6) 稳定性测试 (Endurance Testing) 在一定软硬件环境下，长时间运行一定负载，确
定系统在满足性能指标的前提下是否运行稳定。与上面的压力/强度测试区别在于负载并不强
调是在极限状态下(很多测试人员会持保守观念，在测试时会验证极限状态下的稳定性)，着
重的是满足性能要求的情况下，系统的稳定性、比如响应时间是否稳定、 TPS 是否稳定。一27 性能测试通过标准 23
般我们会在满足性能要求的负载情况下加大1. 情的负载量进行测试。
(7) TPS: 每秒完成的事务数，通常指每秒成功的事务数，性能测试中重要的综合性性
能指标。一个事务是一个业务度量单位，有时一个事务会包括多个子操作，但为了方便统计，
我们会把这多个子操作计为一个事务。比如一笔电子支付操作，在后台系统中可能会经历会
员系统、账务系统、支付系统、会计系统、银行网关等，但对于用户来说只想知道整笔支付
花费了多长时间。
(8) RTI ART (Response Time/average Response Time): 响应时间/平均响应时间 ，指一个
事务花费多长时间完成(多长时间响应客户请求)，为了使这个响应时间更具代表性，会统计
更多的响应时间然后取平均值，即得到了事务平均响应时间 CART) ，为了方便大家通常会直
接用 RT 来代替 ART ART RT 是代表同一个意思。
(9) PV CPage Vìew): 每秒用户访问页面的次数，此参数用来分析平均每秒有多少用户
访问页面。
C 10) Vuser 虚拟用户 (Virtual user) :模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟
的操作步骤都被记录在虚拟用户脚本里。 Vuser 脚本用于描述 Vuser 在场景中执行的操作。
C 11) Concurrency 并发，并发分为狭义和广义两类。
狭义的并发，即所有的用户在同一
时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样
的操作，目的是测试数据库和程序对并发操作的处理。 广义的并发，即多个用户对系统发出
了请求或者进行了操作，但是这些请求或操作可以是不同的。对整个系统而言，仍然有很多
用户同时进行操作。 狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负
载测试、压力测试、稳定性测试场景:广义并发不限制对系统的请求操作，多适用于混合场
景、稳定性测试场景。
(2)场景 Scenario): 性能测试过程中为了模拟真实用户的业务处理过程，在 LoadRunner
中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等的一系列动作的
集合，称之为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、
测试目标、测试执行时的配置条件等。
(13 )思考时间 CThi Time) 模拟正式用户在实际操作时的停顿间隔时间。从业务的
角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。
在测试脚本中，
思考时间体现为脚本巾两个请求语句之间的间隔时间。
(1 4) 标准差 CStd. Deviation): 该标准差根据数理统计的概念得来，标准差越小，说明
波动越小，系统越稳定，反之，标准差越大，说明波动越大，系统越不稳定。包括响应时间
标准差、 TPS 标准差、 Running Vuser 标准差、 Load 标准差、 CPU 资源利用率标准差、 Web
Resources 标准差等。举例响应时间标准差。
性能测试通过标准
性能测试从需求、设计、准备、执行到分析，最后需要判断性能测试是否通过，性能测
试工程师最终需要考虑很多因素，判断的标准相应也会有多个维度。
性能测试通过标准包括服务端性能、前端性能和用户体验性能，常规通过标准如表 2-2
所示。
