开篇

　　我想，作为一个软件测试人员，如果常年一直都处于黑盒和手工测试的话，必然成长速度是不会很快的；故，从黑盒向灰盒转变，也是一个对自己的职业生涯的提升，后面几篇日志我决定分享一下自己的转变过程，由于没什么人来指导自己，属于摸着石头过河过程中的中自我总结。

　　先简述一下灰盒测试的基本概念，Google一下“灰盒测试：是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，的一种测试方法”

　　为神马要用灰盒测试，主要还是因为互联网产品小步快跑，快速迭代的特性。由于强调了个“快”字，从产品需求，到开发提测，再到测试完成发布，间隔的时间会非常之短。如果只借助传统的黑盒测试，质量上不敢做保证；但是需要在极短的时间内再做白盒测试，时间上更是不允许；故这个时候就就有灰盒测试的用武之地了。

　　采用灰盒测试，对测试人员的技能要求，熟悉开发所用的语言，稍微了解框架和设计模式，熟悉白盒测试的覆盖方法（eg：逻辑覆盖，语句覆盖，条件覆盖，组合覆盖==），当然还得需要有阅读提测代码的权限。

　　完全纯理论的讲那就是浮云了。下面几篇，我再结合实例分享一下，我做灰盒测试的一些例子吧。

分解测试任务

　　做灰盒测试，最常见的的场景就是用在模块测试中，个人倾向于使用模块测试 自底向上的测试。

　　首先，拿到一个测试任务（eg：该测试任务是一个新的较独立的功能），不用说，必须了解该功能要实现神马功能，以及实现原理（在对被测对象不熟悉的情况下，可以选择跟开发沟通；如果熟悉的话，自己看svn就好了），也就是对测试任务先做一个快速的分析

　　然后，找到该功能的入口，可能需要借助类似流程图的方法，来迅速展开整个流程或者逻辑（这里推荐一款软件Code Visual to Flowchart，可以方便的生成出cpp的函数级别流程图）；从函数入口开始一路向下分解，直至最小函数单元为止。这样就大概能生成如下的一个层次：

　　从入口开始，主流程里，分别存在调用了三个分支函数，然后branch01里调用了function01；branch02里调用了function01和function02，而function02不是最小单元函数，它还调用了function03；branch03则调用了function03；故在这个例子里，最小函数单元就是function03，我们的自底而上的模块测试就从func03开始

　　总结一下这部分内容：灰盒测试最主要的一个步骤，即是分析和分解测试任务，手段不限。