Test method for new electric bureau system

Abstract

The invention discloses a test method for a new power bureau system, relates to the field of tax administration, and provides the test method for the new power bureau system in order to solve the problem that at present, test implementation for the new power bureau system still depends on manpower. And organizing a plurality of different tax data by taking the taxpayer ID as a unique identifier. And two business modes, namely a single-region single-business mode and a single-region multi-business mode, are distinguished according to the attribution and the declaration type for organization. And the file is output in a corresponding directory structure, so that the file is not mixed during storage, and a single-region single-service file or a single-region multi-service file can be conveniently read from a corresponding directory based on test requirements during subsequent pressure test. Therefore, the method can replace manual work to complete organization of tax data, is suitable for characteristic data in a tax scene, eliminates manual operation errors, can generate data files based on two different organization modes of single-region single business and single-region multi-business, and meets more diversified test requirements.

Description

Technical Field

[0001] This application relates to the tax field, and in particular to a testing method for a new power grid system. Background Technology

[0002] During the implementation and operation phase of the nationwide unified electronic tax bureau (hereinafter referred to as the "New Electronic Bureau") project, it is necessary to quickly reproduce the peak scenario of the peak tax collection period after each monthly peak collection period (the overall window is only about 5 days) to verify the system's response time, throughput, error rate, and other key indicators under high concurrency. However, the existing performance testing process lacks an automated technical solution adapted to the business characteristics of the New Electronic Bureau, resulting in low testing efficiency, poor result reliability, and insufficient scalability, failing to meet the stress testing requirements of "high frequency (once a month), high scale (tens of thousands of concurrent users), and high realism (aligning with production business logic)".

[0003] For example, acquiring load testing data still relies on manual organization of data from various regions and business types. However, on the one hand, the sheer volume of load testing data makes manual organization difficult due to the substantial human and material resources required. On the other hand, testers struggle to accurately differentiate between test scenarios of "single-region, single-business" and "single-region, multi-business mixed" data. This leads to a random and chaotic testing process, and the resulting performance metrics (such as response time and transactions per second, TPS) lack clear business guidance.

[0004] Therefore, those skilled in the art urgently need a testing method for new power grid systems to address the current problem of relying on manual methods in the implementation of testing for new power grid systems. Summary of the Invention

[0005] The purpose of this application is to provide a testing method for new power grid systems, in order to solve the problem that current testing implementation for new power grid systems still relies on manual methods.

[0006] To address the aforementioned technical problems, this application provides a testing method for new power grid systems, comprising:

[0007] Read and parse the original data file to obtain tax data fields; wherein, the original data file stores various tax data in a preset template format; the tax data includes: taxpayer ID, location, and declaration type; there is an association between the taxpayer ID, location, and declaration type stored according to the preset template, and a group of taxpayer ID, location, and declaration type constitutes a tax data field;

[0008] Using the taxpayer ID as a unique identifier, each of the tax data fields is traversed. Based on the location and the declaration type, each of the tax data fields is organized according to the single-region single-business model and the single-region multi-business model, respectively, to obtain the single-region single-business file and the single-region multi-business file.

[0009] The single-region single-service file and the single-region multi-service file are output according to their respective preset directory structures.

[0010] In one optional embodiment, the tax data further includes: a record of tax declaration results;

[0011] After obtaining the tax data fields, the following is also included:

[0012] Invalid data in the tax data fields are removed according to preset filtering rules;

[0013] The filtering rules include one or more of the following: duplicate tax data fields, missing tax data in the tax data fields, taxpayer ID is a deregistered enterprise, taxpayer ID is an abnormal taxpayer, taxpayer ID and location are mismatched, the location has not opened the business corresponding to the declaration type, and the declaration result record is failed.

[0014] In one optional embodiment, the original data file is a .xlsx or .xls format file;

[0015] After removing invalid data from the tax data field according to preset filtering rules, this method further includes:

[0016] Convert the filtered and compliant tax data fields into CSV format.

[0017] In an optional embodiment, it further includes:

[0018] Obtain the IP list of each press;

[0019] Establish network connections with each of the presses through the IP list, and detect the hardware architecture and operating system of each press;

[0020] Based on the hardware architecture and operating system, version compatibility checks are performed on each of the stress testers, and the corresponding component installation packages and stress test scripts are matched.

[0021] The system executes shell commands in batches based on the SSH protocol and initiates component installation operations to multiple stress machines synchronously through a multi-threaded concurrency mechanism. The components used to complete the stress test are installed through the component installation package.

[0022] Configure environment variables, data sources, and JMeter Dashboard templates for each stress tester according to preset configuration rules, and optimize stress test parameters according to hardware configuration;

[0023] The corresponding load test script, the single-region single-service file, and the single-region multi-service file are sent to each of the load testers.

[0024] In an optional embodiment, it further includes:

[0025] Monitor the execution status of each press in response to the received instructions;

[0026] In the event of network interruption, component installation failure, or configuration anomaly, the following steps are repeated: establishing network connections with each of the pressure machines via the IP list; executing shell commands in batches based on the SSH protocol and simultaneously initiating component installation operations to multiple pressure machines through a multi-threaded concurrency mechanism; or configuring environment variables, data sources, and JMeter Dashboard templates for each pressure machine according to preset configuration rules, and optimizing stress test parameters according to hardware configuration; wherein, when the number of repetitions exceeds a preset retry threshold, retrying stops, and the corresponding fault log is output;

[0027] Obtain the deployment results of each pressure machine and generate the corresponding deployment report.

[0028] In an optional embodiment, it further includes:

[0029] By importing the taxpayer IDs from each of the aforementioned tax data fields, a list of taxpayer IDs is generated;

[0030] Configure key parameters through the JMeter Arguments component; the key parameters include: authentication parameters, encryption parameters, and interface address;

[0031] Utilize Setup Thread Group and HTTP request sampler to batch call the unified identity management platform interface to generate tokens;

[0032] The token is persistently stored locally using the BeanShell post-processor;

[0033] Establish the association between each token and the load testing script.

[0034] In an optional embodiment, the step of generating tokens by batch calling the unified identity management platform interface using Setup Thread Group and HTTP request sampler includes:

[0035] For each of the tax data fields in the single-region single-business file: allocate a first region for storing the generated tokens; create a dedicated parameter group for the first region; generate tokens corresponding to each of the tax data fields in the single-region single-business file through a single thread group, and store each token in the first region as a token file based on the dedicated parameter group;

[0036] For each of the tax data fields in the single-region multi-business file: allocate a second area for storing the generated tokens; create a general parameter group for the second area; generate tokens for the tax data fields corresponding to different declaration types in the single-region multi-business file through multiple thread groups; merge the tokens corresponding to different declaration types into a unified token file through the BeanShell post-processor, and store it in the second area based on the general parameter group.

[0037] In an optional embodiment, generating tokens corresponding to each tax data field in the single-region, single-business file through a single thread group includes:

[0038] Read the token file stored in the second area;

[0039] Identify the declaration type field of each token in the token file;

[0040] The tokens are grouped according to the declaration type field to generate multiple token files corresponding to different declaration types; wherein, the generated token files are named according to the corresponding declaration type field value.

[0041] The generated token files are stored in the first area.

[0042] In an optional embodiment, after identifying the declaration type field of each token in the token file, the method further includes:

[0043] If multiple tokens have the same declaration type field value, only the most recently generated token will be retained, and the rest will be deleted.

[0044] In an optional embodiment, when generating a token through the thread group, the method further includes:

[0045] If the number of threads started simultaneously exceeds the preset thread threshold, the threads will be started in batches using a preset thread group gradient startup strategy.

[0046] In an optional embodiment, it further includes:

[0047] Create a token refresh thread group;

[0048] The token refresh thread group is used to: query the validity period of each token every first cycle; if the remaining validity period is less than the preset validity threshold, refresh the corresponding token.

[0049] In an optional embodiment, it further includes:

[0050] Obtain the performance metrics of each pressure machine during the pressure test process; wherein, the performance metrics include: response time, throughput, error rate, and server resource utilization.

[0051] Based on the performance indicators, analyze whether each press has a performance bottleneck, and compare the trend with historical baseline data to generate corresponding pressure test results;

[0052] Based on the stress test results, retrieve the corresponding optimization suggestions from the optimization knowledge base;

[0053] The stress test results and optimization suggestions are displayed in a visual manner, and a stress test report containing the stress test results and optimization suggestions is generated and stored locally.

[0054] This application provides a testing method for the new power bureau system, which organizes tax data using taxpayer unique codes (IDs) as unique identifiers. When local units provide raw tax data, they store the data in a preset template format, thus establishing a relationship between taxpayer ID, location, and declaration type. Multiple different tax data can then be organized into multiple sets of tax data fields using the taxpayer ID. Furthermore, subsequent operations are completed by traversing each tax data field using the taxpayer ID as a unique identifier. In this method, the location in the tax data field represents the region corresponding to that field, and the declaration type corresponds to the business type. This distinguishes two business models: a single-region single-business model and a single-region multi-business model. In the single-region single-business model, each region is further divided according to a single declaration type; that is, a single-region single-business file contains only the tax data fields corresponding to one declaration type for one region. In the single-region multi-business model, the tax data fields are categorized only according to different locations, and tax data for different businesses within the same region belong to the same single-region multi-business file. In other words, this method uses the taxpayer ID as a unique identifier to distinguish different tax data fields, and divides each tax data field according to location and declaration type. It further categorizes the data according to two different classification methods: single-region single-business and single-region multi-business, generating two different file formats: single-region single-business files and single-region multi-business files. These files are output with corresponding directory structures, ensuring they are not mixed during storage. This facilitates subsequent stress testing, allowing users to retrieve either single-region single-business or single-region multi-business files from the appropriate directory based on testing needs. Therefore, this method can replace manual organization of tax data, adapt to the unique data characteristics of tax scenarios, eliminate human error, and generate data files based on both single-region single-business and single-region multi-business organization methods, meeting more diverse testing requirements. Attached Figure Description

[0055] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 A flowchart illustrating the stress test data preparation stage of a testing method for a new power grid system provided in an embodiment of the present invention;

[0057] Figure 2 A flowchart illustrating a testing method for a new power grid system during the pressure machine deployment phase, as provided in an embodiment of the present invention;

[0058] Figure 3 A flowchart illustrating a testing method for a new power grid system during the user simulation phase, as provided in an embodiment of the present invention;

[0059] Figure 4 This is a flowchart of a test method for a new power grid system provided in an embodiment of the present invention, specifically in the result analysis stage. Detailed Implementation

[0060] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0061] The core of this application is to provide a testing method for new power grid systems.

[0062] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0063] During the implementation and operation phase of the nationwide unified electronic tax bureau (hereinafter referred to as "New Electronic Bureau") project, it is necessary to quickly reproduce the peak scenario of the peak tax collection period after each major tax collection period (the regular tax collection period is from the 1st to the 15th, and the window after the end is usually from the 16th to the 20th, and the period is adjusted accordingly if there are holidays, with the overall window period being only about 5 days) in order to verify the system's response time, throughput, error rate and other key indicators under high concurrency. However, the existing performance testing process lacks an automated technical solution adapted to the business characteristics of the New Electronic Bureau, resulting in low testing efficiency, poor result reliability and insufficient scale adaptability, and it cannot meet the stress testing requirements of "high frequency (once a month), high scale (tens of thousands of concurrent users), and high realism (close to production business logic)".

[0064] Common load testing solutions mainly include the following stages:

[0065] 1. Load testing data preparation stage: This stage requires sorting out the original tax data provided by various regions, filtering out the effective data, and organizing and integrating different types of tax data according to the load testing requirements.

[0066] 2. Press Deployment Phase: This phase involves configuring the pressure testing parameters and environment for the press to perform the pressure test, ensuring that the press can perform the pressure test.

[0067] 3. User simulation phase: This phase requires generating corresponding tokens for each user, so that the stress tester can simulate the user's tax filing behavior.

[0068] 4. Load testing execution and result analysis stage: This stage is the formal load testing execution stage, and the stage of analyzing the load testing results after the load testing is completed, marking the end of a load testing process.

[0069] Currently, manual intervention is required at every stage of the load testing process. For example, in the load testing data preparation stage, manual screening and organization of the raw tax data provided by various regions are necessary to format it to meet the requirements of the subsequent load testing. Due to the high frequency and large scale of tax data, it is too difficult to implement the load testing data preparation stage entirely manually, and it is also very easy for invalid data to remain due to human operation errors (such as omissions in template data verification and format conversion errors), thus affecting the accuracy of the load testing results.

[0070] To address the aforementioned problems, this application provides a testing method for new power grid systems, such as... Figure 1 As shown, it includes:

[0071] S11: Read and parse the raw data file to obtain the tax data fields.

[0072] The original data file stores various types of tax data in a preset template format. This tax data includes, but is not limited to: taxpayer ID (social credit code), location (regional code), and declaration type (business name). There is a correlation between the taxpayer's unique document (ID), location, and declaration type stored according to the preset template; a set of taxpayer IDs, locations, and declaration types constitutes one tax data field. It should be noted that taxpayer ID, location, and declaration type are only the minimum types of tax data required to implement steps S11-S13 of this method, which divide the data based on business scenarios; they do not mean that tax data can only contain these types. In actual tax scenarios, more complex tax data can be included, and this application does not impose any restrictions on this.

[0073] S12: Using the taxpayer ID as the unique identifier, traverse each tax data field, and organize each tax data field according to the location and declaration type, based on the single-region single-business model and the single-region multi-business model respectively, to obtain the single-region single-business file and the single-region multi-business file.

[0074] S13: Output single-region single-service files and single-region multi-service files according to their respective preset directory structures.

[0075] For step S11, to facilitate the provision of original tax data by local authorities, the original data files can use common file formats such as .xlsx and .xls. Furthermore, the table files corresponding to .xlsx and .xls formats (both being file formats) also support the establishment of relationships between different types of tax data. For example, different types of tax data can be distinguished by different columns, and different types of tax data in the same row are considered to have a relationship.

[0076] For step S12, as explained above, this method uses the taxpayer ID as a unique identifier to distinguish and organize tax data fields. Tax data fields also include location and declaration type. Location represents the region where the current business declaration occurred, and declaration type represents the specific business being declared. Based on these two pieces of information, the region and business type of this tax data field can be uniquely determined. Therefore, each tax data field can be classified according to location into single-region multi-business and according to location and declaration type into single-region single-business. Single-region multi-business means organizing the tax data corresponding to all businesses in a region into a single file, i.e., a single-region multi-business file. Single-region single-business, on the other hand, is further classified according to business based on region, and the resulting single-region single-business file only includes tax data segments for the same region and the same business.

[0077] It is also important to emphasize that the data in single-region, multi-business files and single-region, single-business files are not mutually exclusive. In other words, the same batch of tax data fields can be organized into two forms—single-region, single-business and single-region, multi-business—based on different partitioning methods. Both single-region, single-business files and single-region, multi-business files contain all tax data fields.

[0078] Next, in step S13, after obtaining the single-region single-business file and the single-region multi-business file, they are output according to their respective preset directory structures, thereby distinguishing between these two types of tax data obtained based on different organizational structures. In subsequent stress tests, the stress tester can read the single-region single-business file or the single-region multi-business file from a specific directory to perform stress tests under different scenario modes.

[0079] Furthermore, as described above, the accuracy of tax data is one of the key factors affecting stress test results. Therefore, this application also provides a further embodiment:

[0080] Tax data also includes: declaration result records. And after step S11: obtaining the tax data fields, this method further includes:

[0081] S14: Remove invalid data from the tax data fields according to preset filtering rules; the filtering rules include one or more of the following: duplicate tax data fields, missing tax data in the tax data fields, taxpayer ID is a deregistered enterprise, taxpayer ID is an abnormal taxpayer, taxpayer ID and location are mismatched, the corresponding business for the declaration type has not been opened in the location, and the declaration result record is failed.

[0082] It is easy to understand that the filtering rules are related to the type of tax data. Since the types of tax data in practical applications are complex and diverse, different scenarios may require different types of tax data. Therefore, this embodiment only provides corresponding filtering rules for the most common types of tax data in practical applications. Similarly, for these types of tax data, it is not limited to using only the filtering rules mentioned above. This embodiment provides only one optional solution; in practical applications, more and more complex filtering rules can be adopted for data cleaning.

[0083] The purpose of this embodiment is to clean the tax data fields after the initial organization of the tax data (i.e., organization into tax data fields). This involves removing invalid data to ensure data accuracy, thereby improving the accuracy and reliability of the final stress test.

[0084] On the other hand, as can be seen from the above embodiments, local governments currently typically provide raw tax data in .xlsx and .xls formats for convenience. However, for pressure testing, pressure machines generally cannot directly recognize .xlsx and .xls format data and usually need to be converted to comma-separated values ​​(CSV) format. Therefore, this application also provides an optional embodiment:

[0085] If the original data file is in .xlsx or .xls format, then after step S14, this method further includes:

[0086] S15: Convert the filtered, compliant tax data fields to CSV format.

[0087] Since there are already several mature technical solutions for converting .xlsx and .xls formats to CSV format, this embodiment will not elaborate on them. This embodiment converts the tax data fields in .xlsx or .xls format to CSV format after data cleaning. This ensures that the subsequently generated single-region multi-business files and single-region single-business files can be directly recognized by the pressure machine; it also avoids converting invalid data, further improving efficiency.

[0088] Furthermore, steps S11 to S15 above correspond to the stress test data preparation stage in the stress test process for the new power grid. Each of the above steps can be implemented using corresponding functional modules developed using Python (a computer language) + Pandas (a data analysis package in Python), that is, these functional modules serve as the execution entities for steps S11 to S15 above.

[0089] As can be seen from the above embodiments, this application provides an automated data processing solution for the stress testing scenario of the new power bureau, specifically addressing the most manpower-intensive and time-consuming data preparation stage. When the original tax data is provided by the local government, the tax data is stored in a preset template format, establishing a relationship between taxpayer ID, location, and declaration type. This allows various different tax data to be organized into multiple sets of tax data fields using the taxpayer ID. Then, two business models—single-region single-business model and single-region multi-business model—are distinguished and organized based on the location and declaration type in the tax data fields. The data is then output in a corresponding directory structure, ensuring no mixing during storage, facilitating subsequent stress testing by retrieving single-region single-business or single-region multi-business files from the corresponding directory as needed. Therefore, this method can replace manual tax data organization, adapt to the unique data in tax scenarios, eliminate human error, and generate data files based on two different organizational methods: single-region single-business and single-region multi-business, meeting more diverse testing needs.

[0090] On the other hand, the current stress testing process for new power grids also includes a stress machine deployment phase. Currently, the common stress machine deployment solution involves manually configuring multiple stress machines sequentially. This deployment method has four major problems: First, deployment efficiency is extremely low, requiring manual installation of components and configuration of the environment on each machine, which can take several hours when dealing with provincial distributed clusters (dozens of machines); second, poor environmental consistency, manual configuration is prone to parameter deviations, component version management is chaotic, and the heterogeneity between different stress machines is prominent, leading to distorted stress test results; third, cross-platform adaptation is difficult, requiring manual differentiation between x86 / arm64 (x86 and arm64 are both computer architectures) server platforms and matching the corresponding installation packages, resulting in a high adaptation error rate and a single-node deployment rework rate exceeding 30%; fourth, troubleshooting is cumbersome, requiring manual troubleshooting and location of problems such as component download failures and configuration anomalies during deployment, which is time-consuming and has poor fault tolerance.

[0091] To address the above problems, this embodiment also provides a corresponding solution. For example... Figure 2 As shown, this method also includes:

[0092] S21: Obtain the IP list of each press.

[0093] IP address: Internet Protocol Address, or simply IP address.

[0094] S22: Establish network connections with each press machine through the IP list and detect the hardware architecture and operating system of each press machine.

[0095] S23: Perform version compatibility checks on each stress tester based on the hardware architecture and operating system, and match the corresponding component installation packages and stress test scripts.

[0096] The hardware architecture, as described above, can include architectures such as x86 and arm64.

[0097] S24: Executes shell commands in batches based on the SSH protocol, and initiates component installation operations to multiple stress machines synchronously through a multi-threaded concurrency mechanism, and installs the components used to complete the stress test through the component installation package.

[0098] The components used to complete the stress test include, but are not limited to: JRE, JMeter, Influxdb, and Grafana.

[0099] SSH: Secure Shell. It is a protocol used for secure remote login and other secure network services over insecure networks. In this embodiment, the SSH protocol is used to achieve network communication between the method execution entity (i.e., the host computer of the pressure machine) and each pressure machine.

[0100] Shell: In computer science, a shell is a concept distinct from the kernel, referring to software that "provides an operating interface for the user".

[0101] JRE: Java Runtime Environment, which is the runtime environment for Java (a computer language).

[0102] JMeter: Apache JMeter is a performance testing tool used to simulate high-concurrency loads.

[0103] InfluxDB: A time-series database designed for efficient storage and querying of time-series data (such as monitoring metrics).

[0104] Grafana: A data visualization platform that supports multiple data sources and is used to create real-time monitoring dashboards.

[0105] S25: Configure environment variables, data sources, and JMeter Dashboard templates for each stress tester according to preset configuration rules, and optimize stress test parameters based on hardware configuration.

[0106] JMeter Dashboard: A dashboard report that displays performance test results through a graphical interface, including key metrics such as response time, throughput, and error rate, facilitating quick analysis of test data.

[0107] S26: Send the corresponding load test scripts and single-region single-service files and single-region multi-service files to each load tester.

[0108] Step S26 is used to batch synchronize the load testing script and the tax data required to complete the load testing to all load test nodes to complete the preparation work before the load test is carried out.

[0109] As described above, firstly, this embodiment provides a cross-platform intelligent adaptation solution. It can identify the hardware architecture and system version of the pressure machine and provide compatible component installation packages to complete environment deployment and parameter configuration. This embodiment solves the current technical problems of cross-platform adaptation relying on manual intervention, high error rates, and frequent rework, completely avoiding deployment failures caused by incompatible installation packages under different architectures.

[0110] Secondly, this embodiment also provides a multi-threaded concurrent deployment scheme based on SSH. It enables batch remote command delivery via the SSH protocol, coupled with a multi-threaded concurrent execution mechanism, supporting the simultaneous deployment of ≤50 load servers. Efficiency increases linearly with the number of servers, with deployment time for 10 provincial-level load servers ≤30 minutes. This solution fundamentally addresses the technical problems of low deployment efficiency and difficulty in adapting to large-scale deployments of provincial-level distributed clusters in existing technologies. Compared to manual deployment one machine at a time (10 machines require 2-3 hours), deployment efficiency is improved by over 80%.

[0111] Thirdly, this embodiment provides a pre-defined standardized configuration scheme. It completes configuration tasks such as environment variable configuration, Grafana data source integration, and JMeter Dashboard template import, based on the hardware architecture and system version and built-in unified configuration rules. Simultaneously, it optimizes key load testing parameters according to the hardware configuration. This fundamentally solves the technical problems of error-prone manual configuration, inconsistent component versions, and poor consistency across multi-machine environments, ensuring uniform configuration across all load testing nodes and avoiding load testing deviations caused by environmental differences.

[0112] Furthermore, this embodiment also provides an optional implementation scheme based on the above embodiments. The above method further includes:

[0113] S271: Monitor the execution status of each press in response to received instructions.

[0114] S272: If a network interruption, component installation failure, or configuration error occurs, repeat the corresponding steps S22, S24, or S25.

[0115] In this embodiment, network interruption corresponds to step S22, component installation failure corresponds to step S24, and configuration error corresponds to step S25. Furthermore, this embodiment does not limit the number of retry attempts; the number of retry attempts for each failure type can be the same or different, and the specific value of the number of retry attempts is also not limited. In one optional embodiment, the number of retries for each failure type is 2.

[0116] S273: Obtain the deployment results of each pressure machine and generate the corresponding deployment report.

[0117] This embodiment provides an automated fault self-healing solution. It monitors the execution status of each node in real time throughout the entire deployment process on the stress tester. For issues such as component download failures, configuration anomalies, and network interruptions, a retry mechanism is automatically triggered (two retries by default), and detailed fault logs are output. The core objective is to solve the current technical problems of fault handling relying on manual intervention, time-consuming troubleshooting, and poor fault tolerance, thereby reducing the cost of manual intervention and improving deployment stability and success rate.

[0118] It should also be noted that the above embodiments pertain to the stress testing deployment phase of the current stress testing process for new power grids. The methods and steps provided in the above embodiments can be implemented by writing an automated script, install.sh (a shell script file).

[0119] On the other hand, the stress test process for the new power grid also includes a user simulation phase. This phase requires generating a corresponding token for each user, allowing the stress tester to simulate the user's tax filing behavior. This application also provides a suitable embodiment for generating these tokens. Figure 3 As shown, the above method also includes:

[0120] S31: Generate a list of taxpayer IDs by importing taxpayer IDs from various tax data fields.

[0121] S32: Configure key parameters through the JMeter Arguments component; among which, key parameters include: authentication parameters, encryption parameters, and interface address.

[0122] JMeter Arguments: A component of JMeter primarily used for parameterized testing. This component allows different parameter values ​​to be provided for different threads or loop iterations, thereby simulating more realistic user behavior.

[0123] S33: Use Setup Thread Group and HTTP request sampler to batch call the unified identity management platform interface to generate tokens.

[0124] Setup Thread Group: This is a special type of thread group used to perform pre-setup operations, such as initializing data or the environment, before the test begins.

[0125] HTTP: Hypertext Transfer Protocol.

[0126] S34: Persist the token to local storage via the BeanShell post-processor.

[0127] BeanShell is a Java-like scripting language used in JMeter to write custom logic, enabling flexible data processing and assertions.

[0128] S35: Establish the association between each token and the load testing script.

[0129] Furthermore, as can be seen from the above embodiments, this method supports organizing tax data according to single-region single-business and single-region multi-business multiple scenarios. Therefore, regarding how to generate corresponding tokens for single-region single-business files and single-region multi-business files organized based on this method, this application also provides a further embodiment. Step S33 specifically includes:

[0130] S331: For each tax data field in a single-region, single-business file: allocate a first region for storing the generated tokens; create a dedicated parameter group for the first region; generate tokens for each tax data field in the corresponding single-region, single-business file through a single thread group, and store each token in the first region as a token file based on the dedicated parameter group.

[0131] S332: For each tax data field in a single-region, multi-business file: allocate a second area to store the generated tokens; create a general parameter group for the second area; generate tokens for tax data fields corresponding to different declaration types in the single-region, multi-business file through multiple thread groups; merge the tokens corresponding to different declaration types into a unified token file through the BeanShell post-processor, and store it in the second area based on the general parameter group.

[0132] This embodiment provides two corresponding token generation logics for single-region, single-business scenarios and single-region, multi-business scenarios, respectively. Different independent business thread groups can be configured as needed to address the testing requirements of different business types. Specifically, for the single-region, single-business scenario: a "fixed parameter configuration + single thread group" mode is adopted. A dedicated parameter group for the first region is created, configuring region-specific parameters such as authentication, encryption, and interface address. Token data for this scenario is generated and stored through a single business thread group. For the single-region, multi-business scenario: a "single-region parameter isolation + multi-thread group concurrency" mode is adopted. A general parameter group for the corresponding region is created, and multiple independent business thread groups (corresponding to different business types) are configured simultaneously. The BeanShell post-processor merges the multiple business tokens into a unified output file.

[0133] Furthermore, to further simplify the token generation logic and improve token generation efficiency, this embodiment provides a further implementation scheme based on the above embodiment. Step S332: Generating tokens for each tax data field in a single business file corresponding to a single region through a single thread group includes:

[0134] S3321: Read the token file stored in the second area.

[0135] S3322: Identify the declaration type field for each token in the token file.

[0136] As mentioned above, the token file can be implemented using a CSV file. By identifying the header information of the CSV file, the application type field (sqbh, i.e., the business application number) can be obtained.

[0137] S3323: Group each token according to the declaration type field to generate multiple token files corresponding to different declaration types; wherein, the generated token files are named according to the corresponding declaration type field value.

[0138] S3324: Store the generated token files in the first area.

[0139] In other words, this embodiment generates a token for a single region and a single business scenario after generating a token for the first time. This generation requires only simple field identification and matching, without the need for complex additional generation logic. Furthermore, this generation scheme utilizes streaming processing technology, supporting the splitting of token files containing millions of data points at a time, with a splitting speed of ≤1 minute / 100,000 records, and the splitting of 4160 records taking ≤5 seconds.

[0140] Furthermore, based on the above embodiments, this embodiment also provides an optional further solution, wherein after step S3322, the method further includes:

[0141] S3325: If multiple tokens have the same declaration type field value, only the most recently generated token will be retained, and the rest will be deleted.

[0142] This embodiment automatically checks and removes duplicate token records under the same sqbh during the splitting process, retaining only the latest valid record. This effectively avoids duplicate requests during load testing, thereby further improving the accuracy of load testing.

[0143] Furthermore, this embodiment provides an optional further solution based on the above embodiment. When generating a token through a thread group in the above steps S331 and S332, it further includes: if the number of threads started at the same time exceeds a preset thread threshold, then each thread is started in batches through a preset thread group gradient start strategy.

[0144] In the above embodiment, the dynamic adjustment of the JMeter thread group concurrency can flexibly support token generation requirements of ≤10,000 concurrent requests. This embodiment also employs a thread group gradient startup strategy to effectively avoid overloading the unified identity management platform interface.

[0145] On the other hand, the validity period of current identity authentication tokens is limited (generally 2 hours), so it is necessary to repeatedly refresh the token's validity period to ensure that the token remains valid during load testing. Currently, the common token refresh solution is to use a Python script with manual assistance. The Python script calls the unified identity management platform interface to generate the token, but this only supports ≤100 concurrent requests, and requires manual recording of the token generation time and manual replacement of the token in the load testing script every 2 hours. This results in a load testing interruption rate ≥40%, making it impossible to reproduce peak scenarios with tens of thousands of concurrent requests. To solve this technical problem, this application also provides a suitable embodiment, in which the above method further includes:

[0146] S36: Create a token refresh thread group.

[0147] The token refresh thread group is used to: query the validity period of each token every first cycle; if the remaining validity period is less than the preset validity threshold, refresh the corresponding token. It should be noted that this embodiment does not limit the specific duration of the first cycle and the validity threshold. However, both the first cycle and the validity threshold should be less than the maximum validity period of the token (such as 2 hours as mentioned above). In an optional embodiment, the first cycle and the validity threshold are the same value (such as 30 minutes) to ensure that the token can be periodically queried and refreshed before it expires.

[0148] This embodiment utilizes a dedicated token refresh thread group, which performs the following operation every 30 minutes: automatically querying and refreshing tokens that are about to expire (validity period ≤ 30 minutes), thereby ensuring that all tokens remain valid. Furthermore, this embodiment uses a thread group to monitor and refresh tokens, supporting the simulation of tens of thousands of users in a single region under single / multi-service scenarios. It achieves "zero-code" configuration using visual components, with a stress test interruption rate of ≤ 1%, lowering the technical threshold while ensuring performance and stability.

[0149] On the other hand, the stress testing process for new power grids also includes a results analysis phase. This application also provides a suitable embodiment on how to improve the automation level of this phase and replace manual labor in completing more test analysis tasks. For example... Figure 4 As shown, the above method also includes:

[0150] S41: Obtain performance metrics for each stress tester during the stress test process. These performance metrics include: response time, throughput, error rate, and server resource utilization (such as CPU, memory, disk I / O, network bandwidth, and other server resources).

[0151] S42: Analyze whether each press has a performance bottleneck based on performance indicators, and compare trends with historical baseline data to generate corresponding pressure test results.

[0152] Specifically, performance bottlenecks can be identified by recognizing abnormal fluctuations in response time, exceeding error rate thresholds, and excessive resource consumption. Furthermore, by comparing trends with historical baseline data, the differences between current and historical performance metrics can be clearly distinguished, thus accurately pinpointing system performance weaknesses.

[0153] S43: Based on the stress test results, retrieve the corresponding optimization suggestions from the optimization knowledge base.

[0154] Specifically, as described in step S42 above, after identifying specific performance bottlenecks and determining the performance indicators considered to be performance bottlenecks, corresponding optimization suggestions can be retrieved from a pre-set optimization knowledge base. The optimization knowledge base can pre-store various performance problems that the load tester may encounter (such as slow database queries, high network latency, application layer processing bottlenecks, etc.) and their corresponding optimization suggestions (such as SQL statement optimization, index adjustment, caching strategy optimization, resource expansion solutions, etc.).

[0155] S44: Visualize stress test results and optimization suggestions, and generate a stress test report containing stress test results and optimization suggestions for local storage.

[0156] Therefore, this embodiment can replace manual analysis of stress test results, identifying performance bottlenecks and shortcomings of the pressure machine during the stress test and displaying them visually. It can also match corresponding optimization suggestions to the testers, facilitating precise location and effective troubleshooting of specific performance issues, improving the efficiency of the entire stress test analysis phase, and lowering the barrier to entry.

[0157] The foregoing has provided a detailed description of a testing method for a new power grid system. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

[0158] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A testing method for new power grid systems, characterized in that, include: Read and parse the original data file to obtain tax data fields; wherein, the original data file stores various tax data in a preset template format; the tax data includes: taxpayer ID, location, and declaration type; there is an association between the taxpayer ID, location, and declaration type stored according to the preset template, and a group of taxpayer ID, location, and declaration type constitutes a tax data field; Using the taxpayer ID as a unique identifier, each of the tax data fields is traversed. Based on the location and the declaration type, each of the tax data fields is organized according to the single-region single-business model and the single-region multi-business model, respectively, to obtain the single-region single-business file and the single-region multi-business file. The single-region single-service file and the single-region multi-service file are output according to their respective preset directory structures.

2. The testing method for new power grid systems according to claim 1, characterized in that, The tax data also includes: records of declaration results; After obtaining the tax data fields, the following is also included: Invalid data in the tax data fields are removed according to preset filtering rules; The filtering rules include one or more of the following: duplicate tax data fields, missing tax data in the tax data fields, taxpayer ID is a deregistered enterprise, taxpayer ID is an abnormal taxpayer, taxpayer ID and location are mismatched, the location has not opened the business corresponding to the declaration type, and the declaration result record is failed.

3. The testing method for new power grid systems according to claim 2, characterized in that, The original data file is in .xlsx or .xls format. After removing invalid data from the tax data field according to preset filtering rules, this method further includes: Convert the filtered and compliant tax data fields into CSV format.

4. The testing method for new power grid systems according to claim 1, characterized in that, Also includes: Obtain the IP list of each press; Establish network connections with each of the presses through the IP list, and detect the hardware architecture and operating system of each press; Based on the hardware architecture and operating system, version compatibility checks are performed on each of the stress testers, and the corresponding component installation packages and stress test scripts are matched. The system executes shell commands in batches based on the SSH protocol and initiates component installation operations to multiple stress machines synchronously through a multi-threaded concurrency mechanism. The components used to complete the stress test are installed through the component installation package. Configure environment variables, data sources, and JMeter Dashboard templates for each stress tester according to preset configuration rules, and optimize stress test parameters according to hardware configuration; The corresponding load test script, the single-region single-service file, and the single-region multi-service file are sent to each of the load testers.

5. The testing method for new power grid systems according to claim 4, characterized in that, Also includes: Monitor the execution status of each press in response to the received instructions; In the event of network interruption, component installation failure, or configuration anomaly, the following steps are repeated: establishing network connections with each of the pressure machines via the IP list; executing shell commands in batches based on the SSH protocol and simultaneously initiating component installation operations to multiple pressure machines through a multi-threaded concurrency mechanism; or configuring environment variables, data sources, and JMeter Dashboard templates for each pressure machine according to preset configuration rules, and optimizing stress test parameters according to hardware configuration; wherein, when the number of repetitions exceeds a preset retry threshold, retrying stops, and the corresponding fault log is output; Obtain the deployment results of each pressure machine and generate the corresponding deployment report.

6. The testing method for new power grid systems according to claim 4, characterized in that, Also includes: By importing the taxpayer IDs from each of the aforementioned tax data fields, a list of taxpayer IDs is generated; Configure key parameters through the JMeter Arguments component; the key parameters include: authentication parameters, encryption parameters, and interface address; Utilize Setup Thread Group and HTTP request sampler to batch call the unified identity management platform interface to generate tokens; The token is persistently stored locally using the BeanShell post-processor; Establish the association between each token and the load testing script.

7. The testing method for new power grid systems according to claim 6, characterized in that, The step of using SetupThread Group and HTTP request sampler to batch call the unified identity management platform interface to generate tokens includes: For each of the tax data fields in the single-region single-business file: allocate a first region for storing the generated tokens; create a dedicated parameter group for the first region; generate tokens corresponding to each of the tax data fields in the single-region single-business file through a single thread group, and store each token in the first region as a token file based on the dedicated parameter group; For each of the tax data fields in the single-region multi-business file: allocate a second area for storing the generated tokens; create a general parameter group for the second area; generate tokens for the tax data fields corresponding to different declaration types in the single-region multi-business file through multiple thread groups; merge the tokens corresponding to different declaration types into a unified token file through the BeanShell post-processor, and store it in the second area based on the general parameter group.

8. The testing method for new power grid systems according to claim 7, characterized in that, The step of generating tokens corresponding to each tax data field in the single business file of the single region through a single thread group includes: Read the token file stored in the second area; Identify the declaration type field of each token in the token file; The tokens are grouped according to the declaration type field to generate multiple token files corresponding to different declaration types; wherein, the generated token files are named according to the corresponding declaration type field value. The generated token files are stored in the first area.

9. The testing method for new power grid systems according to claim 8, characterized in that, After identifying the declaration type field of each token in the token file, the method further includes: If multiple tokens have the same declaration type field value, only the most recently generated token will be retained, and the rest will be deleted.

10. The testing method for new power grid systems according to claim 7, characterized in that, When generating a token through the thread group, the following is also included: If the number of threads started simultaneously exceeds the preset thread threshold, the threads will be started in batches using a preset thread group gradient startup strategy.

11. The testing method for new power grid systems according to claim 6, characterized in that, Also includes: Create a token refresh thread group; The token refresh thread group is used to: query the validity period of each token every first cycle; If the remaining validity period is less than the preset validity threshold, then the corresponding token is refreshed.

12. The test method for new power grid systems according to any one of claims 1 to 11, characterized in that, Also includes: Obtain the performance metrics of each pressure machine during the pressure test process; wherein, the performance metrics include: response time, throughput, error rate, and server resource utilization. Based on the performance indicators, analyze whether each press has a performance bottleneck, and compare the trend with historical baseline data to generate corresponding pressure test results; Based on the stress test results, retrieve the corresponding optimization suggestions from the optimization knowledge base; The stress test results and optimization suggestions are displayed in a visual manner, and a stress test report containing the stress test results and optimization suggestions is generated and stored locally.

Images