软件测试中的敏捷方法
托马斯·汉密尔顿
测试中的敏捷方法是什么？
敏捷方法论是一种提倡以下理念的实践： 不断迭代 开发和测试贯穿整个项目的软件开发生命周期。在软件测试的敏捷模型中，开发和测试活动是同时进行的，这与瀑布模型不同。
👉 免费注册实时软件测试项目
敏捷测试的核心原则和价值观
敏捷测试遵循一系列原则和价值观，旨在促进整个开发过程中的协作、适应性和持续改进。
客户合作： 敏捷测试强调与客户密切互动，以确保软件满足实际需求。
连续测试： 测试是在开发初期和整个开发过程中进行的，而不仅仅是在开发结束时。
适应变化： 欢迎不断变化的需求，促进灵活性和更快的交付。
软件工作胜于文档： 注重实际效果，而非冗长的文档。
团队协作： 鼓励开发人员、测试人员和利益相关者之间进行有效沟通。
持续反馈： 定期的反馈机制有助于快速发现和解决问题。
简单高效： 优先处理关键任务，以最大限度地提高价值并最大限度地减少浪费。
可持续的步伐： Promo测试平衡的工作量，以维持长期的生产力和质量。
敏捷测试生命周期
以下是对敏捷测试生命周期的简要说明：
1. 测试计划
在初始阶段，敏捷团队会定义测试范围、目标、资源和时间表。测试人员会与开发人员和利益相关者协作，以确保测试目标与迭代需求保持一致。
2. 测试设计
在这里，测试人员根据用户故事设计测试用例、场景和验收标准。重点在于模块化、可重用和自动化测试，并使其符合持续集成原则。
3. 测试执行
测试与开发同步进行，是一个迭代过程。测试人员在每个迭代周期内执行单元测试、集成测试和系统测试，以验证新功能并尽早发现缺陷。
4. 缺陷报告和重新测试
所有发现的缺陷都会被记录、确定优先级并迅速修复。重新测试确保缺陷修复不会破坏现有功能。
5.回归测试
自动化回归测试用于验证新代码的更改是否会影响现有模块。这一步骤可确保产品在各个迭代周期中的稳定性。
6. 测试结束
冲刺结束后，团队会审查测试指标，记录经验教训，并确保交付成果符合完成的定义。
敏捷过程
请参考以下敏捷方法论流程，快速交付成功的系统：
有各种 敏捷方法 存在于敏捷测试中，如下所列：
争球
Scrum 是一种敏捷开发方法，它专注于如何在团队协作的开发环境中管理任务。Scrum 的概念源于橄榄球比赛中的“轮流上阵”策略。Scrum 强调赋予开发团队权力，并提倡以小型团队（例如 7 到 9 名成员）的形式开展工作。敏捷和 Scrum 包含三种角色，其职责如下：
Scrum Master
此 Scrum Master 负责组建团队、组织冲刺会议，并排除推进过程中的障碍。
产品所有者
产品负责人创建产品待办事项列表，确定待办事项列表的优先级，并负责在每次迭代中交付功能。
Scrum团队
团队自行管理工作，并组织工作以完成冲刺或周期。
产品积压
这是一个需求跟踪库，用于记录每个版本需要完成的需求（用户故事）数量。它应由产品负责人维护和优先级排序，并分发给 Scrum 团队。团队也可以请求添加、修改或删除需求。
Scrum 实践
本节将详细描述各项实践：
Scrum 方法的流程：
工艺流程 Scrum 测试 如下：
- Scrum 的每次迭代都称为一个迭代周期。 Sprint
- 产品待办事项列表是一个清单，其中记录了最终产品所需的所有细节。
- 在每个 Sprint产品待办事项列表中最重要的用户故事将被选中并转化为 Sprint 积压
- 团队正在处理已定义的迭代待办事项列表。
- 团队检查日常工作
- 在冲刺结束时，团队交付产品功能。
极限编程 (XP)
当客户需求不断变化，或者他们对系统功能不确定时，极限编程（XP）技术非常有用。它提倡在短开发周期内频繁“发布”产品，这从根本上提高了系统效率，并引入了一个检查点，可以轻松实现任何客户需求。XP 开发软件时始终以客户为中心。
业务需求以故事的形式收集。所有这些故事都存储在一个叫做停车场的地方。
在这种方法论中，版本发布基于称为迭代的较短周期，周期为14天。每个迭代都包含编码、单元测试和系统测试等阶段，在每个阶段，都会在应用程序中构建一些次要或重要的功能。
极限编程的阶段
敏捷XP方法共有6个阶段，具体说明如下：
计划
- 利益相关者和发起人的识别
- 基础设施要求
- 安保防护相关信息和收集
- 服务级别协议及其条款
信号分析
- 在停车场捕捉故事
- 优先考虑停车场中的故事
- 清理故事以进行估计
- 定义迭代SPAN(时间)
- 开发团队和质量保证团队的资源规划
工艺设计
- 任务分解
- 每个任务的测试场景准备
- 回归自动化框架
执行
- 编码
- 单元测试
- 执行手动测试场景
- 缺陷报告生成
- 将手动回归测试用例转换为自动化回归测试用例
- 中期迭代审查
- 迭代结束审核
包装
- 小版本发布
- 迭代测试
- 演示和评论
- 根据需要开发新故事
- 根据迭代结束评审意见进行流程改进
关闭
- 试点发射
- 培训实施
- 生产启动
- SLA保证保证
- Rev查看 SOA 策略
- 生产支持
有两个故事板可用于跟踪日常工作，下面列出了这些故事板以供参考。
故事纸板
这是一种传统的做法，即用便利贴的形式将所有故事收集在白板上，用来追踪每日的经验值活动。由于这种手工操作耗时耗力，最好改用在线表格。
在线故事板
可以使用在线工具 Storyboard 来存储故事。 多个团队可以使用它 出于不同的目的。
水晶方法论
水晶方法论基于三个概念
- 租船： 该阶段涉及的各项活动包括：组建开发团队、进行初步可行性分析、制定初步计划以及完善开发方法。
- 循环交付： 主要开发阶段由两个或多个交付周期组成，在此期间
- 团队更新并完善发布计划。
- 通过一次或多次程序测试集成迭代来实现部分需求。
- 集成产品交付给真实用户
- Rev项目计划和所采用的开发方法
- 包起来： 此阶段执行的活动包括部署到用户环境，以及进行部署审查和反思。
动态软件开发方法 (DSDM)
DSDM 是一种 快速应用开发 快速应用开发（RAD）是一种软件开发方法，它提供了一个敏捷的项目交付框架。DSDM 的重要特点在于要求用户积极参与，并赋予团队决策权。频繁交付产品成为 DSDM 的核心关注点。DSDM 中使用的技术包括：
- 时间 Box博士开发的技术萃取的
- 莫斯科规则
- 模型
DSDM项目分为7个阶段
- 预项目
- 可行性研究
- 商业研究
- 功能模型迭代
- 设计并构建迭代
- 实施
- 项目后
功能驱动开发（FDD）
这种方法专注于“设计和构建”功能。与其他敏捷软件工程方法不同，功能驱动开发 (FDD) 将每个功能都划分为非常具体且简短的工作阶段，每个阶段都需要单独完成。它包括领域演练、设计审查、推进构建、代码审查和设计。FDD 在开发产品时会考虑到以下几点。
- 领域对象建模
- 按功能开发
- 组件/类所有权
- 特色团队
- 检查
- 配置管理
- 常规构建
- 进展和结果的可见性
精益软件开发
精益软件开发方法基于“准时生产”原则，旨在提高软件开发速度并降低成本。精益开发可概括为七个步骤。
- 消除浪费
- 强化学习
- 推迟承诺（尽可能晚地做出决定）
- 提前交货
- 赋予团队权力
- 构建 Integrity
- 整体优化
看板
看板 最初源自日语，意为一张卡片，上面记录着产品在各个阶段完成所需完成的所有信息。这种框架或方法被广泛应用于软件测试，尤其是在敏捷开发理念中。
敏捷测试有哪些优势？
以下是敏捷测试的优势所在：
- 早期和持续的反馈： 测试从项目一开始就开始，这样就能及早发现漏洞和设计缺陷，避免造成代价高昂的灾难。
- 更快的交货： 测试与开发同步进行，从而加快发布速度，并确保在更短、持续的周期内交付可用的软件。
- 更好的协作： 测试人员、开发人员和产品负责人紧密合作，促进相互理解，减少沟通不畅。
- 提高质量： 频繁的测试和自动化有助于保持质量的一致性，并在每次迭代中及早发现问题。
- 适应变化的能力： 敏捷测试能够轻松适应不断变化的需求，使团队能够在不影响整个项目的情况下进行调整。
- 更高的客户满意度： 定期的反馈循环确保最终产品符合用户期望和实际需求。
如何克服敏捷测试的挑战？
以下是克服敏捷测试中出现挑战的最佳方法：
- 挑战： 需求的快速变化使得维持稳定的测试计划变得困难。
解决方案： 实施自适应测试策略，利用灵活的自动化框架和持续的反馈循环，以高效地适应不断变化的需求。 - 挑战： 较短的开发周期减少了进行全面测试的可用时间。
解决方案： 优先考虑基于风险的测试，自动化回归测试套件，并在开发流程早期集成持续测试。 - 挑战： 频繁的代码变更使得维持足够的测试覆盖率变得困难。
解决方案： 使用自动化单元测试和集成测试，并辅以持续集成工具，以确保一致的测试覆盖率和快速验证。 - 挑战： 缺乏协作会导致开发人员和测试人员之间产生误解。
解决方案： 通过每日站会、共享文档和跨职能结对编程来促进协作，使测试目标与开发目标保持一致。 - 挑战： 管理一致且准确的测试数据变得越来越具有挑战性。
解决方案： 利用合成数据生成和版本控制的测试数据集，确保可重复和可靠的测试环境。 - 挑战： 在保证高质量交付的同时，兼顾快速交付时间。
解决方案： 在 CI/CD 管道中集成质量门，并强制执行自动化质量检查，同时不减慢交付周期。 - 挑战： 敏捷团队经常因为文档不足或缺失而遇到困难。
解决方案： 维护与用户故事和测试用例关联的轻量级、动态文档，以在不牺牲敏捷性的前提下保持清晰度。 - 挑战： 测试环境通常与生产环境不一致。
解决方案： 采用容器化环境和配置管理工具，以在开发、测试和生产环境中保持一致的设置。
敏捷模型与瀑布模型
敏捷开发和瀑布模型是两种不同的软件开发方法。虽然它们的具体做法不同，但根据需求和项目类型，这两种方法在某些情况下都非常有用。
| 敏捷模型 | 瀑布模型 |
|---|---|
| 软件测试中的敏捷方法论定义：敏捷方法论提出了一种增量式和迭代式的软件设计方法。 | 软件开发流程是从起点到终点按顺序进行的。 |
| 此 敏捷流程 软件测试被分解成设计师负责的单个模型 | 设计过程不会分解成单个模型 |
| 客户有早期且频繁的机会查看产品，并对项目做出决策和修改。 | 客户只能在项目结束时看到产品 |
| 与瀑布模型相比，测试中的敏捷模型被认为是非结构化的 | 瀑布模型更安全，因为它们非常注重计划。 |
| 小型项目可以很快实施。而大型项目则很难估算开发时间。 | 各种类型的项目都可以进行估算和完成。 |
| 该错误可以在项目进行过程中修复。 | 只有到了最后才会对整个产品进行测试。如果发现需求错误或需要进行任何更改，项目就必须从头开始。 |
| 开发过程是迭代式的，项目以较短的迭代周期（2-4周）执行。规划工作很少。 | 开发过程分阶段进行，每个阶段的范围远大于一次迭代。每个阶段的结尾都会对下一阶段进行详细描述。 |
| 文件记录的优先级低于其他因素。 软件开发 | 文档编写至关重要，甚至可以用于员工培训以及与其他团队合作升级软件。 |
| 每次迭代都有自己的测试阶段。这使得每次发布新功能或逻辑时都能实施回归测试。 | 只有在开发阶段之后才会执行测试阶段，因为各个独立部件的功能并不完全完善。 |
| 在敏捷测试中，每次迭代结束后，产品中可交付的功能就会交付给客户。新功能交付后即可立即使用。这在与客户保持良好沟通时非常有用。 | 经过漫长的实施阶段后，所有开发的功能将一次性交付。 |
| 测试人员和开发人员一起工作 | 测试人员与开发人员分开工作 |
| 在每个冲刺结束时，执行用户接受 | 用户接受度是 执行 项目结束时 |
| 需要与开发人员密切沟通，共同分析需求、规划 | 开发人员不参与需求和规划过程。通常，测试和编码之间存在时间延迟。 |
还检查： - 敏捷与瀑布：了解方法论之间的区别
