性能测试的基本概念

学习前的认知

我们在学习性能测试之前，需要有个新的认识：性能测试，不再是像功能测试一样单纯的找 Bug，而是去找性能指标

转变思维

在做功能测试、自动化测试的时候，我们基本都是依托界面进行测试，也称 GUI 测试，我们的目的就是为了跑通功能、程序，并成功找到 Bug
但在做性能测试的时候，我们大部分是 headless 模式（所谓的：无头，无界面模式），目的不再是单纯的为了找到 Bug，而是要分析性能指标等等（后续讲到）

性能测试的时间一般会比自动化、功能测试长，为啥？

因为性能测试的步骤跟自动化、功能测试的步骤不一样，比如说前期的准备（了解系统，环境搭建），后期的压力测试（7*24h）等等
在后面，我们通过讲述性能测试步骤来仔细了解

性能测试一定要工具，手工不行吗？

性能测试是模拟系统在被很多很多用户同时使用时，系统能不能正常使用和提供服务
重点： 很多很多用户
功能测试： 一个人点点点就知道功能通不通，有没有 Bug 了
性能测试： 用手工的话，可以模拟几个、十几个用户，但是当需要模拟上千万个用户时，手工又怎么模拟数据量多的场景呢？
类比，吃饭场景： 一个人可以吃好几碗，但是叫你吃几百碗是不可能的
结论： 工具就可以模拟大数据量的场景，可以做到人做不到的事情

大数据量测试是性能测试吗？

大数据量测试

简单理解：一个接口返回的数据比较多（假设：不使用分页，把所有数据同时返回）

结论

返回大数据量的接口的响应时间会变长
这么大的数据量，我们需要考虑：网络传输数据、服务器查询这些数据、服务器处理这些数据等等分别需要多少时间
这已经跟响应时间挂钩，所以已经属于性能测试的范围，但不归纳于性能分析范围

大数据测试是性能测试吗？

大数据测试的功能属于功能测试哦

性能测试过程发现问题需要立即提交吗？

在性能测试过程中发现一些问题，假设定位到某一段代码有问题，可以截图提交 Bug 给开发，但这并不是我们性能测试的最终目的，最终目的是找出性能指标

有哪些性能指标？

比如说响应时间：10个人、100个人、1000个人、10000个人向服务器发起请求，服务器响应请求的平均响应时间是多少，这就是一个指标
又好比TPS：服务器在当前的配置下，不同用户数发起请求，服务器的 TPS 处理能力是多少，这也是一个指标
后续详细介绍

性能测试中发现的 Bug

性能测试过程中发现的 Bug 属于一个衍生品，并不是最终得到的结果
但像功能测试，最终目的就是为了找出 Bug

关于这个问题的总结

做性能测试，当数据量变大后，会出现连接超时、连接拒绝、500、502等 异常问题；在性能测试中，这些异常问题基本都会出现的，但不会去立即提 Bug
对于性能测试工程师，我们要做的是分析为什么在当前数据量下会出现连接超时、连接拒绝，响应时间超时、服务器异常等异常问题
这就需要我们去分析性能瓶颈，并不会单独去看某个异常问题出现在哪里，而是分析为什么会出现这个异常问题，分析的是服务器或者是代码，而不是让开发人员马上来修复这些异常问题

我们常说的压测是指压力测试吗？

并不是，而是指负载测试，一般都是为了找出系统的最大负载量
就好像你老板说：你去压测下，看看系统能支撑多少用户同时访问我们的系统

什么是性能测试？

狭义理解

通过工具，找出或获得系统在不同工况下的性能指标值
性能测试过程中，重点是找出****性能指标，而不再是找出 Bug，
性能测试的产出绝对不只是 Bug

场景类比

跑步100米，用时多少？运动员的心跳、步伐频率是多少？

跑步100米：业务场景
用时多少：响应时间
运动员的心跳、步伐：性能指标值

性能指标值和响应时间是否满足当前业务场景的最低要求（合格线）

什么时候能找出性能指标值

假设当前有一个业务

电商系统，下单业务，目前还不知道系统支持多少人同时下单，那么我们需要找到服务器能正常支持多少人同时下单

性能测试初始阶段（第一次做）

先把基础的性能指标值找出来 （第一次性能测试也叫做基准测试）
比如：100个人同时下单系统正常，但120个人同时下单就会出现部分请求的响应时间超长，连接异常
那么100-120范围内的某个值就是当前服务器能达到的性能指标值 （基准值）

版本迭代，进行第二次做性能测试，重新跑一遍之前的性能脚本

又会得到一些性能指标值，对比上个版本的性能指标值，看是否有优化（性能变化）
假设这个时候120个人同时下单是正常的，150个人才有异常，那么接口已经有优化了

假设公司是从0开始做性能测试

第一阶段：做好性能测试，得到性能指标值
第二阶段：假设性能比之前差，哪些性能指标值不满足预期值，就需要分析是哪里有问题

广义理解

只要与服务器性能指标相关的测试都属于性能测试
比如：响应时间、并发用户数、服务器处理能力、吞吐量等性能指标
负载测试、压力测试、容量测试、可靠性测试都属于性能测试
通常嘴巴上说的做性能测试就是广义的性能测试，它包括了很多内容，并不只是针对某一个测试类型

“官方”解释

以下含义来源高老的解释，比较“官方”的术语

性能测试针对系统的性能指标，建立性能测试模型
制定性能测试方案
制定监控策略
在场景条件下执行性能场景
分析判断性能瓶颈并调优
最终得出性能结果来评估系统的性能指标是否满足既定值

其实也算是一个简洁描述的性测试流程了

注意

性能测试不像自动化测试那样很多东西大家都是公认的，性能测试没有一套标准的知识体系，只能说是相似的
基本每个人都有自己的一套知识体系，就好像高老也会说他给性能测试的定义很大可能会被轰炸一样
只要属于自己的知识体系建立起来了，那么就能助力你正确的完成性能测试
不用太过纠结于哪个人对性能测试概念的解释是最准确的

目前博主是正在学习性能测试的小白一枚，希望通过通俗简单的术语来学懂性能测试，打造属于自己的知识体系，欢迎大家进群与我沟通（870155189）

什么是负载测试？

概念

逐步增加系统负载，测试系统性能变化，并最终确定系统所能承受的最大负载量
通俗理解： 看看你几斤几两

如何增加负载

通过增加“用户数”，就是常说的并发数

场景类比

天平秤，称东西的时候，需要逐步加砝码，最终达到砝码和物品重量的平衡点，因为它不可能一下子就达到平衡点【好比不可能一下子找到系统能承受的最大负载量】

称东西：业务场景
加砝码：逐步加压
达到平衡点：找到最大负载量

实际场景

有一个业务，增加到40个人的时候，服务器还能正常使用，没有异常
当你增加到50个人的时候，服务器已经开始有异常了，那么就能确定40-50之间某个值就是系统所能承受的最大负载量 【出现性能拐点，找到了服务器性能瓶颈的范围值】
最后减小加压梯度（比如：从40个人开始每次增加1个人、2个人），确认最大负载量 【确认性能拐点】