作者：Gakki

---

考点（分值：4 - 5 分）

• 软件测试的基本概念
• 软件测试的原则
• 软件测试模型
• 软件测试的分类

1、软件测试的基本概念

1.1、基本概念

• 软件测试定义的发展：认证 —— 证伪 —— 软件质量。

• 软件测试的目的是 "保证软件质量"。具体来讲就是要保证软件或系统符合相关的法律法规、技术标准和应用需求，降低软件的产品风险及应用风险。

• 需要指出的是，是否符合应用需求并不是软件测试的唯一目的，测试必须考虑软件对法规的符合性、标准的符合性以及商务要求等方面的符合性。

• 软件测试的对象是软件，包含了程序、数据和文档；但孤立的软件无法进行全面的测试，特别是动态的测试。大量的测试活动需要支持测试的环境，包括软件的运行环境和测试环境，这一定会涉及除了被测对象软件之外的软件和硬件环境，数据环境，甚至是应用环境，这些环境不仅对测试提供支持，也会影响到一些测试的结果。

• 对于测试组织者和实施者第一需要明确测试对象的边界，第二需要认识到环境对测试的影响，以获得适当环境下的真实测试结果。

• 验证和确认：验证是判断生产者是否（按照需求规格）正确的构造软件，或者说是不是正确的做事。而确认是检验软件是否有效，是否满足用户的预期用途和应用需求。由于需求规格不一定真实体现了用户的特定预期用途或应用要求，通过验证的软件不一定能够通过确认。

• 软件失效术语：

  • 软件错误是指在软件生命期内不希望或不可接受的人为错误，其结果是导致软件缺陷的产生；（人为）
  • 软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差；（偏差）
  • 软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态；（内部状态）
  • 软件失效是指软件运行时产生的一种不希望或不可接受的外部行为。（外部行为）

• 软件在需求分析和设计阶段同样会陷入缺陷，而且占比均超过编码阶段。在需求分析阶段引入的缺陷比例通常超过 40 %，在设计阶段映入的缺陷也在 30 %以上，而编码产生的缺陷低于 30 %。

• 一般而言，在软件工程活动中，缺陷从产生到发现的间隔时间越短，修复的代价越小，而缺陷从一个工程阶段跨入后一个工程阶段时，修复的代价将以指数级增长。正因为如此，软件工程活动中要努力做到缺陷早发现早排除，对应的测试活动就不能是编码完成之后的一个阶段性工作，而是贯穿软件工程的各个阶段，力争通过测试尽早地发现缺陷。

• 软件质量的定义：在规定条件下使用时，软件产品满足明确的或者隐含的要求的能力。

• 软件质量包括了软件测试，软件测试是保证软件质量的一种措施或手段。

• 测试用例的要点

  1. 测试用例是测试人员针对特定目标而设计或开发出来的，有非常强的目的性；
  2. 测试用例将体现软件的某一个具体运行实例或场景，包括输入的测试数据，执行条件，逻辑过程以及预期的逻辑结果
  3. 测试用例须提供准确的判定准则，依照该用例实施测试获得实际结果时如何判定。

• 测试用例对于测试实施来说有非常重要的作用。首先测试用例是测试实施的依据，测试人员应该按照设计好的用例开展测试，获取结果并进行判定；其次测试用例是根据测试系统严密设计出来的测试任务描述，在测试用例的指导下可以保证测试规范性，提高测试效率。避免测试的随意性和盲目性，从而保证测试的质量；此外测试用例还是软件企业的一类资产，具有相当大的价值。

• 测试用例包含：用例的标识，名称，说明，环境配置，操作过程，各种条件，评价准则，以及建立用例的人员和时间等信息，其中操作过程要描述每一步操作的输入数据，过程说明，预期结果，通用准则等。

测试用例模板

• 测试脚本通常是指一个特点测试的可以被自动化工具执行的一系列指令，脚本可以在工具中通过录制测试操作生成，也可以使用脚本语言直接编写。脚本虽然同样可以用于测试，并支持自动化的测试，但并没有测试用例所包含的那么丰富的信息。

• 测试策略是一套方法论，可以平衡测试时间、测试技术、测试人力、质量要求之间的关系，达到最佳测试效果，从而实现最大化的测试投入产出比。因此 在测试前期规划时，测试策略是计划中的重要内容，是测试最终成功的关键因素之一。

• 软件测试策略可以划分为基于分析（如风险分析、需求规划分析）的策略、基于模型（如业务模型、软件质量模型、系统性能演化模型）的策略、基于标准规范（如 GB/T 25 000.51 标准、软件验收标准）的策略以及基于自动化的回归测试测试等等。

• 测试策略的输入包括如下方面（了解）：

  • 测试所需软硬件资源的详细说明；
  • 针对测试和进度约束，需要人力资源的角色和职责；
  • 测试方法，测试标准，完成标准；
  • 目标系统的功能性，非功能性需求，技术指标；
  • 系统局限（即系统不能够满足的需求）

• 测试策略的输出包括如下方面（了解）：

  • 已经批准的测试策略文档，测试用例和测试计划。
  • 需要解决方案的测试项目。

• 策略策略的过程为（了解）：

  • 确定测试的需求
  • 评估风险并确定测试优先级
  • 确定测试策略

1.2、软件测试的原则

1. 溯源性原则

   • 不同阶段的测试有不同的阶段性的测试目标，但汇集起来后的总目标是保证软件质量，测试应该溯源到原始需求，而不是仅仅只盯着眼前。

2. 工程性原则

   • 测试不仅仅只是某一个工程的活动，而是贯穿软件生产的各阶段。需要以工程化的思想和方法来实施，需要尽早的按计划的来开展测试，甚至是预防性测试。

3. 独立性原则

   • 应该避免开发人员测试自己的程序，企业也应该设立独立的测试工程师岗位，或者设立测试部门去完成测试的工作。

4. 合理性测试

   • 对软件进行完整性的测试是不可能的，无法对软件进行穷尽的测试，基本规律是测试成本和测试强度成正比，预留的缺陷和测试强度成反比。

5. 不完全性原则

   • 不管强度有多大，测试都不能暴露所有的缺陷，这个是由测试自身所决定的，测试能做的是尽可能多的发现错误，但不能证明软件不再包含错误。

6. 相关性原则

   • 在一个软件或一个模块中发现的缺陷越多，则在这个软件或者模块中剩下的缺陷也越多。这就是说缺陷具有的积聚现象，这个测试原则就提醒测试工程师，暴露的缺陷越多的模块，就越发需要加强测试。

7. 可接受性原则

   • 测试的直接目标是发现软件缺陷，但更进一步的目标是修复发现的缺陷。在各方可以接受的前提下，可以允许某些缺陷遗留在软件当中，应该交给恰当的人员或者会议来进行决策。

8. 风险性原则

   • 测试虽然是为了降低或者化解软件的质量风险，但必须也要意识到测试其本身也是存在风险的。这就需要我们在做测试设计和构造测试用例的时候，考虑如何规避和减少风险。

9. 测试停止准则

   • 测试超过了预定时间；执行了所有的测试用例，没有发现新的故障；采用特定的测试用例设计方案；查出某一预定数量的故障；单位时间内查出的缺陷数量少于预定量。

1.3、软件测试模型（考每个模型的区别点）

1. V模型
   • 软件测试的 V 模型对应开发的瀑布模型。测试就成为了一个阶段性的工作。是最为典型的 V&V 活动。测试 V 模型如图所示。

V模型

• 在 V 模型中，测试活动对应于瀑布模型的每一个工程阶段，即单元测试对应编码、集成测试对应详细设计、系统测试对应概要设计、验收/交付测试对应需求分析。

1. W 模型
   • 它是测试模型的一个重要的改进，充分体现出了尽早开始测试的原则。并将 V 模型中以发现缺陷为目标改进为保证软件质量为目标。
   • W 模型其实就是两个 V 模型的叠加，一个 V 用来描述开发过程，另一个 V 用来描述测试过程；但是测试的开始时机不再是编码结束后，而是在需求分析的时候就要开始，且与开发的每一个活动都是同步进行。

W 模型

1. H 模型
   • 它改进了 V 模型和 W 模型高度依赖于软件开发瀑布模型的缺陷，该模型把测试活动从软件开发活动中独立了出来，该软件过程的任何一个时间点上，只要测试条件满足即可开展测试。测试的流程与其他流程是并行的， H 模型相比于其他模型（如 W 模型）的最大的优势在于可以兼顾测试的效率和灵活性。适用于各种规模和类型的软件项目。

H 模型

1. 敏捷测试模型
   • 该模型源于敏捷开发，敏捷测试是敏捷开发的组成部分，需要与开发流程相互融合。
   • 敏捷测试在整个测试流程当中，需要与项目的其他开发人员甚至是用户保持紧密协作，时刻关注需求变化并实施测试，以体现测试的实效性和适应性，它对测试人员有比较高的能力要求。

敏捷测试模型

1.4、软件测试的分类

1. 按工程阶段划分的测试（重点）

   • 如果按软件开发的瀑布模型，测试活动可以划分为单元测试，集成测试，系统测试，确认测试，验收测试。

   • 单元测试
     它是最小单位的测试活动，也称为模块测试。在封闭的单元内部进行的测试，关注一个单元是否正确的实现了规定的功能，逻辑是否正确，输入输出是否正确，从而寻找模块内部存在的各种错误。单元测试的测试内容包括有：模块接口测试、局部数据结构、模块内路径、边界条件和错误处理。单元测试的依据是详细设计文档。可能需要构造驱动模块和庄模块来完成测试活动。

   • 集成测试
     集成测试是在单元测试完成并修复的基础之上，进行模块的集成时开展的测试。集成测试只要的任务就是发现单元之间的接口可能存在的问题，目标是验证各个模块组装起来之后，是否满足软件的设计文件要求。常见的集成设计策略有一次性集成和增量式集成两种。增量式集成分为：自底向上、自顶向下、混合式等。没有自中间到两端集成。

   • 系统测试
     目标是确认软件应用系统能否按照预期的工作并满足应用的需求。系统测试的对象是应用系统，除了软件以外可能还包括了硬件网络和数据，并且需要在一个比较真实的环境下进行。采用的测试方法主要是黑盒测试。系统测试只能由独立的测试团队，用户或者第三方来实施进行。系统测试一般包括安全，性能，强度可靠性等等。

   • 确认测试与验收测试他们把焦点放在与软件交付相关的验证与确认上，确认测试和验收测试与系统测试相似，以需求规格说明为依据，采用黑盒测试方法。

   • 验收测试
     主要确认软件的功能与性能，以及其他特征是否满足软件需求规格说明书中列出的需求，是否符合软件开发商与用户签订的合同的要求。验收测试是用户主导的，由开发商参与。

   • 确认测试
     确认测试按照用户参与程度不同，可以分为内部确认测试，α 测试，β 测试，验收测试。所以说验收测试可以是确认测试中的一个部分。

注：无论何种测试方式，都必须事先明确验收方法，制定测试计划规定要做的测试种类，并制定相应的测试步骤和具体的测试用例。测试完成后要明确给出验收通过或不通过的结论。

2. 按是否执行代码来分

   • 测试可以分为动态测试和静态测试两种。

   • 动态测试
     就是通常意义上的测试。通过运行软件来发现错误，或者验证程序是否符合预期要求。

   • 静态测试
     静态测试是不运行软件的，只做检查和审核。测试对象包括需求文档，设计文档，产品规格说明书和代码等等。对各类文档的测试主要通过评审的方式来进行，对代码采用走查和代码审查的方式。

3. 按测试实施主体来划分

   • 可以将测试分为开发方测试，用户方测试和第三方独立机构的测试。

4. 按是否关联代码来划分

   • 可以分为白盒测试、黑盒测试和灰盒测试。区别就在于测试实施的时候测试人员是否知道软件是如何实现的。

   • 白盒测试
     也称为结构化测试，逻辑驱动测试或者基于代码的测试，测试时完全清楚被测程序的内部结构，语句及工作过程。

   • 黑盒测试
     黑盒测试通过软件的外部表现行为进行测试的方法，它不关心程序的内部结构和如何实现，只关心程序的输入输出；因此这种方法就好像黑盒一样完全看不到里面的处理过程。

   • 灰盒测试
     它基于黑盒测试与白盒测试之间，既关注黑盒测试方法中的输入与输出，在一定程度上也关心程序的内部实现状况，是这两种方法的融合。

5. 按软件质量属性特征划分

   • 按照软件的八个质量属性来划分，可以分为功能性，性能效率性，兼容性，易用性，可靠性，信息安全性，维护性和可移植性。相应的可以根据这些特征或者其子特征来开展测试。从而形成系统的功能性测试，性能效率测试，兼容性测试，易用性测试，可靠性测试等。

6. 按符合性评价要求划分的测试

   • 符合性测试是要通过测试去判断软件是否符合事先已经明确的文件性要求和约束。例如有标准，规范，技术指标，招投标文件，合同等。

   • 符合性测试是有先决条件的，包括含有符合性准则的文件，就绪的软件，以及软件的系统元素均以存在（测试者可以使用），因此符合性测试更加类似于前述的系统测试，确认测试和验收测试。

7. 回归测试：
   • 发生在软件有变动的情况下，如果这种变动是对缺陷修复的话，回归测试首先就要验证缺陷是否已经被正常修复了，然后测试修复缺陷而可能影响到的功能是否依然正确；如果软件的变动是增加了新的功能，回归测试除了验证新的功能之外，同样要测试可能受到影响的其他功能。即便是删除了软件的某个功能，依然要通过回归测试来检查是否影响到保留的功能。
   • 一方面测试修改的部分有没有问题，另外一方面测试修改的部分所影响的部分有没有问题。