Geek20252021-10-21性能场景为什么只分为四类就够了 1.性能测试是为了产品正常运转和用户体验。结合实际运用的实际，主要还是通过稳定性和容量进行测试，再结合基准分析性能情况，最后避免异常情况发生而补充异常作者回复: 嗯，你领悟了。
5- sky_you2021-06-03我其实想问，这个业务比例要到什么程度，比如我有两个大功能。一个订单管理。一个信息管理。 订单管理中又有新建，查询。信息管理中有新建用户，删除用户。如果我要确定业务比例。是确定大功能的业务比例还是，具体到每个小功能中呢？现在的需求有很多不专业。压根就不会想到这些，只能做性能的人去整理这些。
作者回复: 业务比例最好能到把具体接口罗列出来的程度。 比如你这里说到的订单管理，里面有新建、查询。信息管理中有新建、删除。如果只到大的功能模块，订单管理：信息管理 是 3：1，那还是无法知道订单管理中的新建：查询的比例是多少。所以这个是无法得到具体的业务模型的。 按我的逻辑，从生产环境中的数据统计直接得到的接口比例，进而推算业务比例，还更符合生产场景。
5 
Zzzz2021-05-28老师，基准场景里的响应时间指标，指的是在最大TPS那个点上的响应时间？还是最大响应时间？作者回复: 最大稳定的tps位置对应的响应时间。
5
一步2021-03-25期待老师后面的实战，希望不是一带而过作者回复: 我也希望不是一带而过。看优化结果就可以判断。
2
Hant2022-04-24关于性能测试脚本，一直有个疑问，希望高老师帮忙解惑，谢谢： 1.录制脚本，录制的脚本会多很多接口，各种资源文件，如图片，css等数据（虽然部分可以通过负载均衡做静态加载），但是会非常臃肿 2.单独写的脚本，仅仅只是涉及到业务的几个接口，但是这样的话跟真实业务差太远 这两种脚本应该如何选择？ 另外，在压测过程中能关闭消息通知，登录日志这些接口吗？这些接口非常影响系统性能。作者回复: 1. 按真实的用户逻辑来做脚本就可以。应该有静态资源，脚本中也就要有相应的请求。通常如果静态资源放在CDN，而测试目标又是为了知道后台应用的最大容量，才能直接从接口开始。 2. 日志最好按生产环境设置。
1- Geek_ann2022-02-26想问下老师 刚刚列得性能需要 ：某个单业务场景 200并发的请求，相应时间满足需求。 就直接上线程数200，循环1个。这种测法对吗？我看大多数不专业的都是这么测的
作者回复: 那指定不能对！
1 
future2021-11-02老师能再发一下网盘链接吗 感谢作者回复: 在第30章。
共 2 条评论1- byyy2021-07-10"异常问题通常有两大类：其一是架构级的异常；其二是容量引起的性能异常。" 老师，不太理解架构级的异常和容量引起的性能异常。可以举例分别说明下吗？
作者回复: 架构异常像负载均衡、分布式逻辑。 容量异常就是TPS高的时候，出现的问题。
1 - Geek_7a22e12021-04-261、场景各项指标的值是如何确定的？ 2、需求文档中就应当列出场景和对应的指标吗？
作者回复: 场景的指标定义来自于业务的需求。我这里只是给个示例，如果在具体的工作中，就要做线上的业务统计。 需求文档中应该给出场景和对应的业务指标，要不然测试的目标不就没有了吗？
1 - 挺好的2022-09-21 来自北京老师怎么加群啊，没有看到二维码
作者回复: 可以加我微信，拉进群。Zee_7D