UI automation testing has always been so entangled. Beginners of automated testing always use it as an introduction, but some experienced people have mixed reputations for it, or throw out the classic "pyramid" of layered automated testing to illustrate It is better to do less UI automation testing.
After 7 years of product research and development, the author was appointed to the field of testing when he was in danger, and it has been more than 7 years so far. During the period, the most attention has been on the automation technology of the UI/user side: from web applications to mobile apps, from testing to RPA (Robot Process Automation), from framework development to application promotion.
This article mainly shares why to do UI automation testing, UI automation testing framework design points, teamwork methods, promotion considerations and other experience, hoping to bring a collision of ideas to all colleagues.
1. Should I do UI automation testing?
If an organization really values software quality, UI automation testing is necessary. There are several reasons:
Any automation tool works best in simple, mechanical, and repetitive task scenarios, and UI testing fits this feature very well.
For many organizations, UI testing is currently the most expensive part of the testing team, and most of the full-time testers’ daily work is UI testing. "Workers must first sharpen their tools if they want to do well", and testers also need automated tools to improve their daily work efficiency.
No matter how complex and important the background is, the front-end interface is ultimately what users are exposed to. In addition to the back-end logic, the current software also has a lot of front-end scripting logic and styles. It is impossible to prove the usability of the user end by simply relying on back-end interface/unit testing.
Automated testing is indeed layered (unit testing, interface testing, UI testing). From the perspective of the testing team, we very much hope that there will be sufficient unit testing and interface testing to ensure the quality of the proposed test version, but the actual situation is often The unit tests and interface tests maintained by the development team are also very inadequate, or even almost non-existent.
So when someone in any project tells me not to do UI automation testing with "layered automated testing", I will first ask them to show me the interface testing and unit testing, and then discuss the implementation strategy of automated testing with them. .
But from a practical point of view, why are there so many doubts?
In the final analysis, it is the three words "unstable"!
The construction of the test environment is unstable, the interface of the tested software is unstable, and the test framework runs unstable.
In fact, as long as proper process improvement and development team cooperation, these problems can basically be solved or significantly improved.
Take the test environment as an example. In the purely manual testing phase, the test environment of some projects can be stopped at any time and updated at will. This also has an impact on manual testing (work progress is disturbed, test plans are disrupted), but it can be tolerated. Automated testing will put forward more standardized requirements for the testing environment, at least not at any time, which requires necessary improvements to the R&D testing process.
However, the interface of the tested software is unstable and the test framework is unstable. It is not as easy to solve as the unstable test environment. This mainly involves the cooperation with the development team and the design of the test framework.
2. Cooperate with the development team to improve the testability of the UI
In the theory of hierarchical automated testing, it is mentioned that unit testing and interface testing are relatively stable and easy to implement. In addition to the fact that the underlying code is relatively less affected by changes in user needs and the cost of writing automation use cases is relatively low, there is actually a reason that is rarely mentioned: unit testing and interface testing are usually internal work of the development team. When the unreasonable method or service interface design makes it difficult to write automated test cases, even if it does not directly correspond to a defect, they usually make adjustments to make the code design and implementation more optimized and standardized.
UI automation testing requires the cooperation of the development team. Of course, it does not mean that the development team is not allowed to modify the UI implementation at will. It mainly refers to the agreement and compliance with good UI coding standards, and timely correction of coding problems that do not correspond to functional defects but affect UI automation testing.
The most critical step in UI automation testing is to "locate page objects". Here is a specific example to illustrate how important the development team's internal and simple cooperation is for automated testing.
There are many ways to locate page objects. In addition to ID, XPath, CSS, etc., the author recommends locating objects based on contextual text.
Take the following interface as an example:
If the test script wants to use contextual text to locate the object method (as shown below):
In the test framework, the problem of how to accurately locate the input field/drop-down box in the back according to the text should be solved.
In fact, as long as the development team abides by the basic standards of HTML and regulates the use of Label tags and for attributes (as shown below), it will be easy to achieve the above effects in the test framework.
If the basic UI coding standards are not followed, and every developer writes front-end code at will, the cost and difficulty of UI automation testing will increase significantly.
3. Design an automated test framework that matches the development model
There are many design methods for automated testing frameworks. The core idea of automated testing framework design that the author has been insisting on over the years is to "match the development model."
Taking WebUI development as an example, there are currently two types of modes:
Using a unified UI class library, the enterprise or project team uses a unified front-end UI component library for development, such as JQuery.
Adopt a unified development framework, including UI development tools (and even use UI model-driven development). On the basis of adopting a unified UI class library, tools or models are used to ensure the standardization and consistency of UI code.
In these two modes, due to the large number of UI libraries, the front end will parse out a large number of dynamic, machine-generated page source codes, and it is no longer suitable to use traditional script recording and page object recognition methods to make test scripts.
Corresponding to these two development modes, the automated test framework design modes that I often use are: UI component packaging mode, development framework docking mode, etc.
1) UI component packaging mode
The PageObject mode is the most commonly used mode for automated testing. However, in systems developed based on UI libraries, there are too many page objects, and many tools to identify page objects have become more inaccurate and unintelligent.
The so-called UI component packaging mode refers to the corresponding automated test controls provided by the UI component types provided by the UI class library used in the development (for example, input, select, date, button, tree, grid, etc.).
The positioning method and interaction logic of each type of UI control are encapsulated into the corresponding automated test control. The tester can describe the test process through a simple DSL language (as shown below), and the specific analysis and execution are handed over to a test framework for unified processing .
Through this test framework design pattern, the difficulty of script writing and the amount of script code can be reduced, object recognition and execution stability can be improved, and the impact of UI class library changes can be limited to the test framework without spreading to the test script.
2) Development framework docking mode
When an enterprise adopts a unified development framework, especially when a large amount of UI code is generated through tools, we can first understand which codes are written by developers, which codes are generated by tools, and which information is managed uniformly in the development framework.
When designing an automated test framework, making full use of these resources can greatly improve the ease of use of the framework. As shown in the figure below, after docking the development framework, we can easily obtain the complete menu structure of the project (as a test case) with one click, and accurately identify the page object.
With a complete test case outline and page objects, the writing of test scripts will be easier. In addition, when the project version is upgraded in the future, you can detect and compare again to identify the changes of the page objects and the affected test scripts, and then remind the testers to modify the scripts in batches. Reduce the cost of repeated modification and repeated regression verification when the script is found to be executed during the regression test.
4. What kind of project is more suitable for automated testing
In some people's opinion, the reason for the low quality is that advanced testing techniques, such as automated testing, are not used.
But the real reason for the low quality is that the quality requirements of the project itself are not high. Otherwise, even if there is human flesh, sufficient regression testing must be implemented. If in this case, if a suitable testing framework and implementation strategy are adopted to implement automated testing, more obvious results will usually be achieved.
So about what types of projects are suitable for automated testing, what I want to answer is not about long project cycles, long-term maintenance, agile development models, the implementation of DevOps, the testing team has basic coding skills, balabala...
In recent years, there are many projects that the author recommends not to do UI automation testing, and some projects that I refuse to support also meet the above characteristics. Later, when evaluating whether a project is suitable for automated testing, I introduced some non-technical indicators:
Current test coverage, quality risk and test investment;
Target test coverage, quality risk, and test input required if automated means are not introduced;
Who set this goal or promised to achieve it?
If the project does not set a review coverage goal that cannot be achieved under the current human resources, or is only a goal set by the project team, it has not reported to the boss or promised this goal to the customer. I think it is not sincere to say to do automated testing in this situation.
For projects that really want to do automated testing, I will guide them to take out all existing test cases, analyze the feasibility of automated execution of each (each type) use case, implement technical solutions (UI, interface), and The cost that needs to be invested in the early stage.
After completing the automated test ROI analysis, if it is determined to introduce automated testing, then supplemented by an appropriate automated testing framework, the possibility of successful implementation is very high.
Those who are interested in software testing can also follow my official account: Programmer Erhei, focusing on software testing sharing, mainly sharing testing foundation, interface testing, performance testing, automated testing, TestOps architecture JmeterLoad, Runner, Fiddler, MySql, Linux , Resume optimization, interview skills, and actual video materials for large-scale test projects. If you are interested, please pay attention
Share the wonderful content with your friends