再补充一个，就是社区里目前发技术的，还挺多是 “圈地” 的（这里没有绝对的意思，防止语文不好的人误解），你总会在最下面看到自建的群或者其他什么链接。
表面是为社区发技术贴，其实是榨干社区最后一点价值，引流些人。
个人感觉发水帖更多是社区的真情流露 （我是水贴大户，不过以后不会发了）

不是，只是不写水贴了，我专心写我的小红书

这几天都在听，还有丁真的 SmokeMan 也不错

你的技术热情和持续改进的思考值得赞赏，但属于南辕北辙，陷入了"技术完美主义"的陷阱

• 第一，追求大一统框架反而会增加复杂性，就像想把螺丝刀、钳子、焊枪合成一个工具，结果可能哪个都不好用

  • 试图用一个抽象层完美适配 Web UI 控件交互、HTTP API 请求/响应处理、移动端 (Android/iOS) 特有操作 (手势、权限、通知、应用生命周期等)，会导致这个抽象层变得极其复杂和臃肿。你需要为每种测试类型定义通用接口，并在底层实现差异巨大的适配器。这本身就是一个巨大的、易出错的设计和高成本维护负担
  • 当 Web、API、APP 任一端的底层技术发生变化时，你都需要修改这个统一的框架。一个地方的修改可能会意外影响其他类型的测试，调试和回归测试成本极高
  • 使用者需要理解这套庞大的通用框架概念，才能编写特定类型的测试，增加了上手难度。维护者也需要精通所有领域才能修改这个 “巨无霸”

• 第二，AI 生成定位看似美好，但实际应用中元素动态变化会导致维护成本不降反升

  • 元素属性模糊、页面结构变化、存在遮挡或动态内容时，生成的定位器不稳定或易失效
  • 当 AI 识别失败或给出错误/不稳定的定位器时，你仍然需要人工干预去修正
  • 当测试失败时，排查是定位问题、AI 模型问题还是应用逻辑问题会变得困难

• 第三，平台化建设容易陷入功能堆砌，反而偏离测试本质

  • 构建一个功能完备、稳定、易用的自动化平台是一个极其庞大的工程，远比你想象的要复杂得多。它会消耗巨大的开发、测试、运维资源。你预计的一年时间可能连一个基本可用的核心版本都难以完成，更别提达到 “全栈全业务全场景” 的目标。这容易变成一个长期投入巨大却难以产生预期 ROI 的 “黑洞”
  • 市面上已有非常多优秀的开源和商业测试管理、执行、报告工具，完全自研所有功能是否必要？能否基于现有工具进行集成和二次开发？
  • 平台本身也需要持续开发新功能、修复 Bug、升级依赖、保障安全性和性能，这又是一个长期且沉重的负担
  • “让更多人参与”，目标用户是谁？是业务测试？开发？PO？不同角色需求差异巨大。一个试图满足所有人的 “全栈全场景” 平台，往往谁也服务不好
  • 计划投入一年时间做重构，这个成本可能远高于收益

我建议你最好拉你们产品经理进去讨论，别让技术思维完全主导了需求定义阶段
你们需要有跨角色协同验证，否则投入产出比严重存疑，风险巨大

你这里的槽点太多了，再说都可以写篇水帖了
最后
测试架构的最高境界应该是：在满足业务需求和质量目标的前提下，保持足够的简单、灵活和可维护性，并能快速适应变化

多关注业务盈利走向，如果不是本科记得提升学历，埋头技术是过去的玩法，现在不适用

虽然但是，我现在就在躺平呀 ，每天坐到五点半，工资又到手了
等 70 岁后退休了

区块链现在关联的都是 xn 币项目的吧？ 不太懂，有老哥在这一行，都是远程上班，他三年已经换了三家公司了，貌似挺灰色

面向盈利业务作为技术导向，就不会走歪

很正常，互联网的身份都是自己给的

某达、某马都有开设，不知道你指的大机构是哪些？
而且伪造就业率和创造需求焦虑不是搞培训班那帮人的特长吗？ 培训的逻辑是什么火就整什么，这样能最大限度揽到生意，你这是用打工人的思维去思考了

测什么业务的？

社区过时了

找实习要分春招和秋招，春招都过了很久了，现在没有实习生的坑。我建议你七八月再集中式投递，当然现在投也没差，说不定能捡漏

一般是这样的，业务这边需要人，然后人事就上报，上报同时也在招人，最终你面试通过后，你的期待薪资和要求也上报给老板了，老板忽然改变主意了或者他那一刻心情不好，你就黄了

遇到对应的问题去看才有用

我这里主要是想让应届生们小心 B 站、知乎、公众号弹出来的培训广告

练鸡器时，得穿着祖师爷的战衣

感觉你之前的测试路太顺了，才会有这种疑问

1【独立测试后端接口，再联调测试前端？】
过度理想化，接口测试通常只能覆盖单一层面的正确性（如参数校验、状态码），但无法验证业务场景完整性

• 前端可能组合调用多个接口完成一个业务场景
• 用户的操作可能以后台未预期的方式组合了多个接口调用，导致后端接收到不常见或未处理的参数组合
• 前端在展示数据时，依赖了接口返回的某些数据结构或字段，但这些依赖并没有在接口文档中明确说明，这导致后端修改接口时可能导致前端展示错误

2【测试人员提前编写接口自动化用例是否实际可行？】
接口文档就是渣男，实际中接口文档都是这样操作的

• 文档先行但实现滞后
• 实现先行但文档缺失
• 文档与实现并行变更

3【提测前介入自动化用例设计】
需求文档在开发过程中可能因以下原因频繁变更：

• 业务方临时调整规则
• 技术实现时发现原设计不可行
• 跨团队联调时发现字段缺失

个人建议先把测试用例写好，把测试前置条件需要的物料准备齐全，再做后沟通才是真理。至于自动化，它真的就是项目成功发布后，无重大功能漏洞才去写的。

还能咋办，骑驴找马跑路呗，不要以为年轻就可以挥霍健康，不值得

同感，其实物品这种我更倾向于便宜打包卖出去，除了电子设备和衣服
但是熟悉的环境、熟悉的朋友、熟悉的烧腊店我会开始舍不得。

如果，我说的是如果，你想进国企或者考公，里面有个东西叫职称，可以用得上

这家公司的业务性质貌似也是需要出差的，涉及到政府业务的，很多时候都是要去现场调试

现实还是残酷的，就这个【因为是专科】，boss 在规则上就把你过滤了，导致就算在 boss 上发起对话框，HR 也是看不到的。在 boss 上设置下公司类型（天使轮、公司人数少的）试试

首先 你这个年龄和工作时长，最好就是投管理岗，大头兵一般都会在一面被刷 (原因是一面的面试官，通常都是比你年轻的，我想人性都会是选择比自己年轻的)。

其次 想去一线大厂估计得看你之前的业务，看最近有哪些大厂在往这个业务方向新开一个项目，这样才有机会。

然后 二线或者小公司除了大量海投搏概率外（有些就算你面成功了，薪资你也谈不合），个人觉得没什么好的办法，毕竟你也没人脉找关系内推，至于提升技术，这个是悖论，你这个年龄段的，现阶段招人的游戏规则，都是别人都要你有项目实践经验的技术，所以你除了不断去总结自己以往的业务和技术沉淀外，其他再怎么学其实作用也不大 (个人看法，或者跳出当前的界限，去学一些偏门点的知识，如槽神转到影像测评)。

最后就是少看点幸存者偏差，如果真的好找，你也不会在这里发贴寻求肯定感了，现实情况就是难找难进。放低期待，疯狂海投，尽人事，其他看天命