大话性能测试之性能测试的基本概念
编者按：本文来自微信公众号“软件测试培训”（ID:iTestTrain），作者：软件测试培训，36氪经授权发布。
顾老师新书《全栈软件测试工程师宝典》
https://item.m.jd.com/product/10023427978355.html
以前两本书的网上购买地址：
《软件测试技术实战设计、工具及管理》：
https://item.jd.com/34295655089.html
《基于Django的电子商务网站》：
https://item.jd.com/12082665.html
来源：http://www.51testing.com/
学习前的认知
我们在学习性能测试之前，需要有个新的认识：性能测试，不再是像功能测试一样单纯的找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开始做性能测试
第一阶段：做好性能测试，得到性能指标值。
第二阶段：假设性能比之前差，哪些性能指标值不满足预期值，就需要分析是哪里有问题。
广义理解
只要与服务器性能指标相关的测试都属于性能测试。
比如：响应时间、并发用户数、服务器处理能力、吞吐量等性能指标。
负载测试、压力测试、容量测试、可靠性测试都属于性能测试。
通常嘴巴上说的做性能测试就是广义的性能测试，它包括了很多内容，并不只是针对某一个测试类型。
“官方”解释
以下含义来源高老的解释，比较“官方”的术语。
性能测试针对系统的性能指标，建立性能测试模型。
制定性能测试方案。
制定监控策略。
在场景条件下执行性能场景。
分析判断性能瓶颈并调优。
最终得出性能结果来评估系统的性能指标是否满足既定值。
其实也算是一个简洁描述的性测试流程了。
注意
性能测试不像自动化测试那样很多东西大家都是公认的，性能测试没有一套标准的知识体系，只能说是相似的。
基本每个人都有自己的一套知识体系，就好像高老也会说他给性能测试的定义很大可能会被轰炸一样。
只要属于自己的知识体系建立起来了，那么就能助力你正确的完成性能测试。
不用太过纠结于哪个人对性能测试概念的解释是最准确的。
什么是负载测试？
概念
逐步增加系统负载，测试系统性能变化，并最终确定系统所能承受的最大负载量。
通俗理解：看看你几斤几两。
如何增加负载
通过增加“用户数”，就是常说的并发数。
场景类比
天平秤，称东西的时候，需要逐步加砝码，最终达到砝码和物品重量的平衡点，因为它不可能一下子就达到平衡点【好比不可能一下子找到系统能承受的最大负载量】。
称东西：业务场景
加砝码：逐步加压
达到平衡点：找到最大负载量
实际场景
有一个业务，增加到40个人的时候，服务器还能正常使用，没有异常。
当你增加到50个人的时候，服务器已经开始有异常了，那么就能确定40-50之间某个值就是系统所能承受的最大负载量【出现性能拐点，找到了服务器性能瓶颈的范围值】。
最后减小加压梯度（比如：从40个人开始每次增加1个人、2个人），确认最大负载量【确认性能拐点】。
服务器又有哪些可能会出现的异常呢
响应时间超长：正常服务器处理请求时间是1s，但现在变成3s-5s。
服务报错：无法同时正常响应多个请求。
服务器宕机：系统完全用不了。
什么是压力测试？
概念
在较大的性能压力下，持续运行一个比较长的时间，看看系统服务是否正常及系统资源的利用率情况。
通俗理解：鸭梨山大！
关键字：较大压力+较长时间。
注意：不是满负荷压力哦。
场景类比
问：大家什么时候会觉得工作压力大？
答：996、007；因为你不会觉得955压力山大吧。
结论：所以在我们日常工作中，长时间工作强度高，才会觉得压力大；如果你一周就加班一天也说压力大...（那就别干这一行了）。
压力测试用来干嘛的
测试系统的稳定性
类比
工作压力大，你还能坚持下去（那稳定性肯定好吧），那如果你很快就离职了（那稳定性肯定差，都宕机罢工了）。
什么时候会做压力测试
生产环境下，系统隔三差五的出现不稳定的情况。
这个时候，就需要通过压力测试去测试系统的稳定性情况。
啥情况算不稳定？稳定性差？
隔三差五的出现下面的情况。
服务异常：响应错误、响应时间超时等。
服务器出现异常：宕机。
怎么分析是服务异常还是服务器异常
如果所有请求都是一片红，应用程序发送的所有请求都报红，就是服务器出现了异常。
如果有些请求偶尔成功响应，偶尔又失败，则是服务异常，出现不稳定的情况。
如何取压力值
在负载测试中，我们确认了系统所能承受的最大负载量。
压力值<最大负载量，一般取80%左右。
灵魂拷问
负载测试一般时间比较短，压力测试时间比较长，持续运行时间短就能正常使用，但持续运行时间长就可能崩掉了，这是什么原因呢？
场景类比
栗子一：电脑保持开机状态很长时间，会逐渐变卡，因为内存的东西会越来越多，得不到有效的回收，就会越来越卡。
栗子二：当你经常工作压力很大，且你的心理所能承受的压力逐渐达到最大值时，你就可能会选择离职。
总结
压力测试长时间运行，可能会逐渐增加系统的内存占用空间，若得不到有效的内存回收，当达到内存最大值时，系统就会崩掉。
压力测试持续运行时间要多久？
标准性能测试里面，一般是7*24小时，或者是它的倍数。
但是实际工作中，并不会这么久，否则成本太高。
所以会以小时为单位，比如：4个小时、8个小时...晚上下班之后做，第二天早上上班看结果。
先负载测试还是压力测试？
先负载测试，负载测试可以找到服务器性能瓶颈的范围值，若生产环境中系统稳定性较差，再做压力测试。
所以压力测试是可做可不做的。
什么是可靠性测试？
概念
在给定的一定的业务压力下，持续运行一段时间，查看系统是否稳定。
关键字：是否稳定，一定业务压力。
注意：不是较大压力哦。
业务场景栗子
电商秒杀场景，几十个商品几十万个人同时秒杀抢购。
如何理解可靠性测试
编写性能脚本：假设一秒内有一万个人同时发起请求。
有压力吗？有，一万个人同时发起请求。
但是持续时间短，不像压力测试一样需要持续一段时间。
目的是为了验证当这么多人同时发起请求时，成功秒杀的用户能否继续完成后续下单付款等操作【一定业务压力下，系统是否稳定运行】。
什么是容量测试？
概念
在一定的软、硬件条件下，在数据库不同数据量级数据量的情况下，对系统中读/写比较多的业务进行测试，从而获得不同数据量级下的性能指标值。
关键字：不同数据量级。
数据库数据量对性能测试结果有没有影响？
肯定有
比如数据库已经有几百条数据和几百万条数据，查询的速度肯定不一样，所以肯定会影响性能测试结果。
数据量级的差异，会影响TPS、响应时间、网络等。
场景类比
从一袋米中找一个绿豆，和一碗米中找一个绿豆，找的时间肯定是千差万别的。
顾老师专注企业内训和线下公开课，有兴趣者加顾老师微信xianggu0625
——————————————————————————————————
顾老师课程欢迎报名
软件安全测试
https://study.163.com/course/courseMain.htm?courseId=1209779852&share=2&shareId=480000002205486
接口自动化测试
https://study.163.com/course/courseMain.htm?courseId=1209794815&share=2&shareId=480000002205486
DevOps 和Jenkins之DevOps
https://study.163.com/course/courseMain.htm?courseId=1209817844&share=2&shareId=480000002205486
DevOps与Jenkins 2.0之Jenkins
https://study.163.com/course/courseMain.htm?courseId=1209819843&share=2&shareId=480000002205486
Selenium自动化测试
https://study.163.com/course/courseMain.htm?courseId=1209835807&share=2&shareId=480000002205486
性能测试第1季:性能测试基础知识
https://study.163.com/course/courseMain.htm?courseId=1209852815&share=2&shareId=480000002205486
性能测试第2季:LoadRunner12使用
https://study.163.com/course/courseMain.htm?courseId=1209980013&share=2&shareId=480000002205486
性能测试第3季:JMeter工具使用
https://study.163.com/course/courseMain.htm?courseId=1209903814&share=2&shareId=480000002205486
性能测试第4季:监控与调优
https://study.163.com/course/courseMain.htm?courseId=1209959801&share=2&shareId=480000002205486
Django入门
https://study.163.com/course/courseMain.htm?courseId=1210020806&share=2&shareId=480000002205486
啄木鸟顾老师漫谈软件测试
https://study.163.com/course/courseMain.htm?courseId=1209958326&share=2&shareId=480000002205486
