Table of contents
Why do you need a stress testing platform?
Functional Design Thoughts of the Stress Testing Platform
Pressure testing platform technology implementation plan
Why do you need a stress testing platform?
Starting from the actual work scenario, if there are only one or two people doing performance testing, there is no need to develop a dedicated stress testing platform for the following reasons:
- Cost issue: To develop a stress testing platform, at least 1-2 dedicated manpower needs to be invested in the early stage, and long-term maintenance is required;
- Efficiency issues: the number of people is small, which basically means that there are not too many pressure test tasks. Script management data management can be uploaded to the server locally. The server only needs to establish a corresponding file directory according to the business domain and pressure test nodes, and then have a crontab The scheduled task can be cleaned up;
- Collaboration issues: The small number of people does not really require a platform to solve specification and process issues, and collaboration matters can be resolved verbally in a few words;
Regarding stress testing platforms, or various testing platforms, many students actually have a misunderstanding: the platforms are all high-end and powerful, but they often ignore the cost of development and maintenance and learning to use the platform itself.
The purpose of the test platform is to provide standardized operations through the platform, constrain individual differences in a process-based manner, reduce the cost of troubleshooting and problem solving caused by repeated wheel creation and differences between wheels, and further improve human efficiency .
After all, work is ultimately result-oriented. If problems are not solved more efficiently, the platform will eventually become a sunk cost .
Assuming that you want to own a stress testing platform now, I personally think that at least the following conditions must be met:
- Multiple business lines, fast version iteration (demand driven);
- The technical differences between individual test teams are relatively large (technology-driven);
- There are many performance requirements, and online stability problems occur frequently (problem-driven);
- The technical team has reached a certain scale, and there are more people doing stress testing (efficiency driven);
Functional Design Thoughts of the Stress Testing Platform
After talking about whether the stress testing platform is necessary and the problems to be solved, this part talks about what conditions an available stress testing platform must meet.
- Simple and easy to use: the platform has low cost of learning and using, and the operation is simple and fast;
- Data persistence: test script & test data & test result persistence, easy to trace historical records;
- Low maintenance cost: It can be used out of the box, can interact with external systems, and has efficient technical support if there is a problem;
- Support multi-person collaboration: It can be used by people from different teams, and the pressure test can be carried out quickly without cross-influence;
- Easy configuration management: the management of stress test clusters, stress test components and some configuration items is convenient and efficient, without typing too many commands by hand;
- Perfect pressure support: support a certain high concurrency capability, the pressure test cluster can be expanded, support multi-protocol and basic self-defined expansion capabilities;
After reading the above conditions, we have relatively clear requirements for the functional modules of the stress testing platform.
- Use case management: A stress test project can create multiple stress test tasks, task = use case, and use cases include stress test scripts, stress test data and plug-ins;
- Pressure test execution: supports manual and scheduled execution of pressure tests, can configure operating parameters, can select multiple pressure test nodes, and supports running multiple pressure test tasks at the same time;
- Real-time monitoring: core indicators such as TPS, RT, number of requests, and error rate are displayed in real time during stress testing, and support selection and calculation by time period;
- Pressure test results: After the pressure test is completed, the pressure test results of the entire task can be displayed in detail, such as TPS, ART, 90/95/99RT, number of successful/failed requests, error logs, etc.;
- Configuration management: such as pressure test node parameter changes, binding hosts, plug-in upload updates, etc.;
- Extended functions: such as support for mock, openAPI, number creation tools, compatibility with third-party libraries, etc.;
After reading the above conditions and functional module requirements, what specific functions should a basic stress testing platform have? Please see the picture below:
PS : This picture is for reference only, and it does not mean that these functions must be fully available. Set it according to your specific situation.
Pressure testing platform technology implementation plan
Next, let’s talk about the technical implementation of some functions of the stress testing platform.
In fact, the technical architecture of the stress testing platform already has a lot of keyword searches, and I don’t want to spend too much time here, making micro-innovations on the basis of others.
I would like to share some technical implementation plans of specific functional modules for your reference.
mock function
Log Sampling Function
PS : This function is implemented based on jmeter as a pressure measurement tool and is for reference only.
Summarize
Thanks to everyone who read my article carefully! ! !
I personally sorted out some technical materials I have compiled in my software testing career in the past few years, including: e-books, resume modules, various job templates, interview books, self-study projects, etc. You are welcome to click the link below to get it for free, don't miss it.
