使用 Foundry 进行 Solidity 模糊测试与安全验证指南

引言

智能合约往往由于极少数临界参数下的逻辑失效（如整型向下溢出、负数条件判断缺失）而被黑客攻破。在过去，开发者依赖 Hardhat 编写基于 JavaScript 的常规单元测试。这种测试方式必须预先设定测试输入（如“测试 stake 10个币”），很难覆盖到那些超出常理的边界值。

为了建立可复查的代码质量基线，平头工坊倾向于在适用项目中引入 Foundry 测试框架，并对核心资金流转代码开展模糊测试（Fuzzing Test）与不变性测试（Invariant Test）。

1. 什么是模糊测试 (Fuzzing Test)？

模糊测试（Fuzzing）是指通过向目标函数输入大量的随机随机数，来检测合约逻辑是否会崩溃。

1.1 传统测试 vs 模糊测试

传统单元测试：测试 withdraw(100) 和 withdraw(200)。
模糊测试：测试 withdraw(x)，其中 x 是由 Foundry 测试套件随机生成的成千上万个 uint256 随机数值（包括 0、1、type(uint256).max 等极端值）。

1.2 编写一个简单的 Fuzzing 测试

在 Foundry 中，编写模糊测试可以从带参数的测试函数开始；具体运行次数应以项目的 foundry.toml、命令行参数和 CI 配置为准：

// Foundry 模糊测试用例示例
function testFuzz_Withdraw(uint256 amount) public {
    // 1. 限制随机数范围，使其符合基本物理规则
    vm.assume(amount > 0 && amount <= 10000 ether);

    // 2. 模拟用户存入代币
    stakingContract.deposit{value: amount}();

    // 3. 执行提现并验证合约状态
    uint256 balanceBefore = address(this).balance;
    stakingContract.withdraw(amount);
    uint256 balanceAfter = address(this).balance;

    assertEq(balanceAfter - balanceBefore, amount);
}

2. 深入不变性测试 (Invariant Testing)

模糊测试局限于单个函数的随机测试，而**不变性测试（Invariant Testing）**则是测试整个智能合约在任何可能的交易序列调用后，其底层的某些物理常数或“绝对真理”是否永远成立。

2.1 不变性的经典例子

对于一个去中心化借贷协议或 AMM DEX：

质押池不变性：全网用户本金余额之和 + 累积协议利息 ≡ 合约地址实际持有的 ERC20 代币余额。
DEX 不变性：在没有充值和提取的情况下，流动性池的乘积常数 $x \times y = k$ 在任何 swap 交易后均不得减小。

2.2 不变性测试配置

Foundry 可以按测试配置随机组合调用目标合约的暴露接口（如 stake、unstake、claim、transferOwnership），随后核对断言（Invariant Assertions）是否保持为真。一旦断言被打破，测试会提供相应的调用序列，帮助定位需要复核的状态路径。

3. 从模糊测试到工程验证

在平头工坊，我们将 Foundry 测试流程整合在 GitHub Actions 中：

覆盖率目标：根据合约范围和风险设定覆盖率目标，并记录未覆盖路径及原因。
模糊运行次数 (Runs)：根据逻辑复杂度、执行成本和 CI 时间预算配置 fuzz.runs，再用测试结果决定是否扩大样本。
静态分析：可按项目依赖和审查范围接入静态分析工具，结果需要结合人工复核。

结论

智能合约没有第二次机会。把代码交给安全审计公司之前，自己在本地通过 Foundry 进行高强度的模糊测试和不变性演练，是每个合格的 Web3 团队应该具备的工程底线。