经历过了就多说了点，希望可以帮到些要在测试工作上走的更远的人少走些弯路，有没有用自己体会吧。

说到业务知识点积累及解决问题的经验积累，建议尽可以的熟悉了解业务，了解需求的细节，了解可被利用的数据来源和开源方案。要实践对比优劣，设想适用场景，组织利用形式。这其中就是要多想，多了解，多尝试。不过有很多人在做的事情就是了解为主，别纠结太多了。比如 UI 自动化测试，大多数人在做方案的 “红海” 不好出有个人特色的解决方案，大多是一层层的依赖包装，且同类 “竞品” 太多。找找 “蓝海” 构思下其他人没在尝试的事情。

我的看法测试人员应该是个 “杂家”，各方面都要有些积累，至少做到了解，这样设计解决思路才有资源可以组织。而且项目中可以和各部门聊需求。除了业务自动化，测试流程自动化对接，解决评审流程效率等方面还有更大的空间。

我习惯于目标需求倒推实现思路，多积累实现思路让自己在构思方案时有多条路可以选。

说道对优化测试投入产出比，优化测试方案的资源占用的意识形成，也是和经历有关，每份工作的大起大落最后都和成本控制有关。毕业后在 GameLoft 做游戏测试，就是手工测试事无巨细的报 bug，其实回想起来很多 bug 到项目结束都没解，最后 12 年测试经理以下全部裁员。

之后外包去联想做智能电视的测试，工作团队小才开始注重有意识的报重点要推动解决的 bug，不重要的 bug 少投入些精力。结果联想控制外包成本，清理合作的外包公司，出项闪人。

在之后就是乐视的大起大落，不过这段经历确实是我成长最快的，反思最多的。压得需求多了而且提出的需求越来越大，得靠自己想办法落地，测试团队也是膨胀到裁员收缩，经历事情最多的一段工作。当然乐视的现状很多人都清楚，但内部大起大落的经历不是外部人员能了解的。

陆续的经历，反思下来测试这个花钱的部门，能省钱做事，有套路积累快速落地解决问题，第一时间输出质量风险的人，在每次成本控制，一批批裁员，都会是最后被坚持留下来的。因为踏实做事，持续产出，积累认可度，甚至影响项目团队质量把控的决策。

这样被需求的测试人员，工资待遇，工作机会都是会主动找上来的。

也不算是理论知识，更多的是个人经历的体会。我是干了 5 年手工测试后看到瓶颈在 13 年底转的自动化，当时给自己找的定位是：想办法积累自己构思设计的解决方案，依靠成果输出转向自动化，不拼代码能力拼解决思路的方案设计。之后就是持续的解决思路构思和具体方案的实践，积累多了职业角色就转变了。13 年底起就一直持续积累方案，形成自己解决问题的套路。

我最初做自动化就是从实际解决重复执行的测试专项入手，最初做的是历史版本升降级的遍历自动化覆盖测试，因为最初手工测试安排这事就是安排人等着升级过程点点点，最直接解放人力的点。后来设计的脚本方案在业务中持续迭代和多次重构实现思路，对比优略沉淀出设计思想层面具体的套路。脚本方案持续迭代用到我离职时还在用。长期迭代的脚本方案可以锤炼代码设计意识，还是要多构思多对比。

我的自动化方案设计经历基本都是零基础起点构思，承担性能专项和后面基础体验专项也是。面对需求想办法构思解决问题，逐渐形成自己的解决套路。当初 14 年 4 月接性能优化这事，老大就一句话：团队中想了一圈就你能接这事，性能优化这事就交给你了。之后他提的需求也是很大的，完全要靠自己去构思落地。我是挺感谢这段经历的，当业务上有大需求压过来，扛住解决了，技术上确实成长很快，因为想的更多了。

最有成就感的是做预算时，被老大问：你就报这么几个人？够用？ 自己能有底气回答：够用。 因为说明自己的套路是有用的，用了比其他人预期更少的人力资源。再有就是自己做的方案实际解决人力需求的时候，同样的测试需求节省了资源产生了价值。

先总述下我的看法：
对于测试部门这个成本开销部门，能省钱做事，控制质量风险和资源投入，测试过程和研发资源配合不脱节（不能光关注产出 bug，不顾研发解决能力，尽量配合研发人员解决能力有重点有节奏的输出 bug），掌握这样能力的人是必要的。为了成为这样的人自己去积累解决 “套路”，业务中实践或个人实践均可，形成自己的经验积累。这些快速落地解决问题的 “套路” 就是测试技术。

所谓测试技术无非是需求中来再回测试执行中去，务实的一步步解决问题。当然合适的工作环境及团队氛围可以促使一些新 “玩法” 产生。

根本上来说测试服务于研发阶段的 bug 发现，发版阶段的量化评审，长期项目的持续质量把控。而这其中自动化也好，基于技术方案的专项评审也好也是服务于测试效率提升及测试覆盖范围扩大的。

所谓的 “土壤” 更关键的是该业务对测试质量的重视程度，对测试质量重视才能尊重测试人员的产出结果，做出成果的测试人员也更有成就感。

做测试技术的人最终目的是什么？
我的看法是：
1、节省测试成本包括人力成本、沟通成本和测试软硬件资源成本；
2、通过测试方案设计平衡资源投入的产出比及必要的评审需求支持。

为了最终测试目的，怎样才算懂测试技术呢？
我的看法是：
1、积累自动化解决重复执行工作的各种 “套路”，有需求时可支持快速落地自动化方案去减少执行人力。（手工执行的人力投入是测试过程中最大一块成本）
2、根据项目对质量把控的要求，分阶段有节奏的配合研发资源推动 bug 修复和用户体验优化。也就是通过测试策略设计测试把控范围选择，利用有限资源尽可能扩大覆盖范围。这其中指标性评审项建设，及分阶段的测试资源投入与产出效果平衡就是测试技术。

看描述是拿到 framebuffer 做实时编码？这是肯定要占用不少系统负载啊，而且传输画面的延迟是多少呢？

既然是方案自然就得多考虑通用的实用性，和执行效率。总要有个最优的目标，能不能做到是另一回事。神经网络相对于 opencv 的优势不就是准确率和识别速度，做方案还是要有个更高的预期需求。

图像采集一般都得是 C，要保证帧率，python 调用接口保存图像采集的帧率只有 15 帧。

安卓上一些简单的响应时间 case 也可以用固定帧数的 vsync 时间戳来算时间，这个精度还更高，起始位置时间从 sendevent 模拟操作的时间错，精度到微秒。

在测试行业十几年了，明显感觉到两个词：惰性和惯性。反思下来早期的自己就是这样，习惯于接受工作要求现状，习惯于找测试工具或开源项目直接使用。而技术成长最快的时候，反而是自己坚持要独立做解决方案，不断构思解决思路的过程。需求由具体业务需求中来，自动化方案思路打磨也是在业务中，剩下的就是思路创新尝试，解决思路的扩展与沉淀。

测试行业缺的是有独立想法推动问题解决的人，越早认识越受益。在之前招人的过程中也接触过毕业一两年就在工作中成为自动化负责人的。很明显的特质是：主动探索尝试，花时间将方案落地到项目，实际产生收益后便成为了这件事的负责人。主要是兴趣导向，主动独立思考解决问题，并承担具体的任务责任。

至于工作时间被手工测试占用等问题都是可以解决的，可以和领导谈，尝试自动化落地的时间投入是要领导支持的，但同样顶的是限时尝试，要在限定周期内出成果。

应聘时应该能听出来的，负责人明确说了是招技术强做技术创新的，换言之就是目前公司内测试技术落后需要有个人推动改善。本来招你就是为了干这事，指着别人就别想了。
所谓的技术创新就是看你能不能引入自动化等手段改善目前的工作方式，是要你主动尝试并尝试推广的。其实算是个有挑战但有空间的职位，毕竟没自动化积累，只要你引入并实现了，你就是该公司的测试技术负责人了。

设备端 atx-agent 真有必要？shell 脚本后台执行也可以解决同样的需求，网络 adb 下起后台脚本管理测试执行的过程和具体的调用，shell 脚本还能额外开发功能能力。

安卓做语音测试挺简单，sendevent+stagefright，sendevent 负责做指定位置的按下抬起，stagefright 负责按下抬起之间播放 wav/mp3 样本。

窗口名错了，你取的是 activity 名，实际上窗口名是 “SurfaceView - com.youzu.unity.test/com.unity3d.player.UnityPlayerActivity”，有空格传参需加双引号

还有就是 adb 一行命令执行，双引号需转译，要不就 adb shell 之后再获取。

流畅度是按场景把控的，主要是滑动列表场景、动效场景等，具体看你们的把控范围要求。流畅度是硬指标，手机屏幕是 60 帧、MTK 有些 59 帧屏的产品。UI 交互场景帧率一般良好体验是要 50 帧以上的，重点关注帧间隔大于 100ms 的卡顿，游戏的话大于 50ms 的卡顿就很严重了，具体看是否锁帧，锁帧的一般是 30 帧，不锁的都是 40 帧起步，50 帧以上良好。

每一帧绘制都是由 vsync 通知开始，我这个方式就是用 vsync 间隔来衡量的 fps，刨除重复绘制相同画面这种异常情况（如反复刷布局），实际 vsync 就是和用户看到的帧一一对应的。gfxinfo 是和帧绘制耗时相关的，你可以打开开发者模式中的显示数据到屏幕看到，每一帧的数据展示是实际开销，有小于 vsync 间隔的也有大于的，这部分并不是实际画到屏幕上的时间点。

理解下原理，数据源是安卓 SurfaceFlinger 的接口，安卓系统源生的数据，每个窗口都是独立的数据，只要窗口显示就会一直保存历史 127 帧的绘制数据。而获取数据上我的脚本是间隔 1.6 秒累计的从窗口创建到退出一直在统计。

下面回了好几次了，测试窗口要和目标测试的一致，而且安卓 7.1 后窗口名改了，手机打开要测的窗口，实际获取后再测试。这种情况主要就是窗口名配错。

是这个格式，这个是实时窗口查看，也可以存文件出图。具体的窗口名得打开游戏用 adb shell dumpsys SurfaceFlinger 实际看下。

一样用，就是换下窗口名。一般游戏引擎开发的都是在 SurfaceView 中绘制，安卓 7.0 以下直接监控 SurfaceView 窗口，安卓 7.0 之后有了分屏，名字被改了。变成 SurfaceView - 包名 #0 这种，具体取一下传进去就可以用，只是注意有空格需要英文双引号。

搭个 dzzoffice 还能文档协同

PC 端是 jenkins 任务，这事在之前乐视时就开始做了，没 app 在 IOS 上的单发目前没测 ios

我设计的脚本方案，思路上是脱机执行的，jenkins（搭建在 ubuntu）用 bash 写 shell 脚本连接设备，至于是 usb 还是通过网络 adb 看具体需求。设备端起后台脚本-》PC 端周期判定是否执行完成（后台脚本是否退出）-》等待完成后 pull 结果并生成测试报告-》按需邮件发送

单纯软件层面的话优化动态壁纸下的 cpu 占用吧。增加的绘制开销毕竟是必不可少的。

拆机接 powermonitor，测场景功耗，直接同版本对比静态壁纸和动态壁纸的耗电电流增量。

把监控这个很简单的事搞的复杂了，最不厚道的是要上传生成报告。安卓上做监控不建议用 apk 的形式，主要的问题是：
1、监控是要后台持续运行的，而国内五花八门的系统都会有一个后台查杀策略，跑在安卓层面的监控是受管理的
2、cpu、内存、fps、gpu、电量、温度、屏幕亮度、cpu 主频等数据无非是 dumpsys 取服务信息或 proc 节点，取出来保存为 csv 本身就是挺简单的事，技术点是获取数据的代码逻辑效率
3、至于生成趋势图就更不是大问题了，python+highcharts 框架直接解决

最初我搞 fps 计算方案就是看不上 gamebench，取个帧率还做个 app 还要登陆收费，做个测试工具不能开放些？本身就不是什么有技术壁垒的事

悬浮窗的方式有利有弊，优势是操作中随时可关注，弊端是额外增加了绘制开销。