软件测试的新方法灰盒测试.doc

在测试领域众所周知存在黑盒测试和白盒测试，黑盒测试更多是在集成测试阶段进行只关注应用是否符合需求，而不关心代码设计的结构，方式，方法。而白盒测试是针对黑盒测试提出的，前提是知道软件产品内部工作过程。通过测试来检测软件产品内部动作是否按照规格说明书的规定正常进行，通常是在单元测试阶段进行。那么做了这两种测试是否覆盖了软件测试的全部内容，即是否就能保证产品的质量呢。其实是不一定的，或者说如果靠这两种方法来覆盖，投入的代价是比较大的。譬如目前很火的OPEN API的测试，譬如对具备软件平台性质产品的测试。因为通过黑盒手工测试是很难完成的，而白盒测试是在单元测试进行的，显然对产品的测试带来很大的局限性，它也无法测试到产品在集成过程中带来的问题。那么灰盒测试就有它出现的必然性，这就是所谓存在就是合理的。灰盒测试的特性：1. 灰盒测试通常是在集成测试前期进行的。灰盒测试通常在程序员做完白盒测试之后（有些书上认为白盒测试是由测试人员进行的，我觉得纯属理想主义），在功能测试人员进行大规模集成测试之前进行的。2. 灰盒测试是需要了解代码工程的实现的3. 灰盒测试是通过类似白盒测试的方法进行的，也就是说和白盒测试的方法是相同的，是通过编写代码，调用函数或者封装好的接口进行的。4. 灰盒测试是由测试人员进行测试的。灰盒测试和白盒测试的区别1. 测试的时段不同，白盒测试在单元测试阶段进行，灰盒测试在集成测试前期进行2. 测试的关注对象不同，白盒测试更关注内部实现是否按照规格说明书进行，灰盒测试除了需要关注白盒测试关注的内容还更多从业务层面去考虑问题，考虑更多的组合测试业务场景。3. 范围不同，白盒测试更关注单个代码段，函数的正确性，灰盒测试的对象已经基本能完成一个完整的业务功能。4. 灰盒测试的代码比较独立，不像白盒测试基本上和程序代码需要做到一一对应。灰盒测试和白盒测试的相同点1. 目的相同2. 方法相同，都是需要通过代码来实现3. 对测试人员素质要求相同灰盒测试和黑盒测试的不同点1. 测试的方法不同。2. 对测试人员要求不同。灰盒测试要求比较强的编程能力。3. 测试范围不同，关注的对象不同，黑盒测试是覆盖产品范围最广的测试，是灰盒测试无法取代的。但是灰盒测试是可以被黑盒替代的，只是代价比较大，需要很多的测试用例。灰盒测试和黑盒测试的相同点1. 目的相同2. 测试所处的时间段相近。灰盒测试，确实是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。 灰盒测试结合了白盒测试和黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。 灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。 灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。黑盒测试、白盒测试和灰盒测试的基本概念1. 黑盒测试 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。 黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。黑盒法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。黑盒法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。2. 白盒测试 白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。 白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。白盒法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。3. 灰盒测试 灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。 灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。 灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。浅谈灰盒测试自动化工具AppSight V2黑白双煞的困惑大家都知道，在软件开发生命周期过程中测试的地位举足轻重，它要占据这个软件开发生命周期中相当多的时间。典型的测试方法即黑盒测试和白盒测试。 前者也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。后者则是也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。是否有了黑白双煞两种手段后就可以保证测试工作高效进行、应用软件又是否能够如期交付呢？我们先来看一组统计数据，如图1所示。 图1测试发现问题后解决问题占用了更多的时间事实上，软件测试的根本目的是要提高应用软件的质量，保证其未来能够可靠稳定运行。图1的数据也充分说明了，随着测试的深入，测试发现问题后的解决问题占用了更多的时间。此时黑盒白盒都显然有些力不从心了。白盒测试的代码扫描和应用功能挂不上钩，而黑盒测试的结果就是测试人员把自动化功能测试发现的问题通过缺陷跟踪系统提交给开发人员处理。尽管好一点的测试人员会提供详细的测试用例文档和错误截图，但是开发人员仍不得不面临重现问题并不断的采用Trial&Error的手段来分析并解决问题。 很显然这种问题处理方式是手工方式且非常没有效率，会延缓问题的处理时间。因此，我们需要另辟新径。灰盒俱备，只欠工具 所谓灰盒测试，是介于黑盒和白盒之间的，既关注输出对于输入的正确性，同时也关注内部表现的测试方法。这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。它达到了某种目的，也就是一旦发现问题，可以迅速定位到黑盒中的某个分支，甚至代码级别。灰盒测试在系统组件的协同性环境中评价应用软件的设计，从而增强了测试效率、错误发现和错误分析的效率，可以使得测试达到一个新的境界。但是，灰盒测试对测试人员的要求也比较高，比如灰盒测试要求测试人员具有丰富的开发知识；需要测试人员更多地从业务层面去考虑问题，考虑更多的组合测试业务场景的能力；另外，很多时候问题的解决还需要很多外围知识，包括数据库层面上的分析能力、J2EE服务器内部的调用链分析等。所以简单来看，灰盒测试是一个非常好的测试理念，但要真正发挥其作用，显然还需要相应的自动化工具这个东风来吹一下。AppSight就是其中一种自动化工具。 AppSight概述AppSight由来已久，原来是有Identify开发的，之后被BMC公司收购但是独立运营。 灰盒测试方法 灰盒测试中的精华就是通过灰盒测试能大大缩短解决测试中发现的问题的时间。问题解决流程实际上包括了主要两个过程：“根源问题分析”和“问题解决”。而以经验来看，以前我们的时间主要是耗费在“根源问题分析”上的，一旦问题被定位，解决问题相对是非常容易的。 为了进行根源问题分析，通常需要3个典型步骤来进行分析：信息收集、问题重现和问题分析可惜的是，目前来看，大多数开发人员都是手工来完成这些步骤的，即这个流程是非高效的手工方式，而且易于出错。 而AppSight这个工具的背后实际上是提供了一种问题解决思路的转变，也就是说需要把重现问题这个环节最大程度地消除，同时在发现问题的时候就尽可能的去收集问题信息和相关环境信息，并协助定位问题。这于灰盒测试的方法实际上是不谋而合的，如图2所示。 图2AppSight提供了一种问题解决思路的转变工作原理BMCAppSight应用解决方案事实上是通过采用类似于飞机上的“黑盒子”专利技术来使得测试后问题解决流程变得更加自动化。这又完全不同于黑盒测试，原因在于飞机的黑盒子最终是可以被解剖的，而黑盒测试永远是面对一个黑盒子。具体而言，AppSight系统会将问题发生的相关信息完整录制下来，包括问题发生的现场场景、信息及分析等，从而快速切入到问题根源。如图3所示。 图3AppSight系统会将问题发生的相关信息完整录制下来下面是运用AppSight工具的典型测试工作流程。 1.测试人员通过AppSight提供的录制器进行测试录制，由于灰盒测试不同于黑盒测试中主要强调回归测试的概念，因此录制不需要添加校验点和进行参数化，整个过程相当简单易用。 2.录制过程中，录制器会将所有过程录制成一个灰盒文件，同时包含了很多环境信息和录制中的性能数据信息：如数据库调用、Web访问信息、J2EE/.NET调用信息等，这些信息将有助于将来问题的分析。 3.录制完成后通过AppSight的集成器将缺陷自动创建到缺陷跟踪系统中，同时附上灰盒文件，于是开发人员可以进行问题处理。 4.开发人员拿到相关信息后，可以直截了当地看到当时测试用例的全过程，加之灰盒文件提供了有价值的信息，进而可以快速定位到代码中某一行的位置，这样开发人员就只需要直接进行问题处理即可。 图4问题最终被AppSight准确定位到应用代码相应行和函数小结BMCAppSight通过自动化手段进行灰盒测试的优化应用，并提供开发测试解决方案。它采用的专利问题解决方案技术，从以下几个方面大大加速了测试过程中问题解决流程：提供了自动化的信息采集、捕获现场操作并将所有的相关信息统一打包处理；消除了通常情况下需要完整重现问题发生的过程，避免在重现问题上耗费的时间开销；大大加速了问题分析的过程，使得开发人员能够快速分析问题并隔离根源问题。 事实上，BMCAppSight应用问题解决方案非常适用于测试人员和开发人员。对于测试人员来说，由于自动记录了测试场景和问题发生过程，避免了开发人员和测试人员之间相互推诿，同时开发人员可以通过“黑盒子”直接从测试人员那里得到更多信息，并帮助直接定位到代码行。如果说灰盒测试只是万事俱备只欠东风，那么AppSight就是东风。 灰盒测试技术灰盒测试法1999年，美国洛克希德公司发表了灰盒测试法的论文，提出了灰盒测试法。灰盒测试是一种综合测试法，它将黑盒测试、白盒测试、回归测试和变异(Mutation)测试结合在一起，构成一种无缝测试技术。它是一种软件全寿命周期测试法，用于在功能上检验为嵌入式应用研制的Ada、C、FORTRAN和汇编语言软件。该方法可自动生成所有测试软件，从而降低了成本，减少了软件的研制时间。初步研究表明过去要用几天时间对一套软件进行彻底测试，现在不到4小时就可完成，软件测试时间减少75。灰盒测试定义为将根据需求规范说明语言(RSL)产生的基于测试用例的要求(RBTC)，用测试单元的接口参数加到受测单元，检验软件在测试执行环境控制下的执行情况。灰盒测试法的目的是验证软件满足外部指标要求以及软件的所有通道都进行了检验。通过该程序的所有路径都进行了检验和验证后，就得到了全面的验证。完成功能和结构验证后，就可随机地一次变化一行来验证软件测试用例在软件遇到违背原先验证的不利变化时软件的可靠性。灰盒测试法是在功能上验证嵌入式系统软件的一种10步骤法。程序功能正确系指在希望执行程序时，程序能够执行。子功能是指从进入到退出经过程序的一个路径。测试用例是由一组测试输入和相应的测试输出构成的测试矢量。灰盒测试法的步骤如表1所示。在目前有许多软件测试工具可利用的条件下，灰盒测试法的自动化程度可达7090。利用软件工具可从要求模型或软件模型中提取所有输入和输出变量，产生测试用例输入文件。利用现行静态测试工具可确定入口和出口测试路径。利用静态测试工具可确定所有进出路径。利用仿真得到的要求，可产生测试软件需要的实际测试用例部分数据值。表1 10步灰盒法步骤说明1确定程序的所有输入和输出2确定程序所有状态3确定程序主路径4确定程序的功能5产生试验子功能X的输入。这里X为许多子功能之一6制定验证子功能的X的输出7执行测试用例X的软件8检验测试用例X结果的正确性9对其余子功能。重复7和8步10重复4-8步，然后再进行第9步。进行回归测试1. 测试用例测试用例可根据系统工程算法、详细设计、软件要求或实际代码生成。这些资源的任何结合都可生成功能上或结构上的测试用例。2. 产生基于测试用例的要求灰盒测试法利用判定测试法来预置程序测试之前所有要求的条件。保证核心程序正确的一种方法是利用形式证明(formal verification)。当用形式语言说明软件要求时，就能执行该软件要求，验证要求的说明的正确性。然后。利用先决条件预测。并执行软件要求，就能产生期望的结果即后续条件(postconditiona1)验证。灰盒测试法就是利用需求规范说明语言确定的预测和验证，产生基于测试用例要求的输入。如果对于每个输入，程序都能执行到头，并且输出的判定是正确时，就称该程序对于该输入是正确的。如果该要求不是可执行的形式，则要求编写程序可用下述简单的方法产生预测和验证。如果输入没有唯一有效值，每一个输入指定一个不为0或l的值。根据要求将输入转换成输出。在完成要求转换时，输入就是预测 ，输出就是验证。这一组预测和验证就成为基于测试用例的要求。在鉴定要求过程中。如果遇到条件语句，就要再执行一遍要求，直到所有条件都满足为止。简单地说，如果要求不包括条件语句，验证该要求只需一个测试用力用例就够了。灰盒测试法是专门为嵌入式软件研制的。嵌入式软件的关键算法通常是系统工程组制定的。在需求分析阶段，分配给软件的要求和算法，通常作为输入提供给软件工程组。系统要求、算法常常是用FORTRAN、C语言作为编码语言在系统的软件模拟中制定和检验的。得到的软件要求在多数情况下是算法语句。即FoRTRAN、C语言的系统的软件模拟中制定和检验的。总之。不管要求是用可执行的需求规范语言说明还是嵌入在现行系统模拟中，这些需求信息总是可用来产生基于测试用例的要求。3. 测试执行环境产生基于测试用例的要求后，必须将受测软件放在模拟受测软件的环境中，提取实际的结果。灰盒测试工具具有足够的智能，生成要求的驱动器和插头。最后，得到的实际结果要根据基于测试用例产生的要求得到的期望结果进行检验。受试软件必须在不同层次上进行检验。第一层是单元级。将受试软件放在能够提取模块规范并能产生调用受试单元的驱动器的环境中。被受试模块(MUT)调用的所有模块，如果不存在，就会自动地被打桩(stubbed)。 灰盒测试法支持桩数据通过MTIF文件返回。灰盒测试法支持所有测试软件的自动代码生成(驱动器、桩模块、结果检验)。在软件集成测试中，再次用灰盒测试工具产生驱动器，测试该模块与下级模块的关系。当受试模块完成一次调用返回时，就根据基于测试用例要求的检验数据，对模块接口上的数据值进行检验。对测试用例输入文件中的每个测试用例都要重复这一检验过程。灰盒测试法永远不进入受试模块的内部，所有数据都在受试模块外部检查。模块被放进测试环境中时就受到了探测。这样就使测试环境获得对通道覆盖信息能见能力。当一个模块通过了基于测试用例的要求并走遍了所有路径后，就认为该模块通过了测试。当测试检验得到1分时，模块从上到下每个路径就得到1分。一旦分数达Ii00，就认为该模块在功能上和结构上通过了测试。灰盒测试法可从上到下进行测试，也可从下到上进行测试。灰盒测试法可用于软件测试的各个阶段。单元级测试与模块或集成级的测试一样。不管用户进行严格的单元级测试还是集成测试，灰盒工具都能提供一致的结果。实时灰盒测试法2001年，洛克希德公司在原来的基础上，提出了实时灰盒测试法。最初的灰盒测试法并不是要解决实时或系统级测试问题，其主要目的是提供一套能够彻底测试软件产品的软件。当计算机处于实时环境下，新的问题就来了。计算机系统不仅要产生正确的答案，而且还要满足严格的定时限制。实时处理意味着专用计算机常常并行运行多个处理程序。实时灰盒测试法是在灰盒测试法的基础上，解决了软件的实时性能测试。实时地使用灰盒法，只需要将时间分量加到期望的输出数据上。对于在角位移时产生正弦的系统，正常的灰盒测试包括输入角度和期望的输出正弦值。“对于X=.30”，Y=sin(X)，试验结果将为05。该试验的结果中没有时间分量。因此，每当出现这种响应时，就会与期望的结果05比较。这可能是测试开始后的1毫秒，也可能是测试开始后的10秒。在实时系统中，这种试验是不可接受的。实时试验将规定为“y(t)=sin(x，t)”，增加的时间分量“t”就能保证期望值将在对象级时间范畴里进行比较。使用图1的sin X，主要对象是X。对象X的分量是X.sine。X.sine的对象级时间值是从图中曲线读出的。X一轴为对象级时间轴。因此，在X对象产生时，X.sine应该在1(X.olt)处为O。在lOX.olt处，X.sine的值应该是-O5。在仿真中，一个步骤是检验原始数据是否具有确定的趋势；检查原始数据的另一步骤是用标图包来显示原始数据。这两个步骤有助于工程师在搜集数据时对数据进行目视查看，以减少实时应用时数据的剔除量。在实时测试期间，要检查系统的xolt、xsine和xolt的值。记录时间标记值时间标记组，在测试后立即进行处理，以证实在曲线上时标值在开始和结束时标之间。记录、记数、计时和取样可通过插入代码由软件来做。1. 黑盒测试 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。2. 白盒测试白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。3. 灰盒测试灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。灰盒测试结合了白盒测试盒黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。2.2 白盒测试（结构测试）白盒测试（又叫作结构测试）是指测试情境主要是针对逻辑路径来设计的。测试人员检查程序或系统的内部结构。测试数据根据对程序或系统的逻辑检查来确定，而不关心程序或系统的需求。测试人员知道内部的程序结构和处理逻辑，就像汽车维修工知道汽车的内部构造一样。这一类别中的测试包括基本路径分析、语句覆盖、分支覆盖、条件覆盖、分支/条件覆盖。白盒测试的一个优点是测试比较彻底，并且侧重于已经开发出来的代码。因为测试人员知道内部的结构或逻辑，一些致命的错误或程序员故意放置一段代码而搞的恶作剧就会更容易地被检查出来。白盒测试的一个缺点是不能验证规约的正确性，也就是说，白盒测试仅仅侧重于测试内部的处理逻辑，而不去验证逻辑是否满足需求规约。白盒测试的另一个缺点是无法检验代码中遗漏的路径和数据敏感性错误。例如，如果程序中的代码语句应该写成“if |a-b| 10”，但是结果却写成了“if (a-b)10”， 如果没有详细的规约的话，这种错误将无法被检测出来。白盒测试最后的一个缺点是无法穷举程序中所有可能的逻辑路径，因为穷举导致的测试数量将会是一个天文数字。2.1 黑盒测试（功能测试）黑盒测试（又叫作功能测试）是指测试条件主要根据程序或系统的功能实现来制定。也就是说，测试人员所要求的信息是输入的数据和观察到的输出结果，但他们不知道程序或系统是怎样工作的。正如一个人不必知道汽车的内部是如何工作的而只管去开它，同样也不必知道程序的内部结构而只管去执行它。测试人员侧重于根据规约去测试程序的功能。在黑盒测试中，测试人员把程序看作一个黑匣子，对程序或系统的内部结构并不关心。这一类的测试包括决策表、等价类划分、范围测试、边界值测试、数据库集成测试、因果图、正交阵列测试、阵列和表测试、异常测试、极限测试、随机测试。黑盒测试的一个主要的优点就是测试活动本身的行为要与程序或系统的设计行为相吻合，是正常的一些操作，并且容易被大家所理解。一些测试技术如结构化走查、审查和联合应用设计（JAD）可以证实这一点。黑盒测试的一个限制就是测试全部的、无遗漏的输入流是不太可能的，因为这要求每一个可能的输入条件或其组合都要被测试到。另外，因为测试人员不知道内部的结构或处理逻辑，在黑盒测试中没有被测到的部分很可能会有致命的错误或程序员故意放置一段代码而搞的恶作剧。例如，假设一个为公司开发工资管理程序的程序员在自己开发的代码中嵌入一段“保护”自己工作的代码，他在程序中嵌入如下代码，如果这位员工被辞退后，他的员工代码在系统中不再存在，则他预置在程序里的判断迟早会发挥作用。if my emp