Shulou(Shulou.com)06/03 Report--

Introduction

Occasionally, someone in the group asks what automated testing is, but I don't understand. Qtp object library is so troublesome, how to test jmeter. A bunch of questions. In fact, to be honest, I really don't know how to answer it. My heart is tired.

It suddenly occurred to me that that's what I explained in my new book! It seems that there are still huge problems in many children's shoes' understanding of automated testing.

So, select "Xiaoqiang Software testing Crazy handout" for the following content

What exactly is automated testing?

After a new understanding of performance testing, let's take a look at what automated testing is. In fact, I have talked about this topic many times on different occasions, and even did a special program to explain it in my "getting kicked" talk show, but it is a pity that there are still many friends whose understanding of automated testing is incomplete. Then this section will lead you to a new understanding.

What exactly is automated testing? We can simply understand that the framework is completed by manual coding in the early stage, and the manpower is freed and the required testing is completed automatically in the later stage. A more popular understanding can be put it this way: now there are two robots, Xiaoqiang 1 and 2, and you encode one of them and tell him to "slap Xiaoqiang 2 every day at 12:00 noon". Then when it comes to 12:00, the Xiaoqiang No. 1 robot will follow your coding requirements and slap the Xiaoqiang No. 2 robot so that you can do other things. You don't have to do it yourself, liberate the manpower and improve the efficiency (inexplicably feel like you've been slapped in the face).

At this point, you should understand what automated testing is, right? Hey, hey, you really think you understand? I think there must be a lot of friends who will blurt out at this time, isn't automated testing just QTP, Selenium, Appium? If you really understand it that way, it's still incomplete. Most friends think that automated testing refers to UI layer automated testing, in fact, UI layer automated testing is just one of them, the specific level of which we will explain in later chapters.

Finally, I must also point out that any technology that can not serve the business is worthless, and so is automated testing. Automated testing is valuable only if it can really serve the business and bring high performance-to-price ratio. Automated testing simply stacked with code is not desirable.

Hierarchical model of automated testing

After we have a new understanding of automated testing, we will take a look at the automated testing hierarchical model, and we will also talk to you about how automated testing can be used for "appropriate benefits." This model has also been seen on the Internet. I don't know who wrote it first. Anyway, thanks to the creator of this model! I made some fine-tuning on this model to make it easier for rookies to understand it better. The hierarchical model is shown in figure 1.3.

Figure 1.3 hierarchical model for automated testing

With the experience of the performance testing hierarchical model, the automated testing hierarchical model is easy to understand. It is mainly divided into three layers, which we will explain in detail layer by layer.

UI layer

This is an automated test that most friends understand, and UI refers to a page that users can see with the naked eye. Basically, the rookie I came into contact with thought that the automated testing was on the UI layer. I think this misunderstanding is really terrible.

Let's first talk about the principles of automated testing in the UI layer. Whether it is the web side or the mobile side, the principle is the same: it is based on the identification and positioning of page elements to simulate user behavior. First identify an element, such as a button, and then define an action, such as a click, so that a click of the button is completed by code simulation instead of clicking manually. If we add data-driven and Page Object ideas in the later stage, we can basically form a UI layer automated testing framework. When you understand this, let's talk about the scope of automated testing in the UI layer.

For the scope of application of UI layer automation testing, I personally do not recommend large-scale applications. From my own practical experience, the final outcome of large-scale application of UI layer automation testing is always tragic. It is mainly due to the following reasons:

1) the UI changes frequently, and the plan can not catch up with the change at all (please like those who agree).

2) the initial effect is too slow to wait, we all hope that the use of automated testing technology can immediately see the effect, but the fact is always the opposite, the effect of automated testing is reflected in the later stage.

3) the development of the front end is not standard, which makes it difficult to identify and locate many elements.

So UI layer automated testing can not be applied? Definitely not! It is very important to maintain an objective and fair attitude. At least from my personal practical experience, UI layer automation testing can be applied to smoke testing. Here smoke testing refers to the testing of the main process, that is, those processes that are very important and will not change frequently, which can be completed by using UI layer automation testing. For example, before we will do daily UI layer automatic regression test on the main process of the e-commerce system, to ensure that the function of the online system is normal, and the effect is good. Therefore, the key to use or not lies in its scope of application, only in the appropriate range of the use of the right technology will show the best results.

Finally, to sum up in one sentence: "give you a dragon knife, if you can't use it, it's the same as a kitchen knife." only with a correct understanding of automated testing can we better promote its development. and only by understanding their characteristics can we make better use of them.

Interface layer

Interface layer is one of the most widely used automated testing methods in enterprises, and its advantage is that it basically avoids the shortcomings of UI layer automated testing, and once a relatively stable and complete framework is formed, it is basically more general, and can be used either on the web side or on the mobile side. But the disadvantage is also obvious, that is, the high coding ability of test engineers is required, which is also an important reason why many test engineers stop here.

For the interface layer automated testing is my personal recommendation, but also suggest that we have the ability to learn more, for the improvement of their own testing technology is obviously helpful. General interface layer automated testing will be developed in Python, Ruby and other languages. For example, the interface testing framework of a car rental company is developed with Ruby, and our previous interface testing framework is developed with Python. Here, we do not have to worry about what language to develop. Each language is universal in programming ideas, but slightly different in syntax. Basically, you will be very fast to learn other languages after you are familiar with one language. It is useless to say more, only friends who have done it can realize its good. The following chapters will also explain the design and implementation of some lightweight frameworks.

Unit layer

The automated testing of the unit layer requires high coding ability of the test engineer, and it is necessary to understand the implementation code of the business, so that the unit test code can be written for the tested code, which is generally completed by introducing XUnit, TestNG and other frameworks. Why can't most companies do well at this level? The reasons are discussed in the performance test hierarchical model in Section 1.2 and are not covered here.

In fact, the difficulty of automated testing lies in the design of the framework, not in writing code. The design of the framework needs to coordinate the overall situation, just like a commander. And finally to implement the framework you recruit a few people with code ability can be implemented. I can also feel deeply in Xiaoqiang's automated test class that many students do well when learning to write code, but they have no clue in the final design of the framework, or there is no idea of frame design, resulting in a blank mind all the time. If this is the case, then it is useless for you to learn well, because what you have learned is useless, only if you have the thinking ability of overall framework design. In order to use the language you have learned to achieve, the process is nothing more than problems encountered in the implementation process to check the information, at least you can take the most important step. It can be seen that sometimes thinking is so crucial!

How do beginners choose which technology to learn

This topic is a bit heavy, because if it is not well expressed, it will certainly be scolded by some unscrupulous people, but I decided to write this chapter after thinking it over. Because I have been asked this question by too many friends, about statistics, basically every two days will be asked, sometimes I will be asked N times a day, I will answer to vomit blood, for this reason, I also did a special program in the "get kicked talk Show", we can see the necessity of this topic, but also hope to help friends with choice entanglement.

Below I try to objectively talk about my own learning experience, perhaps this experience is not the best, or even wrong, but can give you some reference, less detours, I think it is valuable.

First of all, let's talk about several challenges that learning performance testing needs to face. You can combine your own actual situation to see if you are suitable to continue learning.

First, the huge knowledge system, this is the first challenge we face. Performance testing is a complex and patient task, and we need to "peel off the cocoon" in the complex system and analyze layer by layer to determine the performance problem. This process will involve middleware, Web server, cache, database, code and other knowledge, so it is difficult to continue without a more complete knowledge system. Although it is a challenge, in my opinion, it is the best way to get started for most rookie friends, because it can help us quickly establish a more perfect knowledge system, and it will do us no harm. I don't know if you have ever encountered such a scene, being pointed at the nose and saying: you can't even write a SQL statement, and you don't even know what the middleware is. Although such "humiliation" makes us unhappy, it also bluntly points out the lack of the overall knowledge system of many test engineers. Only by making up for their own shortcomings can we have the strength and strength to strive for better things.

Second, strong analytical skills, which is the second challenge we face. Just like the cartoon "Conan", solving a case at a complex crime scene requires constant inference and argumentation. in this process, it may overturn what has been determined before, or there may be no progress for several days, but this is also its charm. It can be said to be painful and happy.

After I have come into contact with many students, I find that a common problem is the poor ability of logical analysis. In the process of analysis, it is often a little bit from east to west, there is no logic at all, it is random guessing, and it is often easy to fall into details. Once you fall into it, it leads to stagnation, which is why many people find performance testing difficult. In my opinion, the analysis process of performance testing is like peeling onions, you need to peel layer by layer to see the problem, this process requires you to have strong logical analysis ability, but also macroscopical. Only stand at a certain height to look at the problem can suddenly be enlightened, otherwise you will fall into a dead end. Once this thinking ability is cultivated, it will get twice the result with half the effort, and the efficiency will be improved when learning other technologies, so you have to pay for everything in order to get a harvest.

Second, let's talk about several challenges that we need to face in learning automated testing.

First, the coding ability, this is beyond the limit. Speaking of which, some friends may ask, doesn't performance testing require coding ability? The answer is yes, but the threshold is relatively low compared to automated testing. In fact, coding ability is a necessary skill for a good test engineer.

How to improve their coding ability is also a question that many friends have consulted me, and there are really no shortcuts. I think we should practice more and sum up more. The practice I'm talking about is really doing it instead of watching it. In fact, most of the students I have brought have a problem, that is, when I speak in class, I feel very simple and disagree, but when I practice after class, I have all kinds of problems, and very simple knowledge points can be done for a day. So you must practice more, sum up every mistake you have made, and don't let yourself fall twice in the same place. I would like to say again: "there is no inconspicuous brick, no invisible frame, how can a beautiful building stand."

Second, the ability of logical thinking. Can you do automated testing after you have the coding ability? Obviously not, because automated testing ultimately hopes to build a framework or platform, which is a big project, must have strong logical thinking ability and design ability. For example, just because you can weld doesn't mean you can design cars. So the real difficulty of automated testing lies in the design idea, and it will be difficult for friends who have no experience to do it, which is why I personally suggest that we can learn performance testing first. the reason why you learn automated testing after you develop your ability and thinking.

Having said so much, I think members should already have the answer in mind. I would like to state once again that these are only my personal views. They are not necessarily right. They are for reference only. Do not spray them if you do not like them.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.