软件测试中的敏捷方法

什么是测试中的敏捷方法论？

敏捷方法论指的是一种在软件开发生命周期中，促进开发和测试持续迭代的实践。在软件测试的敏捷模型中，开发和测试活动是并发进行的，这与瀑布模型不同。

什么是敏捷软件开发？

敏捷软件开发方法论是将业务需求愿景转化为软件解决方案的最简单有效的流程之一。敏捷是一个术语，用于描述采用持续规划、学习、改进、团队协作、演进式开发和早期交付的软件开发方法。它鼓励对变化做出灵活响应。

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

个体和互动高于流程和工具
可工作的软件高于详尽的文档
客户协作高于合同谈判
响应变化高于遵循计划

敏捷模型 vs 瀑布模型

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

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

另请查看：- 敏捷与瀑布：了解方法论之间的区别

敏捷流程

查看以下敏捷方法论流程以快速交付成功的系统。

敏捷测试中存在各种敏捷方法，如下所示：

Scrum

SCRUM 是一种敏捷开发方法，它特别关注如何在一个基于团队的开发环境中管理任务。基本上，Scrum 源自橄榄球比赛中发生的活动。Scrum 相信赋能开发团队，并倡导在小团队（例如 7 到 9 名成员）中工作。敏捷和 Scrum 由三个角色组成，其职责解释如下：

Scrum Master
- Scrum Master 负责组建团队、冲刺会议并消除进展障碍。
产品负责人
- 产品负责人创建产品待办列表，优先排序待办列表，并负责在每次迭代中交付功能。
Scrum 团队
- 团队管理自己的工作并组织工作以完成冲刺或周期。

产品待办列表

这是一个存储库，其中跟踪了需求以及每个版本要完成的需求数量（用户故事）的详细信息。它应由产品负责人维护和优先排序，并应分发给 Scrum 团队。团队还可以请求添加、修改或删除新需求。

Scrum 实践

详细描述了实践。

Scrum 方法论的流程

Scrum 测试的流程如下：

Scrum 的每次迭代都称为 Sprint。
产品待办列表是一个包含获取最终产品所需的所有详细信息的列表。
在每个 Sprint 期间，会选择产品待办列表中的顶部用户故事，并将其转化为 Sprint 待办列表。
团队在定义的 Sprint 待办列表上工作。
团队检查每日工作。
在冲刺结束时，团队交付产品功能。

极限编程 (XP)

当客户需求或系统功能不断变化或不确定时，极限编程技术非常有用。它倡导在短开发周期内频繁“发布”产品，这本质上提高了系统的生产力，并引入了一个检查点，可以轻松实现任何客户需求。XP 开发软件时始终以客户为中心。

业务需求以故事的形式收集。所有这些故事都存储在一个名为“停车场”的地方。

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

极限编程的阶段

敏捷 XP 方法中有 6 个阶段，解释如下：

规划

利益相关者和赞助商的识别
基础设施要求
安全相关信息和收集
服务级别协议及其条件

分析

在停车场捕获故事
在停车场优先排序故事
故事估算清洗
定义迭代跨度（时间）
开发和 QA 团队的资源规划

设计

任务分解
每个任务的测试场景准备
回归自动化框架

执行

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

收尾

小规模发布
回归测试
演示和评审
根据需要开发新故事
根据迭代结束评审意见进行流程改进

结案

试运行
训练
上线
SLA 保证
审查 SOA 策略
生产支持

有两个故事板可用于日常跟踪工作，如下所示以供参考。

故事板
- 这是一种传统的收集所有故事到板上以便笺形式跟踪每日 XP 活动的方法。由于这种手动活动涉及更多的精力和时间，因此最好切换到在线形式。
在线故事板
- 在线工具故事板可用于存储故事。多个团队可以将其用于不同的目的。

Crystal 方法论

Crystal 方法论基于三个概念

特许：此阶段涉及的各种活动包括创建开发团队、执行初步可行性分析、制定初始计划和微调开发方法。
周期性交付：主要开发阶段包括两个或更多交付周期，在此期间
1. 团队更新和完善发布计划
2. 通过一次或多次程序测试集成迭代实现需求子集
3. 集成产品交付给真实用户
4. 项目计划和采用的开发方法评审
收尾：此阶段执行的活动包括部署到用户环境、部署后评审和反思。

动态系统开发方法 (DSDM)

DSDM 是一种快速应用开发 (RAD) 软件开发方法，并提供敏捷项目交付框架。DSDM 的重要方面是要求用户积极参与，并赋予团队决策权。DSDM 的重点是频繁交付产品。DSDM 中使用的技术有：

时间箱
MoSCoW 规则
原型设计

DSDM 项目包括 7 个阶段

项目前
可行性研究
商业研究
功能模型迭代
设计和构建迭代
实施
项目后

特性驱动开发 (FDD)

此方法侧重于“设计和构建”功能。与其他软件工程中的敏捷方法不同，FDD 描述了必须为每个功能单独完成的非常具体且短暂的工作阶段。它包括领域演练、设计审查、提升到构建、代码审查和设计。FDD 开发产品时考虑以下几点：

领域对象建模
按功能开发
组件/类所有权
功能团队
检查
配置管理
定期构建
进度和结果的可视化

精益软件开发

精益软件开发方法基于“即时生产”原则。它旨在提高软件开发速度并降低成本。精益开发可以概括为七个步骤。

消除浪费
放大学习
延迟承诺（尽可能晚地决定）
早期交付
赋能团队
建立完整性
优化整体

看板

看板最初来源于日语，意为一张卡片，其中包含产品在完成路径上每个阶段所需的所有信息。这种框架或方法在软件测试方法中，尤其是在敏捷概念中，得到了广泛采用。

Scrum vs 看板

Scrum	看板
在 Scrum 技术中，测试必须分解，以便在一个冲刺内完成。	没有规定特定的项目大小。
规定了一个优先排序的产品待办列表。	优先级是可选的。
Scrum 团队承诺在迭代中完成特定数量的工作。	承诺是可选的。
规定了燃尽图。	没有规定特定的项目大小。
在每个冲刺之间，Scrum 板会重置。	看板是持久的。它限制了工作流状态中的项目数量。
它不能向正在进行的迭代添加项目。	当有可用容量时，它可以添加项目。
WIP（在制品）间接限制。	WIP 直接限制。
规定了时间盒迭代。	时间盒迭代是可选的。

另请查看：- 看板 vs. Scrum：有什么区别？

敏捷指标

可用于有效使用敏捷的指标是

拖延系数
- 不有助于冲刺目标的工时
- 通过减少共享资源数量、减少不贡献工作量可以改善拖延系数
- 新估算可以增加拖延系数的百分比 - 新估算 = (旧估算 + 拖延系数)
速度
- 转换为可交付冲刺功能的产品待办列表（用户故事）数量
添加的单元测试数量
完成每日构建所需的时间间隔
在迭代中或之前迭代中检测到的缺陷
生产缺陷泄漏