GUI Functional Test automation model

For a particular program, the process of developing automated capabilities to test the solution is not significantly different from the process of creating the program. Automated testing is a very young area, and it is undergoing a lot of progress, promotion and standardization processes. In this field, many new tools have emerged that interact with the "Tested Systems" (Sut,system Under test).

There are a number of alternative methodologies and approaches to software development, such as object-oriented programming, functional programming, domain-driven design, test-driven design, behavior-driven design, and so on. They have clear declarative concepts and theories, and simplify the process of defining the initial system architecture, understanding the system, and exchanging knowledge among developers.

This article will mainly discuss the test automation for GUI (graphical user interface) application--from the perspective of automation developers, in this case the system under test (SUT) behaves as a black box (the system being tested is a system that is testing whether it can operate correctly.) For desktop applications, it is the application itself, and for the browser system--it represents the meaning of the website/web project. This is common in environments where the company's legacy systems are high in proportion, or when a newly developed system does not take into account detectable quality attributes.

The preparation and definition of best practices is a key part of developing automated testing. The following illustration shows the traditional interaction between the tested system and the tester:

The interaction between the tester and the SUT

At the center of the system is a human individual who plays the role of a tester. The testers replicate the scenarios depicted in the test cases using visual analysis of manual interactions and applications, and specific SUT interface access tools. If a failure occurs or a system unexpected behavior is encountered, the tester enters the information about the error behavior into the default tracking system.

The primary purpose of automated testing is to eliminate (or at least minimize) the interaction between humans and SUT. This is a very common issue in the ongoing delivery of the product development cycle. A study of sources of documentation suggests that the number of automated test systems is now very large. Commercial products will generally publish a series of detailed requirements and recommendations, especially for their products. However, these manufacturers often do not publish a series of tool diagnostic practices suitable for use with any automated tool.

In addition, these automated tool software providers often use marketing tools to describe the advantages of their systems based on a small amount of functional testing. But as the number of automated tests grows, maintaining existing tests becomes the most expensive part of the system's workflow.

The automated testing framework is designed to help solve these problems. They define basic system reusable components, publish best practices and unify automated methods--to properly develop automated test frameworks, we need to be guided by independent best practices.

Patterns of automated functional testing

Let's examine the following problems with the automation of the Web application (Figure 1), which is an example of an automated solution appliance. The application contains a login page, and each test must go through the page for further testing.

Figure 1: Example-a simple Web application with minimal page and feature sets