功能验证应覆盖哪些层面
区块链功能验证通常分为交易层、区块层和状态层。交易层关注请求是否具备有效签名、正确的发送方和接收方、合法的交易序号或输入、合理的手续费参数，以及是否能被网络接受。区块层关注交易是否被纳入有效区块、区块是否符合共识规则，以及不同节点是否能够对相同链上记录达成一致。状态层则检查交易执行后账户余额、未花费输出或智能合约存储是否按预期变化。
不同链的验证模型并不完全相同。以太坊交易通常包含发送地址、接收地址、签名、nonce、价值、输入数据和燃料参数，交易可能用于转账、部署合约或调用合约。比特币则以未花费交易输出作为后续交易的输入，验证重点包括输入是否来自有效的UTXO、输出总额是否超过输入总额，以及同一输出是否被重复花费。因此，测试用例不能只验证一个通用的“交易成功”字段。
签名与身份校验问题
签名校验失败是常见问题之一。交易必须由相应账户授权，签名应当能够证明交易确实由对应私钥产生，并且交易内容在签名后没有被篡改。测试时应覆盖错误私钥、被修改的接收地址、金额或输入数据、格式不完整的签名，以及签名与发送账户不匹配等情况。
还要区分“地址格式正确”和“账户确实有权执行操作”。地址经过格式校验，并不代表账户拥有足够余额，也不代表它有权调用某个合约方法。对于合约调用，还应验证调用数据中的函数选择器、参数编码和参数类型是否与接口约定一致，避免只检查交易是否进入待处理队列。
状态、重复提交与顺序问题
以太坊使用nonce表示账户交易的顺序。nonce错误可能导致交易被拒绝、等待前序交易，或与已有交易产生冲突。功能验证应覆盖重复使用nonce、跳过nonce、并发提交多个交易，以及同一账户交易先后顺序发生变化等场景。仅凭客户端返回了交易哈希，不能判定状态已经完成。
比特币的核心检查对象是UTXO。一个输出只能作为输入使用一次，重复引用同一输出属于双重花费，节点应拒绝无效交易。测试时需要验证输入不存在、输入已经花费、输入金额不足以覆盖输出和手续费，以及输出金额大于输入金额等情况。多输入、多输出和找零逻辑也应分别验证，不能只用单输入单输出案例代表全部行为。
合约调用与输入数据问题
智能合约交易的输入数据通常是编码后的字节串，前部可能表示要调用的函数，后部包含按照ABI编码的参数。常见问题包括函数选择器错误、地址或整数的编码长度不符合约定、参数顺序错误、数值单位转换错误，以及把普通转账误当成合约调用。验证结果应同时检查交易是否被接受和合约状态是否发生正确变化。
还应区分会改变状态的交易与只读取状态的调用。以太坊中，view或pure函数可以通过只读调用查询，通常不需要提交改变链上状态的交易；但如果同类逻辑在合约内部被调用，可能仍属于执行过程的一部分并消耗燃料。因此，测试不能仅依据函数名称判断是否产生费用或状态变化。
手续费、资源限制与失败处理
以太坊交易需要为计算资源支付费用，gasLimit限制交易最多可消耗的燃料，费用参数影响交易被处理的条件。常见验证问题包括gasLimit不足、费用参数格式错误、账户余额不足以支付转账金额和手续费，以及交易执行失败后对状态变化的判断不准确。测试应明确区分“交易未被接受”“交易已入块但执行失败”和“交易成功但结果未达到业务预期”。
比特币交易中，输入总额与输出总额之间的差额可作为手续费。验证时要检查手续费计算、找零输出以及边界金额处理。对于任一网络，都应避免把手续费估算值当成最终执行结果，也不能只根据前端提示判断费用是否已实际扣除。
区块确认与分叉误判
交易进入交易池、被节点接收、被纳入区块和达到更高确认程度，是不同阶段。以太坊资料所描述的生命周期中，交易先广播并进入待处理池，随后由验证者纳入区块，区块还可能经历更高程度的确认。测试应分别记录这些状态，避免把“已广播”或“已获得交易哈希”直接标记为最终成功。
比特币节点会依据共识规则验证区块，并可能因多个区块几乎同时产生而出现暂时性分叉。短期位于某个分支上的交易或区块，后续可能不再属于最终采用的链。因此，涉及到账本最终状态的功能验证，应检查区块哈希、交易所在区块及确认数量，不能只使用区块高度作为唯一标识。
一套实用的排查顺序
出现验证失败时，可以先确认请求格式和编码，再检查签名与授权关系，接着核对账户余额、nonce或UTXO状态，然后检查手续费和资源限制，最后确认交易是否进入有效区块以及链上状态是否符合预期。若是合约交互，还应对照接口定义解码输入数据和事件或状态结果。
测试报告最好同时保留原始交易标识、关键字段、节点返回状态、所在区块信息和最终状态变化。这样可以区分客户端显示问题、节点接收问题、共识校验问题与合约执行问题。适用范围也应写清楚：以太坊测试重点偏向账户、nonce、gas和合约调用，比特币测试重点偏向UTXO、双重花费、交易费和区块链分叉；不能把一条链的验证结论直接套用于另一条链。