今天突然想了解一下灰盒测试,于是去发掘了一些文章汇总了一下
“灰盒测试，确实是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。”
灰盒测试我的理解，灰盒测试是运用工具及开发知识，寻找软件黑盒的测试点。 灰盒测试属于黑盒测试的一部分，也是对一个黑箱子进行测试，只是灰盒测试点增加黑盒测试路径，也是黑盒测试人员的更高的境界。
灰盒测试是要运用一些开发知识的，大家都认为要去学习开发知识。网上很多论坛也有人说做测试之前，最好要有一、二年的开发经验就比较好。做为黑盒测试人员，如果会当然好，但是大部分黑盒测试人员是没有开发经验，这里我谈谈黑盒测试人员学习什么，怎么去学习。
1、多看、多分析、多总结缺陷
测试人员应该多去看别人的发现的缺陷，特别是一个模块后，你测试完成后，别人再测试，心里一定要多问他为什么可以发现这些缺陷，你没有发现。多分析缺陷发生的原因，是由于开发人员业务不是很了解，还是在设计的问题，还是开发人员态度的问题。可以分类汇总发现的缺陷，也可以总结开发人员常犯的缺陷。
2、和开发做朋友，充分交流。
当发现一个缺陷时，我们应该了解缺陷发现的原因及一些原理。这些缺陷发现的原因只有开发人员很清楚，需要他跟你讲解。只有多和开发人员交流，你对缺陷发现的原因慢慢了解，你的水平才会得到提升。
3、了解数据库结构及学习数据库知识
在界面上你看不到的一些字段，往往是造成一些非常难发现的缺陷，因为这些字段是用来做控制作用。也可以利用数据库知识进行SQL注入。
4、学习工具
可以利用一些工具，方便我们去了解开发相关的知识，比如：Charles能够让我们查看所有网络和机器之间的HTTP流量情况。包括请求、响应、HTTP头信息(包含cookies和缓存)等。
在测试领域众所周知存在黑盒测试和白盒测试，黑盒测试更多是在集成测试阶段进行只关注应用是否符合需求，而不关心代码设计的结构，方式，方法。而白盒测试是针对黑盒测试提出的，前提是知道软件产品内部工作过程。通过测试来检测软件产品内部动作是否按照规格说明书的规定正常进行，通常是在单元测试阶段进行。那么做了这两种测试是否覆盖了软件测试的全部内容，即是否就能保证产品的质量呢。其实是不一定的，或者说如果靠这两种方法来覆盖，投入的代价是比较大的。譬如目前很火的OPEN API的测试，譬如对具备软件平台性质产品的测试。因为通过黑盒手工测试是很难完成的，而白盒测试是在单元测试进行的，显然对产品的测试带来很大的局限性，它也无法测试到产品在集成过程中带来的问题。那么灰盒测试就有它出现的必然性，这就是所谓存在就是合理的。
灰盒测试的特性：
1. 灰盒测试通常是在集成测试前期进行的。灰盒测试通常在程序员做完白盒测试之后（有些书上认为白盒测试是由测试人员进行的，我觉得纯属理想主义），在功能测试人员进行大规模集成测试之前进行的。
2. 灰盒测试是需要了解代码工程的实现的
3. 灰盒测试是通过类似白盒测试的方法进行的，也就是说和白盒测试的方法是相同的，是通过编写代码，调用函数或者封装好的接口进行的。
4. 灰盒测试是由测试人员进行测试的。
灰盒测试和白盒测试的区别
1. 测试的时段不同，白盒测试在单元测试阶段进行，灰盒测试在集成测试前期进行
2. 测试的关注对象不同，白盒测试更关注内部实现是否按照规格说明书进行，灰盒测试除了需要关注白盒测试关注的内容还更多从业务层面去考虑问题，考虑更多的组合测试业务场景。
3. 范围不同，白盒测试更关注单个代码段，函数的正确性，灰盒测试的对象已经基本能完成一个完整的业务功能。
4. 灰盒测试的代码比较独立，不像白盒测试基本上和程序代码需要做到一一对应。
灰盒测试和白盒测试的相同点
1. 目的相同
2. 方法相同，都是需要通过代码来实现
3. 对测试人员素质要求相同
灰盒测试和黑盒测试的不同点
1. 测试的方法不同。
2. 对测试人员要求不同。灰盒测试要求比较强的编程能力。
3. 测试范围不同，关注的对象不同，黑盒测试是覆盖产品范围最广的测试，是灰盒测试无法取代的。但是灰盒测试是可以被黑盒替代的，只是代价比较大，需要很多的测试用例。
灰盒测试和黑盒测试的相同点
1. 目的相同
2. 测试所处的时间段相近。
1.黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
2.白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
3.灰盒测试
灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。
