2020-01-16听完本次课，对性能测试有了更进一步的理解，对以往迷惑的地方有了一些模糊的澄清，还需要继续努力学习。谢谢老师！另外有一些地方请教老师：
1.在基准性能场景测试时，有哪些好的途径和方法来获取所需的业务比例、业务目标TPS和响应时间？
2.容量测试场景中，实在没有弄明白线程递增数据是怎么获得的？我看老师在回答其他人的问题时说后续在业务比例设计中会讲到。如果是这样，很期待早日听到该课程！作者回复: 1. 业务比例和目标tps是业务指标中的关键部分，这是要业务部门提的。要不你看下业务模型那篇是否可以回答得了这个问题。
2. 递增数据的数据在这篇中已经说了吧。就是看响应时间是快还是慢，如果响应时间快就少一点线程上升。 1- 2020-01-14高老师，您好。以下是我对两个思考题的回答。
第一个问题：
性能场景设计前应了解实际场景中对应业务的目标值。然后查看对应业务的组成，采用先局部后整体的思想进行性能场景设计。具体而言，就如文章中所述先将单业务的基准性能测试结果得出，再进行混合业务的性能测试。值得一提的是通常情况下时间是稀缺资源，所以进行性能场景设计时，应时刻谨记以终为始的理念，得出结果后判断是否能满足业务目标。
第二个问题：
二八法则好比万金油，换句话说就是可有可无，进行稳定性场景的测试就是为了知道会不会由于长时间处理业务而引发潜在瓶颈。此时已经了解了对应业务的目标值，那么只要系统在正常处理，资源没有出现问题，也没有报错下，业务目标能满足，而且更确信，这样会更好。展开作者回复: 理解的挺正确。
1 
2020-01-13老师，我一直有一个疑问。在做业务的性能测试时，是只测实现这个业务逻辑的接口，还是要测完成这个业务时访问的所有接口？比如，登录业务。在接口文档里只是一个登录接口，但使用JMeter录制登录操作，还会请求其他接口。作者回复: 你这个问题的前提是：你想做的是什么场景？
只有分析了你要做的场景，才能判断出应该如何访问接口。
比如说，你的目的是只测试登录，那就完全没必要请求后面的接口。即使是录制实现了登录，并且连带了后面的接口请求。也应该把后面的接口请求给删掉。 1
2020-01-13高老师，我有个小白问题哈。为什么容量测试的结果会比单业务测的结果高呢？😄作者回复: 走的路径不一样。单业务涉及到的机器也没有容量场景涉及的机器多。
1- 2020-02-09老师，文中的这段话：在这个示例中，业务 + 运维部门联合给出了一个指标，那就是系统要稳定运行一周，支持 2000 万业务量。运维团队每周做全面系统的健康检查。当然谁没事也不用去重启系统，只要检查系统是否还在健康运行即可。大部分时候运维是等着系统警告的。那么针对前面给出的容量结果，容量 TPS 能达到 3800（业务 1 到业务 6 的容量测试结果 TPS 总和）。所以稳定性场景时间应该是：20000000/3800 = 1.46 小时。
不明白稳定性场景时间为什么要这么计算？能详细分析一下吗？
还有我之前看到的很多都是这么来确定稳定性场景的执行时间的：一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行8小时以上，对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。展开作者回复: 一个系统只有一种情况会需要像你这样来设计场景，就是系统的稳定性只和时间和关，和业务积累量无关。
我说的是用计算业务积累量的角度。 
2020-02-07感觉还是没有很基础- 2020-02-07还是不会做这些结果图啊，能对应jmeter讲解具体点吗？知道怎么分析了，不知道这些数据图怎么来的。
作者回复: 这个专栏没有规划要讲jmeter的基本使用，所以不清楚你要讲的jmeter具体功能是什么，如果呼声高的话，后面，我可以加餐。
2020-01-30稳定性性能场景中100%最大TPS出现了error，而80%正常，如何判断稳定性性能测试是否有Bug。作者回复: 没看懂这个问题，请描述多些。给些具体的数据。
2020-01-17思考题
- 性能场景应该按什么样的逻辑设计: 了解目标要支持多少流量，峰值流量如何，最大月份共计需要支持多少流量。然后用总计流量，除以峰值流量，可以得到以峰值流量进行性能测试的时间
以及在稳定性场景中，为什么不用最大 TPS 的 80% 来做：因为80%就太高了，CPU的抖动会比较大，很难控制变量作者回复: 第二个理解的不对哦。80%也不一定就会有抖动。
而应该是只要用稳定的TPS就可以了。
2020-01-17拿到基准测试的结果后，您是如何按照业务比例设计出容量性能场景的，这块弄不懂，文中也没有计算的过程，不知道基准测试结果起到说明作用，老师能否详细说明。作者回复: 业务比例在容量场景中直接通过控制tps来体现就可以了。后面说了工具中各用什么功能来控制。不知道你的具体疑惑点是什么呢？
基准测试起到的作用就是先把最基本的瓶颈解决掉。我这里已经给出的是优化后的基准测试结果。其实这个过程中遇到的瓶颈很多。 只有先把这些问题解决，基准测试的响应时间和tps才能对容量测试有比对的作用。- 2020-01-16第一个问题，性能场景应该按什么样的逻辑设计吗？
第一步，通过调研分析以及经验等途径获得并列出需要测试的业务、业务比例、业务目标TPS和响应时间指标；如果没有以上数据，也可采用头脑风暴法，也就是俗称的拍脑袋法，来获取相关信息，当然，这时测试过程会延长，需要通过想法、验证、修正等步骤，逐步获取较为精确的数据。
第二步，开展基准性能场景测试，获得每个业务的最大TPS和响应时间。
第三步，开展容量性能场景测试，在场景不断和控制比例的要求下，设计合理的各业务参数，测试后分析数据。
第四步，开展稳定性性能场景测试。在容量场景测试的基础上，确定综合业务TPS和时长。
第五步，开展异常性能测试，在全面分析架构图的基础上，根据测试目标选择压力参数，设计运行场景。
第二个问题，在稳定性场景中，为什么不用最大 TPS 的 80% 来做？
二八原则适用于头脑风暴法，也就是没有分析数据，没有经验值，自己拍脑袋的话，还不如采用这种方法，至少说起来还有一定的依据。😅
但是按第一个问题的回答，在稳定性场景测试时，我们已获取了需要的信息，因此没必要采用这个法子了。展开作者回复: 第二个问题的理解没有说到关键点。
2020-01-15老师那个业务占比是用来干什么的？得到业务占比是为了后面的什么用途需要呢？作者回复: 为了混合容量场景中设置比例。
- 2020-01-15高老师，好，请教个小白的问题，jmeter按照梯度运行，每个阶梯的数据可以像LR一样截取出来吗？
例如：按照10、20、30线程各运行10分钟，可以把每个梯度的数据截取出来吗？作者回复: 从技术操作上来说，可以截取出来。
可是为什么要截取出来？ 1 - 2020-01-14老师，你上面讲的场景设计是开篇已经有了各个业务的比例以及各个业务的TPS指标，对于没有明确指标数据的系统如果去定这些指标呢？比如有个用券兑换礼品的系统，用户就说我有500w张券，用券兑换礼品的活动持续时间是1个月，需要做个性能测试保证这个1个月内系统不要出问题。对于这样的情况，该如何去定指标并完成整个性能测试呢？
作者回复: 没有业务统计数据参照，只能找有经验的人拍脑袋了。
2020-01-14弱问老师线程数递增图和响应时间图是怎么生成的？谢谢
当前的测试都是分开的，比如10 threads 对应的响应时间t1， 20threads对应的响应时间点t2。记录了这两个场景的值作者回复: 场景执行时连续。生成的结果报告自然就是那样了。
1- 2020-01-13老师，有几个问题和想法。首先场景不断这个应该怎么理解？其次是老师例子中的业务一到六是一个接口还是多个接口？再次是控制业务比例，如果可以拿jmeter举例子会好很多，让我们能把您的想法落地，前面那几篇工具篇能匀一篇说业务比例如何设计该多好。最后是容量场景下最大tps应该怎么看？我看您的图都是曲线图，难道是看曲线图约摸着得出一个结果？
作者回复: 场景不断，就是从低到高线程递增。
业务1到6，都是有业务含义的，后端会有很多个接口。
控制业务比例的过程通常是这样的：1. 先是拿线程数和TPS、响应时间来计算业务比例来做；2. 当运行过程中出来业务比例偏差时，就调整线程数；3. 在jmeter中可以有控制吞吐量的控制器。
业务比例设计的后面有一篇是专门描述这个的。
最大TPS，我是通过曲线图的一段来做计算的，你要是“约摸”这个词，也不是不可以。哈哈。 
2020-01-13高老师，jmeter中您是怎么来控制业务比例？我自己在实际压测的过程中很难做到比例的精确，多个线程组的话，每个业务的响应时间又都不相同，求赐教作者回复: 你可以用吞吐量控制器。
2020-01-13高老师 有个问题想问一下。如果没有业务指标情况下 想要跑压测之类 有没有一些常规的指标？或者要怎么去定线程数之类的作者回复: 没有业务指标是可以测试出最大tps的哇。只要有业务比例即可。线程数是根据业务比例来的。
- 2020-01-13如果是新的项目，没有拿到比例的情况，是不是可以按默认1:1:1的比例来执行容量场景？
作者回复: 做为尝试场景，可以这样做。只是要知道这个结果对线上没有参考价值。
2020-01-13答：
1、性能测试场景应该有预期的测试指标并且符合实际的生产场景，按照生产的业务比例模拟真正的业务，以达到我们所真正需要的结果。
2、稳定性场景就是为了知道会不会由于长时间处理业务而引发潜在瓶颈。至于用多大的 TPS 来运行，又有什么关系？这个系统用最大 TPS 能跑下来，业务一直很正常，稳定性目标能达到，为什么不能用最大 TPS 来跑呢？只要系统在正常处理，资源没有出现问题，也没有报错，那这个场景就是有效的，目标也是能达到的。作者回复: 理解的非常对。