接口测试——将入参检查与业务逻辑分离，测试业务逻辑看成数据测试还是状态测试？
状态测试——验证程序的逻辑流程
前面将接口测试入参检查与业务逻辑分离虽然离清晰更接近了，但是第二部分测试接口业务功能是，是将其看做了数据测试，后面思路还是比较混乱。资金划拨成功或失败，这是状态，将业务逻辑看成状态测试感觉更恰当。状态测试首先要明确程序的逻辑流程，把资金当做开发，以自己的逻辑思维，结合需求说明去先画状态转换图，如果直接看开发给的实现逻辑，很容易就先入为主。
资金客户未推送到节点2；
资金可用为0，资金余额为0，可划转金额等于0，划转失败；
资金可用为-1000，资金余额为1000，可划转金额小于0，划转失败；
资金余额为1000，资金余额为1000，划出金额大于可划拨金额1000，划拨失败；
资金余额为1000，资金余额为1000，划出金额等于可划拨金额1000，划拨成功；
资金余额为1000，资金余额为1000，划出金额小于可划拨金额1000，划拨成功；
如此，整个思路就比较清晰了，但是，还是有所遗漏，那就存在最大值限制的边界值条件；可划拨金额，需要测试边界，客户博金额是允许3位小数位的浮点数，假设可划拨金额为1000，补充
划出金额取边界值下限：999.999
划出金额取边界上限：1000.001
还有一点，就是遗漏了验证算法的正确性：
资金可用900<资金余额1000，预留金额10，划出890成功；、
资金可用900<资金余额1000，预留金额10，划出900失败；
资金可用1000>资金余额900，预留金额10，划出890成功；、
资金可用1000>资金余额900，预留金额10，划出900失败；
这样出来的测试要点可能还是不全面，但是距离清晰又靠近一步了。所以总结如下：测试一个接口功能也要结合多种测试方法，如果将测试定位为状态测试，画出逻辑流程图，然后尽可能覆盖各个分支设计测试用例是第一步。在这个基础上，还有从逻辑流程图中挖掘，例如计算算法的验证，存在的边界值条件等。
