什么是敏捷测试？
敏捷测试是遵循敏捷软件开发规则和原则的测试实践。与瀑布方法不同，捷测试方法不是顺序的(从这个意义上说，它只在编码阶段之后执行)，而是连续的。
在这篇文章中，我们将讨论
- 敏捷测试计划。
- 敏捷测试策略。
- 敏捷测试象限。
- 敏捷软件开发的QA挑战。
- 敏捷过程中自动化的风险。
敏捷测试计划
敏捷测试计划包括迭代中完成的测试类型，如测试数据需求、基础设施、测试环境和测试结果。敏捷中的典型测试计划包括
- 测试范围
- 正在测试的新功能
- 基于功能复杂性的测试级别或类型
- 负载和性能测试
- 基础设施注意事项
- 缓解或风险计划
- 资源配置
- 交付成果和里程碑
敏捷测试策略
敏捷测试生命周期跨越四个阶段
- 0迭代（Iteration 0）
在第一阶段或迭代0期间，执行初始设置任务。它包括确定要测试的人员，安装在迭代0中设置要实现的以下步骤
-
为项目建立业务案例
-
确定边界条件和项目范围
-
概述将推动设计权衡的关键需求和用例
-
勾勒出一个或多个候选架构
-
确定风险
-
成本估算和准备初步项目
- 建设迭代（Construction Iteration）
敏捷测试方法的第二阶段是构建迭代，大多数测试都在此阶段进行。为了做到这一点，在每个迭代中，团队实现了XP、Scrum、敏捷建模和敏捷数据等实践的混合。
在构建迭代中，敏捷团队遵循按优先级排序的需求实践：在每次迭代中，他们从工作项堆栈中提取剩余的最基本的需求并实现它们。
构建迭代分为两类，验证性测试和调查性测试。验证性测试集中于验证系统是否满足调查性测试处理的常见问题，如集成测试、负载/压力测试和安全性测试。
再次，对于验证性测试，有两个方面：开发人员测试和敏捷验收测试。验证性测试相当于按照规范进行的敏捷测试。
敏捷验收测试是传统功能测试和传统验收测试的结合，作为开发团队，利益相关方一起来做，开发人员测试验证应用程序代码和数据库架构。
- 发布结束故事或过渡阶段
“发布，结束故事”的目标是将系统成功地部署到生产中。在活动I中，它还包括产品发布的营销、备份和恢复、系统和用户文档的定稿。
最后的敏捷方法测试阶段包括完整的系统测试和验收测试。为了在故事结束时没有任何障碍地完成最终测试阶段，测试人员将致力于它的缺陷。
- 产量
在发布阶段之后，产品将进入生产阶段。
敏捷测试象限
敏捷测试象限将整个过程分成四个象限，并帮助理解敏捷测试是如何执行的。
- 敏捷象限I-内部代码质量是这个象限的主要关注点，它由技术驱动的测试用例组成，实现这些用例是为了支持团队，它包括
1. 单元测试
2. 组件测试
- 敏捷象限II-它包含业务驱动的测试用例，实现这些测试用例是为了支持团队。
1. 测试可能的场景和工作流的示例
2. 测试用户体验，如原型
3. 配对测试
- 敏捷象限III-此象限向象限1和象限2提供反馈。
1. 可用性测试
2. 探索性测试
3. 与客户配对测试
4. 协同测试
5. 用户验收测试
- 敏捷象限IV-此象限专注于非功能需求，如性能、安全性、稳定性等。在此象限的帮助下，应用程序将交付非功能质量和期望值。
1. 压力和性能测试等非功能测试
2. 关于身份验证和黑客攻击的安全测试
3. 基础设施测试
4. 数据迁移测试
5. 可扩展性测试
6. 负载测试
敏捷软件开发的QA挑战
-
敏捷中出错的可能性更大，因为文档优先级较低，最终会给QA团队带来更大压力
-
快速引入新功能，这减少了测试团队识别最新功能是否符合要求以及是否真正满足业务需求的可用时间
-
测试人员通常被要求扮演半开发人员角色
-
测试执行周期高度压缩
-
准备测试计划的时间非常少
-
对于回归测试，它们将有最少的时间
-
他们的角色从质量的把关人转变为质量的合作伙伴
-
需求更改和更新是敏捷方法固有的，成为QA面临的最大挑战
敏捷过程中的自动化风险
- 自动化UI提供了高水平的信心，但它们执行缓慢、维护脆弱且构建成本高昂。除非测试人员知道如何测试，否则自动化可能不会显著提高测试效率。
- 不可靠的测试是自动化测试中的一个主要问题。修复失败的测试并解决与脆性测试相关的问题应该是重中之重，以避免误报
- 如果自动测试是手动启动的，而不是通过CI(持续集成)启动的，则存在未定期运行的风险，因此可能会导致测试失败
- 自动化测试不能替代探索性的手动测试。为了获得预期的产品质量，需要混合测试类型和级别
- 许多商业上可用的自动化工具提供了一些简单的功能，比如自动捕获和重放手动测试用例。此外，将测试用例存储在版本控制系统之外会增加不必要的复杂性
- 为了节省时间，很多时候自动化测试计划计划不周或计划外导致测试失败
- 在测试自动化过程中，通常会遗漏测试设置和拆卸过程，而执行手动测试时，测试设置和拆卸过程听起来是无缝的
- 生产力度量(如每天创建或执行的测试用例数量)可能具有极大的误导性，并可能导致在运行无用测试方面进行大量投资
- 敏捷自动化团队的成员必须是有效的顾问：平易近人、合作和足智多谋，否则这个系统很快就会失败。
- 自动化可能会提出并交付测试解决方案，这些解决方案需要相对于所提供的价值进行过多的持续维护
- 自动化测试可能缺乏构思和交付有效解决方案的专业知识
- 自动化测试可能非常成功，以至于他们没有重要的问题要解决，从而变成了不重要的问题。
结论
软件测试中的敏捷方法涉及在软件开发生命周期中尽可能早地进行测试。主要是团队之间的沟通使敏捷模型测试成功！
