For a long time, I want to open a blog to record the experience, success, and failure in the work, but I have been delayed because of various reasons. Now it is supplemented.
First, let's talk about my current state and concern. We have a total of 12 people in Stress Testing Team, which is a system test of a large universal software. Our department focuses on this product test. With regard to this product, we have a huge team.
Dev Teest Team (dozens of dozens) install test team (dozens of people) Benchmark Tool Dev Team (dozens of dozens), responsible for the Bechmark tool development and performance report of the entire system People), the system tests Qa Teamsystem Test Team in each platform. This is the Team I am.
As can be seen from the above description, some departments have conflicts, such as Benchmark Team and our System Test Team. They are mainly responsible for the development and performance report of the Benchmark tool, and our responsibilities include performance reports. I don't want to discuss how to discuss it, we still return to the technical level.
Pressure test
BUG affecting software performance through Stress Test [1], BUG affects software performance, such as the performance bottleneck of BUG software that Memory Leak will only appear under continuous user pressures.
Develop corresponding qualified standards and carry-on the corresponding Load Test [2]
Pressure test tool
As we all know, there are now many automated pressure test tools, commercial tools such as Load Runner, free tool such as Apache Jmeter. The biggest benefit of these tools is that you can automate recording scripts and provide a lot of support for performance monitoring. But there are some problems that these tools inevitably:
For simple TESTs for simple Web UIs are sufficient, and you can use automatic recording manual modification methods to generate scripts, which greatly facilitates pressure testing. But for complex processes, you still have a lot of test code to write, this time, it is very limited to support for your automation tool. For a complex system, there may be a variety of access methods, the Web UI's SDK call, a wide variety of processes, resulting in a variety of results. In order to ensure the quality of the software, you must provide a more complete results verification mechanism. At this time, you find that you are subject to test tools. There are too many large systems that can support large users, and the efficiency of test tools is a big problem. For traditional test tools, Script Testing Server mode efficiency will not be too good.
Lightweight test framework
Based on the above problems, for a large universal software, a lightweight test framework (Testing Framework) can achieve better results than traditional test tools.
In order to facilitate the transplant between the platform, we selected Java. This framework is driven throughout the test, and each test case and test module are written in Java. Relative to traditional test tools, Testing Frame Work will not be responsible for explaining the test module, which is parallel to drive relationships. This parallel drive relationship utilizes Java's Reflect function, and is implemented by parsing XML. Such structures have better flexibility and better efficiency, but this maximum disadvantage is:
A large number of repeated programming of the interface. For the web interface, you need to read JavaScript in the web page to find out what they really want to do, find out what data they sent with HTTP, and then use the Java code to generate each http request, this is one A very headache. Our existing approach is to provide many auxiliary tools to help analyze interfaces as much as possible. Note -----------
[1] The main goal of Stress Test is to discover the performance bug's performance bug. In Stress Test, you must test different test cases and test configurations, including some extreme cases.
[2] The purpose of Load Test is to test the operation of the software in a given load, and issue the corresponding performance report.
