- 敏捷测试教程
- 敏捷测试 - 首页
- 敏捷测试 - 概述
- 敏捷测试 - 方法论
- 敏捷测试 - 团队中的测试人员
- 敏捷测试 - 活动跟踪
- 敏捷测试 - 重要属性
- 敏捷测试 - 四象限
- 敏捷测试 - Scrum
- 敏捷测试 - 方法
- 敏捷测试 - 技术
- 敏捷测试 - 工作产品
- 敏捷测试 - Kanban
- 敏捷测试 - 工具
- 敏捷测试有用资源
- 敏捷测试 - 快速指南
- 敏捷测试 - 有用资源
- 敏捷测试 - 讨论
敏捷测试 - 技术
传统测试中的测试技术也可以用于敏捷测试。除此之外,敏捷项目中还会使用敏捷特有的测试技术和术语。
测试依据
在敏捷项目中,产品待办事项取代了需求规格说明书。产品待办事项的内容通常是用户故事。非功能性需求也在用户故事中得到考虑。因此,敏捷项目中的测试依据是用户故事。
为了确保高质量的测试,还可以额外考虑以下内容作为测试依据:
- 来自同一项目或过去项目的先前迭代的经验。
- 系统的现有功能、架构、设计、代码和质量特性。
- 当前和过去项目的缺陷数据。
- 客户反馈。
- 用户文档。
完成的定义
完成的定义 (DoD) 是敏捷项目中用于确保冲刺待办事项中活动完成的标准。DoD 在不同的 Scrum 团队之间可能有所不同,但在同一个团队内应该保持一致。
DoD 是一个必要的活动清单,它确保用户故事中功能和特性的实现,以及作为用户故事一部分的非功能性需求。当DoD清单中的所有项目都完成之后,用户故事就达到了“完成”阶段。DoD在团队中共享。
用户故事的典型 DoD 可能包含:
- 详细的可测试验收标准
- 确保用户故事与迭代中其他用户故事一致的标准
- 与产品相关的特定标准
- 功能行为方面
- 非功能特性
- 接口
- 测试数据需求
- 测试覆盖率
- 重构
- 审查和批准要求
除了用户故事的 DoD 之外,还需要 DoD:
- 在每个测试级别
- 对于每个功能
- 对于每个迭代
- 用于发布
测试信息
测试人员需要掌握以下测试信息:
- 需要测试的用户故事
- 相关的验收标准
- 系统接口
- 系统预期工作的环境
- 工具可用性
- 测试覆盖率
- DoD
在敏捷项目中,由于测试不是一个顺序活动,并且测试人员应该以协作的方式工作,因此测试人员有责任:
- 持续获取必要的测试信息。
- 识别影响测试的信息差距。
- 与其他团队成员协作解决差距。
- 确定达到测试级别的时间。
- 确保在相关时间执行适当的测试。
功能和非功能测试设计
在敏捷项目中,可以使用传统的测试技术,但重点是尽早测试。测试用例需要在实现开始之前到位。
对于功能测试设计,测试人员和开发人员可以使用传统的黑盒测试设计技术,例如:
- 等价划分
- 边界值分析
- 决策表
- 状态转换
- 类树
对于非功能测试设计,由于非功能性需求也是每个用户故事的一部分,因此只能使用黑盒测试设计技术来设计相关的测试用例。
探索性测试
在敏捷项目中,时间往往是测试分析和测试设计的限制因素。在这种情况下,可以将探索性测试技术与传统的测试技术结合起来。
探索性测试 (ET) 定义为同时进行学习、测试设计和测试执行。在探索性测试中,测试人员积极控制测试的设计,并在执行测试时使用获得的信息来设计新的、更好的测试。
探索性测试有助于适应敏捷项目中的变化。
基于风险的测试
基于风险的测试是基于失败风险的测试,并使用测试设计技术来减轻风险。
产品质量风险可以定义为产品质量的潜在问题。产品质量风险包括:
- 功能风险
- 非功能性能风险
- 非功能可用性风险
进行风险分析以评估每个风险的概率(可能性)和影响。然后,对风险进行优先级排序:
- 高风险需要广泛测试
- 低风险只需要粗略测试
根据每个风险的风险级别和风险特征,使用适当的测试技术设计测试。然后执行测试以减轻风险。
Fit测试
Fit测试是自动化的验收测试。可以使用Fit和FitNesse工具来自动化验收测试。
FIT 使用 JUnit,但扩展了测试功能。HTML 表格用于显示测试用例。Fixture 是 HTML 表格背后的 Java 类。Fixture 获取 HTML 表格的内容并在被测试的项目上运行测试用例。