软件测试模型

软件测试模型软件测试模型 软件测试模型 常见的软件测试模型软件测试模型包括 V 模型 W 模型 H 模型 X 模型和前置模型 V 模型是最具有代表意义的测试模型 V 模型是软件开发瀑布模型的变种 它 反映了测试活动与分析和设计的关系 从左到右 描述了基本的开发过程和测试行为 非常明确地标明了测试过程中存在 的不同级别 并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 左边依次下降的是开发过程各阶段 与此相对应的是右边依次上升的部分 即各测 试过程的各个阶段 用户需求 验收测试 需求分析和系统设计 确认测试和系统测试 概要设计 集成测试 详细设计 单元测试 编码 1 V 模型 在软件测试方面 V 模型是最广为人知的模型 尽管很多富有实际经验的 测试人员还是不太熟悉 V 模型 或者其它的模型 V 模型已存在了很长时间 和瀑布开发模型有着一些共同的特性 由此也和瀑布模型一样地受到了批评和 质疑 V 模型中的过程从左到右 描述了基本的开发过程和测试行为 V 模型 的价值在于它非常明确地标明了测试过程中存在的不同级别 并且清楚地描述 了这些测试阶段和开发过程期间各阶段的对应关系 局限性 把测试作为编码 之后的最后一个活动 需求分析等前期产生的错误直到后期的验收测试才能发 现 V 模型问题 1 测试是开发之后的一个阶段 2 测试的对象就是程序本身 3 实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现 4 整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心 而且 上一步的结果必须是充分和正确的 如果任何一个环节出了问题 则必将严重的影 响整个工程的质量和预期进度 仅仅把测试过程作为在需求分析 系统设计及编码之后的一个阶段 忽视了测试对需求分析 系统设计的验证 一直到后期的验收测试才被发现 现代化的 V 模型依托计算机辅助控制系统设计 CACSD Computer Aided Control System Design 将计算机支持工具贯穿于控制系统开发测试的全过程 计算机不仅可以辅助控制系统设计 进行方案设计和离线仿真 还用于实时快 速控制原型 产品代码生成和硬件在回路测试 这里 V 代表着 Verification 和 Validation 这样就形成一套严谨完整的系统开发方法 第一阶段 功能需求定义和控制方案设计 在传统方法中 这一过程的产物就是几千字甚至几万字的文字说明 在现代方 法中为了避免文字说明的模糊性及理解性错误 详细说明将采用模型方式 可 以用信号流图的方式 Simulink 模型 进行定义 控制方案的设计也不再采 用过去的那种先将对象模型简化成手工可以处理的形式 再根据经验进行手工 设计的方式 而是用诸如 MATLAB SIMULINK 等计算机辅助建模及分析软件建立 对象尽可能准确的模型 并进行离线仿真 从而避免了传统设计过程中 对象 过于简化带来的设计方案无法满足实际对象要求的尴尬局面 第二阶段 快速控制原型 RCP 按现代设计方法 方案设计结束后 无须等待软件工程师的编程和随后的代码 硬件集成 而是利用计算机辅助设计工具自动将控制方案框图转换为代码并自 动下载到硬件开发平台 从而快速实现控制系统的原型 原型中包括实际系统 中可能的各种 I O 软件及硬件中断等实时特性 之后 就可以利用计算机辅 助试验测试管理工具软件进行各种测试 以检验 Validation 控制方案对实 际对象的控制效果 并在线优化控制参数 此时即使模型需要大规模修改 重 新形成测试原型也只需要几分钟的时间 这样在最终实现控制方案之前 就可 基本确认最终方案和效果 避免过多的资源浪费和时间消耗 第三阶段 生成代码 传统的人工编程很容易引入缺陷 速度较慢 现代开发方法则不同 产品代码 的大部分由机器自动生成 对大多数工程师而言 如果能够加快开发速度 损 失代码的部分实时运行效率是可以接受的 而且机器自动编码 很容易避免人 为的各种错误 第四阶段 硬件在回路仿真 HILS 有了控制产品的初样 还必须对其进行全面综合的测试 以对照确认 Verification 产品与实际指标要求 特别是故障情况和极限条件下的测试 但如果用实际的控制对象进行测试 很多环境条件无法实现的 抑或要付出高 昂的代价 现代开发方法中计算机辅助设计工具 软件 硬件 将再次发挥作 用 可以用 HILS 的方法和工具进行各种条件下的测试 特别是故障和极限条件 下的测试 这是传统开发方法所不具备的 第五阶段 系统集成测试 标定 产品型控制器制造完成后 需要与其它子系统连接起来 构成完整闭环进行全 面 详细的测试 以确认产品符合各项设计指标和需求定义 这一阶段的主要 困难是 并行开发过程中 其它子系统部分未能就绪 无法集成 HILS 应用可 以替代闭环系统当中那些尚未就位或者不易获取的部分 用数学模型模拟它们 的特性 并通过 I O 端口为控制器提供相应的反馈信号 这样 开发过程中各 个子系统之间不必等待对方完成 就可以开展集成测试 及时的完成系统性能 确认和调整 集成测试后期 产品需要根据具体的使用条件需要 调整成品控 制器中的控制参数 即标定过程 W W 模型模型 编辑编辑 W 模型由 Evolutif 公司公司提出 相对于 V 模型 W 模型增加了软件各开发阶 段中应同步进行的验证和确认活动 W 模型由两个 V 字型模型组成 分别代表 测试与开发过程 图中明确表示出了测试与开发的并行关系 W 模型中测试与开发对应关系如下 开发 需求分析 概要设计 详细设计 编码 软件集成 系统 集成 部署 测试 需求评审 概要设计评审 详细设计评审 单元测试 集成测试 系统 测试 验收测试 W 模型强调 测试伴随着整个软件开发周期 而且测试的对象不仅仅是程序 需求 设计等同样要测试 也就是说 测试与开发是同步进行的 W 模型有利 于尽早地全面的发现问题 例如 需求分析完成后 测试人员就应该参与到对 需求的验证和确认活动中 以尽早地找出缺陷所在 同时 对需求的测试也有 利于及时了解项目难度和测试风险 及早制定应对措施 这将显著减少总体测 试时间 加快项目进度 但 W 模型也存在局限性 在 W 模型中 需求 设计 编码等活动被视为串行的 同时 测试和开发活动也保持着一种线性的前后关 系 上一阶段完全结束 才可正式开始下一个阶段工作 这样就无法支持迭代 的开发模型 对于当前软件开发复杂多变的情况 W 模型并不能解除测试管理 面临着困惑 2 W 模型 V 模型的局限性在于没有明确地说明早期的测试 无法体现 尽早地和不断地 进行软件测试 的原则 在 V 模型中增加软件各开发阶段应同步进行的测试 演 化为 W 模型 如下图 在模型中不难看出 开发是 V 测试是与此并行的 V 基于 尽早地和不断地进行软件测试 的原则 在软件的需求和设计阶段的 测试活动应遵循 IEEE1012 1998 软件验证与确认 V V 的原则 W 模型由 Evolutif 公司提出 相对于 V 模型 W 模型更科学 W 模型是 V 模型的发展 强调的是测试伴随着整个软件开发周期 而且测试的对象不仅仅 是程序 需求 功能和设计同样要测试 测试与开发是同步进行的 从而有利 于尽早地发现问题 W 模型也有局限性 W 模型和 V 模型都把软件的开发视为需求 设计 编 码等一系列串行的活动 无法支持迭代 自发性以及变更调整 H H 模型模型 编辑编辑 在 H 模型中 软件测试的过程活动完全独立 形成了一个完全独立的流程 贯 穿于整个产品的周期 与其他流程并发进行 某个测试点准备就绪后就可以从 测试准备阶段进行到测试执行阶段 软件测试可以根据被测产品的不同分层进 行 4 H 模型 H 模型中 软件测试过程活动完全独立 贯穿于整个产品的周期 与其他流程 并发地进行 某个测试点准备就绪时 就可以从测试准备阶段进行到测试执行阶段 软件测试可以尽早的进行 并且可以根据被测物的不同而分层次进行 这个示意图演示了在整个生产周期中某个层次上的一次测试 微循环 图 中标注的其它流程可以是任意的开发流程 例如设计流程或者编码流程 也就是 说 只要测试条件成熟了 测试准备活动完成了 测试执行活动就可以进行了 H 模型揭示了一个原理 软件测试是一个独立的流程 贯穿产品整个生命周期 与 其他流程并发地进行 H 模型指出软件测试要尽早准备 尽早执行 不同的测 试活动可以是按照某个次序先后进行的 但也可能是反复的 只要某个测试达到准 备就绪点 测试执行活动就可以开展 3 X 模型 X 模型也是对 V 模型的改进 X 模型提出针对单独的程序片段进行相互分离 的编码和测试 此后通过频繁的交接 通过集成最终合成为可执行的程序 X 模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试 此后将进行频繁的交接 通过集成最终成为可执行的程序 然