What is automated testing? How to do automated testing?

Functional testing and interface testing were introduced earlier, and API automation was mentioned when introducing interface testing. So what exactly is automation, why do we want to automate, here we focus on summarizing.

1. What is automation?

As the name implies, automated testing is relative to manual testing, and it refers to the practice of transforming manual testing of software into execution by machines.

It should be noted that unit testing is a white-box testing, and many companies are responsible for unit testing by developers, which is not discussed in this article. This article focuses on API testing and GUI testing.

The method of manual API testing is to use an interface testing tool (such as Postman), and then perform the following steps:

  1. Enter interface URL
  2. Select the request type, such as GET, POST, etc.
  3. Fill in the header and parameter information
  4. send request
  5. Validate the response, including the response code and response body.
  6. API automation is to automatically request the corresponding API and automatically verify whether the result meets expectations.

The method of manual GUI testing is to open the system to be tested, refer to the test cases written according to the requirements, and manually click one by one to verify whether the results meet expectations.

GUI automation is to simulate various manual operations on the software interface and automatically verify the results.

2. Why do you want to automate?

Automated testing sounds beautiful and can free testers from simple and repetitive labor. But the essence of automated testing is to use a piece of code (automated use case) to test another piece of code (business logic developed and implemented), so the automated use case itself belongs to the development work, and it must be updated with the update of the object under test, so there are certain requirements. maintenance costs.

Since there are development and maintenance costs, it is necessary to consider its cost performance. Take a look at the advantages of automated testing:

  1. Automated testing can replace a large number of manual repetitive operations, and test engineers can spend more time on more comprehensive use case design and testing of new functions.
  2. Automated testing can answer and improve the efficiency of regression testing
  3. Automated testing can make better use of unattended time to perform frequent tests, which is suitable for key businesses that require 7*24 hours of continuous system stability testing

Automated testing can ensure the consistency and repeatability of the operation and verification performed by each test, avoiding human omissions and negligence Let's take a look at the
disadvantages of automated testing:

Automated testing cannot replace manual testing.
Automated testing itself does not have any "intelligence". It just executes pre-defined test steps step by step and verifies the results, and cannot cope with changes in the system under test.
Automated testing has certain development and maintenance costs. Statistics show that the cost of automated testing can only be recovered when the number of effective executions of automated testing is >=5.
Automated testing can only find defects in the scope of regression testing, and cannot do exploratory testing like manual testing.
Combining the advantages and disadvantages of automated testing, which scenarios are suitable for using automated testing?

Scenarios with stable requirements and infrequent changes
Scenarios that require frequent regression testing For
projects that cannot be achieved through manual testing or are too costly to manually test,
such as the key business mentioned above that requires 7*24 hours to ensure stability, automated testing technology can be used Operate without interruption.

3. Prepare for automated testing

Taking the test user login as an example, the manual test steps are as follows:

Registered user
Test user login
There are two problems:

When registering, the registration service needs to be available. If the user cannot be registered, the test will block.
During the test, the user is not used. In other words, if someone happens to delete the user you just created at this time, the test will fail.
Problem 1 is the preparation of test data, and problem 2 is the interference of the test environment.

3.1 Preparation of test data

Still taking the test user login as an example, we have several methods to obtain registered users:

Directly operate through the GUI
This method is simple and direct, but the efficiency is low. There is no problem
in calling API generation and
implementation. The problem is that a front-end operation may call a series of back-end APIs, not to mention the problems encountered in obtaining these series of APIs. The process of calling manually one by one can catch up with the direct operation on the front end.
There is no problem in implementing database operations
. The problem is that a test student does not know which database tables have been modified by a business. Secondly, even if he knows, manual insertion is troublesome, and directly modifying the DB data. One accidentally deletes or mistakenly deletes Changed, my hands shake just thinking about it.

In fact, there is a better way to call the API or operate through the database to make it an automated tool. For example, a normal registration requires entering a user name, password, and even an email and mobile phone number, and finally an account is generated. And if you want to test the user login function, the user name, password, email address, and mobile phone number are not the focus of attention. In other words, it doesn’t matter what these values ​​are, you just need a user name/password that can log in. Therefore, after understanding the API call sequence, we can make an automated tool (requires front-end knowledge), with a default username (such as test+<timestamp>) and password (such as test123), and one-click registration. In this way, the efficiency is greatly improved and the possibility of manual operation errors is reduced.

In a broad sense, the realization of automation tools is also a part of automation technology.

3.2 Preparation of test environment

Usually the operations of testers are carried out in the test environment. Do you need to build and maintain a test environment specifically for automated testing? Obviously, there are certain material costs and maintenance costs. If a set of test environments are used together, they will interfere with each other. Especially for many businesses with relatively long processes, you need to verify a link. It may happen that this data is used by others, which will lead to the failure of the use case. Therefore, you need to analyze it again, and finally find that it is a data problem. Here are a few solutions I have come across:

In the automation use case, the environment is built in real time, and the environment is released after the automation use case is executed.
Advantages: The automated test environment is naturally isolated.
Disadvantages: The real-time construction environment not only requires a large number of servers, but also requires a lot of time.
Therefore, it is not suitable for fast-paced Internet products.
Separately maintain the manual test environment and the automated test environment.
Advantages: data isolation
Disadvantages: when there is an update, you need to deploy and maintain two copies.
The fast pace of Internet products determines that the deployment is very frequent, and the efficiency of this method is relatively low.
Share the manual test environment and the automated test environment.
Advantages: only one environment needs to be deployed and maintained

Disadvantage: data can interfere with each other

Of course, there are other ways to solve data interference, such as naming conventions, users related to automation use cases, etc. have a fixed prefix (such as auto), and you do not use this type of data in manual testing.

Which solution to use depends on the current problem to be solved. If the automation is in its infancy, you can share the environment first, and wait for the automation to be built; if it is more mature and the data interference is serious, you can consider maintaining two sets of environments.

4. Introduction to Automation Technology

4.1 API automation technology

Code-level API testing is relatively simple, because the basic steps of API testing are very standard:

Prepare test data,
initiate a request , and verify the
response result . Whether it is a request parameter or a response parameter, it is a key-value pair of KV, and the verification result only needs to parse these key-value pairs.
Therefore, there are only a few commonly used classes and methods.

The difficulty lies in: which interfaces are designed for business processes, how to design interface use cases, and how to organize and manage them.

This article does not introduce in detail, if there is time & someone needs it, I will update it~

4.2 GUI automation technology

The core idea of ​​GUI automated testing is to automate the operation of page elements based on page element recognition technology to simulate the behavior of actual end users and verify the correctness of software functions.

GUI automation testing mainly has two directions:

GUI automation testing of traditional web browsers: the mainstream solution is selenium
GUI automation testing of mobile terminals: the mainstream solution is Appium, app+selenium
first let's understand the working principle of selenium and appium.

As a TE, you must know that the technologies of selenium 1.0 and 2.0 are quite different. The core of the former is Selenium RC, while the core of the latter is webDriver. Given that the current 2.0 and 3.0 (which are essentially the same as 2.0) are the mainstream, only the working principle of selenium 2.0 is introduced here.

Selenium 2.0 is a typical client-server model. The client side is the test case, and the server side is the remote server. The execution process is as follows:

After understanding the principle, the remaining work is to implement the test cases with code. Of course, the key here is how to identify page elements (if someone needs it, please open a special article to introduce it).

The page elements are correctly identified, and the code is to verify the business process. This part itself belongs to the development work. Like developing and writing code, it needs code specification, layered design, and encapsulation (module encapsulation, page object encapsulation, etc.).

5. Common interview questions

  1. How to locate page elements
  2. What is the difference between APP testing and web testing?
  3. How is interface automation done?
  4. The principle and steps of GUI automated testing
  5. How to ensure the stability of test cases in GUI automated testing?

6. Thinking and conclusion

This article introduces the concept of automation and why to do automation, the preparation work required for automated testing: test data and test environment, and finally briefly introduces the automated testing technology at the code level.

In a broad sense, automation technology includes not only test cases for code implementation, but also automation tools for code implementation.

Regarding the automated testing technology at the code level, I will update the details later when I have time~

Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it away directly: [Collect at the end of the article]


     [The following is the most complete software test engineer learning knowledge architecture system diagram + full set of materials I compiled in 2023]


1. From entry to mastery of Python programming

2. Interface automation project actual combat 

3. Actual Combat of Web Automation Project


4. Actual Combat of App Automation Project 

5. Resume of first-tier manufacturers


6. Test and develop DevOps system 

7. Commonly used automated testing tools

Eight, JMeter performance test 

9. Summary (little surprise at the end)

life is long so add oil. Every effort will not be let down, as long as you persevere, there will be rewards in the end. Cherish your time and pursue your dreams. Don't forget the original intention, forge ahead. Your future is in your hands!

Life is short, time is precious, we cannot predict what will happen in the future, but we can grasp the present moment. Cherish every day and work hard to make yourself stronger and better. Firm belief, persistent pursuit, success will eventually belong to you!

Only by constantly challenging yourself can you constantly surpass yourself. Persist in pursuing your dreams and move forward bravely, and you will find that the process of struggle is so beautiful and worthwhile. Believe in yourself, you can do it!   

Guess you like

Origin blog.csdn.net/nhb687095/article/details/132297961