性能测试系列（1）-性能测试基本概念

学习前的认知

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

思维需要转变

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

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

• 因为性能测试的步骤跟自动化、功能测试的步骤不一样，比如说前期的准备（了解系统，环境搭建），后期的压力测试（7*24h）等等

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

• 性能测试是模拟系统在被很多很多用户同时使用时，系统能不能正常使用和提供服务
• 有很多很多的用户
• 性能测试：用手工的话，可以模拟几个、十几个用户，但是当需要模拟上千万个用户时，手工又怎么模拟数据量多的场景呢？

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

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

结论

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

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

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

有哪些性能指标？

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

性能测试中发现的BUG

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

关于这个的小结

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

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

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

什么是性能测试

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

假设当前有一个业务

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

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

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

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

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

 

性能测试广义理解

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

“官方”解释

以下含义来源于高楼大佬的解释

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

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

注意

• 性能测试不像自动化测试那样很多东西大家都是公认的，性能测试没有一套标准的知识体系，只能说是相似的
• 每个人都有自己的一套知识体系，不用纠结哪个人对性能测试概念的解释是准确的
• 只要你能建立起自己的性能知识体系，那么你就可以完成性能测试

目前博主正在学习性能知识，希望通过通俗简单的术语来学懂性能测试，打造属于自己的知识体系，欢迎大家与我沟通（微信：John-xinghua）

什么是负载测试？

概念

• 逐步增加系统负载，测试系统性能变化，并最终确定系统所能承受的最大负载量

如何增加负载

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

实际场景

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

什么是压力测试？

概念

• 在较大的性能压力下，持续运行一个比较长的时间，看看系统服务是否正常及系统资源的利用率情况
• 通俗理解：鸭梨山大！
• 关键字：较大压力 + 较长时间
• 注意：不是满负荷压力哦

举例说明

【问】：大家什么时候会觉得工作压力大？

【答】：996、007；因为你不会觉得955压力山大吧

【结论】：所以在我们日常工作中，长时间工作强度高，才会觉得压力大；如果你一周就加班一小时也说压力大...（那就别干这一行了）

压力测试是干嘛的

• 测试系统的稳定性（简单举例：工作压力大，你还能坚持下去（那稳定性肯定好吧），那如果你很快就离职了（那稳定性肯定差，都宕机罢工了）
• 说明了性能承受的压力越大，稳定性越好

【什么时候会去做压力测试】

• 生产环境下，系统隔三差五的出现不稳定（不稳定：隔三差五服务异常，响应错误，响应时间超时等）的情况
• 这个时候，就需要通过压力测试去测试系统的稳定性情况

【如何取压力值】

• 在负载测试中，我们确认了系统所能承受的最大负载量
• 压力值 < 最大负载量，一般取80%左右

 

有意思的问题

• 负载测试一般时间比较短，压力测试时间比较长，持续运行时间短就能正常使用，但持续运行时间长就可能崩掉了，这是什么原因呢？

场景类比

• 举例一：电脑保持开机状态很长时间，会逐渐变卡，因为内存的东西会越来越多，得不到有效的回收， 就会越来越卡
• 举例二：当你经常工作压力很大，且你的心理所能承受的压力逐渐达到最大值时，你就可能会选择离职
• 这些都是压力测试太久（本来就是较大压力+较长时间了，本来说通知加班1个月的，然后又通知说要加班2个月）
• 总结：压力测试长时间运行，可能会逐渐增加系统的内存占用空间，若得不到有效的内存回收，当达到内存最大值时，系统就会崩掉

压力测试持续运行时间要多久

• 标准性能测试里面，一般是7*24小时，或者是它的倍数
• 但是实际工作中，并不会这么久，否则成本太高
• 所以会以小时为单位，比如：4个小时、8个小时...一般晚上下班之后做，第二天早上上班看结果

先做负载测试还是先做压力测试

• 先负载测试
• 负载测试可以找到服务器性能瓶颈的范围值，若生产环境中系统稳定性较差，再做压力测试
• 所以压力测试是可做可不做的

什么是可靠性测试

• 在给定的一定的业务压力下，持续运行一段时间，查看系统是否稳定
• 关键字：是否稳定，一定业务压力
• 注意：不是较大压力哦

举例：

电商秒杀场景，几十个商品几十万个人同时秒杀抢购

 

如何理解可靠性测试

1. 编写性能脚本：假设一秒内有一万个人同时发起请求
2. 有压力吗？有，一万个人同时发起请求
3. 但是持续时间短，不像压力测试一样需要持续一段时间
4. 目的是为了验证当这么多人同时发起请求时，成功秒杀的用户能否继续完成后续下单付款等操作【一定业务压力下，系统是否稳定运行】

 

什么是容量测试

概念

• 在一定的软、硬件条件下，在数据库不同数据量级数据量的情况下，对系统中读/写比较多的业务进行测试，从而获得不同数据量级下的性能指标值
• 关键字：不同数据量级

数据库数据量对性能测试结果有没有影响

肯定是有的

• 比如数据库已经有几百条数据和几百万条数据，查询的速度肯定不一样，所以肯定会影响性能测试结果
• 数据量级的差异，会影响TPS、响应时间、网络等

举例说明： 

从一袋米中找一个绿豆，和一碗米中找一个绿豆，找的时间肯定是千差万别的