软件开发模型与软件测试模型

一、软件开发模型

软件开发模型大体上可分为两种类型，第一种是以软件需求完全确定为前提的瀑布模型。第二种是在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如原型模型、螺旋模型等。实践中经常将几种模型组合使用以便充分利用各种模型的优点。

（1）瀑布模型

瀑布模型也称软件生存周期模型，由W．Royce于1970年首先提出。

根据软件生存周期各个阶段的任务，瀑布模型从系统需求分析开始，逐步进行阶段性变换，直至通过验收测试并得到用户确认的软件产品为止。瀑布模型上一阶段的变换结果是下一阶段变换的输入，相邻的两个阶段具有因果关系，紧密相联。

一个阶段工作的失误将蔓延到以后的各个阶段。为了保证软件开发的正确性，每一阶段任务完成后，都必须对它的阶段性产品进行评审，确认之后再转入下一阶段的工作。评审过程发现错误和疏漏后，应该反馈到前面的有关阶段修正错误、弥补疏漏，然后再重复前面的工作，直至某一阶段通过评审后再进入下一阶段，这种形式的瀑布模型是带有反馈的瀑布模型，

模型中各个阶段的任务和软件开发活动如前所述。瀑布模型在软件工程中占有重要的地位，它提供了软件开发的基本框架，这比依靠“个人技艺”开发软件好得多。它有利于大型软件开发过程中人员的组织和管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。

瀑布模型的主要特点是：

　　阶段间的顺序性和依赖性，开发过程是一个严格的下导式过程，即前一阶段的输出是后一阶段的输入，每一阶段工作的完成需要确认，而确认过程是严格的追溯式过程。

　　后一阶段出现了问题要通过前一阶段的重新确认来解决。因此，问题发现得越晚解决问题的代价就越高。

瀑布模型的主要优点是：

　　（1）强调开发的阶段性。

　　（2）强调早期计划及需求调查。

　　（3）强调产品测试。

瀑布模型的主要缺点是：

　　（1）在软件开发的初始阶段指明软件系统的全部需求是困难的，有时甚至是不现实的。从认识论上讲，人的认识是一个多次反复的过程，实践——认识——再实践——再认识，多次认识，多次飞跃，最后才能获得对客观世界较为正确的认识。软件开发是人的一个智力认识活动，也不可能一次完成，需要多次反复地进行，但瀑布模型中划分的几个阶段没有反映出这种认识过程的反复性，缺乏灵活性。

　　（2）软件开发是个知识密集型的开发活动，需要人们合作交流才能完成，因此，人员间的通信和活动间的并行和串行都是必需的，但在瀑布模型中没有这方面的体现。随着软件开发项目规模的日益庞大，由此引发的问题显得更为严重。

（2）快速原型模型

快速原型法模型快速原型法是针对瀑布模型(即传统的生存周期法)提出来的一种方法。

它的基本思想是回避(或暂时回避)传统的生存周期法中的一些难点，顺从用户需求出发，快速建立一个原型。使用户通过这个原型初步表达出自己的要求，在征求用户对原型意见的过程中，进一步修改、完善、确认软件系统的需求并达到一致的理解，这就大大避免了在瀑布模型冗长的开发过程中，看不见最终软件产品雏形的现象。通过反复修改、完善，逐步靠近用户的全部需求，最终形成一个完全满足用户要求的新体系。

因此，快速原型法的最大特点是快捷，且避免了许多由于不同理解而造成的错误。

原型开发模型如下图所示：

快速开发原型的途径有三种：

　　（1）利用计算机模拟软件系统的人机界面和人机交互方式。

　　（2）开发一个工作原型，实现软件系统的部分功能，而这部分功能是重要的，也可能是容易产生误解的。

　　（3）利用类似软件向客户展示软件需求中的部分或全部功能。为了快速开发原型，要尽量采用软件重用技术，在算法时/空开销方面也可以让步，以便争取时间，尽快向用户提供原型。原型应充分展示软件的可见部分，如数据的输入方式、人机界面、数据的输出格式等。

快速原型法模型在各个阶段用户反馈活动的基础上，突出了快速的改进过程，它改变了瀑布模型的线性结构，采用逐步求精方法使原型逐步完善，以满足用户的要求，是一种在新的高层次上不断反复推进的过程。

由于原型是用户和软件开发人员共同设计和评审的，因此利用原型能统一用户和软件开发人员对软件项目需求的理解，有助于需求的定义和确认。利用原型定义和确认软件需求之后，就可以对软件系统进行设计、编码、测试和维护。

原型系统的不足之处有以下两点：

　　（1）为了使系统尽快运行起来，系统开发人员在初期往往考虑得不周全，有可能使原型不能成为最终软件产品的一部分，只是一个示例而已。这样，在实际开发软件产品时，仍有许多工作要做。

　　（2）原型模型需要大量完备和实用的软件工具的支持才能实现，即原型模型对工具和环境的依赖性较高。

（3）迭代模型

迭代式模型是RUP(Rational Unified Process,统一软件开发过程,统一软件过程)推荐的周期模型。迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和使用该发布必需的所有其他外围元素。在某种程度上,开发迭代是一次完整的经过所有工作流程的过程,主要包括:需求、分析设计、实施和测试工作流程。实质上,它类似小型的瀑布式项目。RUP认为,所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。开发过程如下图所示。

4周时间开发 系统的A模块，B模块，C模块，D模块的功能

增量，第一周完成A模块；第二周完成B模块：第三周完成C模块：第四周完成D模块：

迭代：第一周完成A B C D四个模块的基础框架部分，第二周完成基础功能的开发和测试，第三周进一步开发复杂的功能，第四周完善细节；

与传统的瀑布模型相比较,迭代过程具有以下优点：

① 降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。
② 降低了产品无法按照既定进度进入市场的风险。在开发早期就确定风险,可以尽早地解决而不至于在开发后期由于赶进度而造成软件质量下降。
③ 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。
④ 由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。

（4）螺旋模型

螺旋模型螺旋模型是B．Boehm于1988年提出的。它是瀑布模型与原型模型的结合，不仅体现了两个模型的优点，而且还增加了新的成分——风险分析。

它由四个部分组成：

　　（1）需求定义当初次建立原型时，必须对用户需求进行分析；当针对已有原型构造新的更为丰富和完善的原型时，必须将用户对已有原型的评价意见、改进建议以及对新原型的需求进行分析。

　　（2）风险分析根据初始需求或改进意见，评审可选方案，给出消除或减少风险的途径。

　　（3）工程实现针对前面得到的用户需求，进行软件设计、编码、调试和测试。

　　（4）评审检查原型是否实现了用户需求，邀请用户实际操作该原型，要求用户进行评价，提出改进意见和进一步的需求。

螺旋模型是由以上步骤组成的迭代模型。软件开发过程每迭代一次，螺旋线就增加一周，软件开发又前进一个层次，系统又生成一个新版本，而软件开发的时间和成本又有了新的投入。

在大多数场合，软件开发过程沿螺旋线的路径连续进行，希望最终得到一个用户满意的软件版本。理论上，迭代过程可以无休止地进行下去，但在实践中，迭代结果必须尽快收敛到用户允许的或可接受的目标范围内。只有降低迭代次数，减少每次迭代的工作量，才能降低软件开发的时间和成本。

螺旋模型的每一周期都包括需求定义、风险分析、工程实现和评审四个阶段。这是对典型生存周期的发展。它不仅保留了生存周期模型中系统地、按阶段逐步进行软件开发和“边开发、边评审”的风格，而且还引入了风险分析，并把制作原型作为风险分析的主要措施。

螺旋模型的主要优点是：

　　（1）一个项目分多层小迭代，适合风险比较大并且整个项目也比较庞大，每一个迭代做风险分析，讨论项目是否有价值继续。

螺旋模型的主要优点是：

　　（1）风险分析要求很高，需要投入专业人员，导致时间，项目支出费用比较高。

　　（2）风险对比对测试人员和开发人员要求比较高。

（5）敏捷开发模型

敏捷开发模型是一种20世纪90年代开始逐渐兴起的软件开发模型。现在的计算机技术发展非常迅速,也需要软件快速地开发完成以适应社会的发展变化,这就造成一种边做需求边开发的局面,传统的开发模型难以完成。为了解决这种问题,人们提出了敏捷开发模型。
敏捷开发模型以用户的需求为核心,采用迭代、循序渐进的方式进行软件开发。在项目初期,项目被分成若干个相互联系有独立运行的子项目,然后迭代完成每个子项目。相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。

敏捷开发的原则如下:

① 人和交互重于过程和工具;

② 能使用的软件重于求全而完备的文档。

③ 客户协作重于合同谈判;

④ 随时应对变化重于循规蹈矩。

敏捷开发可以及时响应客户需求变更,不断适应新的趋势,但在开发灵活的同时也带来了一定程度的混乱,如:文档资料缺乏,软件的可回溯性差;对于大型项目,由于人员过多,面对面沟通困难。因此敏捷开发比较适用于小型项目的开发。

敏捷开发特点：

-重目标，重产出，轻文档，轻流程（拥抱变化，客户可以在项目开发过程中改变需求）
-注重和客户的沟通，整个研发团队有效沟通，注重产品质量，注重产品规定的交付日期。
-敏捷开发周期很短（1-4周时间），研发团队人员5-9个人

Scrum流程与角色：

PO（product owner）产品经理：负责整理用户需求，形成userstory。
SM（scrum Master）项目经理，负责保证整个敏捷开发流程的顺利实施，开发，和各种协调等。
ST（scrum team）研发团队，负责整个项目的研发，各种技能的人组成，测试，开发，UI设计师等。

具体怎么做：

1.发布计划会    

2.迭代计划会议  

3.每日站会    

4.产品演示会议    

5.项目总结

二、软件测试模型

件测试模型兼顾了软件开发过程,对软件开发和测试进行了很好的融合,它既明确了软件开发和测试之间的关系,又使测试过程与开发过程产生交互,是测试工作的重要参考和指导。

（1）V模型

V模型是最广为人知的测试模型，它是从瀑布研发模型演变而来的测试模型。由Paul Rook在20世纪80年代后期提出的，旨在改进软件开发的效率和效果。

V模型流程是从上至下，从左到右

①测试工程师在研发人员编程过程中，对其生成的代码函数做单元测试

②单元测试通过后进行集成测试

③集成测试通过后做系统测试、验收测试

v模型的特点：

• 单元和集成测试应检测程序的执行是否满足软件设计的要求
• 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标
• 验收测试确定软件的实现是否满足用户需要或合同的要求

v模型的缺点：

• 项目早期的缺陷，在后期才能发现
• 仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，只针对程序进行的寻找错误的活动，忽视了测试活动对需求分析,系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现。
• 不能体现“尽早地和不断地进行软件测试”的原则。

（2）W模型（双V模型）

W模型是在V模型的基础上演变而来的，一般又称为双V模型。在V模型中，研发活动没有完成、无任何输出物时，测试工程师无法开展测试工作，相对而言，测试活动严重滞后。为了解决V模型的缺点，W模型提出了测试活动与研发活动并行的概念，并且在生产流程演进过程中，增加了验证与确认活动。

W模型

W模型从用户需求开始，研发团队根据用户需求进行需求分析、概要设计、详细设计、编码开发等活动，测试团队则根据用户需求进行验收测试、系统测试、集成测试及单元测试设计。测试工作与研发活动分离，实现了并行操作。测试活动伴随着整个研发过程，而不仅在研发有成果输出后才参与。

W模型强调了测试活动不仅仅包括研发活动所产生的软件源代码，还考虑各种文档，如需求文档、概要设计文档、详细设计文档、代码等。

W模型要求测试活动从用户需求阶段就介入，有利于尽早地发现问题，在模型实施过程中，时刻进行确认（validation）、验证（verification）活动。

它强调，测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。

w模型的特点：

• 测试与开发是同步进行的，从而有利于尽早的测试、发现问题。
• 强调了测试计划等工作的先行和对系统需求和系统设计的测试；
• W模型有利于尽早地全面的发现问题

w模型的缺点：

仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整。

（3）X模型

X模型产生的背景亦与V模型有关，V模型的缺点是测试活动滞后于研发活动，无法尽早地开展测试活动。而X模型与W模型一样，提出的初衷都是解决V模型的缺点。

•X模型的基本思想是由Marick提出的， Robin F.Goldsmith进行了完善。X模型如图所示。

X模型左边表明针对单独的程序片段n进行独立的编码和测试活动，以此为基本过程，不断迭代，通过集成活动最终成为可执行程序，然后再对这些可执行程序进行测试。通过集成测试的成品可以进行封装并提交给系统测试环节或直接给用户。多条并行的曲线表示变更可以在各个部分发生。

X模型提出了探索性测试的概念。探索性测试与常规的测试方法不同，无须事先制定测试计划或设计，有经验的测试工程师可根据自己的思维活动及对被测对象的理解，在测试计划之外发现更多的软件错误。但探索性测试通常情况下仅作为其他测试方法的补充，因其消耗测试资源较多，且受制于测试工程师的经验，所以不能成为独立的测试方法。

x模型的特点：

• 很好地处理测试与开发的交接过程（交接的过程是一个时间段，而不是一个点）
• 左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序，然后再对这些可执行程序进行测试。
• 己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。
• X模型还定位了探索性测试，这是给有经验的测试人员在测试计划之外发现更多的软件缺陷。

x模型的缺点：

探索性测试可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

（4）H模型

H模型将测试活动与其他研发流程独立，测试活动分为测试准备与测试执行两个部分，便于测试设计与测试执行活动定义，如图所示。测试准备活动包括测试需求分析、测试计划、测试设计、测试编码、测试验证等，测试执行包括测试运行、测试报告、测试结果分析、确认回归测试等。

H模型与W模型一样，揭示了软件测试活动应该是一个独立的软件生产流程，贯穿整个软件生命周期，测试活动应该尽早准备、尽早执行，当测试准备工作完成后，一旦到达测试就绪点，就可开展测试执行活动，不会受制于研发活动。

H模型的特点：

• 充分地体现了测试过程
• 软件测试不仅仅指测试的执行, 还包括很多其他的活动
• 软件测试是一个独立的流程, 贯穿产品的整个开发周期, 与其它流程并发进行
• 软件测试要尽早准备, 尽早执行，具有很强的灵活性。
• 软件测试可以根据被测物的不同而分层次进行
• 不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点,测试执行活动就可以开展

H模型的缺点：

• 管理性要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制
• 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小
• 测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大的困难

（5）敏捷模型

强调从客户角度进行测试；

重点关注迭代测试新功能，不再强调测试阶段；

尽早测试，不间断测试，具备条件即测试；

强调持续反馈；

预防缺陷重于发现缺陷；

--------------------------------------------敏捷测试与传统测试的区别-------------------------------------------------

--------------传统测试：--------------

测试是质量的最后保护者；

严格的变更管理；

预先的计划和细节的准备；

重量级文档；

各阶段测试严格的入口和出口标准；

更多在回归测试时进行重量级的自动化测试；

严格依赖流程执行；

测试团队和开发团队是相对独立的；

--------------敏捷测试：--------------

开发和测试人员是紧密合作，大家都有责任对软件负责；

变更是可接受的，拥抱变更；

计划随着进展时常调整；

只需要绝对必要的文档；

各迭代之间已经没有明显的入口和出口标准；

所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分；

流程不再需要严格执行；

团队合作是无缝隙合作；