什么是敏捷测试？

与WaterFall方法不同，敏捷测试可以在项目开始时开始，并在开发和测试之间进行持续集成。 敏捷测试不是顺序的（在某种意义上它只在编码阶段之后执行）而是连续的。

敏捷团队作为一个团队，致力于实现质量的共同目标。 敏捷测试具备更短的时间范围，称为迭代（例如1至4周）。 这种方法也称为发布或者交付驱动方法，由于它可以在短时间内更好地预测可用产品。

敏捷测试计划

与瀑布模型不同，在敏捷模型中，为每个版本编写和升级测试计划。 敏捷测试计划包括在该迭代中完成的测试类型，如测试数据要求，基础架构，测试环境和测试结果。 敏捷中的典型测试计划包括

• 测试范围
• 正在测试的新功能
• 基于特征复杂性的级别或者测试类型
• 负载和性能测试
• 基础设备考虑
• 缓解或者风险计划
• 资源
• 可交付成果和里程碑

敏捷测试策略

敏捷测试生命周期跨越四个阶段

• 迭代0

在第一阶段或者迭代0期间，您执行初始设置任务。 它包括识别人员进行测试，安装测试工具，调度资源（可用性测试试验室）等。以下步骤设置为在迭代0中实现

a）为项目建立业务案例

b）确定边界条件和项目范围

c）概述将推动设计权衡的关键要求和用例

d）概述一个或者多个候选架构

e）识别风险

f）成本估算并准备初步项目

• 构建迭代

测试的第二阶段是构造迭代，大多数测试发生在此阶段。 这个阶段被观察为一组迭代，以构建处理方案的增量。 为了做到这一点，在每次迭代中， 团队实现了XP，Scrum，敏捷建模和敏捷数据等实践的混合。

在构建迭代中，敏捷团队遵循优先级需求实践：每次迭代，他们从工作项堆栈中获取剩余的最基本需求并实现它们。

构建迭代分为两个，验证测试和调查测试。 确认测试集中于验证系统能否满足了迄今为止团队所形容的利益相关者的用意，并由团队执行。 尽管调查测试检测到确认团队已跳过或者忽略的问题。 在调查测试中，测试人员以缺陷故事的形式确定潜在的问题。 调查测试涉及集成测试，负载/压力测试和安全测试等常见问题。

再次，确认测试有两个方面开发人员测试和敏捷验收测试 。 它们都是自动化的，可以在整个生命周期内进行连续回归测试。 确认测试是对规范进行测试的敏捷测试。

敏捷验收测试是传统功能测试和传统验收测试相结合的开发团队，利益相关者正在共同完成。 尽管开发人员测试是传统单元测试和传统服务集成测试的混合。 开发人员测实验证应用程序代码和数据库架构。

• 发布结或者过渡阶段

“发布结束”的目标是将您的系统成功部署到生产中。 这一阶段的活动包括对最终客户，支持人员和业务人员的培训。 此外，它还包括产品发布，备份和恢复，系统最终确定和客户文档的营销。

最终测试阶段包括完整的系统测试和验收测试。 按照完成最终测试阶段没有任何障碍，您应该在构建迭代时更严格地测试产品。 在最后的游戏中，测试人员将研究其缺陷故事。

• 生产

在发布阶段之后，产品将进入生产阶段。

敏捷测试的要素

敏捷测试象限将整个过程分为四个象限，有助于了解敏捷测试的执行方式。

• a） 敏捷象限I - 内部代码质量是该象限的主要焦点，它由技术驱动的测试用例组成，用于支持团队，包括

1.单元测试

2.组件测试

• b） 敏捷象限II - 它包含 业务驱动的测试用例，用于支持团队。 该象限侧重于要求。 在这个阶段进行的测试类型是

1.测试可能的场景和工作流程的示例

2.测试客户体验，例如原型

3.结对测试

• c） 敏捷象限III - 该象限为象限1和2提供反馈。 测试用例可以用作执行自动化测试的基础。 在该象限中，进行了多轮迭代评审，从而建立了对产品的信心。 在这个象限中进行的测试类型是

1.可用性测试

2.探究性测试

3.与用户进行测试

4.协作测试

5.客户验收测试

• d） 敏捷象限IV - 该象限集中于非功能性要求，如性能，安全性，稳固性等。在此象限的帮助下，应用程序可提供非功能性质和预期值。

1.非功能性测试，如压力和性能测试

2.关于身份验证和黑客攻击的安全性测试

3.基础设备测试

4.数据迁移测试

5.可伸缩性测试

6.负载测试

QA在敏捷软件开发方面面临挑战

a）更容易犯错，由于文档优先级较低，最终给QA团队带来更大的压力

b）快速引入新功能，时间更加紧迫

c）测试人员经常是半个开发人员

d）测试执行周期是高度压缩的

e）准备测试计划的时间非常短

f）对于回归测试的时间最短

g）测试的角色从成为质量的守门人转变为成为质量的合作伙伴

h）需求变更和升级是敏捷方法所固有的，成为QA的最大挑战

敏捷过程中的自动化风险

• 自动UI提供了高度的信心，但它们执行缓慢，维护脆弱且构建成本高。 除非测试人员知道如何测试，否则自动化可能无法显着提高测试效率
• 不可靠的测试是自动化测试中的主要问题。 修复失败测试和处理与脆弱测试相关的问题应该是首要任务，以避免误报
• 假如自动测试是手动启动而不是通过CI（持续集成）启动，那么它们可能无法定期运行，因而可能导致测试失败
• 自动化测试不能替代探究性手动测试。 为了取得产品的预期质量，需要混合测试类型和级别
• 许多商用自动化工具提供简单的功能，如自动捕获和重放手动测试用例。 这样的工具鼓励通过UI进行测试，并导致本质上脆弱且难以维护的测试。 此外，在版本控制系统外部存储测试用例会产生不必要的复杂性
• 为了节省时间，很多时候自动化测试计划计划不周或者计划外，导致测试失败
• 测试自动化期间通常会错过测试设置和拆卸程序，而执行手动测试，测试设置和拆卸程序听起来无缝
• 生产力指标（例如每天创立或者执行的大量测试用例）可能会非常误导，并可能导致在运行无用测试方面投入大量资金
• 敏捷自动化团队的成员必需是有效的顾问：平易近人，合作和足智多谋，否则这个系统很快就会失败
• 自动化可以提出并提供相对于所提供的值而言需要过多持续维护的测试处理方案
• 自动化测试可能缺乏构思和提供有效处理方案的专业知识
• 自动化测试可能非常成功，以至于他们无法处理重要问题，从而转向不重要的问题。

结论

敏捷测试涉及在软件开发生命周期中尽早进行测试。 它需要高度的用户参加和测试代码一旦可用。 代码应足够稳固，以便进行系统测试。 可以进行广泛的回归测试，以确保错误得到修复和测试。 主要是，团队之间的沟通使敏捷测试成功！