适用范围与判断依据
区块链编程涉及不同技术体系，以下聚焦以太坊智能合约的测试与访问控制。Ethereum 开发者测试文档强调部署前验证及多种测试方法的配合；OpenZeppelin Contracts 权限文档解释所有者、业务角色与角色管理员的区别。这些机制解决的问题不同，需要结合合约业务规则理解。
误区一：先部署，发现问题再升级
合约部署后的代码修改受到限制，可升级设计也增加实现复杂度。修复依赖问题先被发现，无法保证赶在漏洞被利用之前完成。
因此，升级能力不能代替部署前验证。设计时需要先明确哪些状态变化是允许的、哪些操作必须拒绝，再用测试检查这些规则，而不是把能够升级当作放宽检查的理由。
误区二：正常流程通过就代表逻辑正确
正常输入只能验证部分行为。以竞价流程为例，除了检查有效报价，还需要考虑报价不足、截止时间边界以及重复结束等情况。边界是否包含等号，应由业务规则明确，并与实现一致。
测试预期也可能写错。如果测试直接复述代码中的判断条件，代码与测试可能同时偏离需求。更有效的思路是先用文字写出规则，再分别检查实现和测试是否符合规则。
误区三：覆盖率高或工具通过就等于安全
覆盖率记录代码被执行的情况，不能证明断言充分，也不能证明所有输入组合都正确。某条路径即使运行过，测试仍可能漏查余额或权限变化。
单元测试适合检查局部功能，集成测试关注函数及合约之间的配合。自动化检查便于重复执行，人工审查则能补充对业务含义和边界的判断；这些方法相互补充，均不能单独保证没有漏洞。
误区四：添加管理员就完成权限设计
单一管理主体可以采用所有者模式；操作职责不同的系统可以使用角色划分。权限设计还应区分执行操作与授予权限：拥有某个业务角色，并不默认意味着能够把该角色授予他人。
检查权限时，可以分别提出两个问题：谁能执行这个操作，谁能改变执行者名单？前者正确而后者过宽，仍可能使权限限制失去作用。
常见问题：使用成熟组件后还要检查什么
成熟组件提供通用机制，具体配置仍需验证。例如，初始所有者是否正确、角色是否分配完整、撤销权限后原账户是否确实无法操作。
权限退出也有功能后果：放弃所有权会使受 onlyOwner 保护的操作无法再被调用；两步所有权转移要求接收方确认。选择机制时，应结合后续管理需求检查交接与退出流程，不能仅凭组件名称判断设计已经完整。