|
#REDIRECT[[Test_automation#Framework_approach_in_automation]]
{{Multiple issues
| cleanup = December 2007
| unreliable sources = December 2011
| refimprove = December 2011
| no footnotes = December 2011
}}
A '''test automation framework''' is a set of assumptions, concepts and tools that provide support for [[test automation|automated software testing]]. The main advantage of such a [[Software framework|framework]] is the low cost for [[Software maintenance|maintenance]]. If there is change to any [[test case]] then only the test case file needs to be updated and the [[Driver Script]] and [[Startup script]] will remain the same. Ideally, there is no need to update the scripts in case of changes to the application.
Choosing the right framework/scripting technique helps in maintaining lower costs. The costs associated with test scripting are due to development and maintenance efforts. The approach of scripting used during test automation has effect on costs.
Various framework/scripting techniques are generally used:
# Linear (procedural code, possibly generated by tools like those that use record and playback)
# Structured (uses control structures - typically ‘if-else’, ‘switch’, ‘for’, ‘while’ conditions/ statements)
# [[Data-driven testing|Data-driven]] (data is persisted outside of tests in a database, spreadsheet, or other mechanism)
# [[Keyword-driven testing|Keyword-driven]]
# Hybrid (two or more of the patterns above are used)
The Testing framework is responsible for:<ref>{{cite web
| url = http://www.youtube.com/watch?v=qf2i-xQ3LoY
| title = Selenium Meet-Up 4/20/2010 Elisabeth Hendrickson on Robot Framework 1of2
| accessdate = 2010-09-26
}}</ref>
# defining the format in which to express expectations
# creating a mechanism to hook into or drive the application under test
# executing the tests
# reporting results
==Test automation interface==
Test automation interface are platforms that provides a single [[workspace]] for incorporating multiple testing tools and frameworks for [[system testing|System/Integration testing]] of application under test. The goal of Test Automation Interface is to simplify the process of mapping tests to business criteria without coding coming in the way of the process. Test automation interface are expected to improve the efficiency and flexibility of maintaining test scripts.<ref name = "Interface">{{cite web
| url = http://www.qualitycow.com/Docs/ConquestInterface.pdf
| title = Conquest: Interface for Test Automation Design
| accessdate = 2011-12-11
}}</ref>
[[File:Test Automation Interface.png|thumb|Test Automation Interface Model]]
Test Automation Interface consists of the following core modules:
* Interface Engine
* Interface Environment
* Object Repository
==Interface engine==
Interface engines are built on top of Interface Environment. Interface engine consists of a [[parser]] and a test runner. The parser is present to parse the object files coming from the object repository in to the test specific scripting language. Test runner deals with executing the test scripts using a [[test harness]].<ref name = "Interface" />
==Interface environment==
Interface environment consists of Product/Project Library and Framework Library. Framework Library have modules related with the overall test suite while the Product/Project Library have modules specific to the application under test.<ref name = "Interface" />
==Object repository==
Object repositories are a collection of UI/Application object data recorded by the testing tool while exploring the application under test.<ref name = "Interface" />
==See also==
* {{Portal-inline|Software Testing}}
==References==
{{Reflist}}
* Hayes, Linda G., "Automated Testing Handbook", Software Testing Institute, 2nd Edition, March 2004
* Kaner, Cem, "[http://www.kaner.com/pdfs/testarch.pdf Architectures of Test Automation]", August 2000
[[Category:Automation]]
[[Category:Software testing]]
| 