Some tips for automation test engineers

What automated tests?

   I have been doing testing for several years, and I have really learned and practiced automated testing for a year. I feel that I have gained a lot in this year. I have always wanted to write an article to share some experience in automated testing practice. Finally decided to take some time to do this.

  First, clarify the concept of automated testing. In a broad sense, automation includes all behaviors that replace or assist manual testing through tools (programs), which can be regarded as automation, including performance testing tools (loadrunner, jmeter), or written by yourself. A program for generating 1 to 100 test data. In a narrow sense, the process of manual testing is simulated by means of tool recording or scripting, and test cases are executed by playing back or running scripts, thereby replacing manual verification of system functions.

  Of course, our more general understanding regards "automated testing" as "automated testing based on the UI layer of a product or project".

 Layered automated testing

   This concept has been exposed recently. Traditional automated testing pays more attention to the automated testing of the product UI layer, while layered automated testing advocates that automated testing is required at different stages (levels) of the product.

   I believe that the test students are no strangers to the above pyramid, isn't this the test corresponding to different stages of product development! We need standardized unit testing and corresponding unit testing frameworks, such as java's Junit, testNG, C#'s NUnit, python's unittest, pytest, etc. Almost all mainstream languages ​​will have their corresponding unit testing frameworks.

  Integration and interface testing are not easy to understand for many new testers. Unit testing focuses on the implementation logic of the code, such as the implementation of an if branch or a for loop; then integration and interface testing focus on a function, class (method) Whether the interface provided is reliable. For example, if I define an add() function to calculate the result of two parameters and return it, then I need to call add() and pass the parameters, and compare whether the return value is added to the two parameters. Of course, the interface test can also be delivered in the form of url. For example, if we send a request to the server through get, the content we send will be passed to the server as part of the URL. But for example, a public interface provided by Web service technology needs to be tested by tools such as soapUI. 

  You should be familiar with the automated testing of the UI layer. Most of the work of most testers is to test the functions of the UI layer. For example, we repeatedly test functions such as form submission and result query, and we can simulate these operations through corresponding automated testing tools, thereby liberating repetitive labor. There are many automated testing tools for the UI layer, the more mainstream ones are QTP, Robot Framework, watir, selenium, etc.

  Why draw a pyramid instead of a rectangle or an inverted triangle? This is to indicate the proportion of automated testing invested in different stages. If a product has never done unit testing and interface testing, it is unscientific to only do automated testing of the UI layer, making it difficult to essentially guarantee the quality of the product. If you try to achieve a comprehensive automated test of the UI layer, it is a waste of time and money, and a lot of manpower is invested, and the final benefit may be far lower than the cost paid. Because the higher the level, the higher the maintenance cost. Especially the elements of the UI layer will change from time to time. Therefore, we should put more automated tests in the unit test and interface test phase.

  Since the automated testing of the UI layer is so laborious and costly, let's only do unit testing and interface testing. NO! Because no matter what kind of product, what is finally presented to the user is the UI layer. Therefore, testers should focus more on the UI layer. Then it is precisely because testers invest a lot of energy in the UI layer, so it is necessary for us to help us "partially liberate" repetitive labor through automation.

  The most feared thing in automated testing is change, because the direct result of the change is that the test case fails to run, so the automation script needs to be maintained; how to control failure and reduce maintenance costs is crucial to the success of automation. Conversely, an automated test case that always runs successfully is of no value. 

  As for the ratio of the three tests in the pyramid, it should be divided according to the actual project requirements. In the book "The Way of Google Testing", for Google products, 70% of the investment is unit testing, 20% is integration and interface testing, and 10% is automated testing of the UI layer.

  Why should I do automated testing?

   According to 51testing's "China Software Testing Practitioners Survey Report", manual testing accounts for 89%. Compared with development, the threshold for testing is low, and the salary is generally low. Although the required knowledge has a certain breadth, it lacks depth. This is the general state of testing.

  It is precisely because the threshold for manual skill testing is not high that a large number of graduates, even non-professionals, have poured into this industry. Thereby increasing the fierce competition in this industry. For those who have been in manual testing for several years, they will have a strong sense of crisis. Due to the low technical content of the job, the salary increase has encountered a bottleneck, and on the other hand, it is threatened by new entrants. The same job can be done by someone hired by the company for 5K, so it will not spend 8K.

  Well, this question should not appear in the discussion of technical topics, but it is indeed a problem that most testers have to face. Therefore, from the perspective of the development of testers themselves, I actually need automation technology to increase my competitiveness. Of course, testers who have reached a certain number of years will choose to transfer to management or other positions, which is another topic.

  From the perspective of the development of the testing industry, due to product characteristics, there are not many world-class products in domestic products, relatively low technical content, relatively low quality requirements, foreign projects are outsourced, and testing labor costs are low, so a large number of manual testers are needed. .

  Therefore, in the near future, I think that the demand for pure manual testers will decrease, and companies will need testing with higher technical capabilities. Quality needs to be tested, and testing behavior will never disappear, but it is possible that pure manual testers will disappear.

  Well, you can say that testing is a sunny industry, and I am purely alarmist. No matter what the future holds, we all need to improve our skills, right?

  What projects are suitable for automated testing?

   If you have decided to learn automated testing, how to learn is the next question to face? This problem is analyzed based on the tested product. If the technology you have learned cannot be applied (verified), it will make your learning process difficult.

  First consider whether the product is suitable for automated testing. The general consensus of this method is to make trade-offs from three aspects.

   Software requirements change infrequently

  The stability of test scripts determines the maintenance cost of automated tests. If software requirements change too frequently, testers need to update test cases and related test scripts according to changing requirements, and script maintenance itself is a process of code development, which needs to be modified, debugged, and automated testing when necessary Framework, if the cost is not lower than the test cost saved by using it, then the automated test has failed.

  Some modules in the project are relatively stable, while the requirements of some modules are highly variable. We can then automate the testing of relatively stable modules, while manual testing is still required for relatively large changes.

   Long project cycle

It takes a long time to complete the determination of automated testing requirements, the design of automated testing framework, and the writing and debugging of test scripts. Such a process itself is a test software development process, which takes a long time to complete. If the project cycle is relatively short and there is not enough time to support such a process, then automated testing becomes a joke.

   Automated test scripts can be reused

  The reuse of automated test scripts should be considered from three aspects. On the one hand, whether there is a large difference between the tested items (such as the difference between the C/S system and the B/S system); This difference; finally, whether testers have the ability to develop an automated testing framework that adapts to this difference.

 Which tool to choose for automated testing

   If you have confirmed that the XX project is suitable for automated testing, then the next thing you need to do is to choose a testing tool.

  First of all, you must first confirm whether the product you are testing is a desktop program (C/S) or a web application (B/S).

  Tools for desktop programs include: QTP, AutoRunner

  Tools for web applications include: QTP, AutoRunner, Robot Framework, watir, selenium

  Due to the many advantages of the B/S architecture, a large number of applications of the C/S architecture were converted to the B/S architecture a few years ago. This also promotes the development of web development and testing technology. If there is a product under test with a C/S architecture, then QTP is recommended. QTP accounts for half of the trial rate in the field of UI automation testing. Therefore, it is enough to show that QTP is powerful in the field of automation, easy to use, etc. Learning mainstream tools can also give you more opportunities. There are also a lot of books on QTP on the market. Of course, in order to learn QTP well, you must master the VBS scripting language.

  If the product under test is a B/S structure, then selenium is recommended, why not QTP or other tools? Because selenium supports B/S applications very well, and more importantly, it supports multi-language development. To really try selenium, what you need to master is not just a tool, you also need to learn a language. Why should I choose selenium? I also need to learn a language, which undoubtedly increases my learning costs. While increasing the cost, it also increases your competitiveness. Moreover, in the process, you not only learn an automation tool, but you can use the language you have learned to do more things.

  All right! If you decide to try selenium, you face a new problem, choose a language. Selenium supports java, python, ruby, php, C#, JavaScript.

  In terms of language ease of learning, ruby ​​and python are preferred

  In terms of language application breadth, java, C#, php,

  In terms of language-related testing technology (and data): ruby, python, java

  Or you can consider what language is used mainstream by the entire technical team, and then choose the corresponding language. 

Before you use selenium

   OK! After the above process, I believe that you must make a corresponding choice. If you choose the selenium tool, then read on.

It is preferred that you need to spend one to two months learning a language before starting selenium. This is based on students who have no language foundation. I recommend ruby, python, java any language to learn.

  Of course, if you have a good language foundation and skip this link, or your rich java programming ability, then learning python may only take a few days or less.

  If you have already settled the basics of a language, then you need to understand selenium first. Selenium is not just a tool, it is a collection of tools, and it is divided into 1.0 and 2.0, of course 3.0 is also has arrived.

  Selenium is not a simple tool, but consists of several tools, each of which has its own characteristics and application scenarios.

selenium IDE

  Selenium IDE is a plug-in embedded in the Firefox browser, which realizes the recording and playback functions of simple browser operations. So when is it used?

  Quickly create bug reproduction scripts. During the testing process, testers can record the reproduction steps through the IDE after discovering bugs to help developers reproduce bugs more easily.

  The scripts recorded by the IDE can be converted into multiple languages, which helps us develop scripts quickly, and we will introduce this function in detail later when it is used.

selenium Grid

  Selenium Grid is an automated testing aid. Grid can speed up functional testing of Web-apps by utilizing existing computer infrastructure. Using Grid, it is very convenient to run multiple test cases in parallel on multiple machines and in heterogeneous environments at the same time. Its characteristics are:

· Parallel execution

· Use one host to control the running of use cases in different environments and different browsers.

· Flexibly add and change testing machines

 selenium RC

  Selenium RC is the core tool of the selenium family. Selenium RC supports many different languages ​​to write automated test scripts. The selenium RC server acts as a proxy server to access the application to achieve the purpose of testing.

  Selenium RC uses Client Libraries and selenium Server. The Client Libraries library is mainly used to write test scripts to control the library of selenium Server.

  Selenium Server is responsible for controlling browser behavior. In general, Selenium Server mainly includes 3 parts: Launcher, Http Proxy, Core. Among them, Selenium Core is embedded into the browser page by Selenium Server. In fact, Selenium Core is a collection of JS functions, and it is through these JS functions that we can use programs to operate browsers. Launcher is used to start the browser, load selnium Core into the browser page, and set the browser's proxy to Selenium Server's Http Proxy.

 selenium 2.0

  After clarifying the family relationship of selenium 1.0, selenium 2.0 added WebDriver to this family; simply expressed as:

  selenium 2.0 = selenium 1.0 + WebDriver 

  It should be emphasized that in selenium 2.0, WebDriver is the main promotion. WebDriver is a substitute for selenium RC. Because selenium is for backward compatibility, selenium RC has not been completely abandoned. If you use selenium to develop a new automated test project, it is strongly recommended The column recommends using WebDriver. So what is the main difference between selenium RC and webdriver?

  selenium RC runs JavaScript applications in the browser, and uses the browser's built-in JavaScript translator to translate and execute selenese commands (selenese is a collection of selenium commands).

  WebDriver directly controls browsers through native browser support or browser extensions. Developed for each browser, WebDriver replaces the JavaScript embedded in the web application under test. Tight integration with browsers enables the creation of more advanced tests that avoid the limitations imposed by the JavaScript security model. In addition to support from browser vendors, WebDriver also simulates user input using operating system-level calls.

  If it is a new project, it is OK to learn webdriver directly, and RC is an outdated technology.

  selenium learning route

   Configure your test environment, and configure your corresponding selenium test environment for the language you are learning. Selenium is like the semantics of the definition --- "Say hello". If you are using Chinese, for the sake of expressiveness, your writing method is "Ni Hao", if you are using English, your writing method is "hello". Therefore, the same semantics will be written differently (grammar) in different languages.

   Then you need to be familiar with the webdriver API, which is a method defined by selenium for locating and manipulating various elements on the page.

  First learn the positioning of elements, selenium provides id, name, class name, tag name, link text, partial link text, xpath, css, and other positioning methods. The powerful syntax of xpath and css is slightly complicated, and you may need to know more front-end knowledge in the meantime. xml, javascript, etc.

  The purpose of locating elements is to operate elements, and then we need to learn the operations of various elements, such as input boxes, drop-down boxes, button clicks, file uploads, downloads, pagination, dialog boxes, warning boxes...etc.

  After a period of study, you can easily simulate manual testing to operate various elements on the page. Then what you need to do is to organize these "use cases" and run them together.

  Then what you need to do is to learn and use the unit test framework, which itself solves the organization and operation of use cases.

  When you write some "test cases", you will find that there are a lot of repeated operations in the test cases. Can you write them into a separate file and call these operations when needed? Of course you can, and it will be very easy to use your programming skills to achieve this. Then, you find that there are some data in each use case, and the data is the same, but if it changes, it is very troublesome to modify, you can also write it to a separate file for reading.

  Then you have a new question. The scripts (use cases) I wrote are all pipelined. How do I know whether the use case failed or succeeded. Then you need to add some verification and assertion in the script.

  Then you have more ideas, the log of the unit test framework is too simple, can you generate a beautiful test report. Can I run this script regularly. Can you send the test results of each script run directly to my email. Can you...

  To solve these problems, you have to learn more programming techniques, and then your "test structure" will become more and more powerful and flexible. Produced a certain versatility and portability. A decent automated testing framework was born.

   If, one day, you no longer do UI automation testing, you will find that it is basically not difficult for you to do unit testing or interface testing. It is not a problem to develop a test tool and the like, thanks to selenium! By the way, thank me too!

Finally: The complete software testing video learning tutorial below has been sorted out and uploaded. If you need it, you can get it for free [guaranteed 100% free]

 These materials should be relatively complete for friends who do [software testing]. This kind of learning materials also accompanied me through the most difficult journey, and I hope it can help you too! Everything should be done as early as possible, especially in the technology industry, we must improve our technical skills.
The above software test data collection partners can click the small card below

Guess you like

Origin blog.csdn.net/m0_68405758/article/details/129915423