性能测试一般流程

根据本人的web接口性能测试的项目经验，对测试流程进行了大致划分，以供诸位同志参考，如有错误，可与我讨论，转载请注明出处。

一、测试准备

1.前置准备

	(1)业务逻辑（需求文档）；
	
	(2)数据流转，若通过接口测试，还需了解接口规则（设计文档）；
	
	(3)服务架构，服务运行时所用到的应用服务器、数据库服务器及其他服务（本地与第三方），包括测试环境架构与生产环境架构。

2.环境准备
环境准备主要立足在以下两点已确定的情况下：

	(1)测试工具已确定（jmeter或loadrunner）
	
	(2)测试模式已确定，分为场景脚本录制或编写（jmeter或loadrunner）或者直接编写接口脚本（jmeter）。

场景形式的压测保证了测试过程中业务的连贯性以及场景覆盖的全面性，劣势体现在：

	1.编写或录制脚本需要更多的工作量，主要体现在请求筛选
	
	2.录制完成之后仍需对脚本的变量参数进行优化
	
	3.不便于单业务场景拆分测试

接口形式的压测优势体现在编写脚本时较为节约时间，能够较为准确的定位出具体接口存在的问题，但也具有一些缺点：

	1.场景覆盖时只覆盖到主接口，可能会遗漏一些非必要但实际使用时会用到的接口。
	
	2.涉及到复杂业务场景，需要测试人员去进行接口组合。
	
	3.需要前期花费时间去熟悉接口规则。

关于环境的准备如下：

	(1)安装测试工具（jmeter与loadrunner），安装测试过程中会使用到的插件。
	
	(2)获取服务提供方，应用后台权限。（注意非服务调用方）
	
	(3)获取数据库部署设备的linux后台权限。（不区分调用方与提供方，只关注数据库是否被使用）
	
	(4)在获取的应用服务设备与数据库设备中安装资源监控工具。（一般为NMON）
	
	(5)生产环境业务量（根据实际情况获取时间区间）

二、测试分析

1.测试环境架构分析

	简单来说，就是根据测试环境与生产环境两者设备的比例，来确定测试环境的承载力。

2.业务量分析

	根据获取的生产环境业务量与需求所需达到的标准，对需求体现出的负载量进行计算，
	
	根据前置准备时获取的架构比例，计算出测试环境所要达到的需求负载量（TPS）。

3.场景分析

	根据需求文档与已设计完成的系统，来分析测试过程中所需覆盖到的测试点（业务场景）
	
	根据实际情况计算出，如需进行混合场景测试时，各场景的业务占比。

4.场景设计

	根据已知信息进行场景设计，设计主体根据压力情况分为：基准测试、配置测试、压力测试、稳定性测试。
	
	根据测试方式分为：单接口测试与混合场景测试。

三、编写脚本

这部分可能比较乱，大家方便什么时候写就什么时候写就好

录制或者手动编写测试脚本
以下只针对于jmeter脚本，loadrunner手工编写需要C或Java基础，建议直接录制。
录制编写（场景形式）：

	1.通过jmeter自带http代理或badbody进行录制，推荐此两种录制方法，前者较为便利，后者较为直观。
	
	2.录制完成后进行请求筛选，推荐先使用fidder工具，对业务请求进行抓包，根据请求信息判断筛选接口。
	
	3.对筛序完成后的脚本进行参数化。
	
	4.为每个请求添加断言，便于定位问题。

手动编写：

	手动编写分为两种，一种是已知接口编写，另一种是场景接口编写。
	
	已知接口脚本编写较为简单，直接根据接口文档，编写脚本。（接口形式）

场景接口脚本编写，需要先进行业务场景模拟，使用fidder进行抓包，筛选请求后，进行手动编写。（场景形式）

四、测试执行

1.基准测试

	脚本编写完成后，先单用户运行一次，确认脚本无误。再2-3用户执行一次，确认参数化信息无误。

2.并发测试

	根据分析所得信息，进行单接口并发或混合场景并发

执行时需要注意以下事项：

	(1)需打开应用后台日志，实时查看是否存在报错信息，因为存在一些报错，断言无法体现出。
必要时对日志文件进行cut，找出具体报错。
	
	(2)保证应用服务与数据库服务的资源监控已运行（nmon）。
	
	(3)测试过程中如察觉到异常，可以使用top命令查看服务资源，方便定位问题（必要时打开两个后台）。
	
	(4)每次并发执行时，尽量保证能对服务做一次重启操作，使得测试数据更加真实。--
	
	(5)每次并发执行时，清除nohup.out日志，避免测试过程中日志占满硬盘。
	
	(6) 每次并发执行时,若存在redis缓存服务，应清除缓存，避免历史缓存存在对测试结果的影响。

3.梯度加压测试

	属于并发测试的一种，不过能更加贴切的看出来系统性能变化的曲线

五、问题复现及定位

测试过程中遇到问题后，如后台报错、响应时间过长等，我们可以对问题进行复现及定位，可参考以下步骤：

	(1)明确出现问题的接口，可利用jmeter断言，后台日志报错来定位。
	
	(2)使用测试时遇到问题的配置（线程数、持续时间、迭代此时等）重新执行一次或多次，记录问题，
若无法复现问题，可先对问题进行记录。
	
	(3)问题复现后，记录后台日志，入参信息，及数据库数据，若无法自己定位，可交给开发解决。
	
	(4)开发定位完成后，记录问题原因（需要在报告中体现）。
	
	(5)问题解决后，参照历史并发量、入参信息、数据库数据，重新执行一次。
	
	(6)若问题未解决，则重新与开发沟通。
	
	(7)若问题已解决，可参考历史数据，验证与问题接口类似的接口是否也存在此问题。

六、数据分析

计划场景测试完成后，需要对所得数据进行分析，分析数据时，要注意以下几点：

	(1)数据对应，在测试过程中除了jmeter报告，可能还需要对服务资源监控，数据库资源监控、redis服务监控、
drools-web服务等进行监控，所以，整理数据时，一定要保证各种类数据都要一一对应，这是分析的前提。
	
	(2)信息归纳，分析信息前，可以对所有信息进行分类汇总，选取标志性信息，归纳进excel表格中，
这样可以更清楚明了的看出一个接口各并发量的差异。

常见问题分析思路:
1.曲线分析

    利用加压过程中响应曲线（响应时间、tps等）与资源消耗曲线（数据库与应用服务cpu、内存等）进行对照，
寻找性能变化拐点，利用曲线可以清晰的看出是因为某方面的资源消耗使得响应曲线出现拐点，之后再去关注拐点附近的性能表现。

2.纵向数据分析

	根据测试方案设计的并发量，首先统计各并发量阶段的综合数据，其次根据统计的数据情况，计算业务每个区间指标的跨度，
以混合场景测试的响应时间为例，若跨度按并发量表现为100ms、300ms、700ms、1500ms、2530ms，此时应关注500ms-700ms区间，
场景内各接口的表现情况，此时并发量均衡增加但响应时间未按照合理比例上升，可以去查看此区间各系统的资源消耗情况，
可以较为容易的定位问题。

3.硬件分析

	1.应用出现缺陷与瓶颈时，首先应考虑负载及的硬件资源是否达到上限，并发时检查内存与cpu是否达到负载上限，
排除因为负载机的原因而产生伪性能问题的状况。
	2.其次，查看网络情况，测试带宽是否处于正常水平。、
	3.之后才需考虑应用服务器，数据库以及sql等原因。

4.sql分析与定位

	在某一接口响应过慢或频繁报错的情况下，我们测试人员可以帮助开发人员定位问题，如sql问题
	定位时需要一定的操作linux系统的经验，一般情况下，接口的入参与出参都会在后台日志中体现，先对接口进行定位，
定位完成后在日志中查找可参考linux操作文档进行定位。

5.配置类问题

	当问题显现后，除了因为应用代码缺陷而产生性能问题之外，配置问题也是我们需要关注的问题:
	如数据库连接数是否足够，swap内存分配是否合理，应用内存分配是否合理等。

有些地方可能写的有些欠缺考虑，有些地方缺少了一些长篇大论，但是加上的话有些繁琐，后面再一一解释，这个只能作为一个web接口性能测试一般流程的参考。如有大佬指点，感激不尽。