Server testing method and device, electronic equipment and computer program product

Abstract

The invention discloses a server testing method and device, electronic equipment and a computer program product. Relates to the field of financial science and technology, and comprises the following steps: receiving a server test instruction, and determining a test type of a target server according to the server test instruction, the test type at least comprising one of a performance test and a fault test; under the condition that the test type is a performance test, obtaining a performance test component, and calling the performance test component to test the target server to obtain a performance test result; and when the test type is a fault test, obtaining a fault test component, and calling the fault test component to test the target server to obtain a fault test result. Through the server testing method and device, the technical problem that the testing accuracy is low when the server is tested in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically, to a server testing method, apparatus, electronic device, and computer program product. Background Technology

[0002] As a crucial component of an organization's IT (Information Technology) infrastructure, file servers bear the important responsibility of storing, managing, and distributing files. For example, in the financial industry, the performance of file servers directly impacts business continuity and data security. Therefore, conducting performance tests on file servers to assess their processing capacity and stability is a key step in ensuring efficient system operation.

[0003] Currently, file server performance testing primarily employs load testing tools. These tools simulate user access scenarios by concurrently uploading and downloading large and small files, collecting data on the server's CPU, disk, memory, and network usage to evaluate the overall processing performance of the file server under ideal conditions. However, existing testing methods have several shortcomings that limit the accuracy and applicability of the test results. First, the tests are limited to static performance evaluations, failing to consider performance under scenarios such as hardware failures, network anomalies (e.g., jitter, packet loss), and server software crashes. This results in test results that cannot fully reflect the server's processing capabilities under non-ideal conditions. Furthermore, tests are typically conducted in a single local environment, failing to reproduce the geographically dispersed, multi-center deployment structure of a production environment. This ignores the actual impact of network bandwidth and latency on file server performance, thus limiting the reference value of the test results.

[0004] Furthermore, tests often use uniform file sizes, ignoring the pressure on small file metadata and the complexity of hot / cold data distribution, failing to fully cover possible scenarios in production, and lacking in-depth analysis of system resilience and continuous availability.

[0005] There is currently no effective solution to the technical problem of low testing accuracy when testing servers in related technologies. Summary of the Invention

[0006] The main objective of this application is to provide a server testing method, apparatus, electronic device, and computer program product to solve the technical problem of low testing accuracy in related technologies when testing servers.

[0007] To achieve the above objectives, according to one aspect of this application, a server testing method is provided. The method includes: receiving a server testing instruction; determining the test type of the target server based on the server testing instruction, wherein the test type includes at least one of the following: performance testing and fault testing; if the test type is performance testing, obtaining a performance testing component, invoking the performance testing component to test the target server, and obtaining performance test results; if the test type is fault testing, obtaining a fault testing component, invoking the fault testing component to test the target server, and obtaining fault test results.

[0008] Furthermore, obtaining the performance testing component includes: obtaining the test program and obtaining the initial performance testing component, wherein the initial performance testing component is communicatively connected to M initial container nodes, where M is a positive integer; encapsulating the test program into the M initial container nodes to obtain M container nodes, and configuring the parameters of the initial performance testing component according to the M container nodes to obtain the performance testing component.

[0009] Furthermore, the performance testing component is invoked to test the target server, and the performance test results are obtained by: receiving test parameters and obtaining M container nodes associated with the performance testing component; configuring the M container nodes according to the test parameters to obtain M configured container nodes; controlling the M configured container nodes to generate M test files, wherein each test file has a different file size; controlling the M configured container nodes to upload the M test files to the target server, obtaining the uploaded data, and determining the performance test results based on the uploaded data.

[0010] Furthermore, controlling M configured container nodes to upload M test files to the target server, the uploaded data includes: obtaining the target server's load data during the process of controlling N configured container nodes to upload the generated N test files to the target server, where N is less than or equal to M and N is a positive integer; when the load data shows an increasing trend, controlling MN configured container nodes to sequentially upload the generated MN test files to the target server until the load data shows a stagnant trend; obtaining the target server's upload rate and concurrency when the trend is stagnant, and combining the upload rate and concurrency to form the uploaded data, where concurrency refers to the number of times the MN test files are uploaded concurrently.

[0011] Furthermore, determining the performance test results based on the uploaded data includes: obtaining the first performance data of the target server from the uploaded data, wherein the first performance data includes at least traffic data, memory data, and utilization data; obtaining the preset performance data of the target server; comparing the first performance data with the preset performance data; and constructing the performance test results based on the comparison results.

[0012] Furthermore, the fault testing component is invoked to test the target server, and the fault test results are obtained as follows: Y sets of preset fault parameters are obtained, where each set of preset fault parameters is used to trigger a fault scenario, and Y is a positive integer; while controlling the fault testing component to trigger fault scenarios according to each set of preset fault parameters in sequence, the fault time of each fault scenario of the target server is obtained, and the performance data of the target server is obtained to obtain Y second performance data; Y performance time graphs are constructed based on the fault time and the Y second performance data, and fault test results are generated based on the Y performance time graphs.

[0013] Furthermore, after obtaining the fault test results, the method further includes: if the performance test results and fault test results indicate that the target server is normal, not adjusting the server parameters of the target server; if at least one of the performance test results and fault test results indicates that the target server is abnormal, determining a server adjustment strategy based on at least one of the performance test results and fault test results; adjusting the server parameters of the target server according to the server adjustment strategy, and then obtaining the adjusted target server; and calling the performance test component and the fault test component respectively to test the adjusted target server until the adjusted test results indicate that the target server is normal.

[0014] To achieve the above objectives, according to another aspect of this application, a server testing apparatus is provided. The apparatus includes: a receiving unit, configured to receive a server testing instruction and determine the test type of the target server based on the server testing instruction, wherein the test type includes at least one of the following: performance testing and fault testing; a first acquiring unit, configured to, when the test type is performance testing, acquire a performance testing component, invoke the performance testing component to test the target server, and obtain performance test results; and a second acquiring unit, configured to, when the test type is fault testing, acquire a fault testing component, invoke the fault testing component to test the target server, and obtain fault test results.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, the device where the computer-readable storage medium is located controls the execution of the test method of any of the above-described servers.

[0016] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory storing an executable program, and the processor for running the program, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the test method of any of the above-described servers.

[0017] According to another aspect of the present invention, a computer program product is also provided, the computer program product including a computer program, wherein the computer program, when executed by a processor, implements the test method of any of the above-described servers.

[0018] In this embodiment, a server-side testing method is adopted. This involves receiving a server test instruction and determining the test type for the target server based on the instruction. The test type includes at least one of the following: performance testing and fault testing. If the test type is performance testing, a performance testing component is obtained and invoked to test the target server, yielding performance test results. If the test type is fault testing, a fault testing component is obtained and invoked to test the target server, yielding fault test results. This method solves the technical problem of low test accuracy in related technologies when testing servers. By determining the test type and invoking either the performance testing component or the fault testing component to test the target server, performance test results or fault test results are obtained, thereby improving the accuracy of server testing. Attached Figure Description

[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 It is a hardware structure block diagram of a computer terminal (or mobile device) used to implement a server testing method;

[0021] Figure 2 This is a flowchart of a server testing method provided according to an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of a server testing system provided according to an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of an optional server testing method provided according to an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of a server testing apparatus provided according to an embodiment of this application;

[0025] Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties. For example, this system has interfaces with relevant users or organizations to provide users with corresponding operation data for them to choose to agree to or refuse automated decision-making results. Before obtaining relevant information, a request for obtaining the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained after receiving consent from the aforementioned user or organization; if the user chooses to refuse, the expert decision-making process is initiated. Users can view the purpose of data use in real time through authorization decoding and have the right to withdraw authorization or delete data at any time. After the authorization is withdrawn, the system will terminate the relevant data processing within 24 hours.

[0029] It should be noted that the information collected in this application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize use or refuse use.

[0030] Example 1

[0031] According to an embodiment of this application, a method embodiment for testing a server is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0032] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) used to implement a server testing method, such as... Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 The processor 102 (which may include, but is not limited to, a microprocessor MCU (Microcontroller Unit) or a programmable gate array (FPGA)) is shown as 102a, 102b, ..., 102n. It also includes a memory 104 for storing data and a transmission device 106 for communication functions. In addition, it may include: a display, an input / output interface, a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a keyboard, a cursor control device, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0033] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0034] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the server testing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned server testing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0035] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network interface controller (NIC) and a network interface, which can be connected to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0036] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0037] Under the aforementioned operating environment, this application provides the following: Figure 2 The server testing method is shown. Figure 2 This is a flowchart of a server testing method provided according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0038] Step S201: Receive server test instructions and determine the test type of the target server according to the server test instructions. The test type includes at least one of the following: performance test and fault test.

[0039] Specifically, server test instructions refer to instructions for testing a specific target server. These instructions can include: test type (performance test, fault test, or a combination of both), target server identification information (such as IP address (Internet Protocol Address), server name), specific test parameters (such as file size, concurrency, upload speed, etc.), and detailed fault injection scenarios. Upon receiving these instructions, the information can be parsed to determine the target and type of the test. The test type can include performance testing and fault testing: performance testing is used to evaluate the server's maximum processing capacity and stability under ideal conditions. In practice, a large number of files can be generated and sent according to the parameters set in the instructions (such as file size, concurrency, and upload speed) to simulate high-concurrency user access or data transmission scenarios. Simultaneously, monitoring and data collection nodes record various performance indicators of the server during the test, such as CPU (Central Processing Unit) utilization, memory usage, and network bandwidth, to analyze server performance bottlenecks and optimization potential. Fault testing, also known as chaos testing, aims to test the server's resilience and self-healing capabilities by actively introducing faults or anomalies. In practice, various hardware, network, or software anomalies can be simulated based on fault scenarios in the test instructions, such as disk fullness, network packet loss, and memory exhaustion. This allows for observation of changes in the server's processing capacity under fault conditions, as well as the server's status and performance recovery after fault recovery. By combining performance testing and fault testing, not only is the server's performance under normal operation evaluated, but its performance and recovery capabilities under abnormal conditions are also verified, providing a more comprehensive guarantee for the long-term stable operation of the server.

[0040] Step S202: If the test type is performance test, obtain the performance test component, call the performance test component to test the target server, and obtain the performance test results.

[0041] Specifically, when the server test command specifies performance testing of the target server, a performance testing component can be selected. This component refers to a software tool capable of simulating concurrent transmission of large and small files and collecting data on server resource usage (CPU, disk, memory, network, etc.). For example, it could include a distributed performance load generator, which can dynamically generate test traffic across multiple nodes and supports horizontal scaling to adapt to different scales of testing needs. Then, the performance testing component is invoked to perform performance testing on the target server. For instance, specific test parameters, such as file size, concurrency levels, and upload speed, can be set to simulate different types of file processing scenarios. The number of files sent and the upload speed are then dynamically adjusted to initiate a large number of read and write requests to the target file server, evaluating the server's processing performance under high concurrency. Finally, server performance data during the test is collected, including the server's resource usage and file processing efficiency, to obtain the performance test results.

[0042] Step S203: If the test type is fault test, obtain the fault test component, call the fault test component to test the target server, and obtain the fault test result.

[0043] Specifically, if the test type is determined to be a fault test, a fault testing component can be acquired to test the server's performance and recovery capabilities under abnormal conditions. Since this fault testing component can include a series of predefined fault modes, such as disk full, network packet loss, memory exhaustion, connection limit, and network latency, to cover various possible abnormal situations, specific fault modes can be triggered in real-time or as planned on the target server or its surrounding environment (such as network links) to observe and analyze the server's response and processing capabilities under fault conditions. This involves actively injecting faults into the target server or its environment, while the performance testing component continues to perform file transfer tests to assess the impact of the faults on server performance. Throughout the test, the target server's performance metrics and key logs are continuously monitored, recording performance changes before and after fault injection, as well as the server's self-healing capabilities. Finally, the failure test results are obtained from the failure test. These results can include a quantitative analysis of the server performance during and after the failure, such as quantitative data on performance degradation: the specific values ​​of server performance degradation under different failure scenarios, including changes in file processing time, throughput, and resource usage (CPU, memory, etc.); and self-healing capability assessment: recording the time required for the server to recover to a stable state from the injection of the failure, as well as the performance of the server during the recovery process, in order to evaluate the server's self-healing speed and effectiveness.

[0044] The server testing method provided in this application embodiment receives a server test instruction and determines the test type of the target server based on the instruction. The test type includes at least one of the following: performance testing and fault testing. When the test type is performance testing, a performance testing component is obtained and invoked to test the target server, obtaining performance test results. When the test type is fault testing, a fault testing component is obtained and invoked to test the target server, obtaining fault test results. This method solves the technical problem of low test accuracy in related technologies. By determining the test type and invoking either the performance testing component or the fault testing component to test the target server, performance test results or fault test results are obtained, thereby improving the accuracy of server testing.

[0045] Optionally, in the server testing method provided in this application embodiment, obtaining the performance testing component includes: obtaining a test program and obtaining an initial performance testing component, wherein the initial performance testing component is communicatively connected to M initial container nodes, where M is a positive integer; encapsulating the test program into the M initial container nodes to obtain M container nodes, and configuring the parameters of the initial performance testing component according to the M container nodes to obtain the performance testing component.

[0046] Specifically, before starting performance testing, it's necessary to first obtain the test program. The test program is a collection of code that executes specific test logic, simulating user behavior or file transfers to test the target server's performance. For example, the program can generate files of different types and sizes and upload them to the target server at specified concurrency and rates to simulate real file processing load. To obtain the performance testing component, an initial performance testing component is first needed, which has the ability to communicate with multiple initial container nodes. Then, the test program is encapsulated within these initial container nodes. This means using container technology to package the test program into each container node, ensuring a consistent running environment across all nodes. This avoids testing errors caused by environmental differences and facilitates horizontal scaling—increasing the number of container nodes to increase the test load and thus test the server's performance under different loads.

[0047] Furthermore, based on the container nodes obtained after packaging the test program, the parameters of the initial performance test component are configured to obtain the performance test component. This involves fine-grained configuration of the performance test component to adapt to specific testing needs, such as setting parameters like concurrency, file size, and upload rate. In this way, the test program on each container node can run according to a unified strategy, but the test intensity can be dynamically adjusted according to the actual situation of the container node, ensuring the accuracy and reliability of the test results.

[0048] This embodiment utilizes container technology and distributed deployment to quickly and parallelly execute tests on multiple nodes, significantly improving testing efficiency, shortening the testing cycle, flexibly adjusting the scale and intensity of tests to meet testing needs at different stages, avoiding inconsistencies in test results due to environmental changes, and enhancing the flexibility and scalability of testing.

[0049] Optionally, in the server testing method provided in this application embodiment, calling the performance testing component to test the target server and obtain the performance test results includes: receiving test parameters and obtaining M container nodes associated with the performance testing component; configuring the M container nodes according to the test parameters to obtain M configured container nodes; controlling the M configured container nodes to generate M test files, wherein each test file has a different file size; controlling the M configured container nodes to upload the M test files to the target server to obtain the uploaded data; and determining the performance test results based on the uploaded data.

[0050] Specifically, when performing server testing based on the performance testing component, the system first receives detailed test information from testers, i.e., test parameters. These parameters define the test boundary conditions and expected test scenarios, and may include file size ranges, upload rates, concurrency levels, and other relevant metrics such as test duration and file types. Simultaneously, the system can retrieve the container nodes associated with the performance testing component and configure them according to the test parameters. For example, specific test parameters can be set for each container node, such as file upload rate, concurrency level, and file size. The configuration of test parameters matches the expected test objectives to ensure the validity of the test results.

[0051] Furthermore, the configured container nodes can be controlled to generate test files of varying sizes, and then one or more of these files can be simultaneously uploaded to the target server. This simulates the impact of different file sizes (from small, metadata-intensive files to large, transfer-intensive files) on the file server's performance, testing the server's ability to handle concurrent requests. This allows each container node to independently generate test load, thus creating distributed test pressure overall. Finally, the performance test results are determined based on the uploaded file data, which may include file upload rate, server response time, and server resource consumption. Analysis of this data allows for a quantitative evaluation of the file server's processing performance under different loads, identification of potential performance bottlenecks, and assessment of the server's stability and efficiency under various file sizes and concurrency modes, thereby deriving the performance test results.

[0052] This embodiment constructs various file processing scenarios that simulate a production environment, making the test results closer to actual usage. It achieves high-concurrency stress testing of the file server, which can more accurately evaluate the server's performance under large-scale file transfers, optimize the allocation of test resources, and improve test efficiency.

[0053] Optionally, in the server testing method provided in this application embodiment, controlling M configured container nodes to upload M test files to the target server and obtaining the upload data includes: during the process of controlling N configured container nodes to upload the generated N test files to the target server, obtaining the load data of the target server, where N is less than or equal to M and N is a positive integer; when the load data shows an increasing trend, controlling MN configured container nodes to sequentially upload the generated MN test files to the target server until the load data shows a stagnant trend; obtaining the upload rate value and concurrency of the target server when it is in a stagnant trend, and using the upload rate value and concurrency to constitute the upload data, where the concurrency refers to the number of times the MN test files are uploaded concurrently.

[0054] Specifically, after the container nodes are configured and generate test files of different sizes, when the controller uploads some of the test files to the target server, it can first obtain the resource usage of the target server during the test, such as CPU utilization, memory usage, disk I / O and network bandwidth, that is, obtain load data, and then use this data to evaluate the server's performance under different pressures.

[0055] When the load data shows an increasing trend, the upload process can be dynamically adjusted. For example, the number of concurrent file uploads can be increased, meaning the test pressure can be continuously increased without exceeding the target server's current processing capacity, until the load data trend stabilizes. This allows for a more precise identification of the server's performance limits. Finally, when the server load stabilizes, the upload rate and concurrency of the target server when it is at a standstill can be obtained. The upload rate reflects the speed of file transfer, while the concurrency indicates the server's ability to handle multiple tasks. These data are used to construct the final upload data for evaluating the server's performance capacity and stability under extreme load conditions.

[0056] This embodiment dynamically adjusts the upload strategy based on the actual load of the server during the testing process, which can more accurately assess the server's performance boundaries, avoid resource waste or excessive stress testing during the testing process, improve testing efficiency, and make the testing process closer to real-world usage scenarios. This improves the overall service quality and server stability, and provides a scientific basis for performance optimization and fault prevention in the production environment.

[0057] Optionally, in the server testing method provided in this application embodiment, determining the performance test result based on the uploaded data includes: obtaining first performance data of the target server from the uploaded data, wherein the first performance data includes at least traffic data, memory data, and utilization data; obtaining preset performance data of the target server; comparing the first performance data and the preset performance data; and constructing a performance test result based on the comparison result.

[0058] Specifically, after acquiring the upload data of the target server when it is in a stagnant state, this data can be parsed and analyzed to extract crucial performance metrics, i.e., the primary performance data. This primary performance data includes at least three key dimensions: traffic data (reflecting the server's file transfer speed and efficiency), memory data (indicating the server's memory usage during file read / write operations), and utilization rate data. These metrics collectively constitute a performance profile of the server under high load and stable conditions, providing foundational data for subsequent performance analysis.

[0059] Furthermore, the target server's preset performance data is obtained, that is, the performance standard or threshold that the target server is expected to achieve at the initial design or benchmark testing. Then, the first performance data and the preset performance data are compared to identify whether there is a gap between the target server's actual performance and the expected value, and the degree of the gap. Based on the comparison results, the performance test results are constructed.

[0060] This embodiment accurately evaluates the real performance of a file server when handling large-scale file transfers through dynamic monitoring and precise comparison. It can quantify the deviation between the server's actual performance and design expectations, providing specific guidance for subsequent optimization and maintenance. It avoids interference factors in the early stages of testing and improves the accuracy and reliability of performance test results.

[0061] Optionally, in the server testing method provided in this application embodiment, calling the fault testing component to test the target server and obtaining the fault test results includes: obtaining Y sets of preset fault parameters, wherein each set of preset fault parameters is used to trigger a fault scenario, and Y is a positive integer; while controlling the fault testing component to trigger fault scenarios sequentially according to each set of preset fault parameters, obtaining the fault time when the target server experiences each fault scenario, and obtaining the performance data of the target server to obtain Y second performance data; constructing Y performance time graphs based on the fault time and Y second performance data, and generating fault test results based on the Y performance time graphs.

[0062] Specifically, when using a fault testing component to test a server, multiple sets of preset fault parameters that trigger specific fault scenarios can first be obtained. Each set of parameters corresponds to a specific fault scenario, such as disk full, memory leak, or network latency. Then, the fault testing component is controlled to trigger the fault scenario sequentially according to each set of preset fault parameters. That is, the fault injection operation corresponding to each set of fault parameters is executed in a serialized manner, so that only one fault scenario is activated at a time, in order to accurately measure and analyze the impact of each fault on the server.

[0063] While injecting faults, it is necessary to obtain the exact time of each fault scenario on the target server and record the performance data. The performance data refers to the key operating indicators of the target server before, during, and after the fault scenario is triggered, such as CPU utilization, memory usage, disk I / O, network traffic, etc. These data are combined to form the second performance data, which is a series of performance indicator changes obtained for each fault scenario.

[0064] Finally, the failure time and corresponding secondary performance data are visualized. Specifically, a time-series chart is constructed based on the failure time and secondary performance data to display the server performance fluctuations under each failure scenario. This allows for a direct observation of the impact of the failure on server performance and the utilization of server resources during the failure period, providing clear visual support for subsequent failure test result analysis. Finally, the stability and recovery capability of the file server in the face of different failures are evaluated based on the corresponding performance time-series charts, thereby generating failure test results. These results can include the specific changes in server performance under each failure scenario, the magnitude of performance degradation, the time for self-recovery, and any persistent performance impacts that failed to recover automatically.

[0065] This embodiment injects preset fault parameters into the target server, enabling the test to cover a variety of potential server faults and improving the comprehensiveness and depth of the test; the constructed performance time graph provides a quantitative view of the impact of faults on server performance, which helps to identify performance bottlenecks and optimization directions; the fault test results can reveal the resilience of the server under fault conditions, providing a basis for improving the reliability and availability of the server.

[0066] Optionally, in the server testing method provided in this application embodiment, after obtaining the fault test result, the method further includes: if the performance test result and the fault test result indicate that the target server is normal, not adjusting the server parameters of the target server; if at least one of the performance test result and the fault test result indicates that the target server is abnormal, determining a server adjustment strategy based on at least one of the performance test result and the fault test result; adjusting the server parameters of the target server according to the server adjustment strategy, and then obtaining the adjusted target server; and calling the performance test component and the fault test component respectively to test the adjusted target server until the adjusted test result indicates that the target server is normal.

[0067] Specifically, after obtaining the two test results, it is possible to determine whether the target server has met the expected performance standards and fault recovery capabilities. When the performance test results (e.g., the server's efficiency in processing files, upload speed, concurrency, etc.) and the fault test results (e.g., the server's stability in fault scenarios, recovery time, and performance after recovery) indicate that the target server is normal, there is no need to adjust the server parameters to avoid unnecessary risks and costs.

[0068] If any anomalies are found in the performance test or fault test results, indicating that the server has failed to meet expectations in some aspects, the specific performance bottlenecks or fault recovery issues can be analyzed based on the anomalies in the test results. This allows for the development of targeted server adjustment strategies, such as optimizing resource allocation (e.g., increasing CPU or memory), adjusting concurrency mechanisms, and improving fault detection and recovery processes. After adjusting the server parameters of the target server according to the server adjustment strategy, the adjusted target server needs to be reacquired and retested, including performance and fault tests, to verify the effectiveness of the adjustment strategy. This involves calling performance testing and fault testing components to test the adjusted target server separately, and analyzing the new test results to determine if further adjustments are necessary. This process continues until all test results indicate that the target server is operating without anomalies, meaning that the server can maintain stable performance and rapid recovery under different load and fault scenarios.

[0069] This embodiment adjusts server parameters based on feedback from performance and fault testing until a state without abnormalities is reached, forming a continuously optimized closed-loop system. This improves system stability and resilience, increases operational efficiency, and reduces potential risks caused by human error.

[0070] This application also provides a server testing system. Figure 3 This is a schematic diagram of a server testing system provided according to an embodiment of this application, such as... Figure 3 As shown, the system includes: a test console, a distributed performance load generator (i.e., a performance testing component), a chaos testing tool (i.e., a fault testing component), and monitoring and data collection nodes. The test console is used to configure parameters required for server test commands and to distribute test tasks. The distributed performance load generator tests the target server and obtains performance test results; that is, it schedules container nodes to run specific test programs, initiating test traffic to the target server and distributing stress test traffic. The chaos testing tool executes chaos test commands on the target server to inject chaotic faults, thereby testing the target server and obtaining fault test results. The monitoring and data collection nodes collect program execution logs and write them to a database for retention and performance data analysis.

[0071] The system described above can be used to perform an optional server testing method. Figure 4 This is a schematic diagram of an optional server testing method provided according to an embodiment of this application, such as... Figure 4 As shown, the method includes:

[0072] After receiving the server test command, static analysis can be performed to determine the test objective and test type. The test objective can be the target server (i.e., a file server), and the test type must include at least one of the following: performance testing and fault testing. The test console then configures and issues the test task according to the aforementioned test type.

[0073] Furthermore, it can be determined whether the test type is a fault test, i.e., whether to inject chaos test data. If the test type is a performance test, it indicates that chaos test data is not injected. In this case, the performance test component is obtained, invoked to test the target server, and test data is collected. If the test type is a fault test, it indicates that chaos test data is injected. In this case, the fault test component can be invoked to perform fault injection, and test data is collected after injection. After collecting the test data, it can be analyzed to obtain the performance test results or fault test results.

[0074] If at least one of the performance test results and fault test results indicates that the target server is abnormal, a server adjustment strategy is determined based on at least one of the performance test results and fault test results. Then, the server parameters of the target server are adjusted according to the server adjustment strategy. After obtaining the adjusted target server, it is determined whether the test objective has been achieved. At this point, the performance test component and the fault test component can be called to test the adjusted target server until the adjusted test results indicate that the target server is without abnormalities.

[0075] This embodiment determines the test type, calls the performance test component or the fault test component to test the target server, and obtains the performance test result or the fault test result, thereby achieving the technical effect of improving the accuracy of server testing.

[0076] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0077] Example 2

[0078] This application also provides a server testing apparatus. It should be noted that the server testing apparatus of this application can be used to execute the server testing method provided in this application. The server testing apparatus provided in this application will be described below.

[0079] According to an embodiment of this application, an apparatus for implementing the above-described server testing method is also provided. Figure 5 This is a schematic diagram of a server testing apparatus provided according to an embodiment of this application, such as... Figure 5 As shown, the device includes: a receiving unit 50, a first acquiring unit 51, and a second acquiring unit 52.

[0080] The receiving unit 50 is used to receive server test instructions and determine the test type of the target server according to the server test instructions. The test type includes at least one of the following: performance test and fault test.

[0081] The first acquisition unit 51 is used to acquire the performance testing component when the test type is performance testing, call the performance testing component to test the target server, and obtain the performance test results.

[0082] The second acquisition unit 52 is used to acquire the fault test component when the test type is fault test, call the fault test component to test the target server, and obtain the fault test result.

[0083] The server testing apparatus provided in this application embodiment receives server test instructions through a receiving unit 50, determines the test type of the target server based on the server test instructions, wherein the test type includes at least one of the following: performance test and fault test; when the test type is performance test, the first obtaining unit 51 obtains a performance test component, calls the performance test component to test the target server, and obtains the performance test result; when the test type is fault test, the second obtaining unit 52 obtains a fault test component, calls the fault test component to test the target server, and obtains the fault test result. This solves the technical problem of low test accuracy when testing servers in related technologies. By determining the test type and calling the performance test component or fault test component to test the target server, the technical effect of improving the accuracy of server testing is achieved.

[0084] Optionally, in the server testing apparatus provided in this application embodiment, the first acquisition unit 51 includes: a first acquisition module, used to acquire a test program and an initial performance test component, wherein the initial performance test component is communicatively connected to M initial container nodes, where M is a positive integer; and an encapsulation module, used to encapsulate the test program into the M initial container nodes to obtain M container nodes, and to configure the parameters of the initial performance test component according to the M container nodes to obtain the performance test component.

[0085] Optionally, in the server testing apparatus provided in this application embodiment, the first acquisition unit 51 includes: a receiving module, used to receive test parameters and acquire M container nodes associated with the performance testing component; a configuration module, used to configure the M container nodes according to the test parameters to obtain M configured container nodes, and control the M configured container nodes to generate M test files, wherein each test file has a different file size; and a first control module, used to control the M configured container nodes to upload the M test files to the target server, obtain the uploaded data, and determine the performance test result based on the uploaded data.

[0086] Optionally, in the server testing apparatus provided in this application embodiment, the first acquisition unit 51 includes: a second acquisition module, used to acquire the load data of the target server during the process of controlling N configured container nodes to upload N generated test files to the target server, wherein N is less than or equal to M and N is a positive integer; a second control module, used to control MN configured container nodes to sequentially upload the MN generated test files to the target server when the load data shows an increasing trend, until the load data shows a stagnant trend; and a third acquisition module, used to acquire the upload rate value and concurrency of the target server when it is in a stagnant trend, and to combine the upload rate value and concurrency to form upload data, wherein the concurrency refers to the number of times the MN test files are uploaded concurrently.

[0087] Optionally, in the server testing apparatus provided in this application embodiment, the first acquisition unit 51 includes: a fourth acquisition module, used to acquire first performance data of the target server from the uploaded data, wherein the first performance data includes at least traffic data, memory data and utilization data; and a fifth acquisition module, used to acquire preset performance data of the target server, compare the first performance data and the preset performance data, and construct performance test results based on the comparison results.

[0088] Optionally, in the server testing apparatus provided in this application embodiment, the second acquisition unit 52 includes: a sixth acquisition module, used to acquire Y sets of preset fault parameters, wherein each set of preset fault parameters is used to trigger a fault scenario, and Y is a positive integer; a seventh acquisition module, used to acquire the fault time when the target server experiences each fault scenario and acquire the performance data of the target server, and obtain Y second performance data, when the fault test component is controlled to trigger the fault scenario in sequence according to each set of preset fault parameters; and a construction module, used to construct Y performance time graphs based on the fault time and the Y second performance data, and generate fault test results based on the Y performance time graphs.

[0089] Optionally, in the server testing apparatus provided in this application embodiment, the apparatus further includes: an adjustment unit, configured to, after obtaining the fault test result, not adjust the server parameters of the target server if the performance test result and the fault test result indicate that the target server is without abnormality; a determination unit, configured to, if at least one of the performance test result and the fault test result indicates that the target server is without abnormality, determine a server adjustment strategy based on at least one of the performance test result and the fault test result; a third acquisition unit, configured to, after adjusting the server parameters of the target server according to the server adjustment strategy, acquire the adjusted target server; and a testing unit, configured to, respectively call the performance test component and the fault test component to test the adjusted target server until the adjusted test result indicates that the target server is without abnormality.

[0090] It should be noted that the receiving unit 50, the first acquiring unit 51, and the second acquiring unit 52 mentioned above correspond to steps S201 to S203 in Embodiment 1. The instances and application scenarios implemented by the above units and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above units can also be part of a device and can run in the computer terminal 10 provided in Embodiment 1.

[0091] Example 3

[0092] Embodiments of this application may provide a computer terminal, which may be any computer terminal device in a group of computer terminals. Optionally, in this embodiment, the aforementioned computer terminal may also be replaced with a mobile terminal or an electronic device, etc.

[0093] Optionally, in this embodiment, the computer terminal may be located in at least one of a plurality of network devices in a computer network.

[0094] In this embodiment, the computer terminal can execute the program code for the following steps in the server testing method: receiving a server test instruction, determining the test type of the target server according to the server test instruction, wherein the test type includes at least one of the following: performance test and fault test; if the test type is performance test, obtaining a performance test component, calling the performance test component to test the target server, and obtaining the performance test result; if the test type is fault test, obtaining a fault test component, calling the fault test component to test the target server, and obtaining the fault test result.

[0095] Optionally, the computer terminal described above can execute the program code for the following steps in the server's testing method: obtaining a test program and obtaining an initial performance test component, wherein the initial performance test component is communicatively connected to M initial container nodes, where M is a positive integer; encapsulating the test program into the M initial container nodes to obtain M container nodes, and configuring the parameters of the initial performance test component according to the M container nodes to obtain the performance test component.

[0096] Optionally, the aforementioned computer terminal may execute the following steps of the server's testing method: receiving test parameters and obtaining M container nodes associated with the performance testing component; configuring the M container nodes according to the test parameters to obtain M configured container nodes; controlling the M configured container nodes to generate M test files, wherein each test file has a different file size; controlling the M configured container nodes to upload the M test files to the target server, obtaining the uploaded data, and determining the performance test results based on the uploaded data.

[0097] Optionally, the aforementioned computer terminal can execute the following steps in the server testing method: During the process of controlling N configured container nodes to upload N generated test files to the target server, obtain the load data of the target server, where N is less than or equal to M and N is a positive integer; when the load data shows an increasing trend, control MN configured container nodes to sequentially upload the MN generated test files to the target server until the load data shows a stagnant trend; obtain the upload rate value and concurrency of the target server when it is in a stagnant trend, and combine the upload rate value and concurrency to form the upload data, where concurrency refers to the number of times the MN test files are uploaded concurrently.

[0098] Optionally, the computer terminal described above can execute the program code for the following steps in the server testing method: obtaining first performance data of the target server from the uploaded data, wherein the first performance data includes at least traffic data, memory data, and utilization data; obtaining preset performance data of the target server, comparing the first performance data and the preset performance data, and constructing performance test results based on the comparison results.

[0099] Optionally, the aforementioned computer terminal may execute the following steps in the server testing method: obtaining Y sets of preset fault parameters, where each set of preset fault parameters is used to trigger a fault scenario, and Y is a positive integer; while controlling the fault testing component to trigger fault scenarios sequentially according to each set of preset fault parameters, obtaining the fault time when the target server experiences each fault scenario, and obtaining the performance data of the target server to obtain Y second performance data; constructing Y performance time graphs based on the fault time and the Y second performance data, and generating fault test results based on the Y performance time graphs.

[0100] Optionally, the aforementioned computer terminal may execute the program code for the following steps in the server testing method: if the performance test results and fault test results indicate that the target server is normal, do not adjust the server parameters of the target server; if at least one of the performance test results and fault test results indicates that the target server is abnormal, determine a server adjustment strategy based on at least one of the performance test results and fault test results; after adjusting the server parameters of the target server according to the server adjustment strategy, obtain the adjusted target server; and call the performance test component and fault test component respectively to test the adjusted target server until the adjusted test results indicate that the target server is normal.

[0101] Optionally, Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (Only one is shown) Processor 602, memory 604, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0102] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the server testing method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the aforementioned server testing method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0103] The processor can access the information and application programs stored in the memory via the transmission device to execute the steps described above in the server testing method.

[0104] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0105] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0106] Example 4

[0107] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the server testing method provided in Embodiment 1.

[0108] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0109] Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: receiving a server test instruction, determining the test type of the target server according to the server test instruction, wherein the test type includes at least one of the following: performance test and fault test; if the test type is performance test, obtaining a performance test component, calling the performance test component to test the target server, and obtaining performance test results; if the test type is fault test, obtaining a fault test component, calling the fault test component to test the target server, and obtaining fault test results.

[0110] This application also provides a computer program product, which, when executed on a data processing device, is suitable for performing test method steps of a server.

[0111] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0112] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0113] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0114] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0115] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0116] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0117] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A server testing method, characterized in that, include: Receive server test instructions, determine the test type of the target server according to the server test instructions, wherein the test type includes at least one of the following: performance test and fault test; When the test type is the performance test, obtain the performance test component, call the performance test component to test the target server, and obtain the performance test results; When the test type is the fault test, obtain the fault test component, call the fault test component to test the target server, and obtain the fault test result.

2. The method according to claim 1, characterized in that, The performance testing components include: Obtain the test program and the initial performance test component, wherein the initial performance test component is communicatively connected to M initial container nodes, where M is a positive integer; The test program is encapsulated into M initial container nodes to obtain M container nodes, and the parameters of the initial performance test component are configured according to the M container nodes to obtain the performance test component.

3. The method according to claim 1, characterized in that, The performance testing component is invoked to test the target server, and the performance test results obtained include: Receive test parameters and obtain the M container nodes associated with the performance test component; Configure the M container nodes according to the test parameters to obtain M configured container nodes, and control the M configured container nodes to generate M test files, wherein each test file has a different file size; Control the M configured container nodes to upload the M test files to the target server, obtain the uploaded data, and determine the performance test result based on the uploaded data.

4. The method according to claim 3, characterized in that, Controlling the M configured container nodes to upload the M test files to the target server, the uploaded data includes: During the process of controlling N configured container nodes to upload N generated test files to the target server, the load data of the target server is obtained, where N is less than or equal to M and N is a positive integer; If the load data shows an increasing trend, control MN configured container nodes to sequentially upload the generated MN test files to the target server until the load data shows a stagnant trend. Obtain the upload rate and concurrency of the target server when it is in the stagnant trend, and use the upload rate and concurrency to form the upload data, wherein the concurrency refers to the number of times the MN test files are uploaded concurrently.

5. The method according to claim 3, characterized in that, Determining the performance test results based on the uploaded data includes: The first performance data of the target server is obtained from the uploaded data, wherein the first performance data includes at least traffic data, memory data, and utilization data; Obtain the preset performance data of the target server, compare the first performance data with the preset performance data, and construct the performance test result based on the comparison result.

6. The method according to claim 1, characterized in that, The fault testing component is invoked to test the target server, and the fault test results include: Obtain Y sets of preset fault parameters, where each set of preset fault parameters is used to trigger a fault scenario, and Y is a positive integer; Under the control of the fault test component to trigger fault scenarios in sequence according to each set of preset fault parameters, the fault time of each fault scenario of the target server is obtained, and the performance data of the target server is obtained to obtain Y second performance data. Based on the fault time and the Y second performance data, construct Y performance time graphs, and generate the fault test results based on the Y performance time graphs.

7. The method according to claim 1, characterized in that, After obtaining the fault test results, the method further includes: If the performance test results and the fault test results indicate that the target server is not abnormal, the server parameters of the target server shall not be adjusted. If at least one of the performance test results and the fault test results indicates that the target server is abnormal, a server adjustment strategy shall be determined based on at least one of the performance test results and the fault test results; After adjusting the server parameters of the target server according to the server adjustment strategy, the adjusted target server is obtained; The performance testing component and the fault testing component are invoked respectively to test the adjusted target server until the adjusted test results indicate that the target server has no abnormalities.

8. A server testing device, characterized in that, include: A receiving unit is configured to receive server test instructions and determine the test type of the target server based on the server test instructions, wherein the test type includes at least one of the following: performance test and fault test; The first acquisition unit is used to acquire a performance testing component when the test type is the performance test, call the performance testing component to test the target server, and obtain the performance test results; The second acquisition unit is used to acquire a fault test component when the test type is the fault test, call the fault test component to test the target server, and obtain the fault test result.

9. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the test method for the server according to any one of claims 1 to 7.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the test method for the server according to any one of claims 1 to 7.

Images