灰盒测试

灰盒测试 灰盒测试，是介于 白盒测试 与 黑盒测试 之间的一种测试，灰盒测试多用于 集成测试 阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。 定义 灰盒 测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于 黑盒测试 以增强测试效率、错误发现和错误分析的效率。 学术含义 灰盒 (Gray Box)是一种程序或系统上的工作过程被局部认知的装置。灰盒 测试，也称作灰盒分析，是基于对程序内部细节有限认知上的 软件调试 方法。测试者可能知道 系统组件 之间是如何互相作用的，但缺乏对内部程序功能和运作的详细了解。对于内部过程，灰盒测试把程序看作一个必须从外面进行分析的 黑盒 。 灰盒 测试通常与web服务应用一起使用，因为尽管应用程序复杂多变，并不断发展进步， 因特网 仍可以提供相对稳定的接口。由于不需要测试者接触 源代码 ，因此灰盒测试不存在侵略性和偏见。开发者和测试者间有明显的区别，人事冲突的风险减到最小。然而，灰盒测试相对 白盒测试 更加难以发现并解决潜在问题，尤其在一个单一的应用中，白盒测试的内部细节可以完全掌握。 灰盒测试结合了白盒测试和 黑盒测试 的要素。它考虑了用户端、特定的系统知识和操作环境。它在

灰盒测试：白盒测试和黑盒测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。 灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。 灰盒测试相对于其他黑白盒有什么特点： 1.灰盒测试比白盒测试效率高，从程序的整体出发，而非细节. 2.灰盒测试健壮性好，相对于白盒测试降低了程序代码改变而导致用例失效的风险。 3.灰盒测试更细致。灰盒测试要求测试人员关注程序的代码逻辑，根据代码逻辑扩充用例，更加细致。 如何做好灰盒测试。 1.测试定位要清晰。灰盒测试的对象应该是整个产品，而非各个组件，应从整个测试产品的业务出发进行测试设计。 2.测试阶段要正确。灰盒应该在集成测试中采用,他并不适合于单元测试。 3.测试辅助要必备。灰盒测试需要深入产品代码逻辑，对于测试人员来说，业务逻辑图是必不可少的，测试人员需要根据业务逻辑图进行功能点划分，并扩展用例。另外可以借助于测试覆盖率等工具辅助查找遗漏功能点. 4.运行状态检查点要仔细选择。灰盒测试对于程序运行状态的检查往往采用标志来判断

第一次听说灰盒测试，是在金蝶上班的时候，那时候老大让我们研究灰盒测试，当时一头雾水。来阿里工作一年多自己感觉现在做的工作有点像灰盒测试，于是总结了一下，拿出来给大家分享。 在测试领域众所周知存在黑盒测试和白盒测试，黑盒测试更多是在集成测试阶段进行只关注应用是否符合需求，而不关心代码设计的结构，方式，方法。而白盒测试是针对黑盒测试提出的，前提是知道软件产品内部工作过程。通过测试来检测 软件产品内部动作 是否按照规格说明书的规定正常进行，通常是在单元测试阶段进行。那么做了这两种测试是否覆盖了软件测试的全部内容，即是否就能保证产品的质量呢。其实是不一定的，或者说如果靠这两种方法来覆盖，投入的代价是比较大的。譬如目前很火的 OPEN API 的测试，譬如对具备软件平台性质产品的测试。因为通过黑盒手工测试是很难完成的，而白盒测试是在单元测试进行的，显然对产品的测试带来很大的局限性，它也无法测试到产品在集成过程中带来的问题。那么灰盒测试就有它出现的必然性，这就是所谓存在就是合理的。 灰盒测试的特性： 1. 灰盒测试通常是在集成测试前期进行的。灰盒测试通常在程序员做完白盒测试之后（有些书上认为白盒测试是由测试人员进行的，我觉得纯属理想主义），在功能测试人员进行大规模集成测试之前进行的。 2. 灰盒测试是需要了解代码工程的实现的 3. 灰盒测试是通过类似白盒测试的方法进行的