点点点对于个人的真正价值，是可以让你有途径去理解产品，思考产品设计/技术架构的逻辑，简单说就是要把自己摆在产品经理，架构师的视角上去思考问题。所以从业务上来说，核心的问题不是思考如何避免一直点点点，而是怎么样从点点点中学到东西。
和业务并行的一条线，是技术，lz 的核心诉求，应该是技术成长。在小公司的话，一般空间会比较大，但是平台小，所以我个人的建议是加强业余时间的学习投入，“靠自己”。
假以时日，整个公司的测试平台，质量链路流程都出自你之手，对产品设计和架构理解也非常专业，那个时候就是你功成名就的时候，也是你上升 or 跳槽去更大平台的时候。

我艹，这段话好像有点鸡血&pua，哈哈哈哈。还是希望能帮到 LZ。

机会比较少了。
现在互联网招聘整体在收缩，很多代码能力很强的校招生，之前都是可以面开发的，现在被迫接受一些测试开发的 offer，所以通用的前后端开发能力，运维能力，并不会给你的简历增加非常多的闪光点。
我个人认为，大龄同学在社招还能吃得开的一个因素，是对产品理解的专业度以及质量思考上的深度，比如在大模型，云产品/云平台，容器/虚拟化，游戏引擎，安全/SDK，车机/智能座舱系统等等专项领域有着一定的过人之处。传统的互联网应用领域太卷了，几年前遇到一位会写 iOS/Android app 的测试开发，我会眼前一亮，现在估计好多都会了吧，应为 AI 普及了，有啥不会的问 AI，回答的正确性八九不离十。

而且已经 33 的话，我觉得也不用非常向往大厂，进来大概率也是做个螺丝钉。热门的大模型/云计算方向，招聘要求基本都是高的离谱，去普通的组估计也会比较卷，没有好的基本盘，大概率等着被裁员。我反而应该觉得找个小厂或者中厂，占个坑位，自己当一方诸侯，这样职业生涯会更长久，自己的视野和可能性也会更好。28-30 左右我觉得是个不错的进大厂的时机，技术成熟度/潜力/精力旺盛程度，会比较平衡。

我觉得大龄测试进大厂的概率，运气占 7 成，实力占 3 成，学校背景/项目背景足够硬的话，可以多面一面，但是不用苛求。

一般都是由浅入深，我了解到的，国内大部分 IaaS 产品研发团队，很少配备专门的测试人员。IaaS 产品测试，大概率要把自己往架构师的方向培养（在讨论测试方案时可以和架构/开发平等对话），初期几个方向：

1. 解决端到端的测试方案：从业务视角出发设计测试方案，解决单产品测试覆盖不到的风险点。
2. 提供测试平台和质量管理：涉及到自动化的框架开发和用例维护，三方测试框架的接入以及其他很多横向的事情。
3. 跟进需求和现场问题，加强积累 简单说，初期要提供服务，获得其他老师的信任。 我的体感，大概 3 年左右就可以成为外人眼中的 IaaS 产品"测试"专家。几个好的方向：测试架构师/性能测试专家。

难得看到一个 IaaS 的帖子，广告招人，感兴趣的私聊，目前网络人力缺口大，计算/存储也可以聊。
底层产品测试没有大家说的那么不堪或者地狱难度，整体坑少人也少，而且对年龄更友好，周围同事来的来，走的走，大部分目前都还不错。

大家可能不知道阿里有几个 P9 以上的测试 (转综合管理的不算)，包括字节和 tx 同级别的测试，非常非常非常少。
所以不用焦虑了，市场说明了方向，老老实实做技术，理解产品。
管理型的 TL 分两种，一种是从业务中长起来的，没有你管理团队不行，一种是因人设岗。目前看前者还是有生存空间的，后者面临的挑战非常大，整体生态萎缩，船票和坑位也越来越少。

我怀疑你们在双簧，推广公众号，但是没有证据。当然反手就是一个关注公众号

或者有木有大佬有好的 logcat 切片策略，就是让 logcat 按时间戳顺序保存在一些列 log 文件中。之前想过用 filebean 或者 logstash 直接监控，但是由于各种原因，都不符合应用场景。

单 python 来说，至少一个初级 python 后台开发的水平吧。百度随便搜一下 python 后台面试，10 个问题会 9 个，其中 5 个你能吹够半小时，我感觉就差不多了。资深一点的，协程会看到源码，基本也够了。。。

JAVA 精通劝退

测试妹子还是有优势的。。。。如果是写工具的话，就比较少了，大部分是男的。我接触到，代码稍微好点的测试，只有一个妹子，然后至今单身 = = 真实。。。

去做两年测试，算法估计比 9 成开发还六了吧。

外包普遍技术差，缺乏思考吧。当然也有个例，朋友说隔壁组一个外包出身的测试升 7 了。。。

简单的场景是可以跑 UI 自动化，传统的基于元素检查的框架，和新一点的基于图像和场景识别的框架，发展很快。但是 UI 自动化不可避免的有随机假摔的情况，应付复杂场景的时候，稳定性还是欠佳啊。
还是坐等大佬的框架吧，目前的情况，不看好啊。

还是得看投入产出比啊。以目前的技术环境，还是做和产品代码直接打交道的接口测试或者 intergration test 比较靠谱，至少有稳定输出，也的确能反映问题。
我面试碰到简历上有写 UI 自动化的，都会问一个问题，覆盖率，发现 bug 率，回归成本，稳定性/可靠性。基本没碰到几个满意的回答。
当然可以打打擦边球，做一些简单的 monkey 或者登陆/登出检查，复杂场景，还是手工吧= =
UI 自动化这个，可以做，但是要时间啊，3 个月不出成果，OK，一年两年不出成果，你跟领导怎么交代？。。。
不过随着 AI 的发展，我觉得 UI 自动化还是有潜力的，但是这部分，得看大厂输出框架吧。之前去腾讯看过他们 WeTest 游戏 AI 自动化，做的挺不错的。

游戏测试挺有意思的。特别是前端，毕竟和传统的软件测试有点差别。技术上的空白区域还有很多，但是都是难题。

FPS 一般是看>25 帧比率的吧，

嗯，我搜了一下，这个 phys_footprint 貌似是可以。
还有一个疑问啊，这种嵌入式的东东，不好做竞品分析啊。我们之前做 iOS 的竞品分析，都是用 insturment 跑，跑完拿到 log，再放到我们写的一个 project 里面解析，便宜又大碗。但是 instrument 拿到的内存貌似是 resident mem，感觉不是很有参考价值。。。这块卡了好久，没有好的解决方案。

话说这种嵌到工程里的测试代码，对主线程的影响这么评估。
内存,CPU 拿整机的话，应该差的有点多吧。

最后解决了，记得是 pod project 签名的问题，在 pod file 后面加点后缀就阔以了。
post_install do |installer|
installer.pods_project.build_configurations.each do |config|
config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
end
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
end
end
end

大概是这样，开始 [‘CODE_SIGNING_ALLOWED’] 那个我是用的 ['PROVISIONING_PROFILE_SPECIFIER']，也是一只不行，后面改成 CODE_SIGNING_ALLOWED 就 ok 了，