#18 楼 @fanlei1014 我知道这种情况，其实乐视的 SurfaceView 更多，live3 路视频流。后面还要上 9 路视频。。。
这个场景下监控 SurfaceView 获取的是所有 SurfaceView 窗口帧累计的情况，其实就是屏幕被 SurfaceView 分割不同部分分别刷新，但记录都是记在 SurfaceView 名下。由于是累计刷新帧率会相对单片源提高一倍左右。40 帧 + 的情况。多路场景将目标 KPI 提高进行评价就是了。
建议正常 UI 响应按 60 帧评价，单路视频流按 25 帧，多路视频流按 50

#14 楼 @zhangzhao_lenovo 其实视频播放就是监控 SurfaceView 的绘制，弹幕的话得看是不是也是在这个 window 上绘制。

PS 播放器本身在处理视频流是是有丢帧处理的，视频播放场景主要可以判断的是帧率提高到 50-60 的现象基本都是卡顿加载，换内容切换的时刻。

测试是按窗口测试的，sh /data/local/tmp/fps.sh -t 25 -w SurfaceView。视频类流畅度我是按 25 帧目标值打分的，很多视频流都是 24 帧的。

#10 楼 @zhangzhao_lenovo 什么图？csv 直接 excel 作图的？我工具里提供了 csv 转 html 交互图的脚本。

至于帧率，本身视频的帧率就是动态的，一般是 23 到 25 帧吧，得看具体的码流。如果帧率到了 50 到 60 帧就是 UI 刷新的帧率了，可能是加载缓冲，切换内容之类的 ui 展示操作引起帧率提高。

#42 楼 @yiyusixing 我还面过简历造假，答不上来后自己承认是抄的朋友的工作经历。确实是个” 老实人 “混不过去了还知道坦白。

其实老大们看的是扛任务并按时完成的能力至于如何解决的他们不关心。倒是关心人员变动会不会带来业务上的不稳定，换人就干不了了可是要担风险的。

#37 楼 @monkey 是的，我也是这个观念。只要有清晰的解决问题思路，落地实施其实都是小事。通过搜索引擎，team 内讨论，他人协助都可以解决，能完全独立解决更好。通过解决能力的程度定位人员能力层次：无思路有执行力基础的就定位在已有专项和脚本方案的执行人员；有思路但需要协助才能解决问题的就是待培养成长的中层设计人员；能独立设计解决 “测试需求命题作文 “的就是高级能力人员了。

我面试应聘者都是先聊历史经验确定工作经历真假，追问过去所做出的成果和具体事项的实现细节。然后是展开问解决问题的能力，用自己已经解决过的测试需求或正在解决的测试需求询问解题思路。在过程中会追问几次解决问题的细节，看应聘者是不是能做相关的事情。
其实测试工作还是解决任务需求的能力，用解决任务需求能力去衡量招进来的工作定位。

#5 楼 @CloudHuan Highcharts

#3 楼 @zsg5566 是的，性能落地到数据，还是客观操作录像获取的数据能让相关团队人员信服。

高不成低不就，能力和工作任务匹配很难，一样很难招人。人心太浮了，追行业薪资高点的人多了，踏实做任务的人少了。高薪资一方面是公司能不能 cover，还有就是薪资和所负责的工作任务是否匹配。
所以要不搭好框架招 “人手”，要不招基础还不错，有内在驱动力学习的人来培养（承担可能独立后闪人风险）。高薪人才很多面临工作能力上的 “水土不服”。

#1 楼 @monkey 假期时常昼夜颠倒。。。

#11 楼 @sanlengjingvv touch 到应用层响应 intent 事件确实需要安卓系统优化，并非是 APP 做优化。但如果 app 的启动涉及监听广播启动，就得另算了，得具体问题具体分析。
单就性能测试而言，准确的性能数据是从 touch 算起。可以细分为两部分：touch 到 app 首帧画面；app 首帧画面到指定 activity 显示完全。第一部分涉及系统性能优化，后一部分涉及更多的是 app 自身的优化。

#7 楼 @addison 去测试进程从后台状态恢复并没有太大的实际意义：
1、都清楚从后台直接唤醒会更快，管理好更慢的两个启动场景即可
2、用户实际使用中是会管理后台进程的。无论是手动回收后台进程，还是系统优化测试超阀值触发回收，进程始终是要被从后台清理的。
我作为系统端测试，对于抢占后台资源的行为都视为 “不合理行为”。进入后台需主动释放资源控制 PSS 和 CPU 占用，否则当触发系统优化管理措施的阀值，就会主动回收。我给预装测试提供的性能把控方案就严格控制了后台资源占用。

冷启和热启的性能数据可不是这么来获取的，精确程度和适用性很弱。以下几点原因：
1、启动方式并不是 am，而是点击。这就涉及从按下屏幕响应，硬件上报，软件层响应到指定页面显示整个流程。
2、APP 的形式并不只有独立存在的方式，还有组件形式集成，由其他 app 的指定操作唤起
3、对用户而言完整的启动流程是：点击到显示 app 首屏画面，至于之后的加载等处理就是 app 的流程了。

实际性能测试中是严格录像计时的，按下到首帧响应时间。而冷启和热启在这里的区别是首次无数据启动，和完成过初始化流程后的再次启动。
冷启动：无数据的首次启动。
热启动：非首测启动情况，无初始化欢迎界面和首次初始化过程。

从脚本来模拟最好还是实际流程模拟，发送 touch 事件响应后到指定 activity 显示。即：
1、在发送 touch 事件后记录起始时间，精度到 ms
2、当 SurfaceFlinger 的数据中有指定 activity，记录结束时间精度 ms (dumpsys SurfaceFlinger|grep -c "指定 activity"；非零则存在)
3、两者做差就是所需时间。

。。。没必要匿名，再发一遍

我认为把 “测试任务” 和 “测试技术” 分开理解讨论就好了，本身测试技术就是要讨论解决测试效率和持续有效运作的流程和框架。

每个测试团队扛的是 “测试任务”：测试验证覆盖率，bug 产出，用户反馈 bug 回溯跟踪。

而服务于测试效率的是 “测试技术”：自动化 UI 功能验证相关框架，专项压力脚本方案，手工辅助性测试工具，服务测试流程的框架模板等。

统筹人员和任务流程的是 “测试管理”：协调各测试任务的人员配比，对接配合部门接口需求，控制用例覆盖程度，管理追述 bug 状态，推进集成 “测试技术” 提高效率，推进人员培训提高测试人员能力等。

我认为综合在一起才是 “测试团队”。每个部分都可以单独提出来讨论，如” 测试技术 “。至于是否适用就得放到 “测试团队” 中去考量。

#38 楼 @shandi 工作相关事情很忙，我自身工作积累偏向安卓设备端系统测试，TV，盒子等安卓设备上的系统测试的积累，侧重性能测试和脚本自动化压力方案。
看你们组织的都是偏向 app 测试和接口测试的内容，不过你们北京组织活动的地点有我不少回忆。我在中国电子大厦 B 座 4 和 5 层的 Gameloft 工作了近 5 年，后来 4 层退租了，还真不知道现在什么情况了，多年未去了。

#17 楼 @fenfenzhong
我的方案是实时监控和后台长时间监控并存，观察数据变化。下图是监控的数据图展示，每段采样数据信息都有，单帧渲染最大时间也有，时间戳可以对应 log 时间点

我的看法：帧率只是一方面，稳定帧率不代表不卡，丢帧比例和最大单帧渲染时间也很重要。
如果帧率稳定，所有帧的渲染时间差距不大，自然可以算流畅，因为没有忽快忽慢引起用户关注。
如果丢帧比例少，且丢帧时渲染时间远超正常渲染时间，就会很明显被用户察觉到差异。

#2 楼 @vigossjjj 我认为这是综合评定的，我自己设计评价规则时，定了个规则。
满足帧率 kpi 占 50%，满足 kpi 的两帧间隔帧数/总帧数占 40%，帧间隔 kpi/最大帧间隔占 10%
流畅度得分（%）=(FPS/目标 FPS)*50+(KPI/最大帧间隔)*10+(1-超 kpi 帧数/总帧数)*40。

丢帧率代表持续卡顿，最大帧间隔代表最大卡顿持续时长。

#3 楼 @fenfenzhong 是的，第二列同步时间相同，出现两次，中间还间隔几帧。会导致依次做减法出现负数。
我也是在监控红包弹出框时发现的，你试下红包的弹出效果，高概率出现。就是抖动的动效会有相同帧被复用的情况。

我自己是写了个 shel 脚本分析 dumpsys SurfaceFlinger --latency + 获取的数据，其中遇到两个坑：
1、第二列垂直同步时间会刷 9223372036854775807
2、存在相同帧重复利用的情况，同一帧先后间隔被用两次。比如微信红包弹出效果，就频繁出现重用的场景。

马上要用上机械臂来测试性能响应和帧率，脚本方案被我搁置一旁了，后续有时间我也拿出来写写。
我写的 shell 脚本是直接手机端后台取数据，既可以实时输出到控制台查看，也可以后台自动记录为 csv，后续 csv 转换出图展示。

#17 楼 @heranjin 发生 lowmemorykiller kernel 打印的 log，我只是举了个实际发生时的实例。

#74 楼 @testly 差不多，因为没电话面试环节，根据简历，简单沟通后以面谈为主。

#72 楼 @testly 哎，我也没办法。简单发个招聘需求，双方都不能很好的了解核心需求，会导致沟通效率和面试效率差。
我先把自己的核心需求和所有情况阐述清楚，这样再沟通就可以在关键点上直接交流。