测试需求的解决思路和方案更重要，测试工具只是服务于测试需求的，展示思路构思和实际落地过程的案例过程，方案迭代的优化思路。我是认为测试工具本身不重要。
我当年从手工转自动化就是给自己定位设计决绝方案，后来换工作一方面是同事关系另一方面就是靠测试方案的实际案例说明，解决思路介绍。

我的感受是：风向变了，面向业务快节奏推进，灰度发布快速迭代收敛问题。
这个风向下：上线把控底线要求是什么？自动化能支持的能力和效率是什么程度？问题自动上报到快速迭代推送更新的流程和效率要求是什么？
面临这么多问题，有些人是准备好 再交替，而互联网思维是带着试错想法做事，先干了，出问题解决。微软裁员应该是后者，过程中的问题逐步解决，bug 后果得用户体验买单。

主进程和子进程的概念，jenkins 的环境变量是主进程的，构建的脚本是执行的子进程变量。构建后脚本才开始设置参数值，可 job 已经创建完了，怎么可能用后设置的变量。

安全性用途，比如闸机设备，注意下验证生物识别。设备商也是用合作商的算法 sdk，就那几家。更重要的是不同环境光线下的成像质量，成像有问题，算法修正也白搭。

验收设备还是得关注使用需求场景实测、硬件成像质量、不同光线对成像质量的影响、安全性一定得多测测异常场景，比如验证生物识别的有效性。

这要区分内部测试还是外部数据抓取，外部数据收集走埋点上报，内部测试就简单了，设备端后台挂个监控持续跑数据就是了。脱机方案最简单就是 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 等。最后汇总分析

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

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