按测试对象的⾓度划分：性能测试、安全测试、兼容性测试、⽂档测试、易⽤性测试（⽤户体验测试）。。。 性能测试
性能测试是通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏测试。负载测试和压⼒测试都属于性能测试，两者可以结合进⾏。通过负载测试，确定在各种⼯作负载下系统的性能，⽬标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压⼒测试是通过确定⼀个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最⼤服务级别的测试。 中国软件评测中⼼将性能测试概括为三个⽅⾯：应⽤在客户端上性能的测试、应⽤在⽹络上性能的测试和应⽤在服务器端上性能的测试。通常情况下，三⽅⾯有效、合理的结合，可以达到对系统性能全⾯的分析和瓶颈的预测。
定义
狭义的性能测试主要⽤于描述常规的性能测试，是指通过模拟⽣产运⾏的业务压⼒或⽤户使⽤场景来测试系统的性能是否满⾜⽣产性能的要求。
⼴义的性能测试则是压⼒测试、负载测试、强度测试、并发（⽤户）测试、⼤数据量测试、配置测试、
可靠性测试等和性能相关的测试统称。
基本策略
siro 1300
测试的基本策略是⾃动负载测试，通过在⼀台或⼏台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是⽐较关注的指标；
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议