Selenium Automation Test Framework _ Automation test

Webdriver Working principle

When you start the script, Webdriver launches a new thread to launch the browser, which has two ways to start the browser: With user information and without user information. After the browser is started, Webdriver will bind the browser to a particular port (at which point the browser can be interpreted as a server, the script is a client), and the browser will do the appropriate processing and return the results to the client.
Common Automated Test architectures
An automated test architecture is an integrated system that defines an automated test rule for a particular software product. This system includes test function library, test data source, test object recognition standard, and various reusable modules. These components, as small building blocks, are grouped together to represent some kind of business process. Automated test architectures provide the foundation for automated testing, reducing the difficulty of automated testing.
Common automation architectures include the following:
1. Data Driven test
Data-driven testing places test scripts and test data in the same test architecture. The test architecture provides reusable test logic to reduce test maintenance effort and improve test coverage. Test input data and test result data are stored in one or more data sources, databases, data storage format and data organization depends on the implementation. The test data is separated from the test logic and does not affect the test logic when the test data changes. The same test logic can be tested for different data, which improves the efficiency and maintainability of the test logic.

2. Module Drive test
Module-driven testing uses separate little feet to match the modules, parts, and sub functions to be tested. These different levels of small scripts are combined into a larger level of testing with certain rules, thus implementing an automated test case for a particular feature. In all automated test architectures, he should be one of the easiest to grasp and control. There is such a programming strategy, his application is very extensive, that is, the internal implementation of the shielding components, only provide the external abstract interface of components. This low-level test component is transparent to the upper-level automation test case when it is changed. Module-driven testing introduces the principles of abstraction and encapsulation to improve maintainability and scalability of automated testing.

3. Key word Drive test
Keyword-driven testing, also known as "table-driven testing" or "Operation name testing," is a methodology for software automation testing. It divides the creation of automated tests into two different phases: the design phase and the implementation phase.
(1) A simple example of the design phase:
Object Action Data
Textfield (username) Enter text <username>
A more complicated example is the following
Object Action Data
Textfield (domain) Enter text <domain>
Textfield (usrname) Enter text <usrname>
Textfield (password) Enter text <password>
Button (Login) Click <left click>
(2) The implementation phase relies on the specific test tool used, and typically the automated test engine provides a keyword for the design phase definition, similar to "check" or "enter". Testers write test cases based on these keywords. The test case executes with a driver that reads the keywords and executes the appropriate code.
Advantages:
A, in a longer software maintenance cycle, significantly reduce maintenance workload, so that:
Simple test Case
High readability of test case columns
Test Case column Easy to modify
New test Case column can easily reuse existing keywords
B, keywords can be reused across multiple test cases.
C, not dependent on a language or a tool.
D, let staff focus on their own good place, such as
The building of test cases requires professional knowledge-without the need for too many programming test tools
The implementation of the keyword requires a wealth of testing tools, programming-without the need for much expertise in the field.
E, you can divide the level of abstraction for automated testing
Disadvantages:
It takes longer to create automated tests (compared to manual test and recording-playback technology)
It takes a long time to learn and master the cycle.
4. Hybrid Automation test
The hybrid automation test is developed by other automated test frameworks. Successful automated test frameworks typically incorporate "keyword-driven testing" and "data-driven testing". They have the advantage of separating the test logic from the test data and integrating the advanced architecture of the keyword-driven. This architecture makes data-driven scripts more concise and reduces the likelihood of unexpected failures at run time. On the other hand, the architecture can implement some of the most automated test tasks that are difficult to implement with "keyword driven testing". The architecture consists of a core data-driven engine, functional function components, and a support library.

5, based on the model test
Model-based testing is suitable for the use of "model-based design" software systems. Under this architecture, there is a mature test model to describe all aspects of test data, as well as test cases and case execution environments. Typically, this test model is fully or partially extracted from the functional model of the system to be tested. The test model describes the abstract behavior of the system to be tested, so a functional test case can be derived from the test model. These test cases form the set of abstract test cases, but the set of abstract test cases cannot be performed directly on the system to be tested. The set of test cases that can actually be executed (which can interact with the system to be tested) is derived from the abstract test case set. Some test tools based on model tests support generating an executable test case set from a model (containing enough information).
There are many ways to derive a case from a model, so testing is often based on experience and there is no fixed best method. You need to collect "test requirements, test objectives, user use cases" in advance because they contain information about the system model to be tested. The test case set is derived from the model rather than the code, so model-based testing can be considered a black box test. In fact, model-based testing is currently only suitable for functionally less responsible software systems, and the model-based testing of complex commercial software systems is still in the exploratory phase.