一提到质量度量，第一反应就是做一张大盘： 缺陷数 用例数 自动化通过率 冒烟通过率 发布次数 线上故障数 数字看起来很多，周报也能写满，但真正到了版本决策、问题复盘和流程改进时，常见情况却是： 指标不少，但没人知道哪些真的重要 同一个指标，测试、研发、项目经理看的数字都不一样 通过率很好看，版本还是频繁出问题 缺陷数在下降，但只是因为提单门槛越来越高 自动化覆盖率很高，关键链路仍然经常漏回归 这说明一个更根本的问题： 质量度量最难的部分...
在复杂业务项目里，测试最容易失控的原因，不是需求多，也不是系统大，而是风险没有被结构化识别。需求评审时看起来每个点都重要，提测后每条链路都想覆盖，发布前每个模块都想再回归一遍，最后形成的结果往往是测试动作很多，但真正高风险的位置没有被优先验证，回归范围却不断膨胀。 风险驱动测试的价值，不在于给测试工作换一个更高级的名字，而在于先回答三个关键问题：哪些对象最容易出问题，出了问题影响多大，当前测试资源应该优先砸向哪里。只有先把风险说清楚，测...
提到需求评审时，测试经常只做两件事： 听产品讲一遍需求 记几个待确认问题 这种参与方式看起来没有缺席，但实际价值很有限。因为需求评审阶段最关键的，不是“知道版本要做什么”，而是： 在开发开始之前，把后面最容易返工、漏测、上线后出事故的风险尽量拦下来。 这篇文章不讲“测试左移有多重要”，只讲一个更实际的问题： 需求评审阶段，测试到底应该重点拦哪些风险，怎么拦，拦完之后怎么追踪，才能真正影响后续质量结果。 一、需求评审阶段最容易被低估的，不...
一说“搭质量保障体系”，脑子里先冒出来的是： 要不要补一套完整测试流程 要不要上测试平台 要不要做质量度量大盘 要不要把评审、用例、提测、发布全串起来 这些方向本身没有错，但如果团队还在 10 到 30 人规模，研发节奏快、测试资源有限、业务变化又频繁，一上来就把体系做重，最后通常会出现三种结果： 流程文档很多，但真正拦不住风险 表单和会很多，但提测质量还是飘 测试、研发、产品都觉得“质量体系”是在增加负担 所以中小团队做质量保障，从 ...
说“版本已经提测了”，实际上只是做了两件事： 把包发到了测试环境 在群里喊了一句可以测了 后面会发生什么，往往全靠测试同学临场兜： 先确认环境是不是活着 再确认核心接口能不能通 再确认冒烟能不能跑 再判断这次失败到底该不该拦 这说明一个问题： ** 真正缺的不是测试动作，而是版本提测后的质量校验链路。** 如果这条链路没有设计好，就很容易出现下面几种常态化损耗： 明明是环境没准备好，却把一轮回归白白跑掉 明明是阻塞问题，却因为没有统一口...
第九章前面几篇，已经分别把测试平台真正难的几块拆开了： 后端骨架 模块边界 权限模型 调度与执行引擎 环境管理 报告系统 Jenkins 与告警 写完这些之后，再回头看一个具体项目，会更容易判断它现在到底处在什么阶段。 这篇就不写抽象的平台方法论了，而是直接回到一个具体项目： NexTest。 这次分析不只是参考之前那篇老的设计文，也把仓库本体拉下来过了一遍。从仓库状态看，它现在更准确的判断不是“已经有一个待打磨的平台”，而是： 还处在...
把测试平台接 Jenkins 这件事，最开始都理解成： 平台调一下 Jenkins Job Jenkins 跑一条命令 失败了发个企业微信 从功能上看，这已经能“联通”了。 但只要平台真的开始承接提测、回归、发布前校验和巡检，问题会很快冒出来： 平台里显示运行中，Jenkins 其实已经失败了 Jenkins 成功了，但平台没有收回完整结果 一个问题被多条渠道重复告警，告警渠道很快就会失去敏感度 环境性失败和真实业务失败混在一起，消息没...
做测试平台时，报告系统最开始都容易被理解成： 一张结果列表 一个成功失败统计 一页执行日志 从页面功能上看，这样已经像是“有报告了”。 但只要平台真正服务到多人协作，报告很快就会暴露几个典型问题： 只能看到失败，却看不到失败现场 同样的失败反复出现，但没有聚合视角 结果页能看，问题却没法复现 一次执行结束后，环境、参数、证据很快丢失 项目负责人问“这轮回归到底值不值得拦发布”，报告给不出结论 所以测试平台里的报告系统，本质上不是“结果展...
很多测试平台前期都容易把环境管理理解成一件很轻的事： 配一个 base url 配几套账号 切一下环境下拉框 页面上看起来像是做完了，但平台只要真正进入多人并发使用阶段，环境问题很快就会变成最频繁的一类故障来源： 同一条任务昨天能跑，今天突然全红 用例明明打的是测试环境，结果请求落到了预发 数据准备脚本互相覆盖，前后任务互相污染 任务执行完了，环境现场没有回收，下一个任务接着踩坑 报告显示是业务失败，根因其实是环境配置漂移 所以测试平台...
测试平台做到一定阶段后，最容易暴露问题的模块通常不是： 任务列表页 报告展示页 配置页面 而是平台最底层、但最容易被写轻的一层： 任务调度与执行引擎。 早期做平台，往往会把执行链路写成下面这种样子： 页面点一次执行 后端收一个请求 直接起进程或者调脚本 跑完把结果回写数据库 刚开始任务量少时，这种做法看起来完全能用。 但只要平台开始承载真实使用，问题会很快冒出来： 同一时间多个任务一起跑，资源抢占开始失控 任务执行到一半挂掉，平台不知道...