测试中的敏捷软件开发模型和过程

什么是敏捷方法论?

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

Agile Methodology
Agile Methodology

敏捷方法论

什么是敏捷软件开发?

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

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

  1. 个人和团队通过流程和工具进行交互
  2. 工作软件胜过全面的文档
  3. 通过合同协商进行客户协作
  4. 响应变化,而不是遵循计划

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

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

敏捷模型与瀑布模型

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

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

敏捷流程

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

Agile Process Model
Agile Process Model

敏捷流程模型

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

Scrum

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

Scrum Method
Scrum Method

Scrum方法

  • Scrum Master

    • 敏捷经理负责组建团队,冲刺会议,扫除前进障碍
  • 产品经理

    • 产品经理创建产品待办事项,确定待办事项的优先顺序,并负责在每次迭代中交付功能
  • Scrum团队

    • 团队开展各自的工作,并组织工作以完成冲刺或循环

产品积压

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

Scrum实践

详细介绍了实践:

Scrum Practices
Scrum Practices

Scrum实践

Scrum方法的流程

Scrum测试流程如下:

  • Scrum的每一次迭代都称为Sprint

  • 产品积压是输入所有详细信息以获取最终产品的列表

  • 在每次冲刺期间,都会选择产品积压的顶级用户故事,并将其转化为冲刺积压

  • 团队处理定义的Sprint Backlog

  • 团队检查日常工作

  • 在冲刺结束时,团队交付产品功能

极限编程(XP)

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

Extreme Programming
Extreme Programming

极限编程

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

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

极限编程的各个阶段:

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

规划

  • 确定利益相关者和发起人

  • 基础设施要求

  • 与安全相关的信息和收集

  • 服务级别协议及其条件

分析

  • 确定故事主题

  • 确定故事优先级

  • 评估各个故事花费

  • 定义迭代 SPAN(Time)

  • 开发团队和QA团队的资源规划

设计

  • 任务细分

  • 为每项任务准备测试场景

  • 回归自动化框架

执行

  • 编码

  • 单元测试

  • 手动测试场景的执行

  • 缺陷报告生成

  • 手工回归测试用例向自动化回归测试用例的转换

  • 迭代中期评审

  • 迭代结束评审

发布

  • 小版本

  • 回归测试

  • 演示和反馈

  • 根据需要开发新故事

  • 基于迭代结束评审注释的过程改进

闭合

  • 预发布

  • 培训

  • 投产启动

  • SLA保证保证

  • 审查SOA战略

  • 生产支持

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

  • 故事看板

    • 这是一种传统的方式,以便条的形式收集黑板上的所有故事,以跟踪XP的日常活动。由于此手动活动需要更多的精力和时间,因此最好切换到在线表单。
  • 联机故事板

    • 在线工具故事板可以用来存储故事。几个团队可以将其用于不同的目的。

水晶方法论

水晶方法论基于三个概念

  1. 预分析:此阶段涉及的各种活动包括创建开发团队、执行初步可行性分析、制定初步计划和微调开发方法

  2. 循环交付:主要开发阶段由两个或多个交付周期组成,在此期间

       1. 团队更新和细化发布计划 
      
    1. 通过一个或多个程序测试集成迭代实现需求子集
    2. 集成产品交付给真实用户
    3. 审查项目计划和采用的发展方法
  3. 总结:此阶段执行的活动是部署到用户环境,执行部署后检查和总结反思。

动态软件开发方法(DSDM)

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

  1. 时间计划
  2. MoSCoW规则
  3. 原型制作

DSDM项目由7个阶段组成

  1. 项目前
  2. 可行性研究
  3. 业务学习
  4. 功能模型迭代
  5. 设计和构建迭代
  6. 实现
  7. 总结和反思

功能驱动开发(FDD)

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

  1. 域对象模型
  2. 按功能开发
  3. 组件/类依赖关系
  4. 技术团队
  5. 检查
  6. 配置管理
  7. 常规建造
  8. 进度和结果的及时可见性

精益软件开发

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

  1. 杜绝浪费
  2. 放大学习
  3. 推迟承诺(尽可能晚地做出决定)
  4. 提早交货
  5. 为团队放权
  6. 集成构建
  7. 优化整体

看板

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

Scrum vs 看板

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

敏捷指标:

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

  • 阻力系数

    • 对冲刺目标没有贡献的小时数内的努力

    • 可以通过减少共享资源的数量、减少非贡献工作量来提高阻力系数

    • 新的估算值可以增加阻力系数的百分比,估计值= (经验估计 + 阻力系数)

  • 速度

    • 转换为Sprint的可发货功能的 backlog(user stories) 数量
  • 添加的单元测试数量

  • 完成每日构建所需的时间间隔

  • 在迭代或以前的迭代中检测到的错误

  • 生产缺陷泄漏

IT赶路人

专注IT知识分享