瀑布模型
概念
线性模型, 所有模型中占重要地位, 是所有模型的基础
图示
测试阶段处于软件实现后, 必须在代码完成后预留足够的时间进行测试活动, 否则测试不充分, 很多问题到项目后才会暴露
优缺
优点
▨ 开发各个阶段清晰
▨ 强调早期计划以及需求调查
▨ 适合需求稳定的产品开发
缺点
▨ 依赖早期的需求调查, 不适应需求的变化
▨ 单一流程不可逆
▨ 风险延续到后期才暴露, 失去及早纠错的机会
▨ 前面未发现问题传递扩散到后期阶段, 可能导致项目失败
改良
沿用瀑布模型的线性思想, 细化各个阶段, 在某些重要关注阶段之间掺入迭代思想
快速原型模型 - 敏捷性开发
概念
在开发真实系统前, 构造原型, 在此基础上逐步进行并完成整个系统的开发
图示
第一步建造一个原型, 实现用户与系统的交互吗用户对原型进行评价, 进一步细化对开发的需求,
通过逐步的调整原型使用户满足, 开发人员可以确定用户真正的需求是什么
第二步是第一步的基础上开发出用户满意的软件产品
优缺
优点
▨ 克服瀑布模型的缺点, 更好的满足用户的需求
▨ 减少由于需求不明确导致的项目开发风险
▨ 适合预先不能明确需求的软件系统的开发
缺点
▨ 不适合大型的系统的开发 (适合小型,灵活性高的系统)
▨ 前提拥有一个展示型的产品原型
▨ 一定程度上限制开发人员的创新
螺旋模型
概念
将开发分成几个螺旋周期, 每个周期大致和瀑布模型类似
螺旋模型按照螺旋线旋转, 在坐标的4个象限进行活动,
图示
螺旋模型是基于风险分析来进行的, 因此要求架构师
优缺
优点
▨ 作为一种风险驱动方法体系, 必须要对每个阶段经常发生的风险进行分析
▨ 架构师的存在可以极大的减少这部分你的风险
缺点
▨ 需求经验丰富的架构师
▨ 过多的迭代次数会增加开发成本, 延迟提交时间
V模型
概念
一个具备代表意义的测试模型, 作为瀑布模型的变种, 标明测试过程本身存在的不同阶段
从左到右描述了开发过程和测试过程阶段性的对应关系
图示
▨ 需求分析 - 用户需求, 业务需求, 需求规格说明书
▨ 概要设计 - 系统架构, 模块划分, 模块和模块之间的接口
▨ 详细设计 - 模块内部实现的逻辑和方法
▨ 编码 - 实现上述设计
▨ 单元测试 - 检测代码开发是否符合详细设计的要求
▨ 集成测试 - 检测当前测试的组成部分是否能够完成并结合在一起
▨ 系统测试 - 检测已集成在一起的产品是否符合规格说明书的要求
▨ 验收测试 - 检测产品是否符合最终用户的需求, 以及迭代
优缺
优点
▨ 包含底层测试以及高层测试
▨ 底层测试 : 检验源码质量测试 - 单元测试
▨ 高层测试 : 检验整个系统的需求 - 系统测试
▨ 清楚的标识开发的阶段
▨ 采用自上向下的逐步求精的方式将开发划分不同阶段, 每个阶段分工明确, 因此便于控制开发
缺点
▨ 测试阶段较为靠后, 之前问他产生修改不便
▨ 作为瀑布模型的变种, 需求变化, 需要返工
W模型 - 双V模型
概念
开发一个 V, 测试一个V组成 W 模型
测试伴随着整个开发周期, 而且测试的对象不仅仅是程序
需求以及设计同样要测试
图示
优缺
优点
▨ 开发强调测试伴随整个软件开发周期
▨ 测试对象不仅仅是程序, 需求和设计也要测试
▨ 更早的接入测试, 可以发现开发初期的缺陷, 更低成本的进行缺陷修复
▨ 同样分阶段工作, 便于控制项目过程
缺点
▨ 代码已经在测试之前, 不方便代码的测试工作
▨ 对于当前很多项目, 执行过程中不产生文档, W模型无法适用
▨ 使用起来复杂度高, 对于需求和设计的测试要求很高, 实践起来困难
H模型 - 了解即可
概念
测试完全独立, 形成一个完全的流程, 同时将测试转呗和测试执行清晰表现出来
图示
▨ 测试流程
▨ 测试准备 - 所有的测试活动的准备, 判断是否到测试就绪点
▨ 测试就绪点 - 测试准入准则, 及是否开始执行测试的条件
▨ 测试执行 - 具体的执行测试的程序
▨ 其他流程 - 具体开发中的流程, 如: 设计流程
优缺
优点
▨ 揭示软件测试中除测试执行外, 还有很多工作
▨ 软件测试完全独立, 贯穿整个生命周期, 与其他流程并发执行
▨ 软件测试活动可以尽早准备, 尽早执行, 具备很强的灵活性
▨ 软件测试可以根据被测物的不同而分层次, 分阶段, 分次序的执行
▨ 可迭代
缺点 - 缺点较为致命
▨ 管理要求高
▨ 技能要求高
▨ 测试就休点分许困难
▨ 对整个项目组人员要求非常高