Performance testing project case

1. Project introduction and deployment

1.1 Introduction to micro mall functions

The light mall is an e-commerce project, and it is necessary to comprehensively evaluate the functions of each interface of each project and give optimization suggestions;

functional framework

  • Front desk: home page, product page details, add to shopping cart, order, payment, group purchase, coupon;
  • Backstage: product management, member management, mall management

1.2 Technical introduction to the light mall project

Front-end (visible part—HTML, JS technology implementation):

  • WeChat applet
  • web page

Backend (the invisible part - JAVA is implemented through the backend technology code):

  • Server (application server, database server, background business logic code)

1) Light Mall is a project that supports front-end and back-end separation of web and WeChat mini programs.

  • The separation of front-end and back-end can be understood as the separation of the front-end system and the back-end into two sub-projects for development:
  • The external performance is: after the front-end of the front-end and back-end separation project sends a request, the response content is a json string;
  • If it is a project where the front and back ends are not separated, the response is an HTML page

Compared with projects that do not separate the front and back ends, projects with front and back ends have
high operating efficiency : only basic data needs to be transmitted during data transmission, and html format does not need to be transmitted;
good scalability : front and back ends are separated through the data interface, as long as the excuse is not Change, the front-end code can add any functions you want to add, and the back-end code can also add functions independently. If the front-end and back-end are coupled, adding functions requires the front-end and front-end to work together.

2) The front-end is developed using the VUE technology framework, which supports WeChat applets, mobile terminals, and web pages.

3) The backend uses the SpringBoot framework for development and MySql as the database.

4) Currently still in the development and improvement stage

1.3 Technical architecture of the micro mall project

Technical architecture diagram:


1.4 Familiar with database design

Before performance testing, you need to have a certain understanding of the database tables involved in some of the business functions to be tested;

1) Be familiar with the database design structure to facilitate later performance monitoring of the database;

2) During the performance testing process, the database is prone to bottlenecks;

1.5 Deployment process of micro mall project

Preparation:

Install JDK

InstallMySQL

Install nginx

Install node.js

Project construction steps:

Project deployment process:

2. Performance testing requirements analysis

  • Functional testing: focus on the business functions in the requirements specifications (forward and reverse)
  • Performance testing: Focus on how well the system meets specific business requirement scenarios (time, resources)
    • Dimensions of concern: business functions, project code, servers, hardware configuration

2.1 Obtaining performance requirements

1) Proposed by the customer (the customer can be Party A or the product)

  • Software that can clearly put forward requirements is generally industry software related to finance, banking, telecommunications, and medical care.
  • Even if it is a demand put forward by a customer, a preliminary assessment of the reasonableness of the demand is required.

2) Based on historical data analysis (calculate the performance indicators that should be achieved based on the operating data during the operation of the software)

  • Daily activity - preliminary assessment of stable load
  • Peak - preliminary assessment of pressure loads

2.2 Extraction of new energy test points

Performance test point extraction rules:


Light mall performance test point extraction:

  • 1) According to the extraction rules of performance test points and combined with the functions of the light mall project, sort out the test points to be tested;
  • 2) Obtain the performance indicators that each test point must meet by using the method of obtaining performance indicators explained earlier (product supply/operation data calculation)
  • 3) Determine performance testing goals:
    • Each core business function is required to meet corresponding performance index requirements.
    • Test whether performance index requirements are met based on business processes (multiple interface combinations)
    • Simulate users' real business scenarios and conduct long-term stability tests

2.3 Performance test plan (this part overlaps with the above, the previous part is a thinking point, and finally it must be implemented in the test plan document)

1) Test background

The light mall is a newly developed e-commerce project of the company. In order to ensure that the project can run stably after it is launched and can withstand user growth in the later promotion, the project needs to be tested for performance;

2) Test purpose

  • Determine TPS for core business functions
  • Stress test business processes (multi-interface combinations)
  • The system can operate stably for 24 hours under actual system operating pressure.

3) Test scope


4) Test strategy:

  • Benchmark testing-----Do benchmark testing first to determine the estimation standard
  • Load testing - by gradually increasing the system load, testing changes in system performance, and ultimately determining the maximum load test that the system can withstand while meeting the system's performance indicators;
  • Simulate 5, 10, 30, 50, and 100 users respectively to load test the system to see whether the system software indicators meet the requirements under different concurrency conditions;
  • Stability test-----Conduct a 7*24-hour non-stop stability test on the system with 200 users, check whether there are any abnormalities and errors in the server log: whether there are abnormal fluctuations in various indicators of the system software, and whether there is memory Overflow issues;
  • Verify the long-term stability of the system and whether there are problems such as memory overflow.

5) Risk control:


6) Delivery list: corresponds to the products at each stage of the schedule;

Performance test plan, test script, performance defect statistics and performance test report, etc.;

7) Progress and division of labor: The performance testing work is divided into several steps, as well as the start and end time of each step and the corresponding person in charge.


2.4 Writing performance test cases

Refer to the following performance test case template to write:

  • For performance testing of a single business function, write a test case for each test point (multiple interfaces are strongly related - according to the interface, multiple interfaces can be put into the same use case)
  • For combined testing of multiple business functions, representative business processes are selected to write test cases according to the user's actual business scenarios.

3. Development of performance test scripts

Use JMeter to write test scripts and debug;

3.1 Commonly used test components

Insert image description here
Initialization work:

1) Create test case structure

Note: A thread group is a use case, regardless of how many requests there are;

2) Set HTTP request default value

3) User-defined variables

4) Add a listener—view the result tree

5) Add listener—aggregation report

3.2 Writing scripts

3.2.1 Login script




Assertions: status code, errmsg

If you do interface testing, you must assert the business data in the response, and you can add status code and description information.

If you are doing performance testing, you can only add status code and description information assertions



3.2.2 Get home page data



3.2.3 Search for products

If the parameters in the URL are in Chinese, it is recommended to write the parameters in the following list


Assertions: status code, errmsg

If it is an interface test script, assertions must be made about the number of items in the response.

3.2.4 View product details


Assertions: status code, errmsg

If it is an interface test script, assertions must be made on the product details in the response;

3.2.5 Add to cart


Add Request 1 – Login

Insert image description here
Add json extractor:

Insert image description here
Add Request 2 – Add to Cart

Insert image description here
Add assertions: status code, errmsg

If it is an interface test script, you need to query my shopping cart again to check whether the data returned by my shopping cart is consistent with the data returned by adding to the shopping cart, that is, you need to add another request;

3.2.6 View shopping cart


Request: First send a login request, extract the token information, add the view shopping cart, assign the token information to the X-litemall-Token header field, and fill in the request path and parameters;

3.2.7 Submit order



Submit an order: 1) First send a request to log in and extract the token information; 2) Add a settlement request, assign the token information to the X-litemall-token header field, fill in the path request and parameters; 3) Add an order request, and assign the token information to X-litemall-token header field, fill in the path request and parameters (note that the address and ID must match the user ID)

response:

Status code; errmsg

If the script is an interface test script, it needs to be asserted that the order data in the response message is consistent with the number of my orders in the order table in the database;

3.2.8 View orders

Insert image description here
In the process of writing scripts, commonly used static data can be written into user-defined variables and referenced when the script is running. The advantage is that if the data is not modified later, the variables can be modified directly without going to each script to make modifications;

3.2.9 Business process scripts

Insert image description here
It seems that the use case is complicated, but writing the script is simple, because the single interface scripts have been written and can be directly combined;

Finally, I would like to share with you some of my learning materials:

The above content should be the most comprehensive and complete preparation warehouse for software testing friends. In order to better organize each module, I also referred to many high-quality blog posts on the Internet. and projects, trying not to miss every knowledge point. Many friends relied on these contents to review and got offers from major manufacturers such as BATJ. This warehouse has also helped many software testing learners. I hope it can also help you. .

Follow my WeChat official account below to get it for free! ↓ ↓ ↓ ↓ ↓

Guess you like

Origin blog.csdn.net/weixin_56331124/article/details/132625549