前面的 80% 责任完全不合理吧

同意，深层问题逃逸，研发技术内审，用例评审等都没挖掘出来，测试不是主责，咋测试用例范围的出问题，测试应该主责

提问：在 IT 行业，测试人员测试通过的需求在线上出现了事故。本次事故的主要责任人是否可以认定为测试人员？

豆包回复：
不能直接认定测试人员是本次事故的主要责任人。
线上事故的责任认定，核心看问题根源和流程责任，而非单一环节。
一、先明确：事故的 “根因” 在哪？
需求 / 设计问题
需求本身不清晰、有歧义、逻辑矛盾
设计方案有缺陷、边界考虑不全
→ 根因在产品 / 设计，测试按需求测，不背主责。
开发代码问题
代码逻辑错误、并发 / 性能问题、未处理异常
开发自测 / 单元测试不到位
→ 根因在开发，测试是 “二次验证”，不是 “兜底”。
测试覆盖 / 执行问题
测试用例漏场景、边界 / 异常没测到
测试环境与线上差异大，未模拟真实场景
测试执行不严谨、误判通过
→ 根因在测试，测试需承担主要或重要责任。
运维 / 发布 / 配置问题
发布流程错误、配置错误、权限 / 环境问题
灰度 / 回滚机制缺失
→ 根因在运维 / 发布，与测试无关。
外部依赖 / 不可抗力
第三方服务故障、网络问题、安全攻击
→ 与测试无关。
二、再看：流程与职责边界
测试的职责是发现问题，不是保证零缺陷。
若流程本身有缺陷（如无评审、无灰度、无监控），导致问题漏到线上，流程 / 管理责任大于个人责任。
若测试已按规范执行，问题属于 “极难复现 / 极端场景”，则测试责任显著降低。
三、结论：如何认定主责？
根因在需求 / 设计 / 开发 / 运维 → 对应角色主责，测试最多是 “次要 / 连带责任”（如未及时质疑需求、未做风险提示）。
根因在测试覆盖 / 执行 → 测试主责。
根因在流程 / 管理缺失 → 团队 / 管理主责，而非单一测试。
一句话：测试通过≠测试全责，线上事故≠测试背锅，关键看 “问题是谁造成的、谁本可以避免”。
如果你愿意，我可以帮你按 “根因分析五步法”，把你这次事故的责任链拆清楚，给出可落地的责任认定和改进建议。

测试是无穷尽的，在有限的时间测试有限的范围，通过三方评审拉齐测试范围，没测到更应该只测试用例范围的漏测，而不是说一个未知的问题没测到。我感觉这样解释比较合理

谢谢~~~

谢谢大佬，用 json 提取就好了

好奇怪。。我的就提不出来。。。换了 3.3 就提出来了。。。

嗯呢。谢谢啦。。就是不知道为啥不能用方法 cookise 的方法。。。

没有错。。第二个是 APP 登录的，研发说需要自己解析 header 格式，从 header 里面取 token 值。。。。