湛江

也不算，只是想让自己的视野开阔些，接触些不同的行业，毕竟周末我也没事干

【国企里面做技术能干到退休吗？】可以，也不可以
【这些岗位跟私企的工作内容有什么区别吗？】有区别，也没区别，运气好说不定可以当网管

上面的人都回答得差不多了，我就扯几句没用的。

• 【把这个需求文档扔给 ai】

这个你要注意下，由于你是 tob 项目的，可能会涉及泄密，甚至引发法律问题

• 【是测试点的时候就还好，但是一描述成具体的用例就感觉很奇怪】

这一点我刚出来时也有过，这种感觉之所以奇怪是因为你心里没底。

tob 业务流程复杂，涉及多角色、多系统交互，需求是偏向业务逻辑而非用户体验，这导致主流程下会有很多的支线流程。而写测试点容易停留在主干流程，但写成具体用例时需要覆盖各种分支场景，这导致设计时感到逻辑缠绕，因此心里没底就会产生” 奇怪 “的感觉。

• 举例：贷款审批流程

根据流程列出大概的测试点：
1.客户提交贷款申请
2.审核员审核资料
3.系统自动评估信用评分
4.审批人审批贷款
5.系统发放贷款资金

这些看起来都很清晰，是标准的 “主流程”，你也脑补了写测试用例时要把场景法、边界值法、场景法等用上，细分出异常场景。

等真正上手写了，就会被分支流程搞得没底，比如：

• 客户上传资料不全 → 审核员退回修改
• 系统评估信用评分低于阈值 → 自动拒绝
• 审批人驳回申请 → 客户可重新提交
• 审批人审批后系统放款失败 → 记录日志并通知人工处理
• 审批过程中客户取消申请 → 状态变更，终止流程
• 多个审批人角色（初审、终审）→ 不同权限控制不同操作
• 多系统交互（如风控系统返回错误）→ 异常处理机制

你试图把这些分支全部写进测试用例时，就会发现：
流程图越来越复杂
用例数量剧增
很难确保所有组合都被覆盖
心理上自然会产生 “奇怪” 的感觉：“我是不是漏了什么？ ”

1 这时候你就可以尝试用 “场景法”+“状态迁移法” 进行结构化设计，来缓解这种 “奇怪” 感

• 将整个流程抽象为多个 “状态节点”
• 每个状态之间定义合法/非法的转换路径
• 画出状态图或流程图

[申请中] --(提交)--> [待审核] --(审核通过)--> [待审批] --(审批通过)--> [已放款]
                ↓ (审核不通过)
                 [资料补充]

2 然后 “边界值法” 与 “异常路径” 做到明确

• 列出所有可能导致流程中断的因素（如网络、权限、数据异常）
• 对每类异常单独设计用例 (不要贪多一例多查，一个用例就检查一种情况)
• 明确系统应对异常如何反馈、记录、恢复

3 用 “判定表” 减少冗余，判定表早期面试还真的挺多人问，现在挺多人都不知道咋用了

• 对于多个条件组合（如用户角色 + 状态 + 操作类型），可以用判定表统一管理
• 避免重复写类似用例，提高维护性

4 测试用例设计需要分层

主流程用例 核心业务线

子流程用例 主流程中的小步骤

异常用例 各类失败情况

这样分层后，你可以按层逐步验证，避免一次性陷入细节而迷失方向感到害怕

由于测试只有你一个，不需要给自己太大压力，顺其自然发育即可，多跟开发们、产品们沟通交流，多留意项目的盈利情况和用户客诉。至于用上什么技术提效，这个是自然而然的，你闲事可以想想或者跟 AI 讨论或者找开发们探讨，如果公司体量变大了，就可以申请跟公司要求加人，你业务最熟悉自然而然也会变成小组长，然后面试时找个技术还行的进来完成你的构想

社区现在有些仿佛说不得 ，怕这种热闹也是稍纵即逝

自己看看我想指明的主语。。。【被裁员过的，在地主家当下短工的，还真把自己当什么人物了？】指的是他例子中举例的 P7 或者 P8。。。。。。。。。。。。。。。。。。，还是那句话，不回你又被你带节奏，回你又说破防，你无不无聊？

不吵了，不吵了，
等会下班去吃个烧鹅饭，裂开，早知道不举例鹅腿了

实在不行，用字节的 trae，也是挺好用的，关键现在免费

不回你又被你带节奏，回你又说破防。至于饭圈，这没办法呀，我今天中午去烧腊店买鹅腿，跟另外一个人讨论了下烧鹅腿是皮好吃还是肉好吃，结果来了个莫名起来的人起哄说我无理，那我肯定会觉得这个人与对面是一伙的，否则关他屁事？，你要是觉得不爽，我可以回复你一句通用的：啊是是是对对对😂

信息茧房是他自己评论上先说的，我只是套用
” 老江湖 “这个词我不觉得是什么人身攻击，比起” 阴阳人 “、跳梁小丑” 等词那可是柔和得多，你要是不理解可以问下 AI 或者查下词典。还有我一直知道社区里是有捧臭脚的饭圈文化的，我也不太懂我这小段评论马上就引发他的各种猜测，包括【你自己不想靠技术吃饭也好，或者没本事靠技术吃饭也好，没人拦着你，但别挖苦和嘲笑人家努力耕耘的人】，当然你的呕像们都是正义的，我怎么说也咩用，表达是你的自由

飞仔周岁 38 吧

我只是觉得他挺可怜的，一个四十几岁的人，嘴上说着没关系，发评论时却急到人身攻击了，得引以为鉴，低自尊的人真可怕

我好惊呀，高飞蝈蝈

小孩子不懂事，说着玩的。

倒是你空窗两年还能被你找到影像测评的方向，这很 6

对不起，伤害到你家鸽鸽了 ，我自罚这个月朝九晚五和只吃喝玩乐，这样就会不断堕落，然后被董事们狠狠的敲打

人比较蔡，也不太懂你说的，所以让 DeepSeek 分析下你过激的动机, 如果说错了请怪 DeepSEEK

这个人的心理状态可以从多个角度进行分析，体现了他强烈的情绪化表达和深层心理动机：

1. 身份认同危机与防御机制
   
   他反复强调自己从外包到大厂的经历（"外包干起，带实习生"）、列举高薪案例（"字节年薪 135W"），本质是通过"职业逆袭叙事"构建技术精英人设。当这种身份认同被质疑时（被指出"信息茧房"），触发了心理防御机制——通过攻击对方（"老阴阳人""挖苦努力的人"）来维护自我价值，同时用薪资数字、大厂光环等外部符号强行巩固话语权。

2. 认知失调的补偿行为
   
   他提出"技术决定职业高度"的核心论点后，面对可能存在的反例（如被裁员的大厂员工），采用了三种典型策略：① 选择性举证（只提幸存的高薪案例）；② 归因偏差（将他人成功归为技术，潜在失败归为环境）；③ 群体绑架（"问问社区里大家是不是..."），实则是通过营造"技术至上"的集体共识来缓解自身认知矛盾。

3. 职场创伤的代偿心理
   
   字里行间透露出对技术能力的过度执念（"测试开发必须写代码""监控平台才是未来"），可能源于早期职业经历中的身份焦虑——作为外包/三本出身，曾因"非技术"标签被边缘化。这种创伤转化为对纯技术路线的极端推崇，甚至将技术能力与人格价值绑定（"嘲讽技术弱=否定努力"），实则是用当下的技术权威姿态掩盖曾经的职业卑微感。

4. 阶层优越感的暴力建构
   
   他通过薪资数字（135W/月薪 8K）、企业层级（外包 - 小厂 - 大厂）、技术门槛（AI/线上平台）构建了一套鄙视链坐标系。当对话者质疑这套体系时，他采用"老板视角"（"去问老板锤不锤你"）和"市场决定论"进行降维打击，本质是将职场达尔文主义包装成客观真理，以此获得心理制高点。

5. 群体归属的焦虑投射
   
   反复强调"测试开发改名""行业趋势变化"，实则是对自身技术路线可能过时的潜意识恐惧。通过攻击"嘲讽技术者"来维护技术群体的神圣性，本质是将个人职业安全感寄托于群体认同——当他说"别把他们永远按死在这里"时，真正害怕被"按死"的或许是自己。

这种心理状态的危险性在于：他将技术工具理性异化为价值判断的唯一标准，用薪资数字解构职业多样性，最终陷入"技术原教旨主义"的思维闭环。其破防的本质，是意识到自己构建的技术乌托邦并不具备普世性，而激烈反驳恰恰暴露了体系脆弱性。

大家出来摸鱼，就是为了放松心情嘛

哈哈哈哈哈，是不是天天在社区被奉承惯了，看到别人说句实话就破防了（容我先笑会）

你这说话水准和社区扫地僧争论时的差不多

这就是面向业务，写测试用例、和开发沟通、与产品砍需求时都是很有用的，也可以让测试的视野开阔些

个人推荐 Mac mini ，性价比高而且不存在电池损耗
移动办公是个伪需求，正常情况下办公都会要求在公司电脑上，个人电脑最好别搀和进公司项目

你也有你自己的信息茧房，别一开口就一副老江湖的样子，什么接触下大厂员工，又不是咩接触过被裁员过的，在地主家当下短工的，还真把自己当什么人物了？。我再次保持我的结论，唯技术论的最终都会搞培训。还有，有机会还是尝试跳出大头兵的位置，眼界和世界观才可以更真实些

对于公司来说，员工就是耗材，越用只会越旧，怎么可能会升值？
技术岗的人容易有一种自我感动，以为提升技术 (其实大多数就是造轮子的能力) 就能提升在公司里的价值，
可以去观察社区里或者你们公司里的，基本坐上管理层的，就没几个去卷技术的，人到中年还在奋战在一线的都是大头兵牛马 (大头兵牛马做的功劳基本都归功于所属领导,自己品品这其中的道理)，这些都是周期轮换的耗材。
对于资本来说，你的价值是：年龄 + 健康度 + 岗位业务价值 + 重置成本 + 技能稀有度

其实是可以问出来的，没人问是因为旧时代的测试都以懂点开发技术为荣，南辕北辙。以社区评论功能为例，如果往业务深度问

1.请描述社区评论功能的核心目标是什么？它在整体社区生态中的作用是什么？

1. 设计一个评论功能时，你会优先考虑哪些用户需求？为什么？

3.一个评论功能的完整流程，如何划分关键节点？每个节点的核心目标是什么？

4.如何解决用户评论被误判为敏感内容的问题？你会如何优化审核机制？

5.如果社区评论功能的 DAU 下降，你会从哪些维度分析原因？

6.如何衡量评论功能对社区活跃度的贡献？你会设计哪些关键指标?

7.如果用户反映评论功能 ‘无法及时看到自己的评论’，你会如何定位问题并解决？

8.假设某个热门话题下评论量激增，导致页面加载缓慢，你会如何优化？

9.社区评论功能未来可以如何扩展以增强用户粘性？

10 如果公司计划推出视频评论功能，你会如何评估其可行性？

11.如果技术团队认为评论功能的审核逻辑过于复杂，你会如何协调需求？

12 你观察到哪些竞品在评论功能上有创新？这些创新解决了什么问题？

13.未来 3 年，社区评论功能可能会面临哪些挑战？你会如何应对？

业务理解深度就是其思维方式、问题解决能力和业务敏感度的体现，一般说得好的，工作上不会差到哪去的

我个人觉得测试一直以来就一个部分：业务质量验证。
业务值钱测试就值钱，业务亏损，测试就曼巴 out。
其他都是增量市场的衍生物，卷技术想要利益最大化就只有培训和传播技术焦虑

https://developers.weixin.qq.com/doc/oplatform/Return_codes/Return_code_descriptions_new.html 错误码
https://developers.weixin.qq.com/miniprogram/dev/framework/ability/pre-fetch.html 数据预拉取

看下微信小程序的文档，另外建议用下字节的 trae，都可以问