1. 软件测试基础

软件测试目的：发现软件中的错误。（软件测试只能证明软件中存在错误，不能证明软件没有错误。）

软件测试的对象：程序、数据、文档

软件测试原则：

溯源性原则：测试应当溯源到原始需求，而不是仅仅只盯着眼前。

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

独立性原测：应当避免开发工程师测试自己的程序，企业应设立独立的测试工程师岗位或测试部门去承担测试工作。

合理性原测：对软件进行完全测试是不可能的，无法对软件开展穷举式的测试。基本规律是测试成本与测试强度成正比，遗留缺陷与测试强度成反比。

不完全性原则：不管强度有多大，测试都不能暴露全部的缺陷，这是由测试自身决定了的。测试能做的是尽可能多地发现错误，但不能证明软件不再包含错误。

相关性原则：一个软件（模块）中被找到的缺陷越多，则这个软件（模块)中残留的缺陷也越多，或者说缺陷常常有聚集现象。这个原则提醒测试工程师对暴露错误多的模块应该加强测试。

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

风险性原测：测试虽然是为了降低或化解软件的质量风险，但必须认识到测试本身也是有风险的。这需要在做测试设计及构造测试用例时考虑如何规避和减少风险。

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

软件失效术语：

软件错误：在软件的生存期内不希望或不可接受的人为错误，其结果是导致软件缺陷

软件缺陷：存在于软件（文档，数据，程序）之中不希望或不可接受的偏差

软件故障：在软件运行过程中出现的一种不希望或不可接受的内部状态（关键字：内部）

软件失效：在软件运行时产生的一种不希望或不可接受的外部行为（关键字：外部）

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

缺陷探测率DDP：是另一个衡量测试工作效率的软件质量成本指标，计算公式DDP=Bugs(tester) / (Bugs(tester)+Bugs(customer))

需求规格说明书是导致软件缺陷的最大原因

软件测试结束的标志是bug强度曲线下降到预定的水平

测试执行的三个阶段:初测期,细测期和回归测试期

2. 软件测试模型

2.1 V模型

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

V模型局限性

• 测试在软件开发完成后进行，与“尽早的、不断的进行测试”相冲突
• 早期的问题（需求或者设计的问题）等到最后才发现，使得问题的解决成本大大增加

2.2 W模型

W模型：W模型是对V模型的一个重要改进，充分体现了尽早开展测试的原则，并将V模型中以发现缺陷为目标上升为保证软件质量为目标。W模型如图所示。

W模型实际上是两个V的叠加，一个V描述开发过程，另外一个V描述测试过程。但测试的起始时机不再是编码结束之后，而是从需求分析时开始，且与开发的每一个阶段活动同步进行。

W模型特点：

• 有利于尽早的发现问题，体现“尽早地和不断地进行软件测试”的原则
• 强调测试伴随着整个软件开发周期
• 在 V 模型中增加软件和开发阶段应同步进行的测试

W模型局限性

• 软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这就无法支持迭代、自发性以及变更调整。

2.3 H模型

H模型：改进了W和V模型高度依赖于开发的瀑布模型的缺陷，其特征如图所示：

H模型把测试活动从软件开发过程中独立出来，在软件过程的任何一个时间点上，只要测试条件满足即开展测试。测试的流程与其他流程是并行的。H模型比W模型更好的地方是能够兼顾测试的效率和灵活性，适合于各种规模及类型的软件项目。

2.4 敏捷测试模型

敏捷测试模型：敏捷测试源于敏捷开发。敏捷测试是敏捷开发的组成部分，需要与开发流程良好融合，其特征如图所示。

敏捷测试在整个敏捷开发过程中，需要与项目的其他人员甚至用户保持紧密协作，时刻关注需求变化并实施测试，以体现测试的时效性和适应性，这对测试人员有比较高的能力要求。

3. 软件测试的分类

3.1 按工程阶段划分

按工程阶段划分的测试：如果按软件开发的瀑布模型，测试活动也可以划分为几个主要的阶段，包括单元测试、集成测试、系统测试、确认测试和验收测试等。

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

需要从程序的内部结构出发设计测试用例

多个模块可以平行的独立的进行单元测试

• 集成测试是在软件的单元测试完成并修复了所发现的错误后，进行模块的集成时开展的测试。集成测试的主要任务是发现单元之间的接口可能存在的问题，目标是验证各个模块组装起来之后是否满足软件的设计文件要求。常见的集成策略有一次性集成和增量式集成。

涉及到的文档

• 概要设计文档
• 详细设计文档

组装时考虑的问题

• 连接各模块时，穿越模块接口的数据是否会丢失
• 一个模块的功能是否会对另一个模块的功能产生不利影响
• 各个子功能组合起来，是否能达到预期的父功能
• 全局数据结构是否有问题
• 每个模块的误差累积起来，是否会放大，以致达到不能接受的程度

模块组装方式

• 一次性组装（big bang）——全部一次性组装完成后再进行测试（适用于小软件）
  优点：操作简单，成本低
  缺点：难以定位测试时发现的问题
• 增值式组装
  【1】自顶向下的增值方式
  优点：容易发现分支的错误
  缺点：容易发生错误的底层模块要到最后才会测试发现
  【2】自底向上的增值方式
  【3】混合增值方式

完成标志：

• 成功执行了测试计划中规定的所有集成测试
• 修正了所发现的错误
• 测试结果通过了专门小组的评审或达到了业界的标准

• 系统测试的目标是确认软件的应用系统能否如预期工作并满足应用的需求。系统测试的对象是应用系统，除软件外可能还包括硬件、网络及数据，并且需要在一个比较真实的环境下进行。采用黑盒测试方式，并只能由独立的测试团队、用户或第三方机构进行。系统测试一般包括安全、强度、性能、可靠性等测试。
• 确认测试和验收测试焦点放在与软件交付相关的验证与确认上。确认测试和验收测试与系统测试相似，以需求规格说明为依据，采用黑盒测试方法。
• 验收测试主要是确认软件的功能、性能及其他特性是否满足软件需求规格说明书中列出的需求，是否符合软件开发商与用户签订的合同的要求。验收测试由用户主导，开发方参与。确认测试按用户参与程度不同分为：内部确认测试、α测试、β测试、验收测试。

3.2 按是否执行代码划分

按是否执行代码划分的测试：可以将测试分为动态测试和静态测试。

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

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

3.3 按测试实施主体划分

按测试实施主体划分的测试：可以将测试分为开发方（供方）测试（α测试）、用户方（需方）测试（β测试）和第三方（独立评价方）测试。

3.4 按是否关联代码划分

按是否关联代码划分的测试：可以分为白盒测试与黑盒测试，区别在于测试时测试人员是否知道软件是如何实现的。

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

黑盒测试是通过软件的外部表现行为进行测试的方法，它不关心程序的内部结构和如何实现，只关心程序的输入和输出，因此这种测试方法中软件像是被放于一个无法看见内容的黑盒子中。

灰盒测试介于白盒测试和黑盒测试之间，既关注黑盒测试方法中的输入输出，也在一定程度上关注程序的内部情况，是两种测试方法的一定融合。

3.5 按软件质量特性划分

按软件质量特性划分的测试：应根据国家标准中定义的软件产品质量的八个质量特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性和可移植性，相应地可以针对这些特性或它们的子特性开展测试，从而形成系统的功能性测试、性能效率测试、兼容性测试、易用性测试、可靠性测试等等。

3.6 按符合性评价要求划分

按符合性评价要求划分的测试：符合性测试是要通过测试去判定软件是否符合事先己经明确的文件性要求和约束，如标准、规范、技术指标、招投标文件、合同等。
符合性测试是有先决条件的，包括含有符合性准测的文件（标准、合同等），就绪的软件（软件的所有项均为可用状态，包括文档〉，以及软件的系统元素均己存在（测试者可以使用），因此符合性测试更类似于前述的系统测试、确认测试或验收测试。

3.7 回归测试

回归测试：发生在软件有变动的情况下，如果这种变动是对缺陷的修复，回归测试首先要验证缺陷是否确实被正确修复了，然后测试因此次缺陷修复而可能影响到的功能是否依然正确。如果软件的变动是增加了新的功能，回归测试除了验证新功能的正确性之外同样要测试可能受到影响的其他功能。即使变动是删减了软件中原来的某些功能，依然要通过回归测试来检查是否影响到保留的功能。