现在软件测试已经贯于穿软件开发生命周期的整个过程中，是软件质量控制体系中的重 要环节， 在整个系统生命周期中有哪些测试策略呢？本章我们将详细介绍在系统生命周期中常 用的测试策略。 本章主要包括以下内容： l 测试在质量体系中的位置 l 软件测试模型 l 系统生命周期中的测试策略
2.1
测试在质量体系中的位置
测试不仅仅是找出软件中的缺陷，它在软件质量体系中占有重要的位置，下面我们来讨 论在能力成熟度模型和基于过程的质量模型中软件测试所处的位置。 2.1.1 能力成熟度模型集成 CMMI（Capability Maturity Model Integration，能力成熟度模型集成）认证评估，在过去的 十几年中，对全球的软件产业产生了非常深远的影响。CMMI 共有五个等级，分别标志着软件 企业能力成熟度的五个层次，如图 21 所示。从低到高，软件开发生产计划精度逐级上升，单 位工程生产周期逐级缩短，单位工程成本逐级降低。据 SEI 统计，通过评估的软件公司对项目 的估计与控制能力提升约 40%～50%，生产率提高 10%～20%，软件产品出错率下降超过 1/3。 图 21 CMMI 模型 第一级：初始级 初始级的软件过程是未加定义的随意过程，项目的执行也是随意的，甚至是混乱的。当然有些企业可能已经制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求， 并且在执行过程中没有政策、资源等方面的支持时，它仍然被视为初始级。 第二级：受管理级 根据多年的经验和教训，企业总结出软件开发的首要问题不是技术问题而是管理问题。 因此，CMMI 发展到了第二级，更强调软件管理过程，建立一个可管理的过程是很重要的， 它可以将开发的过程重复， 只有可重复的过程才能逐渐改进并使其成熟。 受管理级的管理过程 主要包括五个方面：需求管理、项目管理、质量管理、配置管理和子合同管理；其中项目管理 过程又分为计划过程和跟踪与监控过程。 通过实施这些过程， 从管理角度可以看到一个按计划 执行且阶段可控的软件开发过程。 第三级：已定义级 在受管理级定义了管理的基本过程，但并没有定义执行的步骤标准。在第三级则要求制 定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中。规定所有开发的 项目或产品都必须遵守该标准过程，并且按照过程执行，当然在实际过程中，可以根据具体 的项目对该过程进行适当的裁剪，但过程的裁剪不是随意的，在使用前必须经过企业有关人 员的批准。 第四级：定量管理级 第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品（包括工作产 品和提交给用户的最终产品）的质量需要有明确的度量指标。这些度量应是详尽的，且可用于 理解和控制软件过程和产品，量化控制将使软件开发真正成为一种工业生产活动。 第五级：持续优化级 持续优化级的目标是达到一个持续改善的境界。所谓持续改进是指根据过程执行的反馈 信息来改善当前已定义的开发过程，即优化已定义的执行步骤。如果企业达到了第五级，就表 明该企业能够根据实际的项目性质、 技术等因素， 不断调整软件开发过程使开发过程达到最优。 CMMI 模型中包括验证（VER）和确认（VAL）两大过程域，这两大过程域与软件测试有 着紧密的联系，也是规范软件测试的两大过程域。 （1）验证（VER）过程域的目的是确保所选定的工作产品符合其指定的需求。验证过程 域包括验证准备、验证执行和纠正措施识别。 验证的对象包括产品和中间工作产品，验证方法是将待验证的对象与选定的客户需求、 产品需求和产品组件需求加以比较。 验证是渐进的过程， 因为它发生在产品和工作产品的整个 开发过程中，从需求开始验证，历经工作产品的验证，最终为已完成产品的验证。 （2）确认（VAL）过程域的目的是展示完全置于预期环境中的产品或产品组件是否满足 预期的使用需求。 所有的产品都可在其预期环境中实施确认活动，例如：操作、培训、制造、维护及支持 服务。所有用于工作产品的确认方法，也能使用在对产品和产品组件的确定过程中（在所有过 程域中，产品和产品组件的含义包括服务和其组件）。工作产品（例如需求、设计、原型）在 整个产品生命周期，应及早并逐步实施确认。 确认环境必须可代表产品和产品组件的预期环境，同时该确认环境也适用于工作产品确 认活动的预期环境。 确认证明是指所提供的产品是否符合预期的使用需求，验证与确认很容易被混淆，验证
是确定每个工作产品是否正确反映了特定需求， 即验证确保 “你正确地做了” ， 而确认是指 “你 做了正确的事” 。确认活动使用与验证类似的方法，例如测试、分析、检查、示范或模拟。通 常，确认活动包含最终用户和其他相关人员。确认与验证活动经常同时实施，且可能使用部分 相同的环境。若有可能，实施确认应将产品或产品组件置于其预期环境中运行。确认可能使用 全部或部分的预期环境， 使用工作产品实施确认， 可让问题在项目生命周期中通过相关人员的 参与及早被发现。服务的确认活动可应用于工作产品，例如建议书、服务目录、工作描述和服 务记录。 当在确认过程中问题被识别出来时，需要参考需求开发、技术解决方案或项目监控过程 域的实践来解决。 2.1.2 基于过程中的质量 目前，软件项目需求正飞速增长，相应的软件开发活动也随之急剧增长，这样使得软件 过程 （即用于开发和维护软件及其相关产品的一组活动、 方法、 实践及转换） 得到更多的关注。 软件过程在成本估算、 项目进度和软件质量等方面必须把握准确， 同时产品必须满足用户对其 功能和质量的要求，所以深入研究软件度量模型、建立基于度量的量化管理是控制软件过程、 提高软件质量的有效保证。基于过程的质量控制如图 22 所示。 定义过程 开发产品 评估产品质量 改进过程 质量是 否合格 产品质量合格 是 否 图 22 基于过程的质量控制 而软件测试是评估产品质量的重要手段，软件测试贯穿产品开发的始终，那么在整个软 件测试过程中， 应该如何来度量软件测试的质量呢？在整个测试过程中， 质量度量主要包括以 下几个方面： l 测试覆盖率； l 测试执行的质量和效率； l 测试用例深度、质量和有效性； l 缺陷分布分析。 （1）测试覆盖率。 测试覆盖率是指在测试过程中对被测试对象的需求、功能、代码测试的程度。主要包括 对需求和代码两个方面的覆盖评估， 但其实这两个方面的评估本质是一致的， 都是通过测试用 例来评估覆盖率。 ①基于需求的测试覆盖评估依赖于对已执行/运行的测试用例的核实和分析，其主要是通 过评估测试用例覆盖率来评估，在测试过程中的目标是要求需求的覆盖率达到 100%。在实际 测试过程中可以通过统计已执行的覆盖率和执行成功的覆盖率来评估需求覆盖率的值。
已经执行的测试用例覆盖率指所有测试用例中被执行用例所占百分比，公式如下： 已执行的测试覆盖率 ＝ Tx/Rft 其中，Tx 表示已执行的测试用例数，Rft 是测试需求的总数。 成功执行的覆盖率指测试过程中执行成功的测试用例所占百分比，公式如下： 成功的测试覆盖率 ＝ Ts/Rft 其中，Ts 表示已执行并且执行状态为成功的测试用例，Rft 是测试需求的总数。 ②基于代码的测试覆盖率是对被测试的程序代码语句、路径或条件的覆盖率分析。代 码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上，主要使用于白盒测试 阶段。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元 素；数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之 前是否已经定义。 基于代码的测试覆盖通过以下公式计算： 已执行的测试覆盖率＝Tc/Tnc 其中，Tc 是指使用代码语句、条件分支、代码路径、数据状态判定点方法设计的并被执 行的用例数，Tnc（Total number of items in the code）是指项目中总的代码数。
（2）测试执行的质量和效率。 测试执行的效率是指测试工程师每天执行的测试用例数，一般每天大概执行 50 条测试用例。 测试执行的质量包括两个方面：一方面是指每个测试用例发现的缺陷数；另一方面是指 软件发布后遗留的软件缺陷数占总缺陷数的百分比，一般要求低于 0.5%。 故测试执行的质量和效率一般使用以下指标来统计： l 每人每天所执行的测试用例数； l 每人每天发现的缺陷数； l 缺陷遗留率。 （3）测试用例深度、质量和有效性。 测试用例是所有测试活动的基础，测试用例质量的好坏直接影响软件测试的质量。 测试用例的度量主要从测试用例深度（也叫测试用例密度）、质量和有效性三个方面来实 现。当然如果开展了自动化测试，还可以从测试用例自动化的程度这一维度来度量。 测试用例深度（Test Case Depth，TCD）指每 KLOC（千行代码）设计的测试用例数或每 个功能点所设计的测试用例数，一般情况下认为每 KLOC 设计的用例数越多表示测试的质量 越高。当然必须考虑冗余或重复的用例数，在设计用例时应该尽量避免出现冗余或重复。
测试用例质量（Test Case Quality，TCQ）其实是一个很复杂的指标，它包括两个方面： 一方面指如何设计一个好的测试用例；另一方面指测试发现缺陷的数量。 一般情况下一个好的测试用例应该考虑以下几个方面： l 测试用例覆盖程度； l 测试用例是否已达到工作量最小化； l 测试用例的分类、描述是否清晰； l 测试用例是否表明目的； l 测试用例的易维护性； l 有充分的负面测试；
l 测试用例没有重复、没有冗余。 发现缺陷方面主要是指测试用例发现的缺陷数量，公式如下： TCQ = 测试用例发现的缺陷数量/总的缺陷数量 总的缺陷数量除了测试用例发现的缺陷数外，还包括通过 adhoc 测试（随机、自由的测 试）、集体走查（Workthrough）和 Firedrill 测试（类似消防训练的用户压力/验收测试）等其 他手段发现的缺陷。 如果企业开展了自动化测试，可以计算可自动化测试用例的数量，这也是衡量测试用例 质量的一个方面，将手动测试用例转换为自动化测试用例可以节约写自动化测试用例的时间， 可转换的越多，节约的成本就越多。 （4）缺陷分布分析。 缺陷是测试过程中体现工作效率和价值的重要指标之一，也是分析系统质量的重要指标。 在测试过程中除了要提交缺陷外， 还需要对缺陷的分布情况进行分析， 这样可以做为改进系统 质量的依据。 在提交缺陷时，需要注意一些必需的元素项，即一个好的缺陷通常需要包含的内容，现 在一些企业通常会使用缺陷管理工具来管理测试过程中所发现的缺陷。 对于提交的缺陷需要进行分析，这样可以进一步改进系统质量并且可以改进测试方法和 测试策略，常用的缺陷分析方法有：ODC 正交缺陷分析法、Gompertz 缺陷分析法、Rayleigh 缺陷分析法、四象限缺陷分析法和根源缺陷分析法，具体的缺陷分析法在第 7 章详细介绍。
2.2 软件测试模型
在软件质量体系中，为了更好地指导软件开发的全部过程、活动和任务，人们提出了软 件开发模型。典型的开发模型有：边做边改模型（BuildandFix Model） 、瀑布模型（Waterfall Model） 、快速原型模型（Rapid Prototype Model） 、增量模型（Incremental Model） 、螺旋模型 （Spiral Model） 、演化模型（Incremental Model） 、喷泉模型（Fountain Model） 、智能模型（四 代技术（4GL） ） 、混合模型（Hybrid Model） 。但是所有的开发模型都没有把软件测试列进去， 这样就无法对软件测试过程进行很好的指导， 而随着软件测试的发展， 软件测试成为软件质量 保证的重要手段之一， 软件测试也慢慢地受到公司的重视， 于是人们就希望软件测试也像软件 开发一样，有一个模型来指导整个软件测试过程。当前最常见的软件测试模型有：瀑布模型、 V 模型、W 模型、H 模型和 X 模型，下面的内容将详细介绍这几种模型。 2.2.1 瀑布模型 1970 年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型” ，直到 80 年代早期， 它一直是唯一被广泛采用的软件开发模型，瀑布模型是由瀑布开发模型演变而来的。 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试 和运行维护六项基本活动， 其过程是将上一项活动接收的工作对象作为输入， 当该项活动完成 后会输出该项活动的工作成果， 并将该项成果作为下一项活动的输入。 该模型规定这六项基本 活动自上而下、固定相互衔接的次序，如同瀑布流水，逐级下落。从本质上讲，它是一个软件 开发架构，开发过程是通过一系列阶段顺序展开的，从需求分析直到产品发布和维护。如果在
其中某个阶段有信息未被覆盖或有问题， 那么就得返回到上一个阶段， 并对这些阶段进行适当 的修改才能进入下一个阶段，这样每个阶段都会产生循环反馈，开发过程从一个阶段“流动” 到下一个阶段，这也是瀑布模型名称的由来，瀑布模型如图 23 所示。 图 23 瀑布模型 瀑布模型的核心思想是按工序将问题简化，将功能的实现与设计分开，便于分工协作， 即采用结构化的分析与设计方法将逻辑实现与物理实现分开。 瀑布模型的优点如下： l 为项目提供了按阶段划分的检查点； l 当前一阶段完成后，只需要关注后续阶段； l 可在迭代模型中应用瀑布模型，如图 24 所示。 图 24 迭代中的瀑布模型 增量迭代应用于瀑布模型，迭代 1 解决最大的问题，每次迭代产生一个可运行的版本，
同时增加更多的功能，但每次迭代必须经过严格的质量和集成测试。 瀑布模型有以下缺点： l 项目中各个阶段之间极少有反馈； l 只有在项目生命周期的后期才能看到结果； l 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 2.2.2 V 模型 V 模型最早是由 Paul Rook 在 20 世纪 80 年代后期提出的，V 模型在英国国家计算中心文 献中发布，目的是改进软件开发的效率和效果。它是软件测试最具代表性的测试模型之一。 在传统的开发模型中，如瀑布模型，通常把软件测试过程作为在需求分析、概要设计、 详细设计和编码全部完成之后的一个阶段， 尽管有时软件测试工作会占整个项目周期一半的时 间，但是仍然被认为软件测试只是一个收尾工作，而不是主要的工程。故对以前的测试模型进 行了一定程度的改进，V 模型其实是软件开发瀑布模型的变种，反映了软件测试活动与软件开 发过程（从分析到设计）的关系，如图 25 所示。 图 25 V 模型 V 模型从左到右， 描述了基本的开发过程和测试行为， 明确地标明了测试工程中存在的不 同级别以及测试阶段和开发过程各阶段的对应关系。 图中箭头代表了时间方向， 左边下降的是 开发过程各阶段，与此相对应的是右边上升的部分，即测试过程各阶段。 V 模型指出， 单元和集成测试是验证程序设计， 单元测试主要由白盒测试工程对代码进行 测试，但目前国内的软件测试，真正做白盒测试的企业不多。这主要有两大原因：第一，白盒 测试投入的成本很高， 并且产出不明显， 很多企业不希望投入更多的资源去做这项工作； 第二， 白盒测试对测试工程师的要求较高， 在目前系统测试还没有完全成熟的情况下就很难真正地开 展白盒测试。而集成测试是介于白盒测试与系统测试之间的一种测试，也叫灰盒测试，由于它 与白盒测试和系统测试之间没有明显的界限， 所以在实际的测试过程中， 即使开展集成测试也 是由系统测试工程师来完成。 系统测试主要验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标， 由测试人员和用户进行软件的确认测试和验收测试， 以及对需求说明书进行测试， 以确定软件
的实现是否满足用户需求或合同要求。 V 模型存在一定的局限性，它把测试过程作为在需求分析、概要设计、详细设计及编码之 后的一个阶段。 这样如果没有开展白盒测试一般都是在程序设计完成后才开始测试， 并且需求 分析阶段隐藏的问题一直到后期的验收测试才被发现，因此修改缺陷的成本就高了很多。 由于 V 模型是软件开发中瀑布模型的变种，所以它存在和瀑布模型相似的一些问题。由 于测试阶段处于软件实现后， 这意味着在代码完成后必须有足够的时间预留给测试活动； 否则 将导致测试不充分， 开发前期未发现的错误会传递并扩散到后面的阶段， 而在后面发现这些错 误时，可能已经很难再修正，从而导致项目的失败。 V 模型最大的缺陷就是只把程序作为被测试对象， 而需求、 说明书等其他规格说明书都未 被列为测试对象。 2.2.3 W 模型 由于 V 模型存在一些明显的缺陷，人们就在实际测试过程中对 V 模型进行了改进，将 V 模型演变为 W 模型。W 模型由 Evolutif 公司提出，由两个 V 字型模型组成，相对于 V 模型， W 模型增加了软件各开发阶段中应同步进行的验证和确认活动，如图 26 所示。 图 26 W 模型 W 模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计 等同样要测试，也就是说，测试与开发是同步进行的。 W 模型有利于尽早全面地发现问题。从需求分析开始测试工程师就参与到项目的测试 中，当需求分析完成后，测试工程师就需要参与到需求的验证和确认活动中，并需要提供可 测试性需求分析说明书，这样可以尽早地发现需求阶段的缺陷。同时，对需求的测试也有利 于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项 目进度。 但 W 模型也存在局限性，需求、设计、编码等活动被视为串行的，同时，测试和
开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一阶段工作， 这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W 模型并不能解除测 试管理面临的困惑。 2.2.4 H 模型 H 模型将测试活动分离出来， 形成一个完全独立的流程， 将测试准备活动和测试执行活动 清晰地体现出来，如图 27 所示。 图 27 H 模型 H 模型演示了在整个生命周期中某个层次上一次软件测试的“微循环” 。当测试条件准备 完成进入测试就绪状态后，在测试准备阶段需要至少完成以下几部分工作： l 该开发流程对应的测试策略是否完成； l 测试方案是否完成； l 测试用例是否完成； l 测试环境是否搭建好； l 相关输入件、输出件是否明确。 模型中其他流程可以是任意的开发流程，它是开发工程师提交测试的阶段产品（即被测 试对象），如设计流程、编码流程等。 当测试条件成熟，并且测试准备工作已经完成，进入了测试就绪点，测试执行活动才可 以进行。 与 V 模型和 W 模型不同的是，H 模型的核心是将软件测试过程独立出来，并贯穿产品的 整个生命周期，与开发流程并行进行，不需要等到程序全部开发完成才开始执行测试，这充分 体现了软件测试要尽早准备、尽早执行的原则。不同的测试活动可以按照某个次序先后进行， 当一次测试工作后产品质量无法达到要求时，可以反复进行多次测试。 2.2.5 X 模型 X 模型的基本思想是由 Marick 提出的，但是 Marick 不建议建立一个替代模型。Robin F Goldsmith 引用了 Marick 的一些想法，并经过重新组织，形成了“X 模型” 。当然这并不是为 了和 V 模型相对应而选择这样的名字，是由于 X 通常代表未知，而 Marick 也认为他的观点并 不足以支撑一个模型的完整描述， 但具备一个模型所需要的主要内容， 其中包括了探索性测试 （Exploratory Testing）见解，如图 28 所示。
图 28 X 模型 Marick 对 V 模型提出质疑，他认为 V 模型必须按照一定顺序严格执行开发步骤，而这样 很可能无法反映实际的实践过程。而众所周知很多项目在立项时需求并不完整，但 V 模型还 是从需求处理开始， 要求对各开发阶段中已经得到的内容进行测试， 但它没有规定需要取得多 少内容，如果没有任何的需求资料，开发人员知道他们要做什么吗？或者需求不完善，开发工 程师做出来的功能就不完善，必须不断地修改。他主张在 X 模型中需要足够的需求并且需求 至少进行一次发布。 Marick 也质疑单元测试和集成测试的区别，目前在国内真正做单元测试的企业不多，很 多企业都是跳过单元测试直接进行集成测试，甚至集成测试也被跳过，直接进行系统测试。而 X 模型则没有强制要求在进行集成测试之前，必须对每一个程序片段进行单元测试，但是 X 模型并没有提供是否跳过单元测试的判断准则。 Marick 认为一个模型不应该规定那些和当前所公认的实践不一致的行为。X 模型的左边 描述的是针对单独程序片段所进行的相互分离的编码和测试， 此后将进行频繁的交接， 通过集 成最终合成为可执行的程序， 这些可执行程序还需要进行测试。 已通过集成测试的成品可以进 行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。 X 模型提倡探索性测试， 指不进行事先计划的特殊类型的测试， 这样可以帮助有经验的测 试工程师发现测试计划之外更多的软件错误， 避免把大量时间花费在编写测试文档上， 导致真 正用于测试的时间减少。
2.3 系统生命周期中的测试策略
软件测试策略是指在软件测试标准、测试规范的指导下，依据测试项目的特定环境约束 制定的软件测试原则、策略和方法的集合。系统生命周期测试策略如图 29 所示。图 29 系统生命周期测试策略 软件测试的策略、方法和技术是多种多样的，对于软件测试技术，从是否执行被测试软 件的角度划分： 可分为静态测试和动态测试两种； 从是否针对系统的内部结构和具体实现方法 的角度划分：可分为白盒测试、灰盒测试和黑盒测试三种。其中灰盒测试是介于白盒测试与黑 盒测试之间的一种测试方法，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但 这种关注不如白盒测试详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运 行状态，所以不易界定灰盒测试的范围，很多公司不开展灰盒测试。 2.3.1 开发阶段的测试策略 在开发阶段的测试策略和方法主要是白盒测试，当然有一些公司也会开展灰盒测试，但 并不多。 白盒测试也称结构测试或逻辑驱动测试， 主要是测试源程 序内部的结构， 通过测试来检查程序内部动作是否满足设计规 格说明书的要求，检查源程序中路径覆盖情况。白盒测试将被 测程序看作一个打开的盒子，如图 210 所示。 白盒测试要求对被测程序的结构特性做到一定程度的覆 盖，通常的程序结构覆盖测试方法有： l 语句覆盖； l 判定覆盖； l 条件覆盖； l 判定/条件覆盖； l 路径覆盖。 对源程序进行覆盖测试其实是一种动态的测试过程，测试过程中必须输入不同的数据进 行测试来达到覆盖测试的目标， 而为了测试一个用例必须编写很多辅助代码， 这样测试效率就 图 210 白盒测试
会降低。为了提高测试效率，测试工程师提出了白盒测试框架，希望将这些辅助的代码作为一 个固定的框架，这样就可以节约很多的时间，可以将主要的精力放在测试用例的设计上。对于 白盒测试框架在第 8 章详细介绍。 2.3.2 产品阶段的测试策略 产品阶段主要采取黑盒测试策略进行测试。黑盒测试也称功能测试，它是通过测试来检 测每个功能是否都能正常使用，是否符合规格说明书。在测试过程中，把程序看作一个不能打 开的黑盒子，如图 211 所示。在完全不考虑程序内部结构和内部特性的情况下，对程序接口 进行测试， 它只检查程序功能是否能按照需求规格说明书的规定正常使用， 程序是否能适当地 接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构， 主要针对软件界面和软件功能进行测试。 图 211 黑盒测试 黑盒测试是以用户的角度、从输入数据与输出数据的对应关系出发进行测试的，黑盒测 试主要发现以下几类错误： l 验证是否有不正确或遗漏的功能？ l 接口测试方面，验证输入能否正确地接受？输出的结果是否正确？ l 是否有数据结构错误或外部信息访问错误？ l 性能是否能够满足要求？ l 是否有初始化或终止性错误？ 从理论上讲，在进行黑盒测试过程中，需要采用穷举法进行测试，需要对全部功能所有 可能出现的情况进行覆盖测试， 不仅需要测试合法的输入条件还要测试不合法的输入条件， 并 且大多数的缺陷是通过输入不合法的测试条件测试出来的， 因此测试条件有无穷多种。 但在实 际测试过程中是不可能这样做的， 这样会导致测试成本太高， 所以需要制定测试方法和策略来 指导测试的实施，保证软件测试有计划地进行。 常用的黑盒测试设计方法有以下几种： l 等价类划分法； l 边界值测试法； l 错误推测法； l 因果图法； l 场景法； l 判定表法； l 正交实验法。
目前大部分企业将产品阶段的黑盒测试规划到系统测试阶段，但对于有项目外包业务的 企业来说，还需要经历验收测试阶段，主要验证产品是否达到需求说明书的要求，而完成的好 坏决定着外包主需要支付的外包成本。 在实际的过程中验收测试一般有两种形式： 一是企业组 织一个团队进行验收测试；二是找第三方测评机构进行评测。 随着软件测试的发展，黑盒测试形成了两个重要的分支：性能测试和自动化测试。在实 际工作中，一个好的产品或系统，不仅仅功能要正确，其性能也是质量表现的重要一环，所以 一些企业根据实际需要开展了性能测试。而自动化测试的目的更多的是为降低手工测试的成 本，因为纯粹功能的黑盒测试都是手工测试，是由手工不停地重复测试，这样测试工程师会出 现情绪不高的现象，并且激情会逐渐消退，因此一些企业就引进了自动化测试工具，将一些可 以使用自动化测试工具进行测试的功能实现自动化测试， 降低了测试成本， 提高了测试的全面 性，这些方法在产品测试阶段经常被用到。
