System and method for testing comprehensive performance of software

Abstract

The invention discloses a system and a method for testing comprehensive performance of software. The system comprises a front-end interaction module based on Vue.js, a back-end service module based on Node.js, a test scheduling and scoring module and a data storage module. The front-end interaction module provides a unified operation interface; the back-end service module processes a test task through an API interface, calls a test tool by using a sub-process and analyzes original data; the test scheduling and scoring module supports a comprehensive and single test mode, has a historical data reuse prompt function in the comprehensive mode, configures weight for each test item, and calculates a comprehensive score based on a test result and a preset threshold value; and the data module adopts an SQLite database to store various test data. Integrated management, automatic scheduling and intelligent evaluation of various test tools are realized, and the test efficiency and the result analyzability are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of computer software, and in particular to a system and method for comprehensive software performance testing. Background Technology

[0002] In the software development process, performance testing is a crucial step in ensuring that software systems possess good stability, rapid response capabilities, and efficient resource utilization in production environments. By simulating different load conditions, performance testing can effectively reveal potential bottlenecks and performance defects in the system, providing vital data support for the development team to optimize code and adjust system architecture, thereby ensuring that the software product provides users with stable and efficient services.

[0003] Currently, the industry offers a variety of performance testing tools, covering multiple specialized areas such as overall system performance evaluation (e.g., UnixBench), disk I / O (e.g., Fio), network bandwidth (e.g., Iperf), and memory bandwidth (e.g., Stream). However, these traditional tools have significant limitations in practical applications. First, they are typically independent and fragmented command-line tools, requiring testers to manually perform complex configurations and executions, a process that is cumbersome and prone to errors. The significant differences in configuration syntax and parameters between different tools impose a heavy learning burden and operational cost on testers. Second, test results are often output in raw, unstructured text format, lacking a unified mechanism for collection, management, and analysis, making it difficult for developers to form an intuitive and comprehensive overall evaluation of the software's performance.

[0004] Furthermore, existing technical solutions severely lack the ability to effectively integrate and automate the scheduling of multiple testing tools. These tools operate independently and cannot work together to complete a comprehensive performance evaluation process. In today's rapidly iterating agile development model, the frequent need for performance regression testing makes this traditional method, which relies on manual sequential operations, inefficient and unable to keep pace with development. Summary of the Invention

[0005] This application provides a system and method for comprehensive software performance testing, which solves the problems of traditional performance testing tools being cumbersome to operate, having scattered results, and lacking unified analysis capabilities.

[0006] In a first aspect, this application provides a system for comprehensive software performance testing, comprising: Front-end interaction module, back-end service module, test scheduling and scoring module, and data storage module; The front-end interaction module, built on Vue.js, provides an interactive interface for selecting testing tools, configuring test parameters, starting test tasks, displaying test progress, visualizing test results, and downloading log files. The backend service module, built on Node.js, provides API interfaces to process test tasks sent by the frontend interaction module. Through a subprocess of Node.js, it calls the testing tools to execute each test item in the test task; it obtains the raw data output by the testing tools and parses the raw data into structured test results. The test scheduling and scoring module is used to manage the test process of test tasks, and supports comprehensive test mode and single test mode; in single test mode, test items are executed directly according to the user's selection. In the comprehensive test mode, check whether there is historical result data corresponding to the test task in the data storage module; if there is historical result data, send a reuse prompt to the user; if the user chooses not to reuse historical result data or there is no historical result data, execute the test items corresponding to the test task in a preset order. Configure weight parameters for each test item, and calculate and generate comprehensive score data corresponding to the test task based on the test results, preset performance thresholds and weight parameters; The data storage module uses the lightweight relational database SQLite to store test results, log files, weight parameters, comprehensive score data, and historical result data.

[0007] Secondly, this application provides a method for comprehensive software performance testing, including: It receives test instructions from users through the front-end interactive interface and generates corresponding test tasks based on the test instructions; the test instructions include the test tools, test parameters and target test mode selected by the user; If the target test mode is a comprehensive test mode, check if there is historical result data corresponding to the test task in the data storage module; if there is historical result data, send a reuse prompt to the user. If the user chooses not to reuse historical result data or there is no historical result data, the backend service module calls the testing tool to execute each test item in the test task in a preset order. The backend service module obtains the raw data output by the testing tool and parses the raw data into structured test results. Configure weight parameters for each test item, and calculate and generate comprehensive score data corresponding to the test task based on the test results of each test item, the preset performance threshold and weight parameters.

[0008] This application provides a self-inspection and auditing system and method for code applications, including a front-end interaction module, a back-end service module, a test scheduling and scoring module, and a data storage module. The front-end interaction module, built on Vue.js, provides an interactive interface for selecting testing tools, configuring test parameters, starting test tasks, displaying test progress, visualizing test results, and downloading log files. The back-end service module, built on Node.js, provides an API interface to process test tasks sent by the front-end interaction module, and through a Node.js subprocess, calls testing tools to execute various test items in the test tasks; it also obtains the raw data output by the testing tools and parses the raw data into structured test results. The test scheduling and scoring module manages the test tasks. The testing process supports both comprehensive testing and single-item testing modes. In single-item testing mode, test items are executed directly based on user selection. In comprehensive testing mode, the system checks the data storage module for historical result data corresponding to the test task. If historical result data exists, a reuse prompt is sent to the user. If the user chooses not to reuse historical result data or if historical result data does not exist, the test items corresponding to the test task are executed in a preset order. Weight parameters are configured for each test item, and comprehensive score data corresponding to the test task is calculated and generated based on test results, preset performance thresholds, and weight parameters. The data storage module uses a lightweight relational database, SQLite, to store test results, log files, weight parameters, comprehensive score data, and historical result data. It achieves unified integrated management and automated scheduling execution of various performance testing tools. Through an intelligent historical data reuse mechanism and a scientific scoring system based on weight thresholds, it transforms scattered raw test data into intuitive and quantifiable comprehensive performance evaluation indicators, significantly improving the efficiency and analyzability of software performance testing results.

[0009] The further effects of the aforementioned non-conventional preferred method will be explained below in conjunction with specific embodiments. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application or the existing technical solutions, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This application provides a schematic diagram of the structure of a system for comprehensive software performance testing, as shown in one embodiment. Figure 2 A schematic diagram of the structure of a front-end interaction module in a system for comprehensive software performance testing, provided as an embodiment of this application; Figure 3 A schematic diagram of the structure of a backend service module in a system for comprehensive software performance testing, provided as an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a test scheduling and scoring module in a system for comprehensive software performance testing, provided in an embodiment of this application; Figure 5 This is a flowchart illustrating a method for comprehensive software performance testing according to an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] In the software development process, performance testing is a crucial step in ensuring that software systems possess good stability, rapid response capabilities, and efficient resource utilization in production environments. By simulating different load conditions, performance testing can effectively reveal potential bottlenecks and performance defects in the system, providing vital data support for the development team to optimize code and adjust system architecture, thereby ensuring that the software product provides users with stable and efficient services.

[0014] Currently, the industry offers a variety of performance testing tools, covering multiple specialized areas such as overall system performance evaluation (e.g., UnixBench), disk I / O (e.g., Fio), network bandwidth (e.g., Iperf), and memory bandwidth (e.g., Stream). However, these traditional tools have significant limitations in practical applications. First, they are typically independent and fragmented command-line tools, requiring testers to manually perform complex configurations and executions, a process that is cumbersome and prone to errors. The significant differences in configuration syntax and parameters between different tools impose a heavy learning burden and operational cost on testers. Second, test results are often output in raw, unstructured text format, lacking a unified mechanism for collection, management, and analysis, making it difficult for developers to form an intuitive and comprehensive overall evaluation of the software's performance.

[0015] Furthermore, existing technical solutions severely lack the ability to effectively integrate and automate the scheduling of multiple testing tools. These tools operate independently and cannot work together to complete a comprehensive performance evaluation process. In today's rapidly iterating agile development model, the frequent need for performance regression testing makes this traditional method, which relies on manual sequential operations, inefficient and unable to keep pace with development.

[0016] To address this issue, embodiments of this application propose a system for comprehensive software performance testing, aiming to solve the problems of traditional performance testing tools being cumbersome to operate, having scattered results, and lacking unified analysis capabilities. See also Figure 1 The image shows a specific embodiment of the system for comprehensive software performance testing provided in this application. In this embodiment, the system for comprehensive software performance testing includes: a front-end interaction module 101, a back-end service module 102, a test scheduling and scoring module 103, and a data storage module 104.

[0017] The system adopts a front-end and back-end separation architecture. The front-end user interface is built using Vue.js, and the back-end service is built using Node.js, enabling unified management and automated scheduling of various performance testing tools. The various modules of the system interact with each other through standardized API interfaces, forming a complete performance testing loop. From test task initiation, execution, and monitoring to result analysis and scoring, the entire process is automated, greatly improving the efficiency and reliability of performance testing.

[0018] The front-end interaction module 101, built on Vue.js, provides an interactive interface for selecting testing tools, configuring testing parameters, starting testing tasks, displaying testing progress, visualizing test results, and downloading log files.

[0019] The front-end interaction module 101 serves as a bridge between the system and the user. Adopting a component-based design, it transforms complex testing processes into an intuitive and user-friendly graphical interface. Users do not need to master the command-line syntax of the underlying testing tools; they can complete complex performance testing tasks simply through clicks and configurations. The interface features a responsive design, providing real-time feedback on test progress and presenting test results in various visualization formats, making the interpretation of performance data more intuitive and efficient.

[0020] The front-end interaction module 101 includes: a tool selection unit 1011, a test control unit 1012, a progress display unit 1013, and a result display unit 1014. For example... Figure 2 The diagram shown is a structural schematic of the front-end interaction module 101 in the system used for comprehensive software performance testing in this embodiment.

[0021] The tool selection unit 1011, test control unit 1012, progress display unit 1013, and result display unit 1014 each perform their respective functions while cooperating with each other, forming a complete user interaction process. From tool selection and parameter configuration in the test preparation phase, to progress monitoring in the test execution phase, and then to result display and data export after the test is completed, the entire process is seamlessly connected in a unified interface, providing users with a one-stop testing operation experience.

[0022] The tool selection unit 1011 is implemented using a checkbox component to provide single or multiple selection of test tools; the test tools include a system overall performance evaluation tool, a disk I / O performance test tool, a network bandwidth performance test tool, and a memory bandwidth test tool.

[0023] The tool selection unit 1011 supports flexible test combination strategies. Users can choose to perform single-dimensional specialized tests or select multiple tools for comprehensive performance evaluation based on actual testing needs. The status of the checkbox component is fed back to the system in real time, ensuring that the subsequent parameter configuration interface can be dynamically adjusted, displaying only configuration items related to the selected tool, thus avoiding redundancy and clutter in the interface information.

[0024] The test control unit 1012 includes a configuration input box and a test start button. The configuration input box is used to receive user-defined test parameters. The test start button is used to trigger the execution of the test task. After clicking the test start button, the selected test tool and test parameters are sent to the backend service module 102.

[0025] The configuration input field offers differentiated parameter settings for different testing tools. For example, for disk I / O testing, parameters such as block size, read / write mode, and test duration can be configured; for network bandwidth testing, parameters such as target server address, transmission protocol, and concurrent connections can be set. The system performs real-time validation of user-input parameters to ensure the correctness and reasonableness of the parameter format. When the user clicks the test start button, the front-end module encapsulates all configuration information into a standardized data packet and sends it to the back-end service module 102 via an HTTP request. Simultaneously, the interface immediately switches to test progress monitoring mode, providing the user with a smooth operating experience.

[0026] The progress display unit 1013 is implemented using a progress bar component and is used to receive the test progress pushed by the backend service module 102.

[0027] The progress display unit 1013 continuously acquires the execution status of test tasks through a real-time communication mechanism between the front-end and back-end. The progress bar not only displays the overall test completion percentage but also shows detailed information such as the name of the specific test project currently being executed, the number of completed test items, and the estimated remaining time. For comprehensive testing mode, the progress bar displays the execution progress of each testing tool in segments, allowing users to clearly understand the progress of the entire testing process. This real-time feedback mechanism effectively avoids user anxiety during the waiting process and improves the system's user experience.

[0028] The results display unit 1014 includes a table component and a visualization chart component. The table component is used to display the performance index data of each test item in a list format. The visualization chart component is used to display the comprehensive score data and the score distribution of each test item in a graphical way, and provides a download button for the log file.

[0029] The table component employs pagination and sorting features, clearly presenting detailed metrics for each test item, such as UnixBench's system call performance and process creation performance, and Fio's random read / write IOPS and sequential read / write bandwidth. The visualization chart component uses various chart formats, including radar charts and bar charts, transforming abstract performance data into intuitive visual presentations, allowing users to easily identify the system's performance strengths and weaknesses. Furthermore, the results display unit 1014 provides test result export functionality, allowing users to export data to CSV or Excel formats for further analysis and report writing. The log file download function preserves the complete original test output, meeting the needs of professional users for in-depth analysis.

[0030] Backend service module 102, built on Node.js, provides API interfaces to process test tasks sent by the frontend interaction module. Through a subprocess of Node.js, it calls the test tool to execute each test item in the test task; it obtains the raw data output by the test tool and parses the raw data into structured test results.

[0031] Backend service module 102 leverages Node.js's asynchronous and non-blocking features to efficiently handle multiple concurrent test requests. The module interacts with the operating system's underlying performance testing tools through the `child_process` mechanism, ensuring native test execution performance and avoiding additional performance overhead. Simultaneously, backend service module 102 implements compatibility handling for various test tool output formats, transforming the originally inconsistent and unusable raw data into unified structured data, laying the foundation for subsequent data analysis and scoring calculations.

[0032] The backend service module 102 includes: an interface unit 1021, a business logic processing unit 1022, and a data parsing unit 1023. For example... Figure 3 The diagram shown is a structural schematic of the backend service module 102 in the system used for comprehensive software performance testing in this embodiment.

[0033] The interface unit 1021, business logic processing unit 1022, and data parsing unit 1023 constitute the three-tier architecture of the backend service. The interface unit 1021 is responsible for receiving and responding to requests, the business logic processing unit 1022 is responsible for implementing core functions, and the data parsing unit 1023 is responsible for cleaning and transforming raw data. This layered design gives the system good maintainability and scalability. When it is necessary to add testing tools or modify data processing logic, only the code at the corresponding layer needs to be adjusted, without affecting the normal operation of other modules.

[0034] Interface unit 1021 includes a test execution interface, a result query interface, and a log download interface; the test execution interface is used to receive test task execution requests, the result query interface is used to query historical result data, and the log download interface is used to provide log file download services.

[0035] Interface unit 1021 adopts the RESTful API design specification, receiving test configuration information sent by the frontend via the POST method and returning a unique identifier for the test task. The frontend can use this identifier for subsequent progress queries and result retrieval. The result query interface supports multiple query conditions, allowing users to search historical test records by test time, test type, test environment, and other dimensions, facilitating longitudinal comparative analysis. The log download interface provides a secure file transfer mechanism, ensuring that users can completely obtain all log files generated during the test, including standard output, error output, and detailed reports generated by the tool itself.

[0036] The business logic processing unit 1022 is used to handle the execution logic of test tasks. It creates child processes through the child_process module of Node.js, calls the shell script to start the test tool, and obtains raw data by listening to the standard output stream and standard error stream of the child process.

[0037] The business logic processing unit 1022 dynamically generates corresponding Shell commands based on the configuration information transmitted by the front-end interaction module 101, and executes them in an isolated sub-process. By monitoring the output stream of the sub-process, the business logic processing unit 1022 can capture the running status and output information of the testing tool in real time, and asynchronously push the progress information to the front end, realizing transparency in the testing process. Simultaneously, the business logic processing unit 1022 also implements a robust exception handling mechanism. When the testing tool fails or times out, it can promptly capture error information, terminate the abnormal process, and provide detailed error reasons to the user, avoiding waste of system resources and blockage of the testing process.

[0038] The data parsing unit 1023 is used to standardize the raw data and encapsulate the raw data into test results in JSON format.

[0039] The data parsing unit 1023 implements specialized parsing logic tailored to the output characteristics of each testing tool. For example, the output of UnixBench contains a large amount of text descriptions and formatted tables. The data parsing unit 1023 uses regular expressions and text parsing algorithms to accurately extract the values ​​of various performance indicators. The output of Fio is presented in JSON format, and the data parsing unit 1023 directly performs JSON parsing and extracts key fields.

[0040] Through this standardization process, the originally inconsistent test results are uniformly converted into well-structured JSON objects. Each object contains complete information such as the test item name, performance indicator name, test value, and unit, providing a unified data model for subsequent data storage, querying, and analysis.

[0041] The test scheduling and scoring module 103 manages the test process for test tasks, supporting both comprehensive testing and single-item testing modes. In single-item testing mode, it directly executes test items based on user selection. In comprehensive testing mode, it checks whether historical result data corresponding to the test task exists in the data storage module 104. If historical result data exists, it sends a reuse prompt to the user. If the user chooses not to reuse historical result data or if historical result data does not exist, it executes the test items corresponding to the test task in a preset order. It configures weight parameters for each test item and calculates and generates comprehensive score data corresponding to the test task based on the test results, preset performance thresholds, and weight parameters.

[0042] The test scheduling and scoring module 103 not only coordinates the execution order of various testing tools, but also implements an intelligent reuse mechanism for historical data, avoiding time waste caused by repeated testing. Furthermore, the test scheduling and scoring module 103 introduces a scoring algorithm that normalizes and weights multi-dimensional performance data into a single comprehensive score, making performance test results from different systems and at different times comparable and providing a quantitative evaluation standard for performance optimization.

[0043] The test scheduling and scoring module 103 includes: a history check unit 1031, a sequential execution unit 1032, a weight configuration unit 1033, and a comprehensive scoring unit 1034. For example... Figure 4 The diagram shown is a structural schematic of the test scheduling and scoring module 103 in the system used for comprehensive software performance testing in this embodiment.

[0044] The historical inspection unit 1031, sequential execution unit 1032, weight configuration unit 1033, and comprehensive scoring unit 1034 work together to achieve fully automated management of the entire test task process, from scheduling and execution to scoring. The historical inspection unit 1031 makes intelligent judgments before the test begins, the sequential execution unit 1032 ensures the orderly progress of the test process, the weight configuration unit 1033 provides flexible scoring strategies, and the comprehensive scoring unit 1034 transforms complex performance data into easily understandable scoring results, together forming an efficient and intelligent test management system.

[0045] The historical inspection unit 1031 is used to query the data storage module 104 in the comprehensive test mode to retrieve historical result data that matches the test task; determine whether the historical result data meets the reuse conditions; and if it meets the reuse conditions, send a reuse prompt to the user.

[0046] The history checking unit 1031 uses a matching algorithm to retrieve historical records in the data storage module 104 that have the same test environment and test parameters as the current test task. Because repeated tests in a short period of time often yield similar results when the test environment and configuration have not changed, historical result data can be directly reused, thereby saving test time.

[0047] When reusable historical results data is detected, the system will display a prompt on the front-end interface, showing detailed information about the historical test's time, environment, and main results, allowing users to decide whether to adopt it. Users can choose to directly reuse the historical results data or re-execute the test to obtain the latest results. This human-computer interaction design ensures efficiency while preserving the user's decision-making power.

[0048] Determine the historical test time, historical test environment, and historical parameters corresponding to the historical result data; if the time difference between the historical test time and the current time is within the preset validity period, and the historical test environment is consistent with the current test environment, and the historical parameters are the same as the test parameters, then the historical result data is determined to meet the reuse conditions.

[0049] Specifically, the system checks the timestamps of historical tests to determine if they are within a preset validity period, such as 24 or 72 hours. Historical results data exceeding this validity period are not considered reusable. The test environment consistency check includes key elements such as operating system version, hardware configuration, and system load, ensuring that historical tests and current tests are conducted under the same baseline conditions. The comparison of test parameters checks the configuration parameters of each tool item by item; only when all parameters match perfectly is the historical results data considered reusable. This matching mechanism guarantees the validity and accuracy of reused data, avoiding evaluation biases caused by environmental differences.

[0050] The sequential execution unit 1032 is used to call the backend service module 102 to execute each test item in a preset order when the user selects not to reuse historical result data or when there is no historical result data.

[0051] The sequential execution unit 1032 maintains a test task queue and arranges the execution order reasonably according to the characteristics and dependencies of the testing tools. For example, the overall system performance evaluation may need to be performed in a relatively idle system state, so it will be given priority; while network bandwidth testing may depend on external server resources and will be appropriately delayed.

[0052] The sequential execution unit 1032 monitors the execution status of each test item in real time during the scheduling process. Once a test is completed, the next test is started immediately to ensure the continuity of the entire process. Simultaneously, the sequential execution unit 1032 also implements an error isolation mechanism. Even if a test item fails, it will not affect the normal execution of subsequent tests. The failed item will be marked in the test report, and detailed error information will be provided for user troubleshooting.

[0053] The weight configuration unit 1033 is used to configure weight parameters for each test item.

[0054] The weight configuration unit 1033 provides a flexible weight setting mechanism, allowing users to adjust the weight ratio of different test dimensions according to the actual application scenario and focus. For example, for database servers, disk I / O performance may be the most critical indicator, so its weight can be set to 40%, while the weight of network bandwidth performance can be appropriately reduced to 20%; for web servers, network bandwidth and overall system performance may be more important, so the weights can be allocated to 30% each.

[0055] The system typically comes pre-loaded with weight templates for several common application scenarios, such as "General Scenarios" (balanced weighting, 25% for each), "Computationally Intensive" (high CPU performance weighting), and "I / O Intensive" (high disk performance weighting). Users can choose these directly or customize the weight configuration. The weight configuration supports real-time saving and historical review, allowing users to use consistent scoring standards across different test rounds and ensuring the comparability of test results.

[0056] The comprehensive scoring unit 1034 is used to obtain the test results corresponding to each test item, normalize each test result according to the performance threshold to obtain a single score, and perform weighted summation of each single score according to the weight parameters to generate comprehensive score data.

[0057] The comprehensive scoring unit 1034 first obtains the raw data of each test item from the data storage module 104, and then compares it with the preset performance threshold. The performance threshold is a benchmark value set according to industry standards, historical statistical data, or user-defined standards, representing an acceptable performance level.

[0058] The normalization process uses a percentage calculation method, which involves dividing the actual test value by the threshold and multiplying by 100 to obtain the individual score for this item. For example, if a system's actual disk random read IOPS is 5000, and the threshold is set to 4000, then the score for this item is 125, indicating that the performance exceeds expectations by 25%.

[0059] For all individual scores, the comprehensive scoring unit 1034 performs a weighted summation according to the weight parameters provided by the weight configuration unit 1033 to calculate the final comprehensive score. The comprehensive score not only provides a quantitative indicator of overall performance, but also clearly shows the distribution of strengths and weaknesses of the system across different performance dimensions by comparing the individual scores, thus pointing the way for performance optimization.

[0060] The data storage module 104 uses the lightweight relational database SQLite to store test results, log files, weight parameters, comprehensive score data, and historical result data.

[0061] The data storage module 104 uses SQLite as its storage engine, mainly because of its lightweight, zero-configuration, and cross-platform characteristics, which make it very suitable for embedded deployment scenarios and can achieve complete data persistence without the need for an additional database server.

[0062] The database adopts a normalized design and establishes multiple related tables to store different types of data. For example, the test task table records basic information for each test, such as task ID, creation time, and test mode; the test result table stores detailed performance data for each test item; the log file table maintains the path and metadata of log files; the weight configuration table stores user-defined weight schemes; and the scoring record table stores the overall score and sub-scores for each test.

[0063] By establishing reasonable indexes and foreign key constraints, the system can efficiently execute various complex queries, such as counting the number of tests by time range and comparing the performance trends of different versions. In addition, the data storage module 104 also implements data backup and recovery functions, allowing users to periodically export database files for archiving to prevent data loss and facilitate the migration of test history records between different environments.

[0064] As can be seen from the above technical solutions, the beneficial effects of this embodiment are: This application provides a code application self-inspection and auditing system, including a front-end interaction module, a back-end service module, a test scheduling and scoring module, and a data storage module. The front-end interaction module, built on Vue.js, provides an interactive interface for selecting test tools, configuring test parameters, starting test tasks, displaying test progress, visualizing test results, and downloading log files. The back-end service module, built on Node.js, provides an API interface to process test tasks sent by the front-end interaction module, and through a Node.js subprocess, calls test tools to execute each test item in the test task; it obtains the raw data output by the test tools and parses the raw data into structured test results. The test scheduling and scoring module manages the test tasks. The testing process supports both comprehensive testing and single-item testing modes. In single-item testing mode, test items are executed directly based on user selection. In comprehensive testing mode, the system checks the data storage module for historical result data corresponding to the test task. If historical result data exists, a reuse prompt is sent to the user. If the user chooses not to reuse historical result data or if historical result data does not exist, the test items corresponding to the test task are executed in a preset order. Weight parameters are configured for each test item, and comprehensive score data corresponding to the test task is calculated and generated based on test results, preset performance thresholds, and weight parameters. The data storage module uses a lightweight relational database, SQLite, to store test results, log files, weight parameters, comprehensive score data, and historical result data. It achieves unified integrated management and automated scheduling execution of various performance testing tools. Through an intelligent historical data reuse mechanism and a scientific scoring system based on weight thresholds, it transforms scattered raw test data into intuitive and quantifiable comprehensive performance evaluation indicators, significantly improving the efficiency and analyzability of software performance testing results.

[0065] like Figure 5 The image shown is a specific embodiment of a method for comprehensive software performance testing according to this application.

[0066] In this embodiment, a method for comprehensive software performance testing includes the following steps: Step 501: Receive test instructions input by the user through the front-end interactive interface, and generate corresponding test tasks according to the test instructions; the test instructions include the test tools, test parameters and target test modes selected by the user.

[0067] At the beginning of the testing process, the system receives complete test commands from the user through the front-end interactive interface. The user first selects the test tools to be executed using the tool selection unit. These tools can be a single specialized test tool or a combination of multiple tools; the system supports flexible strategy selection to meet different testing needs. Next, the user sets the specific parameters required for each test tool in the configuration input box of the test control unit, such as the block size, read / write mode, and test duration for disk I / O tests, and the target server address, transmission protocol type, and number of concurrent connections for network bandwidth tests.

[0068] The system performs real-time validation of user-input parameters to ensure correct format and reasonable values, preventing test failures due to incorrect parameters. Users also need to specify the target test mode, i.e., whether to choose a single-item test mode or a comprehensive test mode. The single-item test mode is suitable for scenarios requiring rapid verification of a specific performance dimension, while the comprehensive test mode is used to obtain a comprehensive performance evaluation report of the system.

[0069] Once the user completes all configurations and clicks the test start button, the front-end interaction module integrates and encapsulates this information into a structured test instruction object. This object contains complete information such as a list of test tools, a parameter configuration dictionary for each tool, and test mode identifiers. The system then generates a uniquely identified test task based on this test instruction. This task is assigned a task ID and a creation timestamp, and records the current test environment information, such as the operating system version, CPU model, memory capacity, and other key configurations.

[0070] Step 502: If the target test mode is the comprehensive test mode, check whether there is historical result data corresponding to the test task in the data storage module; if there is historical result data, send a reuse prompt to the user.

[0071] When the system recognizes that the user has selected the comprehensive testing mode, it immediately initiates an intelligent historical data check mechanism. The system uses the historical check unit in the test scheduling and scoring module to send a query request to the data storage module, retrieving historical test record table to check for the existence of historical result data that matches the current test task.

[0072] The inspection process is based on multi-dimensional matching conditions. The system comprehensively considers multiple factors, including the combination of testing tools, the parameter configuration of each tool, and the hardware and software characteristics of the testing environment. The historical result data reuse mechanism is designed to avoid unnecessary duplicate testing, especially when the testing environment has not changed and the time interval is short. Re-executing the same test often yields highly similar results, which consumes testing time and system resources.

[0073] When the system detects historical data that meets the reuse criteria, it will display detailed information to the user in the form of a pop-up window or prompt box on the front-end interface. This information includes the execution time of the historical test, key configuration parameters of the test environment, main performance indicators of each test item, and overall score results. Users can view this information to determine whether the historical data is still valuable and decide whether to reuse the data directly or re-execute the test to obtain the latest results.

[0074] Determine the historical test time, historical test environment, and historical parameters corresponding to the historical result data; if the time difference between the historical test time and the current time is within the preset validity period, and the historical test environment is consistent with the current test environment, and the historical parameters are the same as the test parameters, then it is determined that the historical result data corresponding to the test task exists in the data storage module.

[0075] Specifically, the system determines the historical test time, historical test environment, and historical parameters corresponding to the historical result data. First, the system extracts the timestamps of the historical records, calculates the time difference between them and the current system time, and determines whether the difference is within the preset validity period. This validity period can usually be customized by the user, with common settings including 24 hours, 48 ​​hours, or 72 hours. Historical data exceeding the validity period will be considered outdated and will not be considered for reuse.

[0076] Secondly, the system will conduct a detailed comparison between the historical test environment and the current test environment to ensure consistency. This includes key hardware and software configurations such as operating system version number and patch level, CPU model and number of cores, memory capacity and frequency, disk type and interface standard, and network interface bandwidth specifications. Only when these core environmental elements are completely consistent can the historical test results be guaranteed to have effective reference value for the current environment.

[0077] Finally, the system will check the parameter configurations used in historical tests item by item and compare them precisely with the test parameters of the current test task, including all configurable items of each testing tool, such as test duration, concurrency level, and data block size. Only when all three conditions are met simultaneously—the time difference between the historical test time and the current time is within the preset validity period, the historical test environment is consistent with the current test environment, and the historical parameters are the same as the test parameters—will the system determine that reusable historical result data exists in the data storage module and issue a reuse prompt to the user.

[0078] Step 503: If the user chooses not to reuse historical result data or there is no historical result data, the backend service module calls the testing tool to execute each test item in the test task in a preset order.

[0079] When a user explicitly states that they will not reuse historical data, or when the system checks and finds that there is no matching historical result data in the data storage module, the system will initiate the actual test execution process. At this time, the sequential execution unit in the test scheduling and scoring module will send test execution requests to the backend service module one by one according to the list of test tools included in the test task and in a pre-set execution order.

[0080] The preset order takes into account the characteristics, resource consumption patterns, and potential interactions between various testing tools. For example, system overall performance evaluation tools are usually scheduled for priority execution because they need to run when the system is relatively idle and resource contention is low to obtain accurate benchmark performance data. Network bandwidth testing, on the other hand, may require a connection to an external test server, which could result in network latency or server overload. Therefore, it is scheduled for later to avoid network issues blocking the entire testing process.

[0081] When the sequential execution unit sends an execution request for a test project to the backend service module, the backend business logic processing unit receives the request and dynamically constructs the corresponding Shell command or script call statement based on the type and configuration parameters of the test tool. Using Node.js's `child_process` module, the system creates an independent child process to run the test tool. This isolation mechanism ensures that the execution of the test tool does not directly affect the stability of the main service process.

[0082] During the test tool's execution, the backend service module continuously monitors the child process's standard output and standard error streams, capturing various output information generated by the test tool in real time, including runtime logs, intermediate progress reports, and final test result data. Simultaneously, the backend module periodically pushes test progress updates to the frontend, which in turn updates the progress bar, allowing users to clearly understand the current test execution status.

[0083] Once one test item completes, the sequential execution unit immediately starts the next test item, and so on, until all selected testing tools have completed execution. Throughout the process, the system also implements a robust exception handling and error isolation mechanism. Even if a test item fails due to configuration errors, missing tools, or environmental issues, the entire testing task will not be terminated. The system will record the failure status and detailed error information of that item and continue executing subsequent test items, ensuring that users obtain the most complete possible test data.

[0084] Step 504: Obtain the raw data output by the testing tool through the backend service module, and parse the raw data into structured test results.

[0085] After each testing tool completes its execution, the backend service module collects a large amount of raw data. The format of this raw data varies significantly depending on the testing tool. Some are output in plain text format, containing a large amount of descriptive text and formatted tables; some are presented in structured JSON or XML format; and some may be a mixture of multiple formats, or even contain binary data.

[0086] In order to transform these raw data, which are in very different formats and difficult to use directly, into unified and standardized test results, the data parsing unit in the backend service module has implemented a dedicated parser for each testing tool. These parsers have a deep understanding of the output characteristics and data structure of each tool.

[0087] Through parsing logic, the data parsing unit converts all raw data into a unified JSON format object. Each object contains complete fields such as test item identifier, performance indicator name, test value, unit of measurement, and test timestamp, forming a clearly structured and easy-to-process data model. This standardized test result not only facilitates subsequent data storage and retrieval operations but also lays a solid data foundation for comprehensive score calculation, result visualization, and cross-version performance comparison analysis.

[0088] Step 505: Configure weight parameters for each test item, and calculate and generate comprehensive score data corresponding to the test task based on the test results of each test item, the preset performance threshold and weight parameters.

[0089] After obtaining the structured test results for all test items, the system will proceed to calculate the overall score. The weight configuration unit in the test scheduling and scoring module first assigns corresponding weight parameters to each test item. These weight parameters reflect the importance of different performance dimensions in the overall evaluation, and users can adjust the weight allocation strategy according to the actual application scenario and business needs.

[0090] Based on the performance threshold, the test results are normalized to determine the individual score of the test item; the individual score is multiplied by the corresponding weight parameter to determine the weighted score of the test item; the weighted scores are summed to determine the comprehensive score data corresponding to the test task.

[0091] Performance thresholds are a set of pre-defined benchmark values ​​that represent the expected or industry standard levels for various performance metrics. These thresholds can be derived from specifications provided by hardware manufacturers, average values ​​from industry performance benchmark tests, historical statistics from within the company, or performance targets customized by users based on business needs.

[0092] The normalization process uses a proportional calculation method, which involves dividing the actual performance value obtained from the test by the corresponding performance threshold, and then multiplying by 100 to obtain the individual score for that item. For example, if a system's actual IOPS value in the Fio random read test is 8000, and the preset performance threshold is 5000 IOPS, then the individual score for that item is (8000 / 5000)×100=160 points, indicating that the performance of that item exceeds the expected standard by 60%.

[0093] Conversely, if the measured value of a performance indicator is lower than the threshold, for example, if the measured network bandwidth is 800Mbps while the threshold is 1000Mbps, then the score for that indicator is (800 / 1000)×100=80 points, indicating that the performance did not meet expectations and was only 80% of the standard. Through this normalization process, various performance indicators that originally had different dimensions and vastly different numerical ranges are uniformly converted into comparable score values, creating conditions for subsequent weighted aggregation.

[0094] After calculating the individual scores for each test item, the comprehensive scoring unit multiplies each individual score by its corresponding weight parameter to determine the weighted score for that test item. For example, if the individual score for the Fio disk test is 120 points and its weight parameter is 30%, then the weighted score for that item is 120 × 0.3 = 36 points.

[0095] The system performs this weighted calculation process on each test item, obtaining its respective weighted score. Finally, the comprehensive scoring unit sums the weighted scores of all test items to obtain the final comprehensive score. This comprehensive score is a value between 0 and 100+. When the comprehensive score is close to or exceeds 100, it indicates that the overall performance of the system meets or exceeds the expected standard; when the comprehensive score is significantly lower than 100, it indicates that the system has obvious performance shortcomings that need to be optimized.

[0096] It also includes: determining the log file corresponding to the test task; and storing the test results, log file, weight parameters, and comprehensive score data in the data storage module.

[0097] After completing the comprehensive score calculation, the system will also perform data persistence operations. The system will determine all log files corresponding to this test task. These log files include standard output logs, error output logs generated during the test tool's operation, and detailed report files that the test tool itself may generate.

[0098] The system will store the complete dataset of this test task, including the structured test results of each test item, the path information of the log files, the weight parameter configuration used, and the final calculated comprehensive score data, into the data storage module.

[0099] Once stored, this data will be permanently saved as historical test records for use in subsequent functions such as historical data reuse checks, performance trend analysis, and version comparison evaluation. Users can also query these historical records at any time through the front-end interface, download detailed test reports and raw log files, providing complete data support for troubleshooting and performance optimization.

[0100] It also includes: monitoring the execution status of test tasks; if a termination command is received from the user through the front-end interface, a termination signal is sent to the corresponding subprocess of the test project through the back-end service module to forcibly terminate the test process of the test task.

[0101] Throughout the test execution process, the system also provides test control capabilities. The system continuously monitors the execution status of test tasks, tracks the running status of each sub-process through the backend service module, and updates test progress information in real time. If the user encounters any abnormalities during the test, or needs to terminate the test early for other reasons, they can send a termination command through the front-end interface.

[0102] When the backend service module receives this termination command, it immediately sends a termination signal, usually SIGTERM or SIGKILL, to the child process corresponding to the currently executing test project, forcibly terminating the child process. For test tools that may have spawned derivative processes, the system will also recursively search for and terminate all related child processes to ensure that the test tools are completely stopped and to prevent residual processes from continuing to occupy system resources.

[0103] As can be seen from the above technical solution, the beneficial effects of this embodiment are as follows: It receives test instructions input by the user through the front-end interactive interface, and generates corresponding test tasks based on these instructions. The test instructions include the test tool, test parameters, and target test mode selected by the user. If the target test mode is a comprehensive test mode, it checks whether historical result data corresponding to the test task exists in the data storage module. If historical result data exists, a reuse prompt is sent to the user. If the user chooses not to reuse historical result data or historical result data does not exist, the back-end service module calls the test tool to execute each test item in the test task in a preset order. The back-end service module obtains the raw data output by the test tool and parses the raw data into structured test results. Weight parameters are configured for each test item, and based on the test results of each test item, preset performance thresholds, and weight parameters, comprehensive score data corresponding to the test task is calculated and generated. This achieves a fully automated process from user input to obtaining score results, simplifies the operational complexity of multi-tool performance testing, improves test efficiency through a historical data reuse mechanism, and transforms multi-dimensional performance data into quantifiable comprehensive evaluation indicators based on a weighted and threshold-based scoring system.

[0104] Those skilled in the art will understand that the embodiments of this application can be provided as methods or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or a combination of software and hardware.

[0105] The various embodiments in this application are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0106] It should also be noted that 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 process, method, article, or apparatus. Unless otherwise specified, 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 that element.

[0107] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A system for comprehensive software performance testing, characterized in that, include: Front-end interaction module, back-end service module, test scheduling and scoring module, and data storage module; The front-end interaction module, built on Vue.js, provides an interactive interface for selecting testing tools, configuring testing parameters, starting testing tasks, displaying testing progress, visualizing test results, and downloading log files. The backend service module, built on Node.js, provides an API interface to process the test tasks sent by the frontend interaction module. Through a subprocess of Node.js, it calls the testing tool to execute each test item in the test task; obtains the raw data output by the testing tool, and parses the raw data into structured test results. The test scheduling and scoring module is used to manage the test process of the test task and supports comprehensive test mode and single test mode. In the single-item test mode, the test item is executed directly according to the user's selection; In the comprehensive test mode, the system checks whether historical result data corresponding to the test task exists in the data storage module; if the historical result data exists, a reuse prompt is sent to the user; if the user chooses not to reuse the historical result data or the historical result data does not exist, the test items corresponding to the test task are executed in a preset order. Configure weight parameters for each of the test items, and calculate and generate comprehensive score data corresponding to the test task based on the test results, preset performance thresholds and the weight parameters; The data storage module uses a lightweight relational database, SQLite, to store the test results, the log files, the weight parameters, the comprehensive score data, and the historical result data.

2. The system according to claim 1, characterized in that, The front-end interaction module includes: Tool selection unit, test control unit, progress display unit, and result display unit; The tool selection unit is implemented using a checkbox component, which provides single or multiple selection of the test tools; the test tools include a system overall performance evaluation tool, a disk I / O performance test tool, a network bandwidth performance test tool, and a memory bandwidth test tool; The test control unit includes a configuration input box and a test start button; the configuration input box is used to receive the user-defined test parameters; the test start button is used to trigger the execution of the test task, and after clicking the test start button, the selected test tool and the test parameters are sent to the backend service module. The progress display unit is implemented using a progress bar component and is used to receive the test progress pushed by the backend service module. The results display unit includes a table component and a visualization chart component; the table component is used to display the performance index data of each test item in a list format; the visualization chart component is used to display the comprehensive score data and the score distribution of each test item in a graphical manner, and provides a download button for the log file.

3. The system according to claim 1, characterized in that, The backend service module includes: Interface unit, business logic processing unit, and data parsing unit; The interface unit includes a test execution interface, a result query interface, and a log download interface; the test execution interface is used to receive the execution request of the test task, the result query interface is used to query the historical result data, and the log download interface is used to provide the log file download service. The business logic processing unit is used to process the execution logic of the test task, create the child process through the child_process module of Node.js, call the shell script to start the test tool, and obtain the raw data by listening to the standard output stream and standard error stream of the child process; The data parsing unit is used to standardize the raw data and encapsulate the raw data into the test results in JSON format.

4. The system according to claim 1, characterized in that, The test scheduling and scoring module includes: Historical inspection unit, sequential execution unit, weight configuration unit, and comprehensive scoring unit; The historical inspection unit is used to query the data storage module in the comprehensive test mode to retrieve the historical result data that matches the test task; determine whether the historical result data meets the reuse conditions; and if it meets the reuse conditions, send the reuse prompt to the user. The sequential execution unit is used to call the backend service module to execute each test item in a preset order when the user selects not to reuse the historical result data or when the historical result data does not exist. The weight configuration unit is used to configure the weight parameters for each of the test items; The comprehensive scoring unit is used to obtain the test results corresponding to each test item, normalize each test result according to the performance threshold to obtain a single score, and perform a weighted summation of each single score according to the weight parameters to generate the comprehensive score data.

5. The system according to claim 4, characterized in that, The determination of whether the historical result data meets the reuse conditions includes: Determine the historical test time, historical test environment, and historical parameters corresponding to the historical result data; If the time difference between the historical test time and the current time is within a preset validity period, and the historical test environment is consistent with the current test environment, and the historical parameters are the same as the test parameters, then the historical result data is determined to meet the reuse conditions.

6. A method for comprehensive software performance testing, said method being applied to the system described in any one of claims 1-6, characterized in that, include: Receive test instructions from users through the front-end interactive interface, and generate corresponding test tasks according to the test instructions; The test instructions include the test tool, test parameters, and target test mode selected by the user; If the target test mode is a comprehensive test mode, check whether there is historical result data corresponding to the test task in the data storage module; if the historical result data exists, send a reuse prompt to the user. If the user chooses not to reuse the historical result data or the historical result data does not exist, the backend service module calls the testing tool to execute each test item in the test task in a preset order. The backend service module obtains the raw data output by the testing tool and parses the raw data into structured test results. Configure weight parameters for each test item, and calculate and generate comprehensive score data corresponding to the test task based on the test results of each test item, the preset performance threshold, and the weight parameters.

7. The method according to claim 6, characterized in that, The step of checking whether the historical result data corresponding to the test task exists in the data storage module includes: Determine the historical test time, historical test environment, and historical parameters corresponding to the historical result data; If the time difference between the historical test time and the current time is within a preset validity period, and the historical test environment is consistent with the current test environment, and the historical parameters are the same as the test parameters, then it is determined that the historical result data corresponding to the test task exists in the data storage module.

8. The method according to claim 6, characterized in that, The calculation to generate the comprehensive score data corresponding to the test task includes: Based on the performance threshold, the test results are normalized to determine the individual score of the test item; The individual score is multiplied by the corresponding weight parameter to determine the weighted score of the test item; The weighted scores are summed to determine the comprehensive score data corresponding to the test task.

9. The method according to claim 6, characterized in that, Also includes: Determine the log file corresponding to the test task; The test results, the log file, the weight parameters, and the comprehensive score data are stored in the data storage module.

10. The method according to claim 6, characterized in that, Also includes: Monitor the execution status of the test task; If a termination command is received from the user through the front-end interactive interface, the back-end service module sends a termination signal to the sub-process corresponding to the test project to forcibly terminate the test process of the test task.

Images