性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
中国软件评测中心将性能测试概括为三个方面：应用在客户端上性能的测试、应用在网络上性能的测试和应用在服务器端上性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
定义
狭义的性能测试主要用于描述常规的性能测试，是指通过模拟生产运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。
广义的性能测试则是压力测试、负载测试、强度测试、并发（用户）测试、大数据量测试、配置测试、可靠性测试等和性能相关的测试统称。
基本策略
测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力，就为最终用户规划整个运行环境的配置提供了有力的依据。
目的
目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，以优化软件，最后起到优化系统的目的。
包括以下几个方面：
1．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
2．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
3．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
4. 检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
5．验证稳定性（resilience）、可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
类型
性能测试类型包括：负载测试、压力测试、并发测试、配置测试、基准测试、验收测试、可靠性测试、失效恢复测试、容量测试，稳定性测试等。
负载测试（Load Testing）
定义
负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。
负载测试是不断增加系统的负载，直到负载达到阈值——评估系统在预期工作负载下的性能的测试。这里增加负载的意思是在测试中增加并发用户数量、用户交互等，通常是在可控的环境下进行。典型的负载测试包括在负载测试过程中确定响应时间，吞吐量，误码率等。该方法可以找到系统的性能极限，可以为性能调优提供相关数据。该类方法通常要基于或模拟系统真实运行环境，且选取的业务场景也要尽可能地与实际情况相符。
狭义的定义：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。运用场景：此类型的测试目前运用得比较少。一般情况下，是以服务器资源安全临界值为界限的测试。如果要模拟某个应用在指定服务器上最大且安全的负载量，则属于负载测试。
目标
确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。例如，响应时间、事务处理速率和其他与时间相关的方面。
负载测试的目标是测试在一定负载情况下系统性能（不关注稳定性，也就是说不关注长时间运行，只是得到不同负载下相关性能指标即可）；实际中我们常从比较小的负载开始，逐渐增加模拟用户的数量（增加负载）， 观察不同负载下应用程序响应时间、所耗资源，直到超时或关键资源耗尽，这就是所说的负载测试，它是测试系统的不同负载情况下的性能指标。
目的
负载测试是为了发现系统的性能问题，负载测试需要通过系统性能特性或行为来发现问题，从而为性能改进提供帮助，从这个意义看，负载测试可以看作性能测试的一部分。但它们两者的目的是不一样的，负载测试是为了发现缺陷，而性能测试是为了获取性能指标。因为性能测试过程中，也可以不调整负载，而是在同样负载情况下改变系统的结构、改变算法、改变硬件配置等等来得到性能指标数据，从这个意义看，负载测试可以看作是性能测试所用的一种技术，即性能测试使用负载测试的技术、使用负载测试的工具。性能测试要获得在不同的负载情况下的性能指标数据。
通过负载测试和压力测试都可以获得系统正常工作时的极限负载或最大容量。容量测试，自然也是采用负载测试技术来实现，而在破坏性的压力测试中，容量的确可以看作是一种副产品——间接结果。
负载测试的必要准备
1.什么是你真正需要了解的？
2.确定用户数量
3.研究你的分析
4.组建你的团队
5.准备你的浏览器
6.准备测试你的应用
7.预留时间分析结果
8.预留时间修改
9.计划一个敏捷测试方法
压力测试（Stress Testing）
定义
压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
压力测试可以被看作是负载测试的一种，即高负载下的负载测试，或者说压力测试采用负载测试技术。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能不能正常使用或系统出错的概率比较低，可能一个月只出现一次，但在高负载（压力测试）下，可能一天就出现，从而发现有缺陷的功能或其它系统问题。通过负载测试，可以证明这一点，某个电子商务网站的订单提交功能，在10个并发用户时错误率是零，在50个并发用户时错误率是1%，而在200个并发用户时错误率是20%。
狭义的定义：压力测试是指超过安全负载的情况下，对系统不断施加压力，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。运用场景：此类型的测试目前运用得比较少。但对于大型的共享中心或者核心的应用也会用到。
目标
压力测试的目标是测试在一定的负载下系统长时间运行的稳定性，尤其关注大业务量情况下长时间运行系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）；压力测试是测试系统的限制和故障恢复能力，它包括两种情况：
稳定性压力测试：在选定的压力值下，长时间持续运行。通过这类压力测试，可以考察各项性能指标是否在指定范围内，有无内存泄漏、有无功能性故障等；
破坏性压力测试：在稳定性压力测试中可能会出现一些问题，如系统性能明显降低，但很难暴露出其真实的原因。通过破坏性不断加压的手段，往往能快速造成系统的崩溃或让问题明显的暴露出来。
目的
压力测试主要是为了发现在一（任意）定条件下软件系统的性能的变化情况，通过改变应用程序的输入以对应用程序施加越来越大的负载（并发，循环操作，多用户） 并测量在这些不同的输入时性能的改变，也就是通常说的概念：压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。其实这种测试也 可以称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。比如实际中我们说从比较小的负载开始，逐渐增加模拟用户的数量， 直到应用程序响应时间超时，就是说的负载测试。
压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。压力测试是指当硬件资源如cpu、内存、磁盘空间等不充足时对软件稳定性的检查。压力测试属于负面测试（Negative testing），使大量并发用户/进程加载软件以使系统硬件资源不能应付，这个测试也被称为是疲劳测试（Fatigue testing），通过超出其能力的测试来捕获应用程序的稳定性。压力测试的主要思想是确定系统故障，关注系统如何优雅地恢复正常，这种质量被称为是可恢复性。
负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。正面测试就是测试系统是否完成了它应该完成的功能；而负面测试就是测试系统是否不执行它不应该完成的操作。
配置测试
同功能测试一样，如果需求规格说明中有明确的性能需求，例如完成复杂运算处理的解算时间要求，解算精度要求，网络传输吞吐量，数据库的最大容量，服务器能允许的同时在线访问数量等等，都要反映在配置项测试里。如果没有明确指出性能要求，测试人员可根据软件产品所处行业，自行产生测试需求。——这很考验测试人员的素质和水平的哦。例如前面所提到的，服务器能允许的最大同时在线访问量，就是互联网行业的一个性能需求。当然，还有常规的空间性能（存储和占用计算机硬件资源）和时间性能（软件处理一个任务所用时间），如今的计算机资源，基本都满足要求，除非你是航空发射，武器控制等特殊行业，才需要非常关注
配置测试主要指通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。例如，可以通过不停地调整 Oracle 的内存参数来进行测试，使之达到一个较好的性能。可以看出，配置测试本质上是前面提到的某些种类的性能测试组合在一起而进行的测试。
并发测试
定义
所谓并发，它的特点是“并行”和“同时”。在loadrunner中就得使用集合点的功能来实现。
测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，几乎所有的性能测试都会涉及一些并发测试。通常的测试方法是设置集合点。
目的
测试目的并非为了获得性能指标，而是为了发现并发引起的问题。
并发概念的浅谈
想确定用户并发数；必须知道系统所承载的在线用户数；
对于并发，我过去接触了几种理解，在接触的第一种理解中，“并发”是由loadrunner中获取，即脚本中所有或部分vuser执行至集合点函数时进行停留，等待触发条件发生以后，同时执行集合点函数后的请求操作的这一个过程，为“并发”（这一个请求操作一般存在多个http请求），可惜这种“并发”是无法直接用于衡量系统性能的。
LoadRuner的并发很好理解，就是虚拟用户数。因为LR有个集合点，可以在所有虚拟用户初始化且到达集合点后，再一起执行后续操作，从而达到同时且并行的效果。
而在接触的第二种理解中，“并发”的理解是相对于服务器某一个时间区间内接收的请求数，也就是每秒的点击率（loadrunner考虑到这点，也就是analysis里面的hits/s），为“并发”，这种“并发”是可以用于对系统性能状况进行量化的，但是这种测试思想只是比较片面的从性能指标的角度去衡量系统性能，不能体现出系统性能带给用户何种性能体验（这也是不少开源性能测试工具的问题）。
前一种“并发”的理解普遍获得了loadrunner初级用户的认可，后一种“并发”的理解普遍获得系统运维、开发人员的认可，在沟通中为了方便区别开来，在两种角色里面，当大家意识到并发的理解存在差异时，大家把前一种被称为“狭义上的并发”，而后一种被称为“广义上的并发”。后来，又从淘宝团队里面了解了一种定义，貌似淘宝QA把“并发”定义为一个完整的事务请求数量过程（loadrunner也考虑到这点，也就是analysis里面的Transactions per Second）。一直以来，还有一种技术范围以外对“并发”的粗略的理解被第三方测试拿来用了，那就是用户在线数中的某个百分比即并发数。
如果一个团队里面对“并发”的理解有这么多种，那么当我们在讨论性能需求的“支持并发数”时，我们究竟在讨论什么呢？
个人认为，有一部分的原因是由于loadrunner是惠普saas（软件即服务的解决方案）的一部分，所以并不是一个纯粹技术人员使用的测试工具，它同时也是一个业务人员可以相对轻易掌握的性能测试工具，因此loadrunner内很多名词解释也不能单纯从技术人员的角度从字面意义上理解。
通常来说，面对同样100笔业务交易量，普遍会认为100vuser对服务器产生的负载会比50vuser要高，但是在性能脚本能够在较快的响应时间中完成时，由于50vuser执行过程中每一个vuser都需要发生两次迭代，导致了性能场景中vuser在脚本action部分停留的时间更长，因此反而能够得到比100vuser的更高的vuser在线数，更高在线数带来的也就是更大的负载，也就是说：
同等业务量的情况下，50线程所产生的负载完全有可能比100线程所产生的负载要高。
为了避免发生这种问题，“并发（集合点）”的真正作用就体现出来了，通过集合点函数控制了vuser的行为相对一致，降低了初始化过程和事务前后文请求产生的时间差影响。测试工具中并发存在的真正意义也就在这里，对集合点所理解的“并发”，和现场实际用户里面同时触发的请求关系不是太大。
分析“并发”需求时的一些典型：
a) 某个业务系统里面有10000用户，但是能够访问这个系统的终端数只有1000个、或者所需测试的业务每个月上限是1000笔，那么最高在线用户数就不可能超过1000、业务量也不可能超过1000。所以，有些时候在分析性能需求的时候，去统计一个业务系统的用户数还不如去统计能够访问这个系统的终端数、甚至业务量靠谱。
b) 某个业务系统里面，各个业务模块都不一样，那么就是说完成一笔业务交易，所产生的请求数也是不一样的，例如表单新增，有的需要填写20个字段，有的只需要填写5个字段，各个表单都不一样，那么为了更接近的去模拟用户现场负载，请求数都不一样的各种业务混在一起，并发数又应该是多少呢？
为了解决这些问题，需要首先考虑“并发”的粒度，以真实的业务场景为例：
a) 把粒度控制在用户上来看，假定所有用户访问一次系统平均耗时500秒，一个业务峰值会有800用户在线，则800/500=1.6。理论上，系统的性能需求是每秒要成功处理1.6个用户的请求；
b) 把粒度控制在事务上来看，假定所有用户执行一次完整的、成功的业务操作平均需要500秒，一个业务峰值有2000笔所关注的业务需要去执行，则2000/500=4。理论上，系统的性能需求是每秒要成功处理4笔业务交易；
c) 把粒度控制在请求上来看，假定所有用户执行一次完整的、不管成功或者失败的HTTP请求操作平均需要0.08秒，一个业务峰值有28000个请求需要去完成，则28000/0.08=350000。理论上，系统的性能需求是每秒要成功处理350000个请求。
分类
1、独立业务性能测试：核心业务模块的某一业务并发性能测试；
2、组合业务性能测试：一个或多个模块的多个业务同时进行并发测试。
独立业务性能测试
1、完全一样功能的并发测试：检查程序对同一时刻并发操作的处理，例如模拟多个用户在同一时刻向数据库写入相同数据，或者多个用户在同一时刻发出请求测试系统能否正确响应。
2、完全一样操作的并发测试：在同一时刻完成完全一样的操作，即从宏观上看操作对系统的影响是一致的，例如同时单击保存按钮。这类测试目的在于验证大量用户使用同一功能时系统能否正常工作。
3、相同/不同的子功能并发测试：同一模块大多数功能相互耦合，针对一些子功能较多的模块做组合测试。组合的依据就是用户使用的场景，每个不同的子功能都模拟一定的用户数量进行并发测试。
组合业务性能测试
1、不同核心业务模块的用户进行并发，模块之间具有一定耦合：这种测试比较接近用户使用情况，测试的对象是多个模块组，每个组相关的模块之间具有一定耦合关系。组与组之间的关系相对独立。例如实际中各类型的用户都会对应一组模块，相当于不同的业务组并发的访问系统。
2、具有耦合关系的核心模块组进行并发，每组模块内部存在耦合关系：主要测试多用户并发条件下一些存在耦合或者数据接口的模块是否正常运行，可以参考集成测试用例和概要设计文档，分析出一些核心模块的接口。
3、基于用户场景的并发测试：选择用户的一些经典场景做测试，测试对象可以是核心模块，也可以是非核心模块。这种测试更接近用户使用的实际情况，测试需要充分考虑实际场景。设计组合模块用户并发性测试用例一般用不同“子功能”或者“子事务”为单位，来进行各种模块的不同核心功能组合。
并发用户数量设计方法
容量测试（Volume Testing）
定义
所谓容量，即系统处于最大负载状态或某项指标达到所能接受的最大阈值下对请求的最大处理能力。
容量测试是一种非功能的测试，它通过向应用程序中添加大量的数据来实现检查被测系统处理大数据量的能力。
可以通过向数据库插入大量的数据或让应用程序处理一个大型文件来进行测试应用程序。通过容量测试，可以识别应用程序中具有大数据时的瓶颈，检查应用程序的效率，进而得到不同数据量级下应用程序的性能。确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。
举例：
在一个新开发的网络游戏应用程序中，在进行容量测试时，可以通过向数据库中插入数百万行的数据，然后在这些数据的基础上进行性能的测试。
注意，这里所说的数据一定是符合其功能场景的，不是毫无关系的数据。
目的
容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。软件容量的测试能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如是不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。
如何统计容量指标？
统计维度
一般来说，可以从如下两个维度来定量系统的容量：
统计方法
一般来说，常用的采集数据的方法，有以下几种方式：
①、埋点采集：即在系统的各个节点，根据需要添加埋点，针对性的进行数据采集；
②、日志/数据库：通过日志服务（比如ELK）或者运维监控（现在很流行的Devops），采集分析数据；
③、Agent/探针：在需要采集的节点添加Agent/探针，实时采集，数据存入时序数据库（比如influxdb），实时展示；
注意事项
①、采集对比的数据一定要采集线上的真实数据，这样才能反映真实客观的系统压力。
②、容量测试环境的配置，一定要和线上保持一致（服务器数量可以不同，但配置尽可能保持一致）。
测试思路
①、根据具体的业务情况和系统架构，通过配置测试的手段，测量得到单个服务节点在对应的业务场景下最大的性能表现；
②、根据系统架构（集群、分布式、微服务）特点，通过启用≥2的服务节点，来得到服务节点的增加和系统性能的提升比例；
③、通过线上采集的系统数据，分析出过去某段时间（或某个业务）的高峰流量，然后通过计算，得到容量扩容，需要投入的实际服务数量；
约束/停止条件
在测试过程中，只要限定的某项指标达到最大可接受阈值或某项资源达到最大使用状态，即刻停止测试。
选择合适的容量指标
考虑到业务需求和系统架构的不同，在选取容量指标时一般遵循如下原则：
①、数据密集型：即并发请求量较大的类型，一般TPS和RT是比较关注的指标；
②、数据存储型：即需要存储读写的数据量较大的类型，一般吞吐量和IO是比较关注的指标；
容量规划
为什么需要容量规划？
对于业务越来越复杂的商业形态，每个业务都由一系列不同的系统来提供服务，每个业务系统都部署在不同的机器上。容量规划的目的在于让每一个业务系统能够清晰地知道：
①、什么时候应该增加服务节点，什么时候应该减少服务节点（比如服务端接受到的流量达到什么量级）？（比如双十一，大促，秒杀）
②、为了双 11 、促销、秒杀、渠道拓展引流等业务需求，需要扩充到什么数量级的服务，才能即保证系统的可用性、稳定性，又能节约成本？
容量规划四步走
①、业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少多少的流量冲击；
②、系统容量评估阶段：根据具体的业务场景，分析每个业务场景的流量配比，然后计算每个业务大概需要多少服务节点来提供可靠稳定的性能支撑；
③、系统容量测试阶段：通过全链路压测或者PAT/UAT环境的压测，来模拟真实的业务场景，确定每个服务节点的具体性能表现，进行针对性的调整；
④、流量分配调整阶段：根据压测的结果，设定限流、服务降级等系统保护措施，来预防当实际流量超过系统所能承受的最大流量时，系统无法提供服务；
扩容手段
①、垂直扩容
升级服务的硬件配置，让单个服务节点的容量更大，来提供更高的系统服务能力。比如：
加大服务机器的CPU数量和内存，更换性能更好的高速缓存服务器，数据存储用NAS盘替换等。
②、水平扩展
即增加服务节点的数量，让可提供服务的服务变得更多，来提升系统总体的服务能力。常见的方式有：
服务集群：服务器的数量由1→N（但需要重点关注负载均衡）；
分布式：提供服务的节点由统一集中管理部署，分散到不同的地点；
容器：提供更灵活的弹性扩容机制，根据具体的访问流量大小来弹性扩容或者缩容；
容量测试的优点
以下是任何软件应用程序的容量或洪水测试的优点。
- 它提供了运行软件应用程序所需的硬件类型的清晰图像，包括CPU、内存等。
- 可以很早地确定可扩展性计划。
- 它有助于节省可能用于应急计划的大量资金。
- 它有助于尽早发现应用程序操作中的瓶颈。
- 它确保了经过容量测试的应用程序已准备好投入实际使用。
- 它有助于让应用程序上线或不上线。
容量测试的缺点
此类测试增加了项目的额外成本，因为它是由不同的性能测试团队在功能测试的基础上完成的。
为什么经常推荐容量测试？
由于以下原因，通常建议进行容量测试。
- 当到数据库中的数据量增加时，它有助于检查系统性能。
- 使用大量数据研究软件应用程序行为。
- 评估应用程序稳定性开始降低的点。
- 它可以识别正常，低，中，高容量下的应用能力。
容量测试检查
在容量或洪水测试期间评估和检查以下参数。
- 容量测试旨在检查是否有任何数据丢失。
- 进行容量测试以记录不同容量条件下的响应时间并评估平均响应时间。
- 它旨在评估数据库中的数据是否正确保存。
- 它旨在验证数据是否被任何通知覆盖。
- 它旨在检查警告和错误消息，以及它们在不同容量级别的关联。
- 它旨在检查高数据量是否会以任何方式影响被测系统中处理请求的速度。
容量测试最佳实践
以下是最佳容量测试结果广泛遵循的最佳实践。
- 在检查所有日志 (即服务器和应用程序的日志) 时, 不要忘记停止所有服务器。
- 在开始容量测试之前，确保正面（正常）场景正常工作。
- 为了从容量测试中获得最佳结果，始终建议错开用户数量。
- 平衡你的容量试时间以克服许可限制。
- 引入的任何新版本都应该非常谨慎地处理。
- 建立基线后，应分析用例以提高性能。
- 在出现性能瓶颈的情况下，应该反复重复进行容量测试，以深入研究性能问题。
可靠性测试
定义
软件可靠性测试是指为了保证和验证软件的可靠性要求而对软件进行的测试。其采用的是按照软件运行剖面(对软件实际使用情况的统计规律的描述)对软件进行随机测试的测试方法。
软件可靠性是软件系统在规定的时间内以及规定的环境条件下，完成规定功能的能力。一般情况下，只能通过对软件系统进行测试来度量其可靠性。
对软件可靠性进行定量的评估或验证，为了达到和验证软件的可靠性定量要求而对软件进行的测试。
软件可靠性测试通常是在系统测试、验收、交付阶段进行，它主要是在实验室内仿真环境下进行，也可以根据需要和可能在用户现场进行。
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。例如，可以施加让 CPU 资源保持 70%～90%使用率的压力，连续对系统加压 8 个小时，然后根据结果分析系统是否稳定。这么多类型的性能测试看起来很吓人，实际上它们大多是密切相关的。例如，运行 8 个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性测试、强度测试、并发（用户）测试、负载测试，等等。
特点
测试的目的
(1)通过在有使用代表性的环境中执行软件，以证实软件需求是否正确实现。
(2)为进行软件可靠性估计采集准确的数据，预测软件在实际运行中的可靠性。
估计软件可靠性一般可分为四个步骤，即数据采集、模型选择、模型拟合以及软件可靠性评估。可以认为，数据采集是整个软件可靠性估计工作的基础，数据的准确与否关系到软件可靠性评估的准确度。
(3)通过软件可靠性测试找出所有对软件可靠性影响较大的错误。
(4)通过测试可以提高整个软件系统的防错、容错和纠错的能力。
通过软件可靠性测试可以达到以下目的：
(1) 有效地发现程序中影响软件可靠性的缺陷，从而实现可靠性增长：软件可靠性是指“在规定的时间内，规定的条件下，软件不引起系统失效的能力，其概率度量称为软件可靠度。”
软件的“规定的条件”主要包括相对不变的条件和相对变化的条件，相对不变的条件如计算机及其操作系统;相对变化的条件是指输入的分布，用软件的运行剖面来描述。认为按照软件的运行剖面对软件进行测试一般先暴露在使用中发生概率高的缺陷，然后是发生概率低的缺陷。而高发生概率的缺陷是影响产品可靠性的主要缺陷，通过排除这些缺陷可以有效地实现软件可靠性的增长。
(2) 验证软件可靠性满足一定的要求：通过对软件可靠性测试中观测到的失效情况进行分析，可以验证软件可靠性的定量要求是否得到满足。
(3) 估计、预计软件可靠性水平
通过对软件可靠性测试中观测到的失效数据进行分析，可以评估当前软件可靠性的水平，预测未来可能达到的水平，从而为开发管理提供决策依据。软件可靠性测试中暴露的缺陷既可以是影响功能需求的缺陷也可以是影响性能需求的缺陷。软件可靠性测试方法从概念上讲是一种黑盒测试方法，因为它是面向需求、面向使用的测试，它不需要了解程序的结构以及如何实现等问题。
分析方法
目前主要的软件可靠性分析方法有失效模式影响分析法、严酷性分析法、故障树分析法、事件树分析法、潜在线路分析法。
测试过程
包括五个步骤：确定可靠性目标，定义软件运行剖面，设计测试用例，实施可靠性测试，分析测试结果。
失败恢复性测试
对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发生故障用户是否能够继续使用系统，用户收到多大的影响。
强度测试
强度测试是一种性能测试，它在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。
强度测试主要是为了检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如：
当正常的用户点击率为“1000 次/秒”时，运行点击率为“2000 次/秒”的测试用例；
运行需要最大存储空间（或其他资源）的测试用例；
运行可能导致操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
强度测试是一种特别重要的测试，对测试系统的稳定性，以及系统未来的扩展空间均具有重要的意义。在这种异常条件下进行的测试，更容易发现系统是否稳定以及性能方面是否
容易扩展。
疲劳测试
疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如 7× 24 小时的压力测试。
尖峰测试（Spike testing）
尖峰测试（Spike testing）其实可以算作是压力测试（Stress Testing）的子集。
尖峰测试是在目标系统经受短时间内反复增加工作负载，以至超出预期生产操作的负载量时，分析系统的行为，验证其性能特征。它还包括检查应用程序是否可以从突然增加的超预期负荷中恢复出来的测试。
举例：在电商应用程序中经常有“整点秒杀”的活动，所以在整点时间前后的两三分钟时间里，会有巨大数量的用户进入到该活动中秒杀商品。尖峰测试就是为了分析这类场景。
持久测试（Endurance testing）
持久测试（Endurance testing），也被称为是浸泡测试（Soak Testing），它也是一种非功能的测试。
持久测试是指在相当长的时间内使用预期的负载量对系统进行测试，以检查系统的各种行为，如内存泄露、系统错误、随机行为等。
这里的提到的相当长的时间是相对而言的，举例来说，如果一个系统设计为运行3个小时的时间，那可以使用6个小时的时间来进行持久测试；如果设计为5个小时的时间，不妨用10个小时的时间来进行持久测试。对于现在的许多网络类应用程序，通常情况下会持续运行好多天，那么进行持久测试时可以选择更长的时间段。
稳定性测试
狭义的定义：稳定性测试是指被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为 n*12 小时。
运用场景：此类型的测试目前也最常见，针对需要长时间稳定运行的性能点，需要执行稳定性测试。往往在一个项目的性能测试过程中，会划分出优先级较高的性能点，做稳定性测试。例如：宝贝详情页面等等。
如何实施
识别并确认软件主要业务（是否需要稳定性测试）
将稳定性测试的重心放在软件最有Value的地方，比如说一个抢票系统，它最有value的地方是当有一定数量的用户同时进行买票操作是系统的响应时间，资源利用率等是否能够正常且稳定，而不是用户如何添加新的联系人，修改个人信息等。
罗列主要用户场景及响应负载量
用户场景可以根据软件主要业务进行设定
对主要场景负载量需要有一个清晰的定义（或者通过负载测试验证了用户场景的负载量，这将作为一个标准的负载在稳定性测试中使用）
制定稳定性指标模型（Modeling）
根据用户场景建模，创建合适合理的稳定性指标模型（之后会有一个例子）
测试环境准备（对软硬件环境的配置：配置的来源可以是客户环境模拟、需求文档规定的配置或者配置测试得出的最佳配置）
识别稳定性的主要性能指标（KPI）
用来描述稳定性测试关注的系统指标，比如响应时间、CPU、内存使用率等等，需要根据具体业务进行定义测试的执行和数据收集，
按照相应稳定性指标模型（Modeling)分析测试结果，将测试结果应用在稳定性测试模型中，观察是否满足稳定性要求
持续改进（如有必要）
大数据量测试
主要针对数据库有特殊要求的系统进行的测试，如电信业务系统的手机短信业务；可以分为实时大数据量，主要目的是测试用户较多或者某些业务产生较大数据量时，系统能否稳定运行；极限状态下的测试，测试系统使用一段时间即系统累计一点量的数据时能否正常的运行业务；前面两种的结合，测试系统已经累计了较大数据量时，一些实时产生较大数据量的模块能否稳定工作；
如下大数量测试用例：
功能：数据库中的短信息表可以保存所有不能及时发送的短信息，用户上线后又能及时发送已经保存的信息；
大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。
速度测试
速度测试主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。
不同类型测试之间的区别
性能测试是为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据，而负载测试、压力测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。通过负载测试，也是为了获得系统正常工作时所能承受的最大负载，这时负载测试就成为容量测试。通过压力测试，可以知道在什么极限情况下系统会崩溃、系统是否具有自我恢复性等，但更多的是为了确定系统的稳定性。
压力测试是测试系统什么情况下失效或者崩溃；负载测试是测试系统什么情况下超出需求指标；强度测试是测试系统在瞬时高负载、长时间负载情况下系统反应；容量测试是测试系统在大数据量交互的反应！
性能指标
性能测试最基本要考虑以下几点
1、时间特性，主要指的是软件产品的事物响应时间（用户发出请求到收到应答的这段时间）
2、资源利用率，包括：cpu、内存、网络、硬盘、虚拟内存（如Java虚拟机）
3、服务器可靠性，指服务器能在相对高负载情况下持续的运行
4、可配置优化性，指服务器配置优化、业务逻辑优化、代码优化等
检查系统是否满足需求规格说明书中规定的性能，通常表现在以下几个方面：
1、对资源利用（包括：cpu、内存、网络、硬盘、虚拟内存（如Java虚拟机）等）进行的精确度量；
2、对执行间隔；
3、日志事件（如中断，报错）
4、响应时间
5、吞吐量（TPS）
6、辅助存储区（例如缓冲区、工作区的大小等）
7、处理精度等进行的监测
在实际工作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？
bs结构程序一般会关注的通用指标如下（简）：
Web服务器指标指标：
* Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）：平均每秒业务脚本的迭代次数，有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Buffer Cache hit ：数据库Cache的命中情况
当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。
我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。一般软件可以按照系统架构分成几种类型：
c/s
client/Server 客户端/服务器架构
基于客户端/服务器的三层架构
基于客户端/服务器的分布式架构
b/s
基于浏览器/Web服务器的三层架构
基于中间件应用服务器的三层架构l
基于Web服务器和中间件的多层架构l
性能指标的两个方面
外部指标|系统指标（与用户场景和需求相关指标）
从外部看，性能测试主要关注如下四个指标
- 吞吐量：每秒钟系统能够处理客户的请求数、任务数，其直接体现系统的承载的能力。
- 并发用户数：同一时刻与服务器进行数据交互的所有用户数量；
- 响应时间：服务处理一个请求或一个任务的耗时。
- 错误率：一批请求中结果出错的请求所占比例。
响应时间
从单个请求来看就是服务响应一次请求的花费的时间。但是在性能测试中，单个请求的响应时间并没有什么参考价值，通常考虑的是完成所有请求的平均响应时间及中位数时间。
平均响应时间很好理解，就是完成请求花费的总时间/完成的请求总数。但是平均响应时间有一点不靠谱，因为系统的运行并不是平稳平滑的，如果某几个请求的时间超短或者超长就会导致平均数偏离很多。因此有时候我们会用中位数响应时间。
所谓中位数的意思就是把将一组数据按大小顺序排列，处在最中间位置的一个数叫做这组数据的中位数 ，这意味着至少有50%的数据低于或高于这个中位数。当然，最为正确的统计做法是用百分比分布统计。也就是英文中的TP – Top Percentile ，TP50的意思在，50%的请求都小于某个值，TP90表示90%的请求小于某个时间。
响应时间的指标取决于具体的服务。如智能提示一类的服务，返回的数据有效周期短（用户多输入一个字母就需要重新请求），对实时性要求比较高，响应时间的上限一般在100ms以内。而导航一类的服务，由于返回结果的使用周期比较长（整个导航过程中），响应时间的上限一般在2-5s。
决定系统响应时间要素
我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。
系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统响应时间；
关键路径是由CPU运算、IO、外部系统响应等等组成。
计算公式
1、响应时间：对一个请求做出响应所需要的时间
网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=网络响应时间+应用程序响应时间=（N1+N2+N3+N4）+(A1+A2+A3)
2、平均响应时间：所有请求花费的平均时间
系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。
如：如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms
平均响应时间： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms并不能反映服务器的整体效率，因为98个请求耗时才1ms，引申出百分位数
百分位数：以响应时间为例，指的是 99% 的请求响应时间，都处在这个值以下，更能体现整体效率。
注：（一般响应时间在3s内，用户会感觉比较满意。在3s~8s之间用户勉强能接受，大于8s用户就可能无法接受，从而刷新页面或者离开，仅供参考）
响应时间与负载对应关系
图中拐点说明：
（1）响应时间突然增加
（2）意味着系统的一种或多种资源利用达到的极限
（3）通常可以利用拐点来进行性能测试分析与定位
并发用户数
一、首先涉及到并发用户数可以从以下几个方面去做数据判断。
1.系统用户数
2.在线用户数
3.并发用户数
二、三者之间的关系
1.在线用户数的预估可以采取20%的系统用户数。例如某个系统在系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考。
2.在线用户数和并发用户数又存在着关系。即：平均并发用户数为:c=NL/T L为在线时长，T为考核时长。例如:考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n*2/8 n为登录系统的用户数，L为登录的时常。例如:一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户则为:c=400*2/8
并发主要是针对服务器而言，在同一时刻与服务器进行交互（指向服务器发出请求）的在线用户数。
（1）并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能。
（2）在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。如多个用户在浏览网页，但没有对同时对服务器进行数据请求，需要与并发用户数区分开。
（3）系统用户数：系统注册的总用户数据
三者之间的关系：系统用户数 >= 在线用户数 >= 并发用户数
同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间
平均并发用户数的计算：C=nL / T
其中C是平均的并发用户数，n是平均每天访问用户数（login session），L是一天内用户从登录到退出的平均时间（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）
并发用户数峰值计算：C^约等于C + 3*根号C 也是峰值C1,即最大并发数，计算公式C1=C+³√C
其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。
注：理解最佳并发用户数和最大并发用户数
看了《LoadRunner没有告诉你的》之理发店模式，对最佳并发用户数和最大的并发用户数的理解小小整理了一下。
所谓的理发店模式，简单地阐述一下，一个理发店有3个理发师，当同时来理发店的客户有3个的时候，那么理发师的资源能够有效地利用，这时3个用户数即为最佳的并发用户数；当理发店来了9个客户的时候，3个客户理发，而6个用户在等待，3个客户的等待时间为1个小时，另外的3个客户的等待时间为2小时，客户的最大忍受时间为3小时包括理发的1个小时，所以6个客户的等待时间都在客户的可以承受范围内，故9个客户是该理发店的最大并发用户数。
吞吐量
我把吞吐量定义为“单位时间内系统处理的客户请求的数量”（ 吞吐量表示单位时间内能够完成的事务数量，因此也被称为每秒事务数（Transaction Per Second），计算方式是完成的事务数除以时间。），直接体现软件系统的性能承载能力，对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。
吞吐量的指标受到响应时间、服务器软硬件配置、网络状态等多方面因素影响。
- 吞吐量越大，响应时间越长。
- 服务器硬件配置越高，吞吐量越大。
- 网络越差，吞吐量越小。
在低吞吐量下的响应时间的均值、分布比较稳定，不会产生太大的波动。在高吞吐量下，响应时间会随着吞吐量的增长而增长，增长的趋势可能是线性的，也可能接近指数的。当吞吐量接近系统的峰值时，响应时间会出现激增。
系统吞度量要素
一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS(每秒请求数)（TPS （Transaction Per Second）每秒事务数）：每秒钟系统处理的request/事务 数量，它是衡量系统处理能力的重要指标；
并发数：系统同时处理的request/事务数
响应时间：一般取平均响应时间
理解了上面三个要素的意义之后，就能推算出它们之间的关系：QPS（TPS）= 并发数/平均响应时间
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
系统吞吐量评估
我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。而通常境况下，我们面对需求，我们评估出来的QPS、并发数之外，还有另外一个维度：日页面流量PV。
PV：访问一个URL，产生一个PV（Page View，页面访问量），每日每个网站的总PV量是形容一个 网站规模的重要指标。
通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。只要能拿到日流量图和QPS我们就可以推算日流量。
通常的技术方法：
1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）
2. 通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。
无论有无思考时间（T_think），测试所得的TPS值和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：TPS=U_concurrent / (T_response+T_think)。
并发数、QPS、平均响应时间三者之间关系
X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。
X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。
同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。
最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发 用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。
Light Load（较轻压力）-----最佳用户数（资源利用最高）---（较重压力，系统可以持续工作，但用户等待时间较长，满意度会下降）-----Heavy Load-------最大并发用户数--------Buckle Zone（用户无法忍受而放弃请求）
最佳并发用户数：当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待
最大并发用户数：系统的负载一直持续，有些用户在处理而有的用户在自己最大的等待时间内等待的时候
我们需要保证的是：
（1）最佳并发用户数需大于系统的平均负载
（2）系统的最大并发用户数要大于系统需要承受的峰值负载
怎么理解这两句话呢？
（1）系统的平均负载：在特定的时间内，系统正在处理的用户数和等待处理的用户数的总和
如果系统的平均负载大于最佳并发用户数，则用户的满意度会下降，所以我们需要保证系统的平均负载小于或者等于最佳并发用户数
（2）峰值：指的是系统的最大能承受的用户数的极值
只有最大并发用户数大于系统所能承受的峰值负载，才不会造成等待空间资源的浪费，导致系统的效率低下
计算公式
指单位时间内系统处理用户的请求数
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量
从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R /T
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
吞吐量与负载对应关系
图中拐点说明：
（1）吞吐量逐渐达到饱和
（2）意味着系统的一种或多种资源利用达到的极限
（3）通常可以利用拐点来进行性能测试分析与定位
错误率
超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。
错误率和服务的具体实现有关。通常情况下，由于网络超时等外部原因造成的错误比例不应超过5%%，由于服务本身导致的错误率不应超过1% 。
内部指标|资源指标（与硬件资源消耗相关指标）
资源利用率：资源利用率指的是对不同系统资源的使用程度，一般使用“资源实际使用/总的资源可用量”形成资源利用率。例如服务器的 CPU 利用率、磁盘利用率等。资源利用率是分析系统性能指标进而改善性能的主要依据，因此，它是 Web 性能测试工作的重点。资源利用率主要针对 Web 服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需要采集具体的资源利用率参数来进行分析。
从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等
1.硬件性能指标：CPU，内存Memory，磁盘I/O（Disk I/O），网络I/O（Network I/O）
CPU：主要解释计算机指令以及处理计算机软件中的数据
Linux系统中top命令查看CPU的使用率
CPU的利用率（<=75%）有：user（用户使用）,sys（系统调用<=30%）,wait（等待<=5%），idle（空闲）
当user消耗高时，通过top命令查看哪个用户进程占用cpu的使用
user消耗过高的原因可能有:
（1）代码问题。如代码中耗时循环中不加sleep，即例如while的死循环中，没有加sleep时间，导致没有空余的时间将cpu的控制权给其他的进程，一直陷入该死循环中，cpu得不到休息，所以usr的消耗过高，则cpu的消耗高
（2）gc频繁。gc则为垃圾回收，由于垃圾回收也是需要大量的计算，也消耗cpu，所以当gc频繁时也导致usr用户空间的消耗也过高，cpu消耗过高
当sys消耗高时，通过top命令查看系统调用资源的情况
sys消耗过高的原因可能有：
（1）上下文切换频繁。上下文切换发生的情况有：中断处理，多任务处理，用户状态改变。
中断处理，当cpu停止处理当前的进程转而处理中断请求的进程时发生上下文切换。多任务处理则为有多个进程请求cpu的处理，进程的数量多于cpu的核数，则分配进程时间片，根据时间片处理进程，意味着会强制停止一个进程而去处理另一个进程，形成频繁的上下文切换。用户状态改变则为user状态与sys状态的改变。
wait较高时，即等待的进程占比高则可以考虑是否磁盘读写，磁盘瓶颈问题， 等待的进程较多时，cpu无论如何切换都是切换到等待的进程，导致cpu一直在频繁切换等待的线程而利用率较低
内存：与cpu沟通的桥梁，计算机中所有程序的运行都在内存中进行，内存分为物理内存、页面交换（Paging），SWAP内存（虚拟内存）
页面交换：当物理内存即实际的内存满了的时候，将物理内存中不常用的进程调出存储到虚拟内存中，以缓解物理内存空间的压力，所以当物理内存与虚拟内存的数据交换频繁的时候，这时候就要关注下内存的性能情况。
SWAP内存：为进程分配虚拟的内存空间，即调用硬盘的空间作为内存使用。
内存的性能分析是又可用内存与页面交换来分析的，可用内存使用占70%-80%为上限，当超出这个数值，内存性能情况就比较危险，而且即使可用内存使用不超过80%的数值时，页面交换比较频繁时，也是要关注下内存情
一般物理内存即使是满内存也不能代表内存出现问题，主要是看虚拟内存swap，虚拟内存应该<=70%，大于则可以考虑是否内存问题或者内存泄漏
磁盘吞吐量，指单位时间内通过磁盘的数据量。主要关注磁盘的繁忙率，如果高于70%，则磁盘瓶颈
网络吞吐量，指单位时间内通过网络的数据量，当吞吐量大于网路设备或链路最大传输能力，即带宽时，则应该考虑升级网络设备或者增加带宽，Linux命令netstate
网络IO也有可能出现终止连接失败。例如当服务端出现大量的TIME_WAIT，见以下TCP终止连接的第4个步骤，在主动发起关闭连接方接收到结束符FIN时状态变为TIME_WAIT,这时在服务端发现大量的TIME_WAIT,意味着关闭连接是由服务端发起的。
常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。
问？什么情况是由服务端发起关闭连接？答：在用户端的应用程序忘记关闭连接
另外如果在服务端发现大量状态CLOSE_WAIT,则说明第二次关闭回不去，也就是TCP关闭连接的第三个步骤没有执行，停留在CLOSE_WAIT的状态，浏览器如果这时发起请求则会返回超时连接，因为服务端这边一直无法进行第二次关闭，将结束符返回去给用户端。
注：普及TCP连接的三次握手，终止连接的四次握手
TCP三次握手连接：
(1)用户端发送SYN给服务器，用户端的状态为SYN_SEND
(2)服务端接收到后发送ACK给用户端，服务端的状态为SYN_RECV
(3)用户端接收到服务端发送过来的后发送了ACK给服务端，用户端的状态变为Estabilished
TCP终止连接：
(1)用户端的应用主动发起关闭连接，即应用调用close发送FIN给服务端
(2)服务端接收到FIN后发送ACK给用户端，服务端的状态变为CLOSE_WAIT
(3)服务端发送ACK给用户端的同时也将FIN作为一个文件结束符传递给接收端应用程序
(4)用户端的应用程序接收到FIN后将调用close关闭它的套接字，确认FIN，这时用户端的状态变为TIME_WAIT
(5)用户端发送ACK回执给服务端，连接终止
2.中间件：常用的中间件例如web服务器Tomcat,Weblogic web服务器，JVM（java虚拟机），ThreadPool线程池，JDBC数据驱动
注：http服务器和web服务器与应用服务器的差别是一个存储静态网页的服务器，一个是存储css，js等动态加载网页的服务器，而tomcat则属于应用服务器
注：对中间件例如对服务器的性能测试，需要将监控的jmeter-server的文件下载在服务端上，然后开启即可监控被测服务器的性能，或者将监控的软件下载在被测服务器上，远程启动监控软件等
3.数据库指标
应关注SQL，吞吐量，缓存命中率，连接数等，则是关注sql语句执行时间，以微妙为单位，吞吐量TPS，缓存命中率应>=95%
注：对数据库的性能测试通过jemter利用批量的sql语句对数据库进行操作，从而测试数据库的性能，前提是需要将jdbc的驱动加载在测试计划添加的驱动文件中，然后添加jdbc的前置处理器和jdbc的请求sample。
4.JVM，java虚拟机，为使java的代码可以编译运行在不同的平台上顺畅，仿真模拟各种计算机来实现
GC：自动内存管理程序，被引用的对象保存在内存中，当对象不被引用时则释放。关注的参数有Full GC完全java虚拟机垃圾部分回收频率
5.前端指标
前端应该关注页面展示，即首次显示时间，页面数量，页面大小，网络startRender，firstRender等
注：关注前端的性能与后端的性能的不同点在于，前端是每个用户的直观的感受，以及前端页面的加载元素耗费时间给予用户的感受，而后端的性能关注点在于多用户使用系统时，服务器是否能够承受或者服务器的处理能力如何，能否以较好的响应时间响应。
6.Load：系统平均负载，特定时间间隔内运行进程数，Load与cpu核数一致
CPU
CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。
后台服务的所有指令和数据处理都是由CPU负责，服务对CPU的利用率对服务的性能起着决定性的作用。
Linux系统的CPU主要有如下几个维度的统计数据：
us：用户态使用的cpu时间百分比
sy：系统态使用的cpu时间百分比
ni：用做nice加权的进程分配的用户态cpu时间百分比
id：空闲的cpu时间百分比
wa：cpu等待IO完成时间百分比
hi：硬中断消耗时间百分比
si：软中断消耗时间百分比
下图是线上开放平台转发服务某台服务器上top命令的输出，下面以这个服务为例对CPU各项指标进行说明
us & sy：大部分后台服务使用的CPU时间片中us和sy的占用比例是最高的。同时这两个指标又是互相影响的，us的比例高了，sy的比例就低，反之亦然。通常sy比例过高意味着被测服务在用户态和系统态之间切换比较频繁，此时系统整体性能会有一定下降。另外，在使用多核CPU的服务器上，CPU 0负责CPU各核间的调度，CPU 0上的使用率过高会导致其他CPU核心之间的调度效率变低。因此测试过程中CPU 0需要重点关注。
ni：每个Linux进程都有个优先级，优先级高的进程有优先执行的权利，这个叫做pri。进程除了优先级外，还有个优先级的修正值。这个修正值就叫做进程的nice值。一般来说，被测服务和服务器整体的ni值不会很高。如果测试过程中ni的值比较高，需要从服务器Linux系统配置、被测服务运行参数查找原因
id：线上服务运行过程中，需要保留一定的id冗余来应对突发的流量激增。在性能测试过程中，如果id一直很低，吞吐量上不去，需要检查被测服务线程/进程配置、服务器系统配置等。
wa：磁盘、网络等IO操作会导致CPU的wa指标提高。通常情况下，网络IO占用的wa资源不会很高，而频繁的磁盘读写会导致wa激增。如果被测服务不是IO密集型的服务，那需要检查被测服务的日志量、数据载入频率等。
hi & si：硬中断是外设对CPU的中断，即外围硬件发给CPU或者内存的异步信号就是硬中断信号；软中断由软件本身发给操作系统内核的中断信号。通常是由硬中断处理程序或进程调度程序对操作系统内核的中断，也就是我们常说的系统调用(System Call)。在性能测试过程中，hi会有一定的CPU占用率，但不会太高。对于IO密集型的服务，si的CPU占用率会高一些。
内存
内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。
性能测试过程中对内存监控的主要目的是检查被测服务所占用内存的波动情况。
在Linux系统中有多个命令可以获取指定进程的内存使用情况，最常用的是top命令，如下图所示
其中
VIRT：进程所使用的虚拟内存的总数。它包括所有的代码，数据和共享库，加上已换出的页面，所有已申请的总内存空间
RES：进程正在使用的没有交换的物理内存（栈、堆），申请内存后该内存段已被重新赋值
SHR：进程使用共享内存的总数。该数值只是反映可能与其它进程共享的内存，不代表这段内存当前正被其他进程使用
SWAP：进程使用的虚拟内存中被换出的大小，交换的是已经申请，但没有使用的空间，包括（栈、堆、共享内存）
DATA：进程除可执行代码以外的物理内存总量，即进程栈、堆申请的总空间
从上面的解释可以看出，测试过程中主要监控RES和VIRT，对于使用了共享内存的多进程架构服务，还需要监控SHR。
LOAD（服务器负载）
Linux的系统负载指运行队列的平均长度，也就是等待CPU的平均进程数
从服务器负载的定义可以看出，服务器运行最理想的状态是所有CPU核心的运行队列都为1，即所有活动进程都在运行，没有等待。这种状态下服务器运行在负载阈值下。
通常情况下，按照经验值，服务器的负载应位于阈值的70%~80%，这样既能利用服务器大部分性能，又留有一定的性能冗余应对流量增长。
Linux提供了很多查看系统负载的命令，最常用的是top和uptime
top和uptime针对负载的输出内容相同，都是系统最近1分钟、5分钟、15分钟的负载均值
Uptime命令结果的每一列的含义如下：
“当前时间 系统运行时长 登录的用户数最 近1分钟、5分钟、15分钟的平均负载”
查看系统负载阈值的命令如下，下方是查看CPU每个核心的使用情况：
在性能测试过程中，系统负载是评价整个系统运行状况最重要的指标之一。通常情况下，压力测试时系统负载应接近但不能超过阈值，并发测试时的系统负载最高不能超过阈值的80%，稳定性测试时，系统负载应在阈值的50%左右。
网络
网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。
性能测试中网络监控主要包括网络流量、网络连接状态的监控。
网络流量监控
可以使用nethogs命令。该命令与top类似，是一个实时交互的命令，运行界面如下
在后台服务性能测试中，对于返回文本结果的服务，并不需要太多关注在流量方面。
网络连接状态监控
性能测试中对网络的监控主要是监控网络连接状态的变化和异常。对于使用TCP协议的服务，需要监控服务已建立连接的变化情况（即ESTABLISHED状态的TCP连接）。对于HTTP协议的服务，需要监控被测服务对应进程的网络缓冲区的状态、TIME_WAIT状态的连接数等。Linux自带的很多命令如netstat、ss都支持如上功能。下图是netstat对指定pid进程的监控结果
磁盘IO
磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。
性能测试过程中，如果被测服务对磁盘读写过于频繁，会导致大量请求处于IO等待的状态，系统负载升高，响应时间变长，吞吐量下降。
Linux下可以用iostat命令来监控磁盘状态，如下图
tps：该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的
kB_read/s：每秒从设备（driveexpressed）读取的数据量，单位为Kilobytes
kB_wrtn/s：每秒向设备（driveexpressed）写入的数据量，单位为Kilobytes
kB_read：读取的总数据量，单位为Kilobytes
kB_wrtn：写入的总数量数据量，单位为Kilobytes
从iostat的输出中，能够获得系统运行最基本的统计数据。但对于性能测试来说，这些数据不能提供更多的信息。需要加上-x参数
rrqm/s：每秒这个设备相关的读取请求有多少被合并了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）
wrqm/s：每秒这个设备相关的写入请求有多少被Merge了
await：每一个IO请求的处理的平均时间（单位是毫秒）
%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，该参数暗示了设备的繁忙程度。
资源利用与负载对应关系
图中拐点说明：
（1）服务器某一资源使用逐渐达到饱和
（2）通常可以利用拐点来进行性能测试分析与定位
性能计数器（counters）
是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析系统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
常见性能瓶颈
吞吐量到上限时系统负载未到阈值：一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因
CPU的us和sy不高，但wa很高：如果被测服务是磁盘IO密集型型服务，wa高属于正常现象。但如果不是此类服务，最可能导致wa高的原因有两个，一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大，如不合理的数据载入策略、log过多等，都有可能导致这种问题。二是服务器内存不足，服务在swap分区不停的换入换出。
同一请求的响应时间忽大忽小：在正常吞吐量下发生此问题，可能的原因有两方面，一是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁；二是Linux本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。
内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位。
性能瓶颈定位之拐点分析法
“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法。它的基本思想就是性能产生瓶颈的主要原因就是因为某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能却出现急剧下降，这样就产生了“拐点”现象。当得到“拐点”附近的资源使用情况时，就能定位出系统的性能瓶颈。
软件性能的其它术语
思考时间的计算公式
Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。
在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R = T / TS
下面给出一个计算思考时间的一般步骤：
1、首先计算出系统的并发用户数
C=nL / T F=R×C
2、统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T
3、统计出平均每个用户发出的请求数量
R=u*C*T/VU
4、根据公式计算出思考时间
TS=T/R
软件性能的影响因素
（1）硬件设施（部署结构、机器配置）
（2）网络环境（客户端带宽、服务器端带宽）
（3）操作系统（类型、版本、参数配置）
（4）中间件（类型、版本、参数配置）
（5）应用程序（性能）
（6）并发用户数（系统当前访问状态）
（7）客户端
（8）数据服务器
（9）编程语言、程序实现方式、算法
软件性能的关注点
首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。
对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。
用户关注的是用户操作的响应时间。
其次，我们站在管理员的角度考虑需要关注的性能点。
1、 响应时间
2、 服务器资源使用情况是否合理
3、 应用服务器和数据库资源使用是否合理
4、 系统能否实现扩展
5、 系统最多支持多少用户访问、系统最大业务处理量是多少
6、 系统性能可能存在的瓶颈在哪里
7、 更换那些设备可以提高性能
8、 系统能否支持7×24小时的业务访问
再次，站在开发（设计）人员角度去考虑。
1、 架构设计是否合理
2、 数据库设计是否合理
3、 代码是否存在性能方面的问题
4、 系统中是否有不合理的内存使用方式
5、 系统中是否存在不合理的线程同步方式
6、 系统中是否存在不合理的资源竞争
那么站在性能测试工程师的角度，我们要关注什么呢？ 一句话，我们要关注以上所有的性能点。
性能测试的核心原理
性能测试的核心原理，开发测试工具也是基于前两点：
1、基于协议（前端后端通信机制），基于界面（决定和前端交互），基于代码（后端）。
基于网络的分布式架构：基于网络协议去模拟用户发送请求；
2、多线程：模拟多线程操作，多人同时操作，模拟大负载量（功能测试在于用以测试功能）；
3、模拟真实场景：真实的网络环境，用户操作时间不确定性，操作不确定，得出的数据是准确的，场景不对，数据也不一定可用。
性能问题分析原则
性能测试原则
1）情况许可时，应使用几种测试工具或手段分别独立进行测试，并将结果相互印证，避免单一工具或测试手段自身缺陷影响结果的准确性；
2）对于不同的系统，性能关注点是有所区别的，应该具体问题具体分析；
3）查找瓶颈的过程应由易到难逐步排查：
服务器硬件瓶颈及网络瓶颈（局域网环境下可以不考虑网络因素）
应用服务器及中间件操作系统瓶颈（数据库、WEB服务器等参数配置）
应用业务瓶颈（SQL语句、数据库设计、业务逻辑、算法、数据等）
4）性能调优过程中不宜对系统的各种参数进行随意的改动，应该以用户配置手册中相关参数设置为基础，逐步根据实际现场环境进行优化，一次只对某个领域进行性能调优（例如对CPU的使用情况进行分析），并且每次只改动一个设置，避免相关因素互相干扰；
5）调优过程中应仔细进行记录，保留每一步的操作内容及结果，以便比较分析；
6）性能调优是一个经验性的工作，需要多思考、分析、交流和积累；
7）了解“有限的资源，无限的需求”；
8）尽可能在开始前明确调优工作的终止标准。
性能测试的注意要点
性能调优应该注意的要点
性能测试流程
采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。
一、性能测试需求分析
性能需求分析是整个性能测试工作开展的基础，如果连性能的需求都没弄清楚，后面的性能测试执行其实是没有任何意义的，而且性能需求分析做的好不好直接影响到性能测试的结果。
一些性能测试人员常犯的错误就是测试一开始就直接用工具对系统进行加压，没有弄清楚性能测试的目的，稀里糊涂做完了以后也不知道结果是否满足性能需求。市面上的书籍也大都是直接讲性能测试工具如LR，jmeter如何使用，导致很多新手一提到性能测试就直接拿工具来进行录制回放，使得很多人认为会使用性能测试工具就等于会性能测试了，殊不知工具其实只是性能测试过程中很小的一部分。
在需求分析阶段，测试人员需要与项目相关的人员进行沟通，收集各种项目资料，对系统进行分析，建立性能测试数据模型，并将其转化为可衡量的具体性能指标，确认测试的目标。所以性能测试需求分析过程是繁杂的，需要测试人员有深厚的性能理论知识，除此之外还需要懂一些数学建模的知识来帮助我们建立性能测试模型。
首先，让我们来看看通过性能需求分析我们需要得出哪些结论或目标：
- 明确倒底要不要做性能测试？性能测试的目的是什么？
- 明确被测系统是什么？被测试系统的相关技术信息如：架构、平台、协议等
- 明确被测系统的基本业务、关键业务，用户行为
- 明确性能测试点是什么？哪些需要测，为什么？哪些不需要测，又是为什么？
- 明确被测系统未来的业务拓展规划以及性能需求？
- 明确性能测试策略，即应该怎么测试？
- 明确性能测试的指标，知道测试出来的结果怎么算通过？
其次，需求分析阶段我们可以从以下几个方面入手：
1、系统信息调研：
指对被测试系统进行分析，需要对其有全面的了解和认识，这是我们做好性能测试的前提，而且在后续进行性能分析和调优时将会大有用处，试想如果连系统的架构、协议都不了解，我们如何进行准确的性能测试？如果进行性能分析与调优？
需要分析的系统信息如下（包括但不仅限于如下这些）：
2、业务信息调研：
指对被测试的业务进行分析，通过对业务的分析和了解，方便我们后续进行性能测试场景的确定以及性能测试指标的确定。
需要分析的业务信息如下（包括但不仅限于如下这些）：
3、性能需求评估：
在实施性能测试之前，我们需要对被测系统做相应的评估，主要目的是明确是否需要做性能测试。如果确定需要做性能测试，需要进一步确立性能测试点和指标，明确该测什么、性能指标是多少，测试通过or不通过的标准？性能指标也会根据情况评估，要求被测系统能满足将来一定时间段的业务压力。
判断是否进行性能测试主要从下面两个方面进行思考：
- 业务角度:
系统是公司内部 or 对外？系统使用的人数的多少？如果一个系统上线后基本没几个人使用，无论系统多大，设计多么复杂，并发性的性能测试都是没必要的，前期可以否决。当然，除非在功能测试阶段发现非常明显的性能问题，使得用户体验较差的，此时可进行性能测试来排查问题。
- 系统角度：系统又可以从以下3个方面进行分析
a）系统架构：
如果一个系统采用的框架是老的系统框架（通常大公司都有自己的统一框架），只是在此框架上增加一些应用，其实是没有必要做性能测试，因为老框架的使用肯定是经过了验证的。如果一个系统采用的是一种新的框架，可以考虑做性能测试。
b）数据库要求：
很多情况下，性能测试是大数据量的并发访问、修改数据库，而瓶颈在于连接数据库池的数量，而非数据库本身的负载、吞吐能力。这时，可以结合DBA的建议，来决定是否来做性能测试。
c）系统特殊要求：
从实时性角度来分析，某些系统对响应时间要求比较，比如证券系统，系统的快慢直接影响客户的收益，这种情况就有作并发测试的必要，在大并发量的场景下，查看这个功能的响应时间。
从大数据量上传下载角度分析，某些系统经常需要进行较大数据量的上传和下载操作，虽然此种操作使用的人数不会太多，但是也有必要进行性能测试，确定系统能处理的最大容量，如果超过这个容量时系统需要进行相关控制，避免由于不人工误操作导致系统内存溢出或崩溃。
4、确定性能测试点：
在上面第3点中，我们简单分析了如何确定一个系统是否需要做性能测试。下面简单总结下如果一个系统确定要做性能测试，我们如何确定被测系统的性能测试点？
我们可以从下面几个方面进行分析：
- 关键业务：
确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如转账，扣款等接口。如果项目（或功能点）不属于关键业务（或关键业务点），则可转入下面。
- 日请求量：
确定被测项目各功能点的日请求量（可以统计不同时间粒度下的请求量如：小时，日，周，月）。如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试，而且关键业务点，可以被确定为性能点。
- 逻辑复杂度：
判定被测项目各功能点的逻辑复杂度。如果一个主要业务的日请求量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式方式的调用中，当某一个环节响应较慢，就会影响到其它环节，造成雪崩效应。
- 运营推广活动：
根据运营的推广计划来判定待测系统未来的压力。未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用。例如，运营计划做活动，要求系统每天能支撑多少 PV、多少 UV，或者一个季度后，需要能支撑多大的访问量等等数据。当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要做性能测试。
以上 4 点，是相辅相成、环环相扣的。在实际工作中应该具体问题具体分析。例如，当一个功能点不满足以上 4 点，但又属于资源高消耗（内存、CPU），也可列入性能测试点行列。
注：
PV：访问一个URL，产生一个PV（Page View，页面访问量），每日每个网站的总PV量是形容一个 网站规模的重要指标。
UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Visitor，用户访问）
5、确定性能指标：
性能需求分析一个很重要的目标就是需要确定后期性能分析用的性能指标，性能指标有很多，可以根据具体项目选取和设定，而具体的指标值则需要根据业务特点进行设定，本文不详细进行阐述，后续可考虑就此单独写一篇。
二、性能测试准备
1、测试环境准备：（见：四：测试脚本设计与开发）
a）系统运行环境：这个通常就是我们的测试环境，有些时候需求比较多，做性能测试担心把环境搞跨了影响其它的功能测试，可能需要重新搭建一套专门用来做性能测试的环境。
b）执行机环境：这个就是用来生成负载的执行机，通常需要在物理机上运行，而物理机又是稀缺资源，所以我们每次做性能测试都需要提前准备好执行机环境。
2、测试场景设计：（见：四：测试脚本设计与开发）
根据性能需求分析来设计符合用户使用习惯的场景，场景设计的好不好直接影响到性能测试的效果。
3、性能工具准备：
a）负载工具：根据需求分析和系统特点选择合适的负载工具，比如LR、Jmeter或galting等
b）监控工具：准备性能测试时的服务器资源、JVM、数据库监控工具，以便进行后续的性能测试分析与调优。
4、测试脚本准备：如果性能测试工具不能满足被测系统的要求或只能满足部分要求时，需要我们自己开发脚本配合工具进行性能测试。
5、测试数据准备：
a）负载测试数据：并发测试时需要多少数据？比如登录场景？
b）DB数据量大小：为了尽量符合生产场景，需要模拟线上大量数据情况，那么要往数据库里提前插入一定的数据量。这可能需要花费一些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表。
6、性能测试团队组建：如果需要其它关联系统或专业人士如DBA配合的，也需要提前进行沟通。
三、性能测试计划
测试计划阶段最重要的是分析用户场景，确定系统性能目标。
1、性能测试领域分析
根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者，哪些系统因素导致系统无法跟上业务发展？确定测试领域，然后具体问题具体分析。
2、用户场景剖析和业务建模
根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，整理一个业务场景表，当然其中最好对用户操作场景、步骤进行详细的描述，为测试脚本开发提供依据。
3、确定性能目标
前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指标）；其中需要和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据，确定最终我们需要达到的响应时间和系统资源使用率等目标；比如：
①登录请求到登录成功的页面响应时间不能超过2秒；
②报表审核提交的页面响应时间不能超过5秒；
③文件的上传、下载页面响应时间不超过8秒；
④服务器的CPU平均使用率小于70%，内存使用率小于75%；
⑤ 各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；
web性能测试之响应时间
4、制定测试计划的实施时间
预设本次性能测试各子模块的起止时间，产出，参与人员等等。
（1）明确测试范围
（2）制订时间（进度）计划
（3）制订成本计划
（4）制订环境计划
（5）测试工具规划
（6）测试风险分析
四、测试脚本设计与开发
性能测试中，测试脚本设计与开发占据了很大的时间比测试重。
1、测试环境设计
本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，
在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）。
这里所说的配置大概是如下几类：
①数据库服务器
②应用服务器
③负载模拟器
④软件运行环境，平台测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景，数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入，写入几条，需要多少的测试数据来使得测试环境的数据保持一致性等等。
可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据，保持一致性。
2、测试场景设计
通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量，操作次数，确定测试指标，以及性能监控等。
3、测试用例设计
确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述，用例大概内容如下：
用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）
用例条件：用户已登录、具有对应权限等。。。
操作步骤：
①进入对应页面。。。。。。
②查询相关数据。。。。。。
③勾选导出数据。。。。。。
④修改上传数据。。。。。。
PS：这里的操作步骤只是个例子，具体以系统业务场景描述；
4、脚本和辅助工具的开发及使用
按照用例描述，可利用工具进行录制，然后在录制的脚本中进行修改；比如参数化、关联、检查点等等，最后的结果使得测试脚本可用，能达到测试要求即可；
PS：个人而言，建议尽量自己写脚本来实现业务操作场景，这样对个人技能提升较大；一句话：能写就绝不录制！！！
五、性能测试执行
在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试用例脚本，部署环境，执行测试并记录结果即可。
1、人工边执行边分析
通常我们做性能测试都是人工执行并随时观察系统运行的情况、资源的使用率等指标。性能测试的吸引力之一就在于它的不可预知性。当我们在做性能测试的时候，遇到跟预期不符的情况很正常，这个时候需要冷静的分析。但这个过程可能会很漫长，需要不断的调整系统配置或程序代码来定位问题，耗时耗人力。特别是在当前敏捷开发模式比较流行的大环境下，版本发布非常频繁且版本周期短（通常1~2周一个版本），没有那么长的时间来做性能测试。
2、无人值守执行性能测试
无人值守是最理想化的目标，目前我们也朝着这个方向努力。无人值守不是说没有人力介入，而是把人为的分析和执行过程分离，执行过程只是机器服从指令的运行而已。通常测试环境在白天比较繁忙，出现性能问题及定位难度较大且会影响功能测试。所以一般性能测试最好在晚上或周末进行，在相对较安静的条件有利于测试结果的稳定性。这种方法也相对比较适合敏捷的模式，不需要人工一直守着。只需要在拿到结果后进行分析就好了。同时，这种方式对测试人员能力的要求比较高，需要我们能进行自动化的收集各种监控数据、生成报表便于后续分析。
六、结果分析与调优
1、测试环境的系统性能分析
根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。
2、硬件设备对系统性能表现的影响分析
由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。
3、其他影响因素分析
影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据2\5\8原则对其进行分析；
至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。
4、测试中发现的问题
在性能测试执行过程中，可能会发现某些功能上的不足或存在的缺陷，以及需要优化的地方，这也是执行多次测试的优点。
1.性能分析方法分类：
（1）指标达成法：用于验证性能指标
（2）最优化分析法：用于能力验证型测试
2.常用性能分析方法：
（1）快速瓶颈识别：
①硬件上的性能瓶颈 ②应用软件上的性能瓶颈 ③应用程序上的性能瓶颈
④操作系统上的性能瓶颈 ⑤网络设备上的性能瓶颈
（2）性能下降曲线：单用户区域、性能平坦区、压力区域、性能拐点
（3）内存分析方法 （4）处理器分析方法 （5）磁盘IO分析方法 （6）进程分析方法 （7）网络分析方法
七、测试报告与总结
性能测试报告是性能测试的里程碑，通过报告能展示出性能测试的最终成果，展示系统性能是否符合需求，是否有性能隐患。性能测试报告中需要阐明性能测试目标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优说明、性能测试过程中遇到的问题和解决办法等。
性能测试工程师完成该次性能测试后，需要将测试结果进行备案，并作为下次性能测试的基线标准，具体包括性能测试结果数据、性能测试瓶颈和调优方案等。同时需要将测试过程中遇到的问题，包括代码瓶颈、配置项问题、数据问题和沟通问题，以及解决办法或解决方案，进行知识沉淀
性能测试的实施过程
客户端性能测试
应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。
并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。
网络端性能测试
应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。
网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。
网络应用性能监控
在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。
网络预测
考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。
从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。
服务器端性能测试
对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控，测试原理如下图。
UNIX资源监控指标和描述
监控指标 描述
平均负载 系统正常状态下，最后60秒同步进程的平均个数
冲突率 在以太网上监测到的每秒冲突数
进程/线程交换率 进程和线程之间每秒交换次数
CPU利用率 CPU占用率（%）
磁盘交换率 磁盘交换速率
接收包错误率 接收以太网数据包时每秒错误数
包输入率 每秒输入的以太网数据包数目
中断速率 CPU每秒处理的中断数
输出包错误率 发送以太网数据包时每秒错误数
包输入率 每秒输出的以太网数据包数目
读入内存页速率 物理内存中每秒读入内存页的数目
写出内存页速率 每秒从物理内存中写到页文件中的内存页数
目或者从物理内存中删掉的内存页数目
内存页交换速率 每秒写入内存页和从物理内存中读出页的个数
进程入交换率 交换区输入的进程数目
进程出交换率 交换区输出的进程数目
系统CPU利用率 系统的CPU占用率（%）
用户CPU利用率 用户模式下的CPU占用率（%）
磁盘阻塞 磁盘每秒阻塞的字节数
分析优化性能思路流程
性能测试总结
1、硬件上的性能瓶颈：
一般指的是CPU、内存、磁盘读写等的瓶颈，为服务器硬件瓶颈。
2、应用软件上的性能瓶颈：
一般指的是服务器操作系统瓶颈（参数配置）、数据库瓶颈（参数配置）、web服务器瓶颈（参数配置）、中间件瓶颈（参数配置）等
3、应用程序上的性能瓶颈：
一般指的是开发人员，开发出来的应用程序（如sql语句、数据库设计、业务逻辑、算法等）。
4、操作系统上的性能瓶颈：
一般指的是Windows、linux等操作系统，如出现物理内存不足时，或虚拟内存设置不合理（虚拟内存设置不合理，会导致虚拟内存的交换率大大降低，从而导致行为的响应时间大大增加，可以认为在操作系统上出现了性能瓶颈）。
5、网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。
2.安全测试
安全测试是一个相对独立的领域，需要更多的专业知识。如：WEB的安全测试、需要熟悉各种网络协议、防火墙、CDN、熟悉各种操作系统的漏洞、熟悉路由器等。
采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ）
安全测试主要是根据对应的项目来进行的安全测试用例设计及编写后执行安全测试。比如主要是对用户登录的校验、密码是否加密、权限；设计充值、提现等必须是否绑定手机号的短信验证码校验等；需要实名认证的，甚至人脸识别技术等；做压力测试的时候，比如需要考虑同一个IP地址的请求过多或频繁，需要有对应的判断是否为恶意攻击及判断后的相应解决措施等。
3.兼容性测试
兼容性测试主要是指，软件之间能否很好的运作，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。
平台测试
浏览器测试
软件本身能否向前或向后兼容
测试软件能否与其它相关软件兼容
数据兼容性测试
最常见的兼容性测试就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页面显示不同。
常见的IE8的兼容性。
4.文档测试
国家有关计算机软件产品开发文件编制指南中共有14种文件，可分为3大类。
开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
用户文件：用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
在实际的测试中，最常见的就是用户文件的测试，例如：手册说明书等。
文档测试关注的点：
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性
5.易用性测试（用户体验测试）
易用性（Useability）是交互的适应性、功能性和有效性的集中体现。又叫用户体验测试。
6.业务测试
业务测试是指：测试人员将系统的整个模块串接起来运行、模拟真实用户实际的工作流程。满足用户需求定义的功能来进行测试的过程。
7.界面测试
界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
8.安装与卸载测试
安装测试是指：测试程序的安装、卸载。最典型的就是APP的安装、卸载。
9.内存泄漏测试
内存泄漏的检测：
1、对于不同的程序可以使用不同的方法来进行内存泄露的检查，还可以使用一些专门的工具来进行内存问题的检查，例如MemProof. AQTime、Purify、BundsChecker等。 有些开发工具本身就带有内存问题检查机制．要确保程序员在编写程序和编译程序的时候打开这些功能。
2、通过代码扫描分析工具来检查