软件测试生命周期和开发模型

一、软件危机和软件工程

软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

软件工程

基于软件危机对于计算机发展的障碍，1968年，在联邦德国召开国际会议上，北大西洋公约组织的计算机科学家讨论软件危机问题，提出软件工程这个名词，从此软件生产进入工程化时代。
软件工程包括两方面的内容：
- 软件开发技术：软件开发方法学、软件工具和软件工程环境
- 软件项目管理：软件质量、项目估算、进度控制、人员组织、配置管理、项目计划
引起软件危机的主要问题是软件质量问题
软件工程主要解决的就是软件质量问题
软件测试是软件质量管理体系中一个非常重要的手段

二、软件生命周期

1、软件生命周期：一个软件产品或者系统要经历孕育、诞生、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）。

2、软件生命周期（SDLC，软件生存周期）是软件的产生直到报废的生命周期。为了使规模扩大、结构复杂和管理复杂的软件开发变得容易管理和控制，把整个软件生命周期划分成若干个阶段，使每个阶段都有明确的任务，整理出软件生命周期模型。

三、软件开发模型

1、概念：软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

2、软件生命周期模型分为：瀑布型生命周期、迭代模型、快速原型模型、螺旋模型、V模型、W模型

四、软件开发模型讲解

瀑布模型

瀑布模型，适用于结构化的软件项目，是面向过程的软件测试模型。

具体的流程如图所示：
1. 项目计划：投入多少人，时间进度如何安排；
2. 需求分析：产品经理输出需求文档，项目组的人员再对这份文档进行分析，对需求进行判断、改进、完善；
3. 软件设计：开发团队根据确认后的文档进行功能设计；
4. 程序开发：代码编写；
5. 软件测试：测试团队制定测试计划，设计与开发测试用例，实施测试，总结与评估；
6. 集成维护
选择瀑布模型必须满足的条件：
1. 在开发时间内需求没有或者很少变化；
2. 分析设计人员对应用领域很熟悉；
3. 低风险项目（对目标、环境很熟悉）；
4. 用户使用环境很稳定；
5. 用户除了提出需求以外，很少参与开发工作
缺点：
1. 测试滞后，在开发完成之后，早期的错误可能要等到后期才能发现，错误成本高
瀑布模型，已经是一种古老的开发模型了，目前市场上按照这套模型进行开发测试的公司逐渐减少，主要是一些传统的互联网公司还在沿用它，例如银行的项目。
螺旋模型

1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。
迭代模型

迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

什么是迭代式开发？

1、每次只设计和实现这个产品的一部分

2、逐步逐步完成的方法叫迭代开发

3、每次设计和实现一个阶段叫做一个迭代

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

迭代式开发的优点：

1、降低风险

2、得到早期用户反馈

3、持续的测试和集成

4、使用变更

5、提高复用性
敏捷开发模型

敏捷开发模式是一种90年代起才引起广泛关注的新型软件开发方法，是一种应对快速变化需求而产生的一种软件开发能力。在实际的应用或者说理解中，其名称、理念、过程、术语都有一定的差别，但相对于传统的“非敏捷”方式，更强调开发团队与业务专家之间的紧密协作沟通（交流大于文档）、形成紧凑而自我组织型的团队，这样可以有助于频繁交付新的软件版本，更好的适应需求变化的代码编写和团队组织方法，也就是更加注重软件开发中人的作用。

敏捷开发实施条件

如果要想很好的实施scrum，通常有两点需要满足：一是团队有三名或以上的研发工程师，二是团队内有一名合适的Scrum Master。当团队内无法找到合适的Scrum Master时，不要轻易推行敏捷。如果你的团队是由新人组成，或者即使有资深员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的Scrum Master出现。

当你真正实行敏捷开发时，要注意量化衡量团队的执行力的指标：完成度、评估准确度、计划合理度。这是评定整个进度的很重要的指标，也是让迭代更好的进行下去的准则。
增量模型

与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

但是，增量模型也存在以下缺陷：

（1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

（2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。

例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。
快速原型模型（墨刀）

我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子。

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。