软件测试中的敏捷方法

Agile Methodology

什么是敏捷测试中的敏捷方法?

敏捷方法意味着一种在项目整个软件开发生命周期中促进开发和测试的持续迭代的实践。在软件测试的敏捷模型中,与瀑布模型不同,开发和测试活动是并发的。

Agile Methodology
敏捷方法

什么是敏捷软件开发?

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

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

  1. 重视个体和交互,而非流程和工具
  2. 重视可工作的软件,而非详尽的文档
  3. 重视客户协作,而非合同谈判
  4. 响应变化,而非遵循计划

敏捷模型与瀑布模型

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

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

另请检查:-敏捷与瀑布:了解两种方法之间的区别

敏捷流程

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

Agile Process Model
敏捷流程模型

敏捷测试中有各种敏捷方法,列举如下

Scrum

SCRUM 是一种敏捷开发方法,它专门关注如何在基于团队的开发环境中管理任务。基本上,Scrum 源于橄榄球比赛中发生的活动。Scrum 相信赋权开发团队,并提倡在小型团队(例如 7 到 9 名成员)中工作。敏捷和 Scrum 包含三个角色,它们的职责解释如下

Scrum Method
Scrum 方法
  • Scrum Master
    • Scrum Master 负责组建团队、召开冲刺会议并消除阻碍进展的障碍
  • 产品负责人
    • 产品负责人创建产品待办事项列表,对列表进行优先级排序,并负责在每次迭代中交付功能
  • Scrum 团队
    • 团队自行管理工作,并组织工作以完成冲刺或周期

产品待办事项列表

这是一个存储库,其中跟踪需求,并详细说明每个版本的用户故事数量。产品负责人应维护和优先排序,并应将其分发给 Scrum 团队。团队也可以请求添加、修改或删除新需求

Scrum实man

实践已详细说明

Scrum Practices
Scrum实man

Scrum方法的过程流程

Scrum 测试的流程如下

  • Scrum 的每次迭代称为 Sprint
  • 产品待办事项列表是一个列表,其中输入了所有详细信息以获得最终产品
  • 在每次 Sprint 中,都会选择产品待办事项列表中的顶级用户故事,并将其转化为 Sprint 待办事项列表
  • 团队致力于定义的 Sprint 待办事项列表
  • 团队检查日常工作
  • Sprint 结束时,团队交付产品功能

极限编程 (XP)

当客户不断变化的需求或不确定系统功能时,Extreme Programming 技术非常有帮助。它提倡在短开发周期内频繁“发布”产品,这自然会提高系统效率,并引入一个可以轻松实现任何客户需求的检查点。XP 在开发软件时以客户为目标。

Extreme Programming
极限编程

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

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

eXtreme编程的阶段

敏捷 XP 方法有 6 个阶段,如下所述

规划

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

分析

  • 在停车场捕获故事
  • 对停车场的故事进行优先级排序
  • 估算故事的清洁
  • 定义迭代跨度(时间)
  • 开发和 QA 团队的资源规划

设计

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

执行

  • 编码
  • 执行手动测试场景
  • 生成缺陷报告
  • 将手动测试转换为自动化回归测试用例
  • 迭代中期审查
  • 迭代末审查

收尾

  • 小版本发布
  • 演示和评审
  • 根据需要开发新故事
  • 根据迭代末审查意见进行流程改进

结案

  • 试运行
  • 训练
  • 生产发布
  • SLA 保证
  • 审查 SOA 策略
  • 生产支持

有两种看板可用,用于跟踪日常工作,下面列出供参考。

  • 故事看板
    • 这是一种传统的收集所有故事的方式,以便利贴的形式在看板上跟踪 XP 日常活动。由于这项手动活动涉及更多的工作和时间,因此最好切换到在线形式。
  • 在线看板
    • 可以使用在线工具看板来存储故事。多个团队可以出于不同目的使用它

Crystal方法

Crystal 方法基于三个概念

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

动态软件开发方法 (DSDM)

DSDM 是一种快速应用程序开发 (RAD) 方法,为软件开发提供了敏捷项目交付框架。DSDM 的重要方面是需要用户积极参与,并且团队拥有决策权。频繁交付产品成为 DSDM 的活动焦点。DSDM 使用的技术是

  1. 时间盒
  2. MoSCoW 规则
  3. 原型设计

DSDM 项目包含 7 个阶段

  1. 项目前
  2. 可行性研究
  3. 业务研究
  4. 功能模型迭代
  5. 设计和构建迭代
  6. 实施
  7. 项目后

特性驱动开发 (FDD)

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

  1. 域对象建模
  2. 按功能开发
  3. 组件/类所有权
  4. 功能团队
  5. 检查
  6. 配置管理
  7. 定期构建
  8. 进度的可见性和结果

精益软件开发

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

  1. 消除浪费
  2. 放大经验
  3. 推迟承诺(尽可能晚地决定)
  4. 早期交付
  5. 赋能团队
  6. 构建完整性
  7. 优化整体

看板

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

Scrum 与 Kanban

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

另请检查:-Kanban 与 Scrum:有什么区别?

敏捷指标

为有效利用敏捷可以收集的指标是

  • 拖拽因子
    • 不计入 Sprint 目标的工时
    • 通过减少共享资源数量、减少非贡献性工作量来改进拖拽因子 - 新估算 = (旧估算 + 拖拽因子)
    • 新的估算可以通过拖拽因子的百分比来增加 - 新估算 = (旧估算 + 拖拽因子)
  • 速度
    • 已转换为可交付功能的 Sprint 的待办事项(用户故事)数量
  • 添加的单元测试数量
  • 完成每日构建的时间间隔
  • 在迭代或先前迭代中检测到的 Bug
  • 生产缺陷泄漏