当前位置：首页 > 文章列表 > Golang > Go问答 > Go testing.T.Attr 怎样把测试属性写进 JSON 事件流

Go testing.T.Attr 怎样把测试属性写进 JSON 事件流

来源：17golang原创 2026-10-23 01:29:30 0浏览收藏

我最近整理 CI 测试日志时，最先想到的是在测试里写一条 t.Log，再让流水线从文本中猜“这是哪个场景”。这种做法能用，但一旦日志格式变化，解析器就容易和正文输出绑死。Go 1.25 提供的 testing.T.Attr 则把测试属性单独放进事件流，更适合表达用例类型、组件名或环境标签。

它的关键不是把日志变成另一种字符串，而是给测试对象附加键值元数据：键不能包含空白，值不能包含换行或回车；使用 go test -json 时，这些信息会变成 Action 为 attr 的事件。下面按 API 契约、事件语义和兼容边界拆开说明。

先把 T.Attr 当成测试元数据接口

T.Attr 在 Go 1.25 加入 testing 包。它接收两个字符串：第一个是属性键，第二个是属性值。键和值的具体含义由 CI 系统或测试框架决定，Go 本身不会替你规定 component、tier 或 owner 这类业务命名。

testing.T、T.Attr、key、value 与测试元数据之间关系的静态说明图 — 图1：API 契约说明图，展示 T.Attr 的参数边界和元数据归属；这是静态说明图，不是运行截图。

我更倾向于把属性键设计成稳定的小词表，而不是把一整段 JSON 塞进 value。这样做便于 CI 查询，也能避免不同测试各自发明字段结构。

package checkout

import "testing"

func TestCheckout(t *testing.T) {
	// 属性描述测试对象，供 CI 或测试平台按键筛选。
	t.Attr("component", "checkout")
	// 用固定值标记测试层级，避免把标签混进普通日志文本。
	t.Attr("tier", "smoke")

	// 普通日志仍然用于解释过程，不承担结构化元数据职责。
	t.Log("准备购物车测试数据")
}

这个调用只适用于 Go 1.25 及以上的 testing.T。如果一份源码还要用旧版本编译器构建，直接调用新方法会在编译期失败，不能靠运行时判断来补救。

键值约束决定了属性应该怎么命名

官方约束很窄，但足够影响设计：key 不能包含空白；value 不能包含换行或回车。属性值可以是任意普通字符串，但不适合承担长篇诊断日志，也不适合编码一个依赖换行和空格解析的自定义协议。

比较稳妥的命名方式是“一项属性表达一个维度”，例如 component=checkout、tier=smoke、region=cn。如果一个测试有多个标签，可以连续调用多次；不要把调用顺序当成属性优先级，因为属性会立即写入测试日志，但官方明确把它们定义为无序信息。

设计对象	建议	原因
`key`	短、稳定、无空白	便于 CI 过滤和长期兼容
`value`	单行、可读、有限长度	避免与普通日志和换行协议混淆
调用次数	按独立维度拆分	解析器不必拆复合字符串
事件顺序	只当作属性集合读取	属性语义不是时间线

从 go test -json 读取 attr 事件

Go 1.25 的发布说明给出了明确变化：go test -json 会把测试属性表达为新的 attr 动作。对应的事件对象包含测试上下文以及 Key、Value 字段，因此 CI 解析器可以只筛选属性事件，不再从 Output 文本里猜标签。

测试函数、testing.T.Attr、test2json 与 Action=attr JSON 字段关系的静态结构图 — 图2：JSON 事件结构图，展示 attr 事件携带的字段和 CI 解析边界；这是静态说明图，不是运行截图。

# 只筛选属性事件，避免把普通 output 混入 CI 标签结果。
go test -json ./... | jq 'select(.Action == "attr") | {Package, Test, Key, Value}'

在事件层面，可以把结果理解为：Action 表示事件类型，Test 表示归属的测试，Key 和 Value 表示属性内容，Package 帮助流水线区分不同包。具体解析时仍应按 JSON 行逐条读取，不要假设并发测试的属性事件一定按人眼看到的顺序出现。

package main

import (
	"bufio"
	"encoding/json"
	"fmt"
	"os"
)

type testEvent struct {
	// 只保留 CI 关心的字段，未知字段由 JSON 解码器忽略。
	Action  string `json:"Action"`
	Package string `json:"Package"`
	Test    string `json:"Test"`
	Key     string `json:"Key"`
	Value   string `json:"Value"`
}

func main() {
	scanner := bufio.NewScanner(os.Stdin)
	for scanner.Scan() {
		var event testEvent
		// 每一行对应一个 JSON 事件，坏行要保留错误上下文。
		if err := json.Unmarshal(scanner.Bytes(), &event); err != nil {
			fmt.Fprintf(os.Stderr, "解析测试事件失败: %v\n", err)
			continue
		}
		if event.Action == "attr" {
			fmt.Printf("%s %s=%s\n", event.Test, event.Key, event.Value)
		}
	}
	if err := scanner.Err(); err != nil {
		fmt.Fprintf(os.Stderr, "读取事件流失败: %v\n", err)
	}
}

上面的解析器把属性当成独立事件消费，既不会破坏普通日志，也不会因为属性先后变化而改变测试结论。生产 CI 还可以在外层保留原始事件，便于遇到未知 Action 时向前兼容。

旧版本和 CI 解析器要留出兼容边界

如果模块需要支持 Go 1.24 或更早版本，可以把 T.Attr 的调用放在版本构建标签对应的文件中，旧版本继续使用 t.Log 或项目已有的标签机制。不要把不存在的方法藏在接口断言里：方法选择仍发生在编译阶段。

CI 侧则应采用“识别就消费、未知就保留”的策略。新解析器读取 Action=attr 后提取 Test/Key/Value；旧 Go 产生的事件流没有 attr 时，流程仍应根据 pass、fail、skip 和 output 正常完成。属性是辅助筛选信息，不应该替代测试的通过或失败状态。

我自己的取舍是：用例分类、组件名、运行层级这类低基数标签适合 T.Attr；一次性错误详情、堆栈和长文本仍然放到 t.Log 或失败输出里。这样既保持事件结构稳定，也不会把 CI 的索引变成一份难以维护的日志仓库。