Go 覆盖率很高但边界仍漏测的检查方式

Go 项目里最容易被误读的指标之一，就是 go test -cover 的百分比。覆盖率很高，只能说明测试运行时触达了不少可统计的语句或基本块；它不能自动证明空值、边界值、错误返回和组合条件都被验证过。真正实用的检查方式，是把“覆盖率统计”与“业务分支”拆成两张表，再逐个补齐会改变结果的输入。

先看 coverprofile 找到未触达的代码块，再回到函数的输入边界和错误分类设计测试。不要把 90% 当成分支测试已经完成。

本文用一个限制参数解析的例子说明这种排查方法。官方参考：https://go.dev/blog/cover、https://pkg.go.dev/cmd/cover。

先判断覆盖率到底覆盖了什么

Go 的 coverage 工具会在编译前给源码加入计数标记，测试运行后再根据计数汇总覆盖率。它关注的是可统计的代码块，不是测试人员脑中列出的业务分支。cmd/cover 文档还特别说明，工具使用近似的基本块信息，不会把 && 和 || 表达式内部的每个条件单独探测。

因此，下面三种情况都可能出现“百分比不错但边界没测”的结果：

• 一个测试输入穿过了函数的大部分语句，却没有触发错误返回。
• 多个判断写在同一表达式里，报告把它们归在同一统计块。
• 只测了一个正常值，恰好覆盖了成功路径，但没有覆盖最小值、最大值和越界值。

先生成 profile，再看函数和代码块分布：

# 先保存测试覆盖率文件，便于后续按函数和代码块排查
go test -coverprofile=coverage.out ./...

# 按函数查看覆盖率，先找明显偏低的函数
go tool cover -func=coverage.out

# 打开源码着色报告，定位没有触达的代码块
go tool cover -html=coverage.out

这里的报告是定位工具，不是质量结论。看到红色区域后，要继续问：它代表哪个输入边界？它返回哪一种错误？如果只是为了把颜色变绿而补一个无意义断言，覆盖率反而会掩盖测试设计问题。

用分支矩阵补齐真正的漏测

假设业务函数负责读取一个 1 到 100 的限制值。与其先写“覆盖率达到 100%”，不如先把结果分类：

package limit

import (
    "errors"
    "fmt"
    "strconv"
)

// ParseLimit 将外部文本转换为业务允许的限制值，并区分错误原因。
func ParseLimit(raw string) (int, error) {
    // 空输入单独返回，避免把用户缺少参数误报成格式错误。
    if raw == "" {
        return 0, errors.New("limit is empty")
    }

    // 转换失败说明输入不是十进制整数，保留底层错误便于定位。
    value, err := strconv.Atoi(raw)
    if err != nil {
        return 0, fmt.Errorf("limit is not an integer: %w", err)
    }

    // 上下界是独立的业务规则，越界不能与格式错误混在一起。
    if value  100 {
        return 0, fmt.Errorf("limit out of range: %d", value)
    }
    return value, nil
}

这个函数至少有五类输入：空字符串、非数字、下界 1、正常值、上界 100，以及越界值。测试表可以把“输入”和“期望结果”放在同一行，让漏测位置一眼可见：

func TestParseLimit(t *testing.T) {
    tests := []struct {
        name    string
        raw     string
        want    int
        wantErr string
    }{
        // 空值、格式错误和范围错误必须分别验证错误分类。
        {name: "empty", raw: "", wantErr: "limit is empty"},
        {name: "not-integer", raw: "abc", wantErr: "limit is not an integer"},
        {name: "lower-bound", raw: "1", want: 1},
        {name: "normal", raw: "20", want: 20},
        {name: "upper-bound", raw: "100", want: 100},
        {name: "above-upper-bound", raw: "101", wantErr: "limit out of range"},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            // 每个案例只检查自己的结果，失败时能直接回到矩阵行。
            got, err := ParseLimit(tt.raw)
            if tt.wantErr != "" {
                if err == nil || !strings.Contains(err.Error(), tt.wantErr) {
                    t.Fatalf("error = %v, want %q", err, tt.wantErr)
                }
                return
            }
            if err != nil || got != tt.want {
                t.Fatalf("got (%d, %v), want (%d, nil)", got, err, tt.want)
            }
        })
    }
}

示例中的断言使用了 strings.Contains，实际文件还需要补充对应导入。这里重点不在复制一份万能测试，而在于每个测试名都对应一个业务边界：缺参数、格式错、合法下界、正常值、合法上界、越界。若团队希望错误类型更稳定，也可以把字符串改成哨兵错误或自定义错误类型，再用 errors.Is 或 errors.As 断言。

把高覆盖率变成可执行的排错清单

覆盖率报告适合定位，分支矩阵适合决策。两者结合时，可以按下面的顺序检查：

1. 先看结果改变点：凡是会改变返回值、错误类型、状态码或资源清理动作的判断，都要有对应案例。
2. 再看边界两侧：对数值至少准备下界、合法值、上界和两侧越界；对字符串准备空值、格式错误和最短可接受值。
3. 单独看错误路径：错误被返回、包装或转换时，断言调用者真正关心的分类，不要只断言“有错误”。
4. 最后看 profile：用 go tool cover -func 找函数，用 HTML 报告找代码块，确认红区能映射回矩阵中的某一行。

如果一个红区无法映射到任何业务分支，先判断它是否是防御性代码、不可达分支或工具统计边界，不要机械补测试。如果矩阵中已有案例但报告仍未触达，再检查测试是否真的调用了目标函数、构建标签是否改变了源码，以及错误路径是否被提前返回。

常见问题

覆盖率 100% 是否代表分支 100%？

不代表。它通常说明被统计的语句或基本块都被触达，仍需要结合输入分类、错误路径和组合条件判断测试是否完整。

应该先补测试还是先追求百分比？

先补会改变业务结果的边界测试，再观察百分比变化。百分比是反馈信号，分支矩阵才是测试设计的依据。

总结一下：高覆盖率最适合回答“哪些代码被走过”，而边界矩阵回答“哪些结果被认真验证”。当两者能逐行对应时，覆盖率才真正成为 Go 排错和回归测试的工具。