安卓端适配,8155 的 android 11，车机分 android 和 qnx，监控方案不太一样，按需重新搞了

搜杜比和 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 操作到事件分发被忽略，而且虚拟屏传画面并不等同外部摄像头，也是有本身的开销和传输影响带来的时间差，就看精度要求程度了，还是有偏差的。

要看是自己的产品还是他人的产品：

自己公司的产品，其实是在评 “底线” 即优化线，是要触发研发团队专项优化任务的；
竞品，其实是设计套 “试卷”，对比个结果，找出优略，要不想办法拉齐后赶超，要不就是找下宣传点，介绍下产品优势，推动销售；

除非有公开业内认同的标准，使用户体验评测在同一把 “尺子” 下来开展，否则就是结果导向，有具体的目标指向的测试专项罢了

测试行业走的久的，是要增强自己的专业深度和不可替代性，要有些自己的解决问题办法，思路，技术方案，立得住 “专家” 角色；有很多优化 “大坑” 是要更资深的人带着解决问题。要不就走人脉，很多时候都是同事拉前同事再就业，在团队管理上，对认可的人的信任感，和抗责任能力，没有合作的人很难快速进入团队。有人走的位置高，跟着的人也是不少的。

08 年印象最深的是公司发消息：由于金融危机，每三个月的绩效暂停。
当初底薪低，加班费按比例，就等三个月绩效提高底薪，结果金融危机暂停了

同感，我是 07 年进的测试行业，从手工、自动化、带专项组，到现在抛开项目写测试工具方案；项目上从最早功能机时代的手游测试、到智能机、智能电视、机器人、车机，其实积累还算是逐渐增多的，可现在回头看，测试无非就是这点事：就看谁有明确的解决思路引领项目测试按计划展开，懂的人引领进展，走管理的带团队，走技术的搞方案，没啥想法的干执行，无非不同角色的人的不可替代性的区别，其实都可以被替代，只要研发质量控制的好，可正因为研发过程不可控和不可信部分，才有质量保障的空间，测试人员的工作。
到之后无法在测试行业继续发展下去，下一步干啥？其实我也一样不知

testin 搞过类似的众测，发个 app，领任务，限时段内报 bug，按有效 bug 给钱，开始是给第一个报的人，后来改了分配规则；最早期对于测试能力强，报 bug 快的还算能领点外快，后来改规则后就是越分越少。最开始时新鲜感参与过一周，后续就没参与过了，抢任务还限时测试时间，实际收入和参与耗时感觉得不偿失。
感觉这种众包测试，如果要求多，限制多，保证基础收益才会有人持续参与，如果像抢红包一样，会逐渐让人失去兴趣，抢红包只是点一下，可众包要干的事多

16 年的事了吧，忘了具体时间，也不知道后来咋样了，这么多年没太看到众测的发展

手机 rom 测试的话，分滑动场景，持续滑动取连续滑动期间的帧率，测性能的机械臂也是一样的方式。

滑动的效果有起始、滑动中、滑动结束后的减速效果，而且还跟滑动动作速度有关。要看评估哪段区间。整体帧率会被起始、结束和操作动作影响。

每台手机的 device 是固定的，而且不同。参数按 device 对应固定的手机号

很简单，接收命令行的传参获取手机号，不同 device 执行不同的手机号

作为写过方案实现分享的人，看着没技术讨论氛围、回复询问的都是如何执行、没技术解决方案讨论，逐渐就懒得写了。虽然自己还在做新思路的尝试，逐渐也不愿意分享出来了。单向分享输出无回馈，感觉不到分享的价值。

你可以看下最新的处理方式：https://testerhome.com/topics/20187

需要重视用户体验，这代表测试对用户体验的把控，至少有理有据提出问题，进一步推动其他部门对用户体验标准的共同认知。之后形成标准把控，减少争议讨论。

shell 的 if 判定条件，其中之一为空就会报这个错误提示。如果不想看到报错，用字符串比较，左右加个相同字符。如：

if [ "a${pod_status}" == "arunning" ];then

设备端后台脚本执行，间隔轮训查看执行状态

dumpsys gfxinfo 包名 framestats 历史 127 帧数据用脚本计算，并不是 rom 都开了 fps 计算，再有 gfxinfo 不统计 SurfaceView。我是不用它，数据实用性差，没多大意义。