Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Test automation
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Other approaches== ===Model-based testing=== {{Main|Model-based testing}} One way to generate test cases automatically is [[model-based testing]] through use of a model of the system for test case generation, but research continues into a variety of alternative methodologies for doing so.{{Citation needed|date=August 2009}} In some cases, the model-based approach enables non-technical users to create automated business test cases in plain English so that no programming of any kind is needed in order to configure them for multiple operating systems, browsers, and smart devices.<ref>{{cite book|title=Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications.|isbn=978-0-7381-5746-7|doi=10.1109/IEEESTD.2008.4578383}}</ref> ===Regression testing=== Some [[software testing]] tasks (such as extensive low-level interface [[regression testing]]) can be laborious and time-consuming to do manually. In addition, a manual approach might not always be effective in finding certain classes of defects. Test automation offers a possibility to perform these types of testing effectively. Once automated tests have been developed, they can be run quickly and repeatedly many times. This can be a cost-effective method for regression testing of software products that have a long maintenance life. Even minor patches over the lifetime of the application can cause existing features to break which were working at an earlier point in time. ===API testing=== {{Main|API testing}} [[API testing]] is also being widely used by software testers as it enables them to verify requirements independent of their GUI implementation, commonly to test them earlier in development, and to make sure the test itself adheres to clean code principles, especially the [[single responsibility principle]]. It involves directly testing [[API]]s as part of [[integration testing]], to determine if they meet expectations for functionality, reliability, performance, and security.<ref name="reichart1">[http://searchsoftwarequality.techtarget.com/tip/Testing-APIs-protects-applications-and-reputations Testing APIs protects applications and reputations], by Amy Reichert, SearchSoftwareQuality March 2015</ref> Since APIs lack a [[Graphical user interface|GUI]], API testing is performed at the [[Communications protocol#Layering|message layer]].<ref name="stickyminds">[http://www.stickyminds.com/interview/all-about-api-testing-interview-jonathan-cooper All About API Testing: An Interview with Jonathan Cooper], by Cameron Philipp-Edmonds, Stickyminds August 19, 2014</ref> API testing is considered critical when an API serves as the primary interface to [[application logic]].<ref>[https://www.gartner.com/en/documents/2645817 Produce Better Software by Using a Layered Testing Strategy]{{cbignore|bot=medic}}, by Sean Kenefick, [[Gartner]] January 7, 2014</ref> ===Graphical user interface (GUI) testing === {{main article|Graphical user interface testing}} Many test automation tools provide record and playback features that allow users to interactively record user actions and replay them back any number of times, comparing actual results to those expected. The advantage of this approach is that it requires little or no [[software development]]. This approach can be applied to any application that has a [[graphical user interface]]. However, reliance on these features poses major reliability and maintainability problems. Relabelling a button or moving it to another part of the window may require the test to be re-recorded. Record and playback also often adds irrelevant activities or incorrectly records some activities.{{Citation needed|date=March 2013}} A variation on this type of tool is for testing of web sites. Here, the "interface" is the web page. However, such a framework utilizes entirely different techniques because it is rendering [[HTML]] and listening to [[DOM Events]] instead of operating system events. [[Headless browser]]s or solutions based on [[Selenium (Software)#Selenium WebDriver|Selenium Web Driver]] are normally used for this purpose.<ref>Headless Testing with Browsers; https://docs.travis-ci.com/user/gui-and-headless-browsers/</ref><ref name="Headless Testing with Browsers">Headless Testing with PhantomJS;http://phantomjs.org/headless-testing.html</ref><ref>Automated User Interface Testing; https://www.devbridge.com/articles/automated-user-interface-testing/</ref> Another variation of this type of test automation tool is for testing mobile applications. This is very useful given the number of different sizes, resolutions, and operating systems used on mobile phones. For this variation, a framework is used in order to instantiate actions on the mobile device and to gather results of the actions. Another variation is script-less test automation that does not use record and playback, but instead builds a model{{clarify|date=June 2016}} of the application and then enables the tester to create test cases by simply inserting test parameters and conditions, which requires no scripting skills.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)