自动化测试方法——哪个最好？

Question

哪种自动化方法最适合？是数据驱动测试还是关键字驱动测试？现在即使我们有业务流程测试，您认为最好的方法是什么？

Answer 1

这一切都取决于您的需求。 作为一项长期投资，我推荐关键字驱动或混合关键字/数据驱动框架。

请参阅下面的简短概述（摘自我的博客页面http://automation-beyond.com/category/automation/automation-methodology/practices/）。

前端测试自动化实践 - 记录/回放

1. 说明 • 硬编码数据 • 硬编码流 • 没有错误处理 • 没有或有限的报告 • 没有结构 • 没有验证 • 无验证

2. 优势 • 易于创建 • 快速创建 • 无需编程

3. 缺点 • 非常低的可用性 • 极高的维护成本 • 无证明测试结果 • 在任何失败时中断 • 测试流程覆盖率低 • 仍然需要大量的手工工作

4. 适用性 • 演示和销售演示 • 当天测试（从头开始重新录制，测试流程短） • 探索性测试（调查测试工具如何处理应用程序） • 自动数据输入（有限制）

前端测试自动化实践 - 记录/回放增强

1. 说明 • 参数化数据 • 数据集是脚本的一部分，但不在代码中 • 通过 GUI 检查点进行验证（硬编码） • 硬编码流 • 没有错误处理 • 没有或有限的报告 • 没有结构

2. 优势 • 易于创建 • 快速创建 • 无需编程，但必须具备测试工具方面的专业知识

3. 缺点 • 易受攻击的脚本 • 不支持多环境 • 检查站的维护成本非常高 • 不可重现的测试结果 • 在任何失败时中断 • 有限的测试流程覆盖范围 • 手动完成所有分析和验证

4. 适用性 • 单一/稳定的环境 • 短流程测试用例 • 有限的检查点集，因为任何数据库/数据输入更改都会破坏验证并需要重新捕获 • 短期简化自动化目标

前端测试自动化实践 - 数据驱动框架

1. 说明 • 以编程方式创建 • 参数化，能够导入电子表格 • GUI/数据库检查点，硬编码和/或参数化 • 基于库的结构 • 可能的错误处理 • 硬编码但数据驱动的流程（输入和逻辑） • 标准报告 • 验证仅限于测试工具的功能 • 无验证

2. 优势 • 良好的可用性和可重用性 • 良好的测试流程覆盖率 • 多环境支持 • 数据和代码是分开的 • 可重现的测试结果

3. 缺点 • 质量和覆盖范围在很大程度上取决于实施人员的自动化技能 • 大量代码导致的持续维护问题 • 失败退出 • 需要手动验证

4. 适用性 • 非常适合单个应用程序测试，具有多环境、大数据集和很少更改的测试用例 • 通过额外的开发工作可以批量运行 • 有限的检查点集，因为任何数据库/数据输入更改都会破坏验证并需要重新捕获 • 需要跨团队工作空间（环境、数据等）共享（离岸支持可能存在问题） • 中期自动化目标

前端测试自动化实践 - 关键字驱动框架

1. 说明 • 纯程序化 • 参数化，能够导入电子表格 • GUI/数据库检查点，硬编码和/或参数化 • 基于框架的结构 • 有限的错误处理 • 基于关键字的流程（电子表格中的逻辑和数据） • 可能扩展报告 • 验证仅限于测试工具的功能 • 无验证

2. 优势 • 良好的可用性和可重用性 • 紧凑的代码 • 测试开发不需要编程技能 • 良好的测试流程覆盖率 • 多环境支持 • 数据和代码是分开的 • 可重现的测试结果

3. 缺点 • 需要对框架的设计和实施进行初始投资 • 由于关键字限制，不允许覆盖非常复杂的测试用例 • 需要对员工进行元语言特定培训 • 版本控制问题 • 失败退出 • 需要手动验证

4. 适用性 • 非常适合多应用测试（同一平台），具有多环境、大数据集和大量简短而直接的测试用例 • 测试计划/测试场景执行（批量运行） • 有限的检查点集，因为任何数据库/数据输入更改都会破坏验证并需要重新捕获 • 更好地支持分布式团队，尤其是实施了扩展报告 • 对元语言的多工具支持 • 中长期自动化目标

前端测试自动化实践 - 混合关键字/数据驱动框架

1. 说明 • 纯程序化 • 内部数据模型，能够从各种来源导入/导出数据 • GUI/数据库检查点，参数化/转换 • 业务验证规则 • 基于框架的结构；能够集成外部对象（即 MSXML DOM） • 异常处理和恢复能力 • 面向测试用例的执行（代码之外的业务逻辑） • 数据驱动的输入和验证 • 扩展业务报告 • 基于人工智能的验证方法

2. 优势 • 高可用性和可重用性 • 紧凑且可扩展的架构 • 测试计划/测试场景创建不需要对测试工具进行编程或培训 • 广泛的测试流程覆盖 • 多应用支持 • 数据和代码是分开的 • 可重复且经过验证的测试结果，方便且可转移的测试报告 • 内置一致性和严重性验证

3. 缺点 • 需要对框架的设计和实施进行初始投资

4. 适用性 • 多应用、多平台产品的综合功能测试，包含大量复杂的测试用例 • 具有广泛覆盖和验证的烟雾-回归-健全性测试周期 • 测试计划/测试场景执行（批量运行） • 大而多变的数据集和数据转换案例 • 对分布式团队的出色支持 • 与其他测试工具集成 • 中长期自动化目标

Answer 2

听起来您的问题是针对 HP 的 QTP/BPT 的。以下是不同之处。 QTP 实际上是 BPT 和 QTP 使用的“引擎”。 QTP 为使用脚本提供了两个主要视图。

QTP： 第一个是“关键字”视图，它呈现动作和功能树。此模式适合初学者，允许他们从应用程序或对象存储库中选择对象，以及选择要对对象执行的方法。然后自动生成脚本。

第二个是“专家”视图，它允许显示和编辑脚本源代码。专家 veiw 提供了一个用于开发脚本的 IDE。此视图适合高级用户。

BPT 基于从可重用业务组件创建测试用例的概念，而这些业务组件又从关键字创建。这种关键字驱动的方法通过提供允许用户“拖放”组件来构建测试的 gui 来简化测试用例的创建过程。脚本是自动生成的。

Answer 3

这取决于您在特定情况下要完成的工作。然而，普遍的一件事是测试自动化是软件开发，需要这样对待。使用合理的设计和编码实践。听起来你是自动化的新手。通常一个好的开始是构建一个烟雾测试，它会为每个新构建快速运行。