敏捷测试 – 技术

敏捷测试 – 技术


传统测试中的测试技术也可用于敏捷测试。除此之外,敏捷项目中还使用了特定于敏捷的测试技术和术语。

测试基础

在敏捷项目中,产品待办列表取代了需求规范文档。产品待办列表的内容通常是用户故事。非功能性需求也在用户故事中得到照顾。因此,敏捷项目的测试基础是用户故事。

为确保质量测试,还可以额外考虑以下内容作为测试基础 –

  • 来自同一项目或过去项目的先前迭代的经验。
  • 系统的现有功能、架构、设计、代码和质量特性。
  • 当前和过去项目的缺陷数据。
  • 客户的反馈意见。
  • 用户文档。

完成的定义

完成定义 (DoD) 是敏捷项目中使用的标准,用于确保完成 Sprint 待办事项中的活动。DoD 可以因 Scrum 团队而异,但在一个团队内应该是一致的。

DoD 是一份必要活动的清单,可确保实现用户故事中的功能和特性以及作为用户故事一部分的非功能性需求。在完成 DoD 清单中的所有项目后,用户故事进入完成阶段。DoD 是跨团队共享的。

用户故事的典型 DoD 可以包含 –

  • 详细的可测试验收标准
  • 确保用户故事与迭代中其他故事一致的标准
  • 与产品相关的特定标准
  • 功能行为方面
  • 非功能特性
  • 接口
  • 测试数据要求
  • 测试覆盖率
  • 重构
  • 审查和批准要求

除了用户故事的 DoD,还需要 DoD –

  • 在每个测试级别
  • 对于每个功能
  • 对于每次迭代
  • 发布

测试信息

测试人员需要具有以下测试信息 –

  • 需要测试的用户故事
  • 相关验收标准
  • 系统接口
  • 系统预期工作的环境
  • 工具可用性
  • 测试覆盖率
  • 国防部

在敏捷项目中,由于测试不是连续的活动并且测试人员应该以协作模式工作,因此测试人员有责任 –

  • 持续获取必要的测试信息。
  • 确定影响测试的信息差距。
  • 与其他团队成员合作解决差距。
  • 决定何时达到测试级别。
  • 确保在相关时间执行适当的测试。

功能和非功能测试设计

在敏捷项目中,可以使用传统的测试技术,但重点是早期测试。测试用例需要在实施开始之前就位。

对于功能测试设计,测试人员和开发人员可以使用传统的黑盒测试设计技术,例如 –

  • 等价分区
  • 边值分析
  • 决策表
  • 状态转换
  • 类树

对于非功能测试设计,由于非功能需求也是每个用户故事的一部分,黑盒测试设计技术只能用于设计相关的测试用例。

探索性测试

在敏捷项目中,时间通常是测试分析和测试设计的限制因素。在这种情况下,探索性测试技术可以与传统测试技术相结合。

探索性测试 (ET) 被定义为同时学习、测试设计和测试执行。在探索性测试中,测试人员在执行测试时主动控制测试的设计,并使用在测试中获得的信息来设计新的和更好的测试。

探索性测试可以方便地适应敏捷项目的变化。

基于风险的测试

基于风险的测试是基于失败风险的测试,并使用测试设计技术降低风险。

产品质量风险可以定义为产品质量的潜在问题。产品质量风险包括 –

  • 功能风险
  • 非功能性性能风险
  • 非功能性可用性风险

进行风险分析以评估每个风险的概率(可能性)和影响。然后,优先考虑风险 –

  • 高风险需要广泛的测试
  • 低风险只需要粗略测试

根据每个风险的风险级别和风险特征,使用适当的测试技术设计测试。然后执行测试以减轻风险。

拟合测试

适合性测试是自动化的验收测试。工具 Fit 和 FitNesse 可用于自动化验收测试。

FIT 使用 JUnit,但扩展了测试功能。HTML 表格用于显示测试用例。Fixture 是 HTML 表格背后的 Java 类。该夹具获取 HTML 表的内容并在被测试的项目上运行测试用例。

觉得文章有用?

点个广告表达一下你的爱意吧 !😁