瀑布模型
用户需求、需求分析、概要设计、详细设计、编码和实现、测试、运行维护
瀑布模型的阶段
用户需求：用户需求一般由用户提出，系统人员或者产品市场人员从客户或将来的系统用户中收集原始项目的信息和需求；
需求分析：对用户需求进行可行性分析，并对用户需求和要求进行详细描述，并最终得到管理层和客户的批准。通过需求分析，定义了开发系统的目的和需要实现的特性和功能；
概要设计：明确系统的框架、系统的模块数量，以及各个模块之间的接口、数据结构，以及可能的网络环境支持和后台数据库等。简单的说，就是将需求映射到新系统的功能和框图上，从而可以对每个子系统经行独立的开发；
详细设计：细化概要设计的框架，定义每个子系统的任务、行为、内部机构以及于其他子系统的接口；
编码和实现：通过编码语言实现所有已经定义的单元，比如模块、单元和类等；
测试：作为开发周期的一个阶段，主要是指测试执行活动；
运行测试：软件系统或者产品发布，在用户中使用，以及根据反馈进行必要的维护活动；
瀑布模型的特点：
软件测试是开发过程中的一个阶段，对产品质量进行的最后检查；
在客户需求明确，以及开发过程中没有频繁的需求变更，比较适合瀑布开发模型；
假如需求不明确，或者需求经常发生变更，采用瀑布模型是非常不适合的；
V模型
单元测试：验收软件的单元是否按照单元规格说明（详细设计说明）正确执行，既保证每个最小的单元能够正常运行。单元测试一般由开发人员来执行，首先设定最小的单元，然后统通过设计相对应的测试用例来验证各个单元功能的正确性；
集成测试：检查多个的单元是否按照系统概要设计描述的方式协同工作。集成测试的主要关注点是系统能够成功编译，实现了主要的业务功能，系统各个模块之间数据能够正常通信等；
系统测试：验证整个系统是否满足需求规格说明；
验收测试：从用户的角度检查系统是否满足合同中定义的需求或者用户需求；
V模型的特点
V模型体现的主要思想是开发和测试同等重要，左侧代表的是开发活动，而右侧代表的是测试活动；
V模型针对每个开发阶段，都有一个测试级别与之相对应；
测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应；
V模型适用于需求明确和需求变更不频繁的情形；
非线性模型
瀑布模型和V模型，都是属于线性模型的范畴，他们的重要特点就是线性的，即前置条件是软件系统具有比较明确的需求，且没有频繁的需求变更；
需求是可变的：某些应用软件的需求与外部环境、公司经营策略或经营内容等密切相关，这些都是经常调整和变化，因此需求也是变化的；
需求是模糊的：许多用户对他们的需求最初只是模糊的概念，想要求一个对需求只有初步设想的人准确无误的说出全部需求，显然是不切实际的；
用户和开发者难于沟通：大多数用户和领域专家不熟悉计算机和软件技术，而软件开发人员往往不熟悉用户的专业领域，开发人员和用户之间很难做到完全沟通和互相理解，在需求分析简短做出的瀛湖需求常常是不完整、不正确的；
增量模型
增量模型的特点
增量模型的每个阶段交付满足客户需求的一个子集的可运行产品。因此可以较好的适应变化，以及控制风险；
增量的一个缺点是后面并入的构件不能破坏已构造好的系统部分，这需要软件具备开放式的体系结构；
在开发构成中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于线性模型，但也很容易退化为边做边改模型，从而是软件过程控制失去整体性；
迭代模型
迭代模型的特点
迭代模型包括了一系列的迭代，每一个迭代都包括一些或者许多的开发活动（需求、分析、设计、实现等等）；
每个后续的迭代都建立在前一个迭代的基础上以使系统得到发展和细化，直到最终产品被完成；
迭代模型中集成不是在项目的尾声进行的“大动作”，每一次迭代都以集成构建系统各部分结束，这样不断的积累将使日后的返工最小化；
好的测试应该具备
每个开发活动都有相对应的测试活动；
每个测试级别都有其特有的测试目标；
对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析合设计；
在开发生命周期中，测试人员在文档初稿阶段就应该参与文档的评审；
单元测试
基本含义
单元测试的对象可以是模块、类、函数和对象等，不同的软件语言来决定；
单元测试的主要目的是验证单元是否满足了详细设计规格说明，发现需求和设计中的错误；
单元测试设计的主要输入是详细设计规格说明、软件设计和数据模型等；
单元测试主要采用白盒测试技术，黑盒测试技术作为单元测试的辅助；
单元测试应该覆盖功能需求和非功能需求；
单元测试经常会使用测试驱动的方法（测试驱动开发）：
测试环境
单元测试处理的对象直接来自开发人员，通常由开发人员来开展单元测试；
单元测试可能并不能形成完成的系统，因此需要驱动模块和桩模块的支持：
桩模块：用以模拟被测模块工作过程中所调用的模块，他们一般只进行很少的数据处理，例如打印入口和返回；
驱动模块：用以模拟被测模块的上级模块，它接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印相应的结果；
驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用；
单元测试关注点：
单元模块接口参数：
实际参数和形式参数的个数是否相同；
实际参数和形式参数的属性是否匹配；
调用函数的参数顺序、个数和属性是否匹配；
单元模块局部数据结构：
不适合或者不相容的类型说明；
变量没有初始化；
不正确的变量名；
集成测试
基本含义
集成测试，又叫组装测试、联合测试等；
集成测试是对组件之间的接口进行测试，以及和系统其他部分的互相作用；
最简单的形式是两个已经测试的单元扭组合成一个组件，来测试它们之间的接口和数据交换；
集成测试的主要工作：把单元测试通过的各个模块足部集成在一起，来测试数据是否能够正确传递和调用，以及各个模块是否能正确的协同工作；
集成测试可以应用在不同的测试级别，比如单元集成测试、系统集成测试等；
集成测试的关注点
单元模块是否传输了错误的数据，或者没有传输数据；
接受数据的单元不能操作或者崩溃，比如单元功能缺陷、接口格式不兼容、协议不兼容等；
单元之间通讯正常，但是使用不同的方法来解析收到的数据，比如规格说明矛盾、理解错误等；
数据能正常传输，但是传输事件错误，比如时序问题，或者传输的时间间隔太短，比如吞吐量、负荷、容量等问题；
集成测试策略
自底而上集成测试步骤
明确被测试模块并进行先后顺序分层；
按照时间线序关系，将不同单元进行集成；
将不用的模块集成子系统，或者分系统；
将子系统集成为系统；
自底而上集成测试特点
不需要桩；
需要构造不同的驱动模块；
自顶向下集成测试步骤
以主控模块作为测试驱动，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；
依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；
每集成一个模块立即测试一遍；
只有每组测试完成后，才着手替换下一个桩模块；
为避免引入新错误，需不断地进行回归测试（即全部或部分地重复已做过的测试）；
自顶向下集成测试特点
优点：不需要测试驱动器，或者只需要简单的测试驱动，这是因为经过测试的较高级别单元组成了测试环境的主要部分；
缺点：还没有集成的较低级别的单元必须用桩代替，成本很高；
核心系统优先集成测试步骤
对核心系统中的模块进行单独的、充分的测试；
核心系统的所有模块一次性集合到被测系统中，在规模相对较大的情况下，也可以按照自底向上的步骤，集成核心系统的各组成模块；
按照各外围软件部件的重要程度以及模块间的相互制约关系，拟定外围软件部件集成核心系统中的顺序方案；
完成外围软件部件内部的集成测试；
按顺序不断加入外围软件部件到核心系统；
随意集成测试步骤
按照单元的完成时间进行集成；
随意集成测试特点
优点：节省时间，因为每个单元可以最快的集成到环境中来；
缺点：桩和测试驱动器都需要；
系统测试
基本含义
系统测试是将已经集成好的软件系统，作为计算机系统的一部分，与计算机硬件、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进行一系列严格优秀的测试；
系统测试关注的是项目或产品范围中定义的整个系统或产品的行为；
在系统测试中，测试环境应该尽量和最终使用的目标或产品使用的环境相一致，从而减少和环境相关的失效；
测试目标
系统测试的目标是确认整个系统是否满足了规格说明中的功能和非功能需求，以及满足的程度；
系统测试应该发现由于需求不正确、不完整或实现和需求不一致而引起的失效，并识别没有文档化或被忘记的需求；
常见的系统测试包括压力测试、容量测试、性能测试、安全测试、容错测试等；
验收测试
基本含义
验收测试通常是由使用系统的用户来进行，同时系统的其他利益相关者也可能参与其中；
验收测试的目的是通过验收测试，对系统功能、系统特定部分或特定的系统非功能特征进行测试；
发现缺陷不是验收测试的主要目标，验收测试也可以用来评估系统是否可以在市场部署、用户使用系统的准备情况等；
测试分类：功能测试、非功能测试、结构测试、变更相关的测试
功能测试
基本含义
功能测试指的是软件系统“做什么”；
功能测试的测试依据包括：需求规格说明、用例、功能规格说明，它们描述了系统必须完成的功能；
功能测试主要考虑的是系统的外部表现，即一般采用的是黑盒测试的技术；
功能测试可以应用在各个测试级别；
功能测试包括：合适性、准确性、互操作性、安全性
非功能性测试
基本含义
非功能性指的是系统工作的“怎么样”，比如系统有多容易使用等；
非功能测试不是功能的测试，而是对功能行为的测试，或作为整体系统能力的测试；
非功能测试可以应用在任何测试级别上；
非功能测试包括：可靠性、易用性、可维护性、可移植性
结构测试
基本含义
结构测试，或者白盒测试，使用测试对象的内部代码结构和架构信息（语句或判断、递归调用、菜单结构），也可能使用软件的抽象模型（例如：过程流模型或状态转换模型）等作为输入；
结构测试可以在任何测试级别上进行；
结构测试技术通常通过评估结构类型测试的覆盖性，来测量测试的完整性；
结构测试通常应用在低级别的测试上，比如单元测试和集成测试，但它同样使用其他级别的测试；
覆盖类型：语句覆盖、判定覆盖、条件组合覆盖、判定/条件覆盖、路径覆盖
变更相关的测试
基本含义
当已有的系统发生变化、缺陷被修正或者增加了新功，变化的部分必须进行重新测试，我们统称为回归测试；
目的1：通过重新进行测试以确定原来的缺陷已经成功的修改、或者新增的功能已经正确实现；
目的2：通过测试，确定系统的变更比如新增功能或者缺陷修改，没有影响原来的功能和系统行为；
回归测试可以应用到任何级别测试中；
静态测试
基本定义
静态测试通过对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行；
主要目的是从已有的规格说明、已定义的标准或甚至是项目计划中发现缺陷和偏差；
包括人工检查（评审）和自动化检查（静态分析），是一个经常被低估的测试方法，或者在测试过程中经常被忽略的方法；
基本类型
人工检查：通过人工的方式，对软件产品的设计规格说明的审查，对程序代码的阅读、审查等；走查、审查、评审
静态分析：静态分析往往需要借助测试工具（比如编译器就是一种静态分析工具）来自动检测；
动态测试
基本定义
动态测试是通过观察软件运行时的动作，来提供执行跟踪、时间分析，以及测试覆盖度方面的信息；
动态测试通过真正运行程序发现错误。通过有效的测试用例，对应的输入/输出关系来分析被测软件的运行情况；
基本类型：白盒测试、黑盒测试、基于经验的测试
维护测试
基本含义
软件系统在运行过程中，经常需要对软件系统和它运行的环境进行修正、改变或扩展；
维护测试是在一个运行的系统上进行，且一旦对软件或系统进行修改、移植或系统被淘汰时，就需要进行维护测试；
基本类型
修改可以是计划中的功能增强（例如：根据版本发布的计划）；
也可以是缺陷修改纠正和应急变更；
甚至是环境的变化，比如计划中的操作系统或数据库升级，或由于新发现或暴露的操作系统漏洞而打的补丁等；
维护测试
步骤描述
软件变更分析：分析和了解各种不同的软件变更，包括软件版本新功能的增加、需求文档的变更、系统设计的变更、系统实现的变更、软禁啊使用平台和操作系统的变更，以及缺陷的修改等；
软件变更影响分析：分析和了解由于软件变更可能导致对软件系统的影响，比如由于需求文档的变更，会导致后续的设计文档、编码和测试文档的变更，以及测试活动的变更；
定义回归测试策略：定义回归测试的方法、策略和准则。回归测试策略可以作为指南，帮助测试工程师开展回归测试活动。回归测试策略一般来说是指如何定义回归测试的范围、回归测试的覆盖率准则要求，以及回归测试执行的顺序等等；
定义回归测试套件：定义如何选择和重用测试用例来形成一个回归测试套件；
执行回归测试套件：执行套件中的测试用例；
报告回归测试结果：报告和分析回归测试结果；
