哪些函数适合做性质测试，哪些更适合示例断言

团队第一次接触 Go 模糊测试时，常见的误区是把它当成“自动多跑一些随机输入”。于是，格式化函数、数据库流程、HTTP 客户端和解析器都被塞进 FuzzXxx，结果有的测试很慢，有的失败无法复现，还有的根本说不清应该断言什么。

更稳妥的判断不是“这个函数能不能被 fuzz”，而是“这个函数是否存在跨大量输入都成立的性质”。输入域宽、执行快、结果确定，而且能写出不变量的函数，最适合性质测试；行为由少数关键样例、精确文本或外部状态定义的函数，更适合示例断言。核心业务往往需要两者组合。

Go 官方模糊测试文档：https://go.dev/doc/security/fuzz/

模式命名：用不变量替代样例穷举

性质测试的核心模式可以叫作“行为契约搜索”。测试不预先列出每个输入对应的精确输出，而是声明一个对整个输入域都应成立的关系，再让生成器不断寻找反例。

例如，一个归一化函数不一定容易为所有字符串写出期望文本，但它通常应该满足幂等性：第一次归一化之后，第二次处理不能继续改变结果。编码器与解码器可能满足往返性质；排序函数应同时满足有序性和元素守恒；解析器至少不应因任意字节输入而 panic。

Go 原生 fuzzing 使用覆盖率引导不断变异输入。官方文档要求模糊测试采用 func FuzzXxx(*testing.F) 形式，每个测试只能有一个 fuzz target；目标应当快速、确定，不依赖跨调用保留的状态。这个约束恰好说明：不是所有可调用函数都适合成为目标。

适用压力：函数特征比测试潮流更重要

判断时可以先问四个问题：输入空间是否大到手写样例明显覆盖不足？函数是否在相同输入下稳定返回相同结果？是否能写出比实现更简单的性质？一次执行是否足够快、没有不可控的外部副作用？四项越接近“是”，越适合性质测试。

典型实现：用幂等性测试归一化函数

假设 Normalize 会清理多余空白并统一文本形式。示例测试可以证明几个常用输入正确，但很难覆盖空字符串、连续控制字符、异常 Unicode 组合和很长文本。幂等性则能覆盖更大的输入域。

func FuzzNormalize(f *testing.F) {
    // 种子覆盖空白、普通文本与多语言文本等有意义的起点。
    for _, seed := range []string{" A  B ", "hello", "你好  Go"} {
        f.Add(seed)
    }

    f.Fuzz(func(t *testing.T, input string) {
        once := Normalize(input)
        twice := Normalize(once)

        // 归一化应满足幂等性，第二次处理不能继续改变结果。
        if once != twice {
            t.Fatalf("Normalize is not idempotent: once=%q twice=%q", once, twice)
        }
    })
}

这个测试不要求先知道任意输入的标准答案，只要求性质本身足够可靠。如果 Normalize 的产品定义允许每次调用逐步收敛，幂等性就不是正确契约；此时应先澄清语义，而不是为了使用 fuzzing 硬造一个性质。

Go 会先运行通过 f.Add 和 testdata/fuzz 提供的种子，再在 go test -fuzz=FuzzNormalize 模式下变异输入。发现失败后，工具会尝试缩小输入，并把失败案例写入对应的 testdata/fuzz/FuzzNormalize 目录。修复之后，这个输入会随普通 go test 一起运行，成为回归测试。

哪些函数通常适合性质测试

解析器与反序列化入口

解析器面对的输入域天然很宽，攻击者或损坏数据也不会遵循人工样例。最基础的性质是“不 panic、不死锁、不无限消耗资源”。如果存在序列化器，还可以验证 Decode(Encode(x)) 与原对象在业务意义上等价。

归一化、去重与规范化函数

URL、路径、标识符、空白、大小写和集合归一化通常具备幂等性。还可补充边界性质，例如输出长度不超过上限、结果中不再包含非法分隔符，或者同义输入得到相同规范值。

排序、集合和可逆转换

排序可检查结果有序且元素多重集不变；集合操作可检查交换律、结合律或幂等性；压缩/解压、编码/解码、加密/解密可检查往返。这里要留意有损转换：图片压缩或浮点量化不能直接断言完全相等，而应定义误差边界。

有参考实现的优化代码

一个简单但较慢的实现常常是最好的测试 oracle。让 fuzzing 同时调用参考版和优化版，可以搜索分支、溢出、边界长度和特殊字符造成的不一致。参考实现必须足够独立，否则两边复制同一个错误只会得到虚假的安全感。

反例：这些函数更适合示例断言

精确展示输出。金额、日期、日志字段、错误提示和导出格式的价值就在于具体结果。此时“长度合法”或“不 panic”远远不够，应该用清晰样例锁定完整字符串或结构字段。

状态型业务流程。订单从待支付到已支付、库存预占与释放、审批角色权限等行为，通常由有限状态和明确业务规则定义。表驱动示例可以把前置状态、动作、期望状态和副作用写清楚，比随机拼装一个大型状态机更容易审查。

外部 I/O 与时间依赖。数据库、网络、文件系统、真实时钟和随机源会让 fuzz target 变慢或不确定。应先把纯计算核心拆出来做性质测试，外围适配器用 mock、fake 或集成示例测试验证。不要把不可控的外部系统直接放进高速变异循环。

只有少数有意义输入。例如会员等级只有四种，税率只有几个明确档位，权限动作来自固定枚举。此时列出完整样例比引入生成器更直接，也更能充当可读规范。

后果：最有效的方案通常是混合测试

性质测试擅长发现“没想到的输入”，示例断言擅长说明“业务明确要求什么”。两者不是替代关系。一个稳健的解析模块可以同时拥有三层测试：

1. 示例层：固定文档中的标准输入、历史故障和关键错误信息。
2. 性质层：验证任意输入不 panic、合法对象往返一致、输出满足边界。
3. 回归层：保留 fuzzing 找到并最小化的失败语料，防止修复后复发。

这种组合还有一个架构收益：为了让核心逻辑可快速、确定地被 fuzz，团队往往会把纯计算从数据库、时钟和网络适配器中拆出来。测试策略因此反向推动了更清晰的依赖边界。

判断清单

• 能否用一句话描述跨大量输入成立的性质？
• 性质是否比被测实现更简单，不会重新实现一遍业务代码？
• 相同输入是否能稳定复现相同结果？
• 单次执行是否快速，并且不依赖全局可变状态？
• 输入域是否足够大，随机变异能够带来超过手写样例的价值？
• 是否仍保留了能解释关键业务语义的示例断言？
• 失败语料是否会进入版本库并成为普通回归测试？

延伸问答

只检查“不 panic”算性质测试吗？

算，但通常只是最低层性质。对解析器和安全边界很有价值；对业务转换函数还应补充往返、幂等、守恒、范围或参考实现等更强契约。

性质测试可以完全替代表驱动测试吗？

不建议。表驱动测试最适合表达关键案例和精确期望，性质测试更适合拓展输入空间。两者组合后，测试既可读又能主动找反例。

随机失败很难复现怎么办？

Go fuzzing 会保存并缩小失败输入，可用输出中的 go test -run=FuzzName/hash 重放。前提是目标本身确定，不依赖真实时间、全局状态或外部服务。

应该从哪个函数开始？

优先选一个执行快、输入为字符串或字节、曾出现边界缺陷并且能写出明确不变量的纯函数。解析器、规范化器和编解码器通常比完整业务流程更适合作为第一批目标。

归根结底，测试方式应由行为契约决定：能用不变量描述的广阔输入域交给性质测试，必须用具体结果解释的业务语义交给示例断言。把两者放在同一套测试设计里，Go 模糊测试才会从“随机跑一跑”变成可持续积累的质量资产。