测试-------性能测试（一）

性能测试的基本问题

1.WHY： 为什么要进行性能测试

1. 要保证应用程序的响应时间在客户的接受范围内 。比如：测试网站的响应时间应该在3~5秒内，“2,8原则，两秒最好，超过8秒就不可以”
2. 要保证应用程序能处理用户要求，并且有盈余能力。比如：一辆公交车，他有固定的座位，当座位坐满了，当们都关不上时，就到了他的最大的承载人数，也就是盈余能力。此时多一个都不可以，应为车门已经关不上了。
3. 要保证应用程序是能处理业务所需要的事务数量。比如：坐公交车的人数，正常人数45，最多乘坐人数75，那么他的处理事务能力就是75，超过了的一个都不能处理。
4. 要保证在预期和非预期的用户负载下，应用程序是否稳定。比如：正常情况和非正常情况下的负载问题，公交车在乘坐人数内启动等操作很快，但是超负荷的情况下吗，速度就会变慢。
5. 是否能确保用户在真正使用软件时获得舒服的体验。比如：坐车时的感受，会不会晕车，有味道等。

1和5都是从响应时间来看的，用户角度
2，3，4是从响应时间来看得，系统角度。业务量很大时重点关注

根源问题：

• 在多种平台上的数百个服务器。对于企业服务器会很贵，而且服务器的运行内存都是有限的，在很高的并发量下，系统还是承受不住。
• 异构系统、多种应用。系统它是不同的架构的。
• 数千个工作站。对于/S模式，客户端访问访问服务器，对于B/S来说就是浏览器直接给服务器发请求访问服务器。双十一时，明显会感觉到响应速度变慢
• 局域网、广域网和其他分类型的分布式网络体系结构 。
• 交错的故障点。在异构系统里面，一个Bug会影响系统的很多功能无法运行。他和bug的种类有关系

2.WHAT: 关注的性能测试内容

1. 并发用户数/吞吐量
2. 平均响应时间
3. 服务器资源占用情况
4. 可靠性、可扩展性
5. 发现引起系统问题的原因,关注采用何种技术提高系统性能
6. 软、硬件配置是否合适（容量规划/硬件选

3.WHO: 哪些人员关注性能

• 开发人员：
  1）系统架构：架构设计是否合理?
  2）数据库设计：数据库设计是否存在问题?
  3） 代码：代码是否存在性能问题?系统中是否存在不合理的内存使用方式?
  4） 设计和代码：系统中是否存在不合理的线程同步方式和不合理的资源竞争?

• 系统管理人员（操作系统、网络、服务器等
  1）资源利用率：应用服务器和数据库资源使用状况合理吗?
  2）系统容量：系统最多能支持多少用户的访问?系统最大的业务处理量是多少?
  3）系统稳定性：系统是否能支持7X24小时的业务访问?
  4）系统可扩展性：系统是否能够实现扩展?系统性能可能的瓶颈在哪里?更换哪些设备能够提高系统性能?

• 用户
  响应时间：过长时间的等待会让使用者烦躁不安；
  对于一般的web网站来说,在欧美国家普遍的标准为原则3/5/8(2/5/10)：

  • 3: 3秒钟用户会觉得是一个很好的体验.
  • 5: 5秒钟用户可能会觉得差了一点,还行,比较好.
  • 8: 8秒钟是用户所能承受的最大极限 系统稳定性：
    出现HTTP500错误或数据库崩溃会让用户对系统失去信心

• 业务人员
  参数：如何向用户提供参数，例如支持多少用户使用？响应时间是多少？

• 测试人员
  不仅要注意上面的问题，还要发现系统存在的性能瓶颈，而且还要具有真实评估系统性能的能力。

4.WHERE: 性能测试的关注领域

• 能力验证（被动）
  性能测试中最简单也是最常用的一个应用领域，主要关心的是“在给定的条件下，系统能否具有预期的表现”。是否达到用户的要求。
• 规划能力（主动）
  规划能力领域与能力验证领域有些不同,其主要关心的是“应该如何才能使系统具有我们要求的性能能力”或 是“在某种可能发生的条件下,系统具有如何的性能能力
• 性能调优（从不同的角度调）
  主要应用于对系统性能进行调优。一般来说，性能调优活动会和其他领域的活动交杂在一起。是一种在开发阶段和测试阶段都可能会涉及到的性能测试应用领域
• 发现缺陷
  主要该应用领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷

注意
误区：
1、性能测试独立于功能测试是错的：因为性能测试的前期要求是功能要稳定，这样才可以进行性能测试。
2、性能测试就是并发用户测试错的：并发用户测试是性能测试的一部分，是被包含的关系。
3、在开发环境测试一下性能就行错的：因为开发环境和测试环境的差异是很大的，所以开发环境下的性能测试是不具有参考性的。而且在测试报告中会对受限性，局限性，测试的网络，版本环境进行说明，表示在这个环境下测出来的结果是这个结果。

5.WHEN: 何时进行性能测试

• 能测试中后期，即功能测试稳定之后进行测试。
  注意
  误区：性能测试在其他测试完成后，测试一下就可以了，错的。
  性能测试：用的时间也是很久的，他也要有性能测试的方案，性能测试的用例，还有输出性能测试的测试报告，发现瓶颈还有进行调优，而且性能是一个产品的重要因素，并不是一下就可以的。

性能测试概念

1. 性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

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

• 性能测试作用：
  主要用来保证产品上线或发布后系统的性能满足用户需求,性能测试在软件质量保证中起重要作用

2. 系统的性能：是对一个软件系统而言包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。

指标说明：

并发数

• 系统用户数：
  就是该系统的注册用户数，也就是保存在数据库里面的用户数目。例如，一个论坛里存在1000个注册用户，他们可以是活跃的，也可以是僵尸的。

• 在线用户数：
  登录系统的用户。例如，其中有666个用户的状态为在线，但在线用户并不一定都会对服务器产生压力，因为有的用户登录后什么都不干。

• 并发用户数：
  同时有多个用户点击同一个功能，对服务器产生压力的用户。例如，可能在线的1000个用户中，假设有20%的人同时点击提交按钮，也就是只有20%的用户对服务器产生了压力，这20%的用户数就是并发用户数。严格意义的并发用户数：同一时间进行同一个操作的用户数。

并发数的计算公式

1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C' = C + 3*根号C
C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
C'是并发用户数峰值

举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一
个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系
统。那么：
平均并发用户数为：C = 400*4/8 = 200
并发用户数峰值为：C' = 200 + 3*根号200 = 243

响应时间（Reponse Time）

又叫请求响应时间：TTLB（time to last byte）

对请求作出响应所需要的时间=网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间

事务响应时间（Transaction Reponse Time）

事务是指一组密切相关的操作组合，所以事物响应时间就是这一系列操作完成之后的时间之和。例如一次登录可能包含了多次HTTP请求，它是根据http请求来取反事务的。

如：判断用户是否存在？密码是否正确？是否已登录？登录？锁定登录？注销登录？等多个HTTP请求。
如果把注册，登录，退出三个功能放在一起，也是一个务。

该数值对用户的意义更直观

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

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

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

举例：坐地铁
进站检票机器有5个，一个机器每次次只能进一个人
并发用户：2人，则TPS为2
并发用户为：5，则TPS为5
并发用户为：100，则TPS为5

点击率（Hit Per Second）

每秒点击数代表用户每秒向Web 服务器提交的HTTP请求数。点击率越大，服务器压力越大。
这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。

一次登录请求：判断用户是否存在？密码是否正确？是否已登录？登录？等多个HTTP请求，
如果多次点击就会：有点击次数*一次点击的HTTP请求数。点击三次，一次点击5个HTTP请求，则会有15个HTTP请求，即点击率为15

吞吐量（Throughput）

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

它的时间是不确定的

• 一般来说用 **请求数/秒 ** 或是 页面数/秒 来衡量，
• 从业务的角度，也可以用 访问人数/天 或是 处理的业务数/小时 来衡量，
• 从网络的角度来说，也可以用字节数/天来衡量。

思考时间（Think Time）

思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。

比如：登录时，输入了账号，但是在输入密码时想了一下密码是什么么，这个时间是就是思考时间

资源利用率

不同系统资源的使用情况。CPU,Memory，磁盘，网络。
在Linux里面可以使用free 和 投票命令来查看资源的使用情况

性能测试模型

曲线拐点模型（发现问题）

1. X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。

2. 然后分析，随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。

3. 接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点承受不住的感觉。

4. 随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。

分析：

轻压力区：随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；

重压力区：但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，响应时间有上升趋势。而重压力区与拐点区的交界点就是系统的最大并发用户数，

拐点区：进入拐点区后吞吐量急剧下降，造成响应时间慢慢变长。因为超过这个点，响应时间慢慢变长，吞吐量会达到极限，资源利用率不会有变化了，因为已经到达饱和状态。如果长时间在拐点区，系统性能将会急剧下降甚至崩溃。

测试类型：在最大并发用户数之前进行的是负载测试，各项指标达到饱和，在并发用户数之后的是压力测试，。

总结
1.用户的并发数在最佳并发数和最大并发数的之间增长的时候，吞吐量，资源利用率正常增长是没有问题的，当用户并发数目增长到一定的数目之后吞吐量和资源利用率就不会再增长了，它会保持一个平稳的水平。在系统的接受范围之内，还会吞吐量会缓慢增长，
2.超过最大用户的并发数之后，就会出现拐点，响应时间变长，吞吐量下降，说明性能出问题了
3.要判断性能是否出现问题，一个独立的指标是判断不出来的，需要结合多个指标结合起来看。比如：并发用户数，吞吐量，资源利用率

地铁模型（解决问题的思路）

假设：
某地铁站进站只有3个刷卡机。
人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。
乘客耐心有限，如果等待超过30min，就暴躁、唠叨，甚至放弃。

场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。

场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。

场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。

场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队。那么，A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。

场景五：假设这次进站一次来了9名乘客，有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s），还有3名的“响应时间”为3s（等待2s+进站1s）。

场景六：如果地铁正好在火车站，每名乘客都拿着大小不同的包，包太大导致卡在刷卡机堵塞，每名乘客的进站时间就会又不一样。刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽）。

场景七：进站的乘客越来越多，3台刷卡机已经无法满足需求，为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。

场景八（核心）：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用服务器、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

总结
1.性能出现问题之后，不能靠单一的方法来解决问题。要有多种方法结合起来解决问题。

性能测试分类介绍

基准测试，性能测试，负载测试，压力测试，并发测试，配置测试，可靠性测试，失效恢复测试，大数据量

基准测试

有基础的标准，这样能通过对比可以发现系统的不同点与变化。这样有了一个标准才可以对比系统是低于标准，还是优于标准，如果低于标准就要进行调优。标准定义必须要合适。定低了达不到业务系统的要求，定高了有达不到要求。

比如：定义CPU的使用率，IO的读写，磁盘的占用率，超过标准会怎样，低于会怎样

应用于以下场景：

1. 可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。
2. 系统进行基准测试可以在较早的阶段发现性能问题。
3. .某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考

狭义性能测试（Performance Testing）

是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能能否满足生产系统要求。

Performance Testing是一种常见的测试方法，就是在特定的运行条件下验证系统的能力情况。该测试是一种正常的测试，主要是测试系统正常使用时是否满足要求

广义的性能测试：

负载测试（Load Testing）（系统调优）

负载测试是在被测系统上不断增加压力，直到各项指标达到饱和，
例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。

目的：找到最佳用户的并发量，和最大并发用户量

这种测试方法可以找到系统的处理极限，为系统调优提供数据。

压力测试（StressTesting）（发现问题）

压力测试是测试系统在一定饱和状态下，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及统能否会出现错误。压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景-例如增加用户数
对系统进行压力测试。

压力测试的目的：是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄漏等

压力测试是在负载测试的基础上进行的。负载测试和压力测试两者可以结合进行。
区别：

• 负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。找到系统处理的最大极限，进行系统调优做参考。
• **压力测试：**是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。找系统的bug，内存泄漏，资源竞争等。

并发测试（Concurrency Testing）

并发测试是通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者功能，数据记录时是否存在死锁或者其他性能问题

并发数计算方法1：
并发数=PV / PV Time× 页面连接次数×HTTP 响应时间× 因数/ Web 服务器数量。

• PV Time 是PV 的统计时间，换算成秒，一天是86 400s。
• 页面连接次数包括外部的JS、CSS、图片等，一般为10。 HTTP
• 响应时间一般可为1s 或更少。因数一般为5。
  假设，网易官网每天有6 万PV，其余参数保持默认，那么推算出来的并发数大致为35。(pv—page view，即页面浏览量）
  并发数：60000/86400105=35

总结：

性能测试，平时说的性能测试是呀以上的性能测试，真正的性能测试是看系统的各项指标能否不达到用户的需求。

负载测试：验证系统处理各项各项指标的极限，资源最大利用率，最大吞吐量，最大并发用户数等，目的是发现性能瓶颈进行性能调优。

压力测试是在负载测试的基础上进一步进行加压测试，目的是发现系统发现性能问题，是否有内存泄漏，资源竞争等问题。

并发测试：就是多个用户对某个功能同一个时刻进行测试

配置测试（ConfigurationTesting）

配置测试方法是通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资
源的最优分配原则。可以对性能进行调优。

例如，在测试执行时更换、扩充硬件设备，调整网络环境、调整应用服务器和数据库服务器的参数设置，比较每次测试结果，从而确定各个因素对系统性能的影响。

举例：Linux下的Tomcat，内存大小512，最大的连接数，最大并发数256 ，这些都可以进行调整

可靠性测试（Reliability Testing）

可靠性测试的前提条件是前提条件是系统是稳定的，它是通过给系统加载一定的业务压力 (例如资源在70%-90%的使用率) 的情况下,让应用系统持续运行 一段时间,测试系统在这种条件下是否能够稳定运行，前提条件是系统是稳定的。

7*24：一周不间断的进行测试。工具要一直对代码进行测试，给服务器施加压力。

失效恢复测试(Failover Testing)

1.失效恢复测试方法是针对有备份和负载均衡的系统设计的（前提条件）,这种测试方法可以用来检验如果系统局部发生故障, 用户能否继续使用系统,以及如果这种情况发生,用户将受到多大程度的影响.

2.一般的关键业务系统都会采用热备份或是负载均衡的方式来实现.这种业务系统一般要求有一台或几台服务器出 现问题,应用系统仍然可以正常执行业务.该方法就是在测试中模拟设备故障,验证预期的恢复技术是否可以正常 发挥作用

3.不是所有的系统都需要进行这种类型的测试,尤其是并没有明确给出系统需要持续运行指标的系统

大数据量测试

大数据量测试的两种类型：

1.独立的数据量测试
针对某些系统存储、传输、统计、查询等业务进行大数据量测试

2.综合数据量测试
和压力测试、负载测试、并发测试、可靠性测试相结合的综合测试方案

这些测试类型其实是密切相关，甚至无法区别，例如几乎所有的测试都有并发测试。在实际中不用纠结具体的概念。而是要明确测试的

性能测试实施与管理

性能测试前期准备

1. 系统基础功能验证

• 确保当前需要进行测试的应用系统具备了进行性能测试的条件 ，即功能测试是稳定的。
• 确保当前进行性能测试的应用系统版本已经稳定；
• 必须保证性能测试之前至少进行了一轮的系统功能覆盖测试，且性能测试选取的业务功能正常。

2. 组建测试团队
确定团队内角色的构成，以及确定人员的技能。
比如：需要几个测试人员，测试人员的技能的中高低。

测试经理：

• 职责：
  * 和用户等项目干系人交互，确保测试的外部环境
  * 定测试计划
  * 监控测试进度
  * 发现和处理测试中的

*技能：
* 计划执行和监控能力
* 风险意识和能力
* 外交能力和灵活变通的能力

专职的网络管理员
网络方面的支持，协助测试工程师解决网络方面的问题，在必要时为测试分析角色提供网络方面的分析支持

专职的DBA
数据库方面的支持，在必要时为测试分析角色提供数据库方面的支持

性能测试工程师
测试数据的准备

3.测试工具需求确认

根据被测系统的了解，评估性能测试工具所应具备的功能

被测系统环境	测试工具功能需求建议
操作系统环境	测试工具是否能运行在本操作系统 上
测试工具是否能支持对本操作系统的监控
应用服务器环境	测试工具能否支持对本应用服务器的监控
据库环境	测试工具能否支持本数据库的监控
应用使用的协议	测试工具能否支持需要进行录制和产生负载的协议
网络环境	是否需要测试工具支持防火墙
是否需要测试工具支持负载均衡
测试管理支持	测试工具是否能够提供方便的测试结果分析和管理

测试工具引入

工具选择
选择适合项目的性能测试工具，商业工具或者是自行开发的工具，Loadrunner，jmeter
工具应用技能培训
为项目组的相关参与者进行测试工具的应用技能培训，以使参与者能够具备测试需要的技能。
确定工具应用过程
确定测试工具在测试中的具体应用范围，并不是“工具无所不能”，哪些工作使用工具完成，哪些无法使用工具完成

性能测试方案

1. 调研测试需求

** 测试业务范围**
关键的、常用的、压力较大的、有代表性的、不宜过多

** 测试环境**
硬件环境：主机型号、配置…
软件环境：操作系统、数据库…
网络环境：带宽？交换机？防火墙？

测试目的：
上线前性能测试？对比性能测试？调优？查找缺陷

性能指标

• 业务性能指标：
  一般步骤是首先从需求和设计中分析出性能测试需求，性能测试需求的来源是多方面的， 需求文档（非功能需求的描述）、设计文档、 客户备忘录、历史经验的积累等等

• 系统性能指标：
  cpu使用率 、内存使用率，IO的读写，
  注：实际测试时，需要监控许多其他的性能指标：数据库、服务器系统、网络，用于定位问题

2、测试策略和测试资源需求

测试工具、测试方式、测试执行
人力资源：明确所需的人员类型（性能测试负责人、性能测试工程师、应用工程师、系统工程师、数据库工程师、
网络工程师）、由何方提供、明确职责分工
硬件资源：明确测试时所需的硬件资源(测试工具要求机器的内存，磁盘空间)

3、性能测试计划

主要内容：性能测试的方案的编写，测试环境的准备，脚本的开发和测试数据的准备，测试的执行，测试报告的输出。

它根据性能测试的测试用例进行测试，根据测试场景进行测试，监控性能指标，测试完成之后生成一个测试报告，然后根据测试结果看看有没有性能的缺陷，如果有就要进行性能调优。然后写性能调优的方案。

性能测试和功能测试的区别：
性能测试：不仅仅要性能缺陷，还要给出解决放方案
功能测试：如果发现问题，由开发人员进行修改

测试设计与开发

1.测试环境设计

性能测试的结果与测试环境之间的关联性非常大，无论那种性能测试，都必须首先确定测试的环境，包括系统的
软/硬件环境、数据库环境等等（50万条数据和空数据库执行操作的时间显然是不同的）

设计的环境要与生产环境的要保持基本的一致，如果达不到就可以进行换算估计一下。

2.测试场景设计（测试用例）

测试场景模拟的一般是实际业务进行的一个剖面，其包括业务、业务比例、测试指标的目标、测试过程中需要监控。

对于并发用户数，如果最佳并发数为200，在喀什进行测试的时候不能直接测试200，可以向测试50,100,150来看看在能否达到最佳用户数，如果能达到最佳用户数，然后继续增加用户就那些测试得出他的拐点即最大用户并发数。同时在测试的时候，必须要对测试结果进行记录。

3.脚本开发

脚本开发的过程：先进性脚本的录制，再根据业务场景进行脚本的增强或者修改，然后要保证修改后的脚本可以运行通过，

对测试场景进一步细化，一般包括测试类型、测试内容描述、前置条件、业务操作序列、参数化需求、验证点等

4.脚本和辅助工具开发

一款工具不能完全满足我们的需求的时候，我们可以自己写或找开发人员或者数据库人员的协助开发一个小工具

测试脚本是对业务操作的体现，一个脚本一般就是一个业务过程的描述，脚本的开发通常都基于“录制”，然后对脚
本进行完善，以满足在性能测试中顺利使用。
辅助工具开发一般基于性能工具无法满足，或者是获取特定资源需要使用。

性能测试执行与管理（核心）

1.建立测试环境

搭建需要的性能测试环境，需要多个团队角色的参与，包括硬件、软件系统环境的搭建、数据库环境建立、应用系统的部署、系统设置参数的调整、以及数据库环境准备

2.部署测试脚本和测试场景

脚本和测试场景的部署最终需要保证场景与设计的一致性，保证需要监控的计数器都已经部署好了相应的监控手
段。然后将脚本部署到服务器上，在对场景进行测测试。

3.执行测试和记录结果

可以依靠工具完成，对于工具不支持的，可以采用系统自带工具或自行开发工具解决。
测试结果是最后分析的基础，因为根据测试的数据和测试的结果才可以分析，看看项目到底有没有性能缺陷。

测试分析与调优

测试结果分析是最难的部分。是一个灵活的过程，每次性能测试结果的分析都需要测试分析人员具有相当程度的对软件性能、软件架构和各种性能测试指标的了解，性能测试分析需要借助各种图表。

方法：之一就是**“拐点分析**的”方法。关注性能表现上的“拐点”，获得“拐点”附近使用情况，定位处系统的性能瓶颈

根据测试数据以及测试结果，对项目进行修改，如果修改之后再次进行的测试。如果显示性能比之前提升了就表示调优起作用了。如果调优不起作用，或者性能还要不如之前，就表示调优没有起作用。

如何判断调优有没有起作用：可以与基准测试进行对比。先给出一个标准。

测试报告

测试目标
指标要求:本次测试预期达到的性能要求。 (TPS,ART，交易成功率，并发数等）
测试概要描述
系统结构
测试时间
测试地点和测试人员
工具和环境
测试过程简介

测试结果和数据（核心）

测试结论（核心）

• 测试通过，不通过
• 测试遗留问题
• 建议
• 测试结论限制：需要它原因是因为，环境里的不同的硬件配置，测试结果是完全不一样的。测试时搭建的性能测试服务器只是模拟接近线上的生产环境，但是它与实际的生成环境还是有区别的。结论仅仅限于内存是多少，硬件是多少，与生产环境是有差别的。