很庆幸，我从初中开始到现在还对健身保持热情，尤其是当了解到力量训练和举重后，开始打开视野，让我对 “健身” 更加地感兴趣。

希望这个兴趣能跟着我，直到我老掉牙练不动了。

写用例没需求文档怎么写，研发怎么实现需求，那不应该直接去怼产品吗？还得拉上你的测试老板一起去怼

你把一些指标的计算口径告诉 ai，然后再告诉 ai 怎么算好怎么不好，分析思路是怎么样，然后把数据格式告诉 ai，ai 就能拿着数据去分析问题了。真的很强大，省了一堆事。这样玩着玩着慢慢你就会让 ai 做越来越多分析，你的想法就能不断丰富。

那就跑路吧，跑不了就先看着，再水的代码它也是代码

1. 代码阅读技能是基本，需要从代码实现角度去理解业务架构。如果连研发的基础代码都看不懂，走不远的。
2. 对测试场景的敏锐度，业务中有很多通用的场景是可以变成经验的。哪些典型场景就天然涉及数据安全、隐私合规问题，哪些典型场景高概率要考虑性能问题……
3. 基础测试方式的信手拈来。对于性能测试、安全测试等各类姿势，要有基本理解，这种理解不会随着更换测试工具而变化，它是一种本质的理解，可以让你不依赖单一测试工具去实现你的想法。

确实是水积分很好的办法

应该不少，腾讯阿里这些肯定都有的

似乎规定是 8 点就可以下班，所谓强度看怎么理解，工作会比较密集，但是不会硬性施加很大的压力。而且强度和业务有很大关系，每个业务团队情况不一样。

但总的来说，随着加入行业的人越来越多，也逐渐开始卷起来了。

不想卷技术，不想加班，又想留在比较安逸的城市，还想拿到比其他行业高一点的薪资，可以考虑做离案外包，现在很多互联网大厂的测试都在推行离案外包，就是非驻场外包测试。

因为我这是应用方，所以具体准确率数据只能给定性的判断，超过 85%（90% 应该也有）。

局限性有，但整体利大于弊：

1. 控件搜索由控件树直接定位，变成大模型搜索控件树，定位时间有增加，但常规定位时间就是秒级，再增加影响不大。
2. 原本的代码控制点击，变成让大模型通过 function call 完成点击，依然是耗时的增加。
3. 多了大模型的处理，多加了一个不稳定的因素，也增加机器成本。
4. 大模型多次调用在返回上的不稳定，好比相同问题多次问大模型，给的答案不完全一样，有时同一个控件定位多次会有小概率定位失误，具体数据应用方视角不清楚。

故整体的局限是耗时和机器成本上的增加，但是人力等到较大节约，编写成本是一方面，长期维护成本也是一方面（谁顶得住一两周就变一下的控件 id 和控件树结构）

如果是上层决策者，个人感觉不会有很大的 “意志差别”，我倾向于认为上层决策者都是信息输入充分的理性人，而国内经常做出 “牺牲质量” 的决策，正正是因为外部环境、历史案例等各种参考。
就好比很久以前李彦宏公开说是国人愿意牺牲一点点隐私来换取极大的便利，我感觉老外可能也愿意，只是少部分很极端的意识形态阻止这种事情，不断强调某种观点，最终大家习惯了就顺着意思去做。

发展才是硬道理啊，业务不同阶段有不同特点，，质量、成本、效率 是一个三角，都应该要关注。

对于各种常规场景是够了，操作成功率是高于 90% 的，只要不是通篇代码滥用，简单场景脚本用这个可以写得很快，也省掉很多脚本控件维护成本

可以网上找找 MTSC 或者 QCon、QECon 最近一两年的 ppt，应该已经有类似的方向，我司的 UI 自动化框架团队也做了这种 ai 找控件再点击的能力，虽然有局限性但感觉已经能覆盖 80% 以上的常规自动化场景，大体来说长得像这样：

ui.action('点击页面右上方圆形蓝色的“搜索”按钮')
ui.action('点击搜索结果列表中第二条数据')

比如，https://www.53ai.com/news/OpenSourceLLM/2024121816054.html。

MTSC 大会和 QECon 这一类大会应该有相关课题的 ppt，需要自行去搜索一下

• 有没有办法进行框架级别的整合，不管是测 UI 还是接口还是 APP，都采用同一套框架，减少对于框架的维护工作量？

我先质疑一下 “采用同一套框架” 是不是真的能带来 “框架维护工作量的减少”。从开发者视角看可能维护两套东西很麻烦，但是两套变一套不代表维护工作量除以 2，就像 5 楼鸡哥说的，硬凑在一起会带来更多复杂度，可能排个 bug 的耗时变成了之前的 3 倍？换个角度，从落地视角，已实现的老脚本要怎么支持，是要求用户从老脚本全部切到新脚本吗？那这个事情必然做不成（如果不是公司实践，那个人过过技术瘾无可厚非）

• UI 测试构建元素定位信息的过程太繁琐了，也容易出错，能不能跳过？

明确可以用 ai 去解决，业界已经有实践。我个人使用下来觉得很不错，对比原先要理解 xpath、控件 id 等概念，直接用自然语言描述/操作元素显然成本更低，还能让更多人参与进来。我是支持用 ai 解决的。

• 如果某产品有多端，需要进行联合测试，比如说一个用例，在 web 上修改一个参数，在 APP 端验证是否修改成功，这样类似的需求在框架层面好像无法实现？

这个真没必要去解决。你先想想这种联合场景多不多，人工测试覆盖需要多少人天成本再考虑。其次这种跨端联合场景，如果是跨服务端到移动端还稍微好一点，而跨 web 端到移动端就更麻烦，中间需要控制的变量/不稳定因素数不胜数。可能最后做是做出来，要不稳定性像屎一样，要不测试脚本配置编写巨麻烦。

• 如何避开复杂环境搭建的过程，减轻使用代码构建测试用例的场景，如何让更多的人投入自动化测试的实施？

问题 4 没看明白，问题大而泛，没理解希望解决什么问题。是成本问题还是效率问题？复杂环境搭建前后端可以用 docker 等成熟技术解决，移动端不了解。【减轻使用代码构建测试用例的场景，如何让更多的人投入自动化测试的实施】，是指类似低代码的思路吗？现在是有不少团队在探索通过和 ai 聊天结合线上流量抓取、代码分析生成一系列接口自动化测试用例这种事情，不知道你是不是想表达这些。

最后，一个大的自动化测试平台，重要的不仅仅是自动化技术，数据看板运营，上下游套件，排查定位方便度等都很重要，可以考虑这些维度的效率提升。

可能是我的年纪到了，阶段到了，以前觉得这段子很煞笔，现在反而觉得这精神状态肯定活得很开心
（抱歉，回复和匿名功能玩不太明白，连删了两次评论😂）

👍

老哥到金蝶了吗？

以前和在 Thoughtworks 工作的师弟聊天，他曾外派到国内某银行干了半年到一年，他说国内很多银行都还在用 ibm 小型机，整个银行系统都是从国外买回来，再招人做运维的程度。

天啊，不敢相信 2025 年了还有如此老久的技术形态 ，但是没办法，架不住别人还是一样地库库赚钱啊。

我想表达，一个业务赚不赚钱、好不好，和技术真的没有必然的关系。但的确可以通过技术提前布局来满足业务未来增量，做到类似 “技术驱动业务” 的感觉，如阿里的全链路压测就是技术支撑业务。而真正因为技术突破而塑造新业务模式，这种案例很少的，电商算一个吧，大模型肯定也算

猜一下可能这么干。

1. 准备好若干组测试数据，触发网络请求，抓包获取报文
2. 观察报文内容，找到多组测试数据之间的报文结构共性，2 楼说得很对
   • Magic Number 是典型的协议设计思路，用以区分协议类型
   • 加密方式：字符偏移是简单的加密方式，可能还有很多复杂的加密（这种很难破解，也不一定非得破解）
   • 报文的上下文：有些加密需要提前交换秘钥或者啥，所以可能不是只抓一个包就能看出奥秘，需要包体上下文，甚至可能是游戏启动之后客户端就和服务端交换密钥
3. 当发现一些规律之后，可以修改原有报文做重放尝试，去撞可能性（验证猜想）
4. 最后摸透了协议，就能着手按照协议格式去构造报文了（说得轻巧，市面上的大游戏基本不可能吧，别人还可能会定期变更协议）

和软件没关，和公司招聘策略有关，遇到只能自认倒霉。

我预设这个问题是问服务端发版。

基本原则：什么时间发版影响小，就什么时间发。
影响小包含：

1. 发版期间的服务升级时间差，所出现的服务不可用影响的用户面 -> 缩短低体验时长
2. 发版期间出现线上问题，回滚止损所影响的用户面 -> 容错能力更高

如果通过多实例、流量路由可控，支持灰度发布就可以一定程度避免加班熬夜发布，可以在白天没那么高峰的时间段搞，影响也可接受。

啊？我还以为个人用户是免费的

鸡娃不好说，但我还是愿意去刻意培养或者挖掘小孩的兴趣，去看看小孩有没有可能性。
如果这个兴趣需要金钱辅助，我力所能及鸡一下自己给支撑好。
如果小孩确实平平无奇，只要 ta 不走歧路，往难听点说即使 ta 开滴滴送外卖扛水泥，不危害社会，是个正向价值观的人，我都可以接受。

我的任务是积累积蓄，积蓄越多，未来 ta 的可能性也越大，所以还是鸡自己吧。