测试中的敏捷开发模型

什么是敏捷方法论？

敏捷方法论

什么是敏捷开发？

敏捷开发方法是将业务需求的转化为解决方案的最简单，有效的过程之一。敏捷是一个用来描述变化的术语，它鼓励人们灵活应对变化。

敏捷软件开发强调四个核心价值.

个人和团队通过流程和工具进行交互
工作的软件胜过全面的文档
通过迭代讨论进行客户协作
响应变化，而不是遵循计划

在本敏捷项目管理教程中，将了解-

什么是敏捷方法论
敏捷模型与瀑布模型
Scrum
产品积压
Scrum实践
Scrum方法的流程：
极限编程(XP)
极限编程的各个阶段：
水晶方法论
动态软件开发方法(DSDM)
功能驱动开发(FDD)
精益软件开发
看板
敏捷指标

敏捷模型与瀑布模型

敏捷和瀑布模型是两种不同的软件开发过程方法.虽然它们的方法不同，但根据需求和项目类型的不同，这两种方法有时都很有用.

敏捷模式	瀑布模型
敏捷方法论定义：敏捷方法论提出增量和迭代的软件设计方法	瀑布模型：软件开发按照从起点到终点的顺序进行
软件工程中的敏捷过程被分解为设计人员处理的单个模型	设计过程不分成单个模型
客户有早期和频繁的机会查看产品，并对项目做出决策和更改	客户只能在项目结束时看到产品
与瀑布模型相比，敏捷模型被认为是非结构化的.	瀑布模型更安全，因为它们是面向规划的
小项目可以很快实现.对于大型项目，很难估计开发时间.	各种项目都可以估算完成.
错误可以在项目中途修复	只有在最后，才会对整个产品进行测试.如果发现需求错误或必须进行任何更改，则项目必须从头开始
项目在短(2-4) 开发过程是迭代的，周的迭代中执行.计划很少.	开发过程是阶段性的，阶段比迭代大得多.每个阶段都以对下一阶段的详细描述结束
与软件开发相比，文档的优先级较低	文档是重中之重，甚至可以用于培训员工和与其他团队一起升级软件
每个迭代都有自己的测试阶段.它允许在每次发布新函数或逻辑时实现回归测试.	只有在开发阶段之后，才会执行测试阶段，因为单独的部件不是完全起作用的.
在迭代结束时的敏捷测试中，产品的可发货功能将交付给客户.当与客户有很好的联系时，这是很有用的.	在漫长的实现阶段之后，所有开发的功能都会立即交付.
测试人员和开发人员一起工作	测试人员与开发人员分开工作
每次冲刺结束时，都会执行用户接受	用户验收在项目结束时执行.
它需要与开发人员密切沟通，共同分析需求和规划	开发人员不参与需求和规划过程.通常，测试和编码之间的时间延迟

敏捷流程

下面的就是敏捷方法流程，用以快速交付可用的系统.

敏捷流程模型

敏捷测试中存在各种敏捷方法，下面列出了这些方法：

Scrum

Scrum是一种敏捷开发方法，它特别关注如何在基于团队的开发环境中管理任务。敏捷和Scrum由三个角色组成，它们的职责解释如下：

Scrum方法

Scrum Master
- 负责组建团队，冲刺会议，扫除前进障碍
产品所有者
- 产品负责人创建产品待办事项，确定待办事项的优先顺序，并负责在每次迭代中交付功能
Scrum团队
- 团队管理自己的工作，并组织工作以完成冲刺或循环

产品积压

requirements(user stories) 这是一个存储库，其中跟踪需求，并提供每个版本要完成的编号的详细信息。团队还可以求添加、修改或删除新需求。

Scrum实践

详细介绍了实践：

Scrum方法的流程：

Scrum测试流程如下：

Scrum的每一次迭代都称为冲刺
产品积压是输入所有详细信息以获取最终产品的列表
在每次冲刺期间，都会选择产品积压的顶级用户故事，并将其转化为冲刺积压
团队处理定义的冲刺积压
团队检查日常工作
在冲刺结束时，团队交付产品功能

极限编程(XP)

当客户的需求或需求不断变化时，或者当他们不确定系统的功能时，极限编程技术非常有用.它提倡XP开发软件的频繁“发布”，使客户保持在目标位置。

极限编程

业务需求是以故事的形式收集的。所有这些故事都存放在一个叫停车场的地方。

在这种类型的方法中，发布基于称为迭代的较短周期，跨度为14天。每次迭代都包括编码、单元测试和系统测试等阶段，在每个阶段都会在应用程序中构建一些次要或主要的功能.。

极限编程的各个阶段：

敏捷XP方法有6个阶段，具体说明如下：

规划

确定相关者和发起人
基础设施要求
与安全相关的信息和收集
服务级别协议及其条件

分析

故事编排
任务优先级评估
故事情节评估
SPAN(Time) 定义迭代
开发团队和QA团队的资源规划

设计

任务细分
为每项任务准备测试场景
回归自动化框架

执行

编码
单元测试
手动测试场景的执行
缺陷报告
手工回归测试用例向自动化回归测试用例的转换
迭代中期评审
迭代结束评审

包装

小版本
回归测试
演示和评论
根据需要开发新故事
基于迭代结束评审注释的过程改进

闭合

试点下水
培训
投产启动
服务级别协议保证保证
审查soa战略
上线支持

每天可以使用两个故事板来跟踪工作，下面列出了这两个故事板以供参考.

故事看板
- 这是一种传统的方式，以便条的形式收集黑板上的所有故事，以跟踪XP的日常活动。由于此手动活动需要更多的精力和时间，因此最好切换到在线表单.
联机故事看板
- 在线工具故事板可以用来存储故事.几个团队可以将其用于不同的目的.

水晶方法论

水晶方法论基于三个概念

评估阶段：此阶段涉及的各种活动包括创建开发团队、可行性分析、制定初步计划和微调开发方法
循环交付：主要开发阶段由两个或多个交付周期组成，在此期间
1. 团队更新和细化发布计划
  1. 通过一个或多个程序测试集成迭代实现需求子集
    1. 集成产品交付给真实用户
      1. 审查项目计划和采用的发展方法
总结：此阶段执行的活动是部署到用户环境，执行部署后检查和反思.

动态软件开发方法(DSDM)

DSDM是一种用于软件开发的快速应用程序开发(RAD) 方法，并提供了敏捷的项目交付框架。DSDM中使用的主要技术有

时间框
MoSCoW规则
原型制作

DSDM项目由7个阶段组成

项目前
可行性研究
业务学习
功能模型迭代
设计和构建迭代
实现
交付

功能驱动开发(FDD)

这种方法主要关注“设计和构建”特性。与软件工程中的其他敏捷方法不同，FDD描述了非常具体和简短的工作流程开发产品，并保持目标中的以下内容：

域对象建模
按功能开发
组件/类关系
团队特色
检查
配置管理
日构建
进度和结果的可见性

精益软件开发

精益软件开发方法是基于“准时生产”的原则.精益开发可以概括为七个步骤.

杜绝浪费
放大学习
推迟承诺(尽可能晚地做出决定)
提早交货
为团队放权
完整构建流程
整体优化

看板

看板最早出现在日语单词中，意思是一张卡片，其中包含产品在完成过程中每个阶段需要完成的所有信息。这种框架或方法在软件测试方法中被广泛采用，特别是在敏捷概念中。

Scrum vs看板

Scrum	看板
在Scrum技术中，测试必须被分解，以便它们可以在一次冲刺中完成	没有规定特定的项目大小
规定了按优先级排列的产品待办事项	优先级排序是可选的
Scrum团队致力于迭代的特定量工作	承诺是可选的
开了燃尽表.	没有规定特定的项目大小
在每次冲刺之间，重置一个Scrum板	看板是坚持不懈的。它限制处于工作流状态的项目数
它不能将项目添加到正在进行的迭代中	只要容量可用，它就可以添加项目
间接限制工作进程	直接限制工作进程
规定时间框和迭代次数	时间框和迭代次数(可选)

敏捷指标：

为有效使用敏捷可以收集的指标包括：

阻力系数
- 对冲刺目标没有贡献的小时数内的努力
- 可以通过减少共享资源的数量、减少非贡献工作量来提高阻力系数
- 新的估算值可以增加阻力系数的百分比——新估计=（旧估计+阻力系数）
速度
- 转换为 sprint 的可交付功能的积压（用户故事）数量
添加的单元测试数量
完成每日构建所需的时间间隔
在迭代或以前的迭代中检测到的错误
生产缺陷泄漏