【软件测试】敏捷模型（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 模型并不能解除测试管理面临着困惑