今天面试之余，我静下心来，仔细想想，做针对业务的测试可不容易了，尤其对外面一个软件公司，认识到软件测试重要性已经很不错了，能够组建测试团队实施测试的也就更好了。这种测试肯定就是黑盒测试了，主要对系统做产品的功能测试为主，如果有条件就做性能测试。这种测试对于需求规格说明书写得不详细，设计也不详细的公司，也只能这样做测试了，但是作为测试经理或测试工程师，你可能觉得很难实施测试，因为好像无从下手，怎么实施测试呢？这种测试不是以规格说明书为依据吗？说明书不详细，或者说没有多大的参考价值，怎么去做依据呢？如何覆盖功能点呢？

　　其实我在想，把白盒测试和黑盒测试两者结合的灰盒测试，就在这种情况下发挥作用了，而我想灰盒测试追求软件质量，又不能投入大量资源做白盒测试的公司的一种理想选择，且能做到让你的软件做到功能上的需求覆盖和代码级上的覆盖，我想这应该是软件测试今后发展的一个趋向。

　　灰盒测试，确实是介于黑盒测试和白盒测试两者之间的，可以这样理解。灰盒测试不但关注输出对于输入的正确性，而且同时也关注程序结构内部表现。但这种关注并不像白盒测试那样详细、完整，而只是通过一些表征性的现象、事件和标志等来判断内部的运行状态。有时候输出是正确的，但内部其实已经错误了，这种情况非常多。如果每次都通过白盒测试来测试，则效率会很低，因此可以采取灰盒的测试方法。

　　灰盒测试结合了白盒测试和盒黑盒测试的要素，它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

　　灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

　　灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

　　灰盒测试借助测试工具可以同时考核两种测试通过准则，一是基于需求的覆盖率准则；二是基于代码的覆盖率准则。能够给出这两种指标，并进行分析和审查，则可以比较充分地考核测试的完整程度。

　　如何来实施灰盒测试呢？其实我们常说的单元测试，基本上算是灰盒测试了，我说的单元测试，首先就是注重代码覆盖，同时注重功能点覆盖的单元测试。灰盒测试的核心思想：针对软件外在的表现设计测试用例，运行被测试程序，在运行时同时统计代码中的覆盖率，根据覆盖情况，反过来再去补充新的测试用例，直到把所有的功能点都覆盖了，这样代码的覆盖率肯定已经接近100%了，如果还没有到100%，那就要分析为什么有些语句或分支没有被执行呢？再去设计测试用例，覆盖这些语句和分支，这样让你的测试做得更充分。但是很多情况下，有些异常处理或例外语句，不好在外部设计测试用例，让这些异常被处理。例如：申请内存的malloc或new语句，有可能失败，但是在我们的计算机中，很难分配失败，这时，就可以借助模拟内存失败的工具xenu等来模拟了。当然，也可以在进入这些语句前，添加一些处理，让程序执行到这里时，发生异常，看程序遇到这种异常如何执行的，是否符合遇到这种异常的正确处理方式。

　　现在有很多的工具，可以做这种灰盒测试，例如logisope、Rational的PureCoverage工具等是针对c和C++语言软件的，还有专门针对Java语言的等。读者如果为测试经理，不妨自己去试试，这种测试让你同时做到两种覆盖，同时互为补充，注意统计的语句或分支覆盖率是逻辑统计的，也就是多个测试用例执行到某些相同的语句，有些工具工具可以统计执行的语句次数，这样也能分析看那些语句是影响程序性能的语句，因为他们总是被执行到。

　　现在软件测试在发展之中，很多概念和术语都不太统一，每个测试人员对软件测试的认识都可能不同，因为这些主要来自于经验，而很少来自于教材。但是灰盒测试应该被有能力的测试人员关注，这样能够在有限的资源下，取得最好的效益。

　　文章上的观点纯属一家之言，如果你有不同意见，请欢迎留言讨论。