适用范围：聚焦智能合约
区块链测试涉及不同层次，本文讨论以太坊智能合约的功能与权限验证，不涵盖共识机制或节点网络性能。Ethereum开发者测试文档强调组合使用测试方法；OpenZeppelin访问控制文档说明所有权与角色管理机制。两者分别为理解测试边界和权限场景提供基础。
误区一：用例通过就代表安全
测试通过只能说明已执行的场景满足所写断言。若断言遗漏业务限制，即使全部通过，也无法说明这些限制得到落实。
例如，竞价功能不能只检查有效报价是否成功，还应验证报价不足、截止时间前后和重复结束等情形。时间恰好等于截止值时，也应按照业务规则单独检查，避免边界条件遗漏。
误区二：覆盖率高就等于验证充分
覆盖率反映代码被执行的情况，不能单独衡量判断结果是否正确。同一条语句被执行，并不意味着不同身份、输入和状态组合都得到验证。
检查状态更新时，应同时考虑返回结果和相关存储变化。覆盖率适合用于寻找未触达的路径，测试质量还取决于断言是否准确表达业务要求。
误区三：单元测试可以代替集成测试
单元测试适合定位独立函数的问题；涉及多函数协作或跨合约调用时，还需要集成测试。各个组件单独正常，不能直接推出完整流程正常。
例如，竞价与退款分别通过测试后，仍应检查连续报价、退款及结束操作之间的状态衔接。测试场景应沿实际业务流程展开，观察前一步是否改变后一步的执行条件。
误区四：使用权限组件就无需测试权限
权限组件仍依赖正确配置。角色持有者与角色管理员是不同概念，拥有操作权限不必然意味着能够授予该权限。
权限测试应覆盖普通账户、授权账户及撤权后的账户。所有权转移还应验证旧所有者失权、新所有者生效；使用两步转移机制时，需要检查接受前后的权限状态。放弃所有权后，受所有者限制的功能可能无法再调用，也应核对是否符合设计。
误区五：自动化或后续升级能解决一切
自动化适合反复执行回归测试，人工检查有助于发现业务假设和边界场景中的遗漏。工具报告需要结合上下文判断，单一方法无法提供完整保证。
升级也不能替代部署前验证：漏洞可能先被利用，升级过程本身也可能引入错误。实践中可先明确业务规则，再用单元测试检查局部逻辑、集成测试检查流程，并在修改后重复验证相关场景。