Many friends are concerned about how to build an interface automation platform. The author happens to have experience in the process of building an automated test platform from scratch to product commercialization, so I can share with you. Due to the nature of the enterprise, it is impossible to share too much code. This article aims to share my thinking and summary in the process of building the whole platform, so as to provide some reference for the friends who want to develop in this field, and also be a periodical summary of my own. This paper mainly summarizes the following issues:
- How to be technical according to the current situation of the team
- What are the stages that the platform will go through in the evolution of 挰, and what should be paid attention to
- Distinguish between platform capabilities and individual capabilities, and don’t be fooled by appearances
NO.1 on the selection of technology
All things are difficult before they are easy, and there is a great deal of literature out there on interface automation platforms, both open source (though much of it is Demo level) and commercial. There are also some professional tools recognized by the industry, such as Pytest, PostMan, Jmeter and so on, but how to choose a good framework as the underlying foundation for your team? (You don’t need to build your own wheel, and it won’t necessarily be better than others)? Personally, at least from the following aspects to consider.
1.1 What is the current status of the team?
If the current team has part of the interface testing work in progress, but not standardized and sustainable, then as far as possible to the existing tools as the bottom of the development, to cultivate user habits of the cost is very high, others may not be willing, also involved in migration costs. If the current team has not done much interface testing, then the technology selection can be considered carefully
1.2 What are the resources of the team?
The resource here is actually the research and development capability. Will there be several people working on it, or will you do it by yourself? What are the development languages that people are good at? Do you have the ability to do front-end pages? Whether there is time commitment (most of the time may not be given). For development languages, you don’t have to worry about Java or Python, just use whichever you’re good at. It’s better to be on the same page as the development team than not (if you’re really familiar with one language, it’s easy to switch to another. I switched from C to Java and now To Python, and it didn’t take long to get used to it.)
1.3 Why choose it?
There are a large number of open source frameworks available for each language (Java JunitTest, TestNg, Python Pytest, HttpRunner, etc.). There is no significant difference in nature, as long as the framework you choose is well-documented and still updated. It’s not a problem. Don’t choose a framework that no one else maintains (especially those Demo frameworks on GIT, which can be misleading).
Summary: technical problems must be starting from the actual situation of the team to practice, because make things, whether it’s platform or framework that is used to give to a specific person to fall to the ground, so we need to respect your users, pure ability show code less do (if you really want to, go to GIT commit the code above, in the company, is mainly to solve the problem).
After confirming the selection of the technology, we can enter the research and development phase. At this point, don’t try to plan a big and complete platform, and make too many technical assumptions. Instead, focus on the most urgent needs of the current team. In Agile terms, deliver the MVP version first, get the team to recognize your platform, and really help them solve their problems. Later, there will be space to promote others to use (here will involve a problem, that is, the relationship between individuals and the platform, many will feel that if the platform, how to improve the ability of testers? I’ll leave this to the end, but hopefully you realize it’s important. Of course, if you have a team of dozens, that’s another story.
NO.2 Core problem of phase 1: availability
At that time, the team of the author did not have the ability to conduct interface testing. The testers had no awareness of interface testing and no code ability, so when they needed to conduct interface testing, they had no way to start. After analyzing the situation at that time, the pain points that need to be solved at this stage are formulated.
Pain point 1: Can quickly generate interfaces and use cases through page configuration.
Solution: Based on THE HTTP protocol (the interaction within the group is basically based on this protocol), you can configure the relevant information on the page to generate the corresponding interface and support direct debugging to avoid the interface being unavailable. At the same time, there is rich support for HTTP body content to accommodate different parameter types.
Pain point 2: Interface parameter transfer is supported.
Solution: HttrRunner itself supports parameter passing as well as fast running use cases (framework benefits), so this pain point can be easily resolved:
Pain point 3: Output reports are more testers friendly.
Solution: HttpRunner native report less friendly, so their analytical report data, do the aggregation, let the tester can more intuitive to see the results, at the same time can make the tester see parameterized or data driven, sent out what is the real request, convenient testing and development orientation (meet an error interface, if the BUG is confirmed, Just copy it and throw it to the developer.
Summary: At this stage, the running-in time is actually the longest. The running-in time of the team, the running-in time of the architecture, the running-in time of the business, and so on, the most important thing is to run the team smoothly. There are basically no major problems in the technology. They are based on the native capabilities of the underlying framework and the front-end encapsulation, which reduces the threshold for testers to use, enables testers to understand and accept the interface testing idea, guides them to use the platform, designs interface test cases, and makes the interface test really fall into place and produce results.
No.3 Core problem of the second stage: easy to use
After completing the content of the first stage, we will enter the second stage, the core idea of this stage is promotion + optimization, the goal is to make the platform easy to use, we are in and will be in this stage for a long time!! . The user decides what is good to use, so the team spent more time on landing the platform, analyzing the pain points and difficulties of testers, and supplementing the platform functions bit by bit based on their own experience and ability. Briefly summarize the following typical pain points to be solved in this stage:
Pain point 1: analyzing the interface is too troublesome, need to manually record.
Solution: By connecting with Swagger platform, Fiddler tools, etc., testers can no longer worry about interface maintenance, and can focus on use case design.
Pain point 2: Some interfaces are not developed, or how to deal with some external interfaces?
Solution: Integrate the Mock service. You can customize the result for the defined interface and generate a URL with a different domain name. When writing test cases, you only need to change the domain name when you want to call the Mock interface or the real interface.
Pain point 3: How can testers be the first to know when the interface changes?
Solution: Provide a contract function to do diff by matching the run result with the last successful run result, get changes in the interface structure, and alert the tester. (There are now dedicated contract testing services available for the Spring framework, which I didn’t notice at the time, so I took a different approach.)
Pain point 4: Preloading test execution and raising test entry barriers.
Solution: With the improvement of corporate CICD, developers can automatically trigger interface tests when merging code to verify that the main process is not affected. Connect platform use cases to the company’s assembly line as part of the quality control loop to ensure that new code does not compromise core functionality.
Pain point 5: How to solve personalized business needs?
Solution: More and more as the service team, we need the corresponding scenario also strange, how to deal with the standardized platform personalized demand through the interface cases before and after the introduction of function of function, make some personalized demand, business team can write your own code to do processing, at the same time, this part of the code can also be saved as a template, convenient reuse.
And some, such as: public login, environment to distinguish, data driven, data generation, timing tasks, file management, and so on the function point, no longer list, mainly according to actual needs to perfect the function point, most afraid of is test developers from hi, write some testers don’t use or is not the function of the pain points, let the platform become like engineering. Be sure to develop feature points in accordance with the requirements of the testers. We are and will be in this phase for a long time!! It’s not the best technology in the industry, but it’s the best solution for the team right now.
Summary: At this stage, we gained recognition from many teams and customers. For example, we carried out landing practice in several BU in the group and assisted external customers to improve the test value. The platform itself has also passed the DevOps Level 3 certification (Advanced level) by the KICT, which proves the value of the platform and proves that it will not become a generic project. This is the biggest achievement and recognition I have received.
No.4 Stage 3: Future planning
Platform functionality needs to evolve to meet more and more needs. At present, the platform has not stopped exploring more requirements, and in future planning, we hope to solve the following problems:
Problem 1: The test warehouse is built so that creating test data is no longer a difficulty
Problem 2: The corresponding relationship between interface test and code coverage provides data support for accurate testing
Problem 3: Automated generation of reverse use cases (chaos tests)
Question 4…
No.5 Individuals and platforms
Back to the original topic, when we platform-specific testing, we encapsulated the functionality, reduced the demands on the testers, and could perform the tests simply through page choreography. So how can testers improve themselves? There are two roles involved: individuals and organizations, which have different demands on the platform.
Organization: From the perspective of the organization, it is hoped that there is unified planning and management, and at the same time, the entry threshold can be effectively reduced. Through simple training, more testers can carry out special tests, so it is more necessary to provide standardized, visual and easy to operate services.
Personal: When you join a team and there is a ready-made platform for you to use, you should not be satisfied with using the platform, but should seize the opportunity to understand the concrete implementation of the platform, even participate in the development process of the platform, and turn others’ development design and problem-solving ideas into your own experience. If you rely only on the company’s platform for specific testing, that’s the platform’s capability, not the individual’s. This is why many interviewers do not like students from DACHang, because leaving the platform, personal ability may appear a cliff drop, remember (in fact, many positions will have similar problems, to learn to distinguish between their own ability, which is the platform to you).
Finally, thank all team members for their efforts and efforts. The ability of a team is far greater than the ability of an individual. It is a very happy thing to have a group of like-minded friends working together for the same goal.
The original link