日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | |||||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 | |||
| 13 | 14 | 15 | 16 | 17 | 18 | 19 | |||
| 20 | 21 | 22 | 23 | 24 | 25 | 26 | |||
| 27 | 28 | 29 | 30 | 31 | |||||
搜索标题
最新来客
最新评论
我的收藏
音乐欣赏
统计信息
- 访问量: 1327
- 日志数: 13
- 图片数: 2
- 建立时间: 2006-12-11
- 更新时间: 2007-12-17
RSS订阅
我的最新日志
-
咖啡和茶
2007-12-17
-
一种心境:波澜不兴，恬淡而宁静至极
2007-12-12
-
给自己的忠告..
2007-12-10
-
Choosing a test automation framework
2007-5-30
Document options requiring Javascrīpt are not displayed
Level: Introductory
Michael Kelly, Software Engineer, QA, Liberty Mutual
A test automation framework is a set of assumptions, concepts, and practices that provide support for automated software testing. This article describes and demonstrates five basic frameworks.
Basing an automated testing effort on using only a capture tool such as IBM Rational® Robot to record and play back test cases has its drawbacks. Running complex and powerful tests is time consuming and expensive when using only a capture tool. Because these tests are created ad hoc, their functionality can be difficult to track and reproduce, and they can be costly to maintain.
A better choice for an automated testing team that's just getting started might be to use a test automation framework, defined as a set of assumptions, concepts, and practices that constitute a work platform or support for automated testing. In this article I'll attempt to shed a little light on a handful of the test automation frameworks I'm familiar with -- specifically, test scrīpt modularity, test library architecture, keyword-driven/table-driven testing, data-driven testing, and hybrid test automation. I won't evaluate which framework is better or worse but will just offer a descrīption and a demonstration of each and, where appropriate, some tips on how to implement it in the IBM Rational toolset.
The Test scrīpt Modularity Framework
The test scrīpt modularity framework requires the creation of small, independent scrīpts that represent modules, sections, and functions of the application-under-test. These small scrīpts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case.
Of all the frameworks I'll review, this one should be the simplest to grasp and master. It's a well-known programming strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. The test scrīpt modularity framework applies this principle of abstraction or encapsulation in order to improve the maintainability and scalability of automated test suites.
To demonstrate the use of this framework, I'll automate a simple test case for the Windows Calculator program (see Figure 1) to test the basic functions (add, subtract, divide, and multiply).
Figure 1: The Windows Calculator At the bottom level of the scrīpt hierarchy are the individual scrīpts testing addition, subtraction, multiplication, and division. As examples, the first scrīpt that follows tests addition and the second scrīpt tests subtraction.
The two scrīpts at the next level of the hierarchy would then be used to represent the Standard view and the Scientific view available from the View menu. As the following scrīpt for the Standard view illustrates, these scrīpts would contain calls to the scrīpts we built previously.
And finally, the topmost scrīpt in the hierarchy would be the test case to test the different views of the application.
From this very simple example you can see how this framework yields a high degree of modularization and adds to the overall maintainability of the test suite. If a control gets moved on the Calculator, all you need to change is the bottom-level scrīpt that calls that control, not all the test cases that test that control.
The Test Library Architecture Framework
The test library architecture framework is very similar to the test scrīpt modularity framework and offers the same advantages, but it divides the application-under-test into procedures and functions instead of scrīpts. This framework requires the creation of library files (SQABasic libraries, APIs, DLLs, and such) that represent modules, sections, and functions of the application-under-test. These library files are then called directly from the test case scrīpt.
To demonstrate the use of this framework, I'll automate the same test case as above but use an SQABasic library. The library contains a function to perform the operations. Following are the header file (.sbh) and the library source file (.sbl).
Using this library, the following test case scrīpt can be made.
From this example, you can see that this framework also yields a high degree of modularization and adds to the overall maintainability of the test suite. Just as in test scrīpt modularity, if a control gets moved on the Calculator, all you need to change is the library file, and all test cases that call that control are updated.
The Keyword-Driven or Table-Driven Testing Framework
Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test scrīpt code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.
If we were to map out the actions we perform with the mouse when we test our Windows Calculator functions by hand, we could create the following table. The "Window" column contains the name of the application window where we're performing the mouse action (in this case, they all happen to be in the Calculator window). The "Control" column names the type of control the mouse is clicking. The "Action" column lists the action taken with the mouse (or by the tester). And the "Arguments" column names a specific control (1, 2, 3, 5, +, -, and so on).
Window Control Action Arguments Calculator Menu 
View, Standard Calculator Pushbutton Click 1 Calculator Pushbutton Click + Calculator Pushbutton Click 3 Calculator Pushbutton Click = Calculator Verify Result 4 Calculator Clear Calculator Pushbutton Click 6 Calculator Pushbutton Click - Calculator Pushbutton Click 3 Calculator Pushbutton Click = Calculator Verify Result 3 This table represents one complete test; more can be made as needed in order to represent a series of tests. Once you've created your data table(s), you simply write a program or a set of scrīpts that reads in each step, executes the step based on the keyword contained the Action field, performs error checking, and logs any relevant information. This program or set of scrīpts would look similar to the pseudocode below:
Main scrīpt / Program Connect to data tables. Read in row and parse out values. Pass values to appropriate functions. Close connection to data tables. Menu Module Set focus to window. Select the menu pad option. Return. Pushbutton Module Set focus to window. Push the button based on argument. Return. Verify Result Module Set focus to window. Get contents from label. Compare contents with argument value. Log results. Return.
From this example you can see that this framework requires very little code to generate many test cases. The data tables are used to generate the individual test cases while the same code is reused. The IBM Rational toolset can be extended using interactive file reads, queries, or datapools, or you can use other tools (freeware, other development tools, and such) along with IBM Rational tools in order to build this type of framework.
The Data-Driven Testing Framework
Data-driven testing is a framework where test input and output values are read from data files (datapools, ODBC sources, cvs files, Excel files, DAO objects, ADO objects, and such) and are loaded into variables in captured or manually coded scrīpts. In this framework, variables are used for both input values and output verification values. Navigation through the program, reading of the data files, and logging of test status and information are all coded in the test scrīpt.
This is similar to table-driven testing in that the test case is contained in the data file and not in the scrīpt; the scrīpt is just a "driver," or delivery mechanism, for the data. Unlike in table-driven testing, though, the navigation data isn't contained in the table structure. In data-driven testing, only test data is contained in the data files.
The IBM Rational toolset has native data-driven functionality when using the SQABasic language and the IBM Rational datapool structures. To demonstrate the use of this framework, we'll test the order form from the test sample application Classics A (see Figure 2).
Figure 2: Order form from the sample application Classics A If we record data entry into this window, we get the following:
We can use datapools to set up test cases that test valid and invalid credit card numbers and expiration dates. The datapool shown in Figure 3, for example, would be for a test case that would test the date field.
Figure 3: Sample datapool for a test case that would test the date field If we modify the scrīpt to accept this data, we get the following:
I had to add SQABasic commands to manipulate the datapools. I also added a
Whileloop to allow for the processing of each row in the datapool. I should also mention the use of the SQABasic commandUCasewithin theIf Thenstatement.UCaseis used to make the argument (in this case, the datapool return value) all uppercase. This way the comparisons aren't case sensitive, making the code more robust.This framework tends to reduce the overall number of scrīpts you need in order to implement all of your test cases, and it offers the greatest flexibility when it comes to developing workarounds for bugs and performing maintenance. Much like table-driven testing, data-driven testing requires very little code to generate many test cases. This framework is very easy to implement using the IBM Rational toolset, and there's a lot of detailed documentation available with how-tos and examples.
The Hybrid Test Automation Framework
The most commonly implemented framework is a combination of all of the above techniques, pulling from their strengths and trying to mitigate their weaknesses. This hybrid test automation framework is what most frameworks evolve into over time and multiple projects. Figure 4 gives you an idea of how you could combine the approaches of the different frameworks within the IBM Rational toolset.
Figure 4: A hybrid test automation framework -
爱或不爱,从胃开始
2007-4-26
-
大妈做饭腰给做折了~~~
2007-4-24
天啊
~~~没天理了,周五兴高采烈的去大妈家准备周末去松江玩,结果,乐极生悲,大姐的腰给做饭做的痛了,我好心帮她揉了几下,大姐叽哩哇啦的给鬼叫了一通,然后.....第二天,惨局发生了....
我和大妈估计我们和东方医院比较有缘,半年不到进了两次,上次是我的腿摔瘸了,这次是大妈的腰....重度腰肌老损了
... 这两天我在深刻的反省当中,我不该去大妈家吃饭,不改让她做饭的热情高涨的时候不进行劝阻,我错了,下次一定不在让大妈做饭了....发现和大妈见面没啥好事,咱俩属于互克的那种,从我们认识开始,逛街遇小偷,回家遭窃贼,然后不是肺炎就是腿瘸的....下次不去大妈家了,大妈也不来咱家,想的时候么就约个地方碰面身上不带钱就带个车卡就OK,然后就各自回家,这样比较保险点
-
小由走路竟然是外八字~~
2007-4-03
近日发现偶家那只破猫走路竟然是外八子~~好丑~~~
疯了
-
搬家啦~~
2007-3-29
-
自动化工具使用之个人心得(二)
2006-12-27
-
面试感悟（二）
2006-12-27
