做单元测试的时候，TESSY里的MC/DC覆盖率该怎样去统计，那些没被覆盖到的空洞又要怎么补上，这是围绕着结构覆盖来展开的。TESSY这个工具是支持代码覆盖率分析的，覆盖率一般说的就是那些已经被测试执行到的代码项在全部代码项里占的比例，而MC/DC比起普通的语句覆盖和分支覆盖来，要求还要更细一些，它不光要求条件被跑到过，还得去证明每一个条件都能单独地去影响整个判定的结果。所以我们在TESSY里面去看MC/DC的时候，不能光去盯那个百分比是不是到了100%，还得去瞧一瞧有哪些判定没有被覆盖到，又有哪些条件没有表现出它的独立影响。

　　一、TESSY MC/DC覆盖率怎么统计

　　在TESSY里统计MC/DC覆盖率，一般是在单元测试跑完之后，通过覆盖率报告来查看结果的，这里头不能只盯着总的覆盖率数字，因为一个函数总覆盖率看着可能还不低，可里面某个复杂的if判断照样可能还没有满足MC/DC的要求。

　　1、先确认覆盖率类型是否选对

　　在【Coverage设置】中确认当前测试对象启用了MC/DC覆盖统计，而不是只统计语句覆盖或分支覆盖。

　　有些项目在测试跑完之后，一看覆盖率好像挺高的，可仔细一瞧，其实只做了语句覆盖或者分支覆盖，并没有真正去统计MC/DC。MC/DC这东西，它关注的是条件和判定之间的关系，就比如A&&B这种表达式，不只是要求A和B都拿到过true和false的值，还要去验证A或者B单独变化的时候，能不能把整个判定的结果给改掉。

　　2、执行测试用例后查看覆盖率报告

　　通过【Coverage Report】、【Summary Report】和【Detailed Coverage】查看函数、判定和条件层面的覆盖情况。

　　从总表里通常只能看到一个整体的百分比，但详细报告会更加有用。比方说某个函数显示MC/DC还没有满，那就得继续去打开具体的判定，看一看究竟是哪一个if、哪一个while，还是哪个条件表达式没有覆盖完整。光盯着一个总百分比，是很容易误以为问题已经解决掉的。

　　3、重点看复杂判定表达式

　　MC/DC覆盖率最容易卡住的地方，往往就是那些复合条件，比如说好几个&&、||搅在一起，还有取反条件，或者边界比较组合在一起的那种判断。简单的语句一般都比较容易覆盖到，真正让人头疼的，是条件之间互相影响，或者因为短路逻辑，搞得后面的条件根本没有机会被执行到。碰到这种情况，不能光靠着增加一些随机的测试数据，而是要去看每一个条件到底有没有单独地改变过判定的结果。

　　4、不要忽略桩函数返回值

　　假如被测函数是要靠着外部函数、传感器的输入，或者是接口的状态来过日子的，那桩函数的返回值就会直接牵动MC/DC的统计结果。桩函数要是老半天都只返回一个固定的值，那么某些条件就永远不会发生变化，覆盖的空洞自然也就一直搁在那儿了。所以在TESSY测试里头，一定得去检查桩函数有没有给出各种不同的返回组合，特别是错误返回、超时状态、边界值，还有正常值之间的来回切换。

　　二、TESSY MC/DC覆盖空洞怎么补

　　MC/DC覆盖空洞的修补，通常不是简单多加几个测试用例就能完事的。更稳妥的做法是先搞清楚空洞是从哪里冒出来的，然后再决定是去补测试数据、调整桩函数，还是对代码不可达的情况做出说明，因为空洞的成因不一样，处理的路数也不相同。

　　1、先定位没有覆盖的判定

　　对照【Detailed Coverage】中未覆盖的decision、condition和MC/DC pair，找到具体代码位置。

　　比方说报告里头显示某个if判断没有满足MC/DC，那就要回到代码里面去，看一看这个判断是由哪些条件搭起来的。到底是A没有取过false，还是B的取值虽然变了但判定的结果却没有跟着动，又或者是某个条件因为短路压根儿就没有被轮到。只有定位到了这一层，后面去补用例的时候才不会胡乱去试。

　　2、用成对用例证明条件独立影响

　　补MC/DC的时候，经常用到的一个方法，就是让其中一个条件发生变化，而其他的相关条件都按住不动，然后再去瞧一瞧整个判定的结果是不是跟着变了。拿判断条件A&&B来说吧，要证明A的独立影响，就得准备那种A变了、B一直保持为true的用例；要证明B的独立影响呢，就得准备B变了、A一直保持为true的用例。照这样补出来的用例，比那种单纯去凑true和false的，要管用得多。

　　3、调整输入数据和桩函数组合

　　通过【Test Data】和【Stub Return】设置不同输入值、边界值和外部函数返回值，补齐没有触发到的条件组合。

　　就比方说，某个条件是靠着传感器状态的，另一个条件又是指望着诊断函数的返回值，这时候就不能光去改函数的输入参数，还得让桩函数也返回不同的状态才行。那些常见的组合，就包括了正常值、边界值、无效值、超时、错误码、空指针保护这些。覆盖空洞很多时候并不是代码没被跑到，而是测试数据压根儿没把条件给“推到”另一边去。

　　4、短路逻辑要单独检查

　　&&和||这些操作符是会带来短路执行的问题的，前一个条件要是已经把结果给定了，后一个条件可能就没有机会再被执行了。就比如A||B里头，如果A一直铁铁地是true，那B根本就捞不着机会去影响整个判定的结果。补这种空洞的时候，就得先把A拨到false那一头去，好让B也有机会参与到判定里头来。这个地方是特别容易被漏掉的，因为分支覆盖说不定已经过了，可MC/DC这一关却还没过去。

　　5、不可达代码不能硬补

　　还有一些覆盖空洞，它是从防御性代码、编译开关、平台差异，或者理论上就跑不到的分支那边来的。碰见这类情况，不太适合为了硬凑一个100%的覆盖率，去强行捏一些不真实的输入出来。更靠谱的做法，是去确认一下这段代码为什么不可达，它是不是一段有效的防御逻辑，还有没有必要保留下来，然后把原因好好地整理到覆盖率的说明里面去。要不然的话，测试数据看上去好像是补上了，实际上反倒脱离了真实运行的条件。

　　三、TESSY MC/DC覆盖结果怎么整理

　　MC/DC覆盖统计完之后，还得把结果整理成能够追溯的证据。覆盖率数字只是结果的一个方面，更要紧的是能讲明白哪些用例覆盖了哪些判定，哪些空洞已经被补齐了，又有哪些空洞是经过分析之后可以接受的。

　　1、保留覆盖率报告和测试用例版本

　　将【Coverage Report】、【Test Case列表】和【测试执行记录】放在同一版本下保存。

　　覆盖率报告，一定得能对应到具体的代码版本和测试用例版本上头去。代码一旦变了，覆盖率的结果自然也会跟着变；测试用例要是改了，报告也得重新再生成一份。要是只留着一张最终的截图摆在那里，后面再去想说明这份覆盖率到底是对应着哪一版代码的，可就非常费劲了。

　　2、覆盖空洞要有处理记录

　　对每个还没被覆盖到的项，都需要讲明白它到底是通过新增用例给补齐了，还是经过分析以后，认为它就是不可达或者不适用。新增用例的时候，要能瞧得见输入的数据、桩函数的设置，还有预期的结果；而对于不可达的项呢，就要把原因给说清楚。就比如编译宏没有打开、防御性的分支没办法通过正常的接口去触发它，又或者某一段代码只适用于别的平台，这都得记录下来。

　　3、覆盖率不能代替需求验证

　　MC/DC覆盖率这东西，它能说明代码的结构被测试到了什么样的程度，但并不能直接就证明软件的需求已经全部被正确地实现了。一个测试用例，它也许覆盖到了条件的组合，可不一定就验到了需求真正期望的那个点。在整理证据的时候，还应该把需求、测试用例和覆盖率的结果搁在一块儿去打量，不能光是拿覆盖率一个数字，就来证明测试已经做得够充分了。

　　总结

　　TESSY里面MC/DC覆盖率到底该怎么去统计，碰上覆盖空洞又该怎么去补上，最要紧的一点，就是别只盯着最后那个百分比看。在统计的时候，要先确认MC/DC覆盖这个类型已经打开了，然后再从详细的报告里边，把那些没覆盖到的判定和条件给找出来；补空洞的时候呢，要围着条件的独立影响去设计用例，同时也要去查一查输入数据、桩函数的返回值，还有短路逻辑这些地方。对于那些确实就是跑不到的代码，也得把分析的说明留下来。照这样整理出来的MC/DC结果，才更适合拿去做单元测试证据的留存。