软件测试基础

• 1. 软件测试与软件质量
• • 1.1 什么是软件测试
  • 1.2 什么是软件质量
  • 1.3 软件测试与质量保证的区别
• 2. 软件测试的目的
• 3. 软件测试原则
• 4.软件测试对象
• 5.软件测试分类
• • 5.1 按照开发阶段划分
  • 5.2 按照测试实施组织划分
  • 5.3 按照测试技术划分
• 6.软件测试过程模型
• • 6.1 V模型
  • 6.2 W模型
  • 6.3 H模型
  • 6.4 其他模型
  • • 6.4.1 X模型 、前置测试模型
  • 6.5 测试模型的使用
• 7. 软件生命周期测试策略
• • 7.1 软件开发与软件测试
  • 7.2 软件测试策略

1. 软件测试与软件质量

1.1 什么是软件测试

测试（test）最早出于古拉丁字，它有“端”或“容器”的含义。在工业制造和生产 中，测试被当作一个常规的检验产品质量的生产活动。测试的含义为“以检验产品是否 满足需求为目标”。而软件测试活动包括了很重要的任务，即发现错误。

“软件测试”的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质 量进行评估。

随着人们对软件工程化的重视以及软件规模的日益扩大，软件分析、设计的作用越 来越突出，而且有资料表明，60%以上的软件错误并不是程序错误，而是分析和设计错 误。因此，做好软件需求和设计阶段的测试工作就显得非常重要。这就是我们提倡的测 试概念扩大化，提倡软件全生命周期测试的理念。

1.2 什么是软件质量

2001年，软件“产品质量”国际标准ISO 9126定义的软件质蛍包括“内部质量”、 “外部质量”和“使用质量”三部分。也就是说，“软件满足规定或潜在用户需求的能力” 要从软件在内部、外部和使用中的表现来衡量。

1.3 软件测试与质量保证的区别

软件测试人员的一项重要任务是提高软件质量，但不等于说软件测试人员就是软件 质量保证人员，因为测试只是质最保证工作中的一个环节。软件质量保证和软件测试是 软件质量工程的两个不同层面的工作。

质最保证（QA）：质量保证的重要工作通过预防、检査与改进来保证软件质量。QA的工作是软件生命周期的管理以及验证软件是 否满足规定的质量和用户的需求，因此主要着眼于软件开发活动中的过程、步 骤和产物，而不是对软件进行剖析找出问题或评估。

软件测试：测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员必须假设软件存在潜在的问题，测试中所作的操作是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。对测试中发现的问题的分析、 追踪与回归测试也是软件测试中的重要工作，因此软件测试是保证软件质量的一个重要环节。

2. 软件测试的目的

测试的目的，是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷， 通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造 成的隐患所带来的商业风险。

3. 软件测试原则

• 1.所有的软件测试都应追溯到用户需求。
• 这是因为软件的目的是使用户完成预定的任务，并满足用户的需求，而软件测试所 揭示的缺陷和错误使软件达不到用户的目标，满足不了用户需求。
• 2.应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
• 3.完全测试是不可能的，测试需要终止。
  ①输入量太大：
  ②输出结果太多：
  ③路径组合太多。
  一个适度规模的程序，其路径组合近似天文数字，对于每一种可能的路径都执行一 次的穷举测试是不可能的。此外，测试也是有成本的，越是测试后期，为发现错误所付 出的代价就会越大，因此也要根据测试错误的概率以及软件可靠性要求，确定最佳停止 测试时冋，我们不能无限地测试下去。
• 4.测试无法显示软件潜在的缺陷。
• 进行测试是可以査找并 告发现的软件缺陷和错误，但不能保证软件的缺陷和错误 全部找到，继续进一步测试可能还会找到一些，也就是说测试只能证明软件存在错误而 不能证明软件没有错误。
• 5.充分注意测试中的群集现象 (二八定律)
• 经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成 正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。
  在所测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性 现象，已为许多程序的测试实践所证实。例如，在美国IBM公司的OS/370操作系统中， 47%的错误仅与该系统的4%的程序模块有关。这种现象对测试很有用。如果发现某一程 序模块似乎比其他程序模块有更多的错误倾向，则应当花费较多的时间和代价测试这个 程序模块。
• 6.程序员应避免检査自己的程序。
• 基于心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自 己的工作；由于思维定势，人们难于发现自己的错误。因此，为达到测试目的，应由客 观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试。
• 7.尽量避免测试的随意性。
• 应该从工程的角度去理解软件测试，它是有组织、有计划、有步骤的活动。

4.软件测试对象

根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。 软件测试应贯穿于整个软件生命周期中。在整个软件生命周期中，各阶段有不同的测试 对象，形成了不同开发阶段的不同类型的测试。需求分析、概要设计、详细设计以及程 序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格 说明以及源程序，都应成为“软件测试”的对象。

为了把握各个环节的正确性，人们需要进行各种验证和确认(verification & validation)工作。

验证(verification)是保证软件正确实现特定功能的一系列活动和过程，目的是保 证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。

确认(validation)是保证软件满足用户需求的一系列的活动和过程，目的是在软件 开发完成后保证软件与用户需求相符合。

验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。

5.软件测试分类

5.1 按照开发阶段划分

按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和 验收测试

? 单元测试。
单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验 的测试工作。其目的在于检査每个程序单元能否正确实现详细设计说明中的模块功能、 性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从 程序的内部结构出发设计测试用例.多个模块可以平行地独立进行单元测试。

? 集成测试。
集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序 的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设 计要求的程序部件或整个系统。
软件集成的过程是一个持续的过程，会形成很多个临时版本，在不断的集成过程中， 功能集成的穏定性是真正的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序 主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。

?确认测试。
确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确 认测试是检测与证实软件是否满足软件需求说明书中规定的要求。

? 系统测试。
系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进 行的测试。系统测试是在真实或模拟系统运行的环境下，检査完整的程序系统能否和系 统（包括硬件、外设、 络和系统软件、支持平台等）正确配置、连接，并满足用户需求。

? 验收测试。
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与 评审，决定是否接收或拒收系统。

5.2 按照测试实施组织划分

按照测试实施组织划分，软件测试可分为开发方测试、用户测试（卩测试）、第三方 测试。

?开发方测试。

通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据，证实软件的 实现是否满足规定的需求。验证测试是在软件开发环境下，由开发者检测与证实软件的 实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后,.开 发方对要提交的软件进行全面的自我检査与验证，可以和软件的“系统测试”一并进行。

?用户测试。

在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自 己预期的要求。通常情况用户测试不是指用户的“验收测试”，而是指用户的使用性测试, 由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。
β测试通常被看成是一种”用户测试” β测试主要是把软件产品有计划地免费分发 到目标市场，让用户大量使用，并评价、检査软件。通过用户各种方式的大量使用，来 发现软件存在的问题与错误，把信息反馈给开发者修改。|3测试中厂商获取的信息，可 以有助于软件产品的成功发布。

?第三方测试。

介于软件开发方和用户方之间的测试组织的测试。第三方测试也称为独立测试。软 件质量工程强调开展独立验证和确认（IV&V）活动。IV&V是由在技术、管理和财务上 与开发组织具有规定程度独立的组织执行验证和确认过程。软件第三方测试也就是由在 技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。一般情况下是 在模拟用户真实应用环境下，进行软件确认测试。

5.3 按照测试技术划分

按照测试技术划分：白盒测试、黑盒测试、灰盒测试。

也可划分为静态测试和动态测试。

• 静态测试是指不运行程序，通过人工对程序和文档进行分析与检査：静态测试技 术又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序 源代码等进行非运行的检査，静态测试包括：走查、符 执行、需求确认等。

• 动态测试 是指通过人工或使用工具运行程序进行检査、分析程序的执行状态和程序的外部表现。

• 白盒测试
  通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个 透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都 是正确的，检査软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。

• 黑盒测试（功能测试）
  通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒 子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是 检査样序是否按照需求规格说明书的规定正常实现。

• 灰盒测试
  介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时 也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现 象、事件、标志来判断内部的运行状态。
  灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识和 操作环境。它在系统组件的协同性环境中评价应用软件的设计。

6.软件测试过程模型

6.1 V模型

优点：

如果测试文档能尽早提交，那么就有了更多的检査和检阅的时间，这些文档还可用 于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面对规格说明书的挑战。这意味着测试不仅仅是评定软件的质堡，测试还可以尽可能早地找出 缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和 难度，这将可以显著地减少总体测试时间，加快项目进度。

缺点：

W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码 等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要有严格 的指令表示上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代、自发 性以及变更调整。对于当前很多文档需要事后补充，或者根本没有文档的做法下（这已 成为一种开发的文化），开发人员和测试人员都面临同样的困惑。

6.3 H模型

• 软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。
• 测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程 中，测试配置只是软件配置的一个子集。
• 测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。

测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。 如果发现出错的数据，就意味着软件有错误，就需要开始排错(调试)。即对已经发现的 错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的 文档一般都要经过再次测试，直到通过测试为止。

2.分析设计阶段

分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、 概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。

• 需求说明书评测
• 需求说明书评测作为需求分析阶段工作的复査手段，应该对功能的正确性、完整性 和清晰性，以及其他需求给予评测。
• 概要设计说明书评测
• 软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省 开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的 可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列 设计质量的评测，以便及时发现和解决在软件设计中出现的问题，防止把问题遗留到开 发的后期阶段，造成后患。
• 详细设计说明书评测
• 详细设计说明书的评测标准和评测内容与概要设计说明书基本相同
• 软件编码规范评测
• 程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表 现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码 规范评测也是围绕这四个方面展开。

3.开发阶段

1. 单元测试的内容。

在进行单元测试时，测试者需要依据详细设计说明书和源程序淸单，了解该模块的 I/O条件和模块的逻辑结构，主要釆用白盒测试的测试用例，辅之以黑盒测试的测试用 例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的 和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检査和严格的代码 审査。

在单元测试中进行的测试工作如图所示,需要在五个方面对所测模块进行检査。

①模块接口测试
在单元测试的开始，应对通过所测模块的數据流进行测试。如果数据不能正确地输 入和输出，就谈不上进行其他测试。
调用 所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配

③路径测试。 常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序：运算的方
式错，即运算的对象彼此在类型上不相容；算法错；初始化不正确；运算精度不够；表 达式的符 表示不正确。

④错误处理测试。 比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦
程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。这种出错处理也应当是
模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺
陷：出错的描述难以理解：出错的描述不足以对错误定位，不足以确定出借的原因；显
示的错误与实际的错误不符；对错误条件的处理不正确：在对错误进行处理之前，错误 条件己经引起系统的干预等。

⑤边界测试。 在边界上出现错误是常见的。例如，在一段程序内有一个n次循环，当到达第n次
重复时就可能会出错。另外，在取最大值或最小值时也容易出错。因此，要特别注意数
据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔 细地选择测试用例，认真加以测试。

模块测试针对的程序规模较小，易于査错；发现错误后容易确定错误的位置， 易于排错，同时多个模块可以并行测试。做好模块测试可为后续的测试打下良好的基础。

模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用 一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：

• 驱动模块(driver) ——相当于所测模块的主程序。它接收测试数据，把这些数据传 送给所测模块，最后再输出实测结果。
• 桩模块(stub)——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可
  以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

所测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”

2. 集成测试的内容
   通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

组装时需要考虑的问题。
①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失：
②一个模块的功能是否会对另一个模块的功能产生不利的影响；
③各个子功能组合起来，能否达到预期要求的父功能：
④全局数据结构是否有问题：
⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。

模块组装成为系统的方式

模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。

①一次性组装方式(big bang).

使用这种方式，首先对每个模块分 别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。

但是由于程序中不可避免地存在涉及模块间接口、全局数据结构方面的问题， 所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。 査错和改错都会遇到困难。

②增殖式组装方式。

这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模 块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问 题。最后通过增殖逐步组装成为要求的软件系统。

（1）自顶向下的增殖方式。
自顶向下增殖方式的缺点是需要建立桩模块，能够较早地发现主要控制方面的问题

（2）自底向上的增殖方式。
缺点是“程序一直未能作为一个实体存在，直到燉后一个模块 加上去后才形成一个实体”。由于涉及到复杂算法和其正输入瀚出的模块最先得到组装和测试，可以把最 容易出问题的部分在早期解决。

（3）混合增殖式测试。