主题
跑测试与看报告
测试它自己跑——改完代码先自测再交活；您要做的只是看懂报告、知道什么时候该多要一层验证。
测试谁跑、什么时候跑
| 时机 | 它做什么 |
|---|---|
| 改完功能 | 自动跑受影响范围的测试（只测相关的，不跑全量——快而且够用） |
| 您说「跑一下测试」 | 按您指定的范围跑（某个模块 / 全部） |
| 提交推送前 | 推送门禁自动把关（见提交与推送代码） |
| 新写功能 | 它补测试——单测 + 集成测试，跟代码一起交付 |
为什么不每次跑全量
全量测试动辄十几分钟，绝大多数用例与本次改动无关。它按影响面定向跑——这是又快又稳的工程惯例。您真要全量（发版前），直接说「跑全部测试」。
报告怎么看
测试跑完，报告在对话里直接给。三个关键数字：
text
✅ 42 通过 ❌ 1 失败 ⏭ 0 跳过| 数字 | 正常吗 | 要做什么 |
|---|---|---|
| 全部通过 | ✅ 正常 | 看一眼覆盖说明即可 |
| 有失败 | ⚠️ 看情况 | 它先自己修——修好重跑；修不好会如实说卡在哪 |
| 有跳过 | ⚠️ 不该有 | 跳过的用例要有理由（环境缺依赖等），无理由跳过它自己会揪出来 |
失败不是坏消息——测试的价值就是抓问题。它修完会把「失败原因 → 修复方式 → 重跑结果」连成一条线给您看。
什么样的改动值得多要一层验证
| 改动 | 建议要的验证 |
|---|---|
| 核心业务逻辑（支付、权限、库存） | 「补个边界测试：金额为 0 / 超大值会怎样」 |
| 界面交互（表单、弹窗、流程页） | 「浏览器里实际点一遍截图给我」（见浏览器实测怎么看） |
| 接口契约变更 | 「把受影响的调用方都验一遍」 |
| 数据库结构变更 | 「迁移脚本在测试数据上跑一遍」 |
说一句就够——它按这层标准补验证。
测试出报告后，您还可以
text
「这个失败的用例，讲讲为什么失败」 → 它引用报错逐条解释
「给购物车模块补几个异常场景的测试」 → 补测并跑给您看
「这次改动有没有漏测的地方」 → 它做覆盖自查并报告测试报告之外：质量分层
代码质量不止「测试过」一层，它按工程节奏分层把着：
- 写码时：遵循项目规范（有规范文档就按规范写）
- 改完时：类型检查 + 受影响测试
- 界面类：真实浏览器实测（自己打开、自己点、自己截图）
- 提交时：推送门禁最后一道把关
您平时只需要在验收节点看结果；中间层自动运行。
常见卡点
| 现象 | 怎么办 |
|---|---|
| 测试一直跑不完 | 大概率在跑全量或等依赖服务——问它进度，或让它收窄范围 |
| 报告看不懂术语 | 直接说「测试报告用人话讲一遍」——它翻译成业务影响 |
| 测试过了但用着还是坏 | 测试覆盖与真实使用有差——把真实操作路径告诉它（现象 + 复现），让它补对应场景 |
| 想看某次改动到底测了什么 | 「这次改动跑了哪些测试、覆盖了什么」——它列清单 |
| CI / 环境依赖缺东西 | 它会说明缺什么；本机环境问题见工具链与环境 |