模块测试框架1-何为模块级测试？

传统意义上的模块测试称之为“Unit Test”，也就是单元级测试。

单元测试一般是针对软件设计的最小单位来进行测试，检验的代码的正确性，而这个“最小单位”的划分标准不是很明确，小的可以是函数，数十行到上百行；大的可以到模块级，规模上万行。当然，对于不同规模、不同类型的软件，测试要求也不一样。

对于对外提供功能型的模块来说，这个模块有多个独立的功能或者算法函数组成，功能算法之间耦合度非常低，这个时候我们希望针对每个功能、算法进行独立的函数级测试。此时我们希望的是函数的每个分支，每种条件都能得到完整的覆盖，也就是对代码覆盖率、分支覆盖率有一定的要求，这种是典型的白盒测试。

对于典型的消息驱动模块级来说，模块更像是一个黑盒，内部如何构成我们大可不必关心，我们关心的是模块对外呈现的消息，给定一个消息，然后模块输出一个消息，也就是对用户来说，用户看到的是消息。这个时候的测试，我们更希望从用户角度出发，对模块的边界进行测试，也就是模块对外呈现的消息进行测试，这种测试就是黑盒测试。

有人可能会问了，对于消息驱动的模块，我们也可以一样使用函数级单元测试啊？其实这个不是不行，只是不建议这么操作，为什么呢？

一般的情况下，这种消息驱动一般都是以一个模块整体发布，有时候会以Lib的方式发布，模块内部可能包含的成百上千的函数，试想一下，即使你保证了所有函数的正确性，你能保证这些函数组装起来后就没有问题吗？再换一个角度，当模块开发一段时间后，会产生很多的代码冗余，此时我们需要对模块内部的重构，此时对外的接口不变，如果我们使用函数级测试，那问题就会非常大，重构的过程也是用例重新编写的过程，那那什么来保证重构后的代码是安全的？

当然，从外部消息驱动进行测试也会有弊端，比如一些异常的场景、流程可能永远走不进去，带来的结果就是代码覆盖率上不去，对外呈现的数据不好看（这种代码是否真的有存在的必要性？当然这个是另外一个课题了）。一般情况下我们认为纯粹了流程级测试，如果覆盖率能够达到90%以上，问题就不大了，如果说你是个完美主义者，剩下的10%可以通过函数级测试来满足:-)

    再考虑一个问题，如果我的覆盖率达到90%了，是不是保证没问题了呢？答案是否定的，带覆盖了90%不等同于场景覆盖了90%，所以剩下的就是考验你写用例的水平了。

    --待续--

(本文章发表于psbec的个人blog，未经本人许可，不得用于商业用途。任何个人、媒体、其他网站不得私自抄袭；网络媒体转载请注明出处，增加原文链接，如有任何问题，请留言或者发邮件给[e-mail])