灰盒测试
按照测试技术来划分软件测试，可以分为白盒测试、黑盒测试，这常见的一种分法。当然也可以分为静态测试（静态分析技术）和动态测试。而我想引入的是灰盒测试，虽然在有些资料上已经引入了灰盒测试的概念，但是关于该测试如何实施、针对于特定的项目，如何来设计测试用例呢？好，我们先来看看白盒测试和黑盒测试的概念。 白盒测试（White-box test，有时被翻译为“白箱测试”，又称“结构测试”）： 通过对程序内部结构的分析，检测来发现问题。白盒测试是基于程序的内部逻辑结构的测试，所以也被称为“结构测试”。这种测试首先是拿到程序的源代码，对源代码中的控制结构、处理过程等进行分析，检查程序内部处理是否正确、包括异常处理、语句结构、分支、循环结构等。很多控制软件，还要考虑有无冗余的代码，因为程序“跑飞”，可能进入这些代码而无法再进行正常的执行。 黑盒测试(Black-box test，有时被翻译为“黑箱测试”)，原来曾经把黑盒测试也称为功能测试，现在来看，这种说法已经过时了，因为黑盒测试包括了功能测试，还有其它的测试，例如，性能测试等。 黑盒测试是通过软件的外部表现来发现其缺陷和错误。在测试时，不用关心源代码，也是不用关心程序内部的结构和处理过程，而是根据软件提供我们的用户接口来进行测试，往往是设计输入和采集输出结果，来检查程序是否按照需求的要求来完成处理。 而如果给灰盒测试下一个定义呢？ 灰盒测试是基于程序运行时刻的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。 执行灰盒测试有什么好处呢？ 1、能够进行基于需求的覆盖测试和基于程序路径覆盖的测试； 2、测试结果可以对应到程序内部路径，便于bug的定位、分析和解决； 3、能够保证设计的黑盒测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合； 4、能够需求或设计不详细或不完整对测试造成的影响。 那么进行灰盒测试有什么缺点呢？ 1、投入的时间比黑盒测试大概多20-40％的时间； 2、对测试人员的技术要求更高； 那么什么样的项目适合做灰盒测试呢？ 这适合于大多数项目，但是这需要根据项目的重要性来决定。对于重要的项目、尤其是涉及到生命或重大财产安全的项目适合使用这种测试方法。但是，任何项目都会从灰盒测试中获益。 做灰盒测试需要哪些条件呢？ 1、需要在测试中，除了部署产品之外，还有是程序源代码，不管外部是多少漂亮界面或易用的功能，终都是由源代码来实现的。所以在部署时，要安装源代码。从源代码编译生成的目录中运行软件。 2、需要代码覆盖率工具的配置；部署可以针对本软件开发语言的代码覆盖率工具； 3、测试人员要具备阅读代码的能力，其对开发语言的熟悉程度和程序设计经验多少决定了采用灰盒测试能够取得多大的好处，所以配置这方面的测试人员或进行必要的培训是必要的。 那么有人可能问，服务器端软件适合做灰盒测试吗？回答是肯定的。任何一个项目都可以从灰盒测试中获得裨益。不管是手机中使用的各种嵌入式软件、还是web页面和服务器端的任何脚本，都可以运用这种测试方法。 那么设计灰盒测试用例与黑盒测试用例到底有没有区别呢？本质上没有区别，但是做灰盒测试设计用例的粒度可能要超出黑盒测试。因为这种测试用例，主要是覆盖需求功能点，每个功能点可能细分为多种情况，这种情况如果不结合程序代码，可能想不到。需求功能点之间的组合情况在黑盒测试是难于实现的，但是通过代码中的各种路径，可以分析出，是否一种组合或几种组合能把其它的情况覆盖了，因为其执行的都是同一段代码，可能只能给变量的值不同，这在很大程度上又提高了测试的效率。
