读 Test Automation Frameworks

2018-07-23  本文已影响24人  cynthia猫

某地儿见到别人推荐的讲自动化测试框架的书,虽然老了点儿,但是基本原理啥的讲的清清楚楚明明白白,所以读之。
原书链接在此,只有英文版,只有电子版:
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

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

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.

(未完待续)

上一篇下一篇

猜你喜欢

热点阅读