Non-UI Automation testing and UI Automation testing _ Automated Testing

Turn from: https://zhuanlan.zhihu.com/p/22174362

First of all, what is an automated test: Test automation in software testing, test automation are the use of special software (separate from The software being tested) to control the execution of tests and the comparison of actual outcomes with predicted .

This article also does not intend to summarize how many kinds of tests, how they classify, we only talk about automated testing ... The above paragraph also said what is automated testing, simply is a software operation software, and then can verify the results of the operation. The definition here is to separate from the software being tested, I don't quite agree with that. Some automated tests are in-process, require inject code to run test code, and even some directly similar to virus-attached binaries and run in the process of the program being tested (indeed, a software that has been seen to do this, Change the binary code directly and run a socket server in the process to perform the test.

Since it's a software, we simply follow a UI-not a UI-and-UI automated test program: Common non-UI Automation most of the unit Test API test integration test ... Common UI Automation with the UI of the unit test, such as mock off the underlying code, only test UI logic with the UI of the API test, such as I have worked in a team is UI component, most of the API is related to the UI functional testing. Most of the UI Automation tests are functional tests. or regression test (should be translated into regression test) ....

Let's take a look at the advantages of the two tests: non-UI simplicity. The test code is relatively easy to write, easy to debug and run stably. Unless the code logic changes, you generally do not need to change the test code. and not susceptible to external factors to affect good maintenance. Running stably, you don't need to constantly update your test code to run faster. The general execution speed is much faster than the UI test. It is easy to simulate error situations. The construction error situation is much more extensive than the UI operation. Simply put, is not picky eaters, as long as there is a UI program, as long as the support of the accessibility program can do. No need to be tested program source code. For example, an article in front of the calculator to maximize the simulation of user operations (some operations such as using Invokepattern, or with the user click the mouse is not the same, but we can simulate the mouse events to achieve the exact same effect). This is easy to understand, after all, the user is using the mouse keyboard operation, not write code to use ...

So how do we choose to use a non-UI or UI? Important Words three times:
No need to use UI Automation testing, you can not use UI Automation testing, you can not use the UI Automation test

It seems to be a bit dark, I just do UI Automation testing and tools ..., then why is it black? It is primarily a UI Automation test that has the following notable drawbacks:
Most people who write UI Automation tests are not rich in code experience, and even some of the UI's automated tests are done by recording playback scripts. Automation test code is also software code, should follow the software development from the design of all the process (not just UI Automation test code), here still agree with Microsoft's Sdet in the entire software development process, the more low-level code changes in the lower frequency. For example, the implementation of the underlying class and the user interface, it is obvious that the UI changes most frequently, and the latest stability in order to meet the requirements of the design, many of the program's UI to use a lot of custom control, but did not follow the Microsoft Accessibility standard (even do not know this thing). Causes no automated test tools to manipulate and obtain information for test validation ... The UI is not exactly the same in each version of Windows (from the perspective of the UI Automation Test tool)

However, everything has two sides, although there are a lot of significant shortcomings, but there are many advantages of the top column, how to choose, how to play the advantages of UI Automation testing, we have a few articles behind will do some introduction: Against Blind UI Automation test
The timing of the start of UI Automation testing Against recording playback scripts you need to consider the input/output ratio of UI Automation
UI Automation testing is not just a script, it also needs to design automated tests should start with software design to consider testability (testability) Programming needs to consider UI Framework program design need to consider the non-UI Automation Test team need to pay attention to automation bug Automation test scripts also have maintenance cycle synchronization and sleep selection
What is a good UI Automation test case
Try not to sleep Single verification point and functionality encapsulation in addition to pass and fail, there is also a need for Errorui automation testing that is not only UI state to validate custom controls support the Windows Automation API to talk about the problems of UI Automation in localization testing