匿名节选
持续集成门禁如何写进评分表
Software Engineering · 项目报告 · 本科 · 1,600 词
Software Engineering项目报告本科
节选在证明什么
小组项目把覆盖率阈值写进 CI，却在 flaky 测试上浪费评审时间。报告建议按模块划分门禁：领域逻辑强制单测，UI 用契约测试，端到端只保留三条主路径。
辅导没有要求继续刷覆盖率，而是把每一次红分成必须阻断和可警告。UI 超时进后者，库存扣减错误进前者。
这样写比“我们有 80% 覆盖率”更接近工业评审，也更符合多数 capstone rubric 里的 maintainability 一栏。
节选是策略说明，不是一份可复制的 yaml。你的课程环境、语言和禁止使用的服务，以 syllabus 为准。
适合谁
面向本科质量课或小组项目：交付物经常是一张“我们有 80% 覆盖率”的截图。适合 CI 很吵、评审时间被 flaky 测试吃掉的小组。
覆盖什么
- 按模块划分门禁，而不是一个全局覆盖率数字
- 领域逻辑强制单测，UI 用契约测试
- 端到端只保留三条主路径
- 承认 UI 测试不稳定，并写清哪些失败必须阻断合并
- maintainability 一栏要的是可重复构建，不是更多功能
怎么进行
- 01先列出当前流水线每一次失败的原因：真缺陷、环境、还是 flaky。
- 02把门禁分层。领域逻辑红了不能合并；UI 超时进警告。
- 03端到端缩到三条主路径，避免把流水线变成噪声源。
- 04报告写清阈值为什么这样设，而不是再刷覆盖率。
在 CS / SE / AI 里怎么落地
Software Engineering
质量课和 capstone 的 maintainability 分，通常比再加一个页面更值钱。
Computer Science
编译或系统 lab 的自动评测也可以用“哪些失败必须阻断”来写报告，但此例是 CI 课。
Artificial Intelligence
训练流水线若作为工程交付，同样要写哪些检查阻断合并（数据校验、种子、指标回归）。
辅导焦点（可迁移的方法）
- 门禁分层
- 承认不稳定测试
- 用阻断规则对齐评分表
节选经过改写与匿名处理，不是学生提交原文，也不作为代写样本出售。对应学科见课程树。
这一页常被问到的
课程强制 80% 覆盖率怎么办？
达到课程阈值，同时写清阈值测的是什么。不要用无断言的测试刷数字。
flaky 能不能删掉？
能隔离就隔离。不能删的，降级为警告并写进已知问题，而不是假装全绿。