搜杜比和 dts 的测试 demo,做杜比或 dts 认证的话还有专门的测试文件,都是能找到的:
比如,随便搜下找到:
https://www.zhihu.com/tardis/zm/art/424772851?source_id=1003
https://zhuanlan.zhihu.com/p/297008675
这只能说明招聘的公司:不着急且有的挑,赶上急招和长时间无应聘的情况会相反
测试左移是测试流程中,测试介入向左移,感觉标题把左移概念扩大了
测试卖工具得走供应商路子,赚的是项目的钱,不过得让工具有 “价值”,能解决痛点,还得有软硬件 “包装”
感觉更像是智慧版的 monkey 方向,立个专项,给云测配个执行端的 “大脑”,不过没给 bug 判定,去重提交,版本线的 bug 追踪配 “大脑”,流程上的决策跟踪,离托管还早
其实 app 的响应时间相应 case,大多结果控制在秒级,顶多关注到 100ms 级别的优化,一般刨除和收益相关的广告之类的影响,底线之内,容忍度很高;
流畅度≠帧率;基础帧率满足后,帧率的稳定性决定流畅度,其实流畅度的优化是拉高均值,和拉平波动,卡顿优化主要在这,相关 bug 也出现在这里,平均帧率低或帧率波动,用户明显感知
其实性能优化往往是在功能需求实现的后期,大头是降低 cpu 和内存占用,响应时间和流畅度是看看是否超内部标准(如果有),再有就是 “民不举官不究”,先有抱怨再有专项优化,这是在项目上往往会面临的 “倒挂” 状态
再有真实的性能测试其实服务于提出问题或客观评估,手机做 rom 的客观评估大多用机械臂结果,毕竟卷的厉害,出个客观结果也是用于发版评审或竞品对比;做 app 的其实对响应时间的容忍度大多很高,有个可接受内部底线,控制在底线内即可;往往流畅度、卡顿的抱怨和优化需求反而更高,相对于响应时间,帧率和流畅度评估往往更容易出 bug 要求优化;再有就是 rom 层面平衡资源占用,要求瘦身,更多是用到负载类数据;综上,单搞响应时间工具被应用的场景,频率都不算很高,产生有意义的 bug 的产出完全看各项目的容忍度
并不是,真实硬件的性能测试是从触屏开始,模拟触控操作是事件注入,从操控上就产生时间差,scrcpy 传输屏幕开销也有时间差,这个方案本身就不能等同真机性能测试,所以首先对结果的阐述要说明这点区别;所以基于真机的机械臂 + 触控 + 摄像头的外部硬件性能测试的客观性才有它的市场
对于忽略以上因素和脚本本身资源开销影响,这个方案只是内部取数据评估也有一定意义,尺子相同,可以讨论问题;相对于客观的机械臂,相对准确的响应时间:起始可以从 getevent -lt 拿到,结束可以从目标 Output Layer 的 vsync 拿到(dumpsys SurfaceFlinger --latency “Output Layer 名”),其实相对客观准确的响应时间是这个
基于视频流并不准确,TP 操作到事件分发被忽略,而且虚拟屏传画面并不等同外部摄像头,也是有本身的开销和传输影响带来的时间差,就看精度要求程度了,还是有偏差的。
要看是自己的产品还是他人的产品:
自己公司的产品,其实是在评 “底线” 即优化线,是要触发研发团队专项优化任务的;
竞品,其实是设计套 “试卷”,对比个结果,找出优略,要不想办法拉齐后赶超,要不就是找下宣传点,介绍下产品优势,推动销售;
除非有公开业内认同的标准,使用户体验评测在同一把 “尺子” 下来开展,否则就是结果导向,有具体的目标指向的测试专项罢了