如果你还有时间和精力系统学习，就会找一些 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. 用例可打标可筛选 —— 工具支持自定义标签与检索

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