性能测试：不再像功能测试一样单纯的找 Bug，而是去找性能指标。
转变思维：
在做功能测试、自动化测试时，我们基本都是依托界面进行测试，也称 GUI 测试，我们的目的就是为了跑通功能、程序，并成功找到 Bug。
但在做性能测试时，我们大部分是 headless 模式（所谓的：无头，无界面模式），目的不再是单纯的为了找到Bug，而是要分析性能指标等。
性能测试的时间一般会比自动化、功能测试长，为啥？
因为性能测试的步骤跟自动化、功能测试的步骤不一样，比如说前期的准备（了解系统，环境搭建），后期的压力测试（7*24）等等。
性能测试一定要工具，手工不行吗？
性能测试是模拟系统在被很多很多用户同时使用时，系统能不能正常使用和提供服务。
重点：很多很多用户
功能测试：一个人点点点就知道功能通不通，有没有 Bug 了
性能测试：用手工的话，可以模拟几个、十几个用户，但是当需要模拟成千上万个用户时，手工又怎么模拟数据量多的场景呢？
工具可以模拟大数据量的场景，可以做到人做不到的事情。
大数据量测试时性能测试吗？
大数据量测试
简单理解：一个接口返回的数据比较多（假设：不使用分页，把所有数据同时返回）
结论：
返回大数据量的接口的响应时间会变长
这么大的数据量，需要考虑：网络传输数据、服务器查询这些数据、服务器处理这些数据等等分别需要多少时间。
这已经跟响应时间挂钩，所以已经数据性能测试的范围，但不归纳于性能分析范围。
大数据测试是性能测试吗？
大数据测试的功能属于功能测试。
性能测试过程发现问题需要立即提交吗？
在性能测试过程中发现一些问题，假设定位到某一段代码有问题，可以截图提交 Bug 给开发，但这并不是性能测试的最终目的，最终目的是找出性能指标。
有哪些性能指标？
比如说响应时间：10个人，100个人，1000个人，10000个人向服务器发起请求，服务器响应请求的平均响应时间是多少
比如说 TPS：服务器在当前的配置下，不同用户数发起请求，服务器的 TPS 处理能力是多少
性能测试中发现的 Bug：
性能测试过程中发现的 Bug 属于一个衍生品，并不是最终得到的结果。
但像功能测试，最终目的就是为了找出 Bug。
总结：
做性能测试，当数据量变大后会出现连接超时、连接拒绝、500、502等异常问题；在性能测试中，这些异常问题基本都会出现的，但不会去立即提 Bug。
对于性能测试工程师，我们要做的是分析为什么在当前数据量下会出现连接超时、连接拒绝，响应时间超时、服务器异常等异常问题。
这就需要我们去分析性能瓶颈，并不会单独去看某个异常问题出现在哪里，而是分析为什么会出现这个异常问题，分析的服务器或者是代码，而不是让开发人员马上来修复这些异常问题。
我们常说的压测是指压力测试吗？
并不是，而是指负载测试，一般是为了找出系统的最大负载量。
举例：你去压测下，看看系统能支撑多少用户同时访问我们的系统。
什么是性能测试？
狭义理解：通过工具，找出或获得系统在不同工况下的性能指标。
性能测试过程中，重点是找出性能指标，而不再是找出 Bug。
性能测试的产出绝对不只是 Bug。
场景类比：
跑步 100 米用时多少？运动员心跳、步伐频率是多少？
1.跑步100米：业务场景
2.用时多少：响应时间
3.运动员的心跳、步伐：性能指标值
性能指标值和响应时间是否满足当前业务场景的最低要求（合格线）
什么时候能找出性能指标值
假设当前有一个业务：电商系统下单业务，目前还不知道系统支持多少人同时下单，那么我们需要找到服务器能正常支持多少人同时下单。
性能测试初始阶段（第一次做）：
先把基础的性能指标值找出来（第一次性能测试也叫基准测试）
比如：100个人同时下单系统正常，但120个人同时下单就会出现部分请求的响应时间超长，连接异常。
那么100-120范围内的某个值就是当前服务器能达到的性能指标值（基准值）。
版本迭代，进行第二次做性能测试，重新跑一遍之前的性能脚本
又会得到一些性能指标值，对比上个版本的性能指标值，看是否有优化（性能变化）。
假设这个时候120个人同时下单是正常的，150个人才有异常，那么接口已经有优化了。
假设公司是从 0 开始做性能测试
第一阶段：做好性能测试，得到性能指标值。
第二阶段：假设性能比之前差，哪些性能指标值不满足预期值，就需要分析是哪里有问题。
广义理解：
只要与服务器性能指标相关的测试都属于性能测试
比如：响应时间、并发用户数、服务器处理能力、吞吐量等性能指标。
负载测试、压力测试、容量测试、可靠性测试都属于性能测试。
通常嘴巴上说的做性能测试就是广义的性能测试，它包括了很多内容，并不只是针对某一个测试类型。
官方解释：
（1）性能测试针对系统的性能指标，建立性能测试模型。
（2）制定性能测试方案。
（3）制定监控策略。
（4）在场景条件下执行性能场景。
（5）分析判断性能瓶颈并调优。
（6）最终得出性能结果来评估系统的性能指标是否满足既定值。
什么是负载测试？
概念：
逐步增加系统负载，测试系统性能变化，并最终确定系统所能承受的最大负载量。
通俗理解：看看你几斤几两
如何增加负载：
通过增加“用户数”，就是常说的并发数
场景类比：
天平秤称东西时需要逐步增加砝码，最终达到砝码和物品重量的平衡点，因为它不可能一下子就达到平衡点【好比不可能一下子找到系统能承受的最大负载量】。
· 秤东西：业务场景
· 加砝码：逐步加压
· 达到平衡点：找到最大负载量
实际场景：
· 有一个业务，增加到40个人时，服务器还能正常使用，没有异常
· 当你增加到 50 个人时，服务器已经开始有异常了，那么就能确定 40-50 之间某个值就是系统所能承受的最大负载量。【出现性能拐点，找到了服务器性能瓶颈的范围值】
· 最后减小压梯度（比如：从40个人开始每次增加1个人、2个人），确认最大负载量。【确认性能拐点】
服务器又有哪些可能会出现的异常呢？
（1）响应时间超长：正常服务器处理请求时间是 1s，但现在变成 3s - 5s。
（2）服务报错：无法同时正常响应多个请求。
（3）服务器宕机：系统完全用不了
什么是压力测试？
概念：
在较大的性能压力下，持续运行一个比较长的时间，看看系统服务是否正常及系统资源的利用率情况。
通俗理解：压力山大
关键字：较大压力 + 较长时间
注意：不是满负荷压力
压力测试用来干嘛的：测试系统的稳定性
类比：工作压力大，你还能坚持下去（那稳定性肯定好吧），那如果你很快就离职了（那稳定性肯定差，都宕机罢工了）
什么情况下会做压力测试：
生产环境下，系统隔三差五的出现不稳定的情况。这个时候，就需要通过压力测试去测试系统的稳定情况。
啥情况算不稳定？稳定性差？
服务异常：响应错误、响应时间超时等。
服务器出现异常：宕机
怎么分析是服务异常还是服务器异常：
如果所有请求都是一片红，应用程序发送的所有请求都报红，就是服务器出现了异常。
如果有些请求偶尔成功响应，偶尔又失败，则是服务异常，出现不稳定的情况。
如何取压力值：
在负载测试中，我们确认了系统所能承受的最大负载量
压力值 < 最大负载量，一般取 80% 左右
灵魂拷问：
负载测试一般时间比较短，压力测试时间比较长，持续运行时间短就能正常使用，但持续运行时间长就可能崩掉了，这是什么原因呢？
场景类比：
例子一：电脑保持开机状态很长时间，会逐渐变卡，因为内存的东西会越来越多，得不到有效的回收就会越来越卡。
例子二：当你经常工作压力大，且你的心理所能承受的压力逐渐达到最大值时，你就可能会选择离职。
总结：压力测试长时间运行，可能会逐渐增加系统的内存占用空间，若得不到有效的内存回收，当达到内存最大值时，系统就会崩掉。
压力测试持续运行时间要多久？
标准性能测试里面，一般是 7 * 24 小时，或者是它的倍数，但是实际工作中并不会这么久，否则成本太高。所以会以小时为单位，比如：4小时、8小时...晚上下班后做，第二天上班看结果。
先负载测试还是压力测试？
先负载测试，负载测试可以找到服务器性能瓶颈的范围值，若生产环境中系统稳定性较差，再做压力测试。
什么是可靠性测试？
概念：
在给定的一定的业务压力下，持续运行一段时间，查看系统是否稳定。
关键字：是否稳定，一定业务压力
注意：不是较大压力
业务场景例子：
电商秒杀场景，几十个商品几十万人同时秒杀抢购
如何理解可靠性测试：
（1）编写性能脚本：假设一秒内有一万个人同时发起请求。
（2）有压力吗？有，一万人同时发起请求。
（3）但是持续时间短，不像压力测试一样需要持续一段时间。
（4）目的是为了验证当这么多人同时发起请求时，成功秒杀的用户能否继续完成后续下单付款等操作【一定业务压力下，系统是否稳定运行】
什么是容量测试？
概念：
在一定的软、硬件条件下，在数据库不同数据量级数据量的情况下，对系统中读 / 写比较多的业务进行测试，从而获得不同数据量级下的性能指标值。
关键字：不同数据量级
数据库数据量对性能测试结果有没有影响？
肯定有
比如数据库已经有几百条数据和几百万条数据，查询的速度肯定是不一样的，所以肯定会影响性能测试结果。
数据量级的差异，会影响 TPS、响应时间、网络等。
场景类比：
从一袋米中找到一个绿豆，和一碗米中找一个绿豆，找的时间肯定是千差万别的。
标签：性能,系统,Bug,测试,压力,服务器,基本概念 From： https://www.cnblogs.com/xianyumaixianyu/p/18294887