软件研发模型和软件测试模型

软件研发模型和软件测试模型

笔者：风起怨江南 出处：https://blog.csdn.net/JackMengJin 笔者原创，文章欢迎转载，如果喜欢请点赞+关注，谢谢支持！

软件研发模型（Software Development Model）

指软件开发全过程、活动和任务的结构框架。
意义：使用研发模型可以提高软件效率，降低研发成本，提高软件质量。
常见的研发模型包括需求、设计、编码、测试和维护阶段。
软件开发模型能清晰直观表达开发全过程，同时也明确规定了要完成的主要活动和任务，故研发模型用来作为软件项目工作的基础。
软件研发模型有：瀑布模型、快速原型模型、螺旋模型、RUP流程和敏捷模型等。

软件测试模型（Software Test Model）

意义：软件测试根据不同的测试对象以及测试项目的背景可采用不同的测试模型实施测试活动。
软件测试模型有：V模型、W模型、H模型、X模型、敏捷测试模型等。
具体分类如下表所示：

软件研发模型	软件测试模型
瀑布模型	V模型
快速原型模型	W模型
螺旋模型	H模型
RUP流程	X模型
敏捷模型	敏捷测试模型

详细介绍
一.软件研发模型
1.1 瀑布模型
时间：1970年由温斯顿.罗伊斯（Winston Royce）提出。
前身：瀑布模型最早根据工业流水线演变过来。
核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开。

软件生命周期划分六个活动，各个活动严格按照线性方式进行，当前活动接收上一项活动的工作结果，实施完成所需的工作内容。
当前活动的工作结果需要进行验证，验证通过后该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改，直到项目成功。
瀑布模型过于强调文档的作用，要求每个阶段都要仔细验证，适合一些规模小，需求明确的项目研发。
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加工作量。
2）由于开发模式是线性，用户只有等到整个过程的末期才能见到开发成果，增加开发风险。
3）而此时活动滞后，导致需要等到开发后期的测试阶段才能开始发现问题，不利于项目研发。
4）不能适应用户需求的变化。
总结：随着发展，软件的功能越来越多，瀑布模型已经不再适合现代软件开发模式，几乎被业界抛弃。

1.2 快速原型模型（又称原型模型）
前身：在瀑布模型基础上演进的一种研发模型，更关注需求的正确性，同时也更加符合开发软件的习惯。

快速原型模型需要迅速建造一个可以运行的软件原型，以便使开发人员和用户尽快确定需求，达成共识，使开发出的软件能够真正反应用户的需求。
原型模型采用逐步求精的方法来完善原型。
总结：从测试角度来看，相比较瀑布模型，测试人员可以在快速原型模型的研发模型期便可以入手，进行测试策略、测试计划、用例设计等测试工作。

1.3 螺旋模型
时间：1988年由巴利玻姆（Barry Boehm）发表。
特点：将瀑布模型和快速原型模型结合起来，强调了风险分析，适合大型复杂系统。

螺旋模型（Spiral Model）采用周期性方法来进行系统开发。在每一个象限里使用瀑布模型法（每个周期都包括制定计划、风险分析、实施工程和客户评估4个阶段，由这4个阶段进行迭代），它把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有主要风险因素都被确定。
四大象限：
1）制定计划——确定软件目标，选定实施方案，弄清项目开发的限制条件。
2）风险分析——分析评估所选方案，由风向专家识别和消除风险。
3）实施工程——实施软件开发和验证。
4）客户评估——评价开发工作，提出修正建议，制定下一步计划。
缺点：成本过高，商业模式下不采用该模型，但安全系数极高，军方应用较多。

1.4 RUP流程
RUP（Rational Unified Process），由Rational公司（已被IBM并购）提出的一种统一软件开发过程。
核心：以用例驱动和体系结构为核心的增量迭代的软件过程模式。

关于RUP的2个轴：
横轴——时间轴，体现了开发过程的动态结构，是过程的生命周期，主要用来描述软件的周期、阶段、迭代和里程碑。
纵轴——工作流，体现开发过程的静态结构，主要用来描述软件活动的工作流。
阶段：
1）初始化阶段——关注整个项目进行中业务和需求方面的主要风险。
2）细化阶段——分析问题领域，建立完善的体系结构基础，编制项目计划，规避项目中风向较大的元素。为项目建立支持环境，包括模板、准则和工具。
3）构造阶段——开发人员对所有构件和应用程序进行集成，并进行详细的集成测试。某种意义上说构建阶段是一个制造过程，重点放在管理资源及控制运作以优化成本、进度和质量。
4）发布阶段——重点确保软件对最终用户是可用的，可以跨越几次迭代，包括为发布作准备的产品测试，基于用户的反馈进行少量的调整。
工作流：
1）业务建模（Business Modeling）——描述如何为一个新的目标组织开发一个构想，并给予这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。
2）需求（Requirement）——描述系统应该做什么，并使开发人员和用户达成共识。最重要是理解系统所解决问题的定义和范围。
3）分析和设计（Analysis&Design）——将需求转化为系统设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，并优化其性能。最终生成设计模型和一个可迭代的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。描述主要体现了类的对象如何协同工作实现用例的过程。
4）实现（Implementation）——将层次化的子系统形式定位代码为组织结构，以组件的形式（源文件、二进制文件、可执行文件）实现类和对象，将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结构，使其称为可执行的系统。
5）测试（Test）——通过可靠性、功能性、系统性能（三维模型）进行测试。在整个项目中进行测试，尽早发现缺陷。
6）部署（Depoyment）——描述了与确保软件产品对用户具有可用性相关的活动，包括：软件打包、安装软件、为用户提供帮助。也包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
7）配置和变更管理（Configuration&Chagement）——工作流描述了如何管理并行开发、分布式开发以及自动化创建工程。
8）项目管理（Project Management）——平衡各个部门之间可能产生冲突的目标，客服约束并成功交付用户满意的产品。目标包括为项目管理提供框架，为计划、人员配备、执行和监控项目提供实用准则，为管理风险提供框架。
9）环境管理（Environment Management）——该工作流向软件开发提供软件开发环境，集中配置和支持项目过程中需要的活动，提供指导手册并介绍如何在组织中实现过程管理。

1.5 敏捷模型
时间：2001年，敏捷联盟成立，提出敏捷开发的概念。
核心：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
敏捷开发中一个大项目分为多个相互联系且可以独自运行的小项目，分别完成。此过程中软件一直处于可使用状态。
宣言：尽早的、持续的交付有价值的软件来使客户满意。

原则：
1）快速迭代——敏捷中版本发布更快，采用小版本，需求、开发和测试更加简单快速。
2）测试人员和开发者参与需求讨论——以研讨会的形式定义可测试的需求并确定需求优先级，优点是可以充分利用团队成员间互补特性，提高效率。
3）编写可测试的需求文档——站在用户的角度编写需求文档，不能过早涉及技术实施方案，否则会降低对需求的注意力。
4）多沟通，减少文档——面对面沟通效率远远大于邮件效果。
5）做好产品原型——图解模型。
6）及早考虑测试——提早设计编写测试用例，测试在敏捷开发中及其重要。

二.软件测试模型
2.1V模型
V模型也称为RAD（Rap Application Development，快速应用开发，简称RAD），模型构图形似字母V。
V模型通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。
时间：20世纪80年代由PaulRook提出。

V模型中的过程从左到右，描述了基本的开发过程和测试行为。
核心：V模型的价值在于它强调软件开发的协作和速度，反映测试活动和分析设计关系，将软件实现和验证结合起来。明确了测试过程中存在不同的级别，并清楚描述测试的各个阶段与开发过程中的各个阶段之间的对应关系。
缺点：测试过程在编码之后，需求分析前期产生的错误要到后期的验证测试才能发现，忽略了测试活动对需求分析、系统设计等活动的验证和确认。
总结：V模型适用于项目比较小、周期短的项目，该模式已渐渐被淘汰。

2.2 W模型
前身：V模型，由Evolutif公司提出。
新增：增加软件开发各阶段中同步进行的验证和确认活动。
W模型由两个V组成，分别代表开发和测试过程，明确禀明开发和测试的并行关系。

W模型就是V&V模型，即验证（Verification）和确认（Validation），是在模型实施过程中进行。
定义：W模型就是验证是否做了正确的事情和确认是否把事情做正确。
1）验证——保证软件正确实现特定功能，验证是否满足软件生命周期过程中的标准和约定，判断每一个软件生命周期活动是否完成。
2）确认——保证所生产的软件可追溯到用户需求，确认过程是否满足系统需求，解决相应问题。
遵循：要求测试活动从用户需求介入，测试人员应该参与到对需求文档的验证和确定活动中，以尽早找到缺陷所在。
需求：对需求的测试有利于及时了解项目难度和测试风险，及早制定应多措施，这将逐渐减少总体测试时间，加快项目进度，有利于尽早地发现问题。
缺点：在W模型中，需求、设计、编码等活动被视为串行，同时测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束后，才可正式开始下一个阶段工作，无法支持迭代开发模式。
总结：W模型测试伴随整个软件开发周期，被测对象不仅仅是程序，需求，设计以及每个阶段输出的文档同样需要测试，也就是说测试与开发是同步进行。

2.3 H模型
定义：H模型的软件测试活动是完全独立的，将测试准备和测试执行分离。
优点：有利于资源调配，降低成本，提高测试效率。

准备：测试需求分析、测试计划、测试设计、测试用例、测试验证。
执行：测试运行、测试报告、缺陷分析、回归测试。
总结：H模型贯穿整个产品生命周期，与其他流程并发进行。只要某个测试达到准备就绪点就可以开展测试执行活动，不同的测试活动可按照次序先后，反复进行。

2.4 X模型
前身：有Marick提出，Robin F.Goldsmith将其思想定义为X模型。
X模型左边描述是针对单独程序片段所进行的相互分离的编码和测试，通过频繁交接，最终集成为可执行的程序，再对这些可执行的程序进行测试。
理念：探索性测试，不进行实现计划的特殊类型测试，发散性测试。
优点：能发现更多测试计划之外的错误。
缺点：对测试人员要求极高，时间、人力、物力等成本增加。

2.5 敏捷测试模型
敏捷测试（Agile Testing）通过不断修正质量指标，正确建立测试策略，确认客户有效需求来保证产品质量。
定义：敏捷测试遵循测试实践，强调从客户角度（从使用系统用户角度）来测试系统。

敏捷测试主旨：测试驱动开发。
对测试人员要求：
1）理解敏捷的核心价值观：沟通、反馈、尊重、学习、分享。
2）具备测试基本技能，如自动化测试、白盒测试等。

说明：本文由作者参考学习《软件测试技术指南》等相关资料编写，供大家学习交流。