Automated Software Testing

Writing this log is actually a trigger. I just accidentally saw a shoes on the forum asking about non-computer automation, but it was not difficult to see the content. It seems that this shoes should be tested for a long time. I think it is low in black box manual technology, code is not involved, and the cloud will not develop in the future. In this case, I have heard a lot about it. It is not surprising that this is also a common phenomenon in most of our testing peers. Indeed, as I wrote in my previous blog titled "Thirty-six changes to software testing engineers", automated testing Engineers/architects are one of the development directions of our testers. If we want to develop towards the technical aspect, this is the ideal goal of most testers. However, the reality that is ignored by most people is that many people may not think about it: with my current understanding of testing, understanding of testing technology, it does not meet the learning automation test conditions. What is this condition? There are two words: thought. There are many people who envy automation, and many people, especially those who do not understand the technology, regard automation as a silver bullet in software testing, which makes automation testing really very popular, it seems that everyone is blindly pursuing automation. In fact, automated testing is not as mysterious as everyone thinks. To put it bluntly, it is to use tools and programs that can be understood by tools instead of people to complete the test, compare the execution results to determine whether the test is successful. Its advantages are obvious. It will not be annoying, it will not lose temper, it can perform complicated operations and execute thousands of times repeatedly. As long as your program has no problems, it will be executed for you without complaint, it is much faster than people, but the disadvantage is obvious. The biggest drawback is that tools don't think about it. Unlike people, they don't design new things, and they don't work around, it is designed by people. So what is important here is not to learn which tool, but to use which tool. What is important is your testing idea. Your thoughts on the tested system cannot be replaced by any tool. If you do not have a system understanding of the test and you do not have your own ideas about the tested system, you cannot apply the test knowledge you have to develop better testing strategies, even if you are familiar with tools and skills, you are still a tester who will write scripts. You will only run the case and click the button, mobile phone users are no different, because you do not have your own ideas. Do you think that people without ideas can grow?

So much has been said. What is the ideal process of learning automation? Let's take my own practical experience as an example. I have been engaged in software testing for so many years. I think I was eager to make progress and want to master the "advanced" Technology (automation here) the mood is the same as that of many children's shoes, so I can understand it very well. I was confused at the beginning and couldn't wait to search for the most popular automated testing tool on the Internet. Then I went to this programming book to learn, learn, practice, and practice, we hope that the success will soon be achieved. The results are often counterproductive, either because the project cannot be used, or because the company has changed. For example, the tools I have learned can only be the basis of the press box, thus, you have to re-learn another tool and language. In addition, due to lack of understanding and understanding of testing, even if I have learned how to use these tools, I cannot design good cases and exert the real power of tools. Slowly, I understand that what I need to learn is not how to use these tools. What I really need to learn is the idea of software testing, including the entire knowledge system of software testing, such as the testing process, different Test types, their purpose and purpose, different test design methods, and the relationship with the development model. How to report defects, how to manage defects, how to analyze test results, and some programming capabilities (this also paves the way for automation ). These are the basis for my software testing. They are the first step that is necessary to help you learn automation and automation in the future. It can also be said to be a precondition. Only when this precondition is reached, you can proceed to the next step, learning automation is a natural thing. Otherwise, you will find that your automated development path will block one day, because your preconditions are not met, it is the same as running case. If the ancient martial arts masters learn martial arts to give a metaphor, the understanding of the software testing knowledge system is equivalent to learning the basic test knowledge, those tools are only equivalent to the powerful sword and the powerful sword, and the internal force is not profound. Even if it is a peerless weapon, you can only have a pile of scrap iron in your hands and cannot play any role. In today's impetuous society, there are few people who are able to cultivate their internal skills, therefore, it is really sad that many children's shoes started to complain about how low technical content and how there is no future for development after a year of manual black box testing.

If you feel that you have a sufficient understanding of software testing and meet the first-step requirements (for this standard, refer to what we actually need to learn in the previous section, in this period, it usually takes about two years to complete the short term based on experience values. In the year 35 S, we can see how hard each person works.) The next step is like upgrading an elementary school to a junior high school, we can naturally learn about automated testing. At this time, when you learn automation, you will feel that this process is very natural. Why do you say this? Because after you have a good understanding of software testing, you will naturally think about how to improve testing efficiency. In your project, which processes can be replaced by automated tools, which test types can be automated, and where automation is not suitable. Then I thought about what tools should be used and how to use them. You will find that everything should be taken into consideration, because you have a good understanding of the test, and you have stood on a certain level to see the entire process at a glance. Let's make another analogy, as if you have grown up and matured, you should find a target person to fall in love. Your psychology and physiology both need to fall in love. Yes, that's the way you feel.

What should we do next? When you use automated tools to a certain extent and you have some experience in automated testing, you will deeply agree with one sentence: Gold is bare and nobody is perfect. Yes, of course, the tool is no exception. No matter what kind of tool you choose, it will have its shortcomings. At this time, you will further consider the following questions: What are the implementation principles of these tools? How does it work? What frameworks have they applied? If the ready-made tools cannot meet the testing requirements of the project, I can't use these testing frameworks and my own understanding of the tests to improve the tools, even write some tools by yourself to meet these unfulfilled requirements? At this time, these problems will naturally come into your mind. If you think about it, study it, and finally try to implement it, no matter whether it is successful or not, you will find that you are looking at the problem at a higher level. You don't need to give you any advice. You can actively think about the principle of the tool and try to improve it, isn't it happy? The so-called "Practice makes perfect" is the true "coincidence. If you can think about the problem at this level and look at the problem, I believe you will look back and see how immature you have been learning a specific tool without any project requirements, you can imagine what you said at that time. Now, after you have these experiences and skills, you may feel "good" after experiencing strong winds and waves, this may be when you really grasp the essence of automated testing. Finally, you may further abstract your own tools and share with everyone the new platforms and frameworks you have improved or even invented ", it affects others rather than others, and masters think so, isn't it?

As a matter of fact, there is only one sentence to sum up: learning automation is a natural process and you do not need to encourage others. You know, you always have to pay back the mixed-up. Not only programming is art, but testing is also an art that many people cannot understand. A layman can only watch the excitement, and only an expert can understand the portal. Well, I have talked so much about it. In this impetuous society, there may not be too many people who care about what I have written, there will never be too many people who change their views on testing and automation. Although I have poor skills, I only hope that people who do not understand and want to understand can get some inspiration, and I feel very satisfied.

Source: http://www.51testing.com/html/98/n-810298.html