也是。很尴尬，我们的业务特性基本没有低峰

我们公司会按照等比例的机器，进行模拟 pro 环境。要区分压测场景不同吧，比如要压测瓶颈。

开销确实高，所以我们都是按系数去评估的。一般不会全模拟 pro 环境的。

亿级的访问量，短暂的几分钟，影响不止百位数吧。当然也和实际公司的业务有关系。每个公司都不一样。我们公司上次两分钟，大几万的请求失败 。

多多少少都会有点影响吧，而且限制就要做很多兼容的实现，觉得还是单独的压测环境比较好点。

生产直接压测，不会对其他业务有影响吗？

为啥会问 k8s 和 kafka 呢？

很赞。理解下，文章中的覆盖率，是把测试用例和接口进行比较得出的结论吗？这个是只能看到接口有没有覆盖吧。对于不同场景怎么进行评估呢？

流量回放没有接触过。是不是为了更好的感知用户的操作步骤，在 test 环境进行模拟，或者做更好的场景分析。

应该是的，二面之后没有给答复。一般面试都会有回复的吧。

6 月份面试过其它部门的测试开发，现在还可以面试吗？

机器配置不一样，能够支持的并发数也不同。对单机能支持 60000+ 表示非常可疑。一般用 jmeter 比较多吧。 百万级肯定是分布式压测了。单机是不可能的。

必须本科吗？之前面试过其它部门的测试开发，还有机会吗？

要测试的场景不清晰。用户要不要重复选课，一共有多少门课。前置的条件要清晰

总觉得，实践是最好的提升方式。

如果负载均衡做的非常好，集群扩容机器是否线性增长。

是的。代码的健壮性决定性能好坏

抛开外界因素不考虑呢。那如果是集群的呢。比如，集群中 10 台机器，支持 1000。扩容到 20 台，支持 2000。这样的

有，这种问题应该就是业务实现不健壮吧。机器的性能还没达到，业务就撑不住了。

劳逸结合

多次重复做的事情。

不会的。可能会调用多个接口。全部跑完不可能的。

目前没有和 spring 集成，很尴尬，所以 case 运行时间很长。整个脚本初始化第一次完成加载之后，每个 test 不需要单独加载一份了吧？

谢谢，懒加载单例是指，用到就去生成实例？不用就不生成吗？

任何工作，一旦久了都是失去热情吧。慢慢的变了味道，为了爱好而工作>>>为了工作而工作>>>为了生活而工作>>>为了活着而工作。