Now many companies are doing UI automation testing, and many of them are on the way to UI automation testing. Partners have always dreamed of being a technical expert, so let’s not talk about performance testing for the time being. Is UI automation testing useful, or what is the use? This section focuses on explaining the application scenarios and existence value of UI automation testing.
text
First of all, it is necessary to correctly understand UI automation testing. Tests can be divided into functional testing and non-functional testing according to types. Functional testing can be divided into script (Unit) testing, interface automation testing, UI automation testing, and manual testing according to implementation methods. Contains performance, security, ease of use, reliability, and more.
At present, more than half of the enterprises are doing and only doing manual testing. Manual testing still accounts for a large proportion in the entire testing industry. This has its inevitability, because most of the current domestic IT companies are still in disorder to order. At this stage of development, manual testing is still the mainstream testing method. There are also some teams or individuals in the industry who are exploring and researching other testing methods. In addition to the above, there are some precision testing, log backtesting, deep traversal testing, AI testing, etc.
The development law of the Internet is the same as that of everything, from birth to growth, from constant trial and error to maturity, then to stability and solidification, and then to improvement. In the current stage of trial and error or from disorder to order, many things have not yet formed a solid system.
Going back to the part of UI automation testing again, first of all, what is UI automation testing? It is a test method that automatically executes or runs predefined operation steps. Based on the UI (interface) level, it completely simulates manual testing. Test action.
Ideally, UI automation can simulate human manual operations almost perfectly, but in fact it also has some limitations, such as some operations that require peripherals and sensors, and the machine is difficult to simulate, requiring a lot of code to crack or Simulate similar behaviors, such as face, fingerprint, QR code scanning, image recognition, and fancy verification codes. This is not to say that it cannot be simulated, but that it needs to pay a relatively high price if it is simulated. It is not very convenient for the time being. Or simple solutions to these puzzles.
What is UI automation is finished, and then talk about the application scenarios of UI automation.
Scenarios where UI automation can be applied include functional testing of customer systems (generally used in the regression stage), covering PCweb, Android, IOS, etc.; it can also be used for automatic number creation, which is not as efficient as interface automation, but the accuracy of number creation It is worse than the interface, because in the case of a black box, it is impossible to understand the internal structure of the system, and that is to say, after understanding the system interaction design, the interface automation personnel can completely simulate the design, but cannot ensure that the actual development is implemented according to this logic; It can be applied to automated office to solve the manual labor duplication in the system under a fixed process; it can also be applied to intelligent customer service, remote control, hacking, likes and swiping tickets, grabbing red envelopes, etc. More application scenarios need everyone to brainstorm to develop.
Let's talk about the value of UI automation testing. All testing methods that are not aimed at intercepting defects are hooligans. Saying this sentence may offend some people, but it is the case. No matter what kind of testing method, intercepting defects should be the primary goal, and the same is true for automated testing.
Many people will say that three or five or more than a dozen defects are found in automated testing in a year. Is it necessary to continue? With so much investment and so little income, is the price/performance ratio too low? This really needs to look at the value. If you have this question, you need to look at the following things:
1. If the defects of automatic interception are not intercepted, how much loss will it cause? Taking "estimated loss minus" minus "investment" is the direction of automated testing. If it is positive, you need to maintain the current investment status of automated testing. If it is negative, you need to properly adjust the coverage of automated testing after analysis (if you have not intercepted high value defects, you need to analyze the coverage rate, whether to increase the coverage, and another possibility is that the coverage rate is too high, the investment is too large, far exceeding the value of the defect).
2. At what stage does automation intercept defects? The closer the time to launch, the greater the value of the intercepted defects.
3. Should defects intercepted by automated testing be discovered by manual personnel? If so, it means that manual testing needs to be strengthened.
4. How deep is the hidden defect of automated testing interception? If a hidden defect is found, the investment and coverage of automated testing should continue to be strengthened.
5. Analyze the standardization of the development process based on the defects intercepted by automated testing.
If none of the above values need to be considered, automated testing is not recommended. In addition, different automated testing technologies can be selected according to the type of the system. For example, the iteration is slow, the business is of high importance, and the business to customers is small. This type of system can be considered for unit testing or interface automation; the system that provides services has a large number of interfaces. If there are many front-end systems, interface automation can be done; the business iteration speed is fast, the user experience is emphasized, the version management is not stable enough, and the system with many new functions can consider UI automation testing (some people think that UI automation should not be done when the page changes frequently. , this is correct, but if it is implemented within the original framework, new functions are added, iterations are faster, and the customer system is actually very suitable for UI automation testing, the premise is that easy-to-use tools are also needed).
Finally, let’s talk about the positioning of UI automation testing. What has been said above is almost the same. The positioning of UI automation is actually a supplement to regression testing tools, automated number creation tools, and testing systems. Aside from automated number making, in some companies, UI automation testing is also a supplement to the testing system. In order to improve the team's testing methods, it will also play a reputation role in some ratings or external publicity. It is completely a test method that is not recommended for small companies, and it is a test method that can be done if you have money.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey, and I hope it can help you! Partners can click the small card below to receive