【软件测试】3.开发模型

1.常见的开发模型

1.1瀑布模型

1.2螺旋模型

1.3增量模型和迭代模型

1.4敏捷模型

1.4.1特点：

1.5Scrum模型（三个角色和五个重要会议）

1.5.1三个角色：

1.5.2Scrum工作流程（五个会议）

1.6测试模型

1.6.1V模型

1.6.2W模型（双V模型）

1.常见的开发模型

1.1瀑布模型

需求分析——计划——设计——编码——测试

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。

特点：瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

1.优点：

强调开发的重要性。
线性结构，每个阶段都只执行一次。
是其他模型的基础框架。

2.缺点：

测试后置前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会。必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差）。
周期太长，产品很迟才能被看到或者使用，可能会导致需求/功能过时。

瀑布模型使用场景：需求固定的小项目。

1.2螺旋模型

特点：螺旋模型中各个阶段都引入了风险分析+原型

引入的目的：是为了减少各阶段遗留的风险问题，避免吧问题遗留到后面阶段

1.优点：

强调严格的全过程风险管理。
强调各开发阶段的质量。
增加风险分析和模型。

2.缺点：

项目中可能存在的风险性和风险管理人员的技能水平有直接联系。
需求人员、资金、时间的增加和投入，可能会导致项目的成本太高。

适用场景：规模庞大、复杂度高、风险性大的项目。

1.3增量模型和迭代模型

增量模型和迭代模型配合使用。

使用场景：大型项目，需求不明确。

1.4敏捷模型

主要困难包括在项目开发期间处理来自客户的变更需求以及合并这些变更所需的高成本和时间。为了克服这些模型的缺点，在1990年代中期提出来了敏捷软件开发模型。

敏捷模型主要旨在帮助项目快速适应变更请求。

在敏捷模型中，需求被分解成许多可以增量开发的小部分。

敏捷模型非常重要的内容：

个体与交互重于过程和工具。（强调高效的沟通）
可用的软件重于完备的文档。（强调轻文档，文档不应该作为工作验收的标准）
客户协作重于合同谈判。（及时了解当下需求）
响应变化重于遵循计划。（能够主动迎接变化）

1.4.1特点：

轻文档、轻流程、重目标、重产出

1.5Scrum模型（三个角色和五个重要会议）

1.5.1三个角色：

scrum由product owner （产品经理）、scrum master（项目经理）和team（研发团队）组成。

其中product owner 负责整理user story（用户故事），定义其商业价值，对其进行排序，制定发布计划，对产品负责。
scrum master复杂召开各种会议，协调项目，为研发团队服务。
研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标、交付产品

迭代开发：

每次迭代会产生一定的交付。

1.5.2Scrum工作流程（五个会议）

产品负责人负责整理user story ，形成左侧的product backlog。
发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初统计。
每日例会：每天Scrum master召开站立会议，团队成员回答昨天做了什么，今天计划做什么，有什么问题。
延时会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，形成新的story。
回顾会议：项目团队对本次迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。（回顾上一次迭代过程中的问题，不断优化）

敏捷中的测试：

轻文档和快速迭代：