Test automation: Difference between revisions

Content deleted Content added
m Reverted edits by 223.181.13.240 (talk) (HG) (3.4.10)
 
(7 intermediate revisions by 4 users not shown)
Line 25:
 
===Continuous testing===
[[Continuous testing]] is the process of executing automated tests as part of the software delivery pipeline to assesassess the business risk of releasing the SUT.<ref name="essential">[https://www.techwell.com/techwell-insights/2015/08/part-pipeline-why-continuous-testing-essential Part of the Pipeline: Why Continuous Testing Is Essential], by Adam Auerbach, TechWell Insights August 2015</ref><ref name="stickym">[http://www.stickyminds.com/interview/relationship-between-risk-and-continuous-testing-interview-wayne-ariola The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola], by Cameron Philipp-Edmonds, Stickyminds December 2015</ref> The scope of testing extends from validating bottom-up requirements or user stories to assessing the system requirements associated with overarching business goals.<ref name="pnsqc">[http://uploads.pnsqc.org/2015/papers/t-007_Ariola_paper.pdf DevOps: Are You Pushing Bugs to Clients Faster], by Wayne Ariola and Cynthia Dunlop, PNSQC October 2015</ref>
 
===Model-based testing===
Line 32:
===Test-driven development===
[[Test-driven development]] (TDD) inherently includes the generation of automation test code. [[Unit test]] code is written while the SUT code is written. When the code is complete, the tests are complete as well.<ref name="Learning TDD">{{cite journal|doi=10.1109/ms.2007.80|title=Learning Test-Driven Development by Counting Lines|year=2007|last1=Vodde|first1=Bas|last2=Koskela|first2=Lasse|journal=IEEE Software|volume=24|issue=3|pages=74–79|s2cid=30671391}}</ref>
 
===Other===
Other test automation techniques include:
 
#* [[Data-driven testing]]
#* [[Modularity-driven testing]]
#* [[Keyword-driven testing]]
#* [[Hybrid testing]]
#* [[Behavior driven development]]
 
==Considerations==
Line 58 ⟶ 67:
 
==Framework==
A test automation [[Software framework |framework]] provides a programming environment that integrates test logic, test data, and other resources. The framework provides the basis of test automation and simplifies the automation effort. Using a [[Software framework |framework]] can lower the cost of test development and [[Software maintenance |maintenance]]. If there is change to any [[Test case (software)|test case]] then only the test case file needs to be updated and the driver script and startup script will remain the same.
 
A framework is responsible for defining the format in which to express expectations, providing a mechanism to hook into or drive the SUT, executing the tests, and reporting results.<ref>{{cite web
Line 78 ⟶ 87:
* Unit testing {{endash}} some frameworks are intended primarily for [[unit testing]] such as [[xUnit]], [[JUnit]] and [[NUnit]]
 
===Test automation interface===
TestA test automation interfacesinterface areis a platformsplatform that provideprovides a single [[workspace]] for incorporating multiple testing tools and frameworks for [[system testing |Systemsystem/Integrationintegration testing]]. of application underA test. Theautomation goalinterface of Test Automation Interface is tomay simplify the process of mapping tests to business criteria without coding. comingA in the way of the process. Testtest automation interface are expected tomay improve the efficiency and flexibility of maintaining test scriptstests.<ref name="Interface">{{cite web
| url = http://www.qualitycow.com/Docs/ConquestInterface.pdf
| title = Conquest: Interface for Test Automation Design
Line 90 ⟶ 99:
[[File:Test Automation Interface.png|thumb|Test Automation Interface Model]]
 
TestA Automationtest Interfaceautomation interface consists of the following core modulesaspects:
 
Interface engines are built on top of Interface Environment.; Interface engine: consistsConsists of a [[parser]] and a test runner. The parser is present to parse the object files coming from the object repository into the test specific scripting language. The test runner executes the test scripts using a [[test harness]].<ref name="Interface" />
* 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 into the test specific scripting language. The test runner executes the test scripts using a [[test harness]].<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" />
 
==Defining boundaries between automation framework and a testing tool==
Tools are specifically designed to target some particular test environment, such as Windows and web automation tools, etc. Tools serve as a driving agent for an automation process. However, an automation framework is not a tool to perform a specific task, but rather infrastructure that provides the solution where different tools can do their job in a unified manner. This provides a common platform for the automation engineer.
 
There are various types of frameworks. They are categorized on the basis of the automation component they leverage. These are:
 
#[[Data-driven testing]]
#[[Modularity-driven testing]]
#[[Keyword-driven testing]]
#[[Hybrid testing]]
#[[Model-based testing]]
# Code-driven testing
#[[Behavior driven development]]
 
===Data-driven testing===
{{Excerpt|Data-driven testing|only=paragraph}}
 
===Modularity-driven testing===
{{Excerpt|Modularity-driven testing|only=paragraph}}
 
===Keyword-driven testing===
{{Excerpt|Keyword-driven testing|only=paragraphs}}
 
===Hybrid testing===
{{Excerpt|Hybrid testing|only=paragraphs}}
 
===Model-based testing===
{{Excerpt|Model-based testing|paragraph=1}}
 
; Object repositoriesrepository: are a collectionCollection of UI/Application object data recorded by the testing tool while exploring the application under testSUT.<ref name="Interface" />
===Behavior driven development===
{{Excerpt|Behavior driven development|only=paragraph}}
 
== See also ==
Line 137 ⟶ 109:
* {{Annotated link |List of web testing tools}}
* {{Annotated link |Fuzzing}}
* {{Annotated link |Headless browser}}
* {{Annotated link |Software testing}}
* {{Annotated link |System testing}}
* {{Annotated link |Unit test}}
 
==References==