阅读《Test Automation Frameworks》

在开发我们的测试策略时，我们必须将我们正在测试的应用程序的更改以及用于测试它们的工具的更改所造成的影响降到最低。

1.1对“项目”过去的思考

项目周期减少要求测试时间减少；在不同的项目中移动的测试人员可能更有可能成为一种阻碍而不是帮助；因此，我们必须努力开发一个单一的框架，随着每个应用程序和每个挑战我们的不同项目不断发展和改进。我们将在第1.2节中看到这些不同方法的优点和缺点。

1.1. 1测试自动化的问题

1.测试工具不适合
2.测试人员不具备开发经验，只能测试
举例说明:
持续测试开发和测试代码维护的资源分配成为一个困难的问题。

1.1.2 一些测试策略指南

由之前错误案例意识到：我们必须开发可重用的测试策略与任何好的应用程序开发项目的可重用性问题没有什么不同。
为了充分利用我们的测试策略，我们需要使其可重用和可管理。为此，在制定整体测试策略时，我们应该遵循一些基本的指导原则:

1. 测试自动化是一项全职工作，而不是副业。
2. 测试设计和测试框架是完全独立的实体。
3. 测试框架应该是应用程序独立的。
4. 测试框架必须易于扩展、维护和延续。
5. 测试策略/设计词汇表应该独立于框架。
6. 测试策略/设计应该将大多数测试人员从测试框架的复杂性中移除。

1.1.3 测试自动化是一项全职工作，而不是副业

这不是一个人可以花一点点时间完成的

1.1.4 测试设计和测试框架是完全独立的实体

开发这个框架需要与测试设计完全不同的技术技能；
测试框架详细说明了如何测试应用程序的特定功能和特性。它将告诉我们该做什么，如何做，何时做，使用什么数据作为输入，以及我们期望找到什么结果。

1.1.5 测试框架应该是应用程序独立的。

虽然应用程序是相对独特的，但组成它们的组件通常不是。因此，我们应该将自动化框架的重点放在处理组成我们独特应用程序的公共组件上。通过这样做，我们可以从框架中删除所有特定于应用程序的上下文，并且实际上重用我们为每个应用程序开发的所有经过自动化测试过程的内容。
我们应该把自动化框架的重点放在处理组成我们独特应用程序的公共组件上。
这个框架应该处理所有细节，确保我们有正确的窗口，验证感兴趣的元素处于正确的状态，对该元素进行操作，并记录整个活动的成功或失败。为此，我们使用变量，并向独立于应用程序的框架提供特定于应用程序的数据。
尝试将特定于应用程序的测试脚本限制在一小部分。

1.1.6 测试框架必须易于扩展、维护和延续。

模块化和可维护
设计文档必须保留，便于维护

1.1.7 测试策略/设计词汇表应该独立于框架

框架指的是我们构建用于执行测试的整体环境。
总体测试策略将定义我们用来测试所有应用程序的格式和低级词汇表，我们的词汇表将独立于所使用的任何特定测试框架。同样的词汇将随着我们从一个框架迁移到另一个框架，从一个应用程序迁移到另一个应用程序。这意味着，例如，无论我们使用什么工具来执行指令，或包含该按钮的应用程序，用于单击按钮的语法都是相同的。
一个好的测试策略可以消除手动和自动测试脚本的必要性。同样的‘脚本’应该对两者都足够了。

1.1.8 测试策略/设计应该将大多数测试人员从测试框架的复杂性中移除

我们的大部分测试人员可以专注于测试设计，并且只专注于测试设计。自动化框架人员将重点关注自动化这些测试的工具和实用程序。（小声哔哔，又让我写测试用例又让我搞框架，没人性！！！）

1.2数据驱动自动化框架

数据驱动脚本

数据驱动脚本是那些特定于应用程序的脚本，这些脚本被捕获或用自动化工具的专有语言手工编码，然后修改以适应可变数据。变量将用于关键的应用程序输入字段和程序选择，允许脚本使用调用例程或调用测试脚本的shell提供的外部数据驱动应用程序。

1. 可变数据，硬编码组件识别:
2. 高技术或重复测试设计:
   数据驱动脚本的另一个常见特性是，实际上应用程序的所有测试设计工作都是在自动化工具的脚本语言中开发的。这意味着与应用程序的自动化测试开发或自动化测试执行有关的每个人都必须精通自动化工具的环境和编程语言
3. 发现:
   依赖于数据驱动脚本的测试自动化框架无疑是最容易和最快速实现的，如果您有并保持技术人员来维护它的话。但这是数据驱动的方法中最难维护和延续的，经常会导致长期失败。

1.2.2关键字或表驱动测试自动化

1. 动作、输入数据和预期结果都在一条记录中:
   数据表记录包含描述我们想要执行的操作的关键字。它们还提供作为应用程序输入所需的任何额外数据，以及我们用于验证组件和应用程序状态的基准测试信息。
2. 可重用代码、纠错和同步:
   开发了应用程序独立的组件函数，它接受特定于应用程序的变量数据。一旦这些组件函数存在，就可以在我们选择用框架测试的每个应用程序上使用它们。
3. 人与机器的测试设计，有或没有应用
   测试框架会有一个运行的执行记录，测试人员学习或可以参考这个简单的词汇表，就可以开始设计测试，而不需要了解用于执行测试的自动化工具。
   关键字驱动方法的另一个优点是，只要初步的需求或设计可以确定，测试人员就可以在没有功能应用程序的情况下开发测试。

1.2.3混合测试自动化(或“以上所有”)

最成功的自动化框架通常同时容纳关键字驱动的测试和数据驱动的脚本。这使得数据驱动脚本可以利用关键字驱动架构通常附带的强大库和实用程序。
框架实用程序可以使数据驱动的脚本更加紧凑，并且不容易出现故障。这些实用程序还可以在需要的时间和地点将现有脚本逐步地、可管理地转换为关键字驱动的等价脚本。
另一方面，框架可以使用脚本来执行一些任务，这些任务可能很难用纯关键字驱动的方法重新实现，或者关键字驱动的功能还没有到位。

1.2.4商业关键词驱动框架

1.3关键词驱动自动化框架模型

该模型着重于实现一个关键字驱动的自动化框架。它不包括任何附加特性，如跟踪需求或提供自动测试结果和测试过程的任何其他功能之间的可跟踪性。它仅仅为自动化测试的关键字驱动执行引擎提供了一个模型。

1.3.1项目指南

该项目被非正式地委托遵循以下指导方针或实践:

1. 实现一个测试策略，允许合理地直观地开发测试，并通过手动和自动化框架执行测试。
2. 测试策略将允许每个测试包含要执行的步骤、要使用的输入数据和预期的结果，这些都包含在输入源的一行或一条记录中。
3. 实现一个集成关键字驱动测试和传统脚本的框架，使两者都能从实现中受益。
4. 将框架实现为完全独立于应用程序的，因为它需要测试至少4或5个不同的应用程序

1.3.2代码和文档标准

1.3.2我们的自动化框架

测试执行从LAUNCH test(1)脚本开始。
这个脚本通过向CycleDriver(2)提供一个或多个高级测试表来调用核心数据驱动引擎。
CycleDriver处理这些测试表，调用它遇到的每个中级测试表的suitdriver(3)。
suitdriver处理这些中级表，并为它遇到的每个低级测试表调用StepDriver(4)。
当StepDriver处理这些低级表时，它试图保持应用程序与测试同步。
当StepDriver遇到一个特定组件的低级命令时，它会确定所涉及的组件类型，并调用相应的组件函数(5)模块来处理该任务。

1.4自动化框架工作流程

我们已经看到了自动化框架的主要特性，现在我们要对其进行测试。本节提供了一个测试工作流模型，它可以很好地与这个框架一起工作。从本质上讲，我们首先定义高级循环表，然后为应用程序映射和低级步骤表提供越来越多的细节。

1.5总结

依赖于数据驱动的自动化工具脚本的测试策略绝对是最容易和最快实现的，如果您有并保持技术人员来处理它的话。但这是最难的