An automated testing method and electronic device

Abstract

The application discloses an automatic test method and an electronic device, and relates to the technical field of automation. Since the code package of a to-be-deployed service project is subjected to service chain feature extraction, then according to the extracted service chain features, a service chain test scene and corresponding automatic test cases for the to-be-deployed service project are generated, and subsequently, according to the service chain test scene and the automatic test cases, performance test is conducted on a to-be-tested device, so that the load applied to the to-be-tested device in the test process is matched with the actual load of the to-be-deployed service project, and the accuracy of the performance test result is improved, and the performance hidden danger for the subsequent deployment of the service project is avoided.

Description

Technical Field

[0001] This application relates to the field of automation technology, and in particular to an automated testing method and electronic device. Background Technology

[0002] The mainstream application scenario for servers and other equipment is currently in network service architecture projects. The business chain characteristics of such projects are highly coupled with the server's hardware computing power, system protocol support, and resource scheduling capabilities. Different types of projects have significantly different requirements for the server's basic resources. Therefore, to select a server that matches the business project to be deployed, performance testing is usually performed on the server beforehand. However, current performance testing methods often do not match the actual load of the business project to be deployed, reducing the accuracy of test results and creating potential performance risks for subsequent deployment. Summary of the Invention

[0003] This application provides an automated testing method and electronic device to at least address the problem that performance testing methods in related technologies often do not match the actual load of the business projects to be deployed, which reduces the accuracy of test results and creates potential performance risks for subsequent business project deployment.

[0004] This application provides an automated testing method, including: Obtain the code package of the business project to be deployed; Extract business chain features from the code package to obtain the business chain features of the business project to be deployed; Based on the business chain characteristics of the business project to be deployed, determine the service chain test scenario and corresponding automated test cases for the business project to be deployed; among them, the service chain test scenario includes at least the target test load, target test indicators and indicator judgment criteria, and the automated test cases are used to implement the service chain test scenario; Based on the service chain test scenario and automated test cases, performance tests are performed on the device under test to obtain the performance test results of the device under test for the business project to be deployed.

[0005] This application also provides an automated testing apparatus, including: The acquisition module is used to obtain the code package of the business project to be deployed. The feature extraction module is used to extract business chain features from the code package to obtain the business chain features of the business project to be deployed. The determination module is used to determine the service chain test scenario and corresponding automated test cases for the business project to be deployed based on the business chain characteristics of the business project to be deployed. The service chain test scenario includes at least the target test load, target test indicators and indicator judgment criteria, and the automated test cases are used to implement the service chain test scenario. The testing module is used to perform performance tests on the device under test based on service chain test scenarios and automated test cases, and obtain the performance test results of the device under test for the business project to be deployed.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described automated testing methods.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described automated testing methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described automated testing methods.

[0009] This application extracts business chain features from the code package of the business project to be deployed. Based on these features, service chain test scenarios and corresponding automated test cases are generated for the business project to be deployed. Subsequently, performance testing is performed on the device under test based on the service chain test scenarios and automated test cases. This ensures that the load applied to the device under test during the test matches the actual load of the business project to be deployed, thereby improving the accuracy of the performance test results and avoiding potential performance risks for subsequent deployment of the business project. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of the structure of the automated testing system on which the embodiments of this application are based; Figure 2 A flowchart illustrating the automated testing method provided in this application embodiment; Figure 3 A flowchart illustrating an exemplary automated testing method provided in this application embodiment; Figure 4 A flowchart illustrating another exemplary automated testing method provided in this application embodiment; Figure 5 A flowchart illustrating another exemplary automated testing method provided in this application embodiment; Figure 6A flowchart illustrating yet another exemplary automated testing method provided in this application embodiment; Figure 7 A schematic diagram illustrating the processing flow of performance test results provided in an embodiment of this application; Figure 8 A schematic diagram illustrating another performance test result processing flow provided in an embodiment of this application; Figure 9 A schematic diagram illustrating the update process of the service chain testing scenario and corresponding automated test cases provided in the embodiments of this application; Figure 10 This is a schematic diagram of the overall process of the automated testing method provided in the embodiments of this application; Figure 11 This is a schematic diagram of the structure of the automated testing device provided in the embodiments of this application; Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] Automated testing of server hardware and systems is a core verification step before servers leave the factory, are selected, and are deployed. It primarily tests the performance, compatibility, and stability of basic hardware and software components such as the server's CPU, memory, disk, network interface card (NIC), and system kernel. The test results directly determine the server's suitability for real-world application scenarios. Currently, the mainstream application scenario for servers is hosting Java Web architecture projects. The server's hardware computing power, system protocol support, and resource scheduling capabilities are highly coupled with the business characteristics of Java Web projects. Different types of Java Web projects (high-concurrency e-commerce, large-scale data reporting, multi-service dependent microservice projects, etc.) have significantly different hardware and system requirements for servers. High-concurrency e-commerce projects emphasize high-concurrency handling and NIC throughput capabilities, while large-scale data reporting projects have stringent requirements for disk I / O throughput and memory read / write speeds.

[0015] In related technologies, server testing and JavaWeb project business characteristic analysis are two independent work processes. Testers need to manually analyze the JavaWeb project code to extract business chain characteristics such as interface calls and data interactions, and then manually design simulated loads to conduct tests. This manual analysis process is labor-intensive, time-consuming, and prone to missing core characteristics, resulting in a disconnect between the test load and the actual business scenario. Consequently, the test results cannot reflect the server's true adaptability. At the same time, manually designed loads cannot cover the diverse testing needs of various JavaWeb businesses, resulting in insufficient test comprehensiveness and creating potential performance risks for subsequent server deployment and business operation.

[0016] To address the aforementioned technical issues, this application provides an automated testing method and electronic device. The method extracts business chain features from the code package of the business project to be deployed. Based on these features, it generates service chain test scenarios and corresponding automated test cases for the business project. Subsequently, performance testing is performed on the device under test using the service chain test scenarios and automated test cases. This ensures that the load applied to the device under test matches the actual load of the business project to be deployed, thereby improving the accuracy of performance test results and avoiding potential performance risks for subsequent business project deployment.

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

[0018] The specific application environment architecture or specific hardware architecture on which the execution of automated testing methods depends is described here.

[0019] First, the structure of the automated testing system on which this application is based will be described: The automated testing method and electronic device provided in this application are applicable to performance testing of servers and other devices under test that are planned to deploy JavaWeb projects (business projects to be deployed), in order to verify whether the devices under test are suitable for deploying the JavaWeb projects. Figure 1 The diagram shows the structure of the automated testing system based on the embodiments of this application, which mainly includes the device under test (DUT), a data acquisition device, and an automated testing device. The data acquisition device collects the code package of the business project to be deployed and sends the collected data to the automated testing device. The automated testing device extracts business chain features from the code package and then performs performance testing on the DUT for the business project to be deployed.

[0020] This application provides an automated testing method for performing performance tests on servers and other devices under test that are planned to deploy Java Web projects (business projects to be deployed), in order to verify whether the devices under test are suitable for deploying the Java Web projects. The execution subject of this application embodiment is an electronic device, such as a server, desktop computer, laptop computer, tablet computer, or other electronic devices that can be used to perform performance testing on the devices under test.

[0021] like Figure 2 The diagram shown is a flowchart of an automated testing method provided in an embodiment of this application. The method includes: Step 201: Obtain the code package of the business project to be deployed.

[0022] The business project to be deployed refers to the business application that needs to be deployed to the device under test. This project can include a business system developed based on a JavaWeb architecture, also known as a JavaWeb project. The code package is a collection of program code that makes up the business project to be deployed, describing its business logic, interface call relationships, data access logic, and service dependencies. The code package can include source code files, configuration files, dependency description files, and database access configuration files.

[0023] Step 202: Extract business chain features from the code package to obtain the business chain features of the business project to be deployed.

[0024] The business chain characteristics of the business project to be deployed are used to characterize the business call relationships, data interaction, service dependencies, and resource consumption during the actual operation of the business project. A business chain refers to the data processing link formed after a user request passes through multiple interfaces, service components, and database operations within the business system. For example, if the business project to be deployed is an e-commerce business project, then the order interface, order service, inventory service, payment service, and database that a user order request passes through in sequence constitute a business chain.

[0025] Step 203: Based on the business chain characteristics of the business project to be deployed, determine the service chain test scenario and corresponding automated test cases for the business project to be deployed.

[0026] The service chain test scenario includes at least the target test load, target test metrics, and metric judgment criteria, and automated test cases are used to implement the service chain test scenario.

[0027] It should be noted that the Service Link Test Scenario (SLTS) is used to describe a server performance test environment built for specific business chain characteristics. The target test load describes the business pressure applied to the device under test during the test, such as the number of concurrent users, interface request frequency, data transfer scale, and test duration. The target test metrics describe the server performance parameters that need to be collected during the performance test, such as CPU utilization, memory usage, disk I / O throughput, network throughput, and request response time. The metric judgment criteria are used to determine whether the collected target performance metrics meet the business operation requirements of the project to be deployed.

[0028] Step 204: Based on the service chain test scenario and automated test cases, perform performance testing on the device under test to obtain the performance test results of the device under test for the business project to be deployed.

[0029] Specifically, corresponding test requests can be generated based on automated test cases, so that the device under test can respond to the test request and generate runtime status data. Then, according to the target test indicators represented by the service chain test scenario, the runtime status data generated by the device under test can be used to collect corresponding actual performance indicators, thereby obtaining the performance test results of the device under test for the business project to be deployed.

[0030] The automated testing equipment implementing the automated testing method provided in this application includes a dedicated intelligent feature extractor for server testing, deployed on an industrial-grade server's Xilinx UltraScale+ FPGA chip and Java parser. The FPGA chip of the feature extractor is physically connected to the server motherboard via a PCIe 4.0 x16 interface, with a data transfer rate ≥ 16 GB / s. The Java parser is deployed in the on-chip memory (OCM) of the FPGA chip and interacts with the FPGA's logic operation unit via an AXI4 bus. The feature extractor has no architectural association or data communication with the code analysis tools used in the development phase. The feature extractor has built-in seven-level functions optimized for server testing scenarios, compatible with mainstream Java Web frameworks such as SSM, Spring Boot, and Spring Cloud. The seven-level functions are executed in the parallel operation unit of the FPGA chip.

[0031] Based on the above embodiments, such as Figure 3 The diagram shown illustrates an exemplary automated testing method provided in this application. As an implementable approach, in one embodiment, business chain features are extracted from the code package to obtain the business chain features of the business project to be deployed, including: Step 2021: Perform code parsing on the code package to obtain the code parsing results; Step 2022: Based on the code parsing results, analyze the interface characteristics of the business project to be deployed; Step 2023: Based on the code parsing results and interface characteristics, determine the data interaction characteristics of the business project to be deployed; Step 2024: Based on the code parsing results and data interaction characteristics, determine the concurrent request threshold for the business project to be deployed; Step 2025: Based on the code parsing results, analyze the service dependency hierarchy characteristics of the business project to be deployed; Step 2026: Based on the code parsing results and service dependency hierarchy characteristics, determine the database interaction patterns of the business project to be deployed; Step 2027: Based on interface characteristics, data interaction characteristics, service dependency hierarchy characteristics, and database interaction pattern characteristics, determine the peak resource consumption prediction results for the business project to be deployed; The business chain characteristics of the business project to be deployed include at least the business type, interface characteristics, data interaction characteristics, concurrent request threshold, database interaction pattern characteristics, and peak resource consumption prediction results represented by the code parsing results. The extraction of the above business chain characteristics is based on the feature extractor. After obtaining the business chain characteristics of the business project to be deployed, the business chain characteristics are transmitted to the Server Model Cache (SMC) through the PCIe 4.0 interface.

[0032] Specifically, in order to obtain the internal business logic structure of the business project to be deployed, the code package is first parsed. Code parsing is the process of analyzing the program characters in the code file according to the syntax rules of the programming language used by the business project to be deployed in order to obtain code structure information.

[0033] Among them, interface features are used to describe the number, call relationships, and call complexity of each business interface when the business project to be deployed provides business services to the outside world; data interaction features are used to describe the data transmission between each interface, service component, and database during the execution of business requests; concurrent request threshold is used to indicate the maximum number of business requests that the business project to be deployed can handle simultaneously while meeting the preset response time requirements; service dependency layer features are used to describe the dependency relationships between different service components within the business project; database interaction pattern features are used to describe database access behavior during business execution; and resource consumption peak prediction results are used to indicate the maximum resource consumption that the business project to be deployed may reach under the target business load.

[0034] Specifically, in this embodiment of the application, the code package of the business project to be deployed has undergone the above seven-level analysis to ensure that the final business chain features cover all the core features of the business chain of the business project to be deployed. This further ensures that the load applied to the device under test during the test matches the actual load of the business project to be deployed, thereby improving the accuracy of the performance test results. The test results can truly reflect the actual adaptability of the device under test to the business project to be deployed, without any test bias.

[0035] Specifically, in one embodiment, the code package can be parsed to extract the word stream in the code package; the word stream can be converted into an abstract syntax tree based on the context information represented by the word stream; and the abstract syntax tree can be traversed to determine the global symbol table of the code package.

[0036] The code parsing results include an abstract syntax tree and a global symbol table, which includes class names, method names, annotation metadata, and import dependencies.

[0037] Specifically, the source code files in the code package are first subjected to syntactic analysis to extract the corresponding token stream. Since the business project to be deployed in this embodiment is a JavaWeb project, the tokens at least include keywords, identifiers, class names, method names, annotation metadata, and import dependencies. Further, based on the contextual relationships between tokens in the token stream, the token stream is parsed to determine the hierarchical and relational relationships between tokens. The token stream is then converted into an abstract syntax tree, which represents the hierarchical and relational relationships between tokens in the code package in a tree structure.

[0038] Furthermore, the nodes in the abstract syntax tree can be traversed to construct the global symbol table corresponding to the code package. The global symbol table is used to record the program entities in the code package and the association information between program entities, including class names, method names, annotation metadata, and import dependencies.

[0039] Specifically, in one embodiment, the interface declaration information in the business project to be deployed can be determined based on the code parsing results; the calling relationship between each interface can be determined based on the interface declaration information; the interface calling topology diagram of the business project to be deployed can be constructed based on the calling relationship between each interface; and the number of interfaces, interface calling level, and interface calling frequency of the business project to be deployed can be determined based on the interface calling topology diagram.

[0040] The interface characteristics include the number of interfaces, the interface call level, and the interface call frequency.

[0041] Specifically, the interface declaration information in the business project to be deployed can be identified based on the abstract syntax tree and global symbol table in the code parsing results. The interface declaration information represents the interface information that provides external service access capabilities in the business project, including the interface access path, request method, request parameters, return data type, and the corresponding method information.

[0042] Furthermore, the call relationships between interfaces can be determined based on the interface declaration information and the method call relationships in the code parsing results. Specifically, the method call chain corresponding to an interface can be analyzed to identify other interfaces called during the interface's execution, and the association between interfaces can be determined based on the call direction. For example, when the method corresponding to the order creation interface calls the order service interface, and the order service interface further calls the inventory query interface, a call relationship can be determined between the order creation interface and the order service interface, and between the order service interface and the inventory query interface. Based on the call relationships between the interfaces, each interface is treated as a node, and the call relationships between interfaces are treated as connecting edges, thus constructing the interface call topology diagram of the business project to be deployed.

[0043] Furthermore, based on the interface call topology diagram, statistical analysis is performed on the number of interface nodes, the hierarchical relationship between nodes, and the number of interface calls to determine the number of interfaces, the interface call level, and the interface call frequency corresponding to the business project to be deployed. Specifically, the number of interfaces represents the total number of business interfaces included in the business project to be deployed; the interface call level represents the hierarchical position of the interface in the business call chain, reflecting the call depth between interfaces; and the interface call frequency represents the number of times each interface is called per unit time, reflecting the access pressure of different interfaces during business operation.

[0044] Specifically, in one embodiment, the data read and write operations corresponding to each interface can be determined based on the code parsing results; based on the data read and write operations, the number of data accesses, the amount of data transmitted in a single transaction, and the total amount of data interaction per unit time for each interface can be counted; based on the call relationship between each interface characterized by the interface features, the number of data accesses, the amount of data transmitted in a single transaction, and the total amount of data interaction per unit time for each interface can be mapped to the corresponding interface call chain; based on the changes in the amount of data transmitted in each interface call chain, the data flow path of the business project to be deployed can be determined.

[0045] Among them, data interaction characteristics include the number of data accesses, the amount of data transmitted in a single transaction, the total amount of data interaction per unit time, and the data flow path.

[0046] Specifically, based on the abstract syntax tree, global symbol table, and method call relationships in the code parsing results, the data access behavior corresponding to each interface in the business project to be deployed can be analyzed to determine the data read and write operations corresponding to each interface. Based on the identified data read and write operations, statistical analysis is performed on the data interaction of each interface to determine the number of data accesses, the amount of data transferred in a single transaction, and the total amount of data interaction per unit time for each interface. Here, the number of data accesses represents the number of times data resources are read or written during interface execution; the amount of data transferred in a single transaction represents the scale of data transferred during the processing of a single business request by the interface; and the total amount of data interaction per unit time represents the total amount of data transferred by the interface within a preset time period.

[0047] Furthermore, based on the call relationships between interfaces in the interface characteristics, the number of data accesses, the amount of data transferred per transaction, and the total amount of data interaction per unit time for each interface are mapped to the corresponding interface call chain to establish the association between interface call relationships and data interaction behavior. For example, when a business request sequentially passes through the order interface, inventory interface, and payment interface, the amount of data transferred during the call process of these interfaces can be obtained respectively, and the corresponding data interaction parameters can be associated with the call chain. Further, based on the changes in the amount of data transferred in each interface call chain, the data transmission process between different interfaces during the execution of the business request is analyzed to determine the data flow path of the business project to be deployed. The data flow path is used to characterize the transmission direction, transmission nodes, and changes in data scale of business data in the business chain.

[0048] By conducting correlation analysis on interface call relationships and data interaction behaviors, the data access pressure and data transmission patterns of the business project to be deployed during actual operation can be accurately described, so as to determine whether the subsequent service chain test scenario matches the data access pressure and data transmission patterns of the business project to be deployed during actual operation.

[0049] Specifically, in one embodiment, the thread call relationship and request processing logic corresponding to each interface in the business project to be deployed can be determined based on the code parsing results; the number of threads occupied and the request response time of each interface can be determined based on the thread call relationship and request processing logic corresponding to each interface; a concurrent request pressure model of the business project to be deployed can be established based on the number of threads occupied, the request response time and data interaction characteristics of each interface; and the maximum number of requests processed by each interface can be determined based on the concurrent request pressure model, under the condition of satisfying the preset response time constraint.

[0050] The concurrent request threshold includes the maximum number of requests that each interface can process.

[0051] Specifically, based on the abstract syntax tree, global symbol table, and method call relationships in the code parsing results, the thread call relationships and request processing logic corresponding to each interface in the business project to be deployed can be determined. The thread call relationship characterizes the thread creation, thread invocation, and data interaction relationships between threads involved in the execution of the business request during interface execution. Specifically, the thread resources invoked during the execution of each interface can be determined by analyzing thread creation statements, thread pool configurations, asynchronous method calls, and the service call chain corresponding to the interface in the code.

[0052] Furthermore, based on the thread call relationships and request processing logic corresponding to each interface, the thread usage and request response time of each interface can be determined. The thread usage represents the number of thread resources occupied by a single interface during business request processing, and can be determined based on the number of method calls, the number of parallel processing tasks, and thread pool configuration parameters. The request response time represents the time elapsed from receiving a business request to returning a processing result. Based on the thread usage, request response time, and data interaction characteristics of each interface, a concurrent request pressure model for the business project to be deployed is established. This model describes the correspondence between interface processing capacity, resource usage, and response time changes under different concurrent request volumes. Based on the concurrent request pressure model, as the number of concurrent requests to the interfaces gradually increases, the change in request response time for each interface is calculated, and it is determined whether the request response time meets the preset response time constraint. When the number of concurrent requests increases to a certain threshold, if the interface request response time reaches or exceeds the preset response time constraint, then that number of concurrent requests is determined as the maximum request processing capacity for the corresponding interface. This provides a reliable basis for the target test load in the subsequent service chain test scenario, ensuring that the concurrent pressure applied during the test process matches the actual operation of the business project to be deployed.

[0053] Specifically, in one embodiment, service components in the business project to be deployed can be determined based on the import dependencies, class call relationships, and method call relationships represented by the code parsing results; a service dependency graph can be constructed based on the call relationships between the service components; and the dependency level, call path, and service node corresponding to each service component can be determined based on the service dependency graph.

[0054] Among them, the service dependency hierarchy features include the dependency hierarchy, call path and service node corresponding to each service component.

[0055] Specifically, service components in the business project to be deployed can be identified based on import dependencies, class call relationships, and method call relationships found in the code parsing results. A service component is a program module in the business project to be deployed that undertakes independent business processing functions, and can include business service components, data access components, third-party calling components, and common function components. Specifically, by analyzing class names, method signatures, and import dependencies in the global symbol table, the relationships between different program entities in the code package can be determined. Further, by combining this with the method call relationships recorded in the abstract syntax tree, the call direction between each program entity can be identified, thereby determining the service components in the business project to be deployed. For example, when a class contains business processing methods that call methods of other business classes or data access classes, it can be determined that this class corresponds to a service component, and the dependency relationship between this service component and the called component can be established. Then, based on the call relationships between the service components, a service dependency graph of the business project to be deployed is constructed. The service dependency graph describes the dependencies between different service components and can include service nodes and dependency edges connecting different service nodes. Specifically, the identified service components can be used as service nodes, and the relationship between one service component and another can be used as dependency edges. The direction of the dependency edges is determined based on the direction of the call. For example, when the order service component calls the inventory service component, a directed dependency edge is established in the service dependency graph, pointing from the order service node to the inventory service node.

[0056] Furthermore, the connection relationships between service nodes can be analyzed based on the service dependency graph to determine the dependency level, call path, and service node corresponding to each service component. The dependency level indicates the hierarchical position of a service component in the business call chain and can be determined based on the upstream and downstream relationships of service nodes in the service dependency graph. The call path indicates the sequence of service nodes that a business request passes through when it is transmitted between different service components.

[0057] Specifically, in one embodiment, the database operation type corresponding to the business project to be deployed can be identified based on the database access statements and database connection configuration represented by the code parsing results; the number of database queries, data updates, transactions, and database connections can be determined based on the database operation type; and the data access path between each service node and the database can be determined based on the service dependency hierarchy characteristics.

[0058] Among them, the characteristics of database interaction patterns include the number of database queries, the number of data updates, the number of transactions, the number of database connections, and the data access paths between each service node and the database.

[0059] Specifically, database interaction behaviors in the business project to be deployed can be identified based on the database access statements and database connection configurations in the code parsing results. The database connection configuration represents the connection information used when the business project establishes a connection with the database, including the database type, connection address, connection pool configuration, and connection limit. Specifically, by traversing the method call nodes in the abstract syntax tree, code snippets containing database access keywords, data access interfaces, and persistence operation methods can be identified. Combined with database-related dependency information in the global symbol table, the database operation type corresponding to the business project to be deployed can be determined. These database operation types include data query operations, data insertion operations, data update operations, data deletion operations, and transaction processing operations.

[0060] Furthermore, based on the identified database operation types, statistical analysis can be performed on the database access behavior of the business project to be deployed to determine the number of database queries, data updates, transactions, and database connections. Specifically, the number of database queries represents the number of times a query operation is performed on the database during the execution of a business request; the number of data updates represents the number of times new, modified, or deleted business data is added to the database; the number of transactions represents the number of times transactions are started, committed, or rolled back during business execution; and the number of database connections represents the number of database connections established during business operation. Based on the service nodes and service call paths in the service dependency hierarchy characteristics, the data access path between each service node and the database is determined. Specifically, the data transmission link between the service node and the database node can be analyzed based on the call relationships between service components and data access components in the service dependency diagram.

[0061] In particular, by performing correlation analysis on the database operation behavior and service dependencies of the business projects to be deployed, the database access pressure and data interaction patterns of the business projects to be deployed can be obtained even when the business projects are not actually running. This provides a data foundation for the subsequent establishment of business chain resource consumption models, prediction of peak resource usage, and generation of service chain test scenarios that match the actual operation of the business.

[0062] Specifically, in one embodiment, a business chain resource consumption model can be established based on interface characteristics, data interaction characteristics, service dependency hierarchy characteristics, and database interaction pattern characteristics. Based on the business chain resource consumption model, the processor resource utilization rate, memory utilization, disk I / O load, and network bandwidth utilization corresponding to the business project to be deployed are predicted under different business load conditions. Peak values ​​are calculated for the processor resource utilization rate, memory utilization rate, disk I / O load, and network bandwidth utilization predicted under different business load conditions to obtain the peak values ​​of processor resource utilization rate, memory utilization rate, disk I / O load, and network bandwidth utilization.

[0063] The peak resource usage prediction results include peak processor resource usage, peak memory usage, peak disk I / O load, and peak network bandwidth usage.

[0064] It should be noted that the business chain resource consumption model is used to describe the resource consumption changes of each business chain node under different business load conditions for the business project to be deployed. Business load conditions are used to represent the different request pressure states that may be generated during the operation of the business project to be deployed, which may include different numbers of concurrent requests, different API call frequencies, and different data interaction scales.

[0065] Specifically, by fusing and analyzing various features, the system can predict server resource consumption under different business load conditions before the actual operation of the business project to be deployed, and obtain the corresponding peak resource usage. This enables the system to generate performance test parameters that match the actual business operation based on the interface characteristics, data interaction characteristics, service dependency layer characteristics, and database interaction patterns of the business project to be deployed, thereby improving the accuracy of subsequent performance test results.

[0066] Based on the above embodiments, such as Figure 4 The diagram shown illustrates another exemplary automated testing method provided in this application. As an implementable approach, in one embodiment, the service chain test scenario and corresponding automated test cases for the business project to be deployed are determined based on the business chain characteristics of the project, including: Step 2031: Generate standardized business chain feature modeling data based on the business chain characteristics of the business project to be deployed; Step 2032: Generate service chain test scenarios based on standardized business chain feature modeling data; Step 2033: Generate corresponding automated test cases based on the target test load and target test metrics in the service chain test scenario.

[0067] The business chain characteristics of the business projects to be deployed can be represented in a standardized feature data format of <business type-feature dimension-numerical threshold-related feature indicators>. Among them, business type can be divided into e-commerce, transportation and enterprise management, etc. Feature dimension is used to represent the total number of feature types in the business chain characteristics. Numerical threshold is used to represent the threshold corresponding to each related feature indicator. Related feature indicators include interface call frequency (interface call frequency), data access frequency, single data transmission volume (single interface data interaction volume), total data interaction volume per unit time, maximum request processing volume of each interface, database query frequency, data update frequency, transaction processing frequency, database connection frequency, peak processor resource utilization, peak memory utilization, peak disk I / O load, and peak network bandwidth utilization, etc.

[0068] Specifically, according to preset coding rules and the business chain characteristics of the business project to be deployed, exclusive attributes such as business type tags and 16-bit feature identifiers can be added. The 16-bit feature identifier is generated as <4-bit business type code + 4-bit feature type code + 4-bit feature indicator code + 4-bit unique checksum>. The checksum is implemented by truncating the last 4 bits using the MD5 algorithm to generate corresponding standardized business chain feature modeling data. The specific related feature indicators selected for encoding from the business chain features can be chosen according to actual needs, with the aim of selecting feature indicators strongly correlated with the performance of the server (device under test).

[0069] After obtaining standardized business chain feature modeling data, it can be stored in JSON format in a server-model matching cache pool (SMC) consisting of a 1.92TB NVMe SSD and Redis 6.2.x cache. This implements a dual mechanism of temporary cache storage and persistent disk storage, with a synchronization frequency of 10 seconds per instance. It has no data interaction with other modeling pools, ensuring data independence. The JSON format includes fixed fields such as business type code, feature type code, feature indicator code, and timestamp. The SMC cache pool enables the reuse of business chain feature data and test scenarios for business projects of the same business type. That is, when extracting business chain features for subsequent deployment projects of the same business type, if it is determined that the SMC cache pool stores business chain feature data for the same business type, it can be directly reused, saving the business chain feature extraction process, reducing repetitive work costs, and achieving test standardization.

[0070] Specifically, such as Figure 5The diagram illustrates another exemplary automated testing method provided in this application. Based on the application plan of the device under test (DUT), a corresponding JavaWeb business type is selected on the testing platform. Then, standardized business chain feature modeling data matching the specified type is automatically retrieved from the Service Chain Management (SMC). The application plan characterizes which type of JavaWeb project the DUT will subsequently deploy. Specifically, the feature indicators of the standardized business chain feature modeling data are mapped to specific stress application parameters by combining the hardware configuration parameters and system operating environment of the DUT, thereby generating a service chain test scenario. Further, corresponding automated test cases are generated based on the target test load and target test indicators in the service chain test scenario. For example, a concurrency gradient adjustment rule with a step size of 100 (range 100 to 10000) is set according to the concurrent request threshold in the target test load, and an adjustable indicator collection frequency of 1 to 5 seconds and a test duration of 24 hours (h), 72 hours (h), or 168 hours (h) are configured. The basic configuration of the test cases includes test execution steps and standardized exception tracing paths. For containerized deployment environments, automated test cases include Docker API v2.0 dedicated call interfaces and standardized parameter configuration rules for image pulling, container startup, and load injection. The image pulling timeout is set to 300 seconds, and the container startup memory threshold can be configured as 2GB / 4GB / 8GB.

[0071] Specifically, in one embodiment, such as Figure 6 The diagram shown illustrates another exemplary automated testing method provided in this application. It generates a test request based on performance test configuration information represented by automated test cases; sends the test request to the device under test (DUT) through a target test interface to obtain actual performance data of the DUT during the execution of the test request; and determines the performance test results of the DUT for the business project to be deployed based on the actual performance data, the target test indicators represented by the service chain test scenario, and the indicator judgment criteria.

[0072] Among them, performance test configuration information refers to the set of parameters defined in automated test cases to constrain the test execution process, such as concurrent load gradient, metric collection frequency, test duration, and containerized deployment parameters; Specifically, based on the performance test configuration information represented by automated test cases, test requests are generated, and then the test requests are sent to the device under test through the target test interface (such as the HTTP / HTTPS dedicated interface of the TCP / IP v4 8080 dedicated port) to obtain the actual performance data of the device under test during the execution of the test requests.

[0073] To ensure the security of the device under test, a token authentication mechanism can be pre-configured to set the validity period and access permissions of the target test interface. This ensures that only automated devices can send test requests to the device under test through the target test interface within the valid validity period. The device under test can be a physical machine, a virtual machine, or a containerized server (implementing load balancing through the Docker API v2.0, configuring standardized parameters for image pulling, container startup, and load injection).

[0074] Specifically, by enabling the device under test (DUT) to execute test requests, full-dimensional automated testing of the DUT can be achieved, such as customized hardware performance testing, dedicated system compatibility testing, high concurrency load limit testing, and long-term stability testing. Among them, the hardware performance customization test is based on customized business loads to verify the matching degree between hardware indicators such as CPU computing power and memory read / write speed and business requirements. Indicator data is collected in real time through hardware monitoring tools such as PerfMon and nmon with millisecond-level accuracy. The system compatibility test verifies the adaptability of the system kernel, network protocols and other features to the characteristics of the business chain. It focuses on testing the support of TCP / IP, HTTP / HTTPS protocols, resource scheduling and interface compatibility, and adapts to mainstream systems such as CentOS 7.9, Ubuntu 20.04 and Windows Server 2019. The high concurrency load limit test simulates the high concurrency request characteristics (concurrency request threshold) in the business chain characteristics. The concurrency gradient is increased in steps of 100 to verify the server's extreme load capacity and stability, and hardware error information under the peak concurrency is recorded. The long-term stability test loads 80% of the daily operating load in the business chain characteristics and tests for a preset duration to verify the hardware and system stability under continuous operation. An hourly snapshot of the running status is generated.

[0075] Furthermore, during the testing process, performance and operational data of the device under test can be collected at a preset frequency to obtain the actual performance data of the device under test, thereby generating a performance snapshot (SPS) of the device under test. The SPS is then uniquely bound to the feature identifier of the service chain test scenario to ensure that the test data is accurately associated with the business feature data.

[0076] Specifically, in one embodiment, such as Figure 7 The diagram shown is a schematic of a performance test result processing flow provided in an embodiment of this application. The actual performance data can be standardized according to the target test index and the target data form represented by the index judgment standard to obtain standardized actual performance data consistent with the target data form. According to the index judgment standard, it is determined whether each actual performance index represented by the standardized actual performance data exceeds the preset normal range. The actual performance index that exceeds the preset normal range is regarded as an abnormal performance index.

[0077] The performance test results should include at least abnormal performance indicators.

[0078] Specifically, since the actual performance data involves a variety of performance indicators, in order to facilitate subsequent comparisons, each performance indicator can be uniformly compressed to between 0 and 1 (data normalization processing, standardization mapping to between 0 and 1) to obtain standardized actual performance data consistent with the target data format.

[0079] Furthermore, if the fluctuation of any performance indicator exceeds ±3 times the standard deviation, the performance indicator can be determined as an abnormal performance indicator, in order to avoid misjudging slight normal fluctuations in performance indicators as abnormal performance indicators.

[0080] Furthermore, in one embodiment, abnormal performance indicators can be classified to determine the anomaly type of the device under test; wherein, the anomaly type is at least divided into four types: hardware performance bottleneck, system compatibility problem, insufficient resource scheduling, and network transmission failure, and the performance test results also include the anomaly type; based on the performance test results, a business chain feature matching degree report between the device under test and the business project to be deployed is generated; the business chain feature matching degree report, actual performance data, standardized business chain feature modeling data, and service chain test scenario are associated and stored in a preset cache pool.

[0081] Specifically, the K-means classification algorithm can be used to categorize abnormal performance indicators to determine the type of anomaly in the device under test. Abnormal indicators are then visually marked with color coding: red for hardware performance bottlenecks, yellow for system compatibility warnings, orange for insufficient resource scheduling, and green for normal indicators. Testers can click on a color-coded node and, via a RESTful interface, be redirected within 1 second to the corresponding BCF (Business Chain Feature) characteristic, test load, server anomaly logs, and detailed indicator collection page, enabling precise anomaly location and tracing. The hardware monitoring module of this visual color coding device is physically connected to the Redis cache via a PCIe 4.0 interface to ensure efficient data retrieval.

[0082] Furthermore, such as Figure 8The diagram shown illustrates another performance test result processing flow provided in this application embodiment. It can automatically generate a Server-JavaWeb Business Chain Feature Matching Report (SFPE) based on data analysis results, clearly defining the server's compatible business type, inapplicable scenarios, quantitative performance optimization suggestions, hardware upgrade directions, and specific parameters for system configuration adjustments. Simultaneously, it saves BCF modeling data (standardized business chain feature modeling data), SLTS test scenarios (service chain test scenarios), SPS performance data (actual performance data), and the SFPE report (business chain feature matching report) in the format <Device Number-Test Time-Project Business Type> to the local SMC cache. Combined with the GIT 2.30+ version management tool, historical test records are uploaded to a remote GitLab repository, enabling full lifecycle traceability and management of test records. These records can be directly reused for automated testing of devices with the same configuration in business projects of the same business type.

[0083] Specifically, in one embodiment, the similarity between the actual performance data and the standard performance data of the business project to be deployed can be used to determine whether the service chain test scenario matches the actual business scenario of the business project to be deployed; if the service chain test scenario does not match the actual business scenario of the business project to be deployed, the actual performance data is discarded, and the service chain test scenario and corresponding automated test cases of the business project to be deployed are re-determined.

[0084] Specifically, the actual performance data generated in this test can be compared and scored with the standard performance data generated by the business project to be deployed during real-world operation. If the score is below 0.8, it indicates that the current load testing scenario differs too much from the real business scenario, meaning the service chain test scenario does not match the actual business scenario of the business project to be deployed. The currently measured data is meaningless, so the actual performance data can be discarded without further anomaly analysis, and the service chain test scenario and corresponding automated test cases should be regenerated. The method for regenerating the service chain test scenario and corresponding automated test cases is the same as the initial generation method, and will not be elaborated here.

[0085] Specifically, in one embodiment, such as Figure 9The diagram illustrates the update process of the service chain test scenario and corresponding automated test cases provided in this application embodiment. When a new JavaWeb business type is added or the business chain characteristics of any business project change, the updated code package can be imported into the intelligent feature extractor to rescan and generate new business chain characteristics, and perform incremental / full updates on the SMC (incremental updates target the changed features, modifying only the changed fields; full updates target the new business type, generating a brand new 16-bit feature identifier). The automated testing equipment can achieve real-time synchronization of SMC update data through the RabbitMQ message queue, automatically updating the corresponding service chain test scenario and corresponding automated test cases without manual redesign, realizing dynamic adaptation of the service chain test scenario to changes in business chain characteristics. The test scenario setup cycle for new business types can be controlled within 30 minutes.

[0086] For example, such as Figure 10 The diagram shown is a schematic representation of the overall process of the automated testing method provided in this application embodiment. Figure 10 The process shown is as follows Figure 2 The illustrated process is an exemplary implementation, and the two implementations are based on the same principle, so they will not be described again.

[0087] The automated testing method provided in this application extracts business chain features from the code package of the business project to be deployed. Then, based on the extracted business chain features, it generates service chain test scenarios and corresponding automated test cases for the business project to be deployed. Subsequently, based on the service chain test scenarios and automated test cases, it performs performance testing on the device under test to ensure that the load applied to the device under test during the test matches the actual load of the business project to be deployed, thereby improving the accuracy of the performance test results and avoiding potential performance risks for subsequent deployment of the business project.

[0088] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0089] Embodiments of this application also provide an automated testing apparatus for executing the automated testing method provided in the above embodiments.

[0090] like Figure 11 The diagram shown is a structural schematic of the automated testing device provided in an embodiment of this application. The automated testing device 110 includes: an acquisition module 1101, a feature extraction module 1102, a determination module 1103, and a testing module 1104.

[0091] The system comprises the following modules: an acquisition module for acquiring the code package of the business project to be deployed; a feature extraction module for extracting business chain features from the code package to obtain the business chain features of the business project to be deployed; a determination module for determining the service chain test scenario and corresponding automated test cases for the business project to be deployed based on the business chain features; wherein the service chain test scenario includes at least the target test load, target test metrics, and metric judgment criteria, and the automated test cases are used to implement the service chain test scenario; and a test module for performing performance tests on the device under test based on the service chain test scenario and the automated test cases to obtain the performance test results of the device under test for the business project to be deployed.

[0092] Specifically, in one embodiment, the feature extraction module is specifically used for: Perform code parsing on the code package to obtain the code parsing results; Based on the code parsing results, analyze the interface characteristics of the business project to be deployed; Based on the code analysis results and interface characteristics, determine the data interaction characteristics of the business project to be deployed; Based on the code analysis results and data interaction characteristics, determine the concurrent request threshold for the business project to be deployed; Based on the code parsing results, analyze the service dependency hierarchy characteristics of the business project to be deployed; Based on the code analysis results and service dependency hierarchy characteristics, determine the database interaction patterns of the business project to be deployed; Based on interface characteristics, data interaction characteristics, service dependency hierarchy characteristics, and database interaction pattern characteristics, the peak resource consumption prediction results for the business projects to be deployed are determined. Among them, the business chain characteristics of the business projects to be deployed include at least the business type, interface characteristics, data interaction characteristics, concurrent request threshold, database interaction pattern characteristics, and peak resource consumption prediction results represented by the code parsing results.

[0093] Specifically, in one embodiment, the feature extraction module is specifically used for: Perform syntactic analysis on the code package to extract the word stream from the code package; Based on the contextual information represented by the lexical stream, the lexical stream is converted into an abstract syntax tree; Traverse the abstract syntax tree to determine the global symbol table of the code package; The code parsing results include an abstract syntax tree and a global symbol table, which includes class names, method names, annotation metadata, and import dependencies.

[0094] Specifically, in one embodiment, the feature extraction module is specifically used for: Based on the code parsing results, determine the interface declaration information in the business project to be deployed; Determine the calling relationships between the interfaces based on the interface declaration information; Based on the calling relationships between the interfaces, construct the interface call topology diagram of the business project to be deployed; Based on the API call topology diagram, determine the number of APIs, API call levels, and API call frequencies for the business projects to be deployed. The interface characteristics include the number of interfaces, the interface call level, and the interface call frequency.

[0095] Specifically, in one embodiment, the feature extraction module is specifically used for: Based on the code analysis results, determine the data read and data write operations corresponding to each interface; Based on data read and data write operations, the number of data accesses, the amount of data transferred in a single transaction, and the total amount of data interaction per unit time are counted for each interface. Based on the calling relationships between interfaces characterized by interface features, the number of data accesses, the amount of data transmitted in a single transaction, and the total amount of data interaction per unit time for each interface are mapped to the corresponding interface call chain. Based on the changes in data transmission volume in each interface call chain, determine the data flow path of the business project to be deployed; Among them, data interaction characteristics include the number of data accesses, the amount of data transmitted in a single transaction, the total amount of data interaction per unit time, and the data flow path.

[0096] Specifically, in one embodiment, the feature extraction module is specifically used for: Based on the code analysis results, determine the thread call relationships and request processing logic corresponding to each interface in the business project to be deployed; Based on the thread call relationship and request processing logic corresponding to each interface, determine the number of threads occupied and the request response time for each interface; Based on the number of threads used by each interface, request response time, and data interaction characteristics, establish a concurrent request pressure model for the business project to be deployed. Based on the concurrent request pressure model, determine the maximum number of requests that each interface can process under the condition of satisfying the preset response time constraint; The concurrent request threshold includes the maximum number of requests that each interface can process.

[0097] Specifically, in one embodiment, the feature extraction module is specifically used for: Based on the import dependencies, class call relationships, and method call relationships represented by the code parsing results, determine the service components in the business project to be deployed; Construct a service dependency graph based on the call relationships between the various service components; Based on the service dependency graph, determine the dependency level, call path, and service node corresponding to each service component; Among them, the service dependency hierarchy features include the dependency hierarchy, call path and service node corresponding to each service component.

[0098] Specifically, in one embodiment, the feature extraction module is specifically used for: Based on the database access statements and database connection configurations represented by the code parsing results, identify the database operation types corresponding to the business projects to be deployed. Determine the number of database queries, data updates, transactions, and database connections based on the type of database operation. Based on the service dependency hierarchy characteristics, determine the data access path between each service node and the database; Among them, the characteristics of database interaction patterns include the number of database queries, the number of data updates, the number of transactions, the number of database connections, and the data access paths between each service node and the database.

[0099] Specifically, in one embodiment, the feature extraction module is specifically used for: Based on interface characteristics, data interaction characteristics, service dependency hierarchy characteristics, and database interaction pattern characteristics, a business chain resource consumption model is established. Based on the business chain resource consumption model, the processor resource utilization, memory consumption, disk input / output load and network bandwidth consumption of the business projects to be deployed are predicted under different business load conditions. Peak values ​​of processor resource utilization, memory usage, disk I / O load, and network bandwidth usage predicted under different business load conditions are calculated to obtain peak values ​​of processor resource utilization, memory usage, disk I / O load, and network bandwidth usage. The peak resource usage prediction results include peak processor resource usage, peak memory usage, peak disk I / O load, and peak network bandwidth usage.

[0100] Specifically, in one embodiment, the determining module is specifically used for: Based on the business chain characteristics of the business projects to be deployed, generate standardized business chain characteristic modeling data; Based on standardized business chain feature modeling data, generate service chain test scenarios; Based on the target test load and target test metrics in the service chain test scenario, generate corresponding automated test cases.

[0101] Specifically, in one embodiment, the test module is specifically used for: Based on the performance test configuration information represented by automated test cases, generate test requests; The test request is sent to the device under test through the target test interface to obtain the actual performance data of the device under test during the execution of the test request; Based on actual performance data and the target test indicators and indicator judgment criteria represented by the service chain test scenario, the performance test results of the device under test for the business project to be deployed are determined.

[0102] Specifically, in one embodiment, the test module is specifically used for: Based on the target test indicators and the target data format represented by the indicator judgment criteria, the actual performance data is standardized to obtain standardized actual performance data that is consistent with the target data format. Based on the indicator judgment criteria, determine whether each actual performance indicator represented by the standardized actual performance data exceeds the preset normal range; Actual performance indicators that exceed the preset normal range are considered abnormal performance indicators. The performance test results should include at least abnormal performance indicators.

[0103] Specifically, in one embodiment, the test module is further configured to: Abnormal performance indicators are classified to determine the type of abnormality of the device under test. The abnormality types are classified into at least four types: hardware performance bottleneck, system compatibility problem, insufficient resource scheduling, and network transmission failure. The performance test results also include the abnormality types. Based on the performance test results, generate a business chain feature matching report between the device under test and the business project to be deployed; The business chain feature matching degree report, actual performance data, standardized business chain feature modeling data, and service chain test scenario are associated and stored in a preset cache pool.

[0104] Specifically, in one embodiment, the test module is further configured to: Based on the similarity between actual performance data and standard performance data of the business project to be deployed, determine whether the service chain test scenario matches the actual business scenario of the business project to be deployed. If the service chain test scenario does not match the actual business scenario of the business project to be deployed, discard the actual performance data and redetermine the service chain test scenario and corresponding automated test cases for the business project to be deployed.

[0105] For a description of the features in the embodiments corresponding to the automated testing device, please refer to the relevant descriptions in the embodiments corresponding to the automated testing method, which will not be repeated here.

[0106] Embodiments of this application also provide an electronic device, such as... Figure 12The diagram shown is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, including a processor 10 and a memory 20. The memory 20 stores a computer program, and the processor 10 is configured to run the computer program to execute the steps in any of the above-described automated testing method embodiments.

[0107] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described automated testing method embodiments at runtime.

[0108] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0109] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described automated testing method embodiments.

[0110] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described automated testing method embodiments.

[0111] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0112] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software 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 application.

[0113] The above provides a detailed description of the automated testing method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. An automated testing method, characterized in that, include: Obtain the code package of the business project to be deployed; Business chain features are extracted from the code package to obtain the business chain features of the business project to be deployed; Based on the business chain characteristics of the business project to be deployed, the service chain test scenario and corresponding automated test cases of the business project to be deployed are determined; wherein, the service chain test scenario includes at least the target test load, the target test metric, and the metric judgment criteria, and the automated test cases are used to implement the service chain test scenario; Based on the service chain test scenario and automated test cases, performance tests are performed on the device under test to obtain the performance test results of the device under test for the business project to be deployed. The step of extracting business chain features from the code package to obtain the business chain features of the business project to be deployed includes: The code package is parsed to obtain the code parsing results; Based on the code parsing results, analyze the interface characteristics of the business project to be deployed; Based on the code parsing results and the interface characteristics, the data interaction characteristics of the business project to be deployed are determined; Based on the code parsing results and data interaction characteristics, determine the concurrent request threshold for the business project to be deployed; Based on the code parsing results, analyze the service dependency hierarchy characteristics of the business project to be deployed; Based on the code parsing results and the service dependency hierarchy characteristics, the database interaction pattern characteristics of the business project to be deployed are determined; Based on the interface characteristics, data interaction characteristics, service dependency hierarchy characteristics, and database interaction pattern characteristics, the peak resource consumption prediction results of the business project to be deployed are determined; The business chain characteristics of the business project to be deployed include at least the business type represented by the code parsing results, the interface characteristics, the data interaction characteristics, the concurrent request threshold, the database interaction pattern characteristics, and the peak resource consumption prediction results.

2. The automated testing method according to claim 1, characterized in that, The step of parsing the code package to obtain the code parsing result includes: Syntactic analysis is performed on the code package to extract the lexical stream from the code package; Based on the contextual information represented by the lexical stream, the lexical stream is converted into an abstract syntax tree; Traverse the abstract syntax tree to determine the global symbol table of the code package; The code parsing result includes the abstract syntax tree and the global symbol table, wherein the global symbol table includes class names, method names, annotation metadata, and import dependencies.

3. The automated testing method according to claim 1, characterized in that, The step of analyzing the interface characteristics of the business project to be deployed based on the code parsing results includes: Based on the code parsing results, determine the interface declaration information in the business project to be deployed; Based on the interface declaration information, determine the calling relationships between the interfaces; Based on the calling relationships between the interfaces, construct the interface call topology diagram of the business project to be deployed; Based on the interface call topology diagram, determine the number of interfaces, interface call levels, and interface call frequencies of the business project to be deployed; The interface features include the number of interfaces, the interface call level, and the interface call frequency.

4. The automated testing method according to claim 1, characterized in that, The step of determining the data interaction characteristics of the business project to be deployed based on the code parsing results and the interface characteristics includes: Based on the code parsing results, determine the data read and data write operations corresponding to each interface; Based on the data read operation and the data write operation, the number of data accesses, the amount of data transmitted in a single transaction, and the total amount of data interaction per unit time are counted for each interface. Based on the calling relationship between the interfaces characterized by the interface features, the number of data accesses, the amount of data transmitted in a single transaction, and the total amount of data interaction per unit time for each interface are mapped to the corresponding interface call chain. Based on the changes in data transmission volume in each interface call chain, determine the data flow path of the business project to be deployed; The data interaction features include the number of data accesses, the amount of data transmitted in a single transaction, the total amount of data interaction per unit time, and the data flow path.

5. The automated testing method according to claim 1, characterized in that, The step of determining the concurrent request threshold of the business project to be deployed based on the code parsing results and data interaction characteristics includes: Based on the code parsing results, the thread call relationships and request processing logic corresponding to each interface in the business project to be deployed are determined; Based on the thread call relationship and request processing logic corresponding to each interface, determine the number of threads occupied and the request response time for each interface; Based on the number of threads used by each interface, the request response time, and the data interaction characteristics, a concurrent request pressure model for the business project to be deployed is established. Based on the concurrent request pressure model, determine the maximum number of requests that each interface can process under the condition of satisfying the preset response time constraint; The concurrent request threshold includes the maximum number of requests that each of the interfaces can process.

6. The automated testing method according to claim 1, characterized in that, The step of analyzing the service dependency layer characteristics of the business project to be deployed based on the code parsing results includes: Based on the import dependencies, class call relationships, and method call relationships represented by the code parsing results, the service components in the business project to be deployed are determined; Construct a service dependency graph based on the call relationships between the various service components; Based on the service dependency graph, determine the dependency level, call path, and service node corresponding to each service component; The service dependency hierarchy features include the dependency hierarchy, call path, and service node corresponding to each service component.

7. The automated testing method according to claim 1, characterized in that, The step of determining the database interaction pattern characteristics of the business project to be deployed based on the code parsing results and the service dependency hierarchy characteristics includes: Based on the database access statements and database connection configurations represented by the code parsing results, identify the database operation type corresponding to the business project to be deployed; Based on the database operation type, determine the number of database queries, data updates, transactions, and database connections; Based on the service dependency hierarchy characteristics, determine the data access path between each service node and the database; The database interaction pattern characteristics include the number of database queries, the number of data updates, the number of transactions, the number of database connections, and the data access paths between each service node and the database.

8. The automated testing method according to claim 1, characterized in that, The step of determining the peak resource consumption prediction result of the business project to be deployed based on the interface characteristics, data interaction characteristics, service dependency hierarchy characteristics, and database interaction pattern characteristics includes: Based on the interface characteristics, data interaction characteristics, service dependency hierarchy characteristics, and database interaction pattern characteristics, a business chain resource consumption model is established. Based on the business chain resource consumption model, the processor resource utilization, memory usage, disk input / output load and network bandwidth usage of the business project to be deployed are predicted under different business load conditions. Peak values ​​of processor resource utilization, memory usage, disk I / O load, and network bandwidth usage predicted under different business load conditions are calculated to obtain peak values ​​of processor resource utilization, memory usage, disk I / O load, and network bandwidth usage. The predicted peak resource usage results include the peak processor resource usage rate, peak memory usage, peak disk input / output load, and peak network bandwidth usage.

9. The automated testing method according to claim 1, characterized in that, The step of determining the service chain test scenario and corresponding automated test cases for the business project to be deployed based on its business chain characteristics includes: Based on the business chain characteristics of the business project to be deployed, generate standardized business chain characteristic modeling data; The service chain test scenario is generated based on the standardized business chain feature modeling data. Based on the target test load and target test metrics in the service chain test scenario, generate corresponding automated test cases.

10. The automated testing method according to claim 9, characterized in that, The step involves performing performance testing on the device under test based on the service chain test scenario and automated test cases, obtaining the performance test results of the device under test for the business project to be deployed, including: Based on the performance test configuration information represented by the automated test cases, a test request is generated. The test request is sent to the device under test through the target test interface to obtain the actual performance data of the device under test during the execution of the test request; Based on the actual performance data and the target test indicators and indicator judgment criteria represented by the service chain test scenario, the performance test results of the device under test for the business project to be deployed are determined.

11. The automated testing method according to claim 10, characterized in that, The step of determining the performance test results of the device under test for the service project to be deployed, based on the actual performance data, the target test indicators characterized by the service chain test scenario, and the indicator judgment criteria, includes: Based on the target test indicators and the target data format represented by the indicator judgment criteria, the actual performance data is standardized to obtain standardized actual performance data that is consistent with the target data format. Based on the aforementioned indicator judgment criteria, determine whether each actual performance indicator represented by the standardized actual performance data exceeds the preset normal range; Actual performance indicators that exceed the preset normal range are considered abnormal performance indicators. The performance test results include at least the abnormal performance indicators.

12. The automated testing method according to claim 11, characterized in that, The method further includes: The abnormal performance indicators are classified to determine the anomaly type of the device under test; wherein, the anomaly type is at least divided into four types: hardware performance bottleneck, system compatibility problem, insufficient resource scheduling and network transmission failure, and the performance test results also include the anomaly type; Based on the performance test results, a business chain feature matching report between the device under test and the business project to be deployed is generated; The business chain feature matching degree report, actual performance data, standardized business chain feature modeling data, and service chain test scenario are associated and stored in a preset cache pool.

13. The automated testing method according to claim 10, characterized in that, The method further includes: Based on the similarity between the actual performance data and the standard performance data of the business project to be deployed, it is determined whether the service chain test scenario matches the actual business scenario of the business project to be deployed. If the service chain test scenario does not match the actual business scenario of the business project to be deployed, the actual performance data is discarded, and the service chain test scenario and corresponding automated test cases of the business project to be deployed are redefined.

14. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the automated testing method as described in any one of claims 1 to 13.

Images