TV 端搞 web 页面，运营需求？性能上不一定抗的住，当初我在乐视，rom 都是 native 做，运营走的是 classload 的插件更新方式。web 运营的话还是 RN 靠谱吧

diy 开个 talkback，uiautomator 就可以获取 web 内容了，之后按 app 测试。

有办法但需要自己设计实现，可用 Hierarchy 的数据，dumpsys activity top 中 View Hierarchy:部分，下面的 # 部分，代表着区别

native：
android.support.v7.widget.ViewStubCompat{ca26463 G.E..... ... 0,0-0,0 #7f090012 app:id/action_mode_bar_stub}
RN
com.facebook.react.views.view.ReactViewGroup{f158dd3 V.E..... ... 0,0-1079,552 #17e87}

FPS 只是数据，最终是要筛出问题提供给研发解决，这里的问题就是度量数据如何用？单从实现 fps 度量的方案上：
16 年我设计了 (https://testerhome.com/topics/4775)
今年又设计了 (https://testerhome.com/topics/21045)
可实际问题上是用它们如何去解决问题，能解决什么问题？

1）要将需要研发解决的问题聚焦在什么程度线上？这就需要了解一般用户的体验需求
a、人眼有 100ms 延迟，一些人经过训练或长期适应高帧率场景会有卡顿敏感度提升
b、竞速类游戏有限制 30 帧的做法，核心是人眼对变化感知明显，所以有些场景控制帧率稳定比提高帧率有效果
c、视频及体验是从 24 帧电影录制及网络流视频 25 帧视频来的
d、20 帧体验，作为一般帧率影响体验的游戏，20 帧就是个底线了，就像 ui 上的 gif 动画一般是 20 帧播放，至少这是被人接受的

2）要和配合优化的研发达成一致的优化目标，要不实际会浪费在优化意义的争论上

3）说说我的经验中，用我自己的方案解决了哪些实际问题
a、手机 rom 游戏效果优化，目标：让游戏帧率稳定，通过策略调整看帧率波动。实际优化是温升限频策略、续航、游戏性能间找平衡点，带着目标做事才能有的放矢。
b、TV 项目 costdown，低端芯片 mstar 648 1.5G 内存项目，我给的目标，内存要给前台 app 提供至少 500M 可用内存，最终通过 bsp、rom、系统 app 各层面的努力，配合后台查杀策略提供了 800M 左右可用内存；而帧率上通过单帧绘制 jank 比例发现 SurfaceFlinger 绘制性能有问题，结果通过研发优化思路探索，打开 Gop 的 overlap 实现减少一次 io 复制，使 SurfaceFlinger 绘制性能明显改善。
c、通过 16 年的方案分场景检查静止画面下，SurfaceFlinger 的无实际意义绘制，控制了重复绘制图层、不关闭未在显示中的 gif 动画绘制两大类不合理性能开销的问题
d、基于流畅度评价，70 分以上每 10 分跨度都可以感受到体验区别，从而把桌面插件上线标准控制在 70 分以上，目标 80 分以上的标准，有效把控了插件上线的流畅度体验。

基于这些应该能理解吧，不在于如何把数据拿到，最核心的是如何用。我扩展的抓取方式只是为了提供拿到数据的手段。

Android 上我还真没遇到取不到性能数据的时候，到目前 9.0,。信息获取思路都是通的，只是数据源信息需要了解哪些产生变化，再怎么控制权限，adb shell 权限总有吧。
我开源的（https://github.com/sandmanli/monitor-for-android）

无非就是要测试，要测试先搞清测试目的，要解决的问题。做测试开发非得局限在编程语言，测试框架上？
1、移动端也是跑在 linx 之上，至少 shell 是有的，移植编译的 arm 工具是有的
2、跑个 app，ios swift 和 android 的 kotlin 是有的，但真需要用 app 的开发方式测 app？
3、移动端和 PC 端配合完成测试场景，PC 端就十分开放了，就看用什么编程语言快速解决问题

再来看看个人的职位任务
1、测试执行？
设计测试 case 能力是基础吧；
复用测试经验排 case 优先级，优先发现严重问题是经验价值吧；
掌握移动端相关技术知识点、项目需求设计细节是玩转测试的基础吧；
基于测试工具和 UI 测试框架提高执行效率都快发展成必备能力了，要掌握吧
2、负责测试专项？
专项基础把控范围，测试方式，把控标准要有了解吧；
如需外部测试设备，要掌握外部设备使用，串口调试控制吧；
3、执行 team 管理？
组织团队，招聘，工作安排，项目节奏和测试计划的协调，项目团队间沟通等工作内容增加，要有自己的掌控团队的风格、沟通、汇报、人员和计划管理能力吧
4、测试开发？工具方向还是支持业务需求？
工具方向：要有工具设计思路吧，要积累方案思路让工具真正能用起来吧，要持续支持迭代维护吧
支持业务：要按需求建立框架，按维护策略持续输出支持吧，要做 CI/CD?

多些反问，自然而然就知道需要什么，解决问题的有效思路积累下来是资本。

真是招执行的人员，考虑更多是人力成本和基础素质，毕竟执行的事教下都能干起来，做事区别就在积极度、项目中的问题沟通。

理解原理，用什么无所谓。面试时讲原理，讲测试方案，经验案例。只关注执行是不够的，要体现的是经验的价值，一直执行下去就会被 “后浪拍在沙滩上”。

此方案确实可以把一类特殊场景绘制部分数据分出来，这里说的场景是这样的：
1、背景有个动效始终循环绘制，哪怕被其他页面覆盖，可以用开发者模式的 GPU 呈现模式分析查看，画面静止但有数据绘制；
2、实际显示页面间隔绘制内容
3、此方案就可以取到绘制的内容，而非不显示的 buffer 绘制

用基于 SurfaceFlinger --latency 的方案就做不到，因为抓取了未显示部分的 buffer 绘制，影响了实际显示内容帧率的评估。

今天看到一份监控结果中 SurfaceTexture 很多名字挂了数字，如"SurfaceTexture-0-1980-2"，统一做了下归类处理，全部重名名为 SurfaceTexture。对应脚本有更新。

#!/system/bin/sh

# $1 存储目录
# $2 文件数量
# $3 起始文件名数量
DD(){
echo "pid=$$"
local i=0
while true;do
    local name=$((i+$3))
    dd if=/dev/zero of=$1/$name.dat bs=4096 count=1 1>/dev/null 2>&1
    local i=$((i+1))
    if [ $i -eq $2 ];then
        break
    fi
done
echo $$ finish
}

folder=$3
if [ ! -d $folder ];then
    mkdir -p $folder
fi
#开多进程

#$1 进程数量
#$2 单进程文件数
#$3 存储位置
n=0
while true;do
    DD $folder $2 $(((n-1)*$2)) &
    n=$((n+1))
    echo "进程: $n"
    if [ $n -eq $1 ];then
        break
    fi
done
wait

存 sh 文件（unix 文本格式，utf8）push 到手机执行，参数参考注释

shell 的 dd 文件进行创建就够了，配置随机的生成大小，无非写个创建文件函数，传参控制。同时做多进程生成。

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

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

实际坐标需要调一下