系列专栏:测试工程师每日一博 · Day 19上一篇:[Day 18 · 测试工程师的成长地图:从初级到资深,这五年学什么]这是系列第二次跳脱测试自己,回答测试跟邻居职能怎么分地盘。Day 18 谈向上成长,Day 19 谈向左右协作。目标:不画独占地盘,只把交叉地带的协作工程化——让三方协作靠 YAML / 接口 / playbook,而不是人情。一、为什么必须有这一篇工业里一个反复出现的撕裂:“这个监控告警是谁的活?”测试说:“我已经把 CI 红线拉好了,告警是 SRE 的”;SRE 说:“告警来了只是数据,测试才知道哪些是真事故”;DevOps 说:“我搭了告警管道,具体怎么用是你们俩的事”。三个职能互相推活,质量漏洞就出现在缝隙里。这一篇来把这些缝隙填上。1.1 三职能的定位差异先给三个职能一张定位卡,所有人必须读到一致:职能核心使命时间维度成功的标志测试工程把质量风险量化为业务决策编码前到上线前“应该发现但没发现的缺陷” 0DevOps让代码从开发到上线跑得快且稳提交到部署部署频率↑、变更失败率↓、恢复时间↓(DORA)SRE让系统在生产里可靠上线后持续SLO 达成率↑、错误预算未耗尽注意时间维度那一列——三职能的核心战场时间轴互不重叠,但有交叉地带。Day 19 主要解决交叉地带怎么分。1.2 工业里三个常见误解讲清三职能定位之前,先撕掉三个反复出现的误解:“DevOps 就是写 CI / CD 脚本的”—— 错。DevOps 的本质是「让交付管道短而稳」,脚本只是表面动作。资深 DevOps 工程师花更多时间在 DORA 指标的优化(部署频率、变更失败率、平均恢复时间)上,而不是写 YAML;“SRE 就是运维的升级版”—— 错。SRE 的核心是「用工程方式解决运维问题」,从告警规则、SLO 设计到混沌实验都是工程行为。把它当高级运维等于浪费 SRE 一半的能力;“测试 QA 手工验收员”—— 错。这一份误解最毒。测试工程的核心是把「质量」量化、可决策(回扣 Day 18 §6.2.1 质量策略)。把它压成点鼠标的人,你只用了测试工程师 5% 的能力。撕掉这三个误解,后面的协作才能聊——不能把邻居看扁了再谈协作,那是单边独白。二、地盘分割矩阵把工业里常见的 12 项关键工程动作,按谁主谁辅谁不参与分割:工程动作测试DevOpsSRE单元测试主——集成 / 契约测试主——E2E 测试主辅(提供 flaky 隔离环境)辅(给线上数据样本)CI 流水线辅(测试 stage)主辅(给预生产 SLO 卡)CD 流水线辅(灰度门控)主辅(灰度观察 SLO)性能压测主辅(跑脚本)辅(给生产分布数据)监控告警规则辅(写测试红灯规则)辅(管道维护)主SLO / SLI 定义辅(给测试覆盖转 SLI映射)—主上线发布按钮辅(给测试绿灯)主辅(给SLO 绿灯)回滚辅(给应回滚信号)辅(执行机制)主(决定回)故障复盘辅(写红灯 case 系统漏洞)辅(postmortem 平台)主(主持)容灾 / 混沌实验辅(设计用例)辅(基础设施)主读法:粗体是该动作的主责人,辅是该动作的协作角色,空是不参与。可以一眼看出:没有任何一行只有一个职能单独干。所有 12 项都至少两个职能协作。这就是为什么地盘大战无解 —— 地盘本来就不是独占的,是分工的。三、CI / CD 里的协作:测试 vs DevOps最常见的协作场景。DevOps 主战场,测试是强势协作者。3.1 阶段划分开发者 push PR │ ↓ [Step 1] Pre-commit hook(lint / type check / format) │ DevOps 主 / 测试不参与 ↓ [Step 2] PR check(单测 覆盖率 Pact verify) │ 测试 主 / DevOps 提供运行环境 ↓ [Step 3] Merge to main → 集成测试 安全扫描 镜像构建 │ DevOps 主 / 测试辅(集成测试) ↓ [Step 4] Deploy to staging │ DevOps 主 / 测试不参与 ↓ [Step 5] E2E 回归 性能基线 │ 测试 主 / DevOps 提供 flaky 隔离 runner ↓ [Step 6] 部署生产(灰度 5% → 25% → 50% → 100%) │ DevOps 主 / 测试 SRE 给绿灯 ↓ [Step 7] 发布后观察窗(1h,看 SLO) SRE 主 / 测试不参与每一步都有清晰的 “主 / 辅” 标签。没标签的步骤,就是漏点——比如 Step 6 灰度阶段,如果测试没给基于回归的绿灯标准,DevOps 会把测试通过理解为自动化全绿,但实际可能是自动化 200 个用例都没跑这个 canary 流量。3.2 一个常见冲突的解法冲突:DevOps 想把 PR check 时间压到 5 分钟内,测试想跑全覆盖。错误解法:互相吵架(DevOps 说测试太慢,测试说质量不能让步)。正确解法:用 Day 7 的时间门控分层——PR check 只跑 ≤ 5 分钟的快速子集(主单测 关键契约);每夜跑全集(全 E2E 性能基线);不让全集绿成为合并的硬性依赖,而是次日修复的节奏。这套分层是 Day 7 已给过的工程动作。三方协作的冲突 → 用工程方式化解,不要用人情协商。四、生产可观测性:测试 vs SRESRE 主战场,测试悄悄来加测试红灯。4.1 监控规则里测试工程师该写的回扣 Day 12 §4 SLO burn rate 告警,SRE 通常负责的是基础设施告警(CPU、内存、QPS、5xx 率)。但测试工程师可以加一类规则:# alerts/testing-rules.yaml — 测试工程师写的,不属于 SRE base alertsgroups:-name:testing_gatesrules:# 规则 1:已被 Tag(prod_incident) 标记的 case 在回归里挂了# 高优告警,因为这代表历史故障复现-alert:ProdIncidentRegressionFailedexpr:ci_test_failures{tagprod_incident}0for:5mlabels:{severity:critical}annotations:summary:生产故障附件用例回归失败,可能复发历史事故# 规则 2:契约测试 provider verify 红灯# 高优,因为 provider 部署可能被 consumer 跳版本而破坏-alert:PactProviderVerifyFailedexpr:pact_verify_status{sideprovider} 0for:10mlabels:{severity:high}这两条规则特别:测试工程师写的告警,挂在 SRE 的告警系统里。SRE 的 oncall 看到红灯时知道是测试视角的事故预警,不会跟CPU 80%那类阈值告警混在一起。4.2 SLO 共同定义回扣 Day 15 §3,SLO 不能只 SRE 一人写。测试工程师要贡献:可用性目标:基于测试覆盖的失败模式反推哪些 SLI 必须达成;延迟 SLI:基于压测容量曲线(Day 15 §5)给 P99 阈值给数据;错误预算:基于质量策略(Day 18 §6.2.1)给消耗优先级。也就是说,测试是 SLO 的输入侧,SRE 是 SLO 的执行侧。两边都不写就是空契约。# slo-definition.yaml 三方共建(Day 18 §6.2.1 Day 15 这一节)slo:-name:order-api-availability target:0.999# 由 SRE 写:基于生产 SLI 历史数据派生rationale_sre:过去 90 天 5xx 率中位数 0.02%,目标 0.1%# 由测试写:哪些测试红线对应这条 SLOrationale_test:对应 Tag(order_api_availability) 50 条回归 case# 由 DevOps 写:部署频率对该 SLO 的影响rationale_devops:每周 3 次部署,每次 0.03% 部署失败预算份额window:30drationale_sre / rationale_test / rationale_devops三行字段是约定。每条 SLO 后面跟三个理由,三方对齐。这也是把地盘化为协作的工程动作。五、上线 / 回滚决策:三方都参与最热点的协作场景。出问题时三方看法往往不一致:决策点测试的看法DevOps 的看法SRE 的看法何时该回滚回归 case 持续 flaky部署成功率 95%burn rate 4x谁按按钮不主动按部署者主按oncall 主按(P0)回滚后干啥跑 smoke test 验恢复看部署日志没拖尾看 SLO 回到基线谁主导复盘测试补红灯DevOps 改部署流程SRE 写时间线注意谁按按钮那一行——按钮的主人是按场景分:部署中失败(部署成功率低)→ DevOps 按钮(部署者);部署后 8 小时内出问题 → SRE 按钮(oncall P0);上线一周后复发历史故障 → 测试发现后报告,DevOps 按钮。提前把哪种场景谁按钮写到 release playbook 里,比事后推活强 10 倍。六、典型的三不管地带工业里反复出现的责任真空:6.1 孤儿测试基础设施谁维护 selenium grid / k6 cluster / Testcontainers 镜像?测试:我用,但不维护基础设施;DevOps:这是测试用的,我不管;SRE:不在我生产 KPI 里。结果:跑了一年后镜像没人升级,有一天安全扫描扫出 CVE,所有人慌了。解法:把它当成二级生产系统,挂 SRE 的 SLA( 4h 响应),但投资改造由测试主导。6.2 测试监控的数据源测试告警需要 PR 历史 / CI 结果 / 测试覆盖率 —— 这些数据归谁管?DevOps:维护 CI,但数据出口不在职责里;SRE:看的是生产指标不是 CI 指标;测试:用数据,但不维护存储。结果:测试告警系统拼凑,数据延迟严重。解法:DevOps 负责数据出口(webhook / API),测试负责消费 告警规则。6.3 性能压测的专属环境性能压测(Day 15)需要专属环境,不能跟 staging 共用。测试:我用;DevOps:维护 staging,不为压测单独起;SRE:还是不在我生产 KPI 里。解法:把性能环境写成 IaC(terraform),由 DevOps 主导维护,测试只是消费者。七、协作的工程动作:CI 友好信号协作不能只靠我说你听。测试工程师应该把信号发给两边:7.1 给 DevOps 的信号(测试质量红线)# ci-quality-gate.yamltest_quality:min_coverage:0.7max_flaky_rate:0.02pact_verify:requiredperf_baseline_drift_max:0.15# 性能回退不能 15%fallback_action:block_merge# 不达标 → DevOps 流水线拒绝合并这个 YAML 由测试工程师维护,但DevOps 的 CI 工程必须读取。这就是测试质量翻译为DevOps 流水线行为的接口。7.2 给 SRE 的信号(质量红线映射 SLO)defcoverage_to_slo_risk(coverage:dict,slo_targets:dict)-dict: 测试覆盖率 → SLO 风险评估 回扣 Day 18 §6.2.1:让 SRE 的告警决策能考虑测试盲点 risky_areas[]forslo,targetinslo_targets.items():# 该 SLO 关联的代码路径覆盖率covcoverage.get(slo_to_path[slo],0)ifcov0.5:risky_areas.append({slo:slo,coverage:cov,risk:高,# 测试盲区 → 这条 SLO 不知道会发生啥recommendation:建议把 burn rate 告警阈值从 4x 降到 2x,})returnrisky_areasSRE 看到建议阈值降一档的输入,会比看到测试覆盖率 60%有用 10 倍。翻译永远是协作的桥。八、回扣系列Day在 Day 19 它对应Day 1-7§3 CI 协作(测试 vs DevOps)Day 8§3 TDD 红绿是 PR check 的核心Day 9§7.2 Pact verify 必进 DevOps 门Day 10§6.1 flaky runner 维护真空Day 11§3.1 PR check 是左移的执行点Day 12§4 SLO burn rate(SRE 主)Day 13§7.2 LLM 报告解读成信号Day 14§6.3 压测专属环境(IaC)Day 15§4.2 SLO 三方共建(test 输入侧)Day 16§5 上线 / 回滚决策三方Day 17§3 PR review 协作(测试 开发 DevOps)Day 18§1.1 三职能定位卡的成熟度12 条回扣,跟 Day 16 / Day 17 同样级别的总调用。这是合情合理的——想讲清楚地盘,必须把前 18 天的工具 / 流程 / 闭环全部重新调一次。九、协作反模式反模式表现后果“Venn 图思维”试图画出独占地盘漏掉交叉地带“我用你不管”测试用 测试维护测试基础设施腐烂数据出口模糊谁出口 PR / CI 数据不明确测试告警延迟监控规则只 SRE 写测试红灯不在告警系统里故障复发率高部署门控不互联DevOps 不知道测试质量红线低质量合入“StackSize 大讨论”在层级深度上推诿工程动作无主责十、原则三句话没有独占地盘,只有分工协作—— 12 项关键动作至少两个职能协作;协作靠工程接口——YAML / 文件 / API,不要靠人情协商;测试给 DevOps / SRE 的价值,是翻译—— 把质量风险翻译为 CI 行为 / SLO 输入。十一、思考题留给今晚:你团队的 CI 流水线,测试 / DevOps / SRE 各自主哪几个 stage?有没有重叠或真空?灰度发布时,谁会按暂停 / 回滚按钮?这个决策有 release playbook 文档吗?你的 CI 质量门控 YAML(§7.1)是谁维护?DevOps 知道它的存在吗?上一次故障复盘(Day 16 §4.2 时间线),时间线由谁拼起来?是 SRE 独力 测试 / DevOps 在旁边看吗?十二、TL;DR三职能定位:测试(质量风险量化) / DevOps(代码到部署快稳) / SRE(生产可靠);12 项关键动作的地盘分割矩阵 —没有任何一项是单职能独占;CI 五阶段 部署两阶段 故障五阶段都需要三方协主;三个 “三不管” 地带(测试基础设施 / 测试数据出口 / 性能压测环境)需要明确归属;协作靠工程接口:ci-quality-gate.yaml / SLO rationale_* / coverage_to_slo_risk 接口。下一篇:Day 20 ·测试工程师的 OKR 与度量:把质量翻译为可量化指标这是系列第 20 篇里程碑。把这一系列所有的工程动作收束为测试团队 OKR 的指标体系 —defect density、testability score、flaky rate、mean time to detect、contract coverage,让质量成为驱动决策的数字,而不是团队内部的形容词。下篇见