My understanding of UI automation testing

Transferred from the 51testing Forum clevermanArticle.

The reference of a good colleague is also a good friend. "UI automation sounds mysterious. Learning is very simple, but it is very difficult to use it ". I agree with this sentence through my own experience. At first, I thought it was mysterious and I could use it.ProgramTo control the mouse, the keyboard to operate the software, never touched before. Later I learned a few popular test tools, and I felt nothing, that is, record and play. However, it is indeed difficult to use projects. I would like to talk about my feelings here. This is not an expert, but it should be helpful for new testers.

The most critical aspect of UI automation is to select a tool suitable for your project. Each test tool has its own advantages and disadvantages, and each tested project has its own characteristics. For example, in what language is a project written, C, C ++, Java, or C #? What is the project type, desktop or web application? It is hard to say that a tool can deal with all or most projects, or a single project can simply rely on one tool. It is also unlikely that you will develop a dedicated tool to suit your project of 100% or more, unless your company is Microsoft, Google will have this strength. Therefore, testers have two requirements. First, they must master as many tools as possible and understand their advantages and disadvantages. In this way, different components of a project can be used properly in different projects. The second is to have a certain degree of development skills. When the test tool is not competent, develop your own tools as a supplement. Of course, it is more likely that every company only has a license for a tool, and you have no right to choose. In this way, your development capabilities are even more important. (The development capability mentioned here is not the compilation of automated scripts. It mainly refers to the development capability of C, C ++, at least C # and Java ).

The following describes how to use the test tool. The first contact is record and replay, which is very simple. Some people think that automated testing is record and replay. I must say that they are very ignorant. People with this kind of thinking may be very difficult to develop things in the future, because they are too easy to understand the problem. I hope no one in the Forum will think so. (I am not very nice to speak here because I have been so angry with this life. I hope you will understand it ). In fact, we need to modify and optimize each statement of the record script.

The most important thing about UI automation is to get the object to be operated, such as a textbox or button. You must be able to access them before you can operate on them. This is actually the only purpose of the recording script, telling us how to get this object. There are two problems: first, the test tool cannot obtain this object. In addition, the script of the test tool obtains this object, but the object does not exist during replay. It can be said that the core chanllenge of UI automation is the ability to get objects. It is much easier to get other objects. What if these two problems occur? First, we need to analyze who is the problem? If the problem is about the object recognition capability of the test tool itself, you can only find other methods. For example, you can compile programs in advanced languages, or skip the operation to perform the same operation. This place can best examine the level of a person, some people are helpless, and some people can think of an effective way. In addition, chanllenge in this place is often more difficult than ordinary developers. If it is a problem with the program itself, you can report a bug and let the developer fix it. In fact, there are a lot of bugs in the accessibility of the program, and most companies or developers do not pay attention to it. It may be useless if you report it. However, if they do not fix it, they will block your automation. The importance of accessibility can also be seen in the level of automation testing of a company.

The above describes the core issue of UI automation: how to get the objects to be operated. If there is a problem, the solution is to fix the problem and wait for the test tool to be upgraded. After obtaining the object, chanllenge controls the test process and handles exceptions. The timeout between automatically generated scripts and operations is fixed to death, which is also the most important reason for us to modify scripts. Objects to be operated are usually not displayed after timeout or enable. At this time, the automatically generated script will fail during replay. Then we need to modifyCodeGenerally, the test tool provides such a function. Be sure not to just sleep, so no matter how fast the object appears, you must wait for this period of time. Usually, it is set to a time, and the object will be returned immediately after it appears or is available, without waiting for the remaining time. If it does not appear at the end, it will be wrong. Another important problem is the interference of other unexpected windows. For example, if a window suddenly appears to cover the object you want to operate on, what should I do? At this time, you need to re-activate the object you want to operate to the front of the desktop, so that the mouse can correctly click on the target. Another better way is to call the click function of this object without clicking the mouse. That is to say, when you click the mouse and then activate the click function, you can directly use the program to activate the click function. In this way, even if the target is covered by other windows, you can perform the expected operations correctly.

The above are some basic questions about UI automation that I have come up. In my experience, you may still encounter many unexpected problems in the automation process. The possible causes of these problems are strange. They may be software bugs, test tool bugs, or even Operating System bugs. The ability to solve these unexpected problems is very important. On the one hand, the accumulation of testing experience, on the other hand, must rely on your imagination and creativity. From the problems encountered in automated testing, it is much more difficult than general development work. Here, we can also say that high-level testers are better than developers. Of course, there are also many difficulties in development. In general, it will be more and more difficult than the difficulties encountered in testing. Therefore, there is no Level Difference between development and testing. The real level is the ability to solve problems.

generally, desktop software is easier than HTML web pages, and Windows programs are easier than Java. That is to say, the general test tools have better support for Windows javasop and support for Jave and HTML. This is because Microsoft has strict definitions and requirements for programatic accessiblity. Therefore, if you test a Windows program, it will save much effort to automate it, and testing Java programs will be much more troublesome. I chose test complete at that time because the company only had the license of silktest. Although it supports Java, it does not support it very well. Maybe the version is too low. I found that the new version of test complete has added support for Java, and the effect is not bad, so I chose it. Winrunner I tried. It seems that plug-ins are needed. I don't have any. I forgot what happened to the robot. It seems that it is not very easy to use, but it is still difficult to install it. It is not clear how they support Java. I am satisfied with the test complete function, price, flexibility, and can be used to do something. If you have no experience with this tool, we recommend using the JScript Language.