这要区分内部测试还是外部数据抓取，外部数据收集走埋点上报，内部测试就简单了，设备端后台挂个监控持续跑数据就是了。脱机方案最简单就是 shell 后台脚本，权限是 shell 或 root 权限，设备端 adbd 不重启进程就在。

比如我自己设计的 shell 设备端监控 (https://testerhome.com/topics/20187) ，shell 脚本加个后台执行（&）就完事了，还可以配合自动化测试分 case 场景分别监控。

性能测试这事一定要 “聚焦”，目的是为了解决问题，最怕无目的的取数据监控，占了开销又没落地到优化。这个又分两个维度：
1、监控：建议在指定位置加埋点，样本量分析，结合具体的 case，在特定行为触发时上报数据，这块重点是采样点和采样频率控制。
2、筛出问题推动解决：找个合适的方案配合自动化 case 或手工测试做数据抓取和分析

对于 android 上的 app，后台查杀是常事，不是 rom 整体测试，监控时长配合进程存活时间做埋点应该是比较合适的监控方式，至于各家的埋点上报和后台数据统计报告都是各做各的，原理一致，方案和形式不一样。

还有就是监控上整合在一起了，fps 这个就没单独维护

• android 端监控方案分享

数据对不对要看窗口名是否对，这里的窗口名不是 activity 名，是 SurfaceFlinger 的 framebuffer 名。
adb shell dumpsys SurfaceFlinger 中最后一部分 Allocated buffers: 下面有对应名字。因为安卓 8.0 之后有分屏，后面有 #0 编号区分

这个不影响，可以注释掉，最初只是为了用 mac 地址对应下测试结果和手机。

技术是改善效率降低人力投入的基础，再有就是 TDD，能不能驱动开发解决问题并让衔接分析的环节更高效

评估压测为主，可以拦住随机压测中的严重问题，概率性问题补充 bug 数量跟进解决进度。当初我的方案拦过必现死机问题，连 MTBF 压测都没出。最后研发定位发现是研发新改动的判定分支有一个 if 分支是有问题的。

评估性专项，固定时长，固定压测范围的压测，多台设备增加样本量，至少两台吧。最后通过 bug 数量和发生频次评估稳定性，算是常规 ROM 测试中 MTBF 的补充

也不用，就是 monkey 测试中不改音量。15 年我是用这个方法解决的，做的 shell 管理 monkey 执行过程的随机压测方案，不过之前也被我弃了。安卓端新设计了基于 Hierarchy 信息解析的随机遍历方案在持续完善。
(https://testerhome.com/topics/3553)
(https://testerhome.com/topics/3685)

调小音量，monkey 事件比例去除 --pct-syskeys 0

用 minitouch 吧，可以模拟：
echo "d 0 P0x P0y 50\nc\nd 1 P1x P1y 50\nc\nd 2 P2x P2y 50\nc\nm 0 P0x2 P0y2 50\nc\nm 1 P1x2 P1y2 50\nc\nm 2 P2x2 P2y2 50\nc\nu 0\nc\nu 1\nc\nu 2\nc\n"|/data/local/tmp/minitouch -i
P0x P0y 移动到 P0x2 P0y2
P1x P1y 移动到 P1x2 P1y2
P2x P2y 移动到 P2x2 P2y2

实际坐标需要调一下

uiautomator，或 shell+uiautomator dump 的 xml 解析都可以实现

我是 07 年测手游（功能机时代开始），12 年测新事物安卓电视，13 年底转自动化，14 年承担性能专项建设，16 年主导用户体验相关专项测试建设，18 年去负责了 TNT 专项测试建设，今年年后这又开始建设服务机器人专项。还没想到之后会怎样。

可有一点：新领域都是缺解决问题的人的，有能力的人不要耗在成熟领域待下去，解决新事物，新领域测试方案能力的人，终归是少数。在 0 到 1 的测试建设中，会有很多机会主导建设过程，产生独立归属的价值产出。

我就是在 30 岁时转的方向，手工测试、带个组继续手工测试干了 6 年，决心转测试开发突破瓶颈。项目中实际尝试自动化解决实际问题，同时多积累不同层面的知识。机会来了独立承担 ROM 性能专项从 0 到 1 建设，做出成果就在其他同事那贴了 “标签”。之后猎头和内推机就不断找上门。转方向后这又 5 年过去了，到现在还是在做一些 0 到 1 的专项建设，积累解决问题能力。

测试大行业讲确实年龄线很尴尬，但从做事角度讲，能比别人更有效率做事，更独立承担复杂任务才是能力。核心竞争力还是经验积累下的解决问题能力，简历上能体现出对应经验亮点很关键。
测试圈子不大，核心研发圈子也不大，但人员流动大。如何让前同事有相关工作岗位时直接联系自己是关键，关键就是项目合作中，其他同事对自己帖的 “标签” 起的作用。

没影响，当初写的时候是为了取了下网卡的 mac 来标识设备用的，由于权限和芯片区别会使节点读取受限制。

写个 shell，手机端后台脚本运行，断开数据线等待跑完。
判定 ui 可以用 uiautomator dump 的 xml 解析，<node 前加换行，awk 用"间隔取对应信息。
操作可以用 input 或 minitouch，minitouch 在 shell 下使用方式：echo "d 0 $x $y 50\nc\nu 0\nc\n"|/data/local/tmp/minitouch，x、y 坐标默认竖屏，需要根据旋转方向转换下。

遍历压测方案替换掉 monkey，让测试覆盖范围可控。至于方案吗，有些改善版的 monkey 或 ui 遍历，再有也可以自己设计遍历逻辑。

价值产出就是通过测试方案、测试决策，自动化脚本方案设计，提高人效降低人力成本，扩展自动化支持的能力，参与质量流程把控，让测试的 “声音” 影响项目上线把控。

我经历的大多是专项测试需求从 0 到 1 的建设，之后 1 到 2 的维护逐步扩展团队支持。

设计测试方案实际解决效率、新领域测试等需求，单项目落地，案例介绍内部推广，收敛项目测试需求到统一 web 入口，网页交互提供测试服务支持。

不跑 monkey，设计按设定时间循环遍历，配合监控脚本获取 cpu、内存等完整监控数据，log 等。最后汇总分析

一是你窗口配置宽度不够被自动换行了，二是你没看懂原理，窗口名是要配参的，要实际查到要监控的窗口名再测。

最简单的测试设备连接路由器，路由器断外网。

可以先把需要用的数据一次性收齐，定义好存储方式和格式，呈现方式和把控线可陆续加。也可以用 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、到后来的带基础体验团队，可以让自己通过经验及对用户使用场景的分析，控制测试范围和节奏，减少加班。当然自己要承担少测部分的漏测风险。使自己的团队是加班需求最少的。当然逼着自己去实现专项自动化比例是重要的条件。

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

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