可以先把需要用的数据一次性收齐，定义好存储方式和格式，呈现方式和把控线可陆续加。也可以用 highcharts 一类的框架做交互图。有几个点得想清楚解决办法，收数据的形式，如果是后台进程得做防后台查杀；收数据间隔，避免影响结果；引导优化落地点在哪，最终产出毕竟不应仅仅是评价，还要落地到和研发优化的对接。

看统计数据和 dumpsys gfxinfo 包名 framestats 的统计信息很像，看个平均值还可以。具体要落地到优化点有些不够，需要分维度抓优化方向。顺时卡顿，平均帧率提升，低配手机 SurfaceFlinger 的绘制效率，用户体验层面优化目标。

严格的需求管理和代码审查是必要的。之前工作中听过一个真实的事情，之前同事的同学做过的一个事。他在项目代码中的一个正常逻辑不可能执行到的判定逻辑写了行：“如果看到这行内容就说明你见鬼了”。之后很久也没什么事，偶然一天半夜雷雨跳闸重启，显示屏跳出了这行文本，结果把保安吓得不轻。

开发人员头脑一热写的无厘头彩蛋还是得代码提交审查来控制。还有一类之前见过的就是往 debug 版本 app 中加开发人员名单/合照的菜单，见过三次。

哎，是多说了些，其实无非是压了很久的看法，一次性小爆发了下。

只是对测试行业的浮躁氛围有很多看法，虽然自己也改变不了什么，表达下自己的看法和谈谈自己的经验总结。能做的只是管好自己，也就是和自己手下的人沟通这些看法，看是否有共识。再有就是和同样有实际解决问题想法的人去聊解决方案的设计。

其实测试技术成长，很大原因是自己逼迫自己去思考，去尝试解决，去扩展知识面带来的。给自己设定要解决的问题，持续尝试不同方案去提高效率和实用性。去主动在项目中依据测试结果传递自己的分析判定，并去推动高风险问题的及时解决。去尝试和研发人员在逻辑实现层面的对等沟通，并主动提供 bug 疑似问题点的思路，哪怕是判断错了，沟通中也可以从研发牛人那得到正确的回复，这都是一步步的积累。带团队就迫使自己多承担些，想想如何控制团队资源的产出成果的关系，毕竟同样的成果低于管理人员的预期资源使用量，可以积累良好评价和信任度。

在面试一些人的时候及私下沟通时，听到过很多声音，几个典型的问题，我是一直在问自己和反思这些问题

1、工作几年了，我要级别提高，我要涨薪。
问题是：你要这些是凭什么？
引申出的问题是：为了要到这些我要有哪些积累呢？

2、手工测试没意思，我要做自动化，我要学编程。
问题是：转自动化要凭借什么呢？对比下已经在自动化的人及懂编程语言的应届毕业生，竞争力在哪呢？

3、工作环境不好，没人做测试技术，没人教自动化测试。
问题是：作为个打工的，只是指着用人单位及其他同事教怎么干活？为了提高自己的测试技术能力，自己能做什么呢？

4、现在的测试没什么技术含量，就是点点点，干了几年也没技术提高。
问题是：就算是点点点，你能比别人快速发现严重问题？
你能比别人发现更多的问题？
你能自己决定哪些必须测、哪些要优先测、哪些可以不测试？
你能基于有限的测试结果判断是否能发布？
能把对测试结果的风险情况清晰的传递给项目组？
引申出的问题：为了能做到这些，日常工作中要有意识的关注和总结哪些信息呢？

等等，大量吐槽声音后带来的问题思考

主要是在测试行业内这么久，体会很深的是：
1、有想法踏实做事的人相对很少，听安排做执行的人居多。
2、有责任担当的人少，怕担风险、担责任安排全覆盖测试耗测试资源的人多。
3、以自己作为出发点思考解决问题办法的少，从其他人和工作环境找原因的多。

分享下我自己在测试工作经历中的做法，我是这么去思考问题和持续积累的，换工作时有些可说的。

1、做手工测试时：我会记住严重 bug 的复现逻辑，有条件情况下会和研发沟通 bug 产生的原因及解决的方式（逻辑层面的，不是代码细节），这些就成为了之后测试时优先测试范围决策的依据。也能看到哪些开发人员不靠谱，严重 bug 多，粗心引起的小 bug 多。哪些研发 bug 少且能主动自测。这样系统测试时，根据开发人员的历史情况也能决策哪些模块要重点关注。

招人面试手工测试人员时，只要是有几年工作经验的人，我都会问道：工作中你遇到过的严重 bug，举个例子说下。
可很少有人快速的把一个 bug 的完整信息及解决方式，很兴奋的说清楚。反而是要想很久去找个 bug 应付下回答。我接触过的手工测试的牛人，都是可以津津乐道的把严重的 bug 以及最终的解决方式讲清楚。

2、带组做执行测试时：拿到版本后，我会用一小时，自己过一遍重点的部分，之后才安排测试工作及有选择的安排重点测试。当别的组在催着加班完成所有测试时，我会通过经验和对用户场景重要性的判断，将不重要的部分在之后的迭代中安排周期性增量覆盖测试，从而减少加班。决定转型自动化后，手工执行效率低，重复操作多的，不靠别人，自己设计自动化方案尝试降低人力需求。

3、到后来的带基础体验团队，可以让自己通过经验及对用户使用场景的分析，控制测试范围和节奏，减少加班。当然自己要承担少测部分的漏测风险。使自己的团队是加班需求最少的。当然逼着自己去实现专项自动化比例是重要的条件。

说这么多，主要是建议想想这个问题：
做为测试工作从业者，自己的竞争力在哪。面对一年年的应届毕业生，一批批大公司出来的人员，一年年的过去，自己相对于他们的优势在哪？怎么能让自己的工作很难被替代。

这个问题我目前的想法是：要让自己积累的解决问题套路在工作中持续可复用；要想办法让同样的工作自己比别人的做法省资源出成果；要让自己在项目中展示自己工作成果的价值，得到其他人的认可；要让自己能在工作中担住更多的责任，能扛住的需求和责任多了，与项目中其他部门的沟通也就越有话语权，因为历史成果积累了信任度。

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

说到业务知识点积累及解决问题的经验积累，建议尽可以的熟悉了解业务，了解需求的细节，了解可被利用的数据来源和开源方案。要实践对比优劣，设想适用场景，组织利用形式。这其中就是要多想，多了解，多尝试。不过有很多人在做的事情就是了解为主，别纠结太多了。比如 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