Golang测试与基准测试的边界如何划分

单元测试验证逻辑正确性，基准测试衡量性能达标性；二者目标、手段、失败含义均不同，不可混用。TestXxx专注输入输出断言与边界覆盖，BenchmarkXxx仅测效率、需隔离副作用、禁用手动设b.N。

单元测试和基准测试的职责边界在哪

单元测试验证「逻辑是否正确」，基准测试回答「性能是否达标」——二者目标不同、手段不同、失败含义也完全不同。混用会导致测试失焦：比如在 TestFoo 里测耗时，或在 BenchmarkFoo 里断言返回值，都是越界操作。

• TestXxx 函数只关心输入 → 输出是否符合预期，允许 t.Error/t.Fatal，必须覆盖边界值（如空输入、溢出、临界点）
• BenchmarkXxx 函数只关心执行效率，不检查结果对错；b.N 是框架自动调节的迭代次数，不能手动设固定值
• 若函数有副作用（如修改全局状态、写文件），必须在 BenchmarkXxx 中清除或隔离，否则基准结果不可复现

什么时候该写 Benchmark 而不是 Test

当你开始怀疑某段代码在真实负载下会拖慢系统，或者想对比两种实现的吞吐差异时，才需要基准测试。单纯“能跑通”不构成写 Benchmark 的理由。

• 典型场景：json.Marshal vs 自定义序列化、LRU 缓存不同淘汰策略、字符串拼接用 strings.Builder 还是 +
• 反例：测试一个纯计算函数是否返回 42，用 Test 就够了；加个 Benchmark 只是凑数
• 注意：go test -bench=. 默认不运行任何 TestXxx，需显式加 -run=^$ 避免干扰，否则初始化逻辑可能污染耗时统计

边界模糊地带：如何处理既要看结果又要测性能的函数

比如一个解析器既要返回正确 AST，又要求单次解析 ≤ 10ms。这时不能把断言和计时塞进同一个函数，而应拆成两个独立测试。

• 写 TestParse：专注校验输出结构、错误类型、边界输入（空字节、超长嵌套、非法字符）
• 写 BenchmarkParse：只喂入典型合法输入，调用前用 b.ResetTimer() 排除编译/初始化开销
• 若需关联两者（如“这个输入必须在 5ms 内解析成功”），用 CI 脚本或自定义检查工具，而非塞进测试函数里

容易被忽略的基准测试陷阱

很多人以为 Benchmark 只是多跑几遍，其实 Go 的基准框架对环境敏感度远超预期。

• b.N 不是并发数，而是单 goroutine 循环次数；想测并发性能，得用 b.RunParallel 或手动启 goroutine + sync.WaitGroup
• 未调用 b.ReportAllocs() 时，内存分配信息不会显示；但即使显示了，也要注意：小对象逃逸到堆上未必是 bug，Go 编译器优化可能动态决定
• 基

  

  准测试默认不启用 race detector；若被测函数涉及共享变量，需单独运行 go test -race -bench=.，否则竞态问题会被掩盖

最常被轻视的一点：基准测试的输入数据必须稳定。用 rand.Intn 生成随机切片长度，或每次 benchmark 读取不同大小的文件，都会让结果失去可比性——性能测试不是压力测试，它要的是确定性度量。