某地儿见到别人推荐的讲自动化测试框架的书，虽然老了点儿，但是基本原理啥的讲的清清楚楚明明白白，所以读之。
原书链接在此，只有英文版，只有电子版：
http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm

这就是个读书笔记，想好好理解的话还是去看原文。部分标题，我自己给出了不大顺溜的翻译，请以原文为准。

1.1 Thinking Past "The Project" (思考不要局限在一个项目上）

不能指望来一个项目，就对应的做一个自动化测试框架，需要开发一个独立与项目之上的框架。

1.1.1 Problems With Test Automation. A CASE STUDY

讲了一个失败的例子。
有个大公司1996年开始评估自动化工具，并在1998年购买了一款商用自动化工具投入使用。
该公司的项目都是独立运作的，所以自动化项目也是独立的，因此每个项目有各自的脚本，各项目也各自写了自己项目的公共库，等。
而当各项目的程序有变化时，脚本需要维护；自动化工具升级时，可能会造成脚本失败，就需要维护甚至降级自动化工具。
无休止的这种维护支出，最终导致了自动化项目的被搁浅。

1.1.2 Some Test Strategy Guidelines

教训：必须开发可重用的测试策略。

• Test automation is a fulltime effort, not a sideline.
• The test design and the test framework are totally separate entities.
• The test framework should be application-independent.
• The test framework must be easy to expand, maintain, and perpetuate.
• The test strategy/design vocabulary should be framework independent.
• The test strategy/design should remove most testers from the complexities of the test framework.

1.2 Data Driven Automation Frameworks（数据驱动自动化框架）

1.2.1 Data Driven Scripts.

依靠数据驱动脚本的测试自动化框架，是最容易和最快执行的，如果有技术人员来持续维护的话。
但维护它是比较困难的，经常会导致长期的失败。

1.2.2 Keyword or Table Driven Test Automation

至今为止的讨论表明，关键字驱动的测试自动化是比较理想的自动化框架。有时也称之为"表格驱动"测试自动化。

Action, Input Data, and Expected Result ALL in One Record:
例如，验证登录页面上的用户名，我们可能有如下数据表：

Reusable Code, Error Correction and Synchronization:

开发应用独立的组件功能，接受特定应用程序的变量数据。一旦组件功能存在，使用框架就可以在每一个被测的应用程序上进行应用。

在我们的设计中,主循环从数据表中读取记录,执行一些高层验证,关注适当的对象,然后使用适当的组件功能，处理完整的表格记录。组件功能负责确定什么动作是被请求的,并基于动作进一步完成表格记录。

（未完待续）