软件的生命周期
软件立项
|
可行性研究
|
需求分析
|
概要设计
|
详细设计
|
编码实现
|
单元测试
|
集成测试
|
系统测试
|
验收测试
|
运行维护
测试评审贯穿从软件立项–》验收测试整个过程
软件的开发过程
瀑布模型
- 制定计划
- 需求分析
- 软件设计
- 程序编写
- 软件测试
- 及时维护
这个是典型的瀑布模型，上个工作阶段的输出是下个工作阶段的输入，但是测试介入工作太晚，并且不支持迭代
快速原型模型
迅速建造一个可以运行的软件原型，以便可以理解和澄清问题，便于开发人员与用户达成共识，最终在确定用户需求基础上开发客户满意的软件产品。
- 快速原型模型允许在需求分析阶段快速的开发出软件系统的原型，用来展示全部或者部分功能
- 用户对该原型进行测试评定，给出改进意见，细化软件需求
- 这种模型适合预先不能确切定义需求的软件系统开发
优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
缺点：所选用的开发技术和工具不一定符合主流的发展，快速建立起来的系统结构加上连续的修改会导致产品质量低下
增量模型
增量模型是把待开发的软件系统模块化，将每一个模块作为一个增量组件，从而分批次分析，设计，编码和测试这些增量组件
相对于瀑布模型而言，使用增量模型，开发人员不需要一次性将整个软件产品提交给用户，而是可以分批量提交
优点：
- 软件产品可以分批次进行交付，用户能够及时了解软件项目的进展
- 以组件为单位进行开发降低了软件开发的风险
- 开发顺序比较灵活
限制: - 软件产品可以分批次地进行交付
- 待开发的软件系统能够被模块化
- 要求项目管理人员把握全局的水平较高
迭代模型
迭代包括产生产品发布（稳定，可执行的产品版本）的全部开发活动和要使用该发布必须得所有其他的外围元素
在某种程度上，开发迭代是一次完整的经过所有的工作流程的过程：需求分析，设计，实施和测试工作流程
优点：
- 降低了在一个增量上开支的风险
- 降低了产品无法按照进度进入市场的风险
- 加快了整个开发工作的进度
- 由于用户的需求并不能再一开始就完全做出界定，迭代的过程会更加实用需求的变化
测试过程
软件测试与开发一样有自己的过程模型，软件测试过程是一种抽象的模型，一个标准的软件测试的过程中应该包含：需求分析，测试计划，测试设计，测试执行，测试总结等
V模型
用户需求 验收测试
| |
需求分析与系统 系统测试
| |
概要设计 集成测试
| |
详细设计 单元测试
| |
编码
优点：解释了开发的过程对应测试阶段的关系，通过开发和测试同时来进行缩短了开发的周期
缺点：没有体现尽早测试的原则
W模型
用户需求 验收测试设计
| |
需求分析与系统设计 确认与系统测试设计 验收 验收测试
| | | |
概要设计 集成测试设计 实施 确认测试与系统测试
| | | |
详细设计 单元测试设计 集成 集成测试
| |
编码 单元测试
优点：
- 测试活动与开发同步进行
- 测试的对象不仅仅包括程序还有需求与设计
- 尽早的发现软件中的缺陷降低开发成本
局限性：
w模型中，需求，设计，编码等活动为串行的，同时测试和开发保持着一种线性关系，上一个活动结束，下一个活动才能开始
h模型
测试准备 ------》 测试就绪点 -------->测试执行---》【测试流程】
|
-----------------------》-------------------------》其他流程
优点：
- h模型将测试活动独立，形成了一个完全独立的流程
- 只要测试条件成熟，测试活动就可以开始
- h模型指出尽早测试，尽早执行
备注：为了更好的对开发的过程进行测试，我们通常使用的w+h的测试模型
测试过程管理的理念
- 尽早测试
- 测试人员尽早参与软件项目，及早开展测试，其中包括，测试计划，制定测试方案，以及准备测试
- 尽早开展工作，从单元测试开始 - 全面测试
- 对软件的所有产品进行全面的测试，包括需求，设计文档，代码，用户文档等
- 软件开发以及测试人员都要参与到测试的工作中 - 全过程测试
- 测试人员要充分关注开发的过程，对开发过程的变化做出响应
- 对测试的全过程进行跟踪 - 独立的，迭代的测试
- 测试过程是独立的，只要条件成熟，测试准备活动完成，测试的执行活动就可以开展
- 在遵循以上理念的同时，测试要作为一个独立的过程进行管理
