视频有没有完整播放，完全可以通过源视频和目标视频的帧信息对比来完成，定时截图非常不可控、且不稳定。

音频更简单了，将音频文件下载下来，转成文字，或者直接用音频文件与原文件做对比，进行打分。

之前写过一个比较初级的实时音视频测试方案，可以参考一下：《实时音视频质量评估方案》

666

Energy Profiler 可以用于详细定位，但是在持续 5 小时的后台耗电测试中，可以持续开启 Energy Profiler 定位吗？如果持续开启，怎么处理和筛选海量信息呢？

飞哥的产出太高效了，666

响应时间只有 100ms，QPS 只有 400，而且性能上不去，很可能是压力机的问题。
（1）请问压测工具的并发数大概多少？提高并发 TPS 变化不大，可能是并发压力太小，建议可以增加到 100 并发看看
（2）压力机和被压服务器建议处于同一网段，局域网访问

看面试题的话，应该是服务端的测开方向吧？

可以在 404 页面的文章列表中找到想看的文章。

或者，去主页搜索：

我觉得可以从质量保障角度，讲讲产品、UI、开发在质量中的重要性，以及质量对于产品发展、品牌、增长的重要性，以及对于公司，当质量保障体系比较完善的时候，在公司成本和发展方面的重要性。

这样有几个好处：
1）让上下游的同学了解质量在做什么
2）让项目中的同学明白质量只靠测试不能是最基本的质量保障，好的产品质量真的需要各位大家的参与和贡献。
3) 其他岗位同学可以如何参与质量保证、通过参与质量保障，除了可以提高产品质量，对自己在相应职业上的帮助有哪些？
4）大家可以站在质量的统一战线，更多的站在公司角度、项目角度去思考问题，而不仅仅是岗位角度。

OCR 本身准确率、稳定性、耗时就是比较大的不稳定因素了

是的，限制流量的逻辑简单，但是高性能比较考验网络这块的积累

测试开发

现在我也在担心这个问题，哈哈

是的，把我问方了

要求限制 QPS，比如第 1 秒超过 QPS 频次了，拉黑。 第二秒还要放开。

要求自己设计开发，不能使用 Nginx 这种现成的

求大佬指导

我记得之前碰到过，可以通过绑定 host 解决这个问题

看你本地访问 github.com 有问题没，看异常是连接重试次数太多导致

多谢，已更正

哦哦，好的

很好的案例哈，赞赞赞，进步就是站在巨人肩膀上，一点点的不断改进。

请求多少次，不止和并发用户数有关，还跟持续运行时间、每次请求的思考时间、接口响应时间有关。

比如：（为了更清晰的说明问题， 以理想状态考虑）

• 1 并发用户，持续运行 1 分钟，接口响应时间为 1 秒，思考时间为 0，那么 1 分钟 60 次请求。
• 1 并发用户，持续运行 1 分钟，接口响应时间为 2 秒，思考时间为 0，那么 1 分钟 30 次请求。
• 1 并发用户，持续运行 1 分钟，接口响应时间为 1 秒，思考时间为 1，那么 1 分钟 30 次请求。
• 1 并发用户，持续运行 10 分钟，接口响应时间为 1 秒，思考时间为 0，那么 1 分钟 600 次请求。

这些都是性能测试的基础，建议看看：
性能概念不清楚的，建议阅读：服务端性能测试 - 入门指南
性能测试工具学习的，建议阅读：服务端性能测试 - 工具篇 (Jmeter)

1、用线上流量统计来计算线上真实压力

根据日 UV 和日 PV 来推导线上真实并发压力，可能会出现严重的性能评估偏差。

因为服务端的并发压力，跟业务本身的特点强相关。

举个例子：秒杀系统，1 秒钟放入 100 万用户，和 1 分钟放入 100 万用户，是截然不同的两种并发压力。

所以，不建议根据 UV 或 PV 来分析并发压力。

建议：根据服务端接口的流量统计来评估当前线上真实 TPS 压力
如果性能目标是满足接下来半年到一年的业务需求，再根据业务增长速度，计算需要的性能冗余。

性能目标评估例子： 比如过去一年，用户数有 100 万，历史峰值 QPS 是 1000。如果接下来一年，我们的目标是用户增加到 500 万，那么线上实际需要的 QPS 目标就是 5000，考虑到业务增长不可预测性（比如超过 500 万）、服务器和开发资源的提前准备、业务的不稳定等，一般准备 3 倍性能冗余，即目标可以定为 5000*3 = 1.5 万，这样满足 1.5 万 TPS 要求的服务，在未来一年内，在软件层面，出现严重性能故障的情况，将比较小。

2、用什么压力模型来测试

如果是一个新系统，建议压力模型顺序：
（1）评估系统压力、拐点、不同压力下表现：用 负载测试（阶梯式加压），建议每个阶段增加的并发，能明显改变性能曲线。比如每分钟增加 100 用户，发现性能直接打满了，那就用二分法，下次每分钟增加 50 用户再试试。
（2）评估系统某个压力下，满足某个业务场景的性能表现：用 压力测试，比如一个持续半小时的活动，那就用目标压力，持续测试 1 小时，观察这期间系统表现。
（3）评估系统稳定性：用稳定性测试，目标压力下，持续运行 7*24 小时，观察系统稳定性，以及是否有内存泄漏。

以上三种压力模型，基本可以满足绝大部分性能需求。

3、建议：先熟悉服务端性能的基本知识

服务端性能的执行，其实大家学习一下基本都能搞定。
但是如果保障自己服务端测试的质量，即能准确做出满足性能目标的性能测试，需要好好考虑和熟悉性能测试的基本概念。
性能概念不清楚的，建议阅读：服务端性能测试 - 入门指南
性能测试工具学习的，建议阅读：服务端性能测试 - 工具篇 (Jmeter)

性能测试工具大同小异，一通百通。

测开目前看路窄，能做开发还是做开发吧，成为 T 型人才的机会比测开大太多了

奔着 100 分去吧，先别想着买房，先努力奋斗拼搏，钱、房都会有的。

我比你的起点低太多了，我家正儿八经的穷 4 代，全国倒数二本毕业，第一份工作在富士康，现在也在北京买房买车娶妻生子了。

我还是不够努力的那种，所以先努力做 100 分，然后我觉得你所关心的那些，用不了几年就会实现了。

复杂的业务，既可以增加你的行业知识深度，又可以增加技术深度，多好啊。

机会难得，能坚持做起来的话，下一份工作可能就跃升一个档次了。