Software test management method and device, equipment and storage medium

Abstract

The invention provides a software test management method and device, equipment and a storage medium, and relates to the technical field of information. The method comprises the steps that test pre-configuration information and a test execution program input by a user are received, the test execution program is used for constraining a test process, and the test pre-configuration information is used for configuring an operation environment of the test process; and storing the test pre-configuration information in a relational database. And generating a test task queue according to the test pre-configuration information and the test execution program, wherein the test task queue comprises at least one test task. And calling a test engine to run the test execution program according to the test task queue, storing performance index data in the running process of the test execution program in a distributed database, and storing execution result data in the running process of the test execution program in a relational database.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a software testing management method, apparatus, device, and storage medium. Background Technology

[0002] In the software testing process, automated testing has become an essential part of ensuring software quality. With the increasing scale and frequency of testing, the test execution process generates massive amounts of results, including various types of data such as text, images, and logs.

[0003] Currently, database systems are typically used to store this test data. However, when faced with massive amounts of test data of different types, the inherent data storage and retrieval patterns of database systems result in different types of test data being isolated from each other and unable to form an effective correlation. Summary of the Invention

[0004] This application provides a software test management method, apparatus, device, and storage medium for effectively associating different types of software test data.

[0005] Firstly, this application provides a software test management method. This method is applied to electronic devices. The executing entity of the method can be an electronic device, a component or device applied to the electronic device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the electronic device, including: It receives pre-test configuration information and test execution program input by the user. The test execution program is used to constrain the test process, and the pre-test configuration information is used to configure the runtime environment of the test process. A test task queue is generated based on the pre-test configuration information and the test execution program. The test task queue includes at least one test task. The test engine is invoked to run test executors according to the test task queue. The performance metrics data during the execution of the test executors are stored in a distributed database, and the execution results data during the execution of the test executors are stored in a relational database. The test analysis report is generated by calling the first performance index data stored in the distributed database, the first execution result data stored in the relational database, and the test pre-configuration information. The first performance index data is the performance index data that matches the test report generation requirements information input by the user, and the first execution result data is the execution result data that matches the test report generation requirements information input by the user.

[0006] In the first aspect, the system receives pre-test configuration information and a test execution program from the user. The test execution program defines the test process, and the pre-test configuration information provides the runtime environment for this process. The pre-test configuration information is stored in a relational database for structured management and rapid retrieval of the configuration data. A test task queue is generated based on the pre-test configuration information and the test execution program, achieving automated, standardized, and queued generation of test tasks. The test engine runs the test execution program according to the test task queue, storing performance metrics data during the execution process in a distributed database and execution results data in a relational database. Leveraging the efficient storage and real-time retrieval capabilities of the distributed database, data silos are broken down, achieving a unified association between performance metrics data, execution results data, and pre-test configuration information. The system uses the first performance metrics data stored in the distributed database, the first execution results data stored in the relational database, and the pre-test configuration information to generate a test analysis report. By effectively integrating configuration information, performance data, and result data, a comprehensive and accurate test analysis report can be quickly generated, thereby improving test efficiency, data utilization, and report generation accuracy, and enhancing the overall relevance and traceability of test data.

[0007] In conjunction with the first aspect, in one possible implementation, the pre-test configuration information includes test task configuration information; Test task configuration information is used to indicate the timing rules for test task execution and / or test priority.

[0008] In this implementation, by using test task configuration information, including test task configuration information, and by using the test task configuration information to indicate the timing execution rules and / or test priority of the test tasks, the test tasks are clearly defined as work units with corresponding scheduling attributes. This enables flexible scheduling and priority management of test tasks, allowing execution time to be arranged according to the actual test plan and ensuring that high-priority tasks are executed first, thereby improving the utilization efficiency of test resources and the timeliness of task execution.

[0009] In conjunction with the first aspect, in one possible implementation, the first performance metric data stored in the distributed database is invoked, including: Receive user input to generate test report requirements; Generate data query instructions that match the distributed database based on the test report's requirements. Use data query commands to query data from a distributed database; Receive the first performance metric data that matches the data query command.

[0010] In this implementation, test report requirements are generated by receiving user input, and a data query command matching the distributed database is generated based on this information, ensuring that the query conditions conform to the database characteristics. Data queries are then performed on the distributed database using the data query command, enabling efficient and accurate retrieval of the required data. Receiving the first performance indicator data matching the data query command ensures the accuracy and completeness of data extraction, thereby supporting the generation of highly targeted test analysis reports with reliable data sources, improving the speed and accuracy of report generation.

[0011] In conjunction with the first aspect, in one possible implementation, the test report generation requirement information is used to indicate at least one of the following: time range, test type, or performance metric type.

[0012] In this implementation, the test report generates requirement information to indicate at least one of the time range, test type, or performance indicator type, enabling users to flexibly set the report content according to specific analysis needs. This allows for targeted data extraction and analysis for different time spans, test types, or key indicators, thereby meeting diverse test evaluation needs and enhancing the practicality and relevance of the report.

[0013] In conjunction with the first aspect, in one possible implementation, the method further includes: Store the test executor in a relational database; It receives and responds to user-inputted program execution request, and invokes the test program stored in the relational database. The program execution request includes program query request or program change request.

[0014] In this implementation, test executors are stored in a relational database, enabling centralized management and structured storage of these executors. The system receives and responds to user-inputted executor invocation requests, calling the test executors stored in the relational database. These requests can include query requests or modification requests, allowing users to quickly retrieve and modify executors, thus improving the flexibility and efficiency of executor management.

[0015] In conjunction with the first aspect, one possible implementation involves storing performance metrics data during the execution of the test program in a distributed database, including: The performance metrics data during the execution of the test program are stored in a distributed database according to the classification rules, which are either classified by test item or by time period.

[0016] In this implementation, performance metrics data during the test execution process are stored in a distributed database according to classification rules, which can be based on test items or time periods. This achieves orderly organization and storage of performance data, facilitating rapid retrieval and aggregation analysis based on project or time dimensions, thereby improving the efficiency of data querying and the accuracy of data analysis.

[0017] In conjunction with the first aspect, in one possible implementation, the method further includes: Render the test analysis report into a data format for display.

[0018] In this implementation, the test analysis report is rendered into a data format for display, making the test results more intuitive and allowing users to quickly obtain test information, thus improving the readability of the report and the user experience.

[0019] In conjunction with the first aspect, in one possible implementation, in the test analysis report used for display, a first indicator is displayed based on a first display format, and a second indicator is displayed based on a second display format, wherein the first indicator does not meet the normal indicator conditions, and the second indicator meets the normal indicator conditions.

[0020] In this implementation, by displaying a first indicator based on a first display format and a second indicator based on a second display format in the displayed test analysis report, wherein the first indicator does not meet the normal indicator conditions and the second indicator does meet the normal indicator conditions, users can quickly distinguish between abnormal and normal indicators, highlighting problematic data, making it easier for users to focus on and take corresponding measures, thus enhancing the practicality of the test report.

[0021] In conjunction with the first aspect, one possible implementation involves testing pre-configuration information, including: Test project information, test environment parameters, and test task configuration information. Test project information includes the project name, project description, and associated test type. Test environment parameters indicate the network environment, relational database, and distributed database used for testing.

[0022] In this implementation, the pre-test configuration information includes test project information, test environment parameters, and test task configuration information. The test project information includes the project name, project description, and associated test type. The test environment parameters indicate the network environment, relational database, and distributed database for testing. This achieves comprehensive configuration of the test project and environment, ensuring that the test is executed in the correct network and data storage environment, improving the accuracy and resource coordination of the test, and facilitating the unified management and reuse of the test environment.

[0023] Secondly, this application provides a software test management device, comprising: The receiving module is used to receive pre-test configuration information and test execution program input by the user. The test execution program is used to constrain the test process, and the pre-test configuration information is used to provide the runtime environment for the test process. The storage module is used to store pre-test configuration information in a relational database; The generation module is used to generate a test task queue based on the test pre-configuration information and the test execution program. The test task queue includes at least one test task. The runtime module is used to call the test engine to run the test executor according to the test task queue, store the performance index data of the test executor in a distributed database, and store the execution result data of the test executor in a relational database. The generation module is also used to call the first performance index data stored in the distributed database, the first execution result data stored in the relational database, and the test pre-configuration information to generate a test analysis report. The first performance index data is the performance index data that matches the test report generation requirement information input by the user, and the first execution result data is the execution result data that matches the test report generation requirement information input by the user.

[0024] In conjunction with the second aspect, in one possible implementation, the pre-test configuration information includes test task configuration information; Test task configuration information is used to indicate the timing rules for test task execution and / or test priority.

[0025] In conjunction with the second aspect, in one possible implementation, the first performance metric data stored in the distributed database is invoked, including: Receive user input to generate test report requirements; Generate data query instructions that match the distributed database based on the test report's requirements. Use data query commands to query data from a distributed database; Receive the first performance metric data that matches the data query command.

[0026] In conjunction with the second aspect, in one possible implementation, the test report generation requirement information is used to indicate at least one of the following: time range, test type, or performance metric type.

[0027] In conjunction with the second aspect, in one possible implementation, the receiving module is also used to store the test executor in a relational database; It receives and responds to user-inputted program execution request, and invokes the test execution program stored in the relational database. The program execution request includes an execution program query request or an execution program modification request.

[0028] In conjunction with the second aspect, in one possible implementation, the runtime module is also used to store performance metrics data during the execution of the test executor in a distributed database, including: The performance metrics data during the execution of the test program are stored in a distributed database according to the classification rules, which are either classified by test item or by time period.

[0029] In conjunction with the second aspect, in one possible implementation, the generation module is also used to render the test analysis report into a data format for display.

[0030] In conjunction with the second aspect, in one possible implementation, it is also used to display a first indicator based on a first display format and a second indicator based on a second display format in the displayed test analysis report, wherein the first indicator does not meet the normal indicator conditions and the second indicator meets the normal indicator conditions.

[0031] In conjunction with the second aspect, one possible implementation involves testing pre-configuration information, including: Test project information, test environment parameters, and test task configuration information. Test project information includes the project name, project description, and associated test type. Test environment parameters indicate the network environment, relational database, and distributed database used for testing.

[0032] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the method of the first aspect described above.

[0033] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; when the computer software instructions are executed in an electronic device, they cause the electronic device to implement the method described in the first aspect.

[0034] Fifthly, this application provides a computer program product comprising a computer program; when the computer program is run in an electronic device, it causes the electronic device to implement the method described in the first aspect.

[0035] The beneficial effects of the second to fifth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0036] Figure 1 A schematic diagram of the application environment for a software testing management method provided in this application; Figure 2 A schematic diagram of a software test management system architecture is provided for this application; Figure 3A flowchart illustrating a software testing management method provided in this application; Figure 4 A schematic diagram illustrating the data transmission process between the server and the distributed database provided in this application; Figure 5 A schematic diagram of the composition of a software test management device provided in this application; Figure 6 This is a schematic diagram of the composition of an electronic device provided in this application. Detailed Implementation

[0037] The following is a detailed description of a call detail record (CDR) data recording method provided in this application, with reference to the accompanying drawings.

[0038] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0039] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0040] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0041] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0042] To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art can understand that the terms "first" and "second" are not intended to limit the quantity or execution order.

[0043] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0044] In the software testing process, automated testing has become an essential part of ensuring software quality. Automated testing mainly includes two types: automated performance testing and automated interface testing.

[0045] For automated performance testing tools, LoadRunner is commonly used. It can effectively simulate high-concurrency scenarios and monitor system performance metrics such as response time and throughput. However, managing test executors is cumbersome; after recording, a significant amount of manual modification and optimization is required, and different types of test executors are difficult to manage uniformly. Especially when dealing with multiple business processes or complex interaction logic, parameter passing and scenario switching configurations between different executors are cumbersome, error-prone, and have poor reusability, thus impacting testing efficiency.

[0046] For API automation testing tools, JMeter or Postman are commonly used. JMeter can perform stress and performance testing on Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP) servers, but it is weak in areas such as API information maintenance, test case design, and management. While using JMeter with Ant can solve some problems in running execution programs and generating reports when building an API automation testing environment, it still requires manual configuration of numerous parameters, including thread group settings, assertion configurations, and data-driven parameter settings, making the operation complex and difficult to reuse across different projects. Furthermore, JMeter lacks unified management capabilities for API information, making the maintenance and updating of API documentation extremely difficult when there are many APIs. Postman, on the other hand, is often used for routine API testing. For example, when developing an Application Programming Interface (API) service, developers can use Postman to quickly verify the functionality of the API. However, Postman lacks flexibility in writing and managing automated test execution programs, making it difficult to meet the needs of large-scale API automation testing.

[0047] In terms of system architecture, common components of a testing platform include a defect management system, a test case management system, and automated testing tools to assist regression testing. For example, many companies use JIRA for defect management and TestRail for test case management. However, as business expands, the integration difficulties between these systems become increasingly apparent. Due to inconsistent data formats and interface standards, test requirements, test cases, and defect information are scattered, making it difficult to achieve end-to-end test control. Testers need to frequently switch between different systems, which not only reduces work efficiency but also increases learning and usage costs. Furthermore, the lack of effective data linkage and collaboration mechanisms between systems makes it impossible to build a complete test data chain, affecting the ability to comprehensively analyze the test process and results.

[0048] In terms of test data storage and management, database systems are typically used to store this test data. Database systems include relational databases (e.g., MySQL, Oracle) and non-relational databases (e.g., MongoDB). Relational databases have relatively fixed table structures, making it difficult to flexibly adapt to the diverse data formats in test results. During automated testing, test results contain various data types such as text, images, and logs. Relational databases are inefficient at storing and processing this unstructured or semi-structured data, and query efficiency drops significantly as data volume increases. While non-relational databases offer better scalability, they are insufficient in terms of data retrieval accuracy and real-time performance, making it difficult to support rapid analysis and large-scale real-time statistics of test results. Furthermore, data generated by different test types is often stored in different databases or storage systems, lacking effective correlation, which is detrimental to a comprehensive evaluation of software quality.

[0049] To address the aforementioned technical problems, this application provides a software test management method, apparatus, device, and storage medium. The approach involves receiving user-inputted pre-test configuration information and a test execution program. The test execution program defines the test process, and the pre-test configuration information provides the runtime environment for this process. The pre-test configuration information is stored in a relational database for structured management and rapid retrieval of the configuration data. A test task queue is generated based on the pre-test configuration information and the test execution program, achieving automated, standardized, and queued generation of test tasks. A test engine is invoked to run the test execution program according to the test task queue. Performance metrics data during the test execution process are stored in a distributed database, and execution results data are stored in a relational database. Leveraging the efficient storage and real-time retrieval capabilities of the distributed database, data silos are broken down, achieving a unified association between performance metrics data, execution results data, and pre-test configuration information. The test analysis report is generated by calling the first performance index data stored in the distributed database, the first execution result data stored in the relational database, and the pre-test configuration information. By effectively integrating the configuration information, performance data, and result data, a comprehensive and accurate test analysis report can be generated quickly, thereby improving test efficiency, data utilization, and the accuracy of report generation, and enhancing the overall relevance and traceability of test data.

[0050] The embodiments provided in this application will now be described in detail with reference to the accompanying drawings.

[0051] like Figure 1 As shown, the application environment may include a terminal device 100 and a server 101. Optionally, the application environment may also include a database system 103 that is communicatively connected to the server 101. They collaborate with each other through an application 102 that supports software test management functions to jointly implement a software test management method.

[0052] Terminal device 100 includes a client application 102 that supports software test management functions. This client provides users with a software test management interface, which can be a World Wide Web (Web) page accessed through a browser. The terminal is specifically user equipment (UE), and its types include, but are not limited to, smartphones, tablets, laptops, desktop computers, Internet of Things (IoT) terminals, and vehicle-to-everything (V2X) terminals. The terminal accesses the access network via a wireless air interface and has the capability to carry voice services, data transmission services, and multimedia services. It can also achieve direct communication between different terminals based on device-to-device (D2D) direct connection technology or V2X technology.

[0053] The software test management method provided in this application can be applied to server 101. Server 101 runs an application 102 that supports software test management functions. This application is responsible for processing software test management requests sent by clients, executing core logic such as scheduling and executing test tasks, and storing and analyzing test data. The software to be tested, serving as the test target, is deployed on server 101.

[0054] In an optional embodiment, the terminal device 100 and the server 101, and the server 101 and the database system 103, can be interconnected via wired or wireless networks. These connections support the transmission of program instructions and data between the components. The server 101 includes a first memory and a first processor. The first memory stores a software test management program; this software test management program is invoked and executed by the first processor to implement the software test management method provided in this application. The first memory may include, but is not limited to, the following: random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EEPROM). The first processor may consist of one or more integrated circuit chips. Optionally, the first processor may be a general-purpose processor, such as a central processing unit (CPU) or a network processor (NP). Optionally, the first processor can implement the software test management method provided in this application by running programs or code.

[0055] The software test management method provided in this application can be executed by server 101. Server 101 is used to provide software test management services for the software test management system of terminal device 100. Optionally, server 101 undertakes the main computing work, and terminal device 100 undertakes the secondary computing work; or, server 101 undertakes the secondary computing work, and terminal device 100 undertakes the main computing work; or, server 101 and terminal device 100 use a distributed computing architecture for collaborative computing. Server 101 can be a single server, a server cluster composed of multiple servers, or a cloud computing service center. Optionally, server 101 includes a second memory and a second processor. The second memory stores a software test management program; the software test management program is called by the second processor to implement the software test management method provided in this application. Optionally, the second memory can include, but is not limited to, the following: RAM, ROM, PROM, EPROM, EEPROM. Optionally, the second processor can be a general-purpose processor, such as a CPU or NP.

[0056] Database system 103 is deployed on a dedicated server to store test data, including performance metrics generated during test execution, interface test results, and project, environment, and task configuration information. Database system 103 includes a distributed database, such as Elasticsearch (ES), and a relational database, such as MySQL. The distributed database is used for efficient storage and retrieval of test results data, while the relational database is used to store structured configuration information.

[0057] This application embodiment also provides a software testing management system, which can be set on a server (such as the server 101 mentioned above). Figure 2 As shown, the software test management system 200 may include: a front-end 201, a back-end 202, and a data storage layer 203.

[0058] Frontend 201 serves as the user interface, receiving pre-test configuration information and test execution procedures from the user and sending the information to backend 202 for processing. It also receives and displays the test task status, analysis results, and generated test analysis report returned by backend 202.

[0059] Backend 202 serves as the core processing unit of the system, comprising control layer 210 and service layer 220.

[0060] The control layer 210 acts as a request distribution hub, receiving and parsing HTTP requests from the frontend 201, and routing them to the corresponding business control unit based on the request content. Specifically, this includes: Automated Performance Testing Engine 211: Manages and executes performance testing tasks based on pre-test configuration information.

[0061] Interface Automation Testing Engine 212: Manages and executes interface testing tasks based on pre-test configuration information.

[0062] Unified Management Engine 213: Manages test project information, test environment parameters, test execution program resources, and analyzes and statistically processes historical data. Test project information includes the software to be tested, which serves as the test target.

[0063] The core business logic and data processing capabilities of the service layer 220 encapsulation system are achieved through the collaborative work of the following dedicated engines: Report generation engine 221: Calls performance indicator data stored in distributed database 232, execution result data stored in relational database 231, and test pre-configuration information, and uses a template to generate a test analysis report. The template can be a FreeMarket template.

[0064] Task scheduling engine 222: Generates test tasks based on pre-test configuration information and test execution program, and calls the test engine to execute the test tasks.

[0065] Data storage engine 223: During the execution of the test task, the performance index data of the test execution program is stored in the distributed database 232, and the execution result data of the test execution program is stored in the relational database 231.

[0066] Data analysis engine 224: Based on the analysis conditions set by the user, it queries and aggregates the performance index data stored in the distributed database 232.

[0067] Data storage layer 203 provides persistent storage capabilities for the system, including: Relational databases (e.g., MySQL databases) are used to store pre-test configuration information, test executors, and test task execution results. Execution result data is highly structured, therefore it is stored in a relational database to leverage its data consistency.

[0068] Distributed databases (e.g., Elasticsearch) are used to store performance metric data generated during the execution of test programs. A distributed database is a data management system that distributes data across multiple independent servers and provides services over a network. Distributed databases create a global index for performance metric data, containing key related fields (e.g., test task identifier, test script identifier, interface name, timestamp, scenario identifier). Based on this global index, the platform can perform distributed retrieval across multiple servers when accessing performance metric data, establishing logical relationships between data records stored on different physical nodes that have the same related fields.

[0069] It should be noted that the system architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0070] In conjunction with the aforementioned software testing management system, this application provides a software testing management method. Figure 3 A flowchart illustrating this method is provided. Figure 3 As shown, the software test management method provided in this application embodiment may include the following steps S300~S304: S300 receives user-inputted pre-test configuration information and test execution program.

[0071] The test executor is used to constrain the test process, while the pre-test configuration information is used to configure the runtime environment of the test process. The pre-test configuration information refers to the predefined and set parameters and rules for the execution of test tasks; its function is to configure the external conditions upon which the test executor depends. The test executor contains the specific operational instructions that drive the test engine to execute, and its content determines the specific steps and logic of the test. The pre-test configuration information constitutes the framework conditions for test execution, while the test executor is the specific sequence of operations executed within this framework. For example, the test executor can be a script.

[0072] S301. Store the pre-test configuration information in a relational database.

[0073] Relational databases are databases that use a relational model to organize data, such as Oracle and MySQL. Storing pre-test configuration information in a relational database leverages its structured storage characteristics to ensure the consistency, integrity, and manageability of the configuration information. This provides stable and reliable data query and retrieval support for the generation and scheduling of subsequent test tasks, and can also serve as the basis for analysis when generating test reports using S304.

[0074] S302. Generate a test task queue based on the pre-test configuration information and the test execution program.

[0075] By combining test execution programs that define specific test operations with pre-test configuration information containing scheduling rules, test tasks with clearly defined execution attributes are generated. Each test task is a complete work unit, with its execution time and execution order defined by the configuration information. Multiple such test tasks are then aggregated and sorted according to their respective execution attributes, ultimately forming a test task queue with a clear order relationship between tasks. A test task queue refers to a work unit with clear boundaries that can be recognized and executed by the test engine, and it includes at least one specific test task. Furthermore, the test task queue not only carries the test tasks to be executed but also clearly defines the execution attributes of each test task: including specific execution time (e.g., scheduled execution, immediate execution after triggering) and execution order (e.g., sequential execution, execution by priority). By standardizing these two core attributes, the testing process is ensured to proceed in an orderly manner as expected.

[0076] S303: Call the test engine to run the test execution program according to the test task queue, store the performance index data of the test execution program in a distributed database, and store the execution result data of the test execution program in a relational database.

[0077] A test engine is an executable program that can run test programs and collect test process and result data. For example, a test engine can be JMeter.

[0078] Performance metrics data refer to time-series data continuously generated during the execution of the test program, reflecting the performance of the software system under test under stress or load, such as response time, throughput, error rate, and number of concurrent users. Storing this type of data in a distributed database (such as Elasticsearch) leverages its efficient storage and real-time retrieval capabilities for massive amounts of data to support in-depth analysis and multi-dimensional aggregate queries of the testing process.

[0079] Execution result data refers to the status data that characterizes the final conclusion of the test task after the test execution program has finished running, such as pass / fail status and detailed error logs. Storing this type of data in a relational database (such as MySQL) leverages its structured storage and transaction characteristics to ensure the consistency, integrity, and manageability of key result data, facilitating rapid status queries, result statistics, and task management.

[0080] S304. Call the first performance index data stored in the distributed database, the first execution result data stored in the relational database, and the test pre-configuration information to generate a test analysis report.

[0081] The first performance index data is the performance index data that matches the test report generation requirement information input by the user, and the first execution result data is the execution result data that matches the test report generation requirement information input by the user.

[0082] The test report generation requirements information is user-inputted information that reflects the user's requirements. For example, the test report generation requirements information may include at least one of the following: test type, specific metrics, or time range. The first performance metric data and the first execution result data are target data filtered and retrieved from the distributed database and relational database, respectively, based on the test report generation requirements information. For example, the test pre-configuration information stored in the relational database includes: project information, environment configuration, and task parameters (e.g., 100 concurrent users). The performance metric data stored in the distributed database includes: response time, throughput, error rate, etc. The execution result data stored in the relational database includes: test pass / fail status, error messages, etc.

[0083] For example, when a user inputs a requirement to generate a test report, specifying the need for performance metrics data from October 1st to October 7th, 2024, the server backend retrieves performance metrics data for that period from a distributed database. This performance metrics data includes error rate data and response time data. Simultaneously, the server backend retrieves test pass / fail status information for the same time period from a relational database. Finally, the server backend uses this error rate data, response time data, and test pass / fail status information to generate a test analysis report.

[0084] In this embodiment, user-inputted pre-test configuration information and test execution program are received. The test execution program defines the test process, and the pre-test configuration information provides the runtime environment for this process. The pre-test configuration information is stored in a relational database for structured management and rapid querying of configuration data. A test task queue is generated based on the pre-test configuration information and the test execution program, achieving automated, standardized, and queued generation of test tasks. The test engine runs the test execution program according to the test task queue, storing performance indicator data during the program's execution in a distributed database and execution result data in a relational database. Leveraging the efficient storage and real-time retrieval capabilities of the distributed database, data silos are broken down, achieving a unified association between performance indicator data, execution result data, and pre-test configuration information. The first performance indicator data stored in the distributed database, the first execution result data stored in the relational database, and the pre-test configuration information are used to generate a test analysis report. By effectively integrating configuration information, performance data, and result data, a comprehensive and accurate test analysis report can be quickly generated, thereby improving test efficiency, data utilization, and report generation accuracy, and enhancing the overall relevance and traceability of test data.

[0085] In one embodiment, the pre-test configuration information includes test task configuration information.

[0086] Test task configuration information is used to indicate the timing execution rules and / or test priority of test tasks. A test task refers to a work unit defined according to the timing execution rules and / or test priority, generated by combining a test execution program with the test task configuration information.

[0087] Test task configuration information defines the rules for test tasks during the scheduling and execution phases. This includes timed execution rules and test priorities, enabling the generation of test tasks that meet the corresponding scheduling requirements in S302, thus achieving automatic management and resource allocation of test tasks. Timed execution rules are preset strategies that control the start time and execution cycle of test tasks. Their purpose is to enable test tasks to execute automatically without manual intervention.

[0088] Test priority refers to the identifier that determines the execution order of multiple test tasks when they coexist. Its purpose is to ensure that more important test tasks are executed first when resources are scarce.

[0089] One possible implementation uses the Quartz scheduler for timed execution and priority management of test tasks. Quartz is an open-source job scheduling library for automating the scheduled execution of test tasks. By configuring scheduled task expressions (Cron expressions), Quartz can precisely control the execution time of test tasks, supporting cyclic execution by minutes, hours, days, weeks, etc., and can also trigger tasks at specific times to meet the needs of periodic performance testing or interface stability inspection.

[0090] In the task scheduling process, a priority-based dynamic weighting mechanism can be used. The scheduling weight of each task is calculated using the following formula:

[0091] α, β, and γ are configurable weight coefficients. Task priorities are set by the user, and estimated execution time is predicted by analyzing historical task data and combining it with machine learning algorithms. Resource requirements cover CPU, memory, network bandwidth, etc. The system sorts the task queue according to the calculated scheduling weights, prioritizing the execution of tasks with higher weights. When system resources are insufficient, low-priority tasks are automatically paused to ensure the execution efficiency of high-priority tasks.

[0092] In terms of concurrency control, independent execution resources are allocated based on the resource requirements of test tasks through thread pool configuration and task grouping mechanisms. Larger thread pools are allocated for automated performance testing tasks to support high-concurrency scenarios; lightweight thread pools are allocated for API automation testing tasks to achieve a balance between resource utilization and execution efficiency. Simultaneously, a semaphore mechanism is introduced to provide fine-grained control over access to critical resources such as database connections and network bandwidth, avoiding execution failures caused by resource contention.

[0093] In this embodiment, by using test task configuration information, which includes test task configuration information, and by using the test task configuration information to indicate the timing execution rules and / or test priority of the test task, the test task is clearly defined as a work unit with corresponding scheduling attributes. This enables flexible scheduling and priority management of test tasks, allowing execution time to be arranged according to the actual test plan and ensuring that high-priority tasks are executed first, thereby improving the utilization efficiency of test resources and the timeliness of task execution.

[0094] In one embodiment, step S304 may include: S3041. Receive user input for test report generation requirements.

[0095] The test report generation requirements information refers to the conditions and parameters set by the user through the front-end interface for customizing the generation of test reports. These serve as the triggering conditions and target basis for data queries.

[0096] S3042. Generate data query instructions that match the distributed database based on the test report generation requirements information.

[0097] Data query commands are commands that are generated based on the requirements information in the test report and can be recognized and executed by a distributed database. They are used to translate user needs into specific database operations.

[0098] S3043. Perform data queries to the distributed database using data query commands.

[0099] The server backend sends data query commands to the distributed database, which then performs the retrieval and aggregation calculations defined within it.

[0100] S3044: Receive the first performance index data that matches the data query command.

[0101] The first performance metric data is the result dataset returned by the distributed database after querying and calculating according to the data query instructions, which meets the information required for generating the user's test report.

[0102] In one possible implementation, the distributed database is Elasticsearch (ES).

[0103] In this scenario, where S3042 generates data query instructions, the system generates requirement information based on the user-input test report, constructs corresponding ES query statements, and realizes the retrieval and aggregation calculation of test result data.

[0104] For example, using terms aggregation to group and count interface identifier fields can quickly obtain the number of errors for different interfaces. Date histogram aggregation can group time fields according to specified time intervals, calculating aggregated values ​​(summation, average, etc.) of performance metrics (such as response time, throughput) within each time interval, thereby analyzing the trend of performance metrics over time.

[0105] Specifically, for the specified interface (api_test_results-XXX- Taking the pass rate of the last 10 executions as an example to generate a test report, the interface quality trend analysis process is as follows: (1) Construct query request: Create a query for index "api_test_results-XXX- The system executes the search request and initializes the query builder to configure the query parameters.

[0106] (2) Get execution identifiers: Query the "execution_records" index to get a list of execution identifiers for the last 10 executions of this interface.

[0107] (3) Filter target data: Construct a query based on the above execution identifier list and filter the corresponding execution records in the target index.

[0108] (4) Configure aggregation analysis: Configure grouping by execution time (minute level), count the total number of test cases and the number of successful test cases for each execution, and then calculate the pass rate (number of successful cases / total number × 100%).

[0109] The operations in steps (1) to (4) together realize the generation of the data query instruction in S3042.

[0110] (5) Execute data query: Associate the aggregation configuration with the query request and execute it to obtain the query response results.

[0111] Step (5) corresponds to the execution process of S3043, which involves sending the constructed instructions to the ES database and obtaining the raw data.

[0112] (6) Parse the aggregated results: Parse the aggregated data in the query response and extract the execution time, total number of times, number of successes and pass rate for each execution.

[0113] The parsing result of step (6) is the first performance index data, which completes the transformation from database response to structured result data.

[0114] In this embodiment, test report generation requirements are received from user input, and a data query instruction matching the distributed database is generated based on this information, ensuring that the query conditions conform to the database characteristics. Data queries are then performed on the distributed database using the data query instruction, enabling efficient and accurate retrieval of the required data. Receiving the first performance indicator data matching the data query instruction ensures the accuracy and completeness of data extraction, thereby supporting the generation of highly targeted test analysis reports with reliable data sources, improving the speed and accuracy of report generation.

[0115] In one embodiment, the test report generation requirement information is used to indicate at least one of the following: time range, test type, or performance metric type.

[0116] The time range is the time interval for the test data set by the user, and its function is to limit the time dimension of the analysis. The test type refers to the test category selected by the user. The time range, test type, and performance indicator type together constitute the specific dimensions of the information required for generating the test report.

[0117] In one possible implementation, the test types include: automated performance testing and interface testing.

[0118] In this embodiment of the application, the test report generates requirement information to indicate at least one of the time range, test type, or performance indicator type, enabling users to flexibly set the report content according to specific analysis needs, and to perform targeted data extraction and analysis for different time spans, test types, or key indicators, thereby meeting diverse test evaluation needs and enhancing the practicality and relevance of the report.

[0119] In one embodiment, the software test management method may further include: S305. Store the test executor in a relational database.

[0120] The test execution program is the core of test task execution, and its content and related information (such as the project it belongs to and the applicable environment) constitute clearly structured data. Relational databases, with their inherent structure, can efficiently and reliably store this type of data, thereby enabling rapid retrieval and accurate updates of the execution program, ensuring the consistency and traceability of test task configurations.

[0121] S306. Receive and respond to a user-inputted program execution request, and invoke a test program stored in a relational database. The program execution request may include a program query request or a program modification request.

[0122] An Execution Program Invocation Request is a user-initiated command requesting a stored test execution program. An Execution Program Query Request is a user-requested query for information about a specific test execution program. An Execution Program Modification Request is a user-initiated request to modify, update, or delete a test execution program.

[0123] The execution program call request serves as an operation command, driving the system to perform corresponding operations on the test execution program stored in the relational database. The execution program query request and execution program change request, as specific operation types, respectively implement the functions of viewing and modifying the execution program.

[0124] In one feasible implementation, the user uploads the test executable program through the executable program management interface. This solution also needs to verify the user's operation permissions and perform format verification on the executable program file (including file extension check, basic syntax check, etc.). After passing the verification, the executable program is uploaded to the backend server and stored in a relational database.

[0125] In this embodiment, by storing the test executor in a relational database, centralized management and structured storage of the test executor are achieved; the system receives and responds to user input of executor call requests, and calls the test executor stored in the relational database. The executor call request includes an executor query request or an executor change request, which supports users to quickly retrieve and modify the executor, thereby improving the flexibility and maintenance efficiency of executor management.

[0126] In one embodiment, step S303 may include: S3031. Store the performance metrics data of the test execution program in a distributed database according to the classification rules.

[0127] Classification rules are the standards for organizing and categorizing performance indicator data. For example, classification rules can be based on test items or time periods.

[0128] Test item classification groups performance indicator data according to test item identifiers. Time period classification divides performance indicator data according to time dimensions (e.g., days, months, years).

[0129] Classification rules serve as organizational standards, guiding the storage method of performance indicator data in the distributed database. Test project classification and time period classification serve as specific classification dimensions, establishing data organization structures from the business and time dimensions, respectively.

[0130] In one possible implementation, the distributed database index design adopts a multi-index pattern, creating independent indexes for performance testing and interface testing respectively. For example, sharded indexes are automatically created according to the test executor name and execution time.

[0131] For example, the distributed database is Elasticsearch (ES) and the execution engine is JMeter.

[0132] Independent indexes include, for example, "performance_test_results-" and "api_test_results-". Sharded indexes include, for example, "performance_test_results-(script_id)-202507081430". All indexes enable _source field filtering, storing only necessary fields to reduce disk usage. This custom JMeter-ElasticSearchBackendlistener backend detector enables real-time storage of execution results. It is based on the open-source plugin jmeter-elasticsearch-backend-listener, with modifications made to handle SampleResult across different ElasticSearch versions, ensuring it uses the appropriate Request format for ElasticSearch version 8.x.

[0133] When using JMeter to execute test execution tasks, the performance metrics data (such as response time, throughput, error rate, etc.) generated during the test are written to the distributed database in real time. Different types of data, such as time-series data generated by performance testing and structured data of interface automation testing, are stored in a unified manner and indexed.

[0134] In one embodiment, the software test management method may further include: S307. Render the test analysis report into a data format for display.

[0135] The data format used for display refers to the data form that is presented intuitively in the user interface, including visual formats such as charts and tables, so that users can quickly understand the test results.

[0136] In this embodiment of the application, by rendering the test analysis report into a data format for display, the test results are presented in an intuitive form, making it easier for users to quickly obtain test information and improving the readability of the report and user experience.

[0137] In one embodiment, the software test management method may further include: S308. In the test analysis report used for display, the first indicator is displayed based on the first display format, and the second indicator is displayed based on the second display format. The first indicator does not meet the normal indicator conditions, while the second indicator meets the normal indicator conditions.

[0138] The first display format is a specific visual style used to identify abnormal test metrics. The second display format is a baseline visual style used to identify normal test metrics. The first metric is a test data metric that does not conform to the preset normal range. The second metric is a test data metric that conforms to the preset normal range. The first display format and the first metric, through differentiated display, quickly locate test anomalies. The second display format and the second metric maintain a normal visual presentation.

[0139] In this embodiment of the application, by displaying a first indicator based on a first display format and a second indicator based on a second display format in the displayed test analysis report, wherein the first indicator does not meet the normal indicator conditions and the second indicator does meet the normal indicator conditions, users can quickly distinguish between abnormal and normal indicators, highlight problem data, facilitate users to focus on and take corresponding measures, and enhance the practicality of the test report.

[0140] In one embodiment, testing pre-configuration information includes: Test project information, test environment parameters, and test task configuration information. Test project information includes the project name, project description, and associated test type. Test environment parameters indicate the network environment, relational database, and distributed database used for testing.

[0141] Test project information includes the project name, project description, associated test type, and the software to be tested. Its purpose is to categorize and manage test activities, clarifying test objectives and scope, and defining the specific test objects. Test environment parameters define the configuration data for the test execution environment, including network environment configuration and database connection information. Their purpose is to ensure that the software to be tested can execute in the correct environment, guaranteeing the accuracy of test results.

[0142] Test project information serves as the organizational framework, providing a basis for classifying and managing test activities. Test environment parameters serve as the execution environment, providing the necessary operating conditions for testing. Test task configuration information serves as scheduling rules, controlling the timing of test task execution and resource allocation.

[0143] In one possible implementation, the relational database is a MySQL database.

[0144] The basic project information, environment configuration parameters, task scheduling rules and other structured configuration data are stored in a MySQL database. By leveraging its structured storage characteristics, the consistency and reliability of the configuration data are ensured.

[0145] In this embodiment, the pre-test configuration information includes test project information, test environment parameters, and test task configuration information. The test project information includes the project name, project description, associated test type, and software to be tested. The test environment parameters indicate the network environment, relational database, and distributed database used for testing. This achieves comprehensive configuration of the test project and environment, ensuring that the test is executed in the correct network and data storage environment, improving the accuracy and resource coordination of the test, and facilitating the unified management and reuse of the test environment.

[0146] The following section, using a specific example from the perspective of server-distributed database (ES database) interaction, further introduces the software test management method provided in this application. Figure 4 A schematic diagram illustrating the data transmission process between the server and the distributed database is shown, such as... Figure 4 As shown, it may include: S400, the server backend sends a test task execution request to the JMeter test engine.

[0147] Based on the pre-test configuration information and test execution program of S300-S302, the server backend generates test tasks. Correspondingly, the server backend can send a test task execution request to the JMeter test engine, which includes the test task.

[0148] S401, the JMeter test engine sends a connection request to the Elasticsearch cluster.

[0149] After detecting the start of the test task, the JMeter test engine actively establishes a connection with the ES cluster to set up a communication channel for subsequent performance metric data transmission.

[0150] S402, The server backend transmits configuration information to the ES backend detector.

[0151] The configuration information is the pre-test configuration information used to initialize the Elasticsearch backend detector and guide it on how to communicate with the Elasticsearch cluster and store data. This includes control parameters such as the Elasticsearch cluster connection address and authentication credentials, and the batch write interval. It ensures that the detector can correctly connect to the target storage location and perform data write operations according to predetermined rules.

[0152] S403 and ES backend detectors create data queues in the local cache.

[0153] After establishing a connection and receiving configuration information, the ES backend detector creates a data queue in the local cache of the server where it resides. This data queue is used to temporarily store performance indicator data generated by the JMeter test engine during test tasks, realizing data buffering and batch processing. After the data queue stores a certain amount of performance indicator data, the server will generate a request in S406 to store the performance indicator data in the data queue into the storage request of the ES cluster.

[0154] After completing S401-S403 above, the performance index data during the execution of the test program in S303 can be stored in the distributed database. The specific steps are as follows: S404, the ES backend detector continuously detects and obtains performance metric data (SampleResult) generated by the JMeter test engine when performing test tasks.

[0155] After the S405 and ES backend detectors convert the acquired performance metric data into a data format suitable for ES cluster storage, they store it in a local cached data queue.

[0156] S406. After the server determines that the data queue stores a certain amount of performance index data, it sends a bulk storage request to the ES backend detector.

[0157] Among them, the storage request is used to request the storage of performance metric data in the data queue to the ES cluster.

[0158] S407 and the ES backend detector respond to storage requests by calling the performance metrics data stored in the local cache data queue, and then sending the performance metrics data to the ES cluster.

[0159] After S407, execute S404-S407 in a loop until the software testing task is completed.

[0160] The S408 and JMeter engines send test completion information to the ES backend detector.

[0161] When the test task is completed or the user actively stops the test, the JMeter test engine sends a test completion message to the Elasticsearch backend detector, notifying the detector that the test task has been completed and no new performance metric data will be generated. At this time, the locally cached data queue may not be full; in other words, the current loop's S406 has not been triggered, and there are still some unstored performance metrics remaining in the data queue. Optionally, in this case, the process may also include: S409: The ES backend detector retrieves the remaining performance metrics data stored in the local cache data queue and then sends the remaining performance metrics data to the ES cluster.

[0162] S410. After the ES backend detector receives the ES cluster's processing response for the last batch of data, the ES backend detector sends the storage result information to the JMeter test engine.

[0163] The S411 and JMeter testing engines transmit stored result information to the server backend.

[0164] After the JMeter engine transmits the final result to the server backend, the data transmission process between the server and the Elasticsearch distributed database officially ends.

[0165] In this embodiment, performance index data during the test execution process is stored in a distributed database according to classification rules, where the classification rules are based on test items or time periods. This achieves orderly organization and storage of performance data, facilitating rapid retrieval and aggregation analysis based on project or time dimensions, thereby improving the efficiency of data query and the accuracy of data analysis.

[0166] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0167] This application embodiment can divide the software test management device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0168] In some embodiments, this application also provides a software test management apparatus. The software test management apparatus may include one or more functional modules for implementing the software test management method of the above method embodiments.

[0169] For example, Figure 5 This is a schematic diagram illustrating the composition of a software test management device provided in an embodiment of this application. Figure 5 As shown, the software test management device 500 includes: a receiving module 501, a storage module 502, a generation module 503, and a running module 504.

[0170] The receiving module 501 is used to receive pre-test configuration information and test execution program input by the user. The test execution program is used to constrain the test process, and the pre-test configuration information is used to configure the runtime environment of the test process.

[0171] Storage module 502 is used to store pre-test configuration information in a relational database.

[0172] The generation module 503 is used to generate a test task queue based on the test pre-configuration information and the test execution program. The test task queue includes at least one test task.

[0173] The execution module 504 is used to call the test engine to run the test executor according to the test task queue, store the performance index data of the test executor in a distributed database, and store the execution result data of the test executor in a relational database.

[0174] The generation module 503 is also used to call the first performance index data stored in the distributed database, the first execution result data stored in the relational database, and the test pre-configuration information to generate a test analysis report. The first performance index data is the performance index data that matches the test report generation requirement information input by the user, and the first execution result data is the execution result data that matches the test report generation requirement information input by the user.

[0175] In one embodiment, the pre-test configuration information includes test task configuration information.

[0176] Test task configuration information is used to indicate the timing rules for test task execution and / or test priority.

[0177] In one embodiment, invoking first performance metric data stored in a distributed database includes: Receive user input to generate test report requirements.

[0178] Generate data query instructions that match the distributed database based on the test report's requirements.

[0179] Data queries are performed on the distributed database using data query commands.

[0180] Receive the first performance metric data that matches the data query command.

[0181] In one embodiment, the test report generation requirement information is used to indicate at least one of the following: time range, test type, or performance metric type.

[0182] In one embodiment, the receiving module 501 is further configured to store the test executor in a relational database.

[0183] It receives and responds to user-inputted program execution request, and invokes the test program stored in the relational database. The program execution request includes program query request or program change request.

[0184] In one embodiment, the running module 504 is further configured to store performance metrics data during the execution of the test executor in a distributed database, including: The performance metrics data during the execution of the test program are stored in a distributed database according to the classification rules, which are either classified by test item or by time period.

[0185] In one embodiment, the generation module 503 is further configured to render the test analysis report into a data format for display.

[0186] In one embodiment, the generation module 503 is further configured to display a first indicator based on a first display format and a second indicator based on a second display format in the displayed test analysis report, wherein the first indicator does not meet the normal indicator conditions and the second indicator meets the normal indicator conditions.

[0187] In one embodiment, testing pre-configuration information includes: Test project information, test environment parameters, and test task configuration information. Test project information includes the project name, project description, and associated test type. Test environment parameters indicate the network environment, relational database, and distributed database used for testing.

[0188] In the case of implementing the functions of the integrated modules described above in hardware, this embodiment of the invention provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 6 As shown, the electronic device 600 includes: a processor 602, a communication interface 603, and a bus 604. Optionally, the electronic device 600 may also include a memory 601.

[0189] Processor 602 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 602 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 602 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0190] Communication interface 603 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0191] The memory 601 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0192] In one possible implementation, the memory 601 can exist independently of the processor 602. The memory 601 can be connected to the processor 602 via a bus 604 and is used to store instructions or program code. When the processor 602 calls and executes the instructions or program code stored in the memory 601, it can implement the software test management method provided in this embodiment of the invention.

[0193] In another possible implementation, the memory 601 can also be integrated with the processor 602.

[0194] Bus 604 can be an extended industry standard architecture (EISA) bus, etc. Bus 604 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0195] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0196] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware. The program can be stored in the aforementioned computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The computer-readable storage medium can be any of the foregoing embodiments or memory. The aforementioned computer-readable storage medium can also be an external storage device of the aforementioned service invocation device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the aforementioned service invocation device. Further, the aforementioned computer-readable storage medium can include both internal storage units of the aforementioned service invocation device and external storage devices. The aforementioned computer-readable storage medium is used to store the aforementioned computer program and other programs and data required by the aforementioned service invocation device. The aforementioned computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0197] This application also provides computer instructions. All or part of the processes in the above method embodiments can be executed by computer instructions to instruct related hardware (such as computers, processors, network devices, and terminals). The program can be stored in the aforementioned computer-readable storage medium.

[0198] This application also provides a computer program product that, when run on a computer, causes the above-described method embodiments to be executed.

[0199] This application also provides a chip system. The chip system may be composed of chips or may include chips and other discrete devices, without limitation. The chip system includes a processor and a transceiver. All or part of the processes in the above method embodiments can be completed by this chip system, such as the chip system being used to implement the functions performed by the network devices or terminals in the above method embodiments.

[0200] In one possible design, the chip system further includes a memory for storing program instructions and / or data. When the chip system is running, the processor executes the program instructions stored in the memory to enable the chip system to perform the functions performed by the network device or terminal in the above method embodiments.

[0201] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A software test management method, characterized in that, include: The test execution program receives pre-test configuration information and test execution program input by the user. The test execution program is used to constrain the test process, and the pre-test configuration information is used to configure the runtime environment of the test process. The test pre-configuration information is stored in a relational database; A test task queue is generated based on the pre-test configuration information and the test execution program, and the test task queue includes at least one test task. The test engine is invoked to run the test execution program according to the test task queue, and the performance index data of the test execution program during its execution is stored in a distributed database, and the execution result data of the test execution program during its execution is stored in a relational database. The system calls the first performance index data stored in the distributed database, the first execution result data stored in the relational database, and the test pre-configuration information to generate a test analysis report. The first performance index data is the performance index data that matches the test report generation requirement information input by the user, and the first execution result data is the execution result data that matches the test report generation requirement information input by the user.

2. The method according to claim 1, characterized in that, The pre-test configuration information includes test task configuration information; The test task configuration information is used to indicate the timing execution rules and / or test priority of the test task.

3. The method according to claim 1, characterized in that, The first performance metric data stored in the distributed database that is invoked includes: Receive the test report generation requirements information input by the user; Based on the test report requirements, generate data query instructions that match the distributed database; The data query command is used to query the distributed database; Receive the first performance index data that matches the data query instruction.

4. The method according to claim 3, characterized in that, The test report generation requirements information is used to indicate at least one of the following: time range, test type, or performance indicator type.

5. The method according to claim 1, characterized in that, The method further includes: The test executor is stored in the relational database; The system receives and responds to user-inputted program invocation requests, and invokes the test program stored in the relational database. The program invocation request may include a program query request or a program modification request.

6. The method according to claim 1, characterized in that, The step of storing performance metric data during the execution of the test program in a distributed database includes: The performance metrics data during the execution of the test program are stored in a distributed database according to the classification rules, which are either classified by test item or by time period.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: The test analysis report is rendered into a data format for display.

8. The method according to claim 7, characterized in that, In the test analysis report used for display, a first indicator is displayed based on a first display format, and a second indicator is displayed based on a second display format. The first indicator does not meet the normal indicator conditions, while the second indicator meets the normal indicator conditions.

9. The method according to claim 1, characterized in that, The pre-test configuration information includes: The test project information, test environment parameters, and test task configuration information include the project name, project description, and associated test type. The test environment parameters are used to indicate the network environment, relational database, and distributed database used in the test.

10. A software test management device, characterized in that, include: The receiving module is used to receive pre-test configuration information and test execution program input by the user. The test execution program is used to constrain the test process, and the pre-test configuration information is used to configure the running environment of the test process. A storage module is used to store the pre-test configuration information in a relational database; A generation module is used to generate a test task queue based on the test pre-configuration information and the test execution program, wherein the test task queue includes at least one test task. The running module is used to call the test engine to run the test execution program according to the test task queue, store the performance index data of the test execution program in a distributed database, and store the execution result data of the test execution program in a relational database. The generation module is further configured to call the first performance index data stored in the distributed database, the first execution result data stored in the relational database, and the test pre-configuration information to generate a test analysis report. The first performance index data is the performance index data that matches the test report generation requirement information input by the user, and the first execution result data is the execution result data that matches the test report generation requirement information input by the user.

11. An electronic device, characterized in that, The device includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the software test management method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer-executable instructions that, when executed on a computer, cause the computer to perform the software test management method according to any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the software test management method as described in any one of claims 1 to 9.

Images