当前位置:首页 >专题 >Go 测试证据与 CI 回归工程实践专题

Go 测试证据与 CI 回归工程实践专题
Go 测试证据与 CI 回归

Go 测试证据与 CI 回归工程实践专题

从测试隔离、产物留存到可复现回归定位
测试通过只是一个瞬间,真正能支撑交付的是可重复的测试环境、清晰的隔离边界和可回看的失败证据。本专题围绕 Go testing、testing.T.ArtifactDir、httptest、并行测试、环境变量、Fuzzing 语料和 Git bisect,串起从本地测试到 CI 回归定位的完整工程闭环。

站内隔离与回归实战文章

按依赖隔离、并发边界、失败留证和回归定位顺序练习

Go httptest用 NewServer 隔离外部依赖的测试结构
文章

Go httptest用 NewServer 隔离外部依赖的测试结构

用 httptest.NewServer 构造本地上游,验证请求路径、请求头、状态码和响应体。
Go testing.T.Parallel 子测试共享数据怎么隔离
文章

Go testing.T.Parallel 子测试共享数据怎么隔离

分析并行子测试中的切片、map、请求对象和包级变量共享风险。
Go testing.T.Parallel 调用后为什么要等待父测试返回
文章

Go testing.T.Parallel 调用后为什么要等待父测试返回

解释 t.Parallel 的暂停、父测试生命周期和并行组释放时序。
Go 测试里修改环境变量为什么不能和 t.Parallel 一起用
文章

Go 测试里修改环境变量为什么不能和 t.Parallel 一起用

说明 t.Setenv 的进程级影响及其与并行测试的冲突边界。
Go testing.F 失败语料保存在哪里
文章

Go testing.F 失败语料保存在哪里

区分 testdata/fuzz 语料、fuzz cache 和代码中的 f.Add 种子。
Go 1.27.1 的 encoding/json 和 net/http 修复如何纳入回归测试
文章

Go 1.27.1 的 encoding/json 和 net/http 修复如何纳入回归测试

用行为契约和版本矩阵验证标准库点版本修复,而不是只看命令是否通过。
Git bisect 怎么自动运行测试定位引入回归的提交
文章

Git bisect 怎么自动运行测试定位引入回归的提交

使用 git bisect run 和稳定退出码自动缩小引入回归的提交范围。
Git bisect run 怎么用测试脚本自动找回归提交
文章

Git bisect run 怎么用测试脚本自动找回归提交

用可测试、回归、跳过三类退出码编写可靠的 bisect 检查脚本。

常见问题

回答测试证据和 CI 回归落地时最容易混淆的四个问题

testing.T.ArtifactDir 和 testdata/fuzz 应该怎么分工?

ArtifactDir 适合运行过程中生成的日志、快照、诊断和临时证据;testdata/fuzz 适合需要随代码提交、长期稳定复现的 fuzz 语料。

为什么本地通过而 CI 偶尔失败?

优先核对测试缓存、并行共享状态、进程级环境变量、时钟和随机种子,再把失败日志、版本和产物目录固定归档。

Go CI 中应该每次都运行 race 和 fuzz 吗?

普通提交可运行快速单测和短时 race;fuzz 更适合定时或专项流水线,并把发现的稳定失败输入沉淀为普通回归测试。

git bisect 的测试脚本什么时候应该返回 125?

当当前提交因缺依赖、缺生成文件、无法构建或环境不完整而无法判断好坏时返回 125,让 Git 跳过该提交;确定复现回归才返回 bad。

微信登录更方便
  • 密码登录
  • 注册账号
登录即同意 用户协议隐私政策
返回登录
  • 重置密码