对最小单元函数做灰盒测试

　　接着上回继续“最小单元函数做简单路径覆盖，是远远不够的”

　　为神马呢，路径覆盖，也只能验证各种不同的条件组合，执行到的各个分支路径的代码是否都是有效的；此时可以分成三种不同的思路来继续测试：

　　一、静态白盒测试

　　静态白盒测试的概念我就不解释了（可以自己google下），也可以理解成是按照先前完成的路径覆盖，去对做基本代码审查。eg：是否有引用的变量未赋值，打开句柄未释放，条件判断语句是否写错，数组的引用是否超出规定的界限之外等等。

　　ps：做这个测试初期不能指望能一次性发现全部BUG，不过在通过其他手段发现BUG之后，不妨都基于代码层review下，看看BUG究竟是怎么出现的，日积月累后必然会大幅提升你的代码审查能力，运用静态白盒测试，也可以发现更多以前没法发现的BUG（后面的日志会找些平时碰到的实例来分享给大家）

————————————————————————分割——————————————————————————

　　二、函数级别的黑盒

　　这个部分其实就相当于把 待测试的函数作为测试对象，input参数就是testcase中的“测试步骤”；而函数的返回值，则是testcase中的“实际结果”；而我们需要做的，也就是，通过黑盒的手段来制造input参数，并通过返回值来观察或者现象来判定当前的实际结果，是否与预期结果一致。

　　ps：这个需要对待测函数的功能完全了解，才可以展开；使用该测试的好处是，可以发现静态白盒测试和路径覆盖未能发现的问题

————————————————————————分割——————————————————————————

　　三、参照需求检查逻辑（静态黑盒）

　　这个部分其实无须单独提出来，其实在执行静态白盒和函数级别的黑盒时，都可以顺带着完成了；但是很多问题，如果单纯的只跟着代码逻辑和开发的思路走，是很难暴露出来的，且需求也有可能出现纰漏。

　　光写概念上的东西，没亲身执行过的话，我也会觉得很生涩，下面的日志就开始结合一些实例来扩宽下。

继续模块测试

　　虽然我也不太喜欢一直写理论和概念，还是先把模块测试的流程写完吧，然后再做实例分享。

　　当我们完成了最小单元函数的灰盒测试之后，即完成了下图的func03的测试：

　　我们将秉承 自底向上的 模块测试流程，向上一层，把func03视为可信，对func02 和 func01做相同的测试步骤；再完成后，继续向上一层，去测试branchxx；依次类推，逐渐向上，直到完成整个main函数的测试为止，那么我们的模块测试才算是完成了。