Anti-blind UI Automation test _ Automation test

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

First of all, we suggest that you take a look at this article, write very good: Automated test: is really silver bullets. Here's the conclusion: Automated testing is not a silver bullet, automated testing (including UI Automation testing) is designed to reduce duplication of effort, increase test coverage, not to replace manual testing, and not to reduce testers (and, of course, potentially lead to a reduction in some manual testers) ... Let's not start this discussion here, we'll talk about UI Automation testing.

Non-UI Automation test and UI Automation Test-UI Automation test in the previous article the features and advantages and disadvantages of UI Automation testing are already mentioned in the column. Here are a few things to discuss: whether the product is suitable for UI Automation testing, and whether there are alternative ways to do it before the article, Without the need for UI Automation testing, without the need for UI Automation testing, without UI Automation testing, this is also because in all kinds of automated testing, UI Automation testing is the most unstable, the test case is the most difficult to write stable, the way to maintain the highest cost. Therefore, we must first consider whether there are alternative options. Although UI Automation is a relatively expensive approach, it is often the only option for functional testing (and, of course, it can be designed to reduce this dependency, as we'll read in the article). This time we need to consider a few things before deciding on a UI Automation solution: Choose the UI Automation tool: Look at the level of support for the product. For example, the product is written in WPF, the company bought the tools can be identified, whether there are other business tools to support the price is not the company has a budget to buy and so on. Whether the development language of an automation tool requires learning costs and whether the Third-party libraries of automated tools are rich, it is recommended that you choose a common language automation tool, such as a scripting language using Python or C #. When defining UI nodes, does the automation tool provide a convenient way to generate a mapping of the UI. And this mapping is easier to maintain whether it is convenient to debug test programs, such as whether to support breakpoints and variable value view
Product inside the custom UI, or the proportions of the UI controls that are called from the drawing, are key node controls (and, of course, there is no problem if you are drawing the accessibility interface that the UI control supports). For example, the main function of the product is drawing, the general plot area is definitely a custom control, and UI Automation tools are basically the plot area is powerless, there are other ways to test. For example, the drawing-related modules are taken out individually, and the API is used to manipulate the test. Against recording playback scripts
See some of the team's support for recording playback scripts as a prerequisite for evaluating automated test tools, and some are using recording playback to create test cases. Small projects, where only a few hundred of test cases are problematic, but when the number of test cases is hundreds of thousands of times, the maintenance test case is basically a heavy task. For example, a slight change in the UI node may cause the automation tool to not recognize the UI controls, so all test cases that use the control need to be updated, find replacements, and make sure that no substitution errors are a huge workload, not to mention the generally recorded script manual is not easy to understand. UI Automation testing is not just a script, it needs to be designed
Software test script development is also the software development, the script must conform to the specification, must pass the design code test maintenance entire process. Test script design: According to the principle of object-oriented design, we need to carry out the necessary encapsulation to the place of frequent change. The most frequent change here is the UI itself, and the relative stability is the business logic. So we can encapsulate the UI, then encapsulate a layer of business logic, and all test cases operate through the business logic interface. For example, we want to test a login window, then the UI layer contains user name, password, login button UI definition, logic layer contains interface like login interface, test cases inside the login interface login and the necessary verification. Test script encoding: Since it is software engineering, scripts must also follow code specifications, such as Python scripts that need to follow Python code specifications. Test Script Testing: The script is used to test the program, then its own quality is also critical. It is difficult to make the code review for the team that has the condition, of course ... The other is to at least manually observe the script's operation to make sure it does the right thing. And they need to be tested on different systems and machines. The maintenance of test scripts: The UI is relatively easy to change, which leads to the fail of the test case, then we need to debug and confirm that it is a scripting problem, and if the design is good, in most cases it just needs to update the UI layer. In addition, we need to consider whether the UI changes too often, and now the automation is correct. The time to start UI Automation testing from the maintenance of the front test script, you can see that the size of the maintenance effort is directly related to how frequently the UI changes. The thing we need to do is to determine when the UI is stabilized and we can start UI Automation, or we should consider manually testing the overlay. Of course, we do not have to wait for the entire program's UI stability, such as a stand-alone functional UI stabilized, we can first automate that function, and then wait for other features of the UI stability. And once the UI Automation starts, the maintenance work behind it will start, so I suggest that during the development process, there is a milestone called UI freeze, after which you can begin to automate the UI test. Of course, non-UI automation, such as unit Test,integration test and API test, should start early in another case, a regression test for the functionality of the previous release, which is the most appropriate aspect of UI Automation. Generally speaking, this situation UI changes basically not, and the function is more stable, after the test is written, can reduce the pressure of manual test effectively, and can focus on the new function verification more. Need to consider the input/output ratio of UI Automation
Let's start with input: As with the input and output of software, a well-designed UI Automation framework, the biggest input should be to create a framework and implement test automation scripts, and minimize the amount of maintenance effort. A bad automation framework, may be less upfront, subsequent maintenance and changes in the cost may be several times and earlier, even to the end can only be discarded. When it comes to output, the more automated tests run, the wider the platform coverage, the more output, and the more work you can do to reduce the amount of manual testing. Once the automated tests are written, they should be kept running, such as setting weekly, daily, or even each submission automatically to all platforms and reporting the results, depending on the situation. This cooperation with Jenkins to achieve will be more convenient. "Sincere appreciation, the hand remaining