思考题
你能说一下性能场景应该按什么样的逻辑设计吗？
以及在稳定性场景中，为什么不用最大 TPS 的 80% 来做？
读者：
高老师，您好。以下是我对两个思考题的回答。
第一个问题：
性能场景设计前应了解实际场景中对应业务的目标值。然后查看对应业务的组成，采用先局部后整体的思想进行性能场景设计。具体而言，就如文章中所述先将单业务的基准性能测试结果得出，再进行混合业务的性能测试。值得一提的是通常情况下时间是稀缺资源，所以进行性能场景设计时，应时刻谨记以终为始的理念，得出结果后判断是否能满足业务目标。
第二个问题：
二八法则好比万金油，换句话说就是可有可无，进行稳定性场景的测试就是为了知道会不会由于长时间处理业务而引发潜在瓶颈。此时已经了解了对应业务的目标值，那么只要系统在正常处理，资源没有出现问题，也没有报错下，业务目标能满足，而且更确信，这样会更好。
读者：
听完本次课，对性能测试有了更进一步的理解，对以往迷惑的地方有了一些模糊的澄清，还需要继续努力学习。谢谢老师！另外有一些地方请教老师：
1.在基准性能场景测试时，有哪些好的途径和方法来获取所需的业务比例、业务目标TPS和响应时间？
2.容量测试场景中，实在没有弄明白线程递增数据是怎么获得的？我看老师在回答其他人的问题时说后续在业务比例设计中会讲到。如果是这样，很期待早日听到该课程！
1. 业务比例和目标tps是业务指标中的关键部分，这是要业务部门提的。要不你看下业务模型那篇是否可以回答得了这个问题。
2. 递增数据的数据在这篇中已经说了吧。就是看响应时间是快还是慢，如果响应时间快就少一点线程上升。
读者：
我一直有一个疑问。
在做业务的性能测试时，是只测实现这个业务逻辑的接口，还是要测完成这个业务时访问的所有接口？
比如，登录业务。在接口文档里只是一个登录接口，但使用JMeter录制登录操作，还会请求其他接口。
读者：
高老师好，有两个细节问题咨询下，谢谢
1.稳定性测试，使用最大tps进行压测，这个时候的压力是通过梯度递增线程到最大线程数，满足加压到最大tps，然后持续运行满足业务需要的时长吗？
另外需要在测试中对每个业务使用 constant through timer对每个业务吞吐量设置吗？
2.这样不同的业务，是部署一个jmeter模拟器通过建立不同的线程区分业务，然后对每个业务都设置一个吞吐量定时器。还是使用不同的模拟器 分别加压一个业务？
读者：
老师，文中的这段话：在这个示例中，业务 + 运维部门联合给出了一个指标，那就是系统要稳定运行一周，支持 2000 万业务量。
运维团队每周做全面系统的健康检查。当然谁没事也不用去重启系统，只要检查系统是否还在健康运行即可。大部分时候运维是等着系统警告的。那么针对前面给出的容量结果，容量 TPS 能达到 3800（业务 1 到业务 6 的容量测试结果 TPS 总和）。所以稳定性场景时间应该是：20000000/3800 = 1.46 小时。
不明白稳定性场景时间为什么要这么计算？能详细分析一下吗？
还有我之前看到的很多都是这么来确定稳定性场景的执行时间的：一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行8小时以上，对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。
读者：
老师，有几个问题和想法。首先场景不断这个应该怎么理解？其次是老师例子中的业务一到六是一个接口还是多个接口？再次是控制业务比例，如果可以拿jmeter举例子会好很多，让我们能把您的想法落地，前面那几篇工具篇能匀一篇说业务比例如何设计该多好。最后是容量场景下最大tps应该怎么看？我看您的图都是曲线图，难道是看曲线图约摸着得出一个结果？
读者：
1、性能测试场景应该有预期的测试指标并且符合实际的生产场景，按照生产的业务比例模拟真正的业务，以达到我们所真正需要的结果。
2、稳定性场景就是为了知道会不会由于长时间处理业务而引发潜在瓶颈。至于用多大的 TPS 来运行，又有什么关系？这个系统用最大 TPS 能跑下来，业务一直很正常，稳定性目标能达到，为什么不能用最大 TPS 来跑呢？只要系统在正常处理，资源没有出现问题，也没有报错，那这个场景就是有效的，目标也是能达到的。
问题那么最后给你留两个问题：
为什么业务比例对性能场景如此重要？
以及如何在执行场景过程中控制 TPS 比例呢？
读者：
老师，您好。我是一名性能测试小白，想请教您一个问题。
在做性能测试时，如何理解和定义业务？是实现这个业务逻辑的核心接口，还是完成这个业务操作所涉及到的所有接口？比如，我们目前打算上线一款APP，我想做一下接口的性能测试，评估服务器目前的承载能力，为后期服务器规划扩容提供数据支撑。由于目前没有实际的生产流量，因此我根据APP的特点，站在用户的角度分功能操作APP并用JMeter录制脚本，于是我设计了两个测试方案：
1.把每个功能看做一个业务，直接用录制的脚本做基准场景和容量场景的性能测试。
2.把每个功能看做一个业务，从录制的脚本中挑出完成这个功能的核心接口做基准场景和容量场景的性能测试。
对于我设计的方案，老师能说说您的看法吗？另外，能针对我的这个需求场景，给我一些实施的建议吗？
读者：
老师我的问题如下，望得到解答：
1.用业务比例来进行容量测试时，用Constant Throughput Timer控制了tps，是不是就压不到最大值了，受限于所设置的tps值，觉得这里设置的tps和想要得到的最大TPS值冲突了
2.用业务比例来进行容量测试时，是不是需要同时使用吞吐量控制器（来控制业务的百分比）和常数吞吐量定时器（控制总TPS），如果不是，那应该怎么实现呢。
1，控制了时间的话，如果最大tps之前就达到了控股的时间，肯定就测试不出最大tps了呀。
2，是
读者：
那么最后给你留两个问题，为什么业务比例对性能场景如此重要？以及如何在执行场景过程中控制 TPS 比例呢？
（1）业务模型是模仿真实使用场景，是在真实使用的基础上进行的性能测试
（2）吞吐量控制器；
【问题】还听说过一种是取余，比如28比例的话就用10/5，余数为0请求一个接口，余数不为0请求另一个，达到业务比例（请求量）比例为2:8目的，但这个似乎控制的不是tps？貌似只是施压比例，楼哥帮忙看下谢谢
读者：
1.为什么业务比例对性能场景如此重要？
不同的业务对系统资源的消耗完全不一样，如果业务比例跟实际的业务比例不一样，就会导致运行过程中资源消耗出现很大的偏差，那么得到的结果不够真实正确，也大大降低了性能测试的价值。
另外，如果生产流量来源是可以覆盖想要测试的业务场景的，可以通过生产流量扩大回放的方式实现压力部分，就不用考虑业务场景了。
2.如何在执行场景过程中控制 TPS 比例呢？
通常，在 LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。注意，JMeter中，Throughput Controller并不控制TPS。
另外请教老师，根据业务模型推算出各业务的TPS，从而根据公式，结合响应时间推算出压力机线程数。这个思路对吗？
如果对，如何进一步确定压力机线程数配置，具体来说，
问题1，响应时间怎么获取？是业务提出的，还是基准测试中获得的最大TPS对应的响应时间？
问题2，推算出来的压力机线程数就是测试中的最大值吗？是否需要适当加大一些呢？如果需要，增加多少合适？如果不是测试中的最大值，怎么取值？
问题3，在一次场景测试中，业务模型是一直要保持吗？比如说，起始线程数的配置也是要按业务比例计算吗？中间任一时刻都得按业务比例设计吗？
读者：
答：
1、通过对生产数据统计能够完整体现系统业务的峰值数据，然后转换成具体场景中的业务模型，模拟真实的生产环境中的业务比例。不同的业务对系统资源的消耗完全不一样，如果业务模型跟线上的业务模型不一样，就会导致运行过程中业务比例出现很大的偏差，那么得到的结果不够真实正确，也大大降低了性能测试的价值。
2、执行场景中控制TPS比例的方法：LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。
读者：
第一个问题我认为业务比例越趋近生产环境得到的性能数据越真实，生产流量的回放我理解的核心目的也是为了真实的覆盖所需要测试的性能场景，如果业务比例跟真实环境差距很大，那么得到的数据是没有意义的
第二个问题控制TPS比例需要根据线上的统计得到每个服务TPS的峰值及范围，不同的天数和时段TPS是不同的，需要根据线上的TPS的比例去测试系统的资源占用和性能指标，这样才能够真实的反应系统的性能情况，不论做系统当前性能测试还是未来系统的容量规划都是有意义的
