AI代码审查结果怎么做回归验证

2026年2月记录，分类「AI测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。

审查结果怎么用

AI 代码审查能给出很多建议，但测试不能直接相信。更合适的方式是把建议拆成可验证的风险点。

对测试来说，最后要落到可复现、可验证、可交接，文章也是按这个思路写的。

验证策略

• 把审查结果按安全、性能、兼容、异常处理分类。
• 对高风险建议补充单元测试、接口测试或回归用例。
• 误报要记录原因，反向优化提示词或规则。

AI发现: SQL未加分页
人工确认: 高风险
回归: 大数据量列表查询 + 慢SQL监控

误报处理

• AI 指出的风险有人工确认。
• 修复代码

阅读全文

灰度发布和回滚演练的测试关注点

2024年12月记录，分类「持续集成」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。

灰度前

灰度发布不能只看新版本能不能访问，还要看流量切分、配置兼容、数据兼容和回滚路径。

整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。

灰度中

• 灰度前确认监控、告警、开关和回滚包。
• 灰度中对比新旧版本核心指标和错误日志。
• 回滚后验证数据、缓存和定时任务状态。

灰度10% -> 观察30分钟 -> 错误率/p95/告警达标 -> 扩到50%
异常: 立即切回旧版本并验证缓存状态

回滚演练

• 灰度比例和目标用户可控。
• 回滚

阅读全文

GitLab CI跑接口自动化的最小闭环

2023年2月记录，分类「持续集成」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。

最小闭环

GitLab CI 跑接口自动化，我先做最小闭环：拉代码、装依赖、跑用例、留报告。复杂能力后面再加，先保证失败有人看。

这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。

CI里放什么

• 按环境变量传入 host、账号和 token，不写死在仓库。
• pytest 输出 junit 和 html 两份报告。
• 失败时保留请求日志，方便不用进 Runner 也能定位。

api-test:
  script:
    - pyt

阅读全文