性能测试术语及流程

性能测试术语及流程

1.性能测试的方法术语

1）负载测试（Load Testing）
通过对被测试系统不断地加压，直到超过预定的指标或部分资源已经达到了一种饱和状态不能再加压为止。

  策略：
		方法：
			在特定的环境下，不断地对系统进行加压，直到系统中部分资源达到极限
		目的：
			找出系统的最大负载能力

2）压力测试（Stress Testing）
	系统已经达到一定的饱和程度（如：CPU、磁盘等已经处于饱和状态）
	疲劳测试是其中一种表现形式

	策略：
		方法：
			使用模拟负载等方法，使系统资源达到一定较高的水平--系统稳定性
		目的;
			测试在系统已经达到一定的饱和程度时，系统最大处理业务能力

3)配置测试（Configuration Testing）
	通过调整系统软硬件环境，了解各个不同环境对系统性能的影响

	策略:
		方法:
			通过调整系统软硬件环境，使系统在不同环境下进行性能测试，系统调优和配置规划能力
		目的:
			通过调整环境了解不同因素对系统性能的影响情况，从而找到调优的方法。

4)并发测试（Concurrency Testing）
通过模拟用户并发访问，测试多用户同时访问同一个应用、模块或数据，观察系统是否存在死锁、系统处理速度是否明显下降等其他的性能问题。

	策略:
		方法:
			模拟多用户同时并发操作
		目的:
			当多用户并发访问时，系统是否存在一些可能的并发问题

5)基准测试（Benchmark Testing）
	在一定的软件、硬件及网络环境下，模拟一定数量虚拟用户运行一种或多种业务，将测试结果作为基线数据，在系统调优或系统评测过程中，通过运行相同的业务场景并比较，结果调优是否达到效果或为系统的选择提供决策数据

	策略:
		目的:
			度量改善性能测试的情况
			测试并调优，保证系统达到性能要求或服务协议要求

6)可靠性测试（Reliability Testing）
	在系统在一定的业务压力下，让系统持续运行一段时间，观察系统是否达到要求的稳定性（例如：系统能够持续无故障运行多少天）

	策略:
		方法:
			在一定业务压力测试下，关注系统业务运行情况
		目的:
			在一定业务压力测试下，系统可持续运行的时间

7）大数据量测试（Bigdata Testing）
	针对系统新建记录或统计查询等业务进行的大数据量测试，或针对大量存量数据而进行的性能测试

2.性能测试指标术语

1）思考时间（Think Time）
	用户在进行操作时，每个请求之间的时间间隔

2）响应时间RT
	响应时间，处理一次请求所需要的平均处理时间

	指应用系统从发出请求开始到客户端接收到所有请求所消耗的时间。

3）并发用户数
指同一时刻与服务器进行数据交互的所有用户数量

		-同一时间，用户同时对服务器进行施压
		-要与服务器进行数据交互

4）吞吐量throughPut
	--指在一次性能测试过程中网络上传输的数据量的总和，也就是在单次业务中，客户端与服务器端进行的数据交互总量--------对交互式应用来说，吞吐量指标反映服务器承受的压力，容量规划的测试中

	--计算公式

			N(vu)：vu（virtual user,虚拟用户）的个数
			R：在T时间内每个VU发出的请求字节数
			T：性能测试所用的时间

	注意：如果系统遇到性能瓶颈，就不适用了。------------吞吐量在UV增长到一定数量时，软件系统出现性能瓶颈，此时吞吐量的值可能趋于平衡或者下降

–吞吐量与负载的关系

5）吞吐率
–吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量

	--单位时间内服务器处理的字节数，吞吐量的单位：B/s  -字节数/秒”

6）资源利用率
	-服务器系统中不同硬件资源被使用的程度、资源使用率=资源实际使用量/总的可用资源量
		1.CPU利用率
		2.内存利用率
		3.磁盘利用率
		4.网络
7）Scenario
	用户场景或测试场景，通常测试设计时，进行负载建模

8）TPS|QPS
	--系统每秒能处理的请求/事务的数量，或者认为是吞吐量

	--在web应用我们更关注的是web应用每秒能处理的request数量

	--QPS的统计可以通过访问日志统计对应时间的PV量除以对应时间求得  --计算公式：QPS（TPS）= 并发数/平均响应时间

9）点击率（HIt Per Second）
	每秒用户向Web服务器提交的Http请求数。

10）PV（Page View）
	用户通过浏览器访问页面，对应用服务器产生的每一次请求

3.性能测试流程
1、设计
收集要求
参与角色
性能测试团队
业务领域的经理
系统管理员|数据库管理员（DBA）
关注问题
业务需求
应用程序情况
创建系统使用演示，让性能测试团队从整体上了解应用程序如何被使用
交易列表
汇编业务流程中需要负载测量（如：登录 或 转移资金等）的关键活动列表
业务流程列表
创建关键业务流程列表，以使用反映最终用户在系统上执行的活动
创建Word文档，以详细记录每个业务流程的正确步骤
创建业务流程图，描述业务流程分支
技术需求
环境预排工作
与系统或基础设置团队开展测试架构的预排工作
系统范围会议
举行会议来讨论系统的哪些部分应该排除在测试流程外，并达成一致见解
生产图–性能调优
创建生产基础设备的图表，以标记出从QA迁移到生成过程中可能影响性能的因素
系统需求
系统在正常和高峰期必须支持的用户数量为多少
系统每秒必须处理的交易量是多少？
对于所有的关键业务交易，可接受的范围（300ms–600ms）的响应时间
团队要求
确定性能测试团队成员。提前收集完整业务、技术、系统和团队要求，是有效和成功地进行负载测试的基础
设计测试策略
定义业务流程
定义系统工作量

2、构建
	设置测试环境
		自动化设置
			制作脚本
				将存档的业务流程记录到自动化脚本中
			交易
				插入计时器来产生业务所需要的逻辑计时
			参数化
				用数据池来代替所有的输入数据（如登录用户名和密码），以便每个虚拟用户使用唯一的数据访问应用程序
			断言--错误率+响应时间
			方案
				通过为不同的用户组分配不同的脚本、连接和用户行为来创建生成工作量
			监控
				确定要监控哪些负载服务器或机器
		环境设置
			组装硬件、软件和数据
			准备数据：历史数据和创建数据
	记录测试脚本
	创建测试方案
	
3、执行
	基线测试
		系统的操作响应时间超出了用户可接受的程度
		角色参与
			系统架构师或技术负责人
				依照系统性能需求，参照性能基线测算计算资源需求
			性能调优人员
				为性能调优建立目标，只有系统性能表现满足基线指标值，方可完成性能调优工作
			性能测试人员
				了解性能基线指标值，能够在测试环境中计算资源不充足的情况下，也对系统的性能表现进行测试并把关，明确系统性能是否达到基线要求，性能测试是否可以通过
		性能基线指标选择
			QPS：每秒请求处理量(Query Per Second)
				对一个特定的应用系统在规定时间内所处理流量多少的衡量标准
			硬件资源
				硬盘、CPU、内存、网络
		场景案例=设计
			QPS指标测试
				场景一、读数据场景 
					脚本描述
						访问用户登录页，输入账户密码后，等待加载首页完，在个人消息中心里进行搜索(搜索条件为空) ，脚本中账户密码参数化500个账号。实际包含对一张数据量100万级别的数据表进行2次数据库查询操作
					压测场景
						没有集合点和思考时间，模拟缓存压测，500并发
				场景二、写数据场景 
					脚本描述
						访问用户登录页，输入账户密码后，等待加载首页完，打开定制的压测页面，新增数据，脚本中账户密码参数化500个账号。实际包含一次百万级数据查询和一次删除、两次插入的数据库操作。 
					压测场景
						没有集合点和思考时间，模拟缓存压测，500并发
			硬软件指标测试
				内网环境，千兆带宽 
				软硬件配置
					4台web服务器：Linux系统，4核8G，web应用基于Ecloud容器部署 

Mysql服务器：Linux系统，8核32G，磁盘IOPS限制在5000
测试-常见发现与结论
基础结论
单纯的读数据场景下，每增加一台4核8G服务器，系统QPS值提升1000左右
单纯的写数据场景下，每增加一台4核8G服务器，系统QPS值提升650左右
推论
框架系统部署提供硬件资源，每一个CPU核，可支撑系统性能表现QPS值在160~250之间，如果实际压测时，依照投入的资源情况，评测出系统性能表现低于此区间的，则认为性能达不到基线标准，需要进行系统调优
基准测试
QPS
配置测试
性能测试
压力测试、负载测试
资源利用率
响应时间RT
并发用户数
吞吐量throughPut
报告生成

4、分析/诊断/调整

	诊断瓶颈
	调整配置
	量化改善
总结
	1、设计阶段
		定义待测试的业务流程、业务的平均处理量、业务处理量的最高峰值、组合业务流程、系统的整体用户和响应时间目标
	2、构建阶段
		涉及设置和配置测试系统及基础设施、使用自动化测试解决方法构建测试脚本和负载方案
	3、执行阶段
		包括运行负载方案和测试系统性能
	4、分析、诊断和调节阶段
		测量系统性能并使负载测试进行下一级别，重点查找问题的原因以帮助开发工程师迅速解决问题，并实时调节系统参数以提高性能