软件工程基础、软件测试过程模型

软件工程

• 软件工程（Software Engineering，简称SE）是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的科学。

• 1983年IEEE给出的定义是：软件工程是开发、运行、维护和修复软件的系统方法

软件工程的主要环节

• 人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试维护等。

软件工程的目标

• 提高软件的质量与生产率，最终实现软件的工业化生产

软件工程

• 可修改性（modifiability）
  • 允许对系统进行修改而不增加原系统的复杂性
• 有效性（efficiency）
  • 软件系统能最有效地利用计算机的时间资源和空间资源
• 可靠性（reliability）
  • 能防止因概念、设计和结构等方面的不完善造成的软件系统失效，具有挽回因不当造成软件系统失效的能力
• 可理解性（understandability）
  • 系统具有清晰的结构，能直接反映问题的需求
• 可维护性（maintainability）
  • 软件产品交付用户使用后，能够对它进行修改，以便改正错误，改进性能和其他属性，使软件产品适应环境的变化等。
• 可重用性（reusebility）
  • 可重用性包括应用项目的重用、规约说明的重用、设计的重用、概念和方法的重用等。
• 可适应性（adaptability）
  • 软件在不同的系统约束条件下，使用户需求得到满足的难易程度
• 可移植性（portability）
  • 软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度
• 可追踪性（traceability）
  • 根据软件需求对软件设计、程序进行正向追踪，或根据程序、软件设计对需求进行逆向追踪的能力
• 可互操作性（interoperability）
  • 多个软件元素相互通信并协同完成任务的能力

软件开发生命周期模型

• 大爆炸模型

  • 大爆炸模式是最简单的软件开发模式，计划、进度安排和正规开发过程都几乎没有，所有精力都花在开发软件和编写代码上
  • 一般，大爆炸模式计划没有测试，即使有也要挤在产品发布前，通常都会避免在此模式下进行测试

• 边写边改模型

  • 此种模式没有计划和文档编制，项目能够迅速展示成果，所以比较适合用完就扔的项目
  • 与大爆炸模式类似，测试在边写边改模式中未特别强调，但是在编写代码和修改缺陷过程中举足轻重
  • 软件测试会陷入无休止的循环往复，因为没有都可能在测试新版本
  • 此种模式是测试期间最有可能碰到的模式

• 瀑布模型

  • 制定周密计划的瀑布模型
  • 强调产品的定义
  • 各步骤是分立的、没有交叉
  • 没有回溯

• 螺旋模型

  • 开始不必详细定义所有细节，从小开始，定义重要功能，努力实现这些功能，接收客户反馈，然后进入下一阶段，重复上述过程，直至得到最终产品
  • 螺旋模式的六个步骤
    • ① 确定目标/方案和限制条件
    • ② 明确并化解风险
    • ③ 评估可选方案
    • ④ 当前阶段开发和测试
    • ⑤ 计划下一阶段
    • ⑥ 确定进行下一阶段的方法

• 敏捷开发

  • 敏捷宣言
    • 个体交互 重于 过程和工具
    • 可用的软件 重于 完备的文档
    • 客户协作 重于 合同谈判
    • 响应变化 重于 遵循计划

• 敏捷开发的核心思想是：以人为本，适应变化

敏捷软件开发的目的是

• 通过过程和工具理解个人和交流的作用
• 通过全面的文档理解运行的软件
• 通过合同和谈判得到客户的协作
• 在计划的执行中做出对变更的响应

软件开发生命周期的模型

开发流程分类	优点	缺点
大爆炸模型	简单，不用学习就会	产品质量无法保证，尽量避免使用
边写边改模型	快速得到可运行的版本	计划有些缺乏，导致版本前后变化较大。
瀑布模型	计划周密，专业，按部就班实现	难以做到快速开发，抢占市场。
螺旋模型	计划变化同时考虑	可选择的模型之一

在任何生命周期模型中，一个好的测试都应该具有以下特点

• 每个开发活动都有相对应的测试活动
• 每个测试级别都有其特有的测试目标
• 对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计
• 在软件开发生命周期中，测试员在文档初稿阶段都应该参与文档的评审

软件测试过程模型

V模型

• "V"的左端表示传统的瀑布开发模型，而"V"的右端表明相应的测试阶段

• V模型是最具有代表意义的测试模型。它的提出旨在改进开发效率和效果 V模型

• 单元和集成测试验证程序设计，检测程序的执行是否满足软件设计的要求

• 系统测试验证系统设计，检测系统功能、性能的质量特性是否达到系统要求的指标

• 验收测试由测试人员和用户进行，追溯软件需求说明书，确定软件的实现是否满足用户需求或合同的要求

W模型

W模型

• W模型从V模型演化过来，实际开发是V，测试是并行的V
• 对比V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动，W明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早地全面的发现问题
• 测试伴随着整个软件开发周期，且测试的对象不仅仅是程序，需求、设计等同样要测试
• W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困境

H模型

• H模型建立
  • 真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量
  • 为了解决V模型和Ｗ模型存在的问题。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来
• H模型应用 Ｈ模型
• H模型揭示了一个原理
  • 软件测试不仅仅指测试的执行，还包括很多其他的活动
  • 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进行测试执行阶段
  • 软件测试要尽早准备，尽早执行
  • 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的

X模型

X模型

• 很好地处理测试与开发的交接过程（交接的过程是一个时间段，而不是一个点）
• 左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序，然后再对这些可执行程序进行测试
• X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，给有经验的测试人员在测试计划之外发现更多的软件缺陷

测试模型的使用

• 应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义
• 在实际的工作中，要灵活地运用各种模型的优点，在W模型的框架下，运行H模型的思想进行独立地测试，并同时将测试和开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标