软件测试从零到精通笔记（02）软件工程与生命周期
软件测试从零到精通--软件工程与生命周期
- 1、软件危机与软件工程
-
- 1.软件危机
- 2.软件工程
- 2、软件生命周期
-
- 1.可行性分析阶段
- 2.需求分析阶段
- 3.软件设计阶段
- 4.软件测试阶段
- 5.软件运行和维护阶段
- 3、模型分类
-
- 1.迭代模型（重点）
- 2.快速原型模型（重点）
- 3.瀑布模型
- 4.增量模型
- 5.螺旋模型
- 4、各种模型的特点
1、软件危机与软件工程
1.软件危机
软件危机（英语：Software Crisis）：是早期计算机科学的一个术语，是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题皆可能导致软件产品的寿命缩短、甚至夭折。 软件开发是一项高难度、高风险的活动，由于它的高失败率，故有所谓“软件危机”之说。 软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之计算机的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说，它谈到了写出正确、可理解、可验证的计算机程序的困难。
何谓软件危机危机其原因，衔接到硬件的整体复杂度，与软件开发流程。危机表现在几个方面：
- 项目运行超出预算。
- 项目运行超过时间。
- 软件质量低落。
- 软件通常不匹配需求。
- 项目无法管理，且代码难以维护。
2.软件工程
软件工程：是一门研究用工程化方法构建和维护有效、实用和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，也提高了工作效率和生活效率 。
2.1、软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下四个方面：
- P（Plan）——软件规格说明。规定软件的功能及其运行时的限制。
- D（DO）——软件开发。开发出满足规格说明的软件。
- C（Check）——软件确认。确认开发的软件能够满足用户的需求。
- A（Action）——软件演进。软件在运行过程中不断改进以满足客户新的需求。
2.2、从软件开发的观点看，它就是使用适当的资源（包括人员，软硬件资源，时间等），为开发软件进行的一组开发活动，在活动结束时输入（即用户的需求）转化为输出（最终符合用户需求的软件产品）。
2.3、定义阶段：可行性研究初步项目计划、需求分析；开发阶段：概要设计、详细设计、实现、测试；运行和维护阶段：运行、维护、废弃
原则：1、抽象；2、信息隐蔽；3、模块化；4、局部化；5、确定性；6，一致性；7、完备性；8、可验证性
2、软件生命周期
软件生命周期(Software Life Cycle,SLC)：是软件的产生直到报废或停止使用的生命周期。软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，也有将以上阶段的活动组合在内的迭代阶段，即迭代作为生命周期的阶段。
1.可行性分析阶段
1.1、问题定义
概念：定义出本次任务都需要做什么，做成什么样子（比如，买家跟卖家说我要什么样子的衣服，然后双方开始协商，最终达成一致意见，这个过程就是需求定义）。
参与者：
- 产品经理，需求分析师，客户
1.2、可行性分析
概念：由项目组相关成员去研究需求是否可行，能不能做出来（比如：商家拿订单需求去找设计和工厂，问设计图形或者样式能否做出来；问工厂在相应的布料上能不能做出设计图样式的衣服，这个过程就是可行性分析）
参与者：
- 产品经理，架构师，项目经理，开发
2.需求分析阶段
2.1、需求分析
概念：需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个框每个按钮的样式，输入输出等各项值（比如：设计和工厂分别就这个衣服做材料分析，分析出这个衣服需要多少布料，扣子什么样式、颜色，不同布料具体用多少等等，这个过程叫做需求分析）；统一整理编写成《需求说明书/需求规格说明书》。
参与者：
- 产品经理，架构师，项目经理，测试/质量管理员、开发
2.2、需求评审
概念：评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与
参与者：
- 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核。
- 比如需求评审，一般是产品经理、项目经理、测试、开发一起评审。
- 系统设计一般是项目经理、开发评审；测试策略评审一般是测试组内部评审等。
3.软件设计阶段
3.1、概要设计和详细设计
概念：架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口参数、参数等。此处设计会形成概要设计文档和详细设计文档。
参与者：
- 项目经理，架构师，开发，测试
3.1、软件编码
概念：开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现
参与者：
- 开发
4.软件测试阶段
4.1、软件测试
概念：开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具任务流方式向测试部门通知xxx模块/功能可以测试
参与者：
- 任务责任人(开发)、测试
4.2、测试策略
概念：测试组长要根据《任务说明书》和《需求说明书》来决定此次测试的思路/类别（功能测试/性能测试/文档性测试或者几种组合）、测试方式方法、flag（任务指标，做到什么程度）等。也有很多公司把测试策略作为测试方案中的一部分。
参与者：
- 测试组长/测试leader/自身的测试工程设计师
4.3、测试计划
概念：测试组长要根据《任务说明书》和《需求说明书》开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
参与者：
- 测试组长/测试leader
4.4、测试方案
概念：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《需求说明书》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。
参与者：
- 测试工程师
4.5、测试设计
概念：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。同样，测试用例也需要评审。
参与者：
- 相关测试工程师
4.6、测试执行
概念：根据测试用例对开发提测部分进行，通过的标记通过，不通过的提交有质量的Bug（问题缺陷）。这里要说下bug，测试对出问题的部分提交bug到相关开发工程师，开发根据问题描述，进行修订，修订完成后会将bug流转给相关测试人员（通过缺陷管理工具分配/邮件通知相关测试人员bug修订完成，可测)，测试需要对bug以及bug相关模块进行测试回归。
参与者：
- 相关测试工程师、责任开发工程师
4.7、测试报告
概念：最终测试完成（所有测试用例通过/已挂起）会出测试报告对以上测试进行总结性描述。
参与者：
- 相关测试工程师
5.软件运行和维护阶段
5.1、部署/发版
概念：经过前面的各个阶段，产品已经可以出售或者面见大众了；由测试进行冒烟测试，冒烟测试通过后配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。
参与人：
- 配置管理人员，测试
5.2、支持维护
概念：支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。
参与人：
- 支持维护人员/售后工程师
3、模型分类
从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。典型的几种生命周期模型包括：迭代模型、快速原型模型、瀑布模型、增量模型、螺旋模型。
1.迭代模型（重点）
迭代式模型是RUP（Rational Unified Process，统一软件开发过程）推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
优点：
- 在需求分析阶段就给出了相对完成的架构设计方案，便于后面迭代的扩展和完善；
- 第一阶段核心功能交互用户后，可以及早获取反馈结果，对后期的迭代起到指导作用；
- 人员分配灵活，前期不用投入很多人力；
- 在前期能够很好的控制风险，并且解决难度系数较低，影响范围也较小。
缺点：
- 对项目需求明晰度要求很高；
- 对整个项目周期要求较宽裕，政治任务需排除。
2.快速原型模型（重点）
快速原型模型需要迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
2.1、探索型原型
这种类型的原型是把原型用于开发的需求分析阶段，目的是要弄清用户的需求，确定所期望的特性，并探索各种方案的可行性。它主要针对开发目标模糊，用户与开发都对项目都缺乏经验的情况，通过对原型的开发来明确用户的需求。
2.2、实验型原型
这种原型主要用于设计阶段，考核实现方案是否合适，能否实现。对于一个大型系统，若对设计方案心中没有把握时，可通过这种原型来证实设计方案的正确性。
2.3、演化型原型
这种原型主要用于及早向用户提交一个原型系统，该原型系统或者包含系统的框架，或者包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。
优点：
- 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
- 这种模型适合预先不能确切定义需求的软件系统的开发。
缺点：
- 所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
- 使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
3.瀑布模型
瀑布模型（Waterfall Model） 是一个软件生命周期模型，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
3.1、传统瀑布模型
阶段间具有顺序性和依赖性
必须等前一阶段的工作完成之后，才能开始后一阶段的工作。前一阶段的输出文档就是后一阶段的输入文档。
推迟实现的观点
清楚的区分逻辑设计与物理设计，尽可能推程序的物理实现，是因为编码之前阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性的后果。实践也表明，对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。
质量保证的观点
每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
3.2、加入迭代过程的瀑布模型
传统的瀑布模型过于理想化，人在工作过程中不可能不犯错误。
特点：当后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。
优点：
- 为项目提供了按阶段划分的检查点。
- 当前一阶段完成后，您只需要去关注后续阶段。
- 可在迭代模型中应用瀑布模型。
- 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点：
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
- 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
- 瀑布模型的突出缺点是不适应用户需求的变化。
4.增量模型
增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交
优点：
能在较短的时间内向用户提交可完成部分工作的产品
将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整
缺点
由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性
如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程
————————————————
版权声明：本文为CSDN博主「「已注销」」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zjuwxx/article/details/97308688
5.螺旋模型
螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。
5.1、简化的螺旋模型
5.2、完整的数据模型
5.3、四种象限
- 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
- 风险分析：分析评估所选方案，考虑如何识别和消除风险；
- 实施工程：实施软件开发和验证；
- 客户评估：评价开发工作，提出修正建议，制定下一步计划。
优点：
- 设计上的灵活性,可以在项目的各个阶段进行变更。
- 以小的分段来构建大型系统,使成本计算变得简单容易。
- 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
- 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
- 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点：
- 很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出- 现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
4、各种模型的特点
| 模型名称 | 技术特点 | 适用范围 |
|---|---|---|
| 瀑布模型 | 简单，分阶段，阶段间存在因果关系，各个阶段完成后都有评审，允许反馈，不支持用户参与，要求预先确定需求 | 需求易于完善定义且不易变更的软件系统 |
| 快速原型模型 | 不要求需求预先完备定义，支持用户参与，支持需求的渐进式完善和确认，能够适应用户需求的变化 | 需求复杂、难以确定、动态变化的软件系统 |
| 增量模型 | 软件产品是被增量式地一块块开发的，允许开发活动并行和重叠 | 技术风险较大、用户需求较为稳定的软件系统 |
| 迭代模型 | 不要求一次性地开发出完整的软件系统，将软件开发视为一个逐步获取用广需求、完善软件产品的过程 | 需求难以确定、不断变更的软件系统 |
| 螺旋模型 | 结合瀑布模型、快速原型模型和迭代模型的思想，并引进了风险分析活动 | 需求难以获取和确定、软件开发风险较大的软件系统 |