虽说设计用例是每个测试人员的必备技能，但总有一些用例设计让你不知所措，来个跟钱相关的案例给你提提神吧!

提问

这个是我们已经测试过的一个活动，测试过程很痛苦，由于只知道这个规则，设计用例时虽然觉得覆盖了业务组合的所有情况，但由于不知道开发的代码逻辑，导致上线后反复出了与代码逻辑相关的两个bug，就是说我们的用例没有覆盖开发的所有逻辑分支，如果我们做了白盒测试，就可以避免了;另外流程上不规范，复杂业务没有做代码 review;而业务测试时的用例设计，这个我还是很头疼，没有理出完整的思路。

系不系感觉很晕菜?!

直接看讨论结果吧!

北京-楠叶儿

我觉得这样的需求功能测试的边界值和等价类划分几乎就可以覆盖了，除了保证单次充值每一个分支的奖励值有效外，还要设计向下包含每个层级的奖励有效等。我习惯写测试用例的时候就是小力度的划分，这样在复杂的业务也都变成点的组成了。

北京-sky

最初我也这么考虑，但测试时发现有些坑，和程序逻辑相关的，也许不属于业务测试范畴?我们后来增加了多用户购买一个标的，一个用户在一个标的中下单多次的情况。

北京-楼

有一些逻辑还是通过代码走查或者白盒测试比较能检查出来，单纯的业务测试案例可能不容易发现，比如一个标的重复下单你是肯定会测试的;奖励按等级发放你也会测试的;但是，按等级方法奖励的时候，这种奇葩的方法方式，不按人头发放，按投标次数去发放，导致重复发放这种情况，说实话，业务案例可能就会疏漏。比如程序里有一个恶意的代码逻辑：如果今天是2017年12月31日，则页面弹出一个固定的消息。这个bug，你不去检查代码逻辑，业务测试基本没戏了。

北京-sky

所以还存在流程不规范的问题

北京-楼

我反正是没想到会有这种逻辑的bug出现，所以我去设计也可能覆盖不到，因为完全不符合逻辑，用例的设计也是根据逻辑去设计，而不是随机覆盖一些奇葩逻辑。那只能期待随机测试区发现，或者通过大量数据去发现

北京-楠叶儿@北京-楼

我还是觉得不管白盒测试还是黑盒测试都是测试方法，您说的这种情况，如果黑盒测试用例没有考虑到的话，这个测试用例编写人用白盒我觉得也是很难想到相关的反例，不过还是和楼管家学习到了，我第一反应确实没考虑那么细，谢谢啦!

北京-楼

此类奇葩逻辑 代码走查效果显著

我个人觉得测试还是以业务为主，只不过懂代码逻辑的话，相对来说想到的测试用例覆盖率更高一些，您说的这些情况测试用例设计者不管是白盒还是黑盒我们都要考虑，就是我一下没想那么多。

感觉还是挺复杂的!

大神建议：

这个案例看起来就是典型的边界值的问题，复杂点可能在取“累计充值和投标的最小值”这个隐藏规则：

第一个情况是：比如我可能只充值了5000块，投标了5000，这5000到期后，会有利息产生，比如利息100快，这5100本息我再去投标5100，这样累计充值还是5000，累计投标是10100，这样就不满足累计充值并投标10000这个档位的要求了。

第二个情况是：再就是充值了10000块，但是只投标了5000块，剩下5000块闲着，这个也拿不到10000档位的奖励;

第三个情况是：充值了10000，再投标的情况下赎回了5000(有的平台可能限制赎回)，然后剩余的5000，反复投标2次，能达到累计投标10000，此类情况是否认定为累计充值了10000还是认定为累计充值了5000.这个是需求层面需要明确的规则。

总结：

1、对于功能测试而言根据业务需求设计出来的测试用例就算是我们遍历了所用的情况，只是说明我们覆盖了业务层面的所有情况，并不代理我们遍历了所有的代码逻辑情况

2、这种复杂的业务一个可以按设计好的测试用例去测试，还应该多测试异常的情况，在线上充值各种奇葩的情况都可能会遇到，就算是我们测试用例写的再全面，毕竟是几个人想到的情况，还有很多异常情况可能是我们想不到的

3、做好交互测试，一个功能尤其是比较复杂的功能，最好是由两个人或者更多的人去测试，尽量不要一个人去测试，一个人的思路是比较有局限性的，测试本来就是一个集思广益的工作

4、业务逻辑复杂的功能在代码层面开发或者测试应该做一下白盒测试，排除代码中的一些不合理或者错误的逻辑，从代码层面和功能层面两个方面测试。

希望当你遇到此类问题时今天的文章可以帮到你哦!