7.18

1、高级架构师

2、世界权威认证

3、自己开发10个左右的项目

性能测试八大类包括：性能测试、负载测试、压力测试、配置测试、并发测试、容量测试、可靠性测试、失败测试。

      性能测试：性能测试是为了描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试。它主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项指标进行测试。通常把性能测试、负载测试、压力测试等统称为性能测试。

    负载测试：是通过逐渐增加系统的负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能承受的最大负载量的测试。简而言之，负载测试时通过逐步加压的方式来确定系统的处理能力和能够承受的各项阈值。

    压力测试：是通过逐步增加系统的负载，测试系统性能的变化，并最终确定在什么负载条件下，系统性能处于失效状态，并获得系统能提供的最大服务级别的测试。压力测试是逐步增加负载，使系统某些资源达到饱和和甚至失效。

    配置测试：主要是通过对被测试软件的软硬件配置进行测试，找到系统各项资源的最优分配原则。配置测试能充分利用有限的软硬件资源，发挥系统的最佳处理能力，同时可以将其与其他性能测试类型联合应用，从而为系统提供重要依据。

    并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，几乎所有的性能测试都会涉及一些并发测试。

    容量测试：在一定的软、硬件条件下，在数据库中构造不同数量级的记录数量，通过运行一种或多种业务场景在一定虚拟用户数量的情况下，获取不同数量级别的性能指标，从而得到数据库能够处理的最大会话能力，最大容量等。系统可处理同时在线的最大用户数，通常和数据库有关。

    可靠性测试：通过给系统加载一定的业务压力（如CPU资源在70%~90%的使用率）的情况下，运行一段时间，检查系统是否稳定因为运行时间较长，通常可以测试出系统是否有内存泄漏等问题。

    失败测试：对于有冗余备份和负载均衡的系统，通过失败测试来检验如果系统局部发生故障，用户能否继续使用系统，用户受到多大的影响，如几台机器做均衡负载，一台或几台机器垮掉后系统能够承受的压力。

LR常用术语： 

场景-Controller中涉及与执行测试用例的用户场景。 
负载发生器-用来产生压力的真实机器，受Controller控制，可以使用户脚本在不同的主机上执行。在性能测试工作中，通常由一个Controller控制多个load generator对被测试系统进行加压。 
虚拟用户-对应于现实中的真实用户，使用LR模拟的用户称为虚拟用户。其本质是通过虚拟用户脚本来模拟真正用户的行为。 
虚拟用户脚本-录制的脚本，模拟真实用户的行为。 
事务-通过事务来衡量服务器的性能。测试人员可以将一个或多个操作步骤定义为一个事务，以便衡量这部分的用户并发响应时间。 
思考时间-为了在模拟时更加接近用户的真实行为而引进的概念。lr_think_time(double time)来模拟用户处理过程。 
集合点-对应于真实用户中的并发点。LR通过集合点实现了真正意义的并发。集合点在虚拟用户脚本中对应函数lr_rendezvous(const char* rendezvous_name),当执行到该函数会按照场景的并发策略来执行。 
事务响应时间-是一个统计量，是评价系统的重要参数。定义好事务后，在场景过程和测试结果分析中即可以看到对应事务的响应时间。通过对核心事务的执行情况进行分析，可以快速定位性能问题。 
 

                                                                       

                             

 

                                                       

loadrunner性能测试结果分析

通过Controller运行性能测试脚本，当运行完成后在result中打开analysis进行测试结果分析。主要分析一下几点内容：

1.      关注Transaction Summary模块

平均响应时间：当标准差std比较小的时候，选择事务平均响应时间。

90%响应时间：当标准差比较大时，可以考虑90%响应时间。

Std:标准差比较小，则相对比较平稳，标准差比较大时，浮动比较大。

分析事务响应时间，因为响应时间是最直观的指标，查看业务中哪个事务的响应时间有问题，然后接下来对该事务进行具体分析。

2.      根据Vusers中的用户负载生成图分析：如果较多用户未通过，说明脚本或场景设置有问题，如果只有一个或少部分虚拟用户运行正常则有可能是脚本出现问题。比如图中出现用户突然猛的下降等，则不必往后分析，需要修改脚本或者场景。

3.      分析错误统计图和每秒错误统计图

根据错误统计图有时候可以一次定位到问题，有时候只能猜测大概出现在哪个部位。

根据每秒错误统计图可以定位哪一段时间内出现错误比较多。

4.      分析事务：

1)     平均事务响应时间：查看哪个事务的平均响应时间响应比较对，对这些事务做标记，然后针对这些事务找出突破口，进行下一步分析。

2)     关注TPS:看成功的事务和失败的事务以及TPS的大小：成功的事务越多说明服务器的处理能力越强，失败的事务越小说明系统越可靠。TPS值越大说明服务器处理能力越好，如果值比较小，后期要进行调优。

5.      分析web resources（网络资源统计图）:

1)     首先分析一下Hits Per Second（每秒点击数）：每秒客户端向服务器发送的HTTP请求数，直接反应客户端侧的问题，如果该值比较低，从脚本和网络上分析问题。

2)     分析一下Connections（连接数）：当该值比较低的时候，要对连接数进行调优。当该值比较大，说明服务器连接池越大。

3)     分析一下每秒连接数：统计关闭的连接数和新建的连接数，方便了解每秒对服务器产生的连接数。当随着用户负载的增加连接数而终止，说明系统的连接池已满。需要修改服务器最大连接数的配置来解决问题。

6.      分析web page Diagnostics(网页分析)：

1)     看网页细分图，可以先从First Buffer Time的分解统计图入手，看是网络问题还是服务器问题。

2)     继续分析页面组件细分图：根据平均响应时间判断到底是网页上哪个文件或图片出现问题。

3)     根据页面下载时间分解图：可以看出每个资源加载的时间，根据平均时间再次判断哪些资源出现问题。

4)     根据下载组件的大小分解图：可以看出每个资源的大小，再根据大小判断资源内部是否有问题等。

7.      分析系统资源统计图（System resuorces）:

1)     查看系统资源的情况：关注CPU、IO、内存、队列等重要指标。

2)     如果CPU使用率很大，且PQL排队等待CPU的队列比较大，则说明本身服务器资源使用瓶颈烦的，硬件处理能力有待提高
8.     并发用户数、响应时间（358）、交易成功率（90,95,99，去除离散点）、TPS与HPS、资源利用率（20%，20%-60%，60%-80%，80%以上）

调优基本准则：

 如果某个部分不是瓶颈，就不要试图优化。
优化是为系统提供足够的资源并且充分的利用资源，而不是无节制的扩充资源。
优化有时候也意味着合理的分配或划分任务。
优化可能会过头，注意协调整个系统的性能。