#31 楼 @xiaolinzi 哎,百度就知道 busybox 是干什么的了,这是手机端版本。
安卓脱机很简单,shell 后台脚本控制就好了,操作脚本就抛给 uiautomator 解决。
其实感觉测试方案应该和 app 产品本身脱离,即不修改 app,也不需 app 集成任何插件。直接在用户的 user 版本展开测试是理想效果,用户环境真实测试。
不同项目不同负责人不同玩法,关键是解决业务需求。我就建了自己的方案:(https://testerhome.com/topics/4775)
主要是实际点还是高帧速摄像头录像实际测试吧。上了性能机械臂 240 帧录像,基本就不依靠脚本方案了。。。。。。
#29 楼 @zhangzhao_lenovo 。。。脚本执行说明很详细的写了
#18 楼 @warcraft1236 要了解细节百度就好了。
【Android framework】am 命令启动 Activity 流程 (http://www.cnblogs.com/sickworm/p/4220139.html)
Android4.0 input 事件输入流程详解 (中间层到应用层) (http://blog.csdn.net/wlwl0071986/article/details/8247138)
#27 楼 @zhangzhao_lenovo 先看窗口再测试,不是说所有播放都是用的 surfaceview,也有自己封装播放器播放的,例如 youtube
#23 楼 @fanlei1014 PS:为什么把弹幕做成了两个 SurfaceView,好奇怪。我看了下我们的弹幕 UI,视频流是一个 SurfaceView。弹幕是占用独立的 PlayerActivity 刷新。
#23 楼 @fanlei1014 看了下数据,发现是我设计脚本逻辑时没处理这个场景。dumpsys SurfaceFlinger --latency SurfaceView 的数据在多窗口情况下是间隔一个空行保存的。数据本身是可以分别计算每个 SurfaceView 的帧率的,之前做完方案搁置,就没有把所有场景考虑全面。
后续有时间我更新下这种同名 window 共存情况的数据处理逻辑。
#82 楼 @ycwdaaaa 其实即懂测试又懂开发的很少,大部分靠培养。我的认知里主要是两类人各有特点,作用不同:
1、手工测试学代码转开发,特点:
(1)了解手工测试” 痛点 “,在设计脚本和工具时更贴实际需求,但受代码能力影响在开发进度上得妥协下时间或找人协作。
(2)对接手工测试需求可以很快沟通理解达成一致,并且会在沟通中引出进一步的核心需求和扩展需求
2、扛不住研发压力向测试方向转的研发人员
(1)研发能力中等,不了解测试,在设计脚本和工具时更侧重直接实现需求,不会主动扩展测试目的的核心需求。
(2)由研发转测试的目的主要是逃避压力,扛任务压力和搭建完整方案的方向适用性不强。
我属于第一类,其实两类人搭配在一起各取所长完成任务更合适,并且也可以互相促进深入掌握对方优势部分。
第一类对接测试任务需求,可以使脚本和工具的逻辑设计更贴近使用者。第二类协助实现,提高脚本及工具变现的进度。
#21 楼 @fanlei1014 单路视频片源帧率还真低,看来视频码流和清晰度打折扣了。弹幕是刷的 ui 不是视频,相当于一路是视频的 15 帧,一路是弹幕 ui 的的 50-60。一路视频一路 ui 相当于 25+60 来评价了,不过视频本身也有扣分。
视频流卡顿刷 ui loading 也是会带来帧率上升的。相当于顺时两路 ui 的 50-60 范围帧率了。
弹幕场景还是按整体评估吧,毕竟用户体验需求是 “视频 + 弹幕 “
#16 楼 @warcraft1236 am start 的启动顺序和由用户点击启动的流程完全不一样,在 app 首帧启动前的开销无可比性。
哎,收不到简历很久了。。。
#17 楼 @zhangzhao_lenovo 写的很清楚啊基于 SurfaceFlinger 的数据,数据本身是安卓记录提供的,我只是拿来计算。计算方法和逻辑是我按自己目标需求设定的。
#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 我还面过简历造假,答不上来后自己承认是抄的朋友的工作经历。确实是个” 老实人 “混不过去了还知道坦白。
其实老大们看的是扛任务并按时完成的能力至于如何解决的他们不关心。倒是关心人员变动会不会带来业务上的不稳定,换人就干不了了可是要担风险的。
我面试应聘者都是先聊历史经验确定工作经历真假,追问过去所做出的成果和具体事项的实现细节。然后是展开问解决问题的能力,用自己已经解决过的测试需求或正在解决的测试需求询问解题思路。在过程中会追问几次解决问题的细节,看应聘者是不是能做相关的事情。
其实测试工作还是解决任务需求的能力,用解决任务需求能力去衡量招进来的工作定位。
#5 楼 @CloudHuan Highcharts
高不成低不就,能力和工作任务匹配很难,一样很难招人。人心太浮了,追行业薪资高点的人多了,踏实做任务的人少了。高薪资一方面是公司能不能 cover,还有就是薪资和所负责的工作任务是否匹配。
所以要不搭好框架招 “人手”,要不招基础还不错,有内在驱动力学习的人来培养(承担可能独立后闪人风险)。高薪人才很多面临工作能力上的 “水土不服”。