某地儿见到别人推荐的讲自动化测试框架的书，虽然老了点儿，但是基本原理啥的讲的清清楚楚明明白白，所以读之。
原书链接在此，只有英文版，只有电子版：
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:
例如，验证登录页面上的用户名，我们可能有如下数据表：
| WINDOW | COMPONENT | ACTION | EXPECTED VALUE |
|---|---|---|---|
| LoginPage | UserIDTextbox | VerifyValue | “MyUseID” |
Reusable Code, Error Correction and Synchronization:
开发应用独立的组件功能，接受特定应用程序的变量数据。一旦组件功能存在，使用框架就可以在每一个被测的应用程序上进行应用。
在我们的设计中,主循环从数据表中读取记录,执行一些高层验证,关注适当的对象,然后使用适当的组件功能，处理完整的表格记录。组件功能负责确定什么动作是被请求的,并基于动作进一步完成表格记录。
| Framework Pseudo-Code |
|---|
| Primary Record Processor Module: Verify “LoginPage” Exists. (Attempt recovery if not) Set focus to “LoginPage Verify “UserIDTextbox” Exists. (Attempt recovery if not) Find “Type” of component “UserIDTextbox”. (It is a Textbox) Call the module that processes ALL Textbox components. Textbox Component Module: Validate the action keyword “VerifyValue”. Call the Textbox.VerifyValue function. Textbox.VerifyValue Function: Get the text stored in the “UserIDTextbox” Textbox. Compare the retrieved text to “MyUserID”. Record our success or failure. |
Test Design for Man and Machine, With or Without the Application:
人类测试员会这样理解并操作该表中的指令：
On the LoginPage, in the UserIDTextbox,
Verify the Value is “MyUserID”.
该表中的测试记录可以被一个人完全理解和执行，但是自动化框架对此一无所知，直到我们提供了额外的信息。这部分内容，我们将在讨论程序映射时进行学习。
Findings:
关键字驱动自动化框架，最初需要的投入比较大，但是这个初始投资是一次性的。一旦到位，关键字驱动自动化，即拥有了数据驱动框架的易用性，在后期的维护和长期使用上也拥有最大的潜力。
1.2.3 Hybrid Test Automation (or, “All of the Above”)
最成功的自动化框架通常适应关键字驱动测试以及数据驱动脚本。这允许数据驱动脚本利用强大的库和工具,通常伴随着一个关键字驱动架构。
1.2.4 Commercial Keyword Driven Frameworks
这部分说的内容有点儿老，跳过。目前主流的是一些这里没提到的开源工具。
1.3 Keyword Driven Automation Framework Model
以下自动化框架模型，花费了超过18个月来进行规划、设计、编码，以及一些试验和错误。当然，算工作量的话只需要1个人，3个月。
该模型着重于实现一个关键字驱动自动化框架。它不包含任何额外的功能,如跟踪需求或提供自动化测试结果之间的可跟踪性和任何其他功能的测试过程。它仅仅提供了一个模型,一个关键字驱动的自动化测试执行引擎。
1.3.1 Project Guidelines
项目是非正式地遵循以下指导原则或实践任务:
- 实现一个测试策略,允许合理直观的测试开发和执行手动和自动化框架。
- 测试策略将允许每个测试步骤执行,要使用的输入数据和预期的结果一起在同一行或输入源的记录。
- 实现一个框架,将整合关键字驱动测试和传统的脚本,让受益于实现。
- 实现框架是完全独立于应用程序,因为它需要测试至少4或5个不同的应用程序部署。
- 该框架将全面记录和发布。
- 框架将公开共享的内部网其他人使用和最终(但愿)共同开发。