灰盒测试技术

2024-04-08 06:38

文章标签 技术测试灰盒

本文主要是介绍灰盒测试技术，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

很想写灰盒测试技术了。

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

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

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

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

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

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