Test method, electronic device, and storage medium

Abstract

The application provides a test method, an electronic device and a storage medium, which can be applied to the field of automatic test technology. The test method comprises the following steps: in response to a test request from a test device, deploying a target image corresponding to a test task in a plurality of preset images to a device under test according to the identification of the test task in the test request; in the case that a communication connection between the test device and the device under test is established through a control interface arranged on the test device, in response to a selection operation of a target test case via the control interface, sending a test script of the target test case to the device under test, so that the device under test executes the test script to obtain a test log, and the target test case comprises a test process and an expected test result required by the test device to execute the test task.

Description

Technical Field

[0001] The present invention relates to the technical field of automated testing, and in particular to a testing method, electronic equipment and storage medium. Background Art

[0002] System-level testing, as a key step in the development cycle of a device under test (DUT), aims to simulate real-world usage scenarios, verify the DUT's overall functionality and performance, and comprehensively verify the DUT's hardware, software, and interaction logic. System-level testing of the DUT can identify system-level defects in the DUT in advance, allowing these defects to be corrected and reducing operational risks. Currently, system-level testing relies primarily on manual environmental preparation and test execution, which not only results in a high error rate but also reduces the degree of automation and, consequently, test efficiency. Summary of the Invention

[0003] In view of the above problems, the present invention provides a testing method, electronic equipment and storage medium for improving testing efficiency.

[0004] One aspect of the present invention provides a testing method, comprising: responding to a test request from a test device, deploying a target image corresponding to the test task from a plurality of preset images to a device under test according to an identifier of the test task in the test request;

[0005] When a communication connection is established between the above-mentioned test device and the device under test through a control interface set on the above-mentioned test device, in response to the selection operation of the target test case through the above-mentioned control interface, the test script of the above-mentioned target test case is sent to the above-mentioned device under test, so that the above-mentioned device under test executes the above-mentioned test script and obtains a test log. The above-mentioned target test case includes the test process and expected test results required for the above-mentioned test device to perform the above-mentioned test task.

[0006] Another aspect of the present invention provides an electronic device, comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0007] Another aspect of the present invention further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the steps of the above method when the computer program or instructions are executed by a processor.

[0008] According to an embodiment of the present invention, in response to a test request, according to the identification of the test task, a target image corresponding to the test task in a plurality of preset images is deployed to the device under test; in the case of establishing a remote connection between the test device and the device under test, in response to the selection operation of the target test case, the test script of the target test case is sent to the device under test so that the device under test executes the test script. Since during the test process, the target image can be automatically deployed to the device under test in response to the test request, and the test script can be automatically transmitted to the device under test in response to the selection operation of the target test case, and the test script is automatically executed by the device under test to obtain a test log, thereby not only improving the degree of automation of the test, but also reducing the problem of high error rate caused by manual execution of the test, thereby achieving the technical effect of improving test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above contents and other objects, features and advantages of the present invention will become more apparent through the following description of the embodiments of the present invention with reference to the accompanying drawings, in which:

[0010] Figure 1 An application scenario diagram of a testing method according to an embodiment of the present invention is shown;

[0011] Figure 2 A flow chart of a testing method according to an embodiment of the present invention is shown;

[0012] Figure 3 A schematic diagram showing a control interface according to an embodiment of the present invention is shown;

[0013] Figure 4 shows an architectural diagram of a testing method according to an embodiment of the present invention;

[0014] Figure 5 Shows a structural block diagram of a testing device according to an embodiment of the present invention;

[0015] Figure 6 A block diagram of an electronic device suitable for implementing a testing method according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0016] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present invention. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of embodiments of the present invention. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concept of the present invention.

[0017] The terms used herein are only for describing specific embodiments and are not intended to limit the present invention. The terms "comprise", "include", etc. used herein indicate the presence of the features, steps, operations and / or components, but do not exclude the presence or addition of one or more other features, steps, operations or components.

[0018] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0019] When expressions such as "at least one of A, B, and C, etc." are used, they should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0020] The system testing process for a device under test typically encompasses use case design, planning, use case distribution, environment setup, and test execution. Automated test environment configuration is difficult during system-level testing of the device under test. Furthermore, setting up the test environment, preparing the test software, and executing the test all rely on manual labor, resulting in low testing efficiency.

[0021] For example, currently, system-level testing relies primarily on manual environmental preparation and test execution. When problems arise and need to be resolved, testers are also primarily responsible for manually running relevant test cases and locating the problem. When conducting system-level testing, testers set up the machine according to the virtual machine (VM) configuration list and refresh the firmware to the latest version. They then select the test system to use based on the listed test cases and perform the test according to the test steps listed in the test cases. When locating the problem, testers must first prepare the environment to ensure that the environment and firmware versions used for problem reproduction or location are consistent with those used during testing. They must then perform a series of actions, such as reproducing the problem, locating the problem, or verifying the solution, according to the steps used during testing. Due to differing job roles, testers generally lack experience with system-level testing. This step is time-consuming and requires the assistance of testers when necessary.

[0022] Generally speaking, manual configuration of the DUT hardware, firmware versions, and test environment requires item-by-item configuration, especially when testing multiple DUTs in parallel. This repetitive work leads to a dramatic increase in time costs. For example, firmware refresh, system installation, and environment configuration for multiple DUTs not only takes hours but is also prone to environmental inconsistencies due to human negligence (such as version mismatches). Manual execution of test cases cannot achieve automated batch operations, making it difficult to cover the complex testing requirements of parallel testing and multiple scenarios, resulting in a long testing cycle. Testers also need to manually restore the test environment. If issues involve multi-component coordination, the reproduction process may require multiple attempts, significantly extending the troubleshooting cycle. Testers lack experience in system-level testing and may miss key debugging steps due to unfamiliarity with the test case logic. Frequent communication with testers familiar with the test case logic can delay problem location and lead to low testing efficiency.

[0023] In view of this, an embodiment of the present invention provides a testing method that integrates automated testing software and Docker containerization technology solutions, aiming to achieve efficient, standardized, and reproducible test environment deployment and execution. It solves the problem of manual configuration of the environment, execution of use cases, and manual saving of test logs caused by traditional testing relying on manual operations, which in turn leads to low efficiency and error-prone problems. For example, it takes several hours to set up the environment of the device to be tested, and manual operations may miss key configurations (such as firmware version mismatches and software installation failures caused by the failure to install dependent packages). The embodiment of the present invention integrates test case management, test parameter configuration, and test execution engines through automated testing software, and supports one-click triggering of full-process testing (such as automatic firmware refresh, automatic configuration of the test environment, and one-click execution of tests, etc.). To address the problems of poor environment reproducibility caused by the reliance on manual installation of software or firmware for environment configuration, the high cost of knowledge transfer caused by the scattered storage of test scripts and test results during cross-team collaboration, and the low efficiency caused by the reliance on manual comparison of logs for result analysis (for example, testers are unable to reproduce test problems due to unfamiliarity with the tools, or need to manually parse multiple logs to locate anomalies), the embodiments of the present invention use Docker containerization technology to achieve one-click deployment of target images, automated execution of test scripts, and intelligent analysis of test logs, thereby solving the above problems and achieving the technical effect of improving testing efficiency.

[0024] Figure 1 An application scenario diagram of a testing method according to an embodiment of the present invention is shown.

[0025] like Figure 1As shown, the application scenario 100 according to this embodiment can include a test device 101, a network 102, a server 103, and a device under test 104. The network 102 is used to provide a communication link between the test device 101 and the server 103, between the server 103 and the device under test 104, and between the test device 101 and the device under test 104. The network 102 can include various connection types, such as wired, wireless communication links, or fiber optic cables, and the like.

[0026] A user can use the test device 101 to interact with the server 103 through the network 102 to receive or send messages, etc., such as sending a test request for testing the device under test 104, and receiving a test result. Various communication client applications can be installed on the test device 101, such as a test application, a shopping application, a web browser application, a search application, an instant messaging tool, an email client, a social platform software, and the like (only as examples).

[0027] The test device 101 and the device under test 104 can each be various electronic devices with a display screen and supporting web browsing, including but not limited to a smartphone, a tablet computer, a laptop computer, a desktop computer, and the like. The test device 101 can test the device under test 104.

[0028] The server 103 can be a server providing various services, and a plurality of preset images can be stored on the server 103. The server 103 can find a target image from the plurality of preset images in response to a test request from the test device 101, and deploy the target image to the device under test 104. The server 103 can also send a test script of a target test case to the device under test 104 in response to an operation on the target test case. The server 103 can further collect and analyze a test log obtained by executing the test script on the device under test 104, and feed back the analyzed result to the test device 101.

[0029] It should be noted that the test method provided by the embodiments of the present application can generally be executed by the server 103. Correspondingly, the test apparatus provided by the embodiments of the present application can generally be arranged in the server 103. The test method provided by the embodiments of the present application can also be executed by a server or a server cluster different from the server 103 and capable of communicating with the test device 101, the device under test 104, and / or the server 103. Correspondingly, the test apparatus provided by the embodiments of the present application can also be arranged in a server or a server cluster different from the server 103 and capable of communicating with the test device 101, the device under test 104, and / or the server 103.

[0030] It should be understood that, Figure 1The number of test devices, networks, servers, and devices under test in the example is merely illustrative. Any number of test devices, networks, servers, and devices under test may be used depending on the implementation requirements.

[0031] The following will be based on Figure 1 The scene described by Figure 2~Figure 3 The testing method of the embodiment of the present invention is described in detail.

[0032] Figure 2 A flow chart of a testing method according to an embodiment of the present invention is shown.

[0033] like Figure 2 As shown, the testing method of this embodiment includes operations S210 to S220.

[0034] In operation S210 , in response to a test request from a test device, a target image corresponding to the test task from a plurality of preset images is deployed to the device under test according to an identifier of the test task in the test request.

[0035] In operation S220, when a communication connection is established between the test device and the device under test through a control interface set on the test device, in response to a selection operation of a target test case through the control interface, the test script of the target test case is sent to the device under test so that the device under test executes the test script and obtains a test log. The target test case includes the test process and expected test results required for the test device to perform the test task.

[0036] In some embodiments, the testing device may be a device that initiates a test request and controls the test process, such as a laptop computer. The device under test may be a device that needs to be tested, such as a server under test.

[0037] In some embodiments, the test request may be initiated by a test device and may be a request to test the device under test, such as a request to perform functional verification testing, performance testing, compatibility testing, stress testing, and stability testing on the device under test.

[0038] In some embodiments, the test task in the test request may refer to a functional verification test task, a performance test task, a compatibility test task, a stress test task, a stability test task, etc. The identification of the test task may be some fields, such as function, performance, compatibility, stress, stability, etc.

[0039] In some embodiments, the preset image can be a template for a system or application environment derived from Docker technology. Docker is a lightweight containerization technology that packages applications and their dependent environments into portable images, enabling build-once, run-anywhere operations. Docker's core mechanisms include namespaces for resource isolation, control groups for resource usage restriction, and a union file system for image layering. In the testing field, Docker's advantages lie in rapid deployment of standardized environments, efficient resource utilization (a single machine can run thousands of containers), and environmental consistency assurance. For example, developers can encapsulate specific operating system versions and test tool chains into images, enabling the startup and destruction of test environments in seconds.

[0040] In some embodiments, the preset image can be configured with an image tag, and the image tag is configured with a sub-tag corresponding to the identifier of the test task. According to the identifier of the test task, a target image that matches the test task can be queried from multiple preset images, that is, a target environment that matches the test task, and the target image can be automatically deployed to the device under test with one click, so that the device under test has a test environment that is adapted to execute the test task.

[0041] For example, the test request is to perform a stability test on the device under test. The identifier of the test task can be stability, and the target image can be an image that matches the stability. By deploying the target image to the device under test, the device under test can have a test environment that is suitable for performing stability testing.

[0042] In some embodiments, the control interface can be an interactive interface provided by the test device for establishing remote communication with the device under test. It can also be used to select test cases, set test parameters, start or stop tests, and confirm test progress. The control interface can include input boxes for entering information such as the Internet Protocol (IP) address of the device under test, test parameters, and the log return path. The control interface can also include function space buttons for establishing a remote connection between the test device and the device under test and selecting test cases for test tasks.

[0043] In some embodiments, the control interface may display multiple test cases, and the target test case may be a test case that matches the test task among the multiple test cases. The target test case may include the test process required to execute the test task (e.g., test steps, test precautions, test tools, and configuration information of the device under test) and expected test results.

[0044] In some embodiments, the target test case may be configured with a test script that can implement the test process in the target test case. In response to the selection or confirmation operation of the target test case, the test script of the test case may be transmitted to the device under test. The transmission of the test script may be performed by the test device or by the test script. Figure 1 Server 103 executes in.

[0045] In some embodiments, the device under test can automatically execute a test script and generate a test log. The test log can record the execution status of the test script, such as any exceptions in the test script execution, the abnormal test script, and the timestamp of the exception. By collecting and processing the test log, a test report can be generated.

[0046] In some embodiments, the automated testing process described above can be used during the design and verification of the device under test (DUT). System-level testing, as a core step in ensuring the reliability of the DUT, plays an irreplaceable role. System-level testing covers the complete verification requirements from hardware components to software collaboration. Through system-level testing, in-depth verification can be performed on areas such as hardware stability (such as full-system stress testing), software stability (such as operating system and driver interaction), and network communications (such as the high-speed Peripheral Component Interconnect Express (PCIe) bus). These tests not only quantify and analyze the system's response time, throughput, and fault tolerance mechanisms, but also identify potential design flaws through stress scenario simulations. For example, if a hard drive stress test reveals that the hard drive backplane becomes inaccessible during high-concurrency read and write operations, relevant personnel can use this phenomenon to investigate the product design, thereby improving product reliability and ultimately ensuring efficient and stable operation of the server in real-world application environments.

[0047] According to an embodiment of the present invention, in response to a test request, according to the identification of the test task, a target image corresponding to the test task in a plurality of preset images is deployed to the device under test; in the case of establishing a remote connection between the test device and the device under test, in response to the selection operation of the target test case, the test script of the target test case is sent to the device under test so that the device under test executes the test script. Since during the test process, the target image can be automatically deployed to the device under test in response to the test request, and the test script can be automatically transmitted to the device under test in response to the selection operation of the target test case, and the test script is automatically executed by the device under test to obtain a test log, thereby not only improving the degree of automation of the test, but also reducing the problem of high error rate caused by manual execution of the test, thereby achieving the technical effect of improving test efficiency.

[0048] In some embodiments, the above-mentioned multiple preset images can be stored in an image warehouse, and any preset image in the image warehouse can be obtained in the following ways: parsing the configuration file of any test task to obtain the image building parameters; generating a container file based on the image building parameters; calling the container application programming interface to build an image for any test task based on the container file.

[0049] In some embodiments, a test task can have a configuration file, which can be a JSON (JavaScript Object Notation) file that describes the image parameters required for the test task. In one embodiment, a programming language (e.g., Python) can integrate a request library and call an application programming interface (API) to generate a JSON file based on the image parameters required by the test task. The programming language can then configure a parser to read the JSON-formatted configuration file (e.g., config.json) and automatically parse it to obtain image build parameters such as the firmware version (firmware_version) and dependencies.

[0050] In some embodiments, a programming language may be used to dynamically generate a container file (Dockerfile) based on the parsed firmware version (firmware_version) and image building parameters such as dependency libraries (dependencies).

[0051] In some embodiments, a Docker API and a Docker build command are called to execute image building based on the container file to obtain an image of any test task.

[0052] According to an embodiment of the present invention, by parsing the configuration file of any test task, image building parameters are obtained; a container file is generated according to the image building parameters; and an image is built according to the container file, automatic image building can be achieved, thereby improving the efficiency and automation of image building.

[0053] In some embodiments, the above-mentioned container file may include multiple build instructions obtained based on image build parameters. The process of building an image for any test task based on the container file may include the following operations: comparing the multiple build instructions of the container file with the cached build instructions obtained based on the historical container file to obtain a comparison result; based on the comparison result, dividing the multiple build instructions in the container file into a first build instruction group that is the same as the cached build instructions, and a second build instruction group that is different from the cached build instructions; and building any image based on the first build instruction group and the second build instruction group.

[0054] In some embodiments, the historical container file may be obtained based on image building parameters of a configuration file of the historical test task during the process of configuring the image of the historical test task.

[0055] In one embodiment, the image being built corresponds to Task A. Specifically, Task A's configuration file is parsed to obtain Image A build parameters for building Task A's image. A container file for Task A is generated based on the Image A build parameters, and the image for Task A is then built based on the container file. During the process of building Task A's image based on the container file for Task A, reference may be made to image files of other tasks that have already completed the image build process, such as Task B, which has already completed the image build process, and its container file (i.e., a historical container file). The container file for Task B may be generated based on the Image B build parameters in Task B's configuration file. Cached build instructions may be build instructions in Task B's container file.

[0056] In the process of building an image, the container file used by task A and the container file used by task B may have the same image building instruction part. For example, if the basic environment required by task A and task B is the same, and the difference is the test input data, then the container file of task A and the container file of task B can be the same in terms of the basic environment building instruction part, and the image of task A and the image of task B can also be the same in terms of the basic environment part. Therefore, when building an image of task A, the building instructions in the container file of task A can be divided first, and the container file of task A can be compared with the container file of task B. The building instructions in the container file of task A that are the same as those in the container file of task B can be divided into the first building instruction group, and the building instructions in the container file of task A that are different from those in the container file of task B can be divided into the second building instruction group. The image is built according to the first building instruction group and the second building instruction group.

[0057] In some embodiments, an image may be composed of multiple image information, such as multiple image layers, each of which may correspond to an image build instruction in a container file. The cache information of a cache build instruction may be a cache image layer corresponding to the cache build instruction. Multiple cache image layers may form a cache image, such as the image of task B.

[0058] In some embodiments, based on the above-mentioned cache information, the process of building any image based on the first build instruction group and the second build instruction group may include the following operations: for the first build instruction group, copy the cache information to obtain a first image set; for the second build instruction group, rebuild the image information to obtain a second image set, and store the image information in the second image set as newly added cache information; obtain any image based on the first image set and the second image set.

[0059] In some embodiments, for the first build instruction group, since the build instructions in the first build instruction group may be the same instructions as the cache build instructions, when building an image based on the first build instruction group, the cache information of the cache build instructions can be directly copied, that is, the cache image layer is copied as the first image set of the first build instruction group. For the second build instruction group, since the build instructions in the second build instruction group may be different instructions from the cache build instructions, when building an image based on the second build instruction group, it is necessary to rebuild the image layer to obtain a second image set. The image layer in the second image set can be stored as a newly added cache image layer, so that when building an image for a new task, if the container file of the new task contains the same image build instructions as the second build instruction group, the image layer in the second image set is directly copied.

[0060] According to an embodiment of the present invention, by adopting the above-mentioned method of dividing the container file into a first build instruction group and a second build instruction group, and building the image differently according to the first build instruction group and the second build instruction group, the cache information can be directly copied for the first build instruction group, and the image information can be rebuilt for the second build instruction group. This can speed up the image building process and improve the efficiency of image building.

[0061] In some embodiments, an image tag can be automatically configured for an image during the image build process. The image tag can be obtained by: obtaining an identification subtag based on any test task; obtaining a timestamp subtag based on the build timestamp of any image; concatenating the identification subtag and the timestamp subtag to obtain an initial image tag; and concatenating a hash value subtag obtained based on the initial image tag with the initial image tag to obtain an image tag.

[0062] In some embodiments, the image tag may be ${image_name}:${timestamp}-${hash}.

[0063] The identification sub-tag can be image_name (image name), which can be obtained based on the test task. For example, identification sub-tags such as stability, function, stress, and compatibility can be obtained based on stability testing, functional testing, stress testing, and compatibility testing.

[0064] The timestamp sub-label is timestamp, which is obtained according to a build time stamp of the image.

[0065] The initial image label can be ${image_name}:${timestamp}, which is obtained by splicing {image_name} and {timestamp}.

[0066] The hash value sub-label {hash} can be obtained by performing hash processing on the initial image label. The image label ${image_name}:${timestamp}-${hash} can be obtained by splicing the hash value sub-label {hash} and the initial image label ${image_name}:${timestamp}.

[0067] In some embodiments, the built image can be automatically stored in an image warehouse and stored with the image label.

[0068] According to the embodiments of the present application, the image label is composed of the test task, the time stamp and the hash value, so that the build time information of the image is recorded, and the mapping between the identification sub-label and the hash value sub-label is realized. In the process of retrieving the image, the image can be quickly retrieved according to the identification sub-label, and the image retrieval efficiency is improved.

[0069] In some embodiments, based on the built image, a programming language control program can be developed to establish a remote connection between the test device and the device under test through a secure shell (SSH) protocol. The target image can be automatically pulled from the image warehouse and the container can be started by combining the orchestration service of Docker. For example, the test environment containing the test software, the firmware and the dependent library can be deployed by using the start command of Docker, so as to ensure that the environment of the device under test is consistent with that of the test device. The script of the programming language can also integrate the performance monitoring instructions (such as the instructions for monitoring the system disk input and output and the central processing unit usage, and the instructions for monitoring the system process and resource occupation (central processing unit and memory, etc.)) and the log collection instructions in the container, so as to facilitate the log collection and result viewing after the test is completed.

[0070] In some embodiments, the above process is to deploy the test environment for the device under test. In the case that the test environment is deployed on the device under test, the SSH remote connection between the test device and the device under test can be realized by using the remote connection library based on the programming language, and the secure communication channel can be established by key authentication.

[0071] Figure 3 A schematic diagram of a control interface of an embodiment of the present application is shown.

[0072] As Figure 3As shown, the test device can be provided with a control interface. The control interface can display a connection information area 301, a file transfer area 302, a hardware information area 303, a firmware information area 304, a status indication area 305, a log output area 306, a performance test area 307, a stress test area 308, a stability test area 309, and a log collection area 310.

[0073] The connection information area 301 can be used to input the information of the device under test, and establish a remote connection between the test device and the device under test. By inputting the IP address of the device under test, the username of the device under test, and the password of the device under test in the connection information area 301, and clicking the connection confirmation, the remote connection between the test device and the device under test can be realized. By clicking the configuration environment, one-key deployment of the environment on the device under test can be realized. By using a programming language to write a program, based on the SSH connection pool management module of the remote link library, concurrent control and task distribution of multiple devices under test can be realized, and by using a programming language script to parse the IP of the test machine, a remote link can be established, which can reduce the resource overhead caused by frequent establishment of remote links.

[0074] The file transfer area 302 can be used for the test device to transfer files to the device under test, and whether the transfer is needed can be selected according to actual needs. For example, the file path to be transferred is selected, and the selected file is sent, so that the test device can transfer files to the device under test. By clicking the test result feedback, the test result of the device under test can be received.

[0075] The hardware information area 303 can include the hardware model and quantity of the test device and / or the device under test, such as the CPU model and quantity, the memory model and quantity, and the hard disk model and quantity.

[0076] The firmware information area 304 can include the firmware model and quantity of the test device and / or the device under test, such as the firmware version number, for example, the basic input / output system version number and the baseboard management controller version number.

[0077] The status indication area 305 can include the machine connection state, the machine running state, and the machine power-on / off state between the test device and the device under test.

[0078] The log output area 306 can be used to display the test log obtained by executing the test script of the device under test in the display box 3061. By clicking the clear display box, the test in the display box 3061 can be cleared. By clicking the download display box content, the test log in the display box 3061 can be downloaded.

[0079] The performance test area 307, stress test area 308, and stability test area 309 can each include multiple related test cases. For example, the performance test area 307 can include hard disk performance test cases and memory performance test cases. The stress test area 308 can include hard disk stress test cases and memory stress test cases. The stability test area 309 can include continuous operation test cases, abnormal condition operation test cases, and restart test cases.

[0080] Test cases can be stored by test area, supporting drag-and-drop selection and batch import. Users can adjust test parameters in real time (e.g., combining multiple test disks, testing a single test disk, and the number of test cycles). For example, after selecting a target test case, users can adjust test parameters in the dialog box that pops up. After starting a test, test logs and related information can be viewed in the log output area 306.

[0081] The log collection area 310 may include a log collection button for collecting test logs obtained when the device under test executes a test script.

[0082] When a remote connection is established between the test device and the device under test, test cases in any one of the performance test area 307, the stress test area 308, and the stability test area 309 can be selected, and at least one test case in at least one test area can be selected as a target test case. In response to the selection operation of the target test case, the test script of the target test case can be transmitted to the device under test.

[0083] In some embodiments, the above method may also include the following operations: compressing the test script to obtain a compressed test script, and sending the compressed test script to the device under test; when the hash value generated based on the compressed test script is consistent with the hash value generated by the device under test based on the compressed test script, instructing the device under test to execute the test script.

[0084] In some embodiments, the test script can be transmitted after being compressed, and a program can be written in a programming language based on the compressed test script, an incremental transmission system can be implemented based on file synchronization and transmission tools, compressed transmission can be implemented in combination with data compression instructions, and the transmission status can be fed back in real time through a progress bar.

[0085] In some embodiments, file hash verification can be combined to automatically compare the integrity of the test script before and after transmission, for example, using a message digest algorithm or a secure hash algorithm. Before the device under test executes the test, the required tools and dependencies can be transferred to the device under test, and the test results and system logs can be returned after the test is completed.

[0086] In some embodiments, the device under test can decompress the compressed test script to obtain the test script, and generate a hash value based on the decompressed test script, compare the hash value with the hash value generated by the test device based on the test script, and if the hash value obtained by the device under test based on the compressed test script and the hash value obtained by the test device based on the test script are consistent, it indicates that the test script is consistent before and after transmission, and in this case, the device under test can be instructed to execute the test script. If the hash value obtained by the device under test based on the compressed test script and the hash value obtained by the test device based on the test script are inconsistent, it indicates that the test script is inconsistent before and after transmission, and in this case, the device under test cannot be instructed to execute the test script, and an alarm message indicating inconsistency before and after the test script transmission can be sent to the operation and maintenance object.

[0087] According to an embodiment of the present invention, by performing hash verification on the test script, it is possible to determine whether the test script is complete, and if the test script is complete, the test script is executed, which can improve the success rate and test efficiency of the test.

[0088] In some embodiments, the test script can be executed when the device under test is instructed to execute the test script. The test script includes an installation script, a startup script, an execution script, and a log collection script; the installation script is used to install a test tool for executing the test task; the startup script is used to start the test tool when the test tool completes installation verification; the execution script is used to execute the test task and obtain a test log when the test tool is started; the log collection script is used to collect the test log; wherein the method further includes instructing the device under test to exit the operation of executing the test script in response to one of the following situations: the test tool does not complete installation verification; the test tool is abnormally started; the test case is abnormally executed; the test log is abnormally collected.

[0089] In some embodiments, the installation script can be used to install the test tool. When the test tool completes the installation verification, that is, the test tool has been installed, the startup script can be used to start the test tool, and when the test tool starts normally, the execution script can be executed to realize the execution of the test task. When the test task is executed normally, the test logs during the execution process can be collected.

[0090] The aforementioned test tool has been installed successfully, which can be indicated by the fact that no warnings or other abnormal information were generated during the execution of the installation script, and the installation mark is a completion mark. The aforementioned test tool has been started normally, which can be indicated by the fact that no warnings or other abnormal information were generated during the startup of the test tool. The aforementioned test task has been completed normally, which can be indicated by the fact that no warnings or other abnormal information were generated during the execution of the test task.

[0091] In some embodiments, if at least one of the following situations occurs: the test tool fails to complete installation verification, the test tool is abnormally started, the test case is abnormally executed, and the test log is abnormally collected, the device under test can be instructed to exit the operation of executing the test script.

[0092] In some embodiments, the test script can be divided into four core phases: script installation, service startup, test execution, and log collection. Each phase can be encapsulated in a function and record detailed logs. By adopting a phased execution and abnormal exit mechanism during the test process, the test can be ensured to be executable and improve test efficiency.

[0093] In some embodiments, the following operations can be performed on the test log obtained by the above operations: obtain an exception log from the test log based on the exception information indicating the abnormal execution of the target test case; perform semantic analysis on the exception log to obtain the exception pattern of the exception log; generate an analysis report in a predetermined format based on the exception log and the fault handling solution for the exception pattern; and feed back the analysis report to the test device so that the test device can display the analysis report.

[0094] In some embodiments, test logs can be collected automatically. The process of automatically collecting test logs can use a task scheduling library or scheduled task in a programming language to trigger a log collection script at fixed intervals (e.g., 5 minutes); use data compression instructions to compress log files to reduce network transmission overhead; and remotely log in to the device under test through a remote connection library or remote deployment and system management tool library to execute instructions for quickly copying files or directories, or interactively encrypting file transfer instructions, and return test logs, such as a system master log file for recording information such as service startup or shutdown, error messages, and user logins; a kernel ring buffer log for recording information such as hardware events, device driver loading, and kernel errors; and a system diagnostic data collection tool log for recording output information such as system configuration, logs, and commands.

[0095] In some embodiments, the test logs collected by the above process can be pre-processed and exception logs can be extracted. The test log files can be parsed using a regular expression operation library module of a programming language, or the test logs analyzed as needed within the test log files can be parsed to extract exception information from the test logs indicating exceptions in the execution of target test cases. For example, natural language processing tools of a programming language can be used to perform natural language processing and extract keywords from the test logs, such as disk full, timeout, error code, exception description, and timestamp.

[0096] Remove duplicate log entries from the test log and retain exception information; filter irrelevant logs and only retain exception logs that include exception information, such as exception logs at the ERROR and CRITICAL levels.

[0097] In some embodiments, exception logs can be semantically analyzed using an intelligent model. For example, by uploading the logs to a deployed intelligent model via the Hypertext Transfer Protocol (HTTP) API, the intelligent model will perform semantic analysis on the test logs, identifying abnormal patterns (such as memory anomalies, dependency package anomalies, and configuration anomalies). Based on the abnormal patterns, the model will output possible root causes (such as "memory failure," "missing dependency package," and "tool management server hardware configuration error"), along with a corresponding troubleshooting solution.

[0098] In some embodiments, the process of outputting a fault handling solution based on the root cause direction may include the following operations: if there is one fault handling solution that matches the root cause direction, directly output the fault handling solution. If there are at least two fault handling solutions that match the root cause direction, a weighted summation may be performed based on the fault resolution success rate and usage frequency of the fault handling solutions, and the fault handling solutions may be sorted from high to low based on the weighted summation result, and the fault handling solutions ranked first or a preset number of the top in the sorting result may be output. If there are zero fault handling solutions that match the root cause direction, the similarity between the root cause direction of the test log and the historical root cause directions in the database may be calculated, and a preset number of historical root cause directions with the highest similarity or high similarity may be selected as reference root cause directions, and the fault handling solution for the reference root cause direction may be pushed. The preset number may be adaptively adjusted according to actual needs.

[0099] In some embodiments, the root cause direction of the test log and the fault handling solution actually used to solve the root cause may also be stored in a database.

[0100] In some embodiments, by flexibly outputting fault handling solutions based on the number of fault handling solutions that match the root cause direction, the availability of the fault handling solutions can be improved, and the fault handling efficiency and testing efficiency can be improved.

[0101] In some embodiments, for the fault handling solution and exception log obtained by the above process, a template engine of a programming language can be used to generate an analysis report in a predetermined format (e.g., Hypertext Markup Language (HTML) or Portable Document Format (PDF)). The analysis report may include a summary of the exception log, the root cause direction analyzed by the intelligent model, and the fault handling solution. The analysis report can be fed back to the test equipment so that the test equipment can display the analysis report.

[0102] According to an embodiment of the present invention, by automatically collecting and analyzing test logs to obtain root cause directions and fault handling solutions, the problems encountered during log analysis, such as long analysis time, reliance on manual experience, and difficulty in locating root causes and obtaining handling solutions, are solved, thereby improving log analysis efficiency and testing efficiency.

[0103] Figure 4 The figure shows an architecture diagram of a testing method according to an embodiment of the present invention.

[0104] like Figure 4 As shown, the testing method of this embodiment may include automated deployment of a Docker-based test environment 401, remote interconnection and testing tool installation and execution 402, and log analysis and root cause location 403.

[0105] Automated deployment of the test environment 401 can achieve automatic image building and distribution and one-click configuration of the environment.

[0106] Automatic image building and distribution: This system uses programming language scripts to dynamically generate container files based on input test requests. It also automatically writes image building instructions based on test requests (such as firmware version and test tool dependency libraries). For example, it parses configuration files for instructions such as "FROM python:3.9-slim" (the base image building instruction used when building a Docker image) and "COPY requirements.txt" (the instruction for copying a local file (requirements.txt) to the Docker image's working directory). It then invokes image building commands to generate standardized images and saves them to the control machine's image repository.

[0107] One-click environment configuration: Develop a control program in a programming language, connect to the test machine remotely via SSH, automatically pull images, and start containers. For example, use the docker-compose up –d command (used to start and manage multi-container applications defined by a docker-compose file) to deploy a test environment containing test software, firmware, and dependent libraries with a single click, ensuring that the test machine has the same environment as the original test machine.

[0108] In one embodiment, the automated deployment of the test environment 401 may include container file generation 401 - 1 , image building and optimization 401 - 2 , image repository building 401 - 3 , and one-click deployment of the test environment 401 - 4 .

[0109] The container file generates 401-1 for: integrating the request library with the programming language, calling the API to generate a JSON file; using the programming language to configure the parser, reading the test requirement file in JSON format (such as config.json), and automatically parsing parameters such as the firmware version (firmware_version) and dependency libraries (dependencies).

[0110] Image building and optimization 401-2 is used to: call the Docker API to perform image building, automatically generate image tags in the format of ${image_name}:${timestamp}-${hash}, and integrate cache layering technology to significantly speed up the process of repeatedly building images.

[0111] The image repository construction 401-3 is used to automatically store the built image in the image repository, realize the mapping between the identification subtag and the hash value, and realize the rapid retrieval of the image by the identification subtag.

[0112] One-click deployment of the test environment 401-4 is used for: programming language scripts to implement SSH batch deployment based on the remote connection library, combined with Docker orchestration services, and integrating performance monitoring instructions and log collection instructions in the container to facilitate log collection and result viewing after the test.

[0113] Remote interconnection and test tool installation and execution 402 can realize device interconnection, instruction transmission and application of graphical interface.

[0114] Device interconnection and command transmission: Use a programming language-based remote connection library to establish an SSH remote connection between the test device and the device under test, using key authentication to establish a secure communication channel. For example, executing the command "ssh user@root 'yuminstall -y ipmitool'" (a remote command executed as user logged in to a server named root) automatically installs test dependencies.

[0115] Graphical interface applications: For example, GUI programs developed using libraries for creating graphical user interface (GUI) applications can display a list of preset test cases, such as stability tests, memory stress tests, and upgrade and downgrade tests. When a user clicks a test case, the program automatically transmits the test script to the device under test and calls the test software to execute commands through standard library modules for creating and managing subprocesses. For example, "pytest --alluredir=results" (combining the instructions of the programming language testing framework (Pytest) and the test reporting tool (Allure) to generate test reports (results),) and returns progress and results in real time.

[0116] In one embodiment, remote interconnection and test tool installation and execution 402 may include integrating programming language scripts into SSH to achieve interconnection 402-1, creating a visual test case management interface 402-2, automated transmission of test software 402-3, and automated installation of test software and automatic test execution based on test scripts 402-4.

[0117] Programming language scripts integrated with SSH to achieve interconnection 402-1 is used to: use programming languages ​​to write programs, based on the SSH connection pool management module of the remote connection library, to achieve concurrent control and task distribution of multiple test machines.

[0118] Create a visual test case management interface 402-2 to build a GUI system that integrates test case display and test parameter selection. Test cases are stored by module, supporting drag-and-drop selection and batch import. Users can adjust test parameters in real time and view test logs in the log output panel after starting a test.

[0119] Test software automated transmission 402-3 is used to write a program using a programming language, implement an incremental transmission system based on file synchronization and transfer tools, and automatically compare the integrity of files before and after transfer using file hash verification. Data compression instructions are used to implement compressed transmission, and a progress bar provides real-time transmission status feedback. Before the test is executed, the required tools and dependencies are transferred to the machine under test, and test results and system logs are returned after the test is completed.

[0120] Implement automated installation of test software and automatic test execution based on test scripts 402-4 is used to: write test scripts that use phased execution and abnormal exit mechanisms to ensure test executability.

[0121] Log analysis and root cause location 403 can be used for automated log collection and preprocessing and access to intelligent models.

[0122] Automated log collection and preprocessing: Programming language scripts are written to regularly collect test logs and parse timestamps and error codes from the tests. For example, exception markers such as "Kernel panic -not syncing" (a fatal error message triggered when the kernel encounters a serious error, indicating that the system has crashed and stopped running) are extracted from dmesg (Display Message, a command used to view kernel ring buffer logs).

[0123] Accessing intelligent models: Access deployed and preliminarily trained intelligent models to analyze exception logs. Automatically upload abnormal statements in logs to the intelligent model for analysis, outputting possible root causes and troubleshooting solutions, and generating analysis reports.

[0124] In one embodiment, log analysis and root cause location 403 may include automated log collection 403 - 1 , log preprocessing and abnormal log extraction 403 - 2 , in-depth analysis using intelligent models 403 - 3 , and visual report generation and feedback 403 - 4 .

[0125] Log automated collection 403-1 is used to: use programming languages ​​to trigger log collection scripts at fixed intervals (e.g., 5 minutes); use data compression instructions to compress log files to reduce network transmission overhead; and remotely log in to the test machine to execute log return commands to return test logs.

[0126] Log preprocessing and exception log extraction 403-2 is used to parse test log files using a programming language and extract information such as timestamps, error codes, and exception descriptions using natural language processing. Duplicate log entries are removed, and key error information is retained to generate exception logs.

[0127] Accessing the intelligent model for deep analysis 403-3 is used to upload exception logs to the deployed intelligent model through the HTTP API, perform semantic analysis on the exception logs, identify exception patterns, and output possible root causes and troubleshooting solutions.

[0128] Visual report generation and return 403-4 are used to: use the programming language template engine to generate an analysis report in HTML / PDF format, including exception log summary, root cause direction, fault handling plan, etc.

[0129] The test method provided by the embodiment of the present invention combines the server soft environment configuration with the server test case execution, which can realize the functions of one-click configuration of the test environment, automatic installation of tools and execution of test tasks, and automatic collection and analysis of logs. It solves the problems of time-consuming environment configuration, inconsistent environment configuration, low environment configuration efficiency, easy testing errors, and difficult log analysis. It is conducive to the rapid location and further analysis of problems, improves the efficiency of problem location and testing, saves human resources, and achieves the purpose of reducing costs and increasing efficiency. On the other hand, the above method is simple to implement and has good practical application value.

[0130] It should be noted that, unless it is clearly stated that there is a sequence of execution between different operations shown in the flowchart in the embodiments of the present invention, or there is a sequence of execution between different operations in technical implementation, otherwise, the execution order of multiple operations may not be prioritized, and multiple operations may also be executed simultaneously.

[0131] Based on the above test method, the present invention also provides a test device. Figure 5 The device is described in detail.

[0132] Figure 5 A structural block diagram of a testing device according to an embodiment of the present invention is shown.

[0133] like Figure 5 As shown, the testing device 500 of this embodiment includes a first response module 510 and a second response module 520 .

[0134] The first responding module 510 is configured to respond to a test request from a test device and deploy a target image corresponding to the test task from a plurality of preset images to the device under test according to an identifier of the test task in the test request.

[0135] The second response module 520 is used to establish a communication connection between the test device and the device under test through a control interface set on the test device, and in response to the selection operation of the target test case through the control interface, send the test script of the target test case to the device under test so that the device under test executes the test script and obtains a test log. The target test case includes the test process and expected test results required for the test device to perform the test task.

[0136] In some embodiments, the testing device may further include a parsing module, a first generating module, and a building module.

[0137] The parsing module is used to parse the configuration file of any test task to obtain the image building parameters.

[0138] The first generation module is used to generate a container file according to the image building parameters.

[0139] The building module is used to call the container application programming interface and build an image for any test task based on the container file.

[0140] In some embodiments, the building module may include a comparing unit, a dividing unit, and a building unit.

[0141] The comparison unit is configured to compare the multiple build instructions of the container file with the cached build instructions obtained according to the historical container file to obtain a comparison result.

[0142] The dividing unit is configured to divide the multiple build instructions in the container file into a first build instruction group that is the same as the cache build instruction and a second build instruction group that is different from the cache build instruction according to the comparison result.

[0143] The building unit is configured to build any image based on the first building instruction group and the second building instruction group.

[0144] In some embodiments, a construction unit may include a replication subunit, a construction subunit, and a result subunit.

[0145] The copy subunit is configured to copy the cache information for the first build instruction group to obtain a first mirror image set.

[0146] The construction subunit is configured to reconstruct the image information according to the second construction instruction group to obtain a second image set, and store the image information in the second image set as newly added cache information.

[0147] The result subunit is configured to obtain any image according to the first image set and the second image set.

[0148] In some embodiments, the testing device may further include a first determination module, a second determination module, a splicing module, and a third determination module.

[0149] The first determining module is configured to obtain an identification sub-tag according to any test task.

[0150] The second determining module is configured to obtain a timestamp subtag according to a build timestamp of any image.

[0151] The splicing module is used to splice the identification subtag and the timestamp subtag to obtain an initial image tag.

[0152] The third determining module is configured to concatenate the hash value subtag obtained based on the initial image tag with the initial image tag to obtain an image tag.

[0153] In some embodiments, the testing device may further include a compression module and an indication module.

[0154] The compression module is used to compress the test script to obtain a compressed test script and send the compressed test script to the device under test.

[0155] The instruction module is used to instruct the device under test to execute the test script when the hash value generated based on the compressed test script is consistent with the hash value generated by the device under test based on the compressed test script.

[0156] In some embodiments, the test script includes an installation script, a startup script, an execution script, and a log collection script; the installation script is used to install a test tool for performing test tasks; the startup script is used to start the test tool after the test tool completes the installation verification; the execution script is used to execute the test task and obtain the test log when the test tool is started; the log collection script is used to collect the test log.

[0157] In some embodiments, the testing device may further include an exit module for instructing the device under test to exit the execution of the test script in response to one of the following situations: the test tool has not completed installation verification; the test tool is abnormally started; the test case is abnormally executed; the test log is abnormally collected.

[0158] In some embodiments, the testing device may further include an acquisition module, an analysis module, a second generation module, and a feedback module.

[0159] The acquisition module is used to obtain the exception log from the test log according to the exception information indicating the execution exception of the target test case.

[0160] The analysis module is used to perform semantic analysis on the abnormal logs to obtain the abnormal patterns of the abnormal logs.

[0161] The second generating module is used to generate an analysis report in a predetermined format based on the abnormality log and the fault handling solution for the abnormality mode.

[0162] The feedback module is used to feed back the analysis report to the test equipment so that the test equipment can display the analysis report.

[0163] According to embodiments of the present invention, any multiple modules in the first response module 510 and the second response module 520 may be combined into a single module, or any one of them may be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in a single module. According to embodiments of the present invention, at least one of the first response module 510 and the second response module 520 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or may be implemented in hardware or firmware through any other reasonable means of circuit integration or packaging, or implemented in any one of software, hardware, and firmware, or any suitable combination thereof. Alternatively, at least one of the first response module 510 and the second response module 520 may be at least partially implemented as a computer program module that, when executed, performs the corresponding functionality.

[0164] Figure 6 A block diagram of an electronic device suitable for implementing a testing method according to an embodiment of the present invention is shown.

[0165] like Figure 6 As shown, an electronic device 600 according to an embodiment of the present invention includes a processor 601, which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 602 or programs loaded from a storage unit 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or related chipsets and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present invention.

[0166] Various programs and data required for the operation of the electronic device 600 are stored in the RAM 603. The processor 601, ROM 602, and RAM 603 are connected to each other via a bus 604. The processor 601 executes the programs in the ROM 602 and / or RAM 603 to perform various operations according to the method flow of the embodiment of the present invention. It should be noted that the programs may also be stored in one or more memories other than the ROM 602 and RAM 603. The processor 601 may also execute the programs stored in the one or more memories to perform various operations according to the method flow of the embodiment of the present invention.

[0167] According to an embodiment of the present invention, electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to bus 604. Electronic device 600 may also include one or more of the following components connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 608 including a hard disk; and a communication section 609 including a network interface card such as a LAN card or modem. Communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. Removable media 611, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 610 as needed, so that computer programs read from the removable media can be installed into storage section 608 as needed.

[0168] The present invention also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently and not incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of the present invention.

[0169] According to an embodiment of the present invention, a computer-readable storage medium may be a non-volatile computer-readable storage medium, and may include, for example, but not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present invention, a computer-readable storage medium may include the ROM 602 and / or RAM 603 described above, and / or one or more memories other than ROM 602 and RAM 603.

[0170] The embodiment of the present invention further includes a computer program product, which includes a computer program containing program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the testing method provided by the embodiment of the present invention.

[0171] The computer program executes the above functions defined in the system / device of the embodiment of the present invention when the computer program is executed by the processor 601. According to the embodiment of the present invention, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0172] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal on a network medium, downloaded and installed via the communication portion 609, and / or installed from a removable medium 611. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0173] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609 and / or installed from a removable medium 611. When the computer program is executed by the processor 601, the above-described functions defined in the system of the embodiment of the present invention are performed. According to the embodiment of the present invention, the systems, devices, means, modules, units, etc. described above can be implemented by computer program modules.

[0174] According to an embodiment of the present invention, the program code for executing the computer program provided by the embodiment of the present invention can be written in any combination of one or more programming languages. Specifically, these computer programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).

[0175] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0176] It will be understood by those skilled in the art that the features described in the various embodiments of the present invention may be combined and / or coupled in various ways, even if such combinations or couplings are not explicitly described in the present invention. In particular, the features described in the various embodiments of the present invention may be combined and / or coupled in various ways without departing from the spirit and teachings of the present invention. All such combinations and / or couplings fall within the scope of the present invention.

[0177] The above describes embodiments of the present invention. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present invention. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present invention, those skilled in the art may make various substitutions and modifications, which should all fall within the scope of the present invention.

Claims

1. A testing method, characterized in that: The method comprises: In response to a test request from a test device, deploying a target image corresponding to the test task from a plurality of preset images to the device under test according to an identifier of the test task in the test request; In a case where a communication connection is established between the test device and the device under test via a control interface provided on the test device, in response to a selection operation of a target test case via the control interface, a test script of the target test case is sent to the device under test so that the device under test executes the test script and obtains a test log, wherein the target test case includes a test process and expected test results required for the test device to perform the test task; Among them, any one of the multiple preset images is obtained in the following manner: for the first build instruction group, copy the cache information to obtain a first image set; for the second build instruction group, rebuild the image information to obtain a second image set, and store the image information in the second image set as newly added cache information; according to the first image set and the second image set, obtain the any one image; the first build instruction group is obtained according to the build instruction in the container file that is the same as the cache build instruction, and the second build instruction group is obtained according to the build instruction in the container file that is different from the cache build instruction, and the container file is generated based on the image build parameters obtained by parsing the configuration file of any test task; The method also includes: obtaining an exception log from the test log based on exception information indicating an execution exception of a target test case; performing semantic analysis on the exception log using an intelligent model to obtain an exception pattern of the exception log; generating an analysis report in a predetermined format based on the exception log and a fault handling solution for the exception pattern; and feeding back the analysis report to the test device so that the test device can display the analysis report.

2. The method according to claim 1, characterized in that Any of the images is configured with an image tag, which is generated in the following way: According to any of the test tasks, obtaining an identification sub-tag; Obtain a timestamp subtag according to the build timestamp of any of the images; Concatenate the identification subtag and the timestamp subtag to obtain an initial image tag; The hash value subtag obtained based on the initial image tag is concatenated with the initial image tag to obtain the image tag.

3. The method according to claim 1, characterized in that The method further comprises: Compressing the test script to obtain a compressed test script, and sending the compressed test script to the device under test; In a case where the hash value generated based on the compression test script is consistent with the hash value generated by the device under test based on the compression test script, the device under test is instructed to execute the test script.

4. The method according to claim 1, wherein The test scripts include installation scripts, startup scripts, execution scripts and log collection scripts; The installation script is used to install the test tool for executing the test task; The startup script is used to start the test tool when the test tool completes installation verification; The execution script is used to execute the test task and obtain the test log when the test tool is started; the log collection script is used to collect the test log; The method further includes: instructing the device under test to exit the operation of executing the test script in response to one of the following situations: The test tool has not completed installation verification; The test tool is abnormally started; The target test case is executed abnormally; The test log is collected abnormally.

5. An electronic device comprising: one or more processors; a memory for storing one or more computer programs, It is characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 4.

6. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

Images