接口测试——将入参检查与业务逻辑分离,测试业务逻辑看成数据测试还是状态测试?
状态测试——验证程序的逻辑流程
前面将接口测试入参检查与业务逻辑分离虽然离清晰更接近了,但是第二部分测试接口业务功能是,是将其看做了数据测试,后面思路还是比较混乱。资金划拨成功或失败,这是状态,将业务逻辑看成状态测试感觉更恰当。状态测试首先要明确程序的逻辑流程,把资金当做开发,以自己的逻辑思维,结合需求说明去先画状态转换图,如果直接看开发给的实现逻辑,很容易就先入为主。
资金客户未推送到节点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失败;
这样出来的测试要点可能还是不全面,但是距离清晰又靠近一步了。所以总结如下:测试一个接口功能也要结合多种测试方法,如果将测试定位为状态测试,画出逻辑流程图,然后尽可能覆盖各个分支设计测试用例是第一步。在这个基础上,还有从逻辑流程图中挖掘,例如计算算法的验证,存在的边界值条件等。
网友评论