测试自动化框架
度量测试自动化，可以有不同视角的标准。其中一个度量测试自动化的可行标准是将它分为如下5级：1.线性
2.结构化
3.模块化
4.数据驱动
5.关键字驱动
要实现上述后3个自动化等级，必需用到测试自动化框架（Test Automation Framework，简写TAF）。TAF为框架和被测应用（Application Under Test，简写AUT）提供了一组可重用的支持功能。针对框架的支持功能主要是与应用无关的，可以很容易地用于其他产品的自动化脚本或程序，例如，字符串处理、文件处理、变量处理等等。针对AUT的支持功能应该是与框架无关的，将针对应用的特定实现隐藏起来，提供抽象层级的接口，以便TAF可以识别为库例程（Routine）或脚本。
这些支持功能可以以两种形式来提供：库例程或关键字。库例程实现了可被不同自动化测试用例调用的那些常用基础功能；关键字就是可以被TAF识别和执行的文本字串，它的底层就是针对AUT的支持功能，或者换句话说就是模块函数。
可重用性在TAF中扮演着重要角色，我们最好能重用函数，甚至是能重用自动化测试用例。关键字驱动型（有时也叫做表格驱动型）TAF主张将自动化测试用例抽象为三个层级：步骤（Step）表格、套组（Suite）表格、循环（Cycle）表格。
●步骤表格包含的是使用单个关键字及其参数来执行特定任务的步骤。一个步骤表格可能代表的是一个测试用例，或者是拥有相同操作组合的更大测试用例（体现为套组表格或循环表格）的一部分；
●套组表格主要是将步骤表格纳入作为其操作步骤，同时也可以是更大测试用例（体现为循环表格）的一部分；
●循环表格可能会纳入套组表格或步骤表格作为其操作步骤。
这种划分只是一种可选方案而已，基本上来说它也就是让表格可以被重用的一种方式，不管是步骤、套组还是循环表格。
设计TAF的时候，万万不可忽视软件研发生命周期其他方面，尤其注意要跟测试策略一起考虑，推荐大家在制定整体测试策略时遵守如下这些重要指导原则：
●测试自动化是一个全职工作，不是兼职副业。
●测试设计和测试框架是完全独立的实体。
●测试框架应该是应用无关的。
●测试框架必须易于扩展、维护和持久。
●测试策略及设计的词汇表应该是框架无关的。
●测试策略及设计应该让大部分测试人员可以无需操心测试框架的复杂性。
我们无法脱离测试的范畴来谈TAF，就像我们无法脱离软件研发生命周期来谈测试一样。不同的TAF代表了对TA的不同看法，有不同的抽象层级及职责，同样也有着不同的适用场景。
使用模块化类型的TAF可能会需要工程师具备很多能力，包括框架开发、支持库的功能实现以及测试用例实现等能力，他们需要熟悉或掌握一些编程语言，有软件研发实践的经验，还应该知晓产品特性。只有这样才能保证我们的自动化能够把代码（自动化代码）构建正确，同时也构建了正确的代码。
当我们使用数据驱动型TAF时，至少我们可以把职责区分为两类，一类负责要验证的测试数据，一类负责前述职责的剩余部分。但目标没有变，我们要提供可靠的自动化测试用例。
关键字驱动将职责分得更细。有些人负责开发和维护框架本身，有些人负责支持功能或称模块函数，同时其他工程师应该去实现实质性的自动化测试用例，例如步骤、套组、循环表格等。
管理员的贴子我一定要顶一顶 seagull1985 发表于 2017-11-3 15:59
管理员的贴子我一定要顶一顶
太给面子了！;P
页:
[1]
