#11 楼 @sanlengjingvv touch 到应用层响应 intent 事件确实需要安卓系统优化,并非是 APP 做优化。但如果 app 的启动涉及监听广播启动,就得另算了,得具体问题具体分析。
单就性能测试而言,准确的性能数据是从 touch 算起。可以细分为两部分:touch 到 app 首帧画面;app 首帧画面到指定 activity 显示完全。第一部分涉及系统性能优化,后一部分涉及更多的是 app 自身的优化。
冷启和热启的性能数据可不是这么来获取的,精确程度和适用性很弱。以下几点原因:
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 状态,推进集成 “测试技术” 提高效率,推进人员培训提高测试人员能力等。
我认为综合在一起才是 “测试团队”。每个部分都可以单独提出来讨论,如” 测试技术 “。至于是否适用就得放到 “测试团队” 中去考量。
#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 转换出图展示。
继续等简历:应聘的,其他测试岗位帮内部推荐的,都可以发。
只要对应能力匹配,我即招聘也帮推荐:手工组、自动化脚本方向(Uiautomator)、隶属研发的测试开发工程师、乐视网 app 相关的测试岗等。
安卓设备的系统端性能测试日常工作涉及:
(1)性能专项任务执行
(2)性能评估用例设计及测试方案的执行与输出
(3)dailybuild 性能问题探索
(4)性能测试专项方案及脚本工具的开发与尝试
(5)后续组织手工组做性能培训
任务是阶段性的按优先级处理,目前除了已有测试专项的执行,其他项都是在探索尝试,还没有变成固定周期执行的任务。
#57 楼 @lanxiangtechnical 测试行业内少量正岗 + 外包形式的测试团队很普遍,本身就是现在正常的形式。
#41 楼 @465998951 好吧,我自己的成果是拿出部分做分享的,毕竟都是自己独立设计的,也算不上公司机密。上次你们来乐视谈过 “雷锋” 系统实现的功能,相关功能我们都有自己的实现方式,后续就没问过细节上的事情。
#39 楼 @465998951 你到是没把你那 “雷锋” 系统拿出来晒晒
#47 楼 @haiquan180 这就不是我能决定的了,你得问 HR。
#44 楼 @qa8335351 补充一点,现在自动化报告及数据可视化报告都是 Html 报告模板方向,这部分的基础设计也是短期需求,迭代更新的。为了报告更高大上,HTML 的报告还是很有价值的。
毕竟完成 100% 工作 + 报告很 low=体现价值 80%-90%
完成 100% 工作 + 报告很高大上=体现价值 100%-120%
#44 楼 @qa8335351 我们自动化组及性组除了自己的测试任务,主要是服务整个测试团队的自动化和内部工具需求。所以这部分需求也是作为短期项目实现后维护的,主要的还是内部的自动化任务需求。兼着这部分工作。所以有这部分能力,就是应聘的附加值。本身这部分工作都有人做,作为附加值的 backup。
#41 楼 @testor 这要看你的预期,能胜任现在执行任务,和用例编写,bug 提交跟踪的 “人手” 只能落地到外包岗,所以你如果想来要有预期,只要后续适应环境,工作表现突出,是有转过来的机会的。
其实我也是计算机相关专业出身,之后做了 6 年手工相关测试,在乐视我也是外包岗低薪进入,后续成果多了,并且内部团队挖我过去的组多了,转乐视就很顺畅。其实只要表现到位,扛任务责任并高效完成,机会很多。毕竟乐视在快速发展,在流程和测试手段完全成熟固定前,很多点可以创新出成果。
我应该算是乐视第一个专项做自动化的,边学边发展。后续测试总监到位才大力发展了自动化和性能测试。乐视这边的环境和支持力度很适合探索自动化和性能测试的有效测试手段。