什么是敏捷测试？流程和生命周期

什么是敏捷测试？

敏捷测试 是一种遵循敏捷软件开发规则和原则的测试实践。与瀑布方法不同，敏捷测试可以在项目开始时开始，并在开发和测试之间进行持续集成。敏捷测试方法不是顺序的（在编码阶段之后才执行），而是连续的。

敏捷测试的原则

以下是敏捷测试的基本原则：

• 在这个敏捷测试模型中，工作软件是进度的主要衡量标准。
• 自组织的团队可以取得最好的结果。
• 尽早并持续地交付有价值的软件是我们的首要任务。
• 软件开发人员必须在整个项目过程中每天采取行动进行收集。
• 通过持续的技术改进和良好的设计来增强敏捷性。
• 敏捷测试通过提供持续的反馈来确保最终产品满足业务的期望。
• 在敏捷测试流程中，我们需要在实施过程中执行测试过程，从而减少了开发时间。
• 敏捷中的测试流程应该按照一致的开发节奏进行
• 定期反思如何提高效率。
• 最好的架构、需求和设计来自自组织团队。
• 每次团队开会时，都会回顾并调整其行为以提高效率。
• 与开发团队面对面交谈是在团队内部传达信息的最有效、最快捷的方法。

敏捷测试包含多种帮助我们提高软件生产力的原则。

敏捷测试生命周期

敏捷测试生命周期分五个不同阶段完成，如下图所示：

以下是敏捷流程测试步骤：

第一阶段：影响评估： 在这个初始阶段，我们收集利益相关者和用户的意见。此阶段也称为反馈阶段，因为它可以帮助测试工程师设定下一个生命周期的目标。

第二阶段：敏捷测试规划： 这是敏捷测试生命周期的第二阶段，所有利益相关者聚集在一起规划测试过程和交付成果的时间表。

第 3 阶段：发布准备： 在此阶段，我们会检查已开发/实施的功能是否已准备好上线。在此阶段，还会决定哪些功能需要返回到上一个开发阶段。

阶段 4：每日站会： 此阶段包括每次早会，以了解测试状态并设定一整天的目标。

阶段 5：测试敏捷性 Review： 敏捷生命周期的最后一个阶段是敏捷 Rev评估会议。它包括每周与利益相关者举行会议，定期评估和评定目标的进展情况。

敏捷测试计划

敏捷测试计划 包括该迭代中完成的测试类型，如测试数据要求、基础设施、 测试环境和测试结果。与瀑布模型不同，在敏捷模型中，每次发布都会编写和更新测试计划。敏捷中的典型测试计划包括

• 测试范围
• 正在测试的新功能
• 根据功能复杂性确定测试级别或类型
• 负载和性能测试
• 基础设施考虑
• 缓解或风险计划
• 提供资源
• 可交付成果和里程碑

敏捷测试策略

敏捷测试生命周期分为四个阶段

迭代0

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

• 为项目建立商业案例
• 建立边界条件和项目范围
• 概述推动设计权衡的关键要求和用例
• 概述一个或多个候选架构
• 识别风险
• 成本估算和准备初步项目

构建迭代

敏捷测试方法的第二阶段是构建迭代，大多数测试都在此阶段进行。此阶段被视为一组迭代，用于构建解决方案的增量。为了做到这一点，在每次迭代中， 团队实施 XP、Scrum、敏捷建模和敏捷数据等实践的混合。

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

构建迭代分为确认性测试和调查性测试两类。 确认测试浓缩物 验证系统是否满足利益相关者迄今为止向团队描述的意图，并由团队执行。而调查性测试则检测确认团队跳过或忽略的问题。在调查性测试中，测试人员以缺陷故事的形式确定潜在问题。调查性测试处理集成测试、负载/压力测试和安全测试等常见问题。

再次，确认测试有两个方面 开发人员测试 和 敏捷验收测试。 两个都 自动化，以便在整个生命周期内进行持续回归测试。确认测试相当于敏捷测试。

敏捷验收测试是传统功能测试和传统验收测试的结合，开发团队和利益相关者共同进行测试。而开发人员测试则是传统单元测试和传统服务集成测试的混合。开发人员测试会验证应用程序代码和数据库模式。

发布结束游戏或过渡阶段

“发布，最终游戏”的目标是成功将您的系统部署到生产中。此阶段的活动包括培训最终用户、支持人员和操作人员。此外，它还包括产品发布的营销、备份和恢复、系统最终确定和用户文档。

敏捷方法测试的最后阶段包括完整的系统测试和验收测试。为了顺利完成最终测试阶段，您应该在构建迭代过程中对产品进行更严格的测试。在最后阶段，测试人员将致力于解决其缺陷故事。

生产

发布阶段结束后，产品将进入生产阶段。

敏捷测试象限

敏捷测试象限将整个过程分为四个象限，有助于理解如何执行敏捷测试。

敏捷象限 I

内部代码质量是此象限的主要关注点，它由技术驱动并为支持团队而实施的测试用例组成，其中包括

• 单元测试
• 组件测试

敏捷象限 II

它包含业务驱动的测试用例，用于支持团队。此象限侧重于需求。此阶段执行的测试类型是

• 测试可能的场景和工作流程的示例
• 测试用户体验，例如原型
• 配对测试

敏捷象限 III

此象限为第一象限和第二象限提供反馈。测试用例可用作执行自动化测试的基础。在此象限中，进行了多轮迭代审查，从而建立了对产品的信心。在此象限中进行的测试类型是

• 可用性测试
• 探索性测试
• 与客户配对测试
• 协作测试
• 用户验收测试

敏捷象限 IV

该象限集中于非功能性需求，例如性能，安全性，稳定性等。借助该象限，应用程序可以提供非功能性品质和预期价值。

• 压力和性能测试等非功能性测试
• 安全测试 认证 和骇客
• 基础设施测试
• 数据迁移测试
• 可扩展性测试
• 负载测试

敏捷软件开发中的 QA 挑战

• 敏捷中出现错误的可能性更大，因为文档的优先级较低，最终给 QA 团队带来更大压力
• 新功能的快速推出，减少了测试团队识别最新功能是否符合需求以及是否真正满足业务需求的时间
• 测试人员通常需要扮演半开发人员的角色
• 测试执行周期高度压缩
• 准备测试计划的时间非常少
• 对于回归测试，他们将有最少的时间
• 角色从质量守门人转变为质量合作伙伴
• 需求变更和更新是敏捷方法的固有特征，成为 QA 面临的最大挑战

敏捷流程中的自动化风险

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

结语

软件测试中的敏捷方法涉及尽早进行测试 软件开发生命周期。它要求客户高度参与，并在代码可用时立即进行测试。代码应该足够稳定，以便进行系统测试。可以进行广泛的回归测试，以确保错误得到修复和测试。主要是，团队之间的沟通使敏捷模型测试成功！！！