单元测试

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

详解： 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。
对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

优点：

1 它是一种验证行为（验证程序是否正确）
2 它是一种设计行为（可以让我们思考如何将程序设计的易调用和可测）
3 它是一种编写文档的行为
4 它具有回归性

意义： 经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。在软件开发的后期阶段，Bug的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用。无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。在提供了经过测试的单元的情况下，系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不是陷入充满很多Bug的单元之中不能自拔

集成测试

定义： 集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。

简介： 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的更大部分。方法是测试片段的组合，并最终扩展成进程，将模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。
集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。

内容： 根据IEEE标准集成测试划分为4个阶段：计划阶段，设计阶段，实现阶段，执行阶段（实施阶段）

计划阶段：输出集成测试计划
设计阶段：输出集成测试设计方案
实现阶段：输出集成测试用例、集成测试规程、集成测试代码、集成测试脚本、集成测试工具
执行阶段：输出集成测试报告

常用方案： 集成测试的实施方案有很多种，如自底向上集成测试、自顶向下集成测试、Big-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。

自顶向下测试：自顶向下集成（Top-Down Integration）方式是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。分两种方法：
第一：先深度：按照结构，用一条主控制路径将所有模块组合起来；
第二：先宽度：逐层组合所有下属模块，在每一层水平地沿着移动
自底向上测试：自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。（最常用）
核心系统测试：核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。
高频集成测试：高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。

与单元测试比较：
测试的单元不同
单元测试是针对软件的基本单元（如：函数）所做的测试，而集成测试则是以模块和子系统为单元进行的测试，主要测试接口间的关系。

测试的依据不同
单元测试是针对软件的详细设计做的测试，测试用例的主要依据也是详细设计。而集成测试是针对软件的概括设计做的测试，测试用例的主要依据则是概括设计。

测试空间不同
集成测试主要测试的是接口层的测试空间，单元测试主要测试的是内部实现层的测试空间。

测试使用的方法不同
集成测试关注的是接口的集成，和单元测试只关注单个单元，因此在具体测试方法上也不同。

系统测试

定义： 系统测试，英文是System Testing。是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善，能不能保证系统不受非法侵入。再例如，压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作

分类： 比较常见的、典型的系统测试包括恢复测试、安全测试、压力测试。

恢复测试：恢复测试作为一种系统测试，主要关注导致软件运行失败的各种条件，并验证其恢复过程能否正确执行。在特定情况下，系统需具备容错能力。另外，系统失效必须在规定时间段内被更正，否则将会导致严重的经济损失。
安全测试：安全测试用来验证系统内部的保护机制，以防止非法侵入。在安全测试中，测试人员扮演试图侵入系统的角色，采用各种办法试图突破防线。因此系统安全设计的准则是要想方设法使侵入系统所需的代价更加昂贵。
压力测试：压力测试是指在正常资源下使用异常的访问量、频率或数据量来执行系统。
步骤：制定系统测试计划 → 设计测试用例→执行测试系统→缺陷管理与改错

目标和原则：
目标：
1、确保系统测试的活动是按计划进行的；
2、验证软件产品是否与系统需求用例不相符合或与之矛盾；
3、建立完善的系统测试缺陷记录跟踪库；
4、确保软件系统测试活动及其结果及时通知相关小组和个人。

原则：
1、测试机构要独立；
2、要精心设计测试计划，包括负载测试、压力测试、用户界面测试、可用性测试、逆向测试、安装测试、验收测试；
3、要进行回归测试；
4、测试要遵从经济性原则。

验收测试

简介： 验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试，系统开发生命周期方法论的一个阶段，这时相关的用户和独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

常用方法：
1.正式测试：正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。
优点：

要测试的功能和特性都是已知的。
测试的细节是已知的并且可以对其进行评测。
这种测试可以自动执行，支持回归测试。
可以对测试过程进行评测和监测。
可接受性标准是已知的。
缺点:
要求大量的资源和计划。
这些测试可能是系统测试的再次实施。
可能无法发现软件中由于主观原因造成的缺陷，这是因为您只查找预期要发现的缺陷。

2 非正式测试：在非正式验收测试中，执行测试过程的限定不象正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不象正式验收测试那样组织有序，而且更为主观。大多数情况下，非正式验收测试是由最终用户组织执行的。
优点：

要测试的功能和特性都是已知的。
可以对测试过程进行评测和监测。
可接受性标准是已知的。
与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
缺点：
要求资源、计划和管理资源。
无法控制所使用的测试用例。
最终用户可能沿用系统工作的方式，并可能无法发现缺陷。
最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
用于验收测试的资源不受项目的控制，并且可能受到压缩。

3.Beta/β测试：在以上两种验收测试策略中，Beta 测试需要的控制是最少的。在 Beta 测试中，采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。Beta 测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不进行管理。Beta 测试是所有验收测试策略中最主观的。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
优点：

测试由最终用户实施。
大量的潜在测试资源。
提高客户对参与人员的满意程度。
与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
缺点：
未对所有功能和/或特性进行测试。
测试流程难以评测。
最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷。
最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
用于验收测试的资源不受项目的控制，并且可能受到压缩。
可接受性标准是未知的。
您需要更多辅助性资源来管理 Beta测试员。

测试内容：
通常可以包括：安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）、可靠性测试等。

过程：