白盒测试怎么做？搞懂逻辑覆盖和判定覆盖

不少开发者以及测试人员觉得跑通了若干用例便算是完成了白盒测试。然而依据我的工作经历，这样的想法极易致使程序带着隐匿的bug上线。白盒测试的关键并非随意测试，而是要留意测试用例对程序逻辑结构覆盖了多少。

代码覆盖率的几种测试方法

存在这样一种测试，它被称作白盒测试，其最基本的要求是，要使得程序当中的每一条语句，至少都能够被执行一次。就好比图4-1里的那个小程序，只需要把A设置成2，将B设置成0，把X设置成3，便能够让每条语句都运行一遍。这样的情况听起来好像是十分简单的，然而实际上，有很多团队，甚至都无法做到这个最基本的要求。我曾经见到过不少项目，那些项目的测试报告写得是相当漂亮，可是代码里面却存在一些分支，从来都没有被执行过。

具备这种最为简单的覆盖方式被称作语句覆盖，其拥有的优点是易于达成，不过存在的不足是覆盖率不够全面，恰似一个房间，你仅仅查看了各个角落是否有人，然而却未监察房间之间的走廊以及门，真正具备很高价值的测试应该往程序的分支以及路径里面深入进去。

判定覆盖让每个判断都走两边

要求判定覆盖比语句覆盖更高一些，它要求每个判断语句均要有“真”与“假”这两种输出结果，并且每条语句至少执行一次，就拿图4-1的程序来讲，你应当让程序既走if条件成立的分支，又走if条件不成立的分支。

比如说，要是你的程序当中存在一个判断，即“当用户年龄大于18岁的时候就开展A操作，不然的话就执行B操作”，那么判定覆盖就需要你去准备两个测试用例，一个是让年龄大于18，另一个是让年龄小于等于18。好多程序员仅仅测试了正常的情况，却忽略了边界值情况，结果在上线之后才察觉到问题。

条件覆盖关注每个条件的真假

条件覆盖相较于判定覆盖更为精细，它规定要将每个判断里每个条件的全部可能结局均至少施行一回，譬如具有这样的判断语句即“IF A>1 AND B = 0”，你得使A>1以及A至于何种样态不清楚，反正得按照要求执行一遍。

于实际项目里，条件覆盖一般会发觉更多潜藏的bug。我曾对一个订单系统做过测试，判定覆盖测试全都通过了，然而条件覆盖测试却找出了一个因条件组合致使的计算差错。这种错误唯有在某一条件为真且另一条件为假之际才会被触发，平常的测试根本检测不出来。

判定条件覆盖结合两者的优点

被判定的条件覆盖将判定覆盖以及条件覆盖的要求予以合并，它要求每个判断的所有可能出现的结果都呈现出来，每个条件的所有可能出现的结果也都展示一回，并且每个入口点最少被调用一次，这种测试准则听起来貌似很完美，然而实际上存在一个问题。

执行某些条件所产生的结果会将其他条件予以屏蔽。比如说，在“与”表达式之中，倘若第一个条件已然为假，那么后面的条件根本就不会被加以计算。如此这般，后面的条件即便存在bug也无法被发现。我于测试一个金融系统之际就碰到过这种情形，一个重要的校验条件由于前面的条件为假而被略过，进而致使了数据错误。

多重条件覆盖把所有组合都测一遍

最严格的测试准则是多重条件覆盖，它要求把每个判断里所有可能的条件结果组合都至少执行一回，对于图4 - 1的程序而言，需要覆盖8种不同的条件组合，这听起来工作量不小，不过对于安全性要求高的系统来讲很有必要。

举例来说，有一个判断语句是“IF KQUEST”，哪怕仅仅存在两个条件，也极有可能需要多个测试用例才能够将所有组合覆盖周全。处于存在循环的情形之下，测试用例的数量一般远远少于路径的总数目，因而这个方法是具备可行性的。我给出建议，针对核心业务逻辑采用这样的测试方式。

如何选择适合你项目的测试覆盖标准

把哪种覆盖标准给选定下来，得看你这个项目自身所具备的特点。要是项目仅仅是一个给内部使用的小工具时，语句覆盖这种方式或许就足够了。然而要是属于金融、医疗、自动驾驶等这些领域范围之内的软件，多重条件覆盖此时会更具保障一些。按照我的经验来讲，绝大多数商业项目只要做到判定条件覆盖，便已然能够发现绝大部分的问题了。

重要考量因素包含时间成本以及人力成本。完全的白盒测试对程序中每条路径都执行到有要求，不过对于带有循环的程序而言，这样做并不切实际。我通常采用的做法是，核心模块运用多重条件覆盖，普通模块采用判定覆盖，在这样的情况下，既对质量予以了保证，又对成本进行了控制。

在进行白盒测试期间，你最为经常运用的是哪一种覆盖标准呢，有没有碰到过由于测试覆盖不够充分进而致使线上出现bug的状况，欢迎于评论区去分享你的经验以及教训，同样也别忘记给需要此内容的同事点赞并转发哦。