注意：因为是笔记，我也结合了具体工作中遇到的情况，穿插了很多自己的理解，所以某些点并非完全和原作者的结构、描述一样。
【性能测试的分类】
1、压力测试：关注点在于系统在峰值负载或超出最大负荷时的处理能力如何。如果继续加压，性能应该按预期缓慢下降，但不应直接崩溃；如果崩溃，找到它的临界点，从而了解系统的薄弱点和极限；
2、容量测试：预估系统可同时处理的最大值后，确定是否可以达到最大值，以及如果超过此值，是否系统还可承受，后半截就有点像压力测试了；
3、极限测试：在过量负载下测试，这看起来又和压力测试类似了。
所以，综上所述，我们对于性能测试的分类，没有必要非要说出个1，2，3，因为它本身就没有清晰的边界。而我们实际测试的时候，以上三点，本身就必须要设计在我们的性能测试方案中。所以对于性能测试来说，重要的是去明白，这场性能测试你到底想要测到一个什么结果，以及得到这个结果的方法。这里作者也给出了一段很好的定义，我贴出来：
整体思路：确定待测指标--->建立测试模型（场景）--->落地为方案（包含整体测试策略、场景分类、测试方法）--->每个场景测试对应指标项，找到瓶颈并调优--->最终让产品达到一个我们预期可发布的性能质量。
那么，基于这个思路，我们进而逐步细化每一步要做的事情。
【确定待测指标】
文中没有细讲。从我的测试经验来说，分为两种方式：
1、产品经理、SE已经有了很清晰明确的产品性能规模，这通常发生在较为成熟的产品项目。那么这就是我们的待测指标；
2、新产品，或者乱成一锅粥的产品项目，没人知道这个指标怎么来。我的经验是，首先根据我们待测产品了解它的同类型典型友商的指标。这个一般不难拿到，官网或者产品经理还是可以提供这个数据的，这是一个很有必要的参考点；然后，看看是不是此次性能指标，是否是为了达到某个资质或者某个客户的要求，如果是，那么这个要求最大，它就是你的指标啦；最后，基于前面两条手上的数据依然少得可怜，就只有依靠你对产品的经验，根据你们这个产品预期的市场定位，是哪个档位的，做好同类型的类比，同时和开发一起，进行进行评估，给出预估的指标，作为待测指标。最最后，不要忘记再整体看一下这个待测目标是否激进，是否保守，要尽量确定出一个合理、公平、从产品经理SE研发经理全体认可同意的待测值。测试真的是一个综合性很强的工种，只要能为质量多一份力，我觉得不要太局限自己的工作范围，特别是你要思考的边界。
【测试模型】
就是你要组装的一个个性能测试的场景。具体主要是两大类：
1、业务性能：这个需要对产品、业务非常理解。比如说做抗D，重点场景就是防护不同的ddos攻击，那么什么场景下去测试到你能够防护的最大能力，就是你要具体设计出来的。通常客户被d的时候，他是什么场景，这就是最值得你模拟的场景。如，客户当前是什么业务，他看重的业务指标是什么，当被打了多大的某种攻击时，清洗设备防护能力达到上限，导致透包，进而影响了客户。我们就是要设计这样的场景，有符合客户常用场景的背景流，也有正在遭受攻击的攻击流，当攻击发生，我们的预期是攻击被清洗（查看清洗设备对应指标，如rx，tx，攻击日志类型，CPU，内存等），背景不受影响（最典型的就是查看被保护服务器的响应延迟、响应准确率），然后不断加压，看看清洗设备上限是否超过待测指标，这是及格线，超过后继续施压到多大，会开始透包，这就是极限。极限，通常决定了你出去外测PK时的成功率。有了大的场景框架，针对这个测试模型，如果性能测试做得足够完备，应该包含三个方面：
1）这个模型下，最好性能的参数及指标：目的是得到产品的规格；
2）这个模型下，最常见业务场景下的参数及指标：目的是得到产品在平时业务中的能力表现；
3）这个模型下，最坏性能的参数及指标：目的是得到产品崩溃的边界，了解自己的底线和脆弱点。
2、容量规格：单纯就是想知道某个业务指标最好的能力，或者说是某个参数的最大值。这个场景一般设计会比较单纯，思路就是：ban掉所有影响它的影响因子，然后求它的最大值；
3、稳定性测试：有些公司会从性能测试中剥离出来，单独做一个稳定性测试方案，有些公司会合并。但本意都是一样的，在一定的时间内，通常是7*24，通过模拟一些压力下的业务场景，确定产品的业务稳定性。这个时间里，压力应做好变化，高压，低压，常规的时间分布也是很考验测试者的场景设计能力的，很多稳定性测试结果都没有太大的实际指导意义，就是因为场景设计不够合理，太过理想化；
4、异常测试/破坏性测试：这个一般不会每次都测试。后面的学习再进一步展开。
【测试方案】
有了基本思路后，落实到纸上来。测试方案通常都有公司模板，根据整体模板，将刚刚思考过的点先放进去，先要做到足够全面，然后再慢慢做好分类和规划，进而预估你要的资源（待测产品数目、板卡、交换机、仪表、人力等等），以及你可能遇到的风险，你预备怎么降低。所有这些，其实是你基于你的测试策略指导后的产物。测试策略它是一个空虚的概念，就是指导你完成测试的思路。所以我个人不太认为把测试策略单独拎出来让写一章是个很好的做法，它应该是渗透在整个方案的方方面面的，它是无处不在的。
【测试调优】
有了计划，有了方案，开始根据一个个的场景进行测试，这就是真的开始测试了。这时候还会有你其实不会写到方案里的内容，就是你的具体测试过程中，你的监控动作，比如对于CPU、内存、rx、tx这些数据的动态监测，是否有突刺等等。不同的测试，他的思考维度和深度都不一样，这也是不同测试最终测试出来的质量不太一样的很大的一个原因。
那么在某个场景测试结束，拿到测试结果后，是否需要调优，主要通过判断是否达到规格要求。如果没有，需要调优，因为这是及格线；如果判断根本就不可能达到，可能是指标过于激进，你需要和研发，产品好好再次讨论一下。其余情况下是否要继续调优，实际上就是丰俭由人了。所以一开始要确定好所有本次测试需要的待测指标，是很重要的，这是指导方向和判断依据。你不能对开发说，我觉得它不行。测试虽然是check者，但守护的是产品质量，一切都是产品的质量目标决定我们要做什么的，绝对不是某个人的想当然。
【测试报告】
辛辛苦苦测试完毕，别忘了把你的数据整理、分析好，形成报告。这是对整个测试过程的一次整体回溯，也许你在编写的时候也有了新的理解，或者发现了自己的疏忽。同时，这也是给后续项目提供的重要测试依据。紧急的时候，我们一般就是把记录的数据放在excel里，标清楚指标项，不合规做好备注。然后会有一句话的整体结论。总之，就是测试报告是一定要有的，根据你的时间和项目形态，它的形式可以不同。