V模型的测试级别

所谓的 V 模型是软件测试过程中的一个重要模型，由于其模型构图形似字母 V，所以又称软件测试的 V 模型，这个会在《软件测试过程模型》中详细讲到。

• 单元测试（Component Testing/Unit Testing）

单元测试也称为组件测试，是指对软件中的最小可测试单元进行检查和验证，如一个模块，一个过程等等。它的目的是检验软件基本组成单元的正确性。

对于单元测试中单元的含义，一般来说，要根据实际情况去判定，如 C 语言中单元指一个函数，Java 里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分隔离的情况下进行测试。

单元测试是编写一小段代码，用于检验被测代码的一个很小很明确的功能是否正确，编写的这一小段代码被称为桩或驱动。

桩（Stub）：是指模拟被测试的模块所调用的模块。 驱动器（Driver）：代替某个软件组件来模拟控制和调用其他组件或系统的软件或测试工具。

一个好的单元测试将会在软件开发阶段发现大部分缺陷，并且修改它们的成本也很低，因为在软件开发后期，修改缺陷会变得很困难，并且要耗费大量的时间和开发费用。

一个单元测试人员需要具备一些测试知识，比如代码编写能力，基本的测试技能，部分单元测试工具的使用等。

单元测试的缺点是无法发现一些接口问题和大环境的缺陷，但接口测试的问题可以在集成测试阶段发现。那么接下来看看什么叫集成测试。

• 集成测试（Integration Testing）

集成测试是将通过测试的单元模块组装成系统或子系统再进行测试，目的是对组件之间的接口进行测试，以及测试一个系统内不同部分的相互作用。

比如操作系统、文件系统、硬件或系统之间的接口，集成测试是单元测试的逻辑扩展。它最简单的形式是：把两个或多个已经测试过的单元组合成一个组件，测试它们之间的接口。集成测试的目标是确保单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。

集成测试的实施方案有很多种，如自底向上集成测试和自顶向下的集成测试等。它所测试的内容包括单元间的接口以及集成后的功能。

自底向上的集成是从最底层模块（即叶子节点）开始，按照调用图的结构，从上而下，逐层将各模块组装起来。在从下而上的集成测试环境中，需对哪些未经集成测试的模块开发驱动模块。

自顶向下的集成是从主控模块（主程序，即根节点）开始，按照系统程序结构，沿着控制层从上而下，逐渐将各模块组装起来。在从上向下的集成测试过程中，需对哪些未经集成的模块开发桩模块。在集成过程中，可以采用宽度优先或深度优先的策略向下推进。

那么什么样的人才能做集成测试呢？需要具备开发技能、具备有关组件间的交互知识，还要具备一些测试基础技能。

集成测试也有其自身的缺陷，比如组件外的缺陷无法被发现。另外，如果程序对整个系统的需求不满足，这样的缺陷测试不出来，那么就需要与系统测试相结合，接下来看看什么是系统测试。

• 系统测试（System Testing）

系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。

系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。

系统测试主要依据《系统需求规格说明书》文档进行测试。主要测试的是系统需求、整个系统的功能和非功能的需求。那么做系统测试的测试人员，需要具备测试技术、要熟悉软件系统的需求，还有性能测试知识和工具的使用。

系统测试也有缺陷，没有实现或者没有完全实现用户的隐性需求，在系统测试中是无法发现的。

• 验收测试（Acceptance Testing）

验收测试是在软件产品完成了功能测试和系统测试之后，产品发布之前所进行的软件测试活动，是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是建立对系统、系统的某部分或特定的系统非功能特征建立信心。

它在系统测试的后期，以用户测试为主，或有测试人员等质量保证人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。一般是根据产品说明书严格检查产品，逐字逐句对照说明书上对软件产品做出的各方面要求，确保所开发的软件产品符合用户的各项要求。

验收测试有下面几种典型的类型：

• 用户验收测试

用户验收测试一般是验证由商业用户使用一个系统的可用性。通常由用户来组织这些测试，并基于商业过程和典型的用户场景选择测试用例。

• 运行（验收）测试

运行（验收）测试由系统管理员来进行验收而开展的相关测试，测试内容主要包括：系统备份/恢复测试、灾难恢复测试、用户管理测试、维护任务测试、安全漏洞阶段性检查。

• 合同和法规性验收测试

合同验收测试根据合同中规定的生产客户定制软件的验收准则，对软件进行测试。应该在合同拟定时定义验收准则。法规性验收测试根据必须要遵守的法律法规来进行测试，比如政府、法律和安全方面的法律法规。

• α 测试和 β 测试

α 测试是由用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试，试图发现错误并修正。目的是评估软件产品的 FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。 α 测试不能由程序员或测试人员完成。 β 测试是由软件的最终用户在一个或多个客户场所进行的测试。经过 α 测试的版本被称为 β 版本，同 α 测试一样都是由潜在的客户进行测试，而不是由产品的开发者进行测试，不同的是，β 测试开发者通常不在现场。 α 测试和 β 测试都不能替代内部的系统测试。只有当系统测试已经证明软件足够稳定后，才可以将新产品提交给潜在的客户做验收测试。 有些组织也可能使用不同的术语，比如在系统正式移交给客户之前或之后进行的测试分别称为工厂验收测试和现场验收测试等。

要注意的是，在开发方将软件提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了足够的正式测试。用户在按照合同接收并清点开发方的提交物时，要查看开发方提供的各种审核报告和测试报告内容是否齐全，再加上平时对开发方工作情况的了解，基本可以初步判断开发方是否已经进行了足够的正式测试。