性能测试概述

---

为什么要进行性能测试

1. 获取系统性能的指标，作为性能指标的基准
2. 验证系统的性能指标是否达到要求（性能需求）
   应用程序是否能够满足系统要求的各种性能指标
   应用程序是否能处理预期的用户负载并有盈余能力
   应用程序是否能处理业务所需要的事务数量
   在预期和非预期的用户负载下，应用程序是否稳定
3. 是否能确保用户在真正使用软件时获得舒服的体验
4. 发现系统的性能瓶颈，内存泄漏等问题。
5. 系统正常工作的情况下的最大容量。
6. 帮助系统运维部门能更好的规划硬件配置

性能测试实施的流程

• 分析性能测试需求
• 根据性能测试的目标，设计性能测试的场景
• 开发性能测试场景和性能测试脚本
• 分析性能测试报告
• 根据性能测试报告排查和定能系统的性能瓶颈

如何确定性能测试的需求

关键性能指标分析

在进行性能测试需求之前，一定要清楚的知道系统的性能需求，不能过于简单或者过于模糊的描述性能需求，系统性能的需求必须通过具体数据进行量化，也就是人们常说的性能指标。

性能指标一旦量化，就可以度量，才具备可测试性（可验证性），即能确认系统的性能指标是否符合设计的要求，是否符合客户的需求。

案例：
某电商交易系统，业务要求支持2亿用户（同一时刻1%的用户在线)，每天支持2000万次交易量（交易的时间集中在早上8点到凌晨2点），交易响应时间要求在1s中之内。

此外，高峰期系统的处理能力要求是平均值的3倍；
本地交易响应时间正常低于1s,在高峰时可以高于1s，但是要在3s内。
正常及交易成功率100%，在高峰期不能低于99.9%

这样的业务要求，作为测试人员，如何转化为可以性能测试可以验证的指标呢？
（1）业务支持2亿用户
数据库要支持这个量级的数据存储。同时按1%的用户在线，那么意味着同时有200万用户在线，那系统就要支持这个数量级用户的各种增删改查操作。
（2）每天支持2000万次交易
根据题意，每天交易的时间在18小时，折算成每秒需要完成多少次交易，即20000000/(18 * 60 * 60)=309次/s
…

一组清晰定义的预期性能指标值，是性能测试的基本要素。

关键业务分析

系统如果出现问题，看似整个系统无法正常运行，实际往往是因为系统运行时某一个环节出了问题，系统的性能问题也是一样，如果在某一些业务功能上不出现性能问题，那么系统就不会出现性能问题，而这些业务功能就是系统性能测试的关键业务所在。

根据帕雷托法则（pareto Principle)，系统中各个功能的使用频率是不相同的，有20%的功能是常用的功能，用户80%以上的时间都在使用这些功能，这些功能就是性能测试当中我们测试人员需要关注的。

比如淘宝这样的购物平台，首页肯定是用户访问量最多的页面，其次，用户进来之后要搜索自己喜欢的商品，输入关键字之后，相关的产品就会根据人气，价格等排序并且展示出来。所以，对于淘宝这样的购物平台，“打开首页”，“搜索”功能等操作就会被选择为性能测试的关键业务功能。

总而言之，在性能测试中，我们测试人员首先要了解哪些业务功能是用户最常使用的，以此来确定性能测试的关键业务功能。

但是能仅仅依靠功能的使用频率来确定性能测试的关键业务吗？
答案是否定的。

我们还要看这个业务功能后面的计算量，它是否耗时，对系统资源的消耗。

例如，淘宝购物当中95%的用户搜索商品，5%的用户才会提交订单，完成支付。
提交订单和支付这两个功能计算更耗时，计算量更大些，它关联着较多相关数据的读写，支付会涉及到外部接口（支付宝），所以这两个功能就是我们性能测试的关键业务。

综上，要确定性能测试的关键业务要从业务功能的使用频率和功能的计算量，资源的消耗程度来决定。

确定好关键业务之后，我们在进行性能测试的时候只要对关键的业务进行测试用例的设计，系统的性能测试脚本就会基于这些关键的业务进行开发。

衡量软件性能的四个维度

软件开发人员

• 系统架构：架构设计是否合理？
• 数据库设计：数据库设计是否存在问题？
• 算法：核心算法是否高效
• 设计和代码：系统中是否存在不合理的线程同步方式和不合理的资源竞争？

系统运维人员（操作系统、网络、服务器等等）

• 资源利用率：应用服务器和数据库资源使用状况合理吗？
• 系统容量：系统最多能支持多少用户的访问？系统最大的业务处理量是多少？
• 系统稳定性：系统是否能支持7X24小时的业务访问？
• 系统可扩展性：系统是否能够实现扩展？系统性能可能的瓶颈在哪里？更换哪些设备能够提高系统性能？

用户

• 从终端用户的维度来讲，软件性能表现为用户进行业务操作时的主观响应时间，具体来讲就是从用户在界面上完成一个操作开始，到系统把本次操作的结果以用户能察觉的方式全部展示出来的全部时间。对终端用户来说，这个时间越短越好。
• 系统稳定性也是用户关注的重点

性能测试人员

• 以上所有层面都需要关注
• 是否能够发现系统中存在的瓶颈？
• 是否真实有效的评估系统性能能力？

概念和术语介绍

性能测试

性能测试是一项综合性的工作，致力于暴露性能问题，评估系统性能趋势。

性能测试工作实质上是利用工具去模拟大量用户操作来验证系统能够承受的负载情况，找出潜在的性能问题分析并解决；找出系统性能变化趋势，为后续的扩展做准备。

一般地，它主要是针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。性能指标里包括系统各个方面的能力，如系统并发处理能力，系统响应时间，批量业务处理能力等等。

并发用户数

并发用户会对系统造成压力，首先对系统用户数，在线用户数，并发用户数做一个区分。

• 系统用户数：简单地说就是该系统的注册用户数。例如，百度贴吧里存在6666个注册用户，他们可以是活跃的，也可以是僵尸的。
• 业务层面的并发用户数：指的是同时向服务器发送请求的用户数量。
• 后端服务器层面的并发用户数：指的是同时向服务器发送请求的请求数量。

响应时间/平均响应时间（RT/ART)

从用户视角来考虑，响应时间反映了完成某个操作所需要的时间，标准定义是，应用系统从发出请求开始，到客户端接收完所有的字节数据所消耗的时间。

响应时间分为前端展示时间 和系统响应时间 两部分

• 前端展示时间指的是客户端收到服务器返回的数据后渲染前端页面，所耗费的时间。
• 系统的响应时间，分为web服务器，应用服务器，数据库服务器等各种服务器之间通信和处理请求的时间。

事务响应时间（Transaction Reponse Time）

每秒完成的事务数，通常指每秒成功的事务数，性能测试中重要的综合性性能指标。

这里的一个事务是一个业务度量单位，是指一组密切相关的子操作的组合。比如，一笔电子支付操作，后台处理的时候可能需要经过会员系统，账务系统，支付系统，银行系统等，这就是是一个关于支付事务里面包含的操作。而对于用户，往往也只关注整个支付花费了多长时间。

每秒事务通过数（Transaction Per Second）

TPS 是指每秒系统能够处理的事务数。 它是衡量系统处理能力的重要指标。

当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的增减而改变。

地铁检票机：
只有10台进站检票的机器，1台机器1秒能进1个人
并发用户数为5，则TPS为5
并发用户数为10，则TPS为10
并发用户数为100，则TPS仍为10

点击率（Hit Per Second）

每秒点击数代表用户每秒向Web 服务器提交的HTTP请求数。 点击率越大，服务器压力越大。

这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。

吞吐量（Throughput）

吞吐量以单位时间为度量衡量；单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力。

一般来说用Requests/second，Pages/Second，Bytes/Second，从业务的角度，也可以用访问人数/天或是处理的业务数/小时来衡量，从网络设置的的角度来说，也可以用字节数/天来衡量。

吞吐量受服务器和网络性能的影响

资源利用率

不同系统资源的使用情况。 包含CPU，内存，硬盘，网络等。

常见的性能指标

• 并发
  并不是只要发出请求，就会对服务器造成压力。
  并发强调大量用户同时性的操作才会对服务器造成压力。
  

• 系统/事务的平均响应时间

• 事务处理效率TPS（Transaction Per Second）

• 吞吐率

• 每秒点击次数（Hits Per Second)

• 服务器资源占用情况，内存和CPU使用率

• 软、硬件配置是否合适（容量规划/硬件选型）

性能测试的分类

一般性能测试

正常情况下和系统条件下是否满足性能指标。没有高并发等特殊情况。

负载测试

验证系统在一定条件下延长系统的运行时间，直到系统出现“拐点”。

压力测试

验证系统在已经处于极限负载下或某指标已经处于饱和状态下性能的表现。（一定要把系统搞崩溃，从而了解系统的承受极限）

稳定测试

验证系统在连续运行情况下，查看系统的各项性能指标。（内存泄漏）