敏捷测试自动化框架

敏捷自动化测试

敏捷自动化测试 测试自动化是指在敏捷交付流程中使用测试自动化。其目的是在保证质量的同时，提高软件开发的效率和效能，并控制版本发布所需的时间和资源。由于测试用例与功能开发同步编写，因此测试自动化高度依赖于开发人员和测试人员之间的协作。

自从敏捷方法论旨在摒弃瀑布模型繁琐的现实问题以来，它的影响就已显现出来。 自动化测试 也一样。这两个学科必须有意识地结合起来：

瀑布式自动化与敏捷式自动化

在传统的软件测试生命周期中，一旦应用程序……，自动化测试就变得可行。 稳定，要求已确定它假设 相当长的时间这需要高技能的自动化专家，以及相当可观的初始投入成本。其基本目的是从长远角度降低成本，并确认现有测试用例周围没有引入新的缺陷。

自动化测试本质上并非探索性的。因为它的主要作用是节省时间和降低成本。它并非旨在发现新的、具有创新性的缺陷。自动化测试大多只是验证已存在的行为。

因此，这两种设置对测试套件的要求截然不同：

如何在敏捷方法论中实现自动化

敏捷方法论本身就摒弃了繁琐的文档工作，以便快速实施新想法，并促进人员自由互动。它更倾向于探索性工作而非文书工作：

敏捷方法论的基本理念与自动​​化测试之间存在着真正的矛盾。敏捷团队通过缩小自动化范围而非减少自动化程度来解决这个问题：测试用例与功能在同一迭代周期内编写，下推到单元测试和 API 测试层级（这些层级维护成本最低），并在每次构建时运行。

敏捷测试自动化的基本要点

在将冲刺资源投入自动化之前，请权衡以下几点，以决定脚本是否能够完成：

• 设计和编码时间： 每个剧本都必须像生产代码一样进行设计、编码和审查。
• 与测试数据进行验证： 最终脚本必须先用现有的测试数据进行验证，才能被任何人信任。
• 测试目的： 功能测试和回归测试的维护成本和有效期各不相同。
• Sprint 长度： 一个迭代周期为一到四周，最常见的是两周，这很少会给大规模的脚本编写工作留下空间。

第二个因素是需求变更。敏捷开发从定义上来说就是一种应对客户驱动型变更的技术，因此它适合在整个开发过程中频繁调整。

相比之下，自动化测试最适用于需求稳定的情况。它并不适合敏捷方法论中不断变化的需求，因此，选择自动化哪些内容比自动化多少内容更为重要。

敏捷自动化工具

选择相关 自动化工具 这是在敏捷方法论中采用自动化测试的另一个重要因素。例如，授权的自动化工具会对不同类型和级别的用户施加严格的安全访问标准，从而限制了哪些用户可以访问属于该测试自动化框架的资源。

相比之下，敏捷方法论强调团队成员之间的开放式协作和自由互动。限制性的访问策略会破坏这种凝聚力，并可能导致对项目成功既无益也无利可图的结果。

首要任务是在敏捷流程允许的时间内交付高质量的自动化脚本。仔细选择候选测试用例，以便生成的脚本可以重复使用，并且仍然能够在规定的时间内完成。

即使在敏捷开发环境中，仍然需要进行一些测试——尤其是回归测试。下一节将探讨自动化测试的适用场景，以及它们如何与敏捷测试相对应。

自动化测试 Concepts 应用于敏捷开发

下表列出了七个经典的自动化测试理由，并给出了每个理由的敏捷解决方案。其中只有三个理由可以清晰地转化为敏捷迭代，而且这三个理由都属于回归测试的范畴：

常见问题