大家都知道，在软件开发生命周期过程中测试的地位举足轻重，它要占据这个软件开发生命周期中相当多的时间。典型的测试方法即黑盒测试和白盒测试。
　　前者也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

　　后者则是也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。

 　　是否有了黑白双煞两种手段后可以保证测试工作高效进行、应用软件又是否能够如期交付呢？我们先来看一组统计数据，如图1所示。

图1 测试发现问题后解决问题占用了更多的时间

　　事实上，软件测试的根本目的是要提高应用软件的质量，保证其未来能够可靠稳定运行。图1的数据也充分说明了，随着测试的深入，测试发现问题后的解决问题占用了更多的时间。此时黑盒白盒都显然有些力不从心了。白盒测试的代码扫描和应用功能挂不上钩，而黑盒测试的结果是测试人员把自动化功能测试发现的问题通过缺陷跟踪系统提交给开发人员处理。尽管好一点的测试人员会提供详细的测试用例文档和错误截图，但是开发人员仍不得不面临重现问题并不断的采用Trial & Error的手段来分析并解决问题。
　　很显然这种问题处理方式是手工方式且非常没有效率，会延缓问题的处理时间。因此，我们需要另辟新径。 
　　灰盒俱备，只欠工具
　　所谓灰盒测试，是介于黑盒和白盒之间的，既关注输出对于输入的正确性，同时也关注内部表现的测试方法。这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。它达到了某种目的，也是一旦发现问题，可以迅速定位到黑盒中的某个分支，甚至代码级别。灰盒测试在系统组件的协同性环境中评价应用软件的设计，从而增强了测试效率、错误发现和错误分析的效率，可以使得测试达到一个新的境界。

 
　　但是，灰盒测试对测试人员的要求也比较高，比如灰盒测试要求测试人员具有丰富的开发知识；需要测试人员更多地从业务层面去考虑问题，考虑更多的组合测试业务场景的能力；另外，很多时候问题的解决还需要很多外围知识，包括数据库层面上的分析能力、J2EE服务器内部的调用链分析等。

　　所以简单来看，灰盒测试是一个非常好的测试理念，但要真正发挥其作用，显然还需要相应的自动化工具这个东风来吹一下。　　
　　AppSight是其中一种自动化工具。
　　
　　AppSight概述

　　AppSight由来已久，原来是有Identify开发的，之后被BMC公司收购但是独立运营。

　　灰盒测试方法
　　灰盒测试中的精华是通过灰盒测试能大大缩短解决测试中发现的问题的时间。问题解决流程实际上包括了主要两个过程：“根源问题分析”和“问题解决”。而以经验来看，以前我们的时间主要是耗费在“根源问题分析”上的，一旦问题被定位，解决问题相对是非常容易的。
　　为了进行根源问题分析，通常需要3个典型步骤来进行分析：信息收集、问题重现和问题分析 
　　可惜的是，目前来看，大多数开发人员都是手工来完成这些步骤的，即这个流程是非高效的手工方式，而且易于出错