testingCryptotest测试随机性

如果密码学测试每次都从系统随机源取输入，失败用例往往很难复现。Go 1.26 引入的 testing/cryptotest 提供了一个面向测试的固定随机入口：在测试函数里调用 SetGlobalRandom，就能让 crypto/rand 以及内部依赖它的密码学包在这段测试期间使用可重复的随机字节。

它解决的是“测试输入不可复现”，不是“把生产环境的密码学随机数固定下来”。迁移时要把调用放在非并行测试中，并保留算法输出可能随实现变化的余地。

升级范围：从手工替换 Reader 到 cryptotest

旧测试常见的做法是直接改写 crypto/rand.Reader，或者把一个自定义 io.Reader 传给待测函数。这两种方式都有边界：前者容易影响同进程的其它测试，后者要求生产函数暴露随机源参数，改动接口；而且某些密码学 API 内部会直接使用 crypto/rand，调用方并不能把 Reader 传进去。

testing/cryptotest.SetGlobalRandom(t, seed) 把固定随机源的生命周期绑定到 *testing.T。它只应出现在测试代码中，测试结束时由 t.Cleanup 恢复之前的 Reader。下面是迁移时需要记住的差异：

SetGlobalRandom 改变了哪一层随机来源

这个函数的关键不是把某个算法的结果写死，而是为当前测试设置一个确定性的密码学随机来源。官方实现会依据 seed 创建随机流，让 crypto/rand.Reader 在测试期间指向它；测试结束后再恢复之前的 Reader。这样，直接调用 rand.Read 的代码和内部间接调用 crypto/rand 的密码学代码，都能在同一测试范围内得到可复现输入。

可以把它理解成三层边界：

• 测试入口：只有带有 *testing.T 的测试函数才应该调用它。
• 随机源边界：影响 crypto/rand 以及密码学包中的隐式随机来源，不代表所有使用 math/rand 的代码都会被改变。
• 恢复边界：清理逻辑在测试完成后恢复原来的 Reader，避免固定随机源泄漏到后续测试。

最小迁移写法：固定 seed，不固定业务结果

下面的示例用 rand.Read 展示输入可复现。真正的业务测试可以把同样的调用放在生成密钥、签名或封装密钥的测试前，但断言应优先检查错误处理、格式和协议约束，不要把算法实现当前生成的每个字节永久写成兼容性契约。

package token

import (
    "bytes"
    "crypto/rand"
    "testing"
    "testing/cryptotest"
)

func readNonce(t *testing.T) []byte {
    t.Helper()
    nonce := make([]byte, 32)
    if _, err := rand.Read(nonce); err != nil {
        t.Fatalf("读取随机输入失败: %v", err)
    }
    return nonce
}

func TestNonceIsReplayable(t *testing.T) {
    // 固定测试期的 crypto/rand 输入，不改变生产代码的随机策略。
    cryptotest.SetGlobalRandom(t, 42)

    first := readNonce(t)

    // 在同一测试中重新设置相同 seed，得到同一段起始随机流。
    cryptotest.SetGlobalRandom(t, 42)
    second := readNonce(t)
    if !bytes.Equal(first, second) {
        t.Fatal("相同 seed 没有得到可复现的随机输入")
    }
}

示例里的两个调用都属于同一个测试对象，因此第二次调用会重置随机流；测试结束时 Cleanup 会恢复之前的随机来源。若测试本身调用了会消耗随机流的其它逻辑，断言时应把调用顺序固定下来，或者在更小的子测试中重新设置 seed。

迁移密码学 API 时，哪些断言更稳定

对于生成密钥、签名、封装等 API，固定随机输入主要用于复现错误分支、比较同一实现下的输入处理，或让回归用例稳定触发某个边界。它不等于官方承诺“某个 seed 永远对应某个密文”。Go 文档明确提醒，密码学算法如何使用随机数通常不是规范的一部分，未来实现调整后，即使继续使用 SetGlobalRandom，依赖具体输出的测试也可能失败。

func TestEncryptInputHandling(t *testing.T) {
    // 让本次测试的随机输入稳定，便于复现错误分支。
    cryptotest.SetGlobalRandom(t, 7)

    ciphertext, err := encryptMessage([]byte("demo"))
    if err != nil {
        t.Fatalf("加密失败: %v", err)
    }

    // 断言协议和数据形状，不把当前实现的密文全文当作长期契约。
    if len(ciphertext) == 0 {
        t.Fatal("密文不应为空")
    }
}

如果确实需要 known-answer test，应使用算法或测试包明确提供的固定输入接口，并把版本与实现范围写进测试说明；不要仅因为随机输入可重复，就推断所有输出都具备跨版本稳定性。

两个必须先处理的边界

不能和并行测试一起使用

SetGlobalRandom 影响整个进程的随机来源，因此不能在调用了 t.Parallel 的测试中使用，也不能放在具有并行祖先的测试里。即使两个测试使用不同 seed，也可能互相覆盖全局 Reader，造成偶发失败。

func TestCryptoCases(t *testing.T) {
    // 需要固定 crypto/rand 时，保持这个测试树不进入并行调度。
    cryptotest.SetGlobalRandom(t, 11)
    runCryptoCases(t)
}

func TestIndependentPureCase(t *testing.T) {
    // 不依赖全局随机源的纯计算测试可以单独并行，但不要和上面的测试共享状态。
    t.Parallel()
    runPureCase(t)
}

FIPS 140 v1.0.0 构建不支持

官方文档注明，使用 Go Cryptographic Module v1.0.0（可通过 crypto/fips140.Version 识别）构建时，SetGlobalRandom 不受支持。涉及合规构建的项目不能把普通开发环境中的这条测试路径直接当成所有构建配置都可用；应为该构建保留单独的测试策略，或者把需要固定随机输入的用例隔离在支持的测试配置中。

迁移后的回归检查清单

1. 确认调用只出现在 _test.go 文件，生产包没有依赖 testing/cryptotest。
2. 确认固定 seed 只用于复现和覆盖边界，不用于生成生产密钥、令牌或其它安全敏感值。
3. 确认使用它的测试及其祖先没有调用 t.Parallel。
4. 确认断言关注错误、格式、长度和协议属性，除非测试明确属于稳定的 known-answer 场景，否则不锁死整段密文。
5. 确认 CI 中的合规构建知道 FIPS 140 v1.0.0 不支持该函数，并有对应的跳过或替代策略。
6. 确认多个子测试的 seed 与调用顺序有意设计，避免把随机流消耗顺序变成隐形依赖。

小结

testing/cryptotest.SetGlobalRandom 适合把密码学测试从“偶尔失败、难以复现”推进到“输入可重放、边界可定位”。迁移的核心只有三点：在测试入口设置 seed，让 Cleanup 负责恢复；把全局影响当成非并行约束；把确定性当成测试输入能力，而不是算法输出的永久保证。

相关问题

SetGlobalRandom 会固定 math/rand 的结果吗？

它面向 crypto/rand 及密码学包中的隐式随机来源，不应把它当成 math/rand 的通用 seed API。普通伪随机业务请使用对应的 math/rand/v2 测试策略。

为什么不直接在测试里给函数传 Reader？

如果生产 API 已经合理地把 Reader 作为依赖注入，继续传 Reader 仍然清晰；cryptotest 更适合测试那些内部直接读取 crypto/rand、又不应该为测试改动生产接口的密码学代码。