误区一：把不同层面的测试混为一谈
区块链测试首先要明确对象。以太坊开发者文档讨论合约功能与安全验证，比特币开发者指南则解释节点验证、交易规则和分叉机制。两者对应不同层面，合约函数测试通过，不能直接说明节点或应用的链上状态处理正确。
适用范围应随测试对象划定：合约关注输入、权限和状态变化；涉及区块记录的应用还需关注区块身份与状态变化。不能把一种链的具体规则直接套用到另一种链。
误区二：正常输入通过就代表功能完整
只验证成功路径，会遗漏拒绝条件和边界行为。以竞价功能为例，除了合法出价，还应考虑出价不足、截止时刻以及重复结束等场景。
测试预期需要来自业务规则。对于时间边界，应分别核对截止之前、恰好截止和截止之后；不能仅凭函数名称或文字描述推断实际行为。异常用例也应检查失败后的状态是否符合预期。
误区三：覆盖率高就等于没有漏洞
覆盖率反映代码被执行的情况，无法单独证明断言正确、输入充分或业务规则完整。一条路径被走到，与这条路径的结果被认真核验，是两件事。
例如，测试执行了退款函数，却未检查退款金额和余额变化，即使相关代码被覆盖，也可能漏掉记账错误。覆盖率适合帮助定位未测试区域，判断正确性仍需具体断言。
误区四：一种测试方式足以包办验证
单元测试适合定位独立功能的问题，集成测试关注函数组合及跨合约交互。各部分分别正常，并不保证调用顺序、共享状态和失败处理组合后仍然正确。
自动化便于重复执行，人工分析则有助于审视业务假设与遗漏场景。以太坊测试文档强调这些方式的互补性；工具报告仍需结合实际触发条件判断。
误区五：上链之后状态就无需继续核对
比特币开发者指南说明，分叉期间同一高度可能出现不同区块，因此高度不能作为全局唯一标识。涉及区块索引的应用若只测试高度递增，就可能遗漏同高度区块变化的情况。
对这类应用，测试需要区分区块高度与区块哈希，并检查相关状态变化后的业务记录。这一问题属于链上数据处理，不能由合约单元测试替代。
常见问题：可以依靠升级弥补测试不足吗
升级只能在问题被发现后尝试修复，还会引入自身的实现与验证要求。它不能消除漏洞发现前的风险。测试通过所支持的结论，应限定在已验证的环境、输入和断言之内；代码或依赖发生变化后，还需要相应的回归验证。