性能测试基本知识

性能测试

性能指标

• RT（响应时间）：从用户发送一个请求到用户接收到服务器返回的响应数据这段时间。

  • 计算方式：responseTime = 网络时间+应用程序处理时间，合理的响应时间2/5/8,2秒比较有吸引力，5秒比较糟糕，10秒非常糟糕，10秒之外请求失败。

• Throughput（吞吐量）：单位时间内系统处理的客户端请求数量。

  • 计算方式：Throughput = （number of requests）/(total time)

• 吞吐率：吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量网络性能的重要指标。

  • 计算方式：吞吐率用字节数/秒来衡量，当然，也可以用“请求数/秒”和“页面数/秒”来衡量。

• 并发数：①狭义上的并发：所有用户在同一时间点进行同样的操作，一般指同一类型的业务场景，比如1000个用户同时登陆系统；②广义上的并发：多个用户与系统发生了交互，这些业务场景可以是相同的也可以是不同的，交叉请求和处理较多；

• 资源利用率：资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关。

  • 资源指标：CPU，内存，IO，带宽

  • 系统指标：并发用户数，响应时间，事务成功率，超时错误率

    • 资源指标：CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%；

      内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%；

      磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能；

      网络带宽：一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；

    • 系统指标：并发用户数：单位时间内与系统发生交互的用户数；

      在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求；

      平均响应时间：系统处理事务的响应时间的平均值；事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间；

      事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般以事务成功率来度量；

      超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率；

• TPS（每秒事务数）：服务器在单位时间内可以处理的事务数量，一般以request/second为单位。QPS是查询，而TPS是事务，事务是查询的入口，也包含其他类型的业务场景，因此QPS应该是TPS的子集！

• QPS（每秒查询率）：指服务器在单位时间内（秒）处理的查询请求速率；TPS和QPS都是衡量系统处理能力的重要指标，一般和并发结合起来判断系统的处理能力；

• Thinking Time（思考时间）：思考时间，在性能测试中，模拟用户的真实操作场景。用户操作的事务与事务之间是有一定间隔的，此时间内是不对服务器产生压力的，引入这个概念是为了并发测试（有交叉业务场景）时，业务场景比率更符合真实业务场景；

• PV（页面浏览量）：通常是衡量一个页面甚至网站流量的重要指标；

• RT/ART：Response Time/average Response Time：响应时间/平均响应时间，指一个事务花费多长时间完成；一般来说，性能测试中平均响应时间更有代表意义。细分的话，还有最小最大响应时间，50%、90%用户响应时间等；

性能需求评估

在实施性能测试之前，我们需要对被测系统做相应的评估，主要目的是明确是否需要做性能测试。如果确定需要做性能测试，需要进一步确立性能测试点和指标，明确该测什么、性能指标是多少，测试通过or不通过的标准？性能指标也会根据情况评估，要求被测系统能满足将来一定时间段的业务压力。
业务角度:
系统是公司内部 or 对外？系统使用的人数的多少？
系统角度：
a）系统架构：b）数据库要求：c）系统特殊要求：

确定性能测试点

• 关键业务：
  确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如转账，扣款等接口。如果项目（或功能点）不属于关键业务（或关键业务点）

• 日请求量：
  确定被测项目各功能点的日请求量（可以统计不同时间粒度下的请求量如：小时，日，周，月）。如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试，而且关键业务点，可以被确定为性能点

• 逻辑复杂度：
  判定被测项目各功能点的逻辑复杂度。如果一个主要业务的日请求量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式方式的调用中，当某一个环节响应较慢，就会影响到其它环节，造成雪崩效应。

• 运营推广活动：
  根据运营的推广计划来判定待测系统未来的压力。未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用。例如，运营计划做活动，要求系统每天能支撑多少 PV、多少 UV，或者一个季度后，需要能支撑多大的访问量等等数据。当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要做性能测试。

建立性能指标

a.选取核心业务流程（重要程度/频繁）
b.并发用户数
c.事物吞吐需求
d.响应时间需求
e.系统占用资源需求
f.可扩展性需求

建立系统负载模型

• 业务层面：
  （a）核心业务流程吞吐率
  （b）高峰期业务分布时段

• 系统负载：
  （a） 高峰/平常场景吞吐率
  （b）CPU/IO/MEM/NETWORK

• 数据来源：
  （a）服务器端监控
  （b）数据库日志
  （c）用户提出需求

制定测试计划的实施时间和方案

预设本次性能测试各子模块的起止时间和结束时间
测试环境的配置：局域网，虚拟机，操纵系统，数据库，中间件
参与人员：谁负责哪些任务，测试策略。
产出：测试方案，分析结果