摸着石头过河——从黑盒到灰盒004篇（对最小单元函数做灰盒测试）

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

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

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

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

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

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

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

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

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