An integrated testing method, apparatus, storage medium, and electronic device

Abstract

The application provides an integrated test method, device, storage medium and electronic equipment, wherein the method comprises the following steps: when a test instruction is received, sending a software information acquisition instruction and a hardware information acquisition instruction to a plurality of test target devices; receiving information data fed back by the plurality of test target devices; and analyzing the information data according to a pre-stored hardware and software correspondence relationship to obtain a test result corresponding to the test instruction. Through implementation of the application, information data of the plurality of test target devices is acquired according to the test instruction, and the information data is automatically analyzed according to the pre-stored hardware and software correspondence relationship, so that automatic testing of the test target devices is realized, human resource consumption in manual testing is reduced, and test efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of testing technology, and more specifically to an integrated testing method, apparatus, storage medium, and electronic device. Background Technology

[0002] Due to the rapid development of computer technology, an increasing number of application systems have emerged. An application system often consists of multiple software modules with different functions. In actual deployment, to ensure system availability, the same application system or the same software module can be deployed on multiple servers to run simultaneously, enabling mutual collaboration or data backup.

[0003] In related technologies, system testing is required before the application system goes live or during regular maintenance to confirm its proper functioning. This typically involves manual, machine-by-machine testing. Because the application system involves numerous machines, manual verification is labor-intensive and inefficient. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide an integrated testing method, apparatus, storage medium, and electronic device to solve the defects of the prior art in that the manual verification process generates certain human resource consumption and has low testing efficiency.

[0005] According to a first aspect, embodiments of the present invention provide an integration testing method, comprising the following steps: when a test instruction is received, sending software information acquisition instructions and hardware information acquisition instructions to multiple test target devices; receiving information data fed back by the multiple test target devices; analyzing the information data according to a pre-stored hardware-software correspondence to obtain the test result corresponding to the test instruction.

[0006] Optionally, when a test instruction is received, sending software information acquisition instructions and hardware information acquisition instructions to multiple test target devices includes: when the test instruction is to test the target system, searching for a pre-stored target system topology diagram; determining the test target devices in the target system based on the target system topology diagram; and sending information acquisition instructions to the test target devices.

[0007] Optionally, when a test instruction is received, software information acquisition instructions and hardware information acquisition instructions are sent to multiple test target devices, including: when a test instruction is received, sending hardware information acquisition instructions to the multiple test target devices; and if the test results of the hardware information of the multiple test target devices meet the usability conditions of the test target devices, sending software information acquisition instructions to the test target devices.

[0008] Optionally, the information data is analyzed according to a pre-stored hardware-software correspondence to obtain the test result corresponding to the test instruction. This includes: analyzing the information data to obtain the test results of the software in the test target device and the test results of the device hardware information; comparing the test results of the software in the test target device and the test results of the device hardware information with a preset minimum availability condition to obtain the test result corresponding to the test instruction, wherein the preset minimum availability condition is determined according to the pre-stored hardware-software correspondence.

[0009] Optionally, the step of analyzing the information data to obtain the test results of the software in the test target device includes: analyzing the information data according to preset judgment indicators to determine the health level of the software in the test target device, wherein the preset judgment indicators include at least one of software version indicators, health status indicators, and survival indicators.

[0010] Optionally, the step of analyzing the information data according to preset judgment indicators to determine the health level of the software in the test target device includes: when the software meets the software version indicator and the health status indicator, obtaining the health level of the software based on the quantitative relationship between the number of surviving software units in the test target device and a preset threshold.

[0011] Optionally, the health level of the software is obtained based on the relationship between the number of surviving software units in the test target device and a preset threshold, including at least one of the following methods: when the number of surviving software units in the test target device is less than the preset threshold, the software is classified as unusable software; when the number of surviving software units in the test target device is equal to the preset threshold, the software is classified as usable software; when the number of surviving software units in the test target device is greater than the preset threshold, the software is classified as healthy software.

[0012] Optionally, it also includes: distinguishing and displaying the test target device corresponding to different test results according to different display methods.

[0013] According to a second aspect, embodiments of the present invention provide an integrated testing apparatus, comprising: an instruction sending module, configured to send software information acquisition instructions and hardware information acquisition instructions to multiple test target devices when a test instruction is received; a data receiving module, configured to receive information data fed back by the multiple test target devices; and an analysis module, configured to analyze the information data according to a pre-stored hardware-software correspondence to obtain the test result corresponding to the test instruction.

[0014] According to a third aspect, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the integration testing method described in the first aspect or any embodiment of the first aspect.

[0015] According to a fourth aspect, embodiments of the present invention provide a storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the integration testing method described in the first aspect or any embodiment of the first aspect.

[0016] The technical solution of this invention has the following advantages:

[0017] The integrated testing method / device provided in this embodiment receives test instructions, acquires information data of multiple test target devices according to the test instructions, and automatically analyzes the information data according to the pre-stored hardware and software correspondence, thereby realizing automatic testing of the test target devices, reducing the human resource consumption of manual testing, and improving testing efficiency. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a specific example of the integration testing method in an embodiment of the present invention;

[0020] Figure 2 This is a specific example diagram of the integration testing method in an embodiment of the present invention;

[0021] Figure 3 This is a specific example diagram of the integration testing method in an embodiment of the present invention;

[0022] Figure 4 This is a specific example diagram of the integration testing method in an embodiment of the present invention;

[0023] Figure 5 This is a schematic diagram illustrating a specific example of an integrated testing and detection device in an embodiment of the present invention.

[0024] Figure 6 This is a schematic block diagram of a specific example of an electronic device in an embodiment of the present invention. Detailed Implementation

[0025] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0027] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can also refer to the internal connection of two components; and they can refer to a wireless connection or a wired connection. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0028] Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0029] This embodiment provides an integration testing method, such as... Figure 1 As shown, it can be applied to, for example Figure 2 The reconciliation system shown plays a crucial role in ensuring the authenticity, accuracy, and reliability of transaction data as a vital component of the online payment platform. Through this system, transaction data recorded by the system can be checked and verified, thereby further clarifying the transaction status and related debt and creditor relationships. Figure 2 As can be seen, the entire system consists of multiple software programs. In the actual deployment process, due to the different roles of the software, each software program may be deployed on multiple hardware devices for collaborative work or mutual backup. Therefore, in general, the construction of an integrated environment consists of at least several hardware devices and corresponding deployment software. The specific integration testing method includes the following steps:

[0030] S101, when a test instruction is received, software information acquisition instructions and hardware information acquisition instructions are sent to multiple test target devices;

[0031] For example, receiving test instructions can be done by receiving a user's click command in a preset area, or by receiving a user's information input command in a preset area. For instance, it could be receiving a click or input command for the name of the system to be tested, or a click or input command for the identifier of a single device to be tested. Software information acquisition instructions and hardware information acquisition instructions can include information acquisition commands, test cases, etc. For example, hardware information acquisition instructions can be commands supported by the Linux system such as ping, free, df, and top; software information acquisition instructions can be accessed using the software's HTTP interface via the curl command, or multiple test cases for the software. This embodiment does not limit the method of receiving test instructions or the software and hardware information acquisition instructions; those skilled in the art can determine them as needed.

[0032] S102, receives information data fed back from multiple test target devices;

[0033] For example, the information data returned by multiple test target devices can be hardware information data and software information data of the test target devices. Hardware information data includes network connection status, CPU, memory, network card, and disk data of the test target devices; software information data includes software version, software availability, and software health status. Software health status can be determined by running a test case in the software information acquisition instruction on the test target device, based on the relationship between the result obtained from running the test case and the expected result. Software availability can be determined by checking the software certificate validity period. This embodiment does not limit the type of information data returned by the test target devices; those skilled in the art can determine it as needed.

[0034] S103: Based on the pre-stored hardware and software correspondence, analyze the information data to obtain the test results corresponding to the test instructions.

[0035] For example, the pre-stored hardware-software correspondence includes which software or software programs are deployed on a certain hardware device, or which hardware devices or hardware devices a certain software program is deployed on. The hardware-software correspondence can be stored in the form of a topology graph. This embodiment does not limit the method of pre-stored hardware-software correspondence; those skilled in the art can determine it as needed.

[0036] The method of analyzing information data based on pre-stored hardware and software correspondence to obtain test results corresponding to test instructions may include: Step 1, analyzing information data to obtain test results of software in the target device and test results of device hardware information; Step 2, comparing the test results of software in the target device and test results of device hardware information with preset minimum availability conditions to obtain test results corresponding to test instructions. The preset minimum availability conditions are determined based on pre-stored hardware and software correspondence.

[0037] In step 1, the information data is analyzed to obtain the device hardware information test results. This can be achieved by scoring the hardware information based on whether it meets preset conditions. For example, if the target device can be pinged, it scores 60 points; normal memory performance adds 10 points; normal disk performance adds 10 points; normal CPU performance adds 10 points; and normal network card performance adds 10 points. Based on the scoring, the hardware condition of the target device is divided into four levels: good, medium, poor, and unusable, which serve as the hardware test results. For example, below 60 points is unusable, 60-70 points is poor, 70-85 points is medium, and 85-100 points is good. This embodiment does not limit the method of analyzing the information data to obtain the device hardware information test results; those skilled in the art can determine the method as needed.

[0038] In step 1, the information data is analyzed to obtain the test results of the software in the target device. This can be achieved by classifying the software as usable or unusable based on its version, availability, and health status. For example, if the software version meets the expected version, the software health status is good, and the number of surviving software devices in the system is greater than or equal to the minimum number of surviving devices for that software (i.e., there are available backup devices for that software in the system), then the software test result is considered usable. If the number of surviving software devices in the expected version is less than the minimum number of surviving devices for that software in the system, then the software test result is considered unusable. If the software version does not meet the expected version or the software health status does not meet expectations, then the software test result is considered unusable. The minimum number of surviving devices can be determined by the minimum number of usable devices required for a particular software to function normally. This embodiment does not limit the method of analyzing the information data to obtain the test results of the software in the target device or the method of determining the minimum number of surviving devices; those skilled in the art can determine these methods as needed.

[0039] In step 2, the test results of the software in the target device and the test results of the device hardware information are compared with the preset minimum availability conditions to obtain the test results corresponding to the test instructions. The preset minimum availability conditions are determined by the minimum number of devices required for a certain software to function normally in the system. For example, in the reconciliation system, at least two available software X devices are required to complete the function of software X. Therefore, the preset minimum availability condition is that there are at least two available software X devices in the reconciliation system (including the test results of software X not being unavailable and the test results of the corresponding hardware for installing software X not being unavailable).

[0040] When there are four target devices A, B, C, and D, and the hardware test results for devices A and B are not unusable, while the hardware test results for devices C and D are unusable, and each of these four devices contains software X, with the preset minimum usability condition being a minimum of 3 surviving instances of software X across all four devices, since two of the device hardware devices are unusable, even if software X is not unusable across all four devices, the test result corresponding to the test instruction for software X will still be unusable. If each of these four devices contains software Y, and the software test results for software Y are not unusable across all four devices, with the preset minimum usability condition being a minimum of 1 surviving instance of software Y across all four devices, then the test result corresponding to the test instruction for software Y will be usable.

[0041] The integrated testing method provided in this embodiment receives test instructions, acquires information data of multiple test target devices according to the test instructions, and automatically analyzes the information data according to the pre-stored hardware and software correspondence, thereby realizing automatic testing of the test target devices, reducing the human resource consumption of manual testing, and improving testing efficiency.

[0042] As an optional implementation of this embodiment, when a test instruction is received, software information acquisition instructions and hardware information acquisition instructions are sent to multiple test target devices, including: when the test instruction is to test the target system, searching for a pre-stored target system topology diagram; determining the test target devices in the target system based on the target system topology diagram; and sending information acquisition instructions to the test target devices.

[0043] For example, the system test command can be received by receiving a user's click command in a preset area, or by receiving a user's information input command in a preset area. For instance, multiple system names or input boxes can be displayed in a preset area of ​​the display interface, allowing the user to click on the system name to be tested or enter the system name in the input box. This embodiment does not limit the method of receiving system test commands; those skilled in the art can determine it as needed. The pre-stored target system topology diagram includes the hardware devices in the target system, the connections between devices, and the one-to-one, one-to-many, or many-to-one relationships between the hardware devices and the installed software. Based on the target system topology diagram, the test target device in the target system is determined, and a corresponding information acquisition command is sent to the test target device.

[0044] The integrated testing method provided in this embodiment, by searching a pre-stored target system topology diagram, makes sending information acquisition commands to the test target device no longer a large number of general acquisition commands, but rather sends targeted information acquisition commands to the devices in the target system and their corresponding commands, thereby reducing the amount of information acquisition command transmission and making it more targeted.

[0045] As an optional implementation of this embodiment, when a test instruction is received, software information acquisition instructions and hardware information acquisition instructions are sent to multiple test target devices, including:

[0046] When a test command is received, a hardware information acquisition command is sent to multiple test target devices; if the test results of the hardware information of multiple test target devices meet the conditions for the use of the test target devices, a software information acquisition command is sent to the test target devices.

[0047] For example, hardware information acquisition commands can be Linux system-supported commands such as ping, free, df, and top. The availability condition of the target device can be determined by the minimum number of devices required for a software to function correctly. For instance, in a system, if software X requires at least two hardware devices to function correctly, then the availability condition of the target device can be that at least two of the devices running software X are not unavailable. When the test results of the target device's hardware information meet the availability condition, a software information acquisition command is sent to the target device to analyze the software analysis results of software X on the corresponding hardware device. When the test results of the target device's hardware information do not meet the availability condition, the test result corresponding to the test command can be considered that software X is unavailable, and no further software information acquisition commands are sent.

[0048] The integrated testing method provided in this embodiment first determines whether the hardware of the test target device meets the availability conditions before issuing the software information acquisition command. Only when the hardware of the test target device meets the conditions is the software information acquisition command issued, instead of issuing hardware information acquisition commands and software information acquisition commands at the same time. As a result, the amount of information data received from multiple test target devices will be reduced accordingly, reducing the amount of data transmission and also reducing the amount of data analysis.

[0049] As an optional implementation method in this embodiment, the information data is analyzed to obtain the test results of the software in the target device, including:

[0050] The information data is analyzed based on preset judgment indicators to determine the health level of the software in the test target device. The preset judgment indicators include at least one of the following: software version indicator, health status indicator, and survival indicator.

[0051] For example, the software version indicator can indicate that the software version on the test target device is consistent with the expected version; the health status indicator can indicate that the software on the test target device is free of vulnerabilities, viruses, etc.; the survival indicator can indicate that the software on the test target device is alive. The survival of software can be determined by whether the software certificate has expired. When the certificate has expired, the software can be considered not alive. This embodiment does not limit the method of determining the survival of software, and those skilled in the art can determine it as needed.

[0052] The health level of the software in the test target device is determined by analyzing the information data according to the preset judgment indicators. If the software version in the test target device is inconsistent with the expected version or the software has vulnerabilities or viruses, the health level of the software in the test target device is classified as unusable. If the software version in the test target device is consistent with the expected version and the software does not have vulnerabilities or viruses, the health level of the software in the test target device is determined according to the number of software surviving in the system.

[0053] When the software version on the target device matches the expected version and the software is free of vulnerabilities and viruses, the health level of the software on the target device can be determined based on the number of software instances surviving in the system. This can be achieved by comparing the number of surviving software instances on the target device with a preset threshold. Specific classification methods include at least one of the following:

[0054] If the number of surviving software devices on the test target device is less than a preset threshold, the software is classified as unusable; if the number of surviving software devices on the test target device is equal to the preset threshold, the software is classified as usable; if the number of surviving software devices on the test target device is greater than the preset threshold, the software is classified as healthy. The preset threshold can be determined by the minimum number of devices required for a software to function normally. For example, if software X needs to survive on at least three test target devices to ensure the target system functions normally, then the preset threshold could be 3. For further details, please refer to the corresponding sections of the above embodiments, which will not be repeated here.

[0055] As an optional implementation of this embodiment, it further includes: distinguishing and displaying test target devices corresponding to different test results according to different display methods.

[0056] Based on different display methods, the unusable software, usable software, healthy software, and the test target devices corresponding to the unusable software, usable software, and healthy software are displayed separately.

[0057] For example, depending on the display method, the way to distinguish between unusable software, usable software, healthy software, and the test target devices corresponding to unusable software, usable software, and healthy software can be by using different colors / different shapes to distinguish between unusable software, usable software, healthy software, and the test target devices corresponding to unusable software, usable software, and healthy software.

[0058] like Figure 3 As shown, there are a total of 3 software A instances in the target system, with a minimum number of 1 software A instance surviving on the test target device; there are a total of 3 software B instances in the target system, with a minimum number of 2 software B instances surviving on the test target device; and there are a total of 3 software C instances in the target system, with a minimum number of 1 software C instance surviving on the test target device.

[0059] If the test results of the hardware information of the three devices on which software A is deployed are all unavailable, and software A meets the version requirements on all three test target devices, and the software is in good health and is alive on all three devices, then software A is healthy software. Software A and its corresponding test target devices can be represented by rectangles, indicating that software A runs normally on all three test target devices.

[0060] The hardware information test results of the three devices deploying software B show that test target device 3 is unavailable, while the other two are not unavailable. Furthermore, software B meets the version requirements on both of the unavailable devices, indicating that the software is healthy and alive. Therefore, software B is usable and can be represented by a diamond. Test target devices 1 and 2 can be represented by rectangles, indicating that software B runs normally on test target devices 1 and 2. Test target device 3 can be represented by a diamond, indicating that software B runs abnormally on test target device 3.

[0061] If the test results of the device hardware information of the three devices where software C is deployed are all unavailable, or although the test results of the device hardware information of the three devices are all unavailable, but software C does not meet the version requirements, or the software health is poor or it is not alive on the three devices, software C and the corresponding test target devices can be represented by circles, indicating that software C is unavailable and that software C is not running properly on the three test target devices.

[0062] The overall architecture diagram of the integration testing method described above in this embodiment is as follows: Figure 4 As shown, it comprises four layers. The bottom layer includes a software configuration library, a deployment device configuration library, and a detection attribute configuration library. The second layer includes a hardware and software analysis module and a health scoring calculation module. The third layer includes an application inspection interface layer. The fourth layer includes an application health platform and automated CI. It is evident that the integration testing method provides two external display methods: the first is a visualization platform, which allows for quick location of the status of each device and each piece of software, enabling rapid filtering of problematic software; the second is an automated CI interface, primarily used in overall automated integration CI scenarios, serving as part of unattended verification.

[0063] The core of the above architecture diagram consists of a hardware software analysis module and a health score calculation module. The hardware software analysis module is mainly used to analyze the relationship between hardware devices and software, including which software or software is deployed on a particular device, or which software or software is deployed on which devices or devices. The health score calculation module is used to calculate the health score of each software, analyzing it at different granularities to ensure that the software is usable before integrated automated testing, which is a prerequisite for the entire automation. The lowest layer contains configuration information for some basic data, including the software deployment status (i.e., including the topology diagram) and various attributes that need to be monitored (including monitoring device hardware such as CPU and memory, as well as software version, software availability, and software health status), etc.

[0064] This embodiment provides an integrated testing device, such as... Figure 5 As shown, it includes:

[0065] The instruction sending module 201 is used to send software information acquisition instructions and hardware information acquisition instructions to multiple test target devices when a test instruction is received; for details, please refer to the corresponding part of the method in the above embodiment, which will not be repeated here.

[0066] The data receiving module 202 is used to receive information data fed back by the plurality of test target devices; see the corresponding part of the method in the above embodiment for details, which will not be repeated here.

[0067] The analysis module 203 is used to analyze the information data according to the pre-stored hardware and software correspondence to obtain the test result corresponding to the test instruction. See the corresponding part of the method in the above embodiment for details, which will not be repeated here.

[0068] As an optional implementation of this embodiment, the instruction sending module 201 includes:

[0069] The topology diagram lookup module is used to look up a pre-stored topology diagram of the target system when the test instruction is to test the target system; see the corresponding part of the method in the above embodiment for details, which will not be repeated here.

[0070] The target device determination module is used to determine the test target device in the target system based on the target system topology diagram; see the corresponding part of the method in the above embodiment for details, which will not be repeated here.

[0071] The instruction sending module is used to send an information acquisition instruction to the test target device. See the corresponding section of the method in the above embodiments for details, which will not be repeated here.

[0072] As an optional implementation of this embodiment, the instruction sending module 201 includes:

[0073] The hardware information acquisition instruction sending module is used to send a hardware information acquisition instruction to the plurality of test target devices when a test instruction is received; see the corresponding part of the method in the above embodiment for details, which will not be repeated here.

[0074] The software information acquisition instruction module is used to send a software information acquisition instruction to the test target device when the test results of the hardware information of the multiple test target devices meet the usability conditions of the test target device. See the corresponding section of the method in the above embodiments for details, which will not be repeated here.

[0075] As an optional implementation of this embodiment, the analysis module 203 includes:

[0076] The first analysis submodule is used to analyze the information data to obtain the test results of the software in the test target device and the test results of the device hardware information; for details, please refer to the corresponding part of the method in the above embodiment, which will not be repeated here.

[0077] The test result determination module compares the test results of the software and hardware information in the target device with preset minimum availability conditions to obtain the test result corresponding to the test instruction. The preset minimum availability conditions are determined based on a pre-stored hardware-software correspondence. See the corresponding section of the method in the above embodiments for details, which will not be repeated here.

[0078] As an optional implementation of this embodiment, the analysis module 203 includes:

[0079] The second analysis submodule is used to analyze the information data according to preset judgment indicators to determine the health level of the software in the test target device. The preset judgment indicators include at least one of software version indicators, health status indicators, and survival indicators. See the corresponding section of the method in the above embodiments for details, which will not be repeated here.

[0080] As an optional implementation of this embodiment, the second analysis submodule includes:

[0081] The health level determination module is used to determine the health level of the software based on the relationship between the number of surviving software units in the test target device and a preset threshold, when the software meets the software version index and the health status index. See the corresponding section of the method in the above embodiments for details, which will not be repeated here.

[0082] As an optional implementation of this embodiment, the health level determination module includes at least one of the following methods:

[0083] The unusable software determination module is used to classify the software as unusable software when the number of surviving software units in the test target device is less than the preset threshold; see the corresponding part of the method in the above embodiment for details, which will not be repeated here.

[0084] The available software determination module is used to classify the software as available software when the number of surviving software units in the test target device is equal to the preset threshold; see the corresponding part of the method in the above embodiment for details, which will not be repeated here.

[0085] The healthy software determination module is used to classify software as healthy software when the number of surviving software devices in the test target device is greater than the preset threshold. See the corresponding section of the method in the above embodiments for details, which will not be repeated here.

[0086] As an optional implementation of this embodiment, it further includes: a display module, used to distinguish and display the test target device corresponding to different test results according to different display methods. See the corresponding part of the method in the above embodiment for details, which will not be repeated here.

[0087] This application also provides an electronic device, such as... Figure 6 As shown, processor 310 and memory 320 are connected via a bus or other means.

[0088] Processor 310 may be a central processing unit (CPU). Processor 310 may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations thereof.

[0089] The memory 320, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the integration testing method in this embodiment of the invention. The processor executes various functional software and data processing by running the non-transitory software programs, instructions, and modules stored in the memory.

[0090] The memory 320 may include a program storage area and a data storage area. The program storage area may store the operating system and software programs required for at least one function; the data storage area may store data created by the processor. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 320 may optionally include memory remotely located relative to the processor, which can be connected to the processor 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.

[0091] The one or more modules are stored in the memory 320, and when executed by the processor 310, they perform actions such as... Figure 1 The integration testing method in the illustrated embodiment.

[0092] For specific details regarding the aforementioned electronic devices, please refer to the relevant documentation. Figure 1 The relevant descriptions and effects in the illustrated embodiments are for understanding purposes only and will not be repeated here.

[0093] This embodiment also provides a computer storage medium storing computer-executable instructions that can execute the integrated testing method in any of the above-described method embodiments 1. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0094] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. An integration testing method, characterized in that, Includes the following steps: When a test instruction is received, software information acquisition instructions and hardware information acquisition instructions are sent to multiple test target devices, including: when the test instruction is to test the target system, searching a pre-stored target system topology diagram; determining the test target devices in the target system according to the target system topology diagram; sending information acquisition instructions to the test target devices; and if the test results of the hardware information of the multiple test target devices meet the usability conditions of the test target devices, sending software information acquisition instructions to the test target devices. Receive information data fed back from the multiple test target devices; Based on the pre-stored hardware and software correspondence, the information data is analyzed to obtain the test results corresponding to the test instructions; The step of analyzing the information data based on pre-stored hardware-software correspondences to obtain the test results corresponding to the test instructions includes: The information data is analyzed to obtain the test results of the software in the target device and the test results of the device hardware information. The test results of the software and hardware information in the target device are compared with the preset minimum availability conditions to obtain the test results corresponding to the test instruction. The preset minimum availability conditions are determined by the minimum number of devices required for the software to function normally in the system.

2. The method according to claim 1, characterized in that, The analysis of the information data to obtain the test results of the software in the target device includes: The information data is analyzed according to preset judgment indicators to determine the health level of the software in the test target device. The preset judgment indicators include at least one of software version indicators, health status indicators, and survival indicators.

3. The method according to claim 2, characterized in that, The step of analyzing the information data according to preset judgment indicators to determine the health level of the software in the test target device includes: When the software meets the software version index and the health status index, the health level of the software is obtained based on the relationship between the number of software surviving devices in the test target device and the preset threshold.

4. The method according to claim 3, characterized in that, The health level of the software is obtained based on the relationship between the number of surviving software devices in the test target device and a preset threshold, including at least one of the following methods: If the number of surviving software devices in the test target device is less than the preset threshold, the software is classified as unusable software. When the number of surviving software units in the test target device is equal to the preset threshold, the software is classified as usable software. If the number of surviving software devices in the test target device is greater than the preset threshold, the software is classified as healthy software.

5. The method according to claim 1, characterized in that, Also includes: Different test target devices are distinguished based on different display methods to display different test results.

6. An integrated testing device, characterized in that, include: The instruction acquisition and sending module is used to send software information acquisition instructions and hardware information acquisition instructions to multiple test target devices when a test instruction is received. Specifically, when the test instruction is to test the target system, the module searches a pre-stored target system topology diagram; determines the test target devices in the target system based on the target system topology diagram; sends information acquisition instructions to the test target devices; and sends software information acquisition instructions to the test target devices when the test results of the hardware information of the multiple test target devices meet the usability conditions of the test target devices. The data receiving module is used to receive information data fed back by the multiple test target devices; The analysis module is used to analyze the information data according to the pre-stored hardware and software correspondence to obtain the test results corresponding to the test instructions; Specifically, the analysis module is used to analyze the information data to obtain the test results of the software in the test target device and the test results of the device hardware information. The test results of the software and hardware information in the target device are compared with the preset minimum availability conditions to obtain the test results corresponding to the test instruction. The preset minimum availability conditions are determined by the minimum number of devices required for the software to function normally in the system.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the integration testing method according to any one of claims 1-5.

8. A storage medium storing computer instructions thereon, characterized in that, When executed by the processor, this instruction implements the steps of the integration test method according to any one of claims 1-5.

Images