2.2 并发用户数
系统并发用户数：同一时间内访问系统的用户数。针对的是服务器最大承载量。关注的 是瞬间最大访问量。 业务并发用户数：从用户角度来说，在相当长的一段时间内，都会有基本固定数量的用 户访问系统。 系统用户数：使用该系统的用户总数。 在线用户数：同时在线的用户数。 在做并发测试的时候，一般会采取两种方法： 一是在并发数一定的情况下，按业务不同进行测试（业务一，多少人一起使用，什么时 候开始使用，使用多长时间） 。这种方式更多的是业务并发测试。 二是在并发数一定的情况下，只做单纯一样的操作（查询、修改、添加、删除） 。这种 方式更多的是系统并发测试。 估算并发用户的公式： C=nL/T 其中：C 为平均并发用户数；n 为 login session 的数量；L 为 login session 的平均时 间长度；T 为考察的时间段长度。 峰值并发数： Cm=C+3*√C 假设 login session 符合泊松分布。 比如：OA 系统，共 3000 个用户，每天大约有 400 个用户访问，对一个用户来说，每天 在线时间为 4 小时，而每天工作时间为 8 小时。则平均的并发用户为 C=400*4/8=200，并发
2.3 吞吐量
单位时间内系统处理的客户请求的数量。体现软件系统的性能承载能力。 一般描述：请求数/秒或页面数/秒。 业务角度来说，访问人数/天或处理的业务数/小时。 网络角度：字节数/天==网络流量。 作用： 1、用于协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目 标； 2、用于协助分析性能瓶颈。比如以字节数/秒主要反映受网络基础设施、服务器架 构、应用服务器制约；以单击数/秒表示主要受应用服务器和应用代码的制约。 在未遇到性能瓶颈时，计算公式： F=Nvu*R/T。 Nvu 表示虚拟用户的个数(Virtual Users)；R 表示每个 VU 发出的请求(单击)数量；T 表示测试时间。
3.5 Segue 性能测试过程 Silk performer
在 Segue 中提供的性能测试过程，是一个 try-check 过程，即：评估需求→开发测试→ 建立基线→执行测试→分析结果→回归测试→测试结束。
3.6 PTGM 模型
Performance Testing General Model。 该性能测试模型将性能测试分为测试前期准备、 测试工具引入、 测试计划、 测试设 计与开发、 测试执行和管理以及测试分析等 6 个步骤。
用户关注的是软件对用户操作的响应时间。此响应时间=呈现时间+系统响应时间。
1.2 管理员角度
关注系统的响应时间。对于系统管理员来说，用户客户端所消耗的时间是不考虑的。重 点就考虑系统响应时间，包括网络耗时、各服务器耗时等。 还会关注系统状态，比如资源利用率、系统可扩展性、系统容量、系统稳定性。
1.3 开发角度
4.3 压力测试 Stress Testing
测试系统在一定饱和状态下，如 CPU、内存等在饱和使用情况下，系统能够处理的会话 能力，以及系统是否会出现错误。 1）主要目的是检察系统处于压力情况下时，应用的表现。通过增加访问压力，如增加 并发用户， 使应用系统的资源使用保持在一定的水平。 检测此时的表现， 有无错误信息， 响应时间等。 2）通过模拟负载等方法，使系统的资源使用达到较高的水平。比如设定为“CPU 75%， 内存 70%”情况下，有无错误、系统响应时间。其他，如 JVM 内存、DB 连接数、DB 的 CPU 等。 3）测试系统的稳定性。如果一个系统能够在压力环境下稳定运行一段时间，那么这个 系统在通常的运行条件下应该可以达到令人满意的稳定程度。
2.4 性能计数器
Counter。描述服务器或操作系统性能的一些数据指标。 资源利用率：系统各种资源的使用状况。
2.5 思考时间
Think Time：从业务角度来说，指用户在进行操作时，每个请求之间的间隔时间。 思考时间与迭代次数、并发用户数和吞吐量之间存在一定的关系。 计算公式： R=T/Tt R：每个用户发出的请求数；T 为测试时间；Tt 为思考时间。 计算思考时间的一般步骤： 1、 首先计算出系统的并发用户数； 2、 统计出系统平均的吞吐量 3、 统计出平均每个用户发出的请求数量
3.3 性能下降曲线分析法
性能下降曲线分析法：通过性能曲线上的单用户区，性能平坦区，压力区域以及性能拐 点几个关键因素来分析性能瓶颈问题。
从上图可以看到，发布博文事务曲线非常平滑，最大响应时间为 0.999 秒，是属于非常 好的现象，其它事务随着负载用户数量的增大，出现相应的波动，从而可以分析性能问题所 在。从图中可以看到，一条曲线可以分为以下几个部分： （1）性能平坦区——在不进行更多性能调优情况下所能期望达到的最佳性能。这个区 域可被用作基线或是 benchmark。 （2）压力区域——应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区 域的开始。 （3）性能拐点——性能开始“急剧下降”的点。 这几个区域实际上明确标识了系统性能最优秀的区间， 系统性能开始变坏的区间， 以及 系统性能出现急剧下降的点。对性能测试来说，找到这些区间和拐点，也就可以找到性能瓶 颈产生的地方。因此，对性能下降曲线分析法来说，主要关注的是性能下降曲线上的各个区 间和相应的拐点，通过识别不同的区间和拐点，从而为性能瓶颈识别和性能调优提供依据。
5 性能测试领域
5.1 能力验证
在给定条件下，系统能否具有预期的能力表现。 问题描述方式： “某系统能否在 A 条件下具有 B 能力” 在已确定的环境下运行，根据典型场景设计测试方案和用例，确定相应的性能目标。 一般采用性能测试。可靠性验证、压力测试、失效恢复测试也可归入。
4.7 失效恢复测试（Failover Testing）
针对有冗余备份和负载均衡的系统设计的。 用来检验如果系统局部发生故障， 用户能否 继续使用系统；以及如果发生，用户将受到多大程度的影响。还关注问题发生时，能支持多 少用户访问和采取何种应急措施。 一般说来， 只有对系统持续运行指标有明确要求的系统才 需要进行此类测试。
3目标
A：Analysis，分析 M：Metrics，度量 E：Execution，执行 （A）：Adjust，调整。E 执行失败后才进入 A 阶段，并且涉及的大多是有关开发和系 统管理工作，因此 A 设为隐式。 性能测试过程模型如图 1-5 所示。
1 软件性能定义
性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软 件产品的一种特性，可以用时间来度量。性能的及时性用响应时间或者吞吐量来衡量。而响 应时间是对请求做出响应所需要的时间。
1.1 用户角度
比如一个典型的 Web 应用：
WEB Server
APP Server
DB Server
4.2 负载测试 Load Testing
通过在被测系统上不断增加压力，直到性能指标。找到系统的处理极限，为系统调优提 供数据。亦称为可量性测试(Scalability Testing)。 极限描述： 在给定条件下最多允许 120 个并发用户访问 或 在给定条件下最多在 1 小时 内处理 2100 笔业务。 预期的性能指标：响应时间不超过 10S 或 服务器平均 CPU 利用率低于 65%。
关注于如何通过调整设计和代码实现， 或是如何通过调整系统设置等方法提高软件的性 能表现。和如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷。 会从系统架构、数据库设计、代码质量等方面考虑性能。
USER 呈现时间
WEB UI
系统响应时间
2 软件性能的主要术语
2.1 响应时间
对请求做出响应所需要的时间。响应时间=呈现时间+系统响应时间。 呈现时间：取决于数据在被客户端收到响应数据后呈现页面所消耗的时间。 系统响应时间：应用系统从请求发出开始到客户端接收到数据所消耗的时间。 从设计角度考虑，更好的用户体验是，前端在等待数据结果时，提供进度条或逐步显示 数据。 进一步分解响应时间：网络传输时间+应用延迟时间（Web 服务器延迟时间+DB 延迟时 间） 。 对于响应时间，其标准不一。一般页面的响应时间，2 秒是非常有吸引力，5 秒是比较 不错的，10 秒则是忍受的极限。视具体情况具体设置。
用户峰值为 242。 实际应用过程中， 要考虑时间的细粒度或结合业务峰值和谷值来更精确的估算并发用户。 更一般的公式是：C=n/10，即以每天访问系统用户数的 10%作为平均的并发用户数 Cm=r*C r 为调整因子，取值一般为 2~3 对 web 服务器的日志分析，能得到更为精确的最大并发用户访问数。
3.4 Loadrunner 性能测试过程
负载测试一般包括 5 个阶段：规划、创建脚本、定义场景、执行场景和分析结果。
➤ 规划负载测试。定义性能测试要求，例如并发用户数量、典型业务流程和要求的 响应时间。 ➤ 创建 Vuser 脚本。在自动化脚本中录制最终用户活动。 ➤ 定义场景。使用 LoadRunner Controller 设置负载测试环境。 ➤ 运行场景。使用 LoadRunner Controller 驱动、管理并监控负载测试。 ➤ 分析结果。使用 LoadRunner Analysis 创建图和报告并评估性能。
4.4 配置测试 Configuration Testing
对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找 到系统各项资源的最优分配原则。 1）了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。 2）规划领域内评估该如何调整才能实现系统的扩展性。
4.5 并发测试 Concurrency Testing
关注于负责测试计划，目标产生“清晰、易理解、可验证的负载测试计划” 。 关注：目标、用户、用例、生产环境、测试环境和测试场景。
3.2 RBI 方法
Rapid Bottleneck Idenfity.快速识别系统性能瓶颈的方法。基于：发现 80%系统的性能瓶 颈都由吞吐量制约； 并发数和吞吐量瓶颈之间存在一定的关联； 采用吞吐量测试可以更快速 定位问题。 首先访问“小页面”或“简单应用” ，从应用服务其、网络等基础的层次上了解系统吞 吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长 趋势，并通过不断增加并发用户数和吞吐量，观察系统的性能表现。