Analysis of UI automation test cases
Let's start our journey by analyzing one end of the automated test case code. The following is a small demo of an automated test I wrote before. This Demo is based on Selenium and Java .
Automated testing small demo
What it wants to test is actually to see if Baidu search can return the official website of Industrial Bank. Let's analyze what this code contains.
-
First, this code contains locators.
Those who are familiar with Selenium know that inpubBox and searchButton are the elements of the webpage, instantiated by By.id, and then the driver finds them through their ids, namely "kw" and "su" when findingElement. So "kw" and "su" are their locators.
locator
-
Second, this code contains test data.
"Industrial Bank", "Industrial Bank welcomes you" is the data to be input for testing.
Test Data
-
The third part is less intuitive than the first two parts.
This code finds the inputBox based on "kw", fills in the four words "Industrial Bank", then clicks the searchButton to submit the search application, and then searches for the text "Industrial Bank welcomes you" in the search results, and then selects whether Find this text as the standard for assert. These test steps reflect the real business logic, and the order cannot be changed arbitrarily. So the third part is business logic.
Business logic
-
The fourth part is the specific operation of each step in the business logic
For example, enter a certain text, or click a button, etc. Specific to our example is sendKeys and click.
Concrete operation
-
The fifth part is what remains of the test code after the first four parts are extracted
Basically, it is some code responsible for preparation or cleanup, such as initializing the driver and so on. I call it a code skeleton.
According to the above analysis, an automated test case consists of five parts: locator, test data, business logic, specific operation, and code skeleton.
UI automation test structure
02. Data-driven automated testing
If the test data is extracted, the execution of the automated test is driven by the change of the data, and finally the test result is changed, which is the data-driven automated test. To put it bluntly, it is test data parameterization .
data driven
Data-driven automated testing is suitable for scenarios where the test scenario and business logic are relatively simple, and the changes are not particularly large, but the test data has a great impact on the test results, or the scenario where the same test scenario needs to be tested through a large number of different test data. Its implementation method is relatively simple, but because the business logic is still embedded in the test code, the business logic and the test code are still strongly coupled . Once the business scenario changes, the test code needs to be modified to adapt to the business change.
If you want to isolate the impact of the business on the test code, you must use a keyword-driven approach .
03. Keyword-driven automated testing
To put it simply, keyword-driven automated testing is based on data-driven, extracting specific operations out of the code, and driving the execution of tests through changes in specific operations.
The keywords mentioned here are actually specific operations, such as sendKeys and click in the example. However, since specific operations (keywords) are based on business logic, in order to extract keywords, business logic must also be extracted together to achieve real keyword-driven. At the same time, the object of the specific operation is the element positioned by the locator, so the locator must also extract code exceptions together to completely isolate the impact of the business on the code.
keyword driven
Keyword-driven automated testing is suitable for scenarios with complex business scenarios and numerous test steps, or scenarios where you want to build a unified test platform. Its biggest advantage is that business people who do not understand programming can freely add new test cases or modify existing test cases by changing the configuration without reading the code. This is quite practical in agile development. It can involve business in the test and make the preparation of test cases as early as possible; in addition, the test code is completely isolated from the business logic to be tested, and the same test code can be reused in different The test scenario reduces the cost of repeated development. However, it's not completely without drawbacks.
-
First of all, not all scenarios need to be driven by keywords . If some scenarios can be solved by data-driven methods, data-driven should be decisively selected instead of over-design;
-
Second, because the business logic is isolated from the code, the readability of the code will be greatly reduced . The pure code basically has no business meaning. It is basically impossible to understand the business by reading the test code. Code readability is sacrificed for reusability.
-
Third, due to code reuse, the execution of each test case is equivalent to a brand new test, which means that without additional processing, test reports will be covered by each other, and only the execution result of the last test case will always be kept .
04. Example of keyword-driven automated testing
This is a demo of a keyword-driven automated test I wrote a long time ago. The basic idea is to extract locators, test data, business logic, and specific operations into a file called testCase.properties.
Parameter is used to store the properties read from testCase.properties, and the main test class TestBankIndex drives the execution of the test by reading this file. The specific operation corresponding to the keyword is placed in the PageAction.
In testCase.Properties, the test case name is defined by testCaseNameList, separated by | in the middle. Below the testCaseNameList are the specific test steps for each test case. Each test step name is prefixed with the test case name, and its order is the order of the test steps. Then the value of the test step is arranged by the operation (keyword), positioning method, positioning expression, test data, and timeout time required for the test, separated by | in the middle. One thing that is special here is the assertion. If it is an assertion, there will be Keyword, which is used to judge the assertion.
testCase.Properties
-
Parameter is used to store the properties of testCase.Properties
It's actually just a simple Java Bean.
Parameter
-
PageAction is used to define the specific operation corresponding to each keyword .
Let's take the search method as an example, by passing in the Parameter to get the elements required by the search to locate the search text to be entered, and then perform the real search operation and wait for a specific time.
PageAction
-
TestBankIndex is the main test class
But in fact there is a testEachCase method inside. It uses the Java reflection mechanism extensively to instantiate and execute methods. Therefore, when testEachCase is executed, it does not know which test case it will run and what operation it will perform until the last moment. These are completely defined in testCase.properties.
TestBankIndex
That's basically it. There is no time to optimize the code, many places are not very standardized, and there is no unit test; the problem of test report coverage has not been dealt with; testCase.properties is too heavyweight, and everything is stuffed into it. There is no UI yet, and there is no convenient operation. But as an MVP, it basically realizes the functions required by the UI automation testing framework.
The following is the supporting information. For friends who do [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse also accompanied me through the most difficult journey. I hope it can help you too!
You can get a 216-page software test engineer interview collection document for free from my official account below. And the corresponding video learning tutorials are free to share! , which includes basic knowledge, Linux essentials, Shell, Internet program principles, Mysql database, packet capture tool topics, interface testing tools, advanced testing-Python programming, Web automated testing, APP automated testing, interface automated testing, testing Advanced continuous integration, test framework development test framework, performance testing, security testing, etc.
