可以理解为接收的 QPS 吧，接收的 QPS=处理完的 QPS+ 错误 QPS

抛砖引玉：
1、大部分情况，服务端容量就是看 QPS，或则说（QPS，Latency，Error_Rate,CPU,Memory) 这几个组合。单纯谈一个或几个指标是没有意义的，比如 QPS 很高，latency 很大，或者错误率很高，这都是无效的
2、大部分情况下，服务端容量就是看 QPS，并发数只是我们达到这个 QPS 的手段 --- 这个是 OK 的
3、为什么说大部分情况下呢，因为对于某些场景下，并发数有特殊的含义。比如说 websocket 协议，比如游戏基于 socket 长链接这种情况下，系统看的是新建连接数，和连接保持数，这个是 QPS 解决不了的。
4、就楼主这个情况，300 并发 != 300QPS。 产品告诉你 300 并发，我理解是最大同时支持 300 个用户并发操作，需要根据用户行为模型来预估最高 QPS。这种情况下，可以看看线上高峰期时并发数是多少，然后对应的各个接口的 QPS 是多少，然后计算出 300 并发下，各个接口的 QPS 是多少，然后需要按照这个数据来进行压测。

1、假设只有 1 个线程，单个请求的响应延时为 T 秒， 那么此时 QPS = 1 秒/T 秒

2、那么当有 N 个线程，也就是 N 个并发时， QPS = N/T。
3、所以正常情况下，增加并发 ，就可以提升 QPS。 但是当并发数超过一定数之后，会导致线程调度占用大量的 cpu，导致 T 变大。
因此需要不调整并发数大小，单台发压机不行，也可以多加几台发压机

case 设计必须以业务为主，必须围绕业务需求，以及系统设计，来进行 case 设计；
UI 测试这块，不需要设计 case，记录测试点就行。
在执行业务 case 的时候，可以顺带将 UI 测试点来验证

1、功能回归测试：所有历史 case 都应该回归一遍
2、性能测试：确保新换组件能支持以前组件的峰值性能
3、稳定性：长时间运行，性能不下降，不出现崩溃
建议部署两套线上环境，一套是线上版本不变，一套切换新组件的版本，将线上流量全部 copy 一份打到新组件上，运行一段时间看看是否有问题。
如果有没有问题，再逐步切流量

个人觉得不用考虑文件大小，说文件太大，是为了不让你把文件全部加载到内存，然后循环遍历，
for line in open() 就是按行读取的，不会全部加载。

问题点是在于，文件只能遍历一次，碰到搜索命中时，后 n 行比较好解决，继续循环就可以了。前三行怎么处理？
这里需要加上一个定长（n＝3）的队列，不断 push，超过了长度，就从顶部删除一条。
遇到命中，就全部清空，写到文件中

做 diff 之前，要想清楚为什么要 diff，目的是为了解决什么问题？
我们做 diff，最主要是目的是：
1、新版本的老接口回归
2、线上服务的监控 -- 有点特殊性
3、AB test

就目的 1 来说，就是要对比基准版本（线上版本）和新版本在相同的环境下，相同 query，来对 response 做对比。所以只要是两个版本所在环境一致，就可以完成对比，当然最好是把线上配置和数据复制一份到线下，然后捞取一批线上请求，来对比不同版本的请求结果。

其他两个稍微麻烦点，有空再讲