【软件测试】敏捷模型（Scrum模型）和V模型、W模型

敏捷模型

前面的那些模型以前非常流行，但现在开发人员在使用的时候会遇到各种问题。主要困难包括在项目开发期间处理来自客户的变更请求，以及合并这些变更所需要的高成本和时间。

• 在实际工作中，一款产品的功能是不断在变化的

---

所以为了克服这些缺点，就提出了敏捷软件开发模型。在敏捷模型中，需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的。

• 敏捷模型主要旨在帮助项目快速适应变更请求。因此，敏捷模型的主要目的是促进项目的快速完成
• 敏捷性是通过是过程适应项目，删除对特定项目可能不是必须的活动来实现的
• 避免任何浪费时间和精力的事情

敏捷模型中有一个非常重要的《敏捷宣言》：

• 个体与交互重于过程和工具（强调高效沟通）
• 可用的软件重于完备的文档（强调轻文档，文档不应该作为工作验收的标准）
• 客户协作重于合同谈判（主动了解当下的需求）
• 响应变化重于遵循计划（能够主动迎接变化）
  总结出敏捷模型的四个特点：轻文档、轻流程、重目标、重产出

scrum

敏捷开发有很多种⽅式，其中 Scrum 是⽐较流⾏的⼀种。在 Scrum 模型中，主要有三个角色和五个重要会议

三个角色

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

迭代开发

与瀑布不同，Scrum 将产品的开发分为若干个小 sprint（迭代），其周期从 1 周到 4 周不等。参与的团队一般是 5 到 9 人。每期迭代要完成的 user story 是固定的，每次迭代会产生一定的交付

五个重要会议：

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

敏捷中的测试

轻文档和快速迭代

• 敏捷模型中强调轻文档，所以测试人员不应使用传统的 Excel 填写测试用例的方法，更多的是使用思维导图、探索性测试（强调自由度，设计和执行同时进行，根据测试结果不断调整测试计划）、自动化测试等
• 敏捷讲求合作，在敏捷项目组中，测试人员应主动跟开发人员了解需求、讨论设计、一起研究 bug 出现的原因

测试模型

V 模型

• V 模型中，明确的标注了测试过程中存在的不同类型的测试
• 右边的测试，都需要参考左边对应高度的要求

缺点：
仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。缺点和瀑布模型一样

---

W 模型（双 V 模型）

V 模型中未将测试前置的问题在 W 模型中得以解决

• 开发 V 模型并不是单单指编码阶段，而是为产品开发流程而实施的各个阶段
• 测试的对象不仅是程序，需求、设计等同样需要测试，测试与开发时同步的

缺点：

• 去求、设计、编码等活动被视为串行的
• 测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作
• 重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W 模型并不能解除测试管理面临着困惑