Preface
When I first started to come into contact with web automation testing, there was no direct leader, and the testing industry knowledge was far less abundant and accessible than it is today. At that time, I had little understanding of the layering of automated testing, let alone a pyramid, such as Like many colleagues, I first entered the pit of UI automation. At that time, I had not developed the habit of searching for English information. The Chinese information about Selenuim2 and WebDriver was still quite limited. The mainstream in China was still Selenuim1. I first familiarized myself with the API and got familiar with it. Element positioning method, some simple encapsulation, and later PageObject, full of energy.
However, in the later stages of the UI automation stage, I already had a better understanding of automated testing. Coupled with the job change, I started to jump into the pit of interface automation. Through work experience, friends and the Internet, I had a certain understanding of the current situation, which was about In 2015, I had some vague ideas in my mind. The architecture of our test objects has changed from the simplest three-tier architecture, to distributed architecture, to SOA, to microservices, all the way forward, and let's look at our testers' understanding of the Web. For the implementation of system interface automation, let’s not talk about directly using mature tools such as Postman. As far as self-developed frameworks are concerned, Java is useful, such as Junit/TestNG + Ant (+ Jenkins + JMeter + xxx), and Python is useful, such as Based on the well-known RobotFramework, Ruby may be used, it may be based on Cucumber, which is familiar in the BDD world, etc. The technology stack may be different. In essence, most of them are isolated projects + data and use cases managed in the form of files.
Maybe four or five years ago, most of what I saw were solutions like this. Today, the number of testing practitioners has increased significantly, and more and more people have good coding skills and can use them in testing work. However, what I see is that these solutions still account for the majority. Except for a few top domestic Internet companies, as far as I know and what can be searched on the Internet, try to turn the solution into the form of a simple Web system and use database storage Data,online management automation is rarely implemented. As for these plans themselves, I think as long as they can achieve the goals of my team, they are all good, and there is no distinction between advantages and disadvantages. What I care about is that the changes I have seen are much lower than expected, and the new attempts are much lower than expected. I think that for many new attempts, for current testers, the difficulty will not be much higher than the previous solutions, and the time cost will not be much higher. I hope that our testers will do automated implementation. Sometimes, just like business testing, it can not be limited to a certain direction.
Since I saw very few attempts, I wanted to do it myself and slowly formed some ideas. By 2016, the company's original automation solution could not support the needs of some new products, so I began to invest energy in designing and implementing one. The web-type testing platform felt as if it had just begun to independently implement UI automation, and it had a lot of momentum. Design selection, coding, the first version of the server went online, the first team started using it, the first version of the UI went online, 1.6, 2.0,... In terms of functionality, I have made a system that is barely close to my expectations (if not Considering the poor UI). On the surface, I completed the platform alone, but in fact, the recognition of the ideas, the support of work arrangements, and the needs of business line partners from fellow experts are indispensable. I originally planned to write an article about this part this year, but due to being very busy with work and life this year, I have almost no independent time on weekends in the past six months, and procrastination has caused trouble, so I finally started coding today.
Although I am not sure how much the content I plan to output this time will help readers, I still plan to write it in several articles. Of course, I am not sure how many articles I can output. Procrastination is a strong enemy, so I decided to write the first article first. make an overview
The introduction to this issue is a bit too long, sorry. I hope this article can bring some value to those who have the patience to read this.
1. Goals and positioning
The first thing to note is that since the focus of work in recent years has been mainly on the Web server, and based on the current work situation of the team, the automation strategy has been to prioritize the implementation of the interface layer rather than the UI layer, so the current main functions of the platform are around the HTTP layer. Automated testing is deployed.
The platform is positioned as an automated public platform for the company's business line servers. The goal is to support the company's product groups to improve testing efficiency through rapid implementation of automated testing.
2. Platform features
The most basic feature is that the platform is a Web service with separate front-end and back-end. Basic information and test cases are managed by a database, and test reports can be viewed online. To be more detailed, I think it might be clearer to present it through comparison. The implementation mentioned in the introduction is compared here with the test platform described in this article.
| Comparative item | Common projects in the industry | This article platform |
|---|---|---|
| position | Support the interface automation requirements of a certain product line | Support various automation needs of each product line |
| applicability | Automation for specific web system interfaces | Suitable for automation of interfaces for different products and different design concepts |
| infrastructure | Independent project, file-based management data | Web service with separate front-end and back-end, managing data based on database |
| Landing method | Build a running environment locally, obtain the project and run it to debug new use cases | Online UI operation, open interface facilitates CI integration |
| Data management | Manage use cases by updating/uploading files | Create/update use cases online and use MySQL to manage data |
| Operation mode | Implement run plan management by editing Jenkins job/Crontab, etc. | Online customization of run time schedules and run content |
| Result verification | The verification granularity is coarse, and the database verification may be in the code. | Fine-grained verification based on Json parsing, online management of database verification |
| historical data | Lack of effective management of historical data | View historical running records and test reports online |
3. System architecture
The general system architecture of the entire platform is as shown below, in which product database interaction is mainly data preset/cleaning/verification
Platform system architecture
4. Related technology stacks
| application | Technology/Tools |
|---|---|
| Web service basic framework | Spring Boot |
| Web container | Jetty |
| Persistence layer framework | MyBatis |
| HTTP call and verification basic framework | REST-assured |
| Use case scheduling execution | TestNG |
| HTML report | Allure |
| Platform interface information | Swagger |
| Basic UI components | Bootstrap |
| Front-end and back-end interaction | AJAX(Jquery) |
| Online code editing | Ace |
Regarding online code editing, it is mainly provided for students with basic coding skills to apply automated implementation in complex scenarios. Ordinary interface automation requirements are not required. Subsequent articles will explain more.
5. UI Overview
Basic information management
Use case management
Online scene editing
Scheduled plan management
Use case debugging
Online report
Email sample
6. Parts to be improved
The platform currently has two major functional deficiencies:
- Account system and permission control
- Security control (sandbox) for dynamic compilation and running of code
The account system and permission control are currently not implemented, mainly due to time and cost issues. Considering that the current platform is used by various test groups within the company, there is no particularly strong demand for the time being. As for the security issues of dynamic compilation and operation, it is mainly due to difficulty and time cost. For this security issue, I currently do not have a comprehensive solution. I welcome your valuable opinions. On the other hand, as a platform for intranet operation , security requirements are relatively low.
Thank you to everyone who reads my article carefully. There is always a courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends, and this warehouse also accompanies Thousands of test engineers have gone through the most difficult journey, and I hope it can help you!Friends in need can click on the small card below to receive it
