- 敏捷测试教程
- 敏捷测试 - 首页
- 敏捷测试 - 概述
- 敏捷测试 - 方法论
- 敏捷测试 - 团队中的测试人员
- 敏捷测试 - 活动跟踪
- 敏捷测试 - 重要属性
- 敏捷测试 - 象限
- 敏捷测试 - Scrum
- 敏捷测试 - 方法
- 敏捷测试 - 技术
- 敏捷测试 - 工作成果
- 敏捷测试 - Kanban
- 敏捷测试 - 工具
- 敏捷测试有用资源
- 敏捷测试 - 快速指南
- 敏捷测试 - 有用资源
- 敏捷测试 - 讨论
敏捷测试 - 工作成果
测试计划在发布计划时准备,并在每个冲刺计划时进行修订。测试计划作为测试过程的指南,以确保完整的测试覆盖率。
测试计划的典型内容包括:
- 测试策略
- 测试环境
- 测试覆盖率
- 测试范围
- 测试工作量和时间安排
- 测试工具
在敏捷项目中,所有团队成员都对产品的质量负责。因此,每个人也参与测试计划。
测试人员的责任是提供必要的指导,并利用其测试专业知识指导团队其他成员。
用户故事
从原则上讲,用户故事并非测试工作成果。但是,在敏捷项目中,测试人员参与用户故事的创建。测试人员编写对客户有价值的用户故事,并涵盖系统可能出现的各种行为。
测试人员还确保所有用户故事都是可测试的,并确保验收标准。
手动和自动化测试
在第一次运行测试时,使用手动测试。它们包括:
- 单元测试
- 集成测试
- 功能测试
- 非功能测试
- 验收测试
然后,将测试自动化以进行后续运行。
在**测试驱动开发**中,首先编写单元测试使其失败,然后开发和测试代码以确保测试通过。
在**验收测试驱动开发**中,首先编写验收测试使其失败,然后开发和测试代码以确保测试通过。
在其他开发方法中,测试人员与团队的其他成员合作以确保测试覆盖率。
在所有类型的这些方法中,都会进行持续集成,其中包括持续集成测试。
团队可以决定何时以及要自动化哪些测试。即使测试自动化需要付出努力和时间,由此产生的自动化测试也能显著减少敏捷项目迭代期间重复测试的工作量和时间。这反过来又促使团队更加关注其他所需活动,例如新的用户故事、更改等。
在**Scrum**中,迭代是时间盒化的。因此,如果某个用户故事的测试无法在一个特定的冲刺中完成,测试人员可以在每日站立会议中报告该用户故事无法在该冲刺中达到“完成”状态,因此需要将其推迟到下一个冲刺。
测试结果
由于敏捷项目中的大多数测试都是自动化的,因此工具会生成必要的测试结果日志。测试人员会审查测试结果日志。需要为每个冲刺/发布维护测试结果。
还可以准备一份测试摘要,其中包含:
- 测试范围(测试了什么和未测试什么)
- 缺陷分析,如果可能的话,还包括根本原因分析
- 缺陷修复后的回归测试状态
- 问题及其相应的解决方案
- 如有任何未决问题
- 测试策略中需要进行的任何修改
- 测试指标
测试指标报告
在敏捷项目中,每个冲刺的测试指标包括:
- 测试工作量
- 测试估算准确性
- 测试覆盖率
- 自动化测试覆盖率
- 缺陷数量
- 缺陷率(每个用户故事点的缺陷数量)
- 缺陷严重程度
- 在同一冲刺中修复缺陷的时间(修复在当前冲刺中逃脱的缺陷的成本是其 24 倍)
- 在同一冲刺中修复的缺陷数量
- 客户在冲刺中完成验收测试
冲刺评审和回顾报告
测试人员也为冲刺评审和回顾报告做出贡献。典型内容包括:
- 测试指标
- 测试结果日志审查结果
- 从测试角度来看,哪些方面做得好以及哪些方面可以改进
- 最佳实践
- 经验教训
- 问题
- 客户反馈