数字货币范围测试总做不全？这几类边界场景该补上

数字货币范围测试总做不全？这几类边界场景该补上

数字货币系统上线前，我见过最多返工就是因为范围测试没做透。今天把实操中踩过的坑和必须覆盖的边界场景捋一遍，希望对正在做CBDC或链上支付项目测试的同行有用。

转账金额是最显而易见的测试点数字货币范围测试总做不全？这几类边界场景该补上，但大家容易只测最小值和最大值。实际项目中，精度截断是个高频翻车点——比如链上代币小数位是18位，前端输入框限制了6位，中间那12位谁来兜底？我一般会把金额边界拆成四档：零值、最小可转额、超出单笔限额、溢出uint256。每一档都要跑通正常路径和异常路径。

双花攻击的边界复现是数字货币测试里最恶心的部分。不是简单的两个请求同时发，而是网络延迟、节点分叉、区块回滚这些组合场景。我习惯用混沌工程工具把网络延迟拉到500ms数字货币范围测试，同时模拟两个节点对同一笔交易产生不同确认结果，验证系统能不能在最终一致性窗口内正确回滚或确认。

很多团队测完功能就交差，AML/KYC的风控阈值根本没进测试范围。比如单笔5万触发人工审核，那49999.99元连续拆成5笔各9999.99，系统能不能识别？这类"合法范围内踩线"的场景，必须和风控规则引擎的同学一起设计用例，不能开发自己猜。

你们项目里，范围测试和风控测试是同一个团队做还是分开做的？