为什么没有 “全链路” UI 自动化测试工具？

因为每个业务的 “全链路” 长得都不一样，中间有多少服务接口，经过多少层缓存、消息队列、数据库，服务之间彼此如何通信交流，根本没一个定式。所以从 “模块化” 的思想出发，UI 自动化就是测 UI，接口自动化就是测接口。做 “全链路” 自动化就自己用不同的工具去拼装支持不同的需求。

双周更一次，偶尔休个刊，有时候又忘发

问题范围太大了，编都没法帮你编出来

如果你还有时间和精力系统学习，就会找一些 MIT、CMU 的计算机算法公开课慢慢啃，这种方式尤其适合学生党。

但是对于咱们这种上班族来说时间很碎片化，精力也相对有限，更高效的办法还是多刷，去押题……

其实了解业务逻辑不等价于绑死在某个具体业务上。

了解的过程是业务和技术一起发展的，在理解具体业务场景后，往往对应的技术实现就水到渠成理解了，当看这种东西多了，脑海里就开始构建【什么类型的业务场景 => 什么样的技术构成】这种关系，我管这种叫 “经验”，越是高阶的人脑海里这种关系索引越丰富越具象。

而这些知识，都是可以在不同的业务间迁移的，如业务需要登录、支付、查询、写入等很多共性场景，就都能做知识迁移了。

其实在大厂数据库权限一样很严格，测试也没有数据库权限（线上线下的都没有，想要往往得走好几层 leader 的审批，得跟一堆人解释）。

这时得提前和研发沟通好，要不让研发支持帮忙看数据库数据，要不换其他的验证方式检查数据

这是好事，不是坏事。

内部逻辑才是业务根本，基本的工具都是一用就会其实没所谓，思想掌握就好。

这个表述角度好，很赞同。
【现在大部分考核制度其实就是为了把前 5% 和后 5% 筛出来而已，也就是他们根本不是为了引导你成为公司需要的那种人】
【从这个角度看，只要你和别人不一样，你就会脱颖而出（注意别整到后 5% 了哈哈），而技术上区分度相对好操作点，so~~】

从我的角度看：

• 熟悉业务不等于有竞争力。个人视角，业务 = 了解技术链路 + 熟悉产品形态 + 理解产品规划 + 掌握竞品动态。一句话说，如果给你找个技术很好的打手，你能否从零复制一个产品出来，复制出多少大概等于对产品理解多少。

如果业务技术链路非常简单，没有几个层级的上下游，也没什么历史债务的说法，代码量小场景简单流量低，对应的是业务熟悉门槛低，测试研发替换成本低，熟悉这类业务是竞争力不足的。

• 技术确实是容易突出个体差异，因为业务经验和知识的验证比较依赖一些关键场景彰显（重大需求的测试判断、日常长期的质量保障布局、问题排查现场的思路），这种彰显机会实话说确实不多。技术就很容易在日常工作体现，而且给人的印象是更长远的，比如做了一个测试工具大家会记住很久，但是你线上查出了一个问题不一定会被大家记住。

同意，面试重在务实。

不过如果是换成我，测试用例设计 可以再加多一些细节和花样，
我倾向于让候选人去说某个功能研发大概会怎么实现，需要什么要素、架构，内部之间如何交互通信，最后我想听到的是候选人的用例设计里包含了提及的这些技术实现要素，这就代表候选人真的理解这个功能。
这种测试，我可以认为 ta 只是除了代码技能不如开发熟练，在业务理解上一点都不差，如果还能说的上业务的一些产品指标和产品规划就更加分。

另一方面，我会关注候选人的整体质量保障方案，也就是除了用例设计之外，其他专项测试、灰度、监控等各方面的想法。这可以看出来候选人整体质量保障思维框架是否完整，思路是否广阔。（别说，很多人其实说完了线下测试就没有然后了）

这一套下来，就用能折腾个二十分钟了。

我理解这种问题应该不是临阵磨枪就能答得好，肯定需要思考沉淀过。

1、DNS 劫持，劫持的是运营商，和用不用数据流量没有任何关联
2、切换 WIFI，还是推 —— 这个要看你切换 WIFI 后解析 DNS 是不是还在同一个服务器，还是在的话估计没解决
3、换设备，换 ip，用 pc 打开随机推荐的博文，再看安全中转，还是有广告（不是黄）—— 这些操作应该都没关系，最终还是看你的 DNS 解析是在哪里进行

可能是被 DNS 投毒了吧，曾经的大网站，应该不至于这么干

从目标倒推过程：

1. 用例未来可维护 —— 要保存在云端且有版本管理可复原版本，不能存在本地个人电脑
2. 多人协作成本要足够低 —— 支持共享与多人在线编辑，有权限控制
3. 可追溯上下文分析其他问题 —— 需求 & bug 单关联检索展示
4. 用例呈现结构清晰 —— 使用清晰简单的树状脑图，避免使用冗长的表格
5. 用例可打标可筛选 —— 工具支持自定义标签与检索

适合，大厂无论什么时候去都不会亏，有机会还是可以进去锻炼一下。大厂给的钱相对多，平台也大，在里头除了学到什么能做，还能学到什么不能做。

认同你的观点，AI 肯定要用，也得用好。问题主要是 AI 实在太好用了，人的技能也容易用进废退。

不过重新看了一下楼主的帖子，感觉我的发言是跑题了…… 楼主的疑问应该不是标题上写的这么简单

我身边有些同事（尤其是外包和经验少的实习生），非常依赖 AI 写代码，新时代的 copy-paste 抄袭让他们没法沉下心去真正掌握技术，最后自己在写什么代码也不理解，能跑出符合预期的结果就行，但凡代码有点 bug 都没法自己排查，又得找 AI。

我就问一个问题：你想不想成为上面这样的人？

力量训练，吃点好吃，玩玩变形玩具，写点小代码

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

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

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

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

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

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

确实是水积分很好的办法

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

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

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

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