公共区块链（如以太坊）是不可变的，这使得在部署后修改智能合约代码变得很困难。 虽然存在用于执行“虚拟升级”的合约升级模式，但这些模式很难实现，并且需要社会共识。 此外，升级只能在发现错误_之后_修复——如果攻击者先发现了漏洞，你的智能合约就面临被利用的风险。
出于这些原因，在部署到主网之前测试智能合约是安全的最低要求。 有许多用于测试合约和评估代码正确性的技术，你可以根据需求进行选择。 然而，由不同工具和方法组成的测试套件很适合捕捉合约代码中的细微或重大安全缺陷。
前提条件
本页面将解释如何在部署到以太坊网络之前进行智能合约测试。 本文假设你熟悉智能合约。
什么是智能合约测试？
智能合约测试是验证智能合约代码是否按预期工作的过程。 测试对于检查特定智能合约是否满足可靠性、可用性和安全性的要求非常有用。
虽然具体的方法可能各不相同，但大多数测试方法都要求使用合约要处理的少量样本数据执行智能合约。 如果合约样本数据能产生正确的结果，就可以认为合约能正常运行。 大多数测试工具都提供了用于编写和执行测试用例 (opens in a new tab)的资源，以检查合约的执行是否与预期结果相符。
为什么测试智能合约很重要？
由于智能合约通常管理着高价值的金融资产，微小的编程错误就可能且经常导致用户遭受巨大损失 (opens in a new tab)。 但是严格的测试可以帮助你在部署到主网之前，及早发现智能合约代码中的缺陷和问题，并进行修复。
虽然在发现漏洞后可以升级合约，但升级过程很复杂，如果处理不当可能会导致错误 (opens in a new tab)。 进一步升级合约会削弱不可变性原则，并给用户增加额外的信任假设。 相反，对合约进行全面测试的计划可以减轻智能合约的安全风险，并减少在部署后执行复杂逻辑升级的需求。
智能合约的测试方法
测试以太坊智能合约的方法可分为两大类：自动化测试和手动测试。 自动化测试和手动测试各有独特的优点和权衡，但你可以将二者结合起来，创建强大的测试计划来分析你的合约。
自动化测试
自动化测试使用工具来自动检查智能合约代码的执行错误。 自动化测试的好处在于，它使用脚本 (opens in a new tab)来指导对合约功能的评估。 脚本化测试可以按计划重复运行，人工干预极少，因此自动化测试比手动测试更高效。
自动化测试特别适用于以下情况：测试重复且耗时；手动执行困难时；容易出现人为错误时；或涉及评估关键合约功能时。 但自动化测试工具有其缺点——它们可能会漏掉某些漏洞，并产生许多误报 (opens in a new tab)。 因此，理想的方法是结合自动化测试与手动测试。
手动测试
手动测试需要人工辅助，在分析智能合约的正确性时，涉及逐个执行测试套件中的每个测试用例。 这与自动化测试不同，在自动化测试中，你可以同时在合约上运行多个独立的测试，并获得显示所有失败和通过的测试的报告。
手动测试可以由单个人员按照包含不同测试场景的书面测试计划进行。 你还可以在指定的时间段内，让多个个人或团体与智能合约进行交互，作为手动测试的一部分。 测试人员将对比合约的实际行为与预期行为，将任何差异标记为错误。
高效的手动测试需要大量的资源（技能、时间、金钱和精力），由于人为错误的存在，在执行测试时可能会错过某些错误。 但手动测试也有好处，例如，人工测试人员（例如审计员）可以凭直觉来检测自动化测试工具可能忽略的边缘情况。
智能合约的自动化测试
单元测试
单元测试对合约功能分别进行评估，并检查每个组件是否正常工作。 良好的单元测试应该简单、运行快速，并且在测试失败时清晰地说明出了什么问题。
单元测试对于检查函数返回预期值以及在函数执行后正确更新合约存储非常有用。 此外，在更改了合约代码库后运行单元测试，可以确保添加新逻辑不会引入错误。 以下是运行有效单元测试的一些准则：
智能合约单元测试指南
1. 理解你的合约业务逻辑和工作流程
在编写单元测试之前，了解智能合约提供的功能以及用户如何访问和使用这些函数很有帮助。 这对于运行正常路径测试 (opens in a new tab)特别有用，该测试用于确定合约中的函数是否为有效的用户输入返回正确的输出。 我们将使用这个（节选的）拍卖合约 (opens in a new tab)示例来解释这个概念。
constructor(
uint biddingTime,
address payable beneficiaryAddress
) {
beneficiary = beneficiaryAddress;
auctionEndTime = block.timestamp + biddingTime;
}
function bid() external payable {
if (block.timestamp > auctionEndTime)
revert AuctionAlreadyEnded();
if (msg.value <= highestBid)
revert BidNotHighEnough(highestBid);
if (highestBid != 0) {
pendingReturns[highestBidder] += highestBid;
}
highestBidder = msg.sender;
highestBid = msg.value;
emit HighestBidIncreased(msg.sender, msg.value);
}
function withdraw() external returns (bool) {
uint amount = pendingReturns[msg.sender];
if (amount > 0) {
pendingReturns[msg.sender] = 0;
if (!payable(msg.sender).send(amount)) {
pendingReturns[msg.sender] = amount;
return false;
}
}
return true;
}
function auctionEnd() external {
if (block.timestamp < auctionEndTime)
revert AuctionNotYetEnded();
if (ended)
revert AuctionEndAlreadyCalled();
ended = true;
emit AuctionEnded(highestBidder, highestBid);
beneficiary.transfer(highestBid);
}
}
复制Solidity显示全部 (49)
这是一个简单的拍卖合约，用于在竞标期间接收竞标。 如果 highestBid 增加，之前的最高出价者会收到他们的钱；一旦竞价期结束，beneficiary 就会调用合约来取钱。
对这样的合约进行的单元测试将涵盖用户在与合约交互时可能调用的不同函数。 例如，一个单元测试可以检查用户在拍卖进行期间是否可以出价（即对 bid() 的调用成功），或者检查用户是否可以出比当前 highestBid 更高的价格。
了解合约的运行流程还有助于编写单元测试，以检查执行是否满足要求。 例如，拍卖合约规定，当拍卖结束后（即 auctionEndTime 小于 block.timestamp 时），用户不能出价。 因此，开发者可以运行一个单元测试，检查当拍卖结束时（即 auctionEndTime > block.timestamp 时），对 bid() 函数的调用是成功还是失败。
2. 评估与合约执行相关的所有假设
重要的是记录关于合约执行的任何假设，并编写单元测试来验证这些假设的有效性。 除了提供对意外执行的保护之外，测试断言还迫使你思考可能破坏智能合约安全模型的操作。 一个有用的技巧是不仅要进行“正向测试”，还要编写负面测试，检查函数对错误的输入是否会失败。
许多单元测试框架允许你创建断言，即简单的语句，用于说明合约的能力和限制，并运行测试以验证这些断言在执行过程中是否成立。 在运行负面测试之前，对之前描述的拍卖合约进行开发的开发者可以对其行为做出以下断言：
当拍卖结束或尚未开始时，用户无法进行竞标。
如果竞价低于可接受的阈值，合约将会回滚。
未能赢得竞标的用户将获得其资金的退款
注意：另一种检验假设的方法是编写测试来触发合约中的函数修饰符 (opens in a new tab)，尤其是 require、assert 和 if…else 语句。
3. 度量代码覆盖率
代码覆盖率 (opens in a new tab)是一种测试指标，用于跟踪测试期间执行的代码中的分支、代码行和语句的数量。 测试应该具有良好的代码覆盖率，以最大程度地减少未经测试漏洞的风险。 如果没有充足的代码覆盖率，你可能会误认为你的合约是安全的，因为所有测试都通过了，而未经测试的代码路径中仍存在漏洞。 记录高代码覆盖率，可以确保智能合约中的所有语句/函数都经过了足够的正确性测试。
4. 使用完善的测试框架
运行智能合约单元测试时所使用的工具质量至关重要。 理想的测试框架需经常进行维护；提供有用的功能（例如，日志记录和报告功能）；并且必须经过其他开发者广泛使用和审核。
单元测试框架用于对 Solidity 智能合约进行单元测试，提供不同语言的选择（主要是 JavaScript、Python 和 Rust）。 请参阅下面的指南，了解如何开始使用不同的测试框架运行单元测试：
使用 Brownie 运行单元测试 (opens in a new tab)
使用 Foundry 运行单元测试 (opens in a new tab)
使用 Waffle 运行单元测试 (opens in a new tab)
使用 Remix 运行单元测试 (opens in a new tab)
使用 Ape 运行单元测试 (opens in a new tab)
使用 Hardhat 运行单元测试 (opens in a new tab)
使用 Wake 运行单元测试 (opens in a new tab)
集成测试
虽然单元测试可以独立调试合约函数，但集成测试会将智能合约的各个组件作为一个整体进行评估。 集成测试可以检测到跨合约调用或同一智能合约中不同函数之间的交互引起的问题。 例如，集成测试可以帮助检查继承 (opens in a new tab)和依赖注入等功能是否正常工作。
如果合约采用模块化架构或在执行过程中与其他链上合约进行接口交互，集成测试将非常有用。 运行集成测试的一种方法是在特定高度（使用 Forge (opens in a new tab) 或 Hardhat (opens in a new tab) 等工具），并模拟你的合约与已部署合约之间的交互。
分叉的区块链将与主网的行为类似，其帐户具有关联的状态和余额。 但是它只是一个沙盒式的本地开发环境，举例来说这意味着你不需要真正的以太币进行交易，同时你的更改也不会影响真实的以太坊协议。
基于属性的测试
基于属性的测试是一种检查智能合约是否满足一些定义的属性的过程。 属性是关于合约行为的断言，预期其行为在不同的场景中始终保持为真。智能合约属性的一个例子可以是“合约中的算术运算永不溢出或下溢”。
静态分析和动态分析是执行基于属性的测试的两种常用技术，二者都可以验证一个程序（在本例中为智能合约）的代码是否满足某些预定义属性。 有些基于属性的测试工具提供预定义的合约属性规则，并根据这些规则检查代码，而其他工具则允许你为智能合约创建自定义属性。
静态分析
静态分析器接受智能合约的源代码作为输入，并输出结果，声明合约是否满足某个属性 与动态分析不同，静态分析不涉及执行合约来分析其正确性。 静态分析则可以推断智能合约在执行过程中可能采取的所有路径（即通过检查源代码的结构来确定合约在运行时的操作意义）。
Linting (opens in a new tab) 和静态测试 (opens in a new tab)是对合约运行静态分析的常用方法。 这两种方法都需要分析由编译器输出的合约执行的低级表示形式，例如抽象语法树 (opens in a new tab)和控制流图 (opens in a new tab)。
在大多数情况下，静态分析对于检测合约代码中的安全问题非常有用，例如使用不安全的结构、语法错误或违反编码标准。 然而，静态分析器通常被认为在检测更深层次的漏洞方面不够准确，并且可能会产生过多的误报。
动态分析
动态分析为智能合约的函数生成符号输入（例如，在符号执行 (opens in a new tab)中）或具体输入（例如，在模糊测试 (opens in a new tab)中），以查看是否有任何执行轨迹违反了特定属性。 这种基于属性的测试形式与单元测试不同，因为测试用例涵盖多种场景，并且由程序处理测试用例的生成。
模糊测试 (opens in a new tab)是动态分析技术的一个示例，用于验证智能合约中的任意属性。 模糊测试工具使用随机或畸形的变化调用目标合约中的函数，以对预定义的输入值进行测试。 如果智能合约进入错误状态（例如，断言失败），问题会被标记，并在生成的报告中包含驱动执行进入脆弱路径的输入。
模糊测试对于评估智能合约的输入验证机制非常有用，因为对于非预期输入的处理不当可能导致意外执行并产生危险影响。 这种基于属性的测试形式可能非常理想，原因有多种：
**编写涵盖多种场景的测试用例很困难。**基于属性的测试只需要你定义一个行为和用于测试该行为的数据范围——程序会根据定义的属性自动生成测试用例。
**你的测试套件可能无法充分覆盖程序中的所有可能路径。**即使代码覆盖率达到 100%，也可能漏掉边缘情况。
**单元测试证明合约对样本数据的执行是正确的，但合约对样本之外的输入的执行是否正确仍然是未知的。**基于属性的测试使用一个给定输入值的多个变体来执行目标合约，以找到导致断言失败的执行轨迹。 因此，属性测试为合约在广泛的输入数据类别下正确执行提供了更多的保证。
运行智能合约的基于属性的测试指南
运行基于属性的测试通常从定义要在智能合约中验证的一个或一组属性（例如，不存在整数溢出 (opens in a new tab)）开始。 在编写属性测试时，你可能需要定义一个数值范围，程序可以在此范围生成用于交易输入的数据。
配置正确后，属性测试工具将使用随机生成的输入执行你的智能合约函数。 如果存在任何断言违规情况，你应该获得一份报告，其中包含违反正在评估的属性的具体输入数据。 请参阅下面的指南，了解如何使用不同的工具开始运行基于属性的测试：
使用 Slither 对智能合约进行静态分析 (opens in a new tab)
使用 Wake 对智能合约进行静态分析 (opens in a new tab)
使用 Brownie 进行基于属性的测试 (opens in a new tab)
使用 Foundry 对合约进行模糊测试 (opens in a new tab)
使用 Echidna 对合约进行模糊测试 (opens in a new tab)
使用 Wake 对合约进行模糊测试 (opens in a new tab)
使用 Manticore 对智能合约进行符号执行 (opens in a new tab)
使用 Mythril 对智能合约进行符号执行 (opens in a new tab)
智能合约的手动测试
在开发后期，经常会进行智能合约手动测试，而这类测试通常在运行自动化测试之后进行。 这种测试形式将智能合约作为一个完全集成的产品进行评估，以验证其是否按照技术要求的规定顺利运行。
在本地区块链上测试合约
虽然在本地开发环境中进行的自动化测试可以提供有用的调试信息，但你需要了解你的智能合约在生产环境中的行为。 然而，部署到以太坊主链上会产生燃料费用，更不用说如果你的智能合约仍然存在错误，你或你的用户可能会损失真金白银。
在本地区块链（也称为开发网络）上测试合约，是主网测试之外的另一个推荐选择。 本地区块链是在你的计算机本地运行的以太坊区块链副本，模拟以太坊执行层的行为。 因此，你可以编程交易与合约进行交互，而不会产生大量开销。
在本地区块链上运行合约可以作为一种有用的手动集成测试的方式。 智能合约具有高度的可组合性，允许你与现有协议集成——但你仍需确保这类复杂的链上交互能产生正确结果。
关于开发网络的更多信息。
在测试网上测试合约
测试网络或测试网的运行方式与以太坊主网完全相同，唯一的区别在于它使用的是没有现实价值的以太币 (ETH)。 将你的合约部署在测试网上，意味着任何人都可以与它交互（例如通过去中心化应用程序的前端），而无需冒资金风险。
这种手动测试形式对于从用户角度评估应用程序的端到端流程非常有用。 在这里，测试人员还可以进行试运行，并报告与合约的业务逻辑和整体功能有关的任何问题。
在本地区块链上进行测试后，部署到测试网是理想的选择，因为测试网更接近以太坊虚拟机的行为。 因此，许多以太坊原生项目通常会在测试网上部署去中心化应用程序，以在真实环境条件下评估智能合约的运行。
关于以太坊测试网的更多信息。
测试与形式化验证
虽然测试有助于确认合约返回某些数据输入的预期结果，但它不能最终证明测试期间未使用的输入也是如此。 因此，测试智能合约不能保证“功能正确性”（即无法证明程序在_所有_输入值集合上都按要求运行）。
形式化验证是一种通过检查程序的形式模型是否与形式规范相匹配来评估软件正确性的方法。 形式模型是对程序的抽象数学表述，而形式规范则定义了程序的属性（即关于程序执行的逻辑断言）。
由于属性以数学术语编写，因此可以使用逻辑推理规则验证系统的形式（数学）模型是否满足规范。 因此，形式化验证工具被称为能够提供系统正确性的“数学证明”。
与测试不同，形式化验证可用于证明智能合约的执行在_所有_执行中都满足形式规范（即没有漏洞），而无需使用样本数据来执行。 这不仅减少了运行数十个单元测试所花费的时间，而且在发现隐藏的漏洞方面也更加有效。 话虽如此，形式化验证技术在实施难度和实用性上存在一定的变化程度。
关于智能合约形式化验证的更多信息。
测试、审计与漏洞赏金
正如前面提到的，严格的测试很少能够保证合约中没有错误；形式化验证方法可以提供更强的正确性保证，但目前使用起来困难且成本相当高昂。
尽管如此，你仍可通过进行独立的代码审查来进一步增加捕获合约漏洞的可能性。 智能合约审计 (opens in a new tab)和漏洞赏金 (opens in a new tab)是让他人分析你的合约的两种方式。
审查由具有在智能合约中发现安全漏洞和开发不良实践案例经验的审查人员进行。 审核通常包括对整个代码库进行测试（可能包括形式化验证）以及手动审查。
相反，漏洞赏金计划通常会向发现智能合约漏洞并向开发者披露的个人（通常称为白帽黑客 (opens in a new tab)）提供经济奖励。 漏洞奖励类似于审查，因为它涉及要求其他人帮助发现智能合约中的缺陷。
主要的区别在于漏洞奖励计划对更广泛的开发者/黑客社区开放，并吸引了一批具有独特技能和经验的道德黑客和独立安全专业人员。 与主要依赖可能拥有有限或狭窄专业知识的团队的智能合约审查相比，这可能是一个优势。
测试工具和库
单元测试工具
solidity-coverage (opens in a new tab) - 用于以 Solidity 编写的智能合约的代码覆盖率工具。
Waffle (opens in a new tab) - 用于高级智能合约开发和测试的框架（基于 ethers.js）。
Remix Tests (opens in a new tab) - 用于测试 Solidity 智能合约的工具。 在 Remix IDE 的“Solidity 单元测试”插件下工作，该插件用于为合约编写和运行测试用例。
OpenZeppelin Test Helpers (opens in a new tab) - 用于以太坊智能合约测试的断言库。 确保您的合约按预期运行！
Brownie 单元测试框架 (opens in a new tab) - Brownie 使用 Pytest，这是一个功能丰富的测试框架，可让你用最少的代码编写小型测试，能够很好地扩展到大型项目，并且具有高度可扩展性。
Foundry 测试 (opens in a new tab) - Foundry 提供 Forge，一个快速灵活的以太坊测试框架，能够执行简单的单元测试、燃料优化检查和合约模糊测试。
Hardhat Tests (opens in a new tab) - 基于 ethers.js、Mocha 和 Chai，用于测试智能合约的框架。
ApeWorx (opens in a new tab) - 基于 Python 的开发和测试框架，用于面向以太坊虚拟机的智能合约。
Wake (opens in a new tab) - 一个基于 Python 的框架，用于单元测试和模糊测试，具有强大的调试功能和跨链测试支持，利用 pytest和 Anvil 实现最佳用户体验和性能。
基于属性的测试工具
静态分析工具
Slither (opens in a new tab) - 一个基于 Python 的 Solidity 静态分析框架，用于发现漏洞、增强代码理解以及为智能合约编写自定义分析。
Ethlint (opens in a new tab) - 用于为 Solidity 智能合约编程语言强制执行样式和安全最佳实践的 Linter。
Cyfrin Aderyn (opens in a new tab) - 一个基于 Rust 的静态分析器，专为 Web3 智能合约的安全和开发而设计。
Wake (opens in a new tab) - 一个基于 Python 的静态分析框架，具有漏洞和代码质量检测器、用于从代码中提取有用信息的打印机以及对编写自定义子模块的支持。
Slippy (opens in a new tab) - 一个简单而强大的 Solidity linter。
动态分析工具
Echidna (opens in a new tab) - 快速的合约模糊测试器，通过基于属性的测试来检测智能合约中的漏洞。
Diligence Fuzzing (opens in a new tab) - 自动化模糊测试工具，可用于检测智能合约代码中的属性违规。
Manticore (opens in a new tab) - 用于分析 EVM 字节码的动态符号执行框架。
Mythril (opens in a new tab) - EVM 字节码评估工具，使用污点分析、混合执行分析和控制流检查来检测合约漏洞。
Diligence Scribble (opens in a new tab) - Scribble 是一种规范语言和运行时验证工具，可让你为智能合约添加属性注释，以便使用 Diligence Fuzzing或 MythX 等工具自动测试合约。
相关教程
不同测试产品的概述和比较 _
如何使用 Echidna 测试智能合约
如何使用 Manticore 查找智能合约漏洞
如何使用 Slither 查找智能合约漏洞
如何模拟 Solidity 合约以进行测试
如何使用 Foundry 在 Solidity 中运行单元测试 (opens in a new tab)
扩展阅读{#further-reading}
以太坊智能合约深度测试指南 (opens in a new tab)
如何测试以太坊智能合约 (opens in a new tab)
MolochDAO 的开发者单元测试指南 (opens in a new tab)
如何像摇滚明星一样测试智能合约 (opens in a new tab)