目录
第一课? 为什么要做性能测试？
0 前言
0.1 受众分析
很多学生多数都没有做过性能测试，或者很多人做的性能测试不规范，所以性能侧记着门课面临如下问题：
（1）一些性能测试术语理解起来困难
（2）作为其他课程的基础中的基础，没有太多可以动手的，有人是希望多动手的
（3）这门课程放在最开始，没有太多铺垫，和学生之间的交流存在一定的磨合
0.2 教学策略
1 为什么要做性能测试
1.1 我们身边的那些事儿
1.1.1 回家的路好长？
1.1.2 赵丽颖结婚了，我的女神有主了？
—需求分析不对，粉丝多 ！！！首选。方向不对，努力白费
—关键时刻并发大，系统负载高
—系统架构不具备扩大性，造成了崩溃宕机 ！！！其次。
强调要了解需求分析，了解业务，了解架构。
互联网应用和传统应用的差异？
互联网的应用是一个访问不受时间和地域限制。
传统应用则相反，更可控。
1.1.3 追某女生3年了，我们终于在一起了，嗨…
—这也是性能测试，追求过程中，女生有很多废物测试，不断测试男生的可靠性，整个追求时间跨度不断，可以类比性能测试中的稳定性测试，疲劳强度测试
1.1.4 安卓的手机越用越卡，我们还是买个苹果的吧…
—手机卡本质就是一个性能问题，存在内存碎片，这个状况是由安卓采用了的架构决定
1.2 五个理由
（1）选型
系统中采用了新技术或者新的架构，但新架构能满足业务需要吗？
如果等到系统开发完成后，再来验证成本就非常大，于是功能还没开发完成，就半路突击做性能测试。
（2）验收
（3）备份
举例：服务器部署在阿里云上，为了避免风险，在华为云上也部署一套。怎么做？
阿里云和华为云的功能性能上是否有差异？此时，不能直接切。
测试团队就会对华为云做测试评估：行和不行？
行，则可以切换。说明两者是可以相互备份的。
这里强调的不是备份这个动作，而是为了备份这件事，我们需要先做性能测试。
不是说备份就备份，不先做性能测试，不先了解清楚，怎么做备份呢？
冷备份和热备份：
冷备份需要重启，用户有感知
热备份，切换时，用户无感知
（4）省钱（指导运维成本）
（5）更好
即评估，优化，预测所对应的专业场景。
把上面5个理由理解成5个场景：
（1）选择
（2）验证属实
（3）异常处理
（4）容量规划
（5）优化
第二课? 性能测试实战案例（1）
1 两个问题
问题1: 负载和并发的区别？
所谓负载：不断加压力，观察在加压力的过程中，系统的表现。
所谓并发：做性能测试，根据先前的需求分析出来的结果做性能测试。
后面再说详细区别。
问题2: 先预习再上
2 性能测试发展过程
2.1 我是谁
早期：不会性能测试，先上产品，先抢用户，气候再紧急补债
现在：两级分化严重，专业的人做专的专业，不专业的人还在裸奔
裸奔的人什么样子呢？
没有明确的性能测试指标，没有测试需求，没有测试策略。
但这却又偏偏是性能测试，所以称之为尴尬的性能测试。
性能测试就是扔给你一个Loadrunner, 给你的url链接，然后再给你个性能测试报告的模版，最后告诉你，给你一个星期，或者说再xx号前把报告交给我。
很多性能测试工程师一拿到Loadrunner和url就开始性能测试的旅程。
但是没有明确的测试目标，没有测试策略，既然任务已经下来，就不管其他的，用这个万能的Loaderrunner.
脚本篇—懂一点儿Loadrunner的测试流程，于是就用它强大的录制功能，录制了基本急哦脚本。然后在脚本中参数化参数，插入事物，插入集合点等等增强脚本。在迭代几次回放后，没有报错，就算完成了。
场景片—脚本完成后，开始准备设置场景的参数。没有做任何的基准测试和铜梁测试，测试报告上要求多少用户，持续多长时间，就填上相应的参数。作为性能测试，总归要监控服务器的性能，一开始性能工程师是用头儿推荐的方法：用操作系统自带的性能工具来监控服务器的性能。理由是Loadrunner是装在测试机的，用测试机来监控服务器的数据，会存在网络上的延时而不准确。用了Loadrunner， 为什么不相信它？如果用系统自带的性能测试工具来监控，为什么不请100个民工一起点，或者这样的效果更好。。。这个想法，有点儿。。。
专业的人做什么事？
—需求分析：了解产品规格说明，用户计划，用户行为，用户分布，运维日志，市场计划，架构
—准备工作：写的脚本不管何时何地何人，不管多少人在跑，都能跑
—监控：表面看（TPS，响应时间…），深层看(CPU，内存)，长期看
—分析：从整体到局部，从表到里，做好分析，调优
课程要求：学完后，需求分析，脚本编写都要专业！
2.2 我要去哪里/发展方向
—功能测试是业务型的。性能测试是技术型的。技术无止境（编程，数据库，操作系统，中间件）
—自动化3个月能入门。性能测试的入门要比较久，掌握的内容，除了自动化内容之外，还有其他。
—性能测试的发展方向：
平民化（大众化）
开源化
专业化
3 什么是软件性能测试
3.1 性能测试概念
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
3.2 什么时候（阶段）做性能测试
—先前给予占领市场的公司产品线上，有一定用户后再考虑系统性能
—一些正规公司，功能测试稳定后再做性能测试
—但并不绝对，有的公司，架构复杂，人员能力强的，会在技术架构选型之前开始做性能测试。
有的公司，在功能测试之前，先做规划（需求分析），准备完成后，等功能测试完成后，做性能测试。
第三课? 性能测试实战案例（2）
4 软件性能测试分类（重点）
（1）基准测试： 先测一轮作为后面测试或者后面版本的基准
（2）性能测试：基于用户行为情况和用户分布等信息，对系统能否达到预期服务能力进行验证
（3）负载测试：日本不断挑战我们的底线，占领xx, 。。。我们一直在忍耐，直到77事变前（一个循序渐进的过程）
（4）压力测试：1937年77事变，忍无可忍，抗日战争全面爆发 （压倒骆驼的最后一根稻草）（极端情况）
（5）容量测试：我们能忍多少事，比如全面抗战前夕，我们对日本的挑衅行为的容量久就是，77事变没有发生前的所有事的总和。
系统会有很多配置参数，所有配置参数都放到最大的时候，是不是生效？系统是不是扛得住？它们之间是不是存在冲突？
（6）疲劳强度测试：结婚7年，牵着老婆的手就像左右牵着右手，牵着小姨的手。。。
（7）现网性能测试：在真实环境上做性能测试（为了得出真实的数据，这种类型测试要注意对网络性能的影响，比如占用过多的带宽，影响其他业务，垃圾数据的清理等）
在内网测试，我们关注的是服务器，系统软件，系统相关的各种配置等是否有问题。缺点是：我们没有评估系统所在的这个环境的带宽网络层面的限制，真实使用时会有问题。
所以我们先在内网测，然后要评估真实的带宽。于是我们会做一些现网性能测试。
（8）失效恢复测试：（这个比喻可能不太恰当：某明星出轨，女主进入局子，男主角带着原配住进了美国豪宅，这里原配扮演了故障转移的角色）
不过失效恢复测试一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。
在实际应用过程中，可以模拟一台或者几台负载均衡及其出现故障来进行失效恢复测试。但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用户，已经采用哪些备选方案来快速响应。（储库功能要大于主库）
问题：性能测试是不是包含负载测试和压力测试？
性能测试是一个通俗概念，下面有几个概念：
性能测试
负载测试
压力测试
第四课? 性能测试流程
1?性能测试包含哪些？（配图略）
（1）性能测试（重要）：期望点。a点，持续测试，验证系统资源是否在可接受范围内（自己定义的），是不是符合预期。
（2）负载测试（重要）：高于期望。a-b点，持续测试，验证压力增大后，系统的表现如何？（b点不固定，只要高于a点，任何一点都可以称为b点？）a点只有一个，b点有很多个。如果a点有很多个，那产品不明确。
（3）压力测试：临界点，系统资源吃紧。b-d 点，持续测试，验证系统超出自身能力后的表现。重点是要找到系统在不断加压的过程中，在什么时间点（并发量时）崩溃。
（4）稳定性测试（重要）：系统崩溃，超时等。 a-b点，验证系统n*24小时持续运行后的稳定性。强调时间维度，重点是验证系统持续提供服务的时间，稳定情况。
有时候会把稳定性测试和负载测试合二为一，为了省时间。业界比较少人只做负载测试。
对性能测试而已，最关注的是tps和相应时间。虚拟用户数没那么关注。
2?作业讲解
1）上述已讲
2）怎么考虑性能测试的典型场景？
—产品规格：产品经理提供
—用户模型：用户喜欢用什么功能，什么时间段用，大概有多少用户 （产品经理不太会说，需要我们自己分析）
—系统数据：基础数据（用户名密码地址信息等）和业务数据（买了什么东西花了多少钱等）
为什么需要考虑这些数据？
我们要访问的数据大多放在数据里了。性能测试过程中需要制造大量的数据，是要解决数据库当中数据量比较大时性能低的问题，数据太少的话，和数据库相关的性能问题根本就测不准确。
原则：准备数据时，宁多勿少
—系统架构：一个是逻辑结构，一个是 ？（即有哪些模块构成，在部署的时候分别部署在哪些系统上）
举例：比较粗的逻辑架构：Browser—Tomcat(nginx)—Redis—Mysql
不同硬件不同结构，会对性能有影响。要把架构做好，不然会在很多阶段有很多遗漏，或者影响性能。
—运维日志
—市场计划：
—项目管理计划：
Btw：-》测试需求-》设计出模型
第五课? 性能答疑
1. 负载测试时，有时服务器过大，测试过程没有测试出它的极限，上市后出现瘫痪，怎么解决？
测试环境搭建：
1）尽可能在线上测（全链路压测）
2）自己搭建环境测试
（1）线上服务器很多，不可能搭建完全真实的环境，此时采用等比缩放，测试出扩散系统
（2）能搭建出真实的环境测试，那就测试吧
2. 现网性能测试时在公网进行吧？
看应用，具体情况具体分析。要看服务器是给谁用，如果开发的应用程序只是给公司内部使用，则只需内网。如果给外部使用，则公网。
3. 基准测试，是不是每一轮版本都会作为下一轮的基础，还是稳定版本呢？
一般情况下只会把第一版本第一轮测的数据作为基准。
PS. 更多的是同一个大版本下的第一轮测试。
不同版本之间需要评估，版本跨度不能过大，不然没有意义。
4. 基准测试时有基准标准，不一定非要自己做一遍，也可以用行业标准作为基准。
这是对的。
如果你做的系统是业界已经有的系统，那就用业界标准；
如果你做的系统是业界最新，标准就是你们自己定的，这里的标准来源于几个方向：
1）产品说明——大家期望的结果
2）基准测试的结果——实际上的标准（当然大家要同意）
5. 例如行业usb2.0, usb3.0传输标准，5g传输标准这些都可以认为是基准。
有行业标准用行业标准，没有的话自己定。
具体情况具体分析。
6. 难道大多数公司做性能不一定都有会行业标准，可能还是探索阶段的吧。。。
具体情况具体分析。
更多的是同一个版本（的第一轮）作为基准，跨基准的话也可以，但是不能跨太远。比如版本2，版本3可以用版本1来做基准，但是版本10再用版本1来做基准，就不合适了。
很多系统已经有所谓的标准了，但实际情况，中小型公司很多执行不到位，有标准不一定用，所以需要我们推进这件事。
7. 疲劳度测试和稳定性测试区分一下。
疲劳测试：测试系统出现疲劳时候的点（可以是跑了多少时间，也可以是并发量等）
稳定测试：系统是否稳定，长时间运行时是否有内存泄漏
两者并没有太本质的区别，只是关注的点不一样。
8. 即便抛去现网测试因素，在内网下如何判断出接近真实的数据量（用户量，真实配置量等）
性能需求分析重要解决的问题：
需要记住：在互联网应用中，一个服务降级，另一个自动扩容。（！！！非常重要）
100人 ——— 1台服务器
200人 ——— 监控检查到有更大的压力过来了 ———又启动2台服务器
1000人 ——— 监控检查到有更大的压力过来了 ———又启动10台服务器
性能需求分析非常重要。方向不对，努力白费。
性能需求分析即使做了之后，还是会出现问题，说明在服务降级或者自动扩容这些方面存在一些问题。
服务降级是什么？
系统比较繁忙时，停掉一些不常用的服务。
80%的用户，支持20%的功能。
9. 内网下的性能测试数据量，标准时如何来的呢？
性能需求分析重要解决的问题：
如果你做的系统是业界已经有的系统，那就用业界标准；
如果你做的系统是业界最新，标准就是你们自己定的，这里的标准来源于几个方向：
1）产品说明——大家期望的结果
2）基准测试的结果——实际上的标准（当然大家要同意）
10. 这些每一种类型的测试后面都有实战吗？
不完全有。
11. 其实我在想淘宝的那种现网性能测试他们是怎么测的？
全链路压测：
存在几个问题：担心线上用户，担心数据污染线上数据库，应用比较复杂时协调各部门比较复杂。
淘宝之类的，能解决上述问题，所以他们能进行线上压测。
12. 我想知道基准测试，什么时候做，做几次？
第一个版本第一轮。测第一轮的时候可能测好几次。
比如，产品要求TPS100, 相应时间在1秒内：
实际测试结果TPS90, 相应时间1秒。测多次后，定一个基准。
一般是在大面积做性能测试之前，先做一下基准测试。
13. 全链路压测是什么意思？
14. 什么是失效恢复测试？
15. 当一个接口，根据数据不同，会走不同的分支，逻辑不同，然后性能跑出来的基线都不一样，怎么测性能？
答：关键（起点）—> 性能需区分分析 —> 各种准备（数据准备） —> 这个问题不存在了
16. 项目中介入第三方支付，需要用户绑卡和授权支付，这种场景下的性能如何测试？支付过程中需要使用的数据都是正实的，第三方支付对支付笔数和金额是有限制的，这种场景的测试数据如何设计？
答：1） mock。 2）模拟数据 。3）导入真实数据，脱敏等等
17. 如何学习软件性能测试
17.1 L0需要掌握的知识技能
1）需求分析只是：用户分析性能测试需求
2）测试分析设计能力：（不具备该能力，功能测试都做不好），用于设计压测方案
3）一定的代码能力（Java，python）：用户编写性能测试脚本
4）Linux知识：环境搭建，监控工具部署等
5）数据库知识：oracle或者 mysql
6）网络知识：如http协议
7）工具使用：loadrunner等
8）中间件知识：tomcat, nginx等
9）文档编写能力：测试报告编写
17.2 如何学习性能测试
17.3 我们要达到的目标
1）熟练分析项目性能测试需求
2）能独立编写性能测试脚本
3）能独立执行性能测试
4）能熟练收集相关性能数据，并做简单分析（知道一些套路）
5）目标决定方向，同时表明了重点
17.4 性能测试理论在性能测试中的位置
1）作为后续课程的基础
2）可理解为葵花宝典总纲“要练此功，必先自宫”，用于指导实际性能测试工作
练习题提问汇总：
1～12点 （截图）
性能测试是需要参数化
数据和业务分离很重要
8核16G电脑足够用
第六课? 如何做专业的性能测试
（接着上述第四课讲，讲解作业）
-
怎么考虑性能测试的典型场景？
—产品规格：产品经理提供
—用户模型：用户喜欢用什么功能，什么时间段用，大概有多少用户 （产品经理不太会说，需要我们自己分析）
—系统数据：基础数据（用户名密码地址信息等）和业务数据（买了什么东西花了多少钱等）
为什么需要考虑这些数据？
我们要访问的数据大多放在数据里了。性能测试过程中需要制造大量的数据，是要解决数据库当中数据量比较大时性能低的问题，数据太少的话，和数据库相关的性能问题根本就测不准确。
原则：准备数据时，宁多勿少
—系统架构：一个是逻辑结构，一个是 ？（即有哪些模块构成，在部署的时候分别部署在哪些系统上）
举例：比较粗的逻辑架构：Browser—Tomcat(nginx)—Redis—Mysql
不同硬件不同结构，会对性能有影响。要把架构做好，不然会在很多阶段有很多遗漏，或者影响性能。
—运维日志： 了解运维日志，进一步确定真实用户的数据和行为。
—市场计划：跟市场部要，为来帮助我们考虑性能的扩展性。
—项目管理计划：用来帮助我们明确测试的优先级（重点）。
以上，就能得出我们的性能测试需求，根据性能测试需求，进而设计出压测模型。
—测试需求-》设计出压测模型
2. 在给定的测试环境下，考虑北侧系统的业务压力量和典型场景？
考虑业务量，即进行性能分析。
3. 什么时候可以开始执行性能测试？
一般是在功能稳定后开展的比较多，不然录制脚本后，往往因为开发修改代码，功能出现问题而导致性能测试用例脚本无法运行，测试阻塞。
但目前有些公司的项目可能因为项目要上线赶进度，往往没有做性能才认识的，功能没问题就直接安排上线，等用户多了，出现问题了，才开始性能调优。
6 软件性能测试流程（重点）
1）流程是什么？
需求分析 —> 测试计划 —> 用例编写 —> 测试执行 —> 输出报告
细化：
? ? 前夕准备 中期准备 ? ? ? 测试执行
—————————————— ————————————————— ———————
需求分析 —> 方案设计—> 计划 —> 脚本编写（环境搭建，预热，数据准备） —> 执行 ，监控
?? ? ? ? 完成
—— ? ————
调优 —> 输出报告
（1）需求分析：需求分析和调优是性能测试的难点。? （做什么事情？）
输入：
产品规格
用户模型
系统数据（基础数据和业务数据）
系统架构
运维日志
市场计划
项目管理计划
输出：
性能测试需求分析
（2）方案设计：主要是讲流程思路（比较粗略的），测试用例讲的是具体的一个功能点。（我怎么做这件事，宏观）
测试需求是：什么场景（功能），多少人，在多长时间完成多少事
压测模型是：将上面测试需求，用对应方案，工具，技术来实现
（3）计划编写：
什么时间，什么人，做什么事，什么时间完成
不同的企业，测试计划的编写形式不尽相同，有完成版和精简版
完整版，有项目背景，风险说明，风险应对等等，通常用Word来编写
精简版，事情—时间—谁做， 通常用project来编写
（4）脚本编写：
性能测试脚本
要先了解系统，对接口，功能（模块），彼此间的依赖关系，再开始编写。
常见的问题：
—脚本全都放在一个Action里面，耦合性太强
—没有注释
—写完后没在场景中（编译器中）跑，结果压测一开始，脚本就各种报错 （通常先在场景
中跑15分钟）
。。。。。。
第七课? 性能测试执行
（5）环境搭建：
性能测试环境
搭建环境需要多少资源，这个环境要满足什么样的需求（比如 4核8g，带宽多少，需要
多少台）？
主要问题：线下环境如何模拟线上环境？
答：能在线上做就在线上做，两个方面：
没上线的，可以在线上做（没上线，没用户）；
全链路的方式（已上线，有用户）。——很多小公司做不到
如果不能在线上做，搭建模拟环境，测试机器的扩展系数+自动扩容（或服务降级）构成
一个方案。
如果线上和实际的数据差异过大，缩放后也没有参考意义，大家都不认可，那就不要
做。（主要指数据的差异，配置上的差异没那么大）
性能测试的差异和功能测试的差异分析，差不多。
PS: 搭建环境完成后，要预热。
（6）数据准备：
包括基础数据和业务数据
主要是性能分析的结果：准备多少数据？
测试方案：怎么准备？（业务生成，SQL存储过程，工具生成，导入线上数据（敏感数据
要脱敏））
具体准备：测试准备
自动扩容，扩容系数。。。！！！需要进一步理解
性能测试忌讳记住死数据，要记住的是思想思路。流程是怎么玩的，为什么要这么做，不
这么做的问题是什么。
（7）执行压测
设置好场景，跑数据跑出来
（8）监控搜集数据
监控：为了搜集数据，为后面分析和调优做准备
（9）分析调优
调优往往是一个团队的事
调优：为了软件更好，更能服务预期
过程：是一个迭代反复的。
（10）编写报告
什么人，看什么数据，是有讲究的
比如：
给领导看的报告，如何写？（过程中的问题和成长）
给客户看的报告，如何写？（结果）
2）为什么需要流程？
保证项目顺利进行
第八课? 性能测试中的理论模型
7 性能测试指标（重点）
7.1 性能指标详解
1）并发用户数/在线用户数/注册用户数
并发用户数 <= 在线用户数 <= 注册用户数
12306同时在线买票的用户，12306登上去的所有用户，12306的注册用户数
Ps： 并发用户数是用来压测的。注册用户数会根据这个值来造数据。
2）响应时间：
响应时间是和一定的用户行为联系在一起的，对外说的时候：TPS多少的时候，响应时间是多少？
响应时间一般是越短越好，需要看具体测试对象的标准。
响应时间组成（web）:
—打开浏览器，在百度中输入：新浪
—浏览器自身的处理
—DNS的解析时间：host — 本地DNS —国内DNS — 国际DNS
—TCP建连时间：三次握手所需要花费的时间
—请求在网络上传输的时间
—服务端接收时间
—服务端解析时间：OSI网络模型接缝状到找到具体的业务程序解析所花费的时间
—数据库处理时间
—数据发送给客户端的时间
—数据在网络上传输的时间
—客户端收到数据并呈现出来所需要的时间
—整个业务处理中经过的模块话费的都要考虑进来
3）TPS：每秒事物数
用来衡量系统处理业务的能力，根据实际需要增加。
注意：
这是看在客户端的角度来说的，并不是服务端自己定义的。
单位是：xx个/秒
举例：测试登录的性能，一个事务里面可能有很多的请求。
4）吞吐量：
用于反应客户端和服务器之间网络状况的一个指标，其能间接反应服务器承受的系统压力。
衡量网络性能的实际指标（带宽是理论指标）
实际单位是：比特/秒 （bit/s）
5）思考时间：
模拟真实用户操作而停顿的时间间隔。
思考时间会影响系统TPS。
编写脚本的时候，要考虑思考时间
6）资源利用率 — 之 cpu， 内存，网络， IO（磁盘的，网络的）? （在资源监听器窗口可以看）
—CPU: 物理cpu， 逻辑cpu，cpu核心数。（百度，这几个概念要搞清楚）
关注具体指标：
会看整体是否够用。
会看具体要测试的程序用掉多少CPU。
（性能测试里，定性不定量）
—内存
Windows 系统显示用了多少就是多少
Linux 所有的内存都会被系统拿来用。
关注具体指标：
会看整体是否够用。
会看具体要测试的程序用掉多少内存。
有没有交换分区 ———如果使用交换分区，也表明了系统的内存紧张。（win和linux都有，一般当内存使用了80-90%的时候，基本都在使用交换分区了）
—网络（连接客户端和服务端）
关注：带宽，实际吞吐量是多少，丢包率是多少，一般有丢包率的时候还有延迟
—IO （典型：硬盘读写）
关注：当前使用了多少，是谁在读在写，他们各自占用了多少
7.2 不同视角下的性能指标
—用户视觉：TPS, 响应时间
—开发视觉：代码能跑多快
—运维视觉：CPU, 内存，网络，IO
—测试视觉：上述全部
8 性能测试中的理论模型（重点）
8.1 性能测试拐点模型 （图）
TPS和吞吐量是有本质区别的。
TPS是：用来衡量服务端处理业务的个数，是一个网络指标，是实际的值，带宽是一个理论值。
吞吐量是：客户端和服务端之间的网络性能，间接的反应服务端的处理能力。（这里是吞吐量还是响应时间？）
第九课? 性能测试的拐点模型分析
8 性能测试中的理论模型（重点）
8.1 性能测试拐点模型 （图）
1）随着压力增大，响应时间逐渐变大
2）随着压力增大，吞吐量显示逐渐增大，维持一个较高水平，之后吞吐量会下降
3）随着压力增大，资源利用率显示逐渐增大，维持一个较高水平
该模型用于统筹一些指标之间的关系。
这些关系在后面实战及实际工作中可用于排查定位性能问题。
出现拐点的地方，是我们要重点关注的点。
理论情况下，系统在压力大到不可接受后，如果出现崩溃，tps会断崖式下跌。
8.2 理发师模型
该模型用于理解资源调度和业务排队等待之间的关系。
最大的好处是，让我们理解到压力增大之后，吞吐量为什么会降低，资源利用率为什么会
逐渐增高。。。（自己搜相关概念来理解）（模型图跟拐点模型基本一样）
9 前端性能测试
9.1 前端性能测试概述（图）
前端性能测试是一个用户的行为，而服务端性能测试是很多用户并发起来的行为。
9.2 前端性能测试工具介绍
—httpwatch
—Fiddler
—浏览器自带开发工具
—在线前端性能测试工具 ： https://gtmetrix.com
(这是谷歌的一个工具，在谷歌浏览器打开，然后输入你要测试的网址。
默认用国外的服务器，如果要用国内的，注册，选择一个国内服务器？)
（运行完了之后看结果，重点看标红的项）
（这个工具能出来很多具体的问题分析，很方便，建议使用）
前端性能测试工具：浏览器的开发者工具（F12）, httpwatch, 在线免费工具等。
9.3 前端性能优化工具介绍（略）
1）smush.it 图片优化
2）PunyPNG图片优化
3）SiteReportCard图片优化
4）js优化
5）css优化
9.4 前端性能测试实战
1）注册一个https://gtmetrix.com 账号，并登录
2）输入 www.sina.com.cn 并开始测试
3）搜集测试数据，并分析测试结果是否符合预期
10 App 性能测试
某个角度来说，APP装在移动设备中，可以看作是嵌入式设备。
所以APP的性能测试既受嵌入式设备的限制，也要考虑APP自身的特点。
这里的性能测试，重点是服务器端，APP性能测试略。
作业解答：
- 如何识别性能瓶颈点
TPS —— 响应时间
分析：初步性能数据是否满足预期？
满足呢，则看四大件有没有潜在风险，有潜在风险的话，分析。
不满足呢，分析，看看瓶颈点在哪里，看谁占用过多的资源，再进一步确认它占用这么多资源和不合理，如果合理，ok。如果不合理，开发介入优化。
2. 你如何设计负载？标准是什么？
测试出满足产品需求的数据（假设是50）
开始设计负载测试，以大于50的压力开始跑，比如60，70， 80…….开始跑负载测试，直到系统挂掉（压力测试压挂掉系统时的压力）
实际上
更关注性能测试，更关注系统的稳定性
要知道系统能不能满足应用
要知道系统什么时间点开始不满足应用
什么情况下会挂掉
