软件测试级别详细介绍

一、组件测试

组件测试也称单元测试。作为软件生命周期的第一个测试级别，针对软件单元模块进行。

1. 组件测试模式
   组件测试有两种模式：测试驱动模式和代码先行模式：
   （1）测试驱动模式。把测试用例的设计提前到代码还没产生出来之前进行。强迫开发人员对即将编写的代码的程序进行需求方面的细节分析和代码
   设计方案的考虑。这种测试策略使得开发的习惯改变了，如敏捷开发中
   的测试。
   （2）代码先行模式。先编代码，后进行测试。这种方式较易实施和控制，可选择需要测试的重要代码进行测试，但对开发的习惯和流程改变不大。
2. 组件测试任务
   （1）组件内部模块接口测试
   （2）局部数据结构检测
   （3）路径检测
   （4）边界条件检测
   （5）出错处理检测

二、集成测试

集成测试阶段是每个模块完成组件测试后，需按照设计时确定的软件结构图，将它们连接起来，进行集成测试。

1. 集成测试策略
   集成测试一般包含两种不同的测试策略：非增量式测试与增量式测试。
   （1）非增量式测试
   非增量式测试采用一步到位的方法构造测试。在对所有模块进行测试后，
   按照程序结构图将各模块连接起来，把连接后的模块当成一个整体进行测试。
   集成测试的非增量方式如图1所示。被测试程序的结构由图1 (a) 表示，
   由6个模块组成。在组件测试时，根据它在结构图中所处的层级位置，对模块
   B和D配置了驱动模块（dx) 与桩模块（sx) , 对模块C、E、F只配备了驱动
   模块。模块A由于处在结构顶端，没有其他模块可调用，因此仅配置3个桩模
   块，以模拟被它调用的3个模块B、C和D, 如图6 (b) ©(d)、（e)(f)
   （g) 所示。分别进行单元测试以后，再按图1 (a) 的结构图形式连接起来，
   进行集成测试。
   　　　　　　　　　　　　　　图1 非增量式测试
   （２）增量式测试
   增量式测试的集成是逐步实现的，测试也是逐步实现的，可认为是将组件测试与集成测试结合起来。

三、系统测试

系统测试内容较多，另写文章介绍，详情请点此处跳转

四、确认测试

在集成测试完成之后，分散开发的软件各模块将关联起来，从而构成完整的软件产品（系统）。这时，软件的各模块之间接口存在的各种错误都已被消除，此时可以进行软件产品（系统）开发工作的最后一个部分，即确认测试。
确认测试可检验所开发的软件产品能否按用户（合同）提出的各项要求来进行。若经过确认测试，判定软件能够达到（合同）这一要求，则认为该开发完成的软件是合格的。因此，确认测试也常称为软件合格性测试。

1. 确认测试的准则
   软件确认是通过一系列证明软件功能与需求设计要求一致的（通常采用黑盒
   测试技术）测试来完成。通常，在软件产品（系统）的需求规格说明书中可能仅作原则性的规定，并不具体或者很详细，但在其后的测试阶段则需要有更详细、更具体的测试规格说明书做进一步的详细说明，列出所要进行的测试种类、定义发现与需求不一致的错误，而使用具体测试用例来开展实施测试过程。经过确认测试，可为已开发完成的软件产品做出是否合格的结论与其质量评价。
   （1）经过检验的软件功能、性能及其他要求均也满足需求规格说明书的规
   定，因而可被认为是合格的软件。
   （2） 经过检验发现与软件需求说明之间有相当的偏离，并得到软件各项缺陷的清单，对这种情况，可能在交付期之前要把发现的缺陷、错误与问题完全修改与纠正过来，通常，软件产品（或系统）的确认是需要经过开发者与用户协商过程，并以共同确定的确认测试的准则实施确认测试。
2. 程序修改后的确认测试
   （1）回归测试（regression testing)
   当软件或程序被发现缺陷或错误，或软件发生了变更时，程序都将被修改。在软件新的版本完成后，重复执行上一版本测试时的测试用例，即回归测试。回归测试是在程序被修改后重新测试的过程，也是一种确认测试，以检查本次程序修正后并确认没有引入新的缺陷。
   回归测试可运用于任何测试阶段：单元测试、集成测试、系统性测试和验收测试阶段。例如，在性能测试中，回归测试可通过重新执行所有测试用例检验软件经修改后性能的变化，回归测试的测试用例集合包括以下三种不同类型的测试用例。
   （1) 能测试软件的所有功能的代表性测试用例。
   （2) 专门针对可能会被修改的影响功能的附加测试。
   （3) 专门针对修改过的软件成分的测试。
   甚于测试风险与开发成本的平衡，回归测试常会：只重复测试计划中高优先级的测试；在功能测试中，忽视特定的变化（如特别的例子）， 只针对特定配置进行测试（如只对操作系统的一个版本测试）； 只针对特定子系统或某个测试级别进行测试。
   回归测试的规模或工作量有时会很大。因此，回归测试一般只测试出现错误
   模块的那部分。若对每一项修改或变更而言，将所有的程序都重新测试一遍，则测试工作效率将会降低。通常回归测试分为部分回归与完整回归。
   回归测试的测试用例须具备文档化，以备软件后期维护所使用。
   更详尽的回归测试点此处跳转
   （2) 变更测试
   见下文。
3. 配置与审查
   认测试的重要内容之一是配置审查工作，有时也称为配置审计。， 其目的在于确保已开发软件（产品）的所有文件资料均已编写齐全，这里包括已发布的软件版本（或称它为软件资产）等并得到分类编目，足以支持运行以后的软件维护工作。
   （1) 用户手册：用于指导用户如何安装、使用软件和获得服务与援助的相关
   资料，有时也包括软件使用的案例。
   （2) 操作手册：软件中进行各项使用操作的具体步骤和程序方法。
   （3) 设计资料：设计说明书、源程序以及测试资料（测试说朋书、测试报告）等。
   （4) 已发布的软件资产（程序）版本。

五、验收测试

验收测试是检验软件产品质量的最后一个过程，验收测试通常更突出客户的主导作用，同时也需开发人员参与。这里对验收测试的任务、目标及验收测试的组织与管理给出简要说明。常见的验收测试有如下形式：
（1）根据合同的验收测试，这是最重要的验收测试，通过验收判断合同的条款是否得到满足。
（2) 由用户和用户群组织的验收测试活动，为整个系统得到确认的最后的测试阶段。
（3) 验收测试通常有测试备份、灾难恢复、用户管理、维护项目和安全攻击的检查。
（4) 用户现场的测试（a测试与测试）。
验收测试范围取决于软件的风险评估。若开发的软件是用户定制的，则风险相对较高，需要进行全面的验收测试。若获得的是标准软件产品，并在一个类似环境中运行了很长的时间，则验收测试仅包括安装该系统，运行一些代表性的测试用例（User Case) 。

六、变更测试

软件开发项目在通过了验收测试后，即可交付用户或者发布了。但产品运行后，一般会使用数年或更长的时期。在此期间，软件可能会发生多次的缺陷、故障的修正、版本升级或功能扩展。每当发生这些情况，就会创建一个原产品的新版本（Version) 、对新的软件版本，自然也需要进行测试。这类测试可统称为变
更测试。

1. 软件维护测试
   在软件系统部署后，都需要一定的修正和改进，软件维护的目的不是维护产
   品操作能力或修复因使用过度而造成的损坏，在产品应用到新的运行操作环境（适应性维护）或在消除了缺陷（纠正性维护）时，都要进行维护。这种情况称为软件维护和软件支持。
   软件维护的策略是：对任何新的或变更的内容都应进行测试；为避免因变更而导致的副作用，系统否认其余部分应进行回归测试。
2. 软件新版本开发的测试
   软件的版本在不断的计划和变更中出现，产品的改进版本以一定时间间隔发布，每次版本发布后，项目重新启动，所有项目阶段重新进行，该方法称为迭代式软件开发。
   需要对软件产品的每个版本进行所有测试级别的测试，对任何新的软件改变都应重新测试。同时，为防止程序修改可能发生的副作用及产生新的缺陷，对系统的其余部分应进行回归测试。
3. 软件增量开发中的测试
   增量开发表明项目不是作为一个整体（可能比较大）来完成的，而是由一系列较小的开发或交付组成的，系统的功能性和可靠性需求随着时间的推移而不断增加。在已开发好的系统中加入新的增量，构成不断成长的系统。增量模型试图通过尽早地交付系统的可用功能，并得到用户反馈，以降低开发中的错误带来的系统风险。
   适应这种开发方式的测试是：持续的集成测试和回归测试。针对每个组件和增量都有可重用的测试用例，在测试中重用和更新这些测试用例。如若不然，软件的可靠性将会随时间的推移逐渐降低而不是增加。
4. 与变更测试有关的测试专业术语
   （1) 回归测试
   在软件（程序）中发现缺陷或错误并被修改后，或软件发生了变更后，需要
   重复执行上一版本测试时的测试用例，基于这种策略的测试称为回归测试。
   （2) 软件版本（号）