背后开两枪

请不要在社区讨论破解问题~~

我给你们理一下这个争吵的过程，你们看看是不是很可笑，然后我晚些时间锁帖~

• 1st、黑哥给了个莫名其妙的推论 “测试坚持唯技术论的人，最后的归属都会是搞培训班”，姑且不说这个推论搞笑不搞笑，但是这里吐槽的点是 “唯技术论”，应该说并没有否定技术的重要性
• 2nd、孙总说很多混到高薪的是靠技术的，也就说有这么一条路可卷；“技术重要” 和 “唯技术” 是两码事，所以此时应该没有把矛头对准黑哥，但是阐述有点上头了，觉得楼上大部分人没有清醒地认识到技术的重要性……但是，说实在的没看出楼上有这种论断的苗头出现，这是属于凭空创造假想敌
• 3rd、接着黑哥上头，讥讽孙总以自己的价值观 CPU 其他同仁……
• 4th、各种下头言论出现，不分轻重地互怼、不分是非地站队~

• 观点一：唯技术论是不对的，业务也很重要甚至更重要
• 观点二：技术是很重要的，卷技术是一条 “混出头” 的可行路线

压根争论的不是一个论点，二者都没毛病，你说你们吵毛线~~~

我看到你这么长的回复，再联想到你前面发的帖子说你连续几个月每天疯狂加班到深夜，心想必然是创业公司，晚上七点之前不用干活的

测试坚持唯技术论的人，最后的归属都会是搞培训班

你这句就是鬼扯了，我坚持了那么多年，最后的归属是失业——好在赋闲 2 年后凭着年前时摆弄相机的那点粗陋知识找到了个影像测评的工作~

30~45，取信 30，猎字当头，除以 1.5，实际 20K，我理解的没错吧各位大佬

来，说一下是哪个大厂？说出来让我们见识一下大厂的降本之道……

合情合理，完美操作，甲方圣明！

说真的，这世道有明明的一份功劳，我向来主张看中哪个面哪个，面不上再退而求其次面下一家，像明明这种凭借硬实力一下子拿 7 个 offer 的，给了那些用人单位更高的期望，希望人人都如 “我上次面的那个明明” 般强……而且多个明明叠加，搞的他们期望越来越高，但是现在出现了很多比明明更强或更年轻的人了，明明自己也遇到了困境，是不是明明自己造的孽呢？

明明三年前那会儿面试 11 个还能拿到 7 个 offer

坦白说第一眼看过去我觉得你在杠，仔细看了一下你发的内容，发现还是 GPT 在杠

额外说一句，用任何厂家的 AI，问问题的时候都不要带上倾向性甚至拉踩的方式，不然你得到的答案慢慢的、越来越接近你已经知道的信息，这是自己给自己创造信息茧房，而且这些 AI 很容易被 “投毒”，使用时更需小心。比如你要问：“格力空调比大金空调好在哪里”，不如问 “格力空调和大金空调各自有什么优缺点”。你预设了自己想要的答案，他们就会变成一种新的竞价排名工具……

这种为了杠而杠的问题，针对性太强了，GPT 显然在扮演理中客，强行否定……甚至为了杠而假定出对方说过某个错误言论，比如：

那种 “一旦用 LEFT JOIN，MySQL 就会被迫扫右表全部数据，而用 INNER JOIN 就能快速过滤只读少量数据” 的说法往往是过度简化甚至不准确的

“一旦用 LEFT JOIN，MySQL 就会被迫扫右表全部数据” 这句话谁说的呢？

在我看来，或许 GPT 连 “可能” 和 “一旦” 都理解不清楚，就没必要参与中文的逻辑解答了，要不你问问它 “INNER JOIN 和 LEFT JOIN 有什么区别”，看它怎么回答呢？

问一下 AI 就知道了，LEFT JOIN 的作用一般来说仅在于 返回左表所有行，右表部分无匹配，帖子里的场景 case_branch，起码会有个 main、master 或 base，必然会有匹配（如果没有，那就是数据结构问题了），为啥要用 LEFT JOIN？

在联表查询中，INNER JOIN 和 LEFT JOIN 的效率对比需结合具体场景分析，但通常 INNER JOIN 效率更高，原因如下：

1. 结果集大小

• INNER JOIN：仅返回匹配的行，结果集更小。
• LEFT JOIN：返回左表所有行（即使右表无匹配），结果集可能更大。处理更多数据会增加内存和计算开销。

2. 索引与过滤

• 若连接键有索引，两者效率接近。但若右表无匹配时，LEFT JOIN 需额外处理 NULL 值，可能略微增加开销。
• 若右表无索引，LEFT JOIN 可能触发全表扫描，导致性能显著下降。

3. 执行计划优化

• 数据库优化器可能将 LEFT JOIN 转换为 INNER JOIN（当左表所有行在右表均有匹配时），此时效率相同。
• 但若优化器无法确定匹配情况，LEFT JOIN 可能选择保守执行计划（如哈希连接），增加内存使用。

4. 数据分布影响

• 若左表大部分行在右表有匹配，两者效率差异较小。
• 若左表大量行在右表无匹配，LEFT JOIN 因处理更多 NULL 值而更慢。

总结

• 优先选 INNER JOIN：若只需匹配数据，效率通常更高。
• 谨慎用 LEFT JOIN：仅在需要保留左表所有行时使用，并确保右表连接键有索引。
• 实际验证：通过 EXPLAIN 分析执行计划，观察是否触发全表扫描或低效操作。

• 示例：若左表有 1000 行，右表有 100 万行且无索引：

  • INNER JOIN 可能通过索引快速过滤，仅匹配少量数据。
  • LEFT JOIN 可能需扫描右表全部 100 万行，导致性能骤降。

是什么样的魔鬼数据结构设计才会让你在 OLTP 应用里面敢随便用 left join 的
遇到这种问题我第一反应就是干死这种 sql，干不死就要重新设计数据结构

黑哥太霸道了，取关取关

你要不要去问问 kimi、ds、千问、文心它们这几个问题：

• 测试对象有 4 个输入，取值分别为（A1, A2）、（B1, B2, B3）、（C1, C2）、（D1, D2, D3, D4），使用 BC(Basic Choice) 覆盖方法获得的测试条件有哪些？
• 有函数 f(l, m, n)，l 取值 [1500, 1800], m[2, 15], n[3, 25]，采用边界值法和基本选择法进行测试，仅考虑边界内有效值，最少有几个测试用例，分别是什么？

听听 AI 在放什么屁……再决定要不要用 AI 写 case

昊翔本人？

参考 FMEA：https://zhuanlan.zhihu.com/p/523384133

远程调试的技术细节看样子你们都明白，明显问题只在租户管理，你想问的

如何做到只获取一台 iOS 的调试权限

人家回答你了：

通过云端设备池管理系统，确保每台设备在同一时间仅分配给一个用户，避免权限冲突

所以你们在杠啥？

全栈，只会 java 和 python 没法混，shell、powershell、perl、js/ts、go、cotlin、rust、c/c++ 全部都要会……拼写~

你这个问题描述的就好像在问：我知道每次上厕所要去男厕，但是总会跑到女厕去，我该怎么办……我职业生涯里唯一一次因为测试工作质量被机车开发经理投诉，就是因为 BI 报表测试，太繁琐了，心累，需要业务积累远大于技术！

• 咨询产品、业务/用户，实际会有什么数据场景可能
• 导生产/线上数据到测试环境，自己去跑全量测试、做探索分析
• 总结每次发现的 BUG 以及漏测，做一下 RCA，形成检查单，测试设计的时候反复参考，并且不断累积 & 藏私 这不就体现你个人经验价值和不带替代性了吗
• 多问问 AI 怎么搞，看看别人以前测 cognos/水晶报表、datastage/kettle 这些都是怎么玩的

还是得私有化部署，不然信安弄死你~

不说码流检查，如果只是清晰度评估，其实 psnr 这些无参考评估指标也可以用一点，并不是非要有个标准去对比，比如：用不同的滤波尺寸将图像做简单的高斯去噪和椒盐去噪，分别将结果与原图一起计算 PSNR/SSIM，然后再去加权计算、推断，评估图像质量……只是个思路，未必有用，供参考~
按理说编码之前应该能 dump 出原始的输入才对，要么问下开发能否帮忙提升可测性~

同一个问题问文心一言、ds、gpt 类，然后回来对比

答：

• 我只负责设计框架、做算法实现，就是用算法遍历代码穷举数据，然后灌入框架，每次随着构建自动执行，而且每次执行都会根据系统的变更而演进，不断学习……
• 具体执行多少不清楚，因为每次都不一样，反正就是数据记录也就千万级的样子吧……
• 所以从传统意义上来说我不写 case，我也不喜欢 case，我最开心的时候是我每个月写几十个 case 的时候……