Upgrading method of test configuration package, test system and computing equipment

Abstract

The invention discloses a test configuration package upgrading method, a test system and computing equipment, and relates to the technical field of computing equipment. The method is applied to a first computing device. The method comprises the steps that on the basis of feature information of to-be-tested objects, downloading information of test software packages of the to-be-tested objects is obtained, and the feature information of different to-be-tested objects is different; on the basis of the downloading information, under the condition that the test software package of the to-be-tested object is updated, a target test software package of the to-be-tested object is obtained, and the target test software package comprises test information used for describing the latest version for testing the to-be-tested object. Based on the target test software package, a target test configuration package is generated, and the target test configuration package is used for testing the to-be-tested object. And sending the target test configuration packet to the second computing device. Therefore, the labor cost is reduced, and the test timeliness and accuracy are improved.

Description

Technical Field

[0001] This application relates to the field of computing device technology, and in particular to a method for upgrading a test configuration package, a test system, and a computing device. Background Technology

[0002] In the manufacturing process of computing devices (such as servers), the server or its constituent modules (such as motherboards, backplanes, circuit boards, media, etc.) can be considered as a test object, requiring testing to proactively identify and address defects. Specifically, for different specifications and versions of the test object, different test configuration packages need to be customized based on third-party provided test software packages and deployed in the production facility to assist in production testing.

[0003] In existing technologies, operators need to manually download test software packages from third-party platforms and manually create test configuration packages. This leads to problems such as high labor costs, test configuration packages being prone to errors, and difficulty in responding to update requests outside of working hours in a timely manner. Summary of the Invention

[0004] This application provides a method for upgrading a test configuration package, a test system, and a computing device, thereby reducing labor costs and improving the timeliness and accuracy of testing.

[0005] In a first aspect, embodiments of this application provide a method for upgrading a test configuration package, applied to a first computing device. The method includes: obtaining download information of a test software package for the object under test based on characteristic information of the object under test; obtaining a target test software package for the object under test, provided the download information is available and the test software package is updated; the target test software package includes test information describing the latest version for testing the object under test; generating a target test configuration package based on the target test software package, the target test configuration package being used to test the object under test; and sending the target test configuration package to a second computing device.

[0006] In this way, by obtaining the download information of the test software package through the characteristic information of the object under test, different test software packages can be automatically located and downloaded according to the differences of the object under test, eliminating the need for operators to manually download test software packages and reducing labor costs. Simultaneously, it can respond promptly when the test software package is updated, obtaining the latest version of the target test software package, and automatically generating the latest version of the target test configuration package based on the latest version of the target test software package. This overcomes the limitation of manual updates outside of working hours, automating the creation of target test configuration packages and avoiding omissions and errors that may occur during manual creation, thus improving the accuracy of the target test configuration package. Based on this, the target test configuration package is then sent to a second computing device to complete the upgrade of the test configuration package, thereby improving the timeliness and accuracy of production line testing.

[0007] In one possible implementation of the first aspect, the feature information includes one or more of the following: the type of the object under test, the system in which the object under test resides, the structural information of the object under test, and the customer information to which the object under test is applied. For example, the type of the object under test can be categorized based on two dimensions: one dimension can refer to different board modules, such as a motherboard or backplane; the other dimension can refer to different models of the same board module, such as a motherboard of model A and a motherboard of model B. The system in which the object under test resides can be understood as the system environment in which the object under test resides, including the operating system and system framework (such as x86 architecture, ARM architecture, etc.). The structural information of the object under test can include one or more detailed details from the following: the components of the object under test, the relationships between the components, the hierarchical division, and the connection methods. The customer information to which the object under test is applied can refer to the third parties to which the object under test is applied, such as customer 1 and customer 2.

[0008] In one possible implementation of the first aspect, the characteristic information of different test objects is different. Different characteristic information may refer to one or more differences in: the type of the test object, the system in which the test object is located, the structural information of the test object, the customer information applied by the test object, etc.

[0009] In one possible implementation of the first aspect, the test information may include test steps and test metrics for the object under test.

[0010] In one possible implementation of the first aspect, the test software package may include a program package and a configuration package, wherein the test step is encapsulated in the program package and the test metrics may be encapsulated in the configuration package.

[0011] In one possible implementation of the first aspect, the test software package may be published by a third party to a third-party platform for the first computing device to download automatically based on the download information.

[0012] In one possible implementation of the first aspect, obtaining the download information of the test software package of the test object based on the characteristic information of the test object includes: obtaining the identifier of the test object based on the characteristic information of the test object and a first mapping relationship. The first mapping relationship includes: a correspondence between the characteristic information of different test objects and the identifiers of the test objects, wherein the identifiers of different test objects are different. The download information of the test software package of the test object is then obtained based on the identifier of the test object.

[0013] In this way, by establishing a primary mapping relationship between feature information and identifiers, it is possible to map to downloaded information based on standardized identifiers, avoiding matching errors caused by differences in feature information descriptions. Furthermore, by using identifiers as an intermediate hub, the coupling degree of information association is reduced. For example, when feature information changes locally, only the primary mapping relationship needs to be adjusted, making it more suitable for test scenarios with multiple types of features and complex feature information of the test objects.

[0014] In one possible implementation of the first aspect, obtaining the download information of the test software package of the test object based on the identifier of the test object includes: obtaining the download information based on the identifier of the test object and a second mapping relationship. The second mapping relationship includes the correspondence between the identifiers of different test objects and the download information of the test software packages of the test objects. The download information of the test software packages is different for different test objects.

[0015] Thus, by establishing a second mapping relationship between identifiers and download information, using the identifier as the link, the complexity of directly associating feature information with download information can be reduced, improving the efficiency of download information retrieval. Furthermore, when download information is updated, only the correspondence between the identifier and the new download information in the second mapping relationship needs to be adjusted, making it more suitable for scenarios where download resources are frequently updated.

[0016] In another possible implementation of the first aspect, obtaining the download information of the test software package of the test object based on the feature information of the test object includes: obtaining the download information of the test software package of the test object mapped to the feature information of the test object based on a third mapping relationship. The third mapping relationship includes: the correspondence between the feature information of different test objects and the download information of the test software packages of the test objects.

[0017] In this way, based on this third mapping relationship, the download information of the test software package of the test object mapped to the feature information of the test object can be obtained directly, which is more efficient.

[0018] In one possible implementation of the first aspect, the download information includes the download address of the test software package of the object under test and verification information; the verification information is used to verify the legitimacy of the first computing device. Before obtaining the target test software package of the object under test, the method further includes: obtaining the version of the test software package of the object under test indicated by the download address; and determining whether the version of the test software package of the object under test indicated by the download address is consistent with the version of the test software package of the object under test stored on the first computing device. Wherein, if the version of the test software package of the object under test indicated by the download address is inconsistent with the version of the test software package of the object under test stored on the first computing device, it is determined that the test software package of the object under test has been updated.

[0019] Thus, by verifying the consistency between the version indicated by the download address and the locally saved version before obtaining the target test package, it is possible to accurately determine whether the test package has been updated, avoiding test deviations caused by using outdated versions and improving the accuracy of the testing process. Furthermore, when an update exists, the latest target test package can be obtained promptly, improving the timeliness of testing the object under test.

[0020] In one possible implementation of the first aspect, obtaining the version of the test software package of the object under test indicated by the download address includes: obtaining the version of the test software package of the object under test indicated by the download address once at a preset time interval.

[0021] In this way, it is possible to monitor test packages released in real time (such as those from third-party platforms) and download the latest target test packages in real time, thereby further improving the timeliness of testing the objects under test.

[0022] In one possible implementation of the first aspect, if the version of the test software package for the object under test indicated by the download address matches the version of the test software package for the object under test stored on the first computing device, it is determined that the test software package for the object under test has not been updated. Thus, it is unnecessary to download the version of the test software package indicated by the download address, reducing redundant downloads when versions match.

[0023] In one possible implementation of the first aspect, obtaining the target test package for the object under test includes: sending a download request to a third-party platform based on a download address, the download request requesting the download of the latest version of the target test package indicated by the download address, the download request including verification information; and receiving the target test package returned by the third-party platform.

[0024] In this way, the first computing device can securely and accurately obtain the latest target test software packages from third-party platforms, ensuring the timeliness and accuracy of downloaded resources and improving the security of the target test software package acquisition process.

[0025] In one possible implementation of the first aspect, generating a target test configuration package based on the target test package includes: generating the target test configuration package based on the target test package and configuration package generation rules. The configuration package generation rules describe the rules for generating the test configuration package.

[0026] In this way, by processing the target test package through configuration package generation rules, the generated target test configuration package follows preset rules, ensuring that the target test configuration package meets the test requirements. This allows the test process to be carried out in an orderly manner based on the compliant target test configuration package, thereby improving the standardization and reliability of test execution.

[0027] In one possible implementation of the first aspect, the configuration package generation rules may include one or more of the following: metadata generation rules, test step structuring rules, test metric association rules, exception handling rules, and execution flow rules. The metadata generation rules are used to indicate the rules for generating metadata. Metadata may include one or more of the following: configuration version, generation time (i.e., update time), the object to be tested, and the test scenario. The test step structuring rules are used to standardize the test steps. The test metric association rules are used to associate test metrics with test steps. The exception handling rules are used to define the handling rules when exceptions occur during the test. The execution flow rules are used to indicate the execution order of test steps, the dependencies between steps, and the criteria for judging the overall test results.

[0028] Thus, the target test configuration package generated based on the configuration package generation rules and the target test package can retain the test logic (including test steps and test metrics) in the target test package, follow a unified structural specification, and further standardize the test process through one or more rules included in the above configuration package generation rules, thereby improving the universality and execution efficiency of the target test configuration package.

[0029] In one possible implementation of the first aspect, after generating the target test configuration package based on the target test software package, the method further includes: storing the target test configuration package at a storage location of a first computing device indicated by a first storage path, the first storage path including version information of the target test configuration package.

[0030] Thus, storing the target test configuration package in the location indicated by the first storage path, which includes its version information, not only allows for quick identification of the test configuration package version through the first storage path, facilitating subsequent version management and tracing, but also avoids overwriting or confusion of different versions of test configuration packages due to storage path conflicts, thereby improving the orderliness of test configuration package storage and calling efficiency.

[0031] In one possible implementation of the first aspect, before sending the target test configuration package to the second computing device, the method further includes: receiving a first acquisition request from the second computing device. The first acquisition request is used to request acquisition of the target test configuration package.

[0032] This allows the second computing device to obtain the latest version of the target test configuration package and to test the object to be tested in a timely manner.

[0033] In one possible implementation of the first aspect, sending the target test configuration package to the second computing device includes: sending the target test configuration package to the second computing device after verifying the legitimacy of the second computing device.

[0034] In this way, by verifying the legitimacy of the second computing device before sending the target test configuration package, unauthorized devices are prevented from obtaining test configuration resources (i.e., the target test configuration package), thus ensuring the security of the test configuration package transmission.

[0035] Secondly, embodiments of this application provide a testing system, which includes a first computing device, a second computing device, and a third computing device. The first computing device is used to execute the test configuration package upgrade method described in the first aspect or any possible implementation of the first aspect. The second computing device is used to receive a target test configuration package from the first computing device and send the target test configuration package to the third computing device. The third computing device is used to receive the target test configuration package from the second computing device and perform tests on the object to be tested based on the target test configuration package.

[0036] Thus, through the collaboration of the first, second, and third computing devices, an automated end-to-end process is constructed, from the characteristic information of the object under test to the generation and upgrading of the target test configuration package, reducing manual costs. On the one hand, the test software package is accurately matched based on the characteristic information of the object under test, obtaining the latest version of the target test software package. The target test configuration package generated based on this can be specifically adapted to the differences of different objects under test, improving the accuracy of the generated target test configuration package, thereby improving the accuracy and reliability of the testing process. On the other hand, the orderly transmission and consistent updating of the target test configuration package among multiple computing devices are realized, ensuring that the third computing device can test the object under test based on the latest target test configuration package, improving the timeliness and efficiency of the testing process.

[0037] In one possible implementation of the second aspect, before the second computing device receives the target test configuration package from the first computing device, the second computing device is further configured to send a first acquisition request to the first computing device.

[0038] Thus, by actively sending the first acquisition request through the second computing device, the acquisition process of the target test configuration package can be triggered as needed, which can meet the actual testing needs of the third computing device.

[0039] In one possible implementation of the second aspect, the second computing device is specifically used to query whether the test configuration package in the first computing device has been updated, and if the test configuration package in the first computing device has been updated, to send a first acquisition request to the first computing device.

[0040] In this way, the second computing device can accurately trigger the acquisition process of the target test configuration package by first querying the update status of the target test configuration package in the first computing device and then sending requests as needed, avoiding the waste of resources caused by invalid requests, while ensuring that the latest target test configuration package can be obtained in a timely manner.

[0041] In one possible implementation of the second aspect, the second computing device is further configured to store the received target test configuration package at a storage location of the second computing device indicated by a second storage path, the second storage path including version information of the target test configuration package.

[0042] In this way, the second computing device sets a storage path for the target test configuration package, including version information, to achieve consistent updates and traceable management of the test configuration package and avoid version conflicts and confusion.

[0043] In one possible implementation of the second aspect, the third computing device is also used to send a second acquisition request to the second computing device before the third computing device is used to receive the target test configuration package from the second computing device.

[0044] In this way, by actively sending a second acquisition request, the third computing device can obtain the new target test configuration package without interfering with the currently executing production test, ensuring that the upgraded test configuration package can be used for the next production test, thus achieving timely upgrades of the test configuration package and ensuring the continuity and stability of the ongoing test.

[0045] In one possible implementation of the second aspect, the third computing device is specifically used to query whether the test configuration package in the second computing device has been updated, and if the test configuration package in the second computing device has been updated, to send a second acquisition request to the second computing device.

[0046] In this way, the third computing device can accurately trigger the acquisition process of the target test configuration package by first querying the update status of the target test configuration package in the second computing device and then sending the second acquisition request as needed. This avoids the waste of resources caused by invalid requests and ensures that the latest target test configuration package can be obtained in a timely manner, thereby further improving the timeliness of test configuration package upgrades.

[0047] Thirdly, embodiments of this application provide another testing system, which includes a first computing device and a third computing device. The first computing device is used to obtain download information of a test software package for the object under test based on the characteristic information of the object under test; the characteristic information differs for different objects under test. It is also used to obtain a target test software package for the object under test based on the download information, provided that the test software package for the object under test has been updated. The target test software package includes test information describing the latest version for testing the object under test. Furthermore, it is used to generate a target test configuration package based on the target test software package, which is used to test the object under test. The third computing device is used to obtain the target test configuration package and to test the object under test based on the target test configuration package.

[0048] In one possible implementation of the third aspect, the test system further includes a second computing device. The second computing device is configured to receive a target test configuration package from the first computing device and to send the target test configuration package to a third computing device. The third computing device is configured to acquire the target test configuration package, including receiving the target test configuration package from the second computing device.

[0049] In one possible implementation of the third aspect, the second computing device is further configured to store the received target test configuration package at a storage location of the second computing device indicated by a second storage path, the second storage path including version information of the target test configuration package.

[0050] Fourthly, embodiments of this application provide a computing device, including: a memory and a processor. The memory is used to store program instructions. The processor is used to execute the program instructions, causing the computing device to perform the upgrade method of the test configuration package in the first aspect or any possible implementation of the first aspect.

[0051] Fifthly, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed on a computing device, cause the computing device to perform the upgrade method of the test configuration package in the first aspect or any possible implementation of the first aspect.

[0052] In a sixth aspect, a computer program product is provided, the computer program product including computer execution instructions, which, when executed on a computing device, cause the computing device to execute the upgrade method of the test configuration package in the first aspect or any possible implementation of the first aspect.

[0053] The technical effects of any of the implementation methods in aspects three through six can be found in the technical effects of different implementation methods in aspects one and / or two, and will not be repeated here.

[0054] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0055] Figure 1 This is a schematic diagram of the structure of a testing system provided in an embodiment of this application;

[0056] Figure 2 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0057] Figure 3 A flowchart illustrating a method for upgrading a test configuration package provided in an embodiment of this application;

[0058] Figure 4 A visual flowchart illustrating a method for upgrading a test configuration package, as provided in an embodiment of this application;

[0059] Figure 5 A visual flowchart illustrating another method for upgrading a test configuration package provided in an embodiment of this application;

[0060] Figure 6 A visual flowchart illustrating another method for upgrading a test configuration package provided in an embodiment of this application;

[0061] Figure 7 A flowchart illustrating another method for upgrading a test configuration package provided in an embodiment of this application;

[0062] Figure 8 This is a schematic diagram of another computing device provided in an embodiment of this application. Detailed Implementation

[0063] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0064] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0065] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0066] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0067] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0068] In the manufacturing process of computing devices (such as servers), servers or their component modules (such as motherboards, backplanes, circuit boards, media, etc.) can be referred to as test objects, which need to be tested to intercept defects and make improvements in advance. Specifically, for different specifications and versions of the test objects, different test configuration packages need to be customized based on third-party provided test software packages and deployed in the production plant to assist in production testing.

[0069] A third party can be understood as a provider of customized testing requirements, such as Company 1. These customized testing requirements are delivered on a third-party platform in the form of a software package (which can be called a test software package). For example, if a third party is the end user (such as a purchasing customer) of product A (i.e., the object to be tested), and proposes testing requirements based on its own usage scenario to ensure that the purchased product A can adapt to its business needs, then the third party publishes a test software package for customized testing requirements of product A on its third-party platform.

[0070] The production plant area can be understood as the physical location where the aforementioned test objects are actually produced, assembled, and tested.

[0071] In this embodiment, the object to be tested can be a server or a board module included in the server. Board modules include one or more of the following: motherboard, backplane, circuit board, media, etc.

[0072] The motherboard serves as the core platform, integrating or connecting key computing components of computing devices through its interfaces. These interfaces, such as Universal Serial Bus (USB) and Peripheral Component Interconnect Express (PCIe), allow for the connection of peripherals (e.g., display cards, network cards, encryption cards) to enhance device functionality. The motherboard also houses the processor, Basic Input Output System (BIOS) chip, and other components.

[0073] The backplane is responsible for expanding the motherboard's connectivity and managing the coordinated operation of specific hardware components, such as hard drive backplanes, fan control boards, and input / output (I / O) control boards. The hard drive backplane connects the hard drive to the motherboard, enabling data transfer. The fan control board manages the operation of the cooling fans. The I / O control board handles data exchange and signal control with the external environment (such as users and other devices).

[0074] The expansion cards extend server functionality through motherboard interfaces, and include components such as baseboard management controllers (BMCs), redundant array of independent disks controllers (RAID cards), network interface cards, management boards, and switching boards. Management boards are used for overall operational status monitoring, configuration management, and maintenance control of the computing device. Switching boards are used for data traffic forwarding and routing within the computing device or between other devices.

[0075] Media can include hard drives and memory. Hard drives are used for persistent storage of operating system images, application code, business data, etc. Hard drives include hard disk drives (HDDs), solid-state drives (SSDs), and storage media using the non-volatile memory host controller interface specification (NVMe) protocol. Memory, also known as internal memory or main memory, is installed in memory slots on the motherboard of a computing device and connected to the CPU via the memory bus. It is mainly used for temporary storage of data and instructions, providing high-speed data read and write support for the processor. For example, during device operation, frequently interacting content such as operating system and application running data and temporary calculation results are temporarily stored in memory.

[0076] This application provides a method for upgrading a test configuration package. First, based on the characteristic information of the object under test, the download information of the test software package for the object under test is obtained. Different objects under test have different characteristic information. Second, based on the download information, if the test software package for the object under test is updated, a target test software package for the object under test is obtained. The target test software package includes test information describing the latest version for testing the object under test. Then, based on the target test software package, a target test configuration package is generated. The target test configuration package is used to test the object under test. Finally, the target test configuration package is sent to a second computing device.

[0077] In this way, by obtaining the download information of the test software package through the characteristic information of the object under test, different test software packages can be automatically located and downloaded according to the differences of the object under test, eliminating the need for operators to manually download test software packages and reducing labor costs. Simultaneously, it can respond promptly when the test software package is updated, obtaining the latest version of the target test software package, and automatically generating the latest version of the target test configuration package based on the latest version of the target test software package. This overcomes the limitation of manual updates outside of working hours, automating the creation of target test configuration packages and avoiding omissions and errors that may occur during manual creation, thus improving the accuracy of the target test configuration package. Based on this, the target test configuration package is then sent to a second computing device to complete the upgrade of the test configuration package, thereby improving the timeliness and accuracy of production line testing.

[0078] The following provides an exemplary description of the systems and devices used in the embodiments of this application.

[0079] like Figure 1 As shown in the figure, this application provides a testing system, which includes a first computing device and a second computing device. The first computing device and the second computing device are communicatively connected.

[0080] The first computing device is used to obtain download information of the test software package for the object under test based on the object's characteristic information. Different objects under test have different characteristic information. The first computing device is also used to obtain a target test software package for the object under test, based on the download information, if the test software package for the object under test is updated. The target test software package includes test information describing the latest version for testing the object under test. The first computing device is also used to generate a target test configuration package based on the target test software package. The target test configuration package is used to test the object under test. Furthermore, the first computing device is also used to send the target test configuration package to a second computing device.

[0081] In one implementation, the test software package can be provided by the aforementioned third-party platform. Accordingly, the first computing device can interact with the third-party platform. For example, the third-party platform could be a cloud service platform.

[0082] The second computing device can be deployed in the aforementioned production plant area, which can have one or more such plants. Figure 1 As shown, a production plant area can include production plant area 1, ..., n, where n represents the total number of production plant areas. The Internet Protocol (IP) used by the second computing devices in different production plant areas is different. Furthermore, each production plant area can be divided into multiple factory areas according to actual production needs, and the IP addresses of the second computing devices deployed in different factory areas within the same production plant area may also be different.

[0083] In some embodiments, the testing system further includes a third computing device. The third computing device is communicatively connected to the second computing device. Accordingly, the second computing device sends a target test configuration package to the third computing device. The third computing device performs tests on the object to be tested based on the target test configuration package.

[0084] The third computing device can be deployed in the aforementioned production plant area. For example, the third computing device and the second computing device can be connected via a switch network.

[0085] In one implementation, a third computing device deploys a test client. This test client can be a test program with built-in hardware interaction interface logic and a test execution framework. The hardware interaction interface logic is responsible for communication and connection between the test client and the hardware layer (such as the object under test). Specifically, it establishes a data transmission channel through the hardware interface (such as a bus or driver) of the third computing device, realizing the format conversion of test instructions in the target test configuration package and the response data returned by the object under test, as well as low-level communication management. The test execution framework is used to parse and load the target test configuration package. Specifically, it schedules the test execution process according to the test content defined in the target test configuration package. The test execution process includes the execution order of test steps, the dependencies between steps, and the overall test result judgment criteria. It sends test instructions to the object under test by calling the hardware interaction interface logic, collects response data from the object under test, and completes result verification according to the expected standards in the target test configuration package. Based on this, the third computing device is used to load the target test configuration package through the test client to perform targeted testing on the object under test.

[0086] For example, the object under test (AUT) and the test client can be deployed on the same computing device (i.e., a third computing device) or on different computing devices. For instance, if the AUT and the test client are deployed on the same computing device, the hardware interface of the third computing device is an internal bus and a built-in device driver. The internal bus could be a PCIe or an inter-integrated circuit (I2C) bus. The test client connects directly to the AUT (e.g., the motherboard) via the third computing device's internal bus and uses the third computing device's built-in driver to transmit instructions and data without additional external connections. For example, the test client can communicate directly with the PCIe slot on the motherboard via the internal PCIe bus. Alternatively, if the AUT and the test client are not on the same computing device, the hardware interface of the third computing device is an external communication interface and a corresponding external device driver. External communication interfaces could be USB or Ethernet ports. The test client needs to establish a physical connection with the device under test via an external connection line, and then interact with commands and data through an adapted external driver. For example, the test client runs on a computing device and is connected to the server where the motherboard under test is located via a network cable, and the two communicate using a network driver.

[0087] Optionally, if the object to be tested is a server, the test client establishes a physical connection with the server through the external bus mentioned above to test the server based on the target test configuration package.

[0088] For example, the first computing device, the second computing device, and the third computing device may be the same computing device or different computing devices, and this is not limited thereto. This application illustrates the example where the first computing device, the second computing device, and the third computing device are not the same computing device. The first computing device, the second computing device, and the third computing device may be collectively referred to as computing devices. In the embodiments of this application, the computing device may be a server.

[0089] The aforementioned servers can be a single physical server or logical server, or they can be composed of two or more physical servers or logical servers that share different responsibilities and work together to achieve various server functions such as data processing and service provision through division of labor and cooperation.

[0090] In terms of hardware form, servers can be blade servers, high-density servers, rack servers, or tower servers, which are suitable for different application scenarios such as high-density cluster deployment in data centers and small enterprise server rooms.

[0091] like Figure 2As shown, the hardware of a computing device includes a processor, a BIOS chip, an out-of-band controller, and memory, while the software mainly includes BIOS firmware, an out-of-band management module, and an operating system (OS).

[0092] A processor may include a central processing unit (CPU). A CPU includes one or more CPU cores, each containing an arithmetic unit, a control unit, and a register set. It supports instruction sets such as integer and floating-point arithmetic. All data processing operations are performed by the CPU cores. Under the same processor architecture (e.g., x86, ARM, RISC-V) and manufacturing process, the more CPU cores a processor has, the stronger its ability to process data in parallel, theoretically increasing data processing speed.

[0093] The BIOS chip, located in a chip slot on the motherboard, is an important piece of hardware during the boot process of a computing device. It may be an electrically erasable programmable read-only memory (EEPROM) or flash memory chip, used to store BIOS firmware, BIOS initialization parameters, and BIOS detection results of components in the computing device.

[0094] Out-of-band controllers are typically integrated into the motherboard's southbridge chip or are separate management chips, supporting management protocols such as the Intelligent Platform Management Interface (IPMI) and Redfish. As a hardware carrier, the out-of-band controller hosts the out-of-band management module, a software logic unit. This management module can be understood as a management unit for non-business modules, providing a dedicated remote management channel for computing devices. It supports remote hardware status monitoring, such as real-time acquisition of component temperature, voltage, fan speed, and power consumption; it also supports fault repair, such as isolating and marking damaged memory chips, remotely upgrading BIOS firmware, and adjusting RAID cards.

[0095] As a software logic unit that enables remote management, the out-of-band management module requires a specific hardware carrier or hardware operating mode to function.

[0096] For example, remote management functionality for an out-of-band management module is implemented based on a BMC (Band Control Controller). As an implementation of an out-of-band controller, the BMC is independent of the central processing unit (CPU) of the computing device. It integrates its own processor, memory, non-volatile storage, network interface, etc., and is powered by a backup power supply. The software logic of the out-of-band management module can be embedded and run on this BMC. Thus, the BMC provides the out-of-band management module with an OS-independent operating environment. Even if the OS is powered off, the BMC can continue operating via backup power. Simultaneously, the out-of-band management module can utilize the BMC's dedicated network channel to perform management operations such as accessing the BIOS, collecting hardware operating parameters, remotely restarting the device, and upgrading firmware.

[0097] Another example demonstrates remote management of the out-of-band management module (OBMM) based on system management mode (SMM). By triggering a System Management Interrupt (SMI) on the CPU, the CPU can temporarily detach from the OS and enter SMM. SMM is a special hardware operating mode for the CPU in a computing device. In this mode, the CPU executes the OBMM program embedded in the BIOS chip, thereby enabling remote management of the OBMM. In this example, the OBMM software logic runs on the CPU's SMM, requiring no additional hardware configuration for the OBMM, and can still manage the computing device even when the OS is not running or malfunctioning.

[0098] As can be seen, the program code of the out-of-band management module can be stored in dedicated flash memory (such as the flash memory area built into the BMC chip, the flash memory area in the BIOS chip, etc.). This type of flash memory is dedicated to storing the program code of the out-of-band management module. When it is stored in the BIOS chip, it is separate from the flash memory area in the BIOS chip used to store BIOS firmware and related parameters, and they do not occupy space together. It should be noted that the specific form of the out-of-band management module in this application embodiment is not limited; the above is only an illustrative example.

[0099] Memory, also known as internal memory or main memory, is installed in memory slots on the motherboard of a computing device and connected to the CPU via the memory bus. It is primarily used for temporary storage of data and instructions, providing high-speed data read and write support for the processor. For example, during device operation, frequently interacting content such as operating system and application runtime data, and temporary calculation results are temporarily stored in memory.

[0100] In addition, computing devices are typically equipped with storage devices such as hard drives for persistent storage of operating system images, application code, business data, etc. Integrated interfaces on the motherboard, such as USB and PCIe, can be used to connect peripherals (such as display interface cards, network interface cards, RAID cards, and encryption cards) to enhance device functionality.

[0101] BIOS firmware is a set of programs embedded in the BIOS chip. It runs first when the computing device is powered on, completes hardware initialization and detection, and then boots the OS, allowing users to use the computing device normally. It provides the lowest-level and most direct hardware settings and control for the computing device, such as setting the hard drive boot order and adjusting CPU power consumption.

[0102] An operating system (OS) is a computer program that manages and controls the hardware and software resources of a computing device. It runs on the processor, relies on hardware such as memory to work together, and is responsible for tasks such as process management, memory allocation, file system management, and device driver loading. It is the foundation for users to operate devices and for other software to run.

[0103] The OS program files are stored on external storage devices. Here, "external" refers to storage devices independent of the motherboard's core circuitry, as opposed to the CPU, memory, etc., of the computing device. Common types include hard disk drives (HDDs) and solid-state drives (SSDs) directly connected to the motherboard's storage interface. These devices are used for persistent storage of large amounts of data (such as operating system images, applications, and business data). During runtime, the operating system schedules the program files from the external storage device to memory, where the processor reads and executes the instructions.

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

[0105] For ease of understanding, the upgrade method of the test configuration package provided in the embodiments of this application will be described exemplarily below with reference to the above-described computing device and accompanying drawings.

[0106] like Figure 3 As shown in the diagram, this application provides a flowchart illustrating a method for upgrading a test configuration package. This method is applied to a first computing device, specifically executed by a processor, such as a CPU, within the computing device. The method includes:

[0107] S301, Obtain the feature information of the object to be tested.

[0108] For example, the characteristic information includes one or more of the following: the type of the object under test, the system in which the object under test resides, the structural information of the object under test, and the customer information to which the object under test is applied. For instance, the type of the object under test can be categorized in two dimensions: one dimension can refer to different board modules, such as motherboards or backplanes; the other dimension can refer to different models of the same board module, such as motherboard model A and motherboard model B. The system in which the object under test resides can be understood as the system environment in which the object under test exists, including the operating system and system framework (such as x86 architecture, ARM architecture, etc.). The structural information of the object under test can include one or more detailed details such as the components of the object under test, the relationships between the components, the hierarchical division, and the connection methods. The customer information to which the object under test is applied can refer to the third parties to which the object under test is applied, such as customer 1 and customer 2.

[0109] For example, different test objects have different characteristic information. Different characteristic information can refer to one or more differences in: the type of the test object, the system on which the test object resides, the structural information of the test object, and the customer information applied to the test object. For example, the characteristic information of test object 1 includes: Type: Motherboard of model A (the board module is the motherboard, model A); System: Operating system is Linux***7.9, system framework is x86 architecture; Structural information: Includes 2 CPU sockets, 16 memory slots, 4 PCIe 4.0×16 expansion slots, with signal connections between components and the CPU achieved through the onboard chipset; Applied customer information: Customer 1.

[0110] The characteristics of test object 2 include: Type: Model B backplane (the board module is the backplane, and the model is Model B); System: Operating system is Windows Server 2022, system architecture is ARM; Structure: Contains 24 SATA hard drive interfaces and 8 SAS expansion interfaces, connected to the motherboard's storage controller via internal cables, supporting hardware RAID signal forwarding; Client information: Client 2. It is evident that test object 1 and test object 2 differ in type (board module and model), system (operating system and architecture), structure (composition and connection method), and client information, and therefore belong to different test objects.

[0111] The characteristics of test object 3 include: Type: Motherboard of model A (the board module is the motherboard, model A); System: Operating system is Linux***7.9, system framework is x86 architecture; Structure information: Includes 2 CPU sockets, 16 memory slots, 4 PCIe 4.0×16 expansion slots, with signal connections between components and the CPU achieved through the onboard chipset; Client information: Client 2. Therefore, test object 1 and test object 2 have different client information and belong to different test objects.

[0112] Step S301 above is an optional step.

[0113] S302, Based on the characteristic information of the object under test, obtain the download information of the test software package of the object under test.

[0114] The test package for the object under test includes test information describing the tests performed on the object under test.

[0115] For example, the test information may include test steps and test metrics for the test object. For instance, taking the motherboard as the test object, the test steps may include: Step 1, powering on and initializing the motherboard, waiting for the BIOS self-test to complete; Step 2, sending commands via the IPMI interface to sequentially test the power supply voltage of CPU slots 1 to 2 (3 tests per slot, 2-second intervals); Step 3, inserting standard test memory modules into memory slots 1 to 16 respectively, and performing a memory read / write stress test (lasting 5 minutes, recording the error rate once per second); Step 4, sending test data packets to the four PCIe slots via a PCIe diagnostic tool to verify data transmission integrity (1000 data packets per slot); Step 5, collecting the raw data from all test steps and generating a preliminary test report. Test metrics may include: BIOS self-test completion time ≤ 30 seconds, no error codes; CPU socket power supply voltage stable within the range of 1.8V±0.05V, with a deviation of ≤ 0.02V over 3 tests; memory read / write error rate of 0, maximum latency ≤ 80ns; PCIe slot data packet transmission success rate of 100%, with no packet loss or verification errors; and motherboard core temperature ≤ 65℃ after all tests are completed (under an ambient temperature of 25℃).

[0116] For example, a test package may include a program package and a configuration package. The test step is encapsulated in the program package, while the test metrics can be encapsulated in the configuration package.

[0117] Download information is used to locate and obtain the test software package for the object under test. For example, download information may include the download address of the test software package and verification information for the object under test.

[0118] Download links can be as follows: For example, a third-party platform's Hypertext Transfer Protocol (HTTP) / Hypertext Transfer Protocol Secure (HTTPS) resource path, such as https: / / thirdparty-test-resources.com / *** / modelA_v1001.zip. Alternatively, an Application Programming Interface (API) download link, such as https: / / api.thirdparty-test.com / ***=A&version=latest.

[0119] The verification information is used to verify the legitimacy of the first computing device. As an example, the verification information can be a token. A token is an encrypted string generated by a third-party platform after the first computing device has successfully authenticated for the first time; it may include information such as device identity, permission scope, and validity period. As another example, the verification information can also be an access key, digital certificate, signature information, etc.

[0120] The following provides several ways to implement step S302 above:

[0121] Implementation Method 1: A third mapping relationship exists between the feature information of the object under test and the download information of its test software package. That is, the third mapping relationship includes the correspondence between the feature information of different objects under test and the download information of their test software packages, with different download information for different objects under test. Thus, based on this third mapping relationship, the download information of the test software package mapped from the feature information of the object under test can be directly obtained, which is more efficient. Table 1 shows one possible third mapping relationship as an example.

[0122] Table 1

[0123]

[0124] Implementation Method Two: A primary mapping relationship exists between the feature information of the object under test and its identifier. For example, the identifier here could be a Bill of Materials (BOM) code or an Identity Document (ID). This primary mapping relationship includes the correspondence between the feature information of different objects under test and their identifiers. Different objects under test have different identifiers. Accordingly, the identifier of the object under test can be obtained first based on this primary mapping relationship and the object's feature information. Then, based on the identifier, the download information of the object under test can be obtained. Thus, by establishing a primary mapping relationship between feature information and identifiers (BOM code / ID), download information can be mapped based on standardized identifiers, avoiding matching errors caused by differences in feature information descriptions. Furthermore, by using the identifier as an intermediary, the coupling degree of information association is reduced. For example, when feature information changes partially, only the primary mapping relationship needs to be adjusted, making it more suitable for test scenarios with multiple types of objects and complex feature information.

[0125] For example, taking the identifier as BOM encoding, Table 2 shows one possible first mapping relationship.

[0126] Table 2

[0127]

[0128] In one specific implementation of obtaining the download information of a test object based on its identifier, a second mapping relationship exists between the identifier of the test object and the download information of its test software package. This second mapping relationship includes the correspondence between the identifiers of different test objects and the download information of their test software packages. Accordingly, after obtaining the identifier of the test object, its download information can be obtained based on this second mapping relationship and the identifier. Thus, by establishing a second mapping relationship between the identifier and download information, using the identifier as the link, the complexity of directly associating feature information with download information can be reduced, improving the efficiency of download information retrieval. Furthermore, when download information (such as download address or verification information) is updated, only the correspondence between the identifier and the new download information in the second mapping relationship needs to be adjusted, making it more suitable for scenarios where download resources are frequently updated.

[0129] For example, taking the identifier as BOM encoding, Table 3 shows one possible second mapping relationship.

[0130] Table 3

[0131]

[0132] For example, one or more of the first, second, and third mapping relationships described above may be manually pre-configured and configured in the first computing device.

[0133] For example, for the same board module, different models will have different feature information, and therefore their download addresses will also be different. This is because the same board module will have different feature information due to different models, and the test software package needs to adapt to these differences (such as testing requirements).

[0134] S303, Obtain the version of the test software package for the object to be tested as indicated by the download address.

[0135] For example, the version can be represented by version information, such as 1001.

[0136] For example, the first computing device retrieves the version of the test software package for the object under test from the download address indicated at preset intervals. For instance, the preset interval can be set according to actual testing needs, such as 1 second, 5 seconds, 60 seconds, 1 minute, 5 minutes, or 10 minutes. This allows for real-time and continuous monitoring (e.g., of test software packages released by third-party platforms) and real-time download of the latest target test software package, further improving the timeliness of testing the object under test.

[0137] S304, determine whether the version of the test software package of the object to be tested indicated by the download address is consistent with the version of the test software package of the object to be tested stored in the first computing device. If not (i.e., the version of the test software package of the object to be tested indicated by the download address is inconsistent with the version of the test software package of the object to be tested stored in the first computing device), proceed to step S305.

[0138] The version of the test software package for the object under test stored on the first computing device refers to the version of the test software package that is currently in use or was last downloaded and stored locally on the first computing device.

[0139] S305, It has been determined that the test software package for the object under test has been updated.

[0140] In this embodiment, before obtaining the target test software package, the consistency between the version indicated by the download address and the locally saved version is verified to accurately determine whether the test software package has been updated. This avoids testing deviations caused by using outdated versions and improves the accuracy of the testing process. Furthermore, when a version update exists, the latest target test software package can be obtained promptly, improving the timeliness of testing the object under test.

[0141] Steps S303-S305 above are optional.

[0142] For example, if the version of the test software package for the object under test indicated by the download address matches the version of the test software package for the object under test stored on the first computing device, it is determined that the test software package for the object under test has not been updated. In this case, it is not necessary to download the version of the test software package indicated by the download address, thus reducing duplicate downloads when versions match.

[0143] S306, Based on download information, if the test software package of the object under test is updated, obtain the target test software package of the object under test.

[0144] The target test package includes test information describing the latest version of the test package used to test the object under test. In other words, the target test package is the latest version of the test package within the test package.

[0145] In one implementation of obtaining the target test package for the object under test, a download request is sent to a third-party platform based on a download address. This download request requests the latest version of the target test package indicated by the download address and includes verification information (such as a token). The target test package returned by the third-party platform is then received. During the interaction between the first computing device and the third-party platform, the third-party platform responds to the download request and parses the verification information to verify the legitimacy of the first computing device (e.g., whether it is an authorized device, whether it has permission to access the package, whether the token is valid, etc.). If the legitimacy verification result of the first computing device is valid, the third-party platform sends the target test package to the first computing device. If the legitimacy verification result of the first computing device is invalid, sending the target test package to the first computing device is prohibited. In this way, the first computing device can securely and accurately obtain the latest target test package from the third-party platform, ensuring the timeliness and accuracy of the downloaded resources and improving the security of the target test package acquisition process.

[0146] S307 generates a target test configuration package based on the target test software package.

[0147] The target test configuration package is used to test the object under test. Unlike the target test package, the target test configuration package retains the test logic of the target test package and focuses on the structured instructions and rules required for test execution. It is more adapted to the parsing and running requirements of automated test systems and can be directly called and executed by the test execution end (such as the test client of a third computing device), ensuring the standardization and consistency of the test process.

[0148] In one implementation of generating a target test configuration package based on a target test package, the target test configuration package is generated based on the target test package and configuration package generation rules. The configuration package generation rules describe the rules for generating the test configuration package. For example, the configuration package generation rules can be provided by a third party or by the provider of the object to be tested.

[0149] In this embodiment of the application, the target test software package is processed by configuration package generation rules to ensure that the generated target test configuration package follows preset rules, thereby ensuring that the target test configuration package meets the test requirements. This allows the test process to be carried out in an orderly manner based on the compliant target test configuration package, improving the standardization and reliability of test execution.

[0150] For example, configuration package generation rules may include one or more of the following: metadata generation rules, test step structuring rules, test metric association rules, exception handling rules, and execution flow rules. Metadata generation rules are used to indicate the rules for generating metadata. Metadata may include one or more of the following: configuration version, generation time (i.e., update time), object to be tested, and test scenario. Test step structuring rules are used to standardize test steps. Test metric association rules are used to associate test metrics with test steps. Exception handling rules are used to define the handling rules for exceptions that occur during testing. Execution flow rules are used to indicate the execution order of test steps, the dependencies between steps, and the criteria for judging the overall test results.

[0151] Thus, the target test configuration package generated based on the configuration package generation rules and the target test package can retain the test logic (including test steps and test metrics) in the target test package, follow a unified structural specification, and further standardize the test process through one or more rules included in the above configuration package generation rules, thereby improving the universality and execution efficiency of the target test configuration package.

[0152] The following provides an illustrative description of the configuration package generation rules and the target test configuration package generated based on these rules:

[0153] For example, configuration package generation rules may include: automatically generating a configuration version (using numerical encoding, such as "1001") and associating it with the target test package version (keeping it consistent with the target test package version, such as "modelA_v1001"); recording the configuration package generation time (accurate to the minute, in the format "YYYY / MM / DD HH:MM"); determining the test object (extracted from the test object implicit in the target test package, such as "motherboard") and the test scenario (determined based on the test steps, such as "hardware function and performance verification"). Test step structuring rules may include: assigning a unique ID to each test step (numbered in the format "STEP_XXX", such as STEP_001 to STEP_005); retaining the original operation description in the test package (such as "power on and initialize the motherboard, wait for BIOS self-test to complete"); supplementing execution parameters (derived based on test step details, such as "detection interval 2 seconds", "IPMI command port: 0x20", etc.), and marking "no additional parameters, relying on default process" when there are no additional parameters. Test metric association rules can include: binding independent test metrics in the test software package to corresponding steps (e.g., associating "BIOS self-test completion time ≤ 30 seconds" with STEP_001); refining metric descriptions (e.g., supplementing specific judgment criteria such as "no error code returned (e.g., 0x00)" and "CRC check passed"). Anomaly handling rules can include: defining processing logic for possible anomalies in each step: terminating the test and marking the cause when a critical step (e.g., BIOS initialization, CPU power supply detection) is abnormal; recording details and continuing execution when a non-critical step (e.g., memory, PCIe slot test) is abnormal; and standardizing the anomaly marking format (e.g., "[Anomaly Type]: Detailed Description"). Execution flow rules can include: specifying the execution order of steps (executed sequentially by number); and clarifying the result judgment criteria: "Test passed" if all step metrics meet the criteria, and "Test failed" if critical steps (e.g., STEP_001, STEP_002) fail to meet the criteria.

[0154] For example, the target test configuration package may include the following: Configuration version: 1001; Target test package version: modelA_v1001; Generation time: 2025 / 2 / 7 16:43; Test Object: Motherboard; Test Scenario: Hardware Function and Performance Verification; Test Steps and Corresponding Indicators: Step ID: STEP_001, Operation: Power on and initialize the motherboard, wait for the BIOS self-test to complete; Execution Parameters: No additional parameters, relies on the motherboard's default boot process; Test Indicators: Self-test completion time ≤ 30 seconds, returns no error code (e.g., 0x00); Exception Handling: If timeout or error code occurs, mark it as "BIOS initialization exception" and terminate the test; Step ID: STEP_002, Operation: Send commands through the IPMI interface to sequentially detect the power supply voltage of CPU socket 1 to socket 2 (3 times per socket, 2-second interval); Execution Parameters: 2-second detection interval, repeated 3 times per socket, IPMI command port: 0x20; Test Indicators: Power supply voltage stabilizes within the range of 1.8V±0.05V, deviation ≤ 0 for 3 detections.02V; Anomaly Handling: If the voltage exceeds the range or deviation limit in a single test, record the specific value and continue testing. If the voltage fails to meet the standard in 3 tests, mark it as "CPU power supply abnormality"; Step ID: STEP_003, Operation: Insert standard test memory modules into memory slots 1 to 16 respectively, and perform a memory read / write stress test (lasting 5 minutes, recording the error rate once per second); Execution Parameters: Test duration 5 minutes, sampling frequency 1 time / second, memory bandwidth set to the maximum supported value; Test Indicators: Read / write error rate 0, maximum latency ≤80ns; Anomaly Handling: If the error rate >0 or the latency exceeds the limit, record the corresponding slot position and specific value, and continue testing the remaining slots; Step ID: STEP_004, Operation: Send test data packets to the 4 PCIe slots through the PCIe diagnostic tool to verify the integrity of data transmission (1000 data packets per slot); Execution Parameters: Data packet size 1KB, transmission rate 10Gbps 1000 packets are sent to each slot; Test indicators: 100% data packet transmission success rate, no packet loss or verification errors (CRC check passed); Anomaly handling: If packet loss or verification errors occur, record the sequence number of the failed data packet and the slot position, and continue testing the remaining slots; Step ID: STEP_005, Operation: Collect the raw data of all test steps and generate a preliminary test report; Execution parameters: The report format is PDF+JSON, containing the raw data of each step and the comparison results of indicators; Test indicators: After all test items are completed, the motherboard core temperature ≤65℃ (under an ambient temperature of 25℃); Anomaly handling: If the temperature exceeds the limit, mark "heat dissipation performance not up to standard" in the report, but this will not affect the overall report generation. Execution rules: Step execution order: Execute in sequence from STEP_001 to STEP_005. If the previous step fails, the subsequent test will be terminated (except for STEP_003 and STEP_004, which allow some slots to continue abnormally). Result determination: If all step indicators meet the standards, the test is considered "passed"; if any critical step (STEP_001, STEP_002) fails to meet the standards, the test is considered "failed".

[0155] S308 records the version information of the target test configuration package.

[0156] S309, the target test configuration package is stored at the storage location of the first computing device indicated by the first storage path.

[0157] The first storage path includes the version information of the target test configuration package.

[0158] Thus, storing the target test configuration package in the location indicated by the first storage path, which includes its version information, not only allows for quick identification of the test configuration package version through the first storage path, facilitating subsequent version management and tracing, but also avoids overwriting or confusion of different versions of test configuration packages due to storage path conflicts, thereby improving the orderliness of test configuration package storage and calling efficiency.

[0159] In one implementation, after the target test configuration package is stored at the storage location of the first computing device indicated by the first storage path, the test configuration package is managed. For example, Tables 4, 5, and 6 show various possible management information for the test configuration package. As shown in Table 4, the BOM code differs depending on the platform or machine model, and the management information includes the BOM code, platform or machine model, customer name, service key (such as the access key mentioned above), update time, operator, and status. As shown in Table 5, the management information may include the BOM code, version information (i.e., the version information of the target test configuration package mentioned above), package name, configuration package name, update time, operator, and status. As shown in Table 6, the management information may include the BOM code, version information, production plant area, factory area, IP address of the second computing device, update time, and test configuration package storage path, or it may also include the storage path of the test software package (not shown in Table 6). It should be noted that the management information shown in Tables 4, 5, and 6 below can be combined.

[0160] Table 4

[0161]

[0162] Table 5

[0163]

[0164] Table 6

[0165]

[0166] S310, receives a first acquisition request from the second computing device.

[0167] The first acquisition request is used by the second computing device to request the target test configuration package from the first computing device.

[0168] S311, in response to the first acquisition request, verify whether the second computing device is legitimate. If yes, proceed to step S312. If no, prevent the sending of the target test configuration package to the second computing device.

[0169] For example, the first acquisition request may include verification information, which may be the same as or different from the aforementioned verification information; for ease of distinction, it can be referred to as verification information. Accordingly, in response to the first acquisition request, the first computing device parses the verification information to verify the legitimacy of the second computing device (e.g., whether it is an authorized device, whether it has permission to access the software package, whether the token is valid, etc.), and if the legitimacy verification result of the second computing device is valid, then the following step S312 is executed. If the legitimacy verification result of the second computing device is invalid, sending the target test configuration package to the second computing device is prohibited.

[0170] In this embodiment of the application, the target test configuration package is sent after the legitimacy of the second computing device is verified, which prevents unauthorized devices from obtaining test configuration resources (i.e., the target test configuration package) and ensures the security of the transmission of the test configuration package.

[0171] The steps S308-S311 above can be optional.

[0172] S312, send the target test configuration package to the second computing device.

[0173] In this embodiment, the first computing device receives a first acquisition request from the second computing device and sends a target test configuration package, enabling the second computing device to obtain the latest version of the target test configuration package for timely testing of the object to be tested. Alternatively, the first computing device can proactively send the target test configuration package to the second computing device, promptly synchronizing the latest target test configuration package to the second computing device, allowing the second computing device to automatically obtain the latest version of the target test configuration package, further improving the timeliness and synchronization efficiency of cross-device testing collaboration.

[0174] like Figure 4 As shown in the figure, this application provides a visual flowchart of a method for upgrading a test configuration package.

[0175] First, the first computing device performs the following steps: ① Determines the identifier of the object to be tested. ② Automatically obtains the target test package for the object to be tested from a third-party platform based on the identifier. ③ Creates a target test configuration package based on the target test package. ④ Records and manages the target test configuration package.

[0176] Next, multiple second computing devices (including the second computing device in production plant 1 and the second computing device in production plant n) respectively perform: ⑤ Sending a first acquisition request to the first computing device.

[0177] Finally, the first computing device performs the following step: ⑥ Sending the target test configuration package to the second computing device.

[0178] Multiple third computing devices are also deployed in production plant 1 and production plant n respectively. The third computing devices are connected to the second computing devices through a switch network and are used to test the object under test based on the target test configuration package.

[0179] like Figure 5 As shown, a visual flowchart of another method for upgrading the test configuration package is presented. The example uses the production plant as Plant 1, the factory area as Area 1, the customer name as Customer 1, and the verification information as token 1; where Plant 1 deploys a second computing device 1.

[0180] First, the first computing device performs the following: ① Automatically retrieves the target test package of the object to be tested from Client 1's platform based on token1, with version number ***.1. ② Creates a target test configuration package based on the target test package, with version number ***.1. ③ Records and manages the target test configuration package.

[0181] Next, the second computing device 1 performs the following: ④ Sends a first acquisition request to the first computing device.

[0182] Finally, the first computing device performs the following step: ⑤ Sends the target test configuration package to the second computing device 1.

[0183] In Area 1 of Plant 1, multiple third computing devices (such as third computing device 1 and third computing device 2) are also deployed. The third computing devices are connected to the second computing device 1 through a switch network and are used to test the object under test based on the target test configuration package.

[0184] In this embodiment of the application, by automating the acquisition of the target test software package, the creation of the target test configuration package based on the target test software package, the management of the target test configuration package, and the transmission of the target test configuration package to the second computing device 1 in the production environment, the efficient synchronization and standardized application of test configuration in the production scenario are achieved, ensuring the consistency and timeliness of the test process.

[0185] like Figure 6 As shown, a visual flowchart of another method for upgrading the test configuration package is presented. The example uses the production plant as Plant 1, the factory area as Area 2, the customer name as Customer 2, and the verification information as token 3; where Plant 1 deploys a second computing device 2.

[0186] First, the first computing device performs the following: ① Automatically retrieves the target test package (version number ***.3) from Client 2's platform based on token 3. ② Creates a target test configuration package (version number ***.3) based on the target test package. ③ Records and manages the target test configuration package.

[0187] Next, the second computing device 2 performs the following: ④ Sends a first acquisition request to the first computing device.

[0188] Finally, the first computing device performs the following step: ⑤ Sends the target test configuration package to the second computing device 2.

[0189] In Area 2 of Plant 1, multiple third computing devices (such as third computing device 3 and third computing device 4) are also deployed. The third computing devices are connected to the second computing device 2 through a switch network and are used to test the object under test based on the target test configuration package.

[0190] In this embodiment, the first computing device can accurately obtain the appropriate target test package and create a target test configuration package for the corresponding customer (i.e., customer 2), and send the target test configuration package to the second computing device 2. This achieves accurate adaptation of the test configuration package for a specific customer and targeted distribution across factory areas, improving the targeting of test resource matching and the flexibility of target test configuration package deployment.

[0191] like Figure 7 As shown in the embodiment of this application, another method for upgrading a test configuration package is provided. The method includes:

[0192] The first computing device performs steps S301-309 as described above. Afterwards, the following steps are performed:

[0193] S701, the second computing device queries whether the test configuration package in the first computing device has been updated.

[0194] For example, the second computing device queries and retrieves the version of the test configuration package in the first computing device, and compares the version of the test configuration package in the first computing device with the version of the test configuration package stored locally. If the version of the test configuration package in the first computing device is different from the version of the test configuration package stored locally, it is determined that the test configuration package in the first computing device has been updated; if the version of the test configuration package in the first computing device is the same as the version of the test configuration package stored locally, it is determined that the test configuration package in the first computing device has not been updated. In this way, by comparing the two versions, it accurately determines whether the test configuration package in the first computing device has been updated, avoiding the acquisition of outdated versions and improving the accuracy and timeliness of the testing process.

[0195] S702, if the test configuration package in the first computing device is updated, the second computing device sends a first acquisition request to the first computing device.

[0196] The first computing device receives a first acquisition request from the second computing device.

[0197] In this way, the second computing device can accurately trigger the acquisition process of the target test configuration package by first querying the update status of the target test configuration package in the first computing device and then sending an acquisition request as needed, avoiding the waste of resources caused by invalid requests, while ensuring that the latest target test configuration package can be obtained in a timely manner.

[0198] For example, if the test configuration package in the first computing device is not updated, the second computing device does not need to send a first acquisition request to the first computing device.

[0199] S311, the first computing device responds to the first acquisition request and verifies whether the second computing device is legitimate. If yes, proceed to step S312. If no, prevent the sending of the target test configuration package to the second computing device.

[0200] The steps S701-S702 and step S311 described above are optional steps.

[0201] S312, the first computing device sends the target test configuration package to the second computing device.

[0202] The second computing device receives the target test configuration package from the first computing device.

[0203] S703, the second computing device stores the received target test configuration package in the storage location of the second computing device indicated by the second storage path.

[0204] The second storage path includes the version information of the target test configuration package.

[0205] In this way, the second computing device sets a storage path for the target test configuration package, including version information, to achieve consistent updates and traceable management of the test configuration package and avoid version conflicts and confusion.

[0206] S704, the third computing device queries whether the test configuration package in the second computing device has been updated.

[0207] For example, the third computing device queries and retrieves the version of the test configuration package in the second computing device, and compares the version of the test configuration package in the second computing device with the version of the test configuration package stored locally. If the version of the test configuration package in the second computing device is different from the version of the test configuration package stored locally, it is determined that the test configuration package in the second computing device has been updated; if the version of the test configuration package in the second computing device is the same as the version of the test configuration package stored locally, it is determined that the test configuration package in the second computing device has not been updated. In this way, by comparing the two versions, it accurately determines whether the test configuration package in the second computing device has been updated, avoiding the acquisition of outdated versions and improving the accuracy and timeliness of the testing process.

[0208] S705, if the test configuration package in the second computing device is updated, the third computing device sends a second acquisition request to the second computing device.

[0209] The second acquisition request is used by the third computing device to request the target test configuration package from the second computing device. The second computing device receives the second acquisition request from the third computing device.

[0210] For example, if the test configuration package in the second computing device is not updated, the third computing device does not need to send a second acquisition request to the second computing device.

[0211] In this way, the third computing device can accurately trigger the target test configuration package acquisition process by first querying the update status of the target test configuration package in the second computing device and then sending the second acquisition request as needed. This avoids resource waste caused by invalid requests and ensures that the latest target test configuration package can be obtained in a timely manner. Furthermore, it can acquire the new target test configuration package without interfering with the currently executing production test, ensuring that the next production test can use the upgraded test configuration package, thus achieving timely updates of the test configuration package and guaranteeing the continuity and stability of the ongoing tests.

[0212] Steps S703-S705 above are optional.

[0213] S706, the second computing device sends the target test configuration package to the third computing device.

[0214] At the same time, the third computing device receives the target test configuration package from the second computing device.

[0215] S707, the third computing device, tests the object under test based on the target test configuration package.

[0216] In this embodiment, through the collaboration of a first computing device, a second computing device, and a third computing device, an automated end-to-end process is constructed, from the characteristic information of the object under test to the generation and upgrading of the target test configuration package, reducing manual costs. On the one hand, the test software package is accurately matched based on the characteristic information of the object under test to obtain the latest version of the target test software package. The target test configuration package generated based on this package can be specifically adapted to the differences of different objects under test, improving the accuracy of the generated target test configuration package, thereby improving the accuracy and reliability of the testing process. On the other hand, the orderly transmission and consistent updating of the target test configuration package among multiple computing devices are achieved, ensuring that the third computing device can test the object under test based on the latest target test configuration package, improving the timeliness and efficiency of the testing process.

[0217] For example, the third computing device loads the target test configuration package through the test client and performs targeted tests on the object to be tested.

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

[0219] like Figure 8 As shown, this application embodiment provides another computing device 500. The computing device 500 includes a processor 510 and a memory 520 for storing processor-executable instructions. When the processor 510 is configured to execute instructions, the computing device 500 implements the method described above.

[0220] Figure 8 The computing device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0221] The computing device 500 is manifested in the form of a general-purpose computing device. The components of the computing device 500 may include, but are not limited to: one or more processors 510, memory 520, communication bus 540 connecting different system components (including memory 520 and processor 510), and communication interface 530.

[0222] The communication bus 540 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0223] Computing device 500 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computing device, including volatile and non-volatile media, removable and non-removable media.

[0224] Memory 520 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The computing device may further include other removable / non-removable, volatile / non-volatile computer system storage media. Although Figure 8 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disc drive for reading and writing to a removable non-volatile optical disc (e.g., a compact disc read-only memory (CD-ROM), a digital video disc read-only memory (DVD-ROM), or other optical media) may be provided. In these cases, each drive may be connected to the communication bus 540 via one or more data media interfaces. The memory 520 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0225] A program / utility having a set (at least one) of program modules can be stored in memory 520. Such program modules include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The program modules typically perform the functions and / or methods described in the embodiments of this application.

[0226] The computing device 500 can also communicate with one or more external devices (e.g., keyboard, pointing device, display, etc.), and with one or more devices that enable a user to interact with the computing device, and / or with any device that enables the computing device to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). This communication can be performed through the communication interface 530. Furthermore, the computing device 500 can also communicate through a network adapter (… Figure 8(Not shown) communicates with one or more networks (e.g., Local Area Network (LAN), Wide Area Network (WAN), and / or public networks, such as the Internet). The aforementioned network adapter can communicate with other modules of the computing device via the communication bus 540. It should be understood that, although... Figure 8 As not shown, the computing device 500 may be used with other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Arrays of Independent Drives (RAID) systems, tape drives, and data backup storage systems.

[0227] The processor 510 executes various functional applications and data processing by running programs stored in the memory 520, such as implementing the methods described above in the embodiments of this application.

[0228] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the computing device 500. In other embodiments of this application, the computing device 500 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0229] It is understood that the aforementioned computing devices, etc., include hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, in conjunction with the exemplary units and algorithm steps described in conjunction with the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware-driven or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0230] This application embodiment can divide the above-mentioned computing device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0231] This application also provides a storage medium including computer program instructions, which, when executed by a computer, cause the computer to perform the method described above.

[0232] This application also provides a computer program product that, when run on a processor, causes the processor to execute the methods described above in this application.

[0233] The computing device, storage medium, or computer program product provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0234] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

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

[0237] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for upgrading a test configuration package, characterized in that, Applied to a first computing device; the method includes: Based on the feature information of the object under test, the download information of the test software package of the object under test is obtained. The feature information of different objects under test is different. Based on the download information, if the test software package of the object under test is updated, the target test software package of the object under test is obtained, and the target test software package includes test information describing the latest version for testing the object under test; Based on the target test software package, a target test configuration package is generated, which is used to test the object under test; The target test configuration package is sent to the second computing device.

2. The method according to claim 1, characterized in that, The step of obtaining the download information of the test software package for the test object based on the feature information of the test object includes: Based on the feature information of the object to be tested and the first mapping relationship, the identifier of the object to be tested is obtained; wherein, the first mapping relationship includes: the correspondence between the feature information of different objects to be tested and the identifier of the object to be tested, and the identifiers of different objects to be tested are different; Based on the identifier of the object to be tested, obtain the download information of the test software package of the object to be tested.

3. The method according to claim 1 or 2, characterized in that, The feature information includes one or more of the following: the type of the object under test, the system in which the object under test resides, the structural information of the object under test, and the customer information applied to by the object under test.

4. The method according to claim 2, characterized in that, The step of obtaining the download information of the test software package of the object under test based on the identifier of the object under test includes: The download information is obtained based on the identifier and second mapping relationship of the object to be tested; The second mapping relationship includes the correspondence between the identifiers of different test objects and the download information of the test software packages of the test objects, wherein the download information of the test software packages of different test objects is different.

5. The method according to any one of claims 1-4, characterized in that, The download information includes the download address and verification information of the test software package for the object to be tested; The verification information is used to verify the legitimacy of the first computing device; Before obtaining the target test package of the object to be tested, the method further includes: Obtain the version of the test software package for the object to be tested as indicated by the download address; Determine whether the version of the test software package of the object to be tested indicated by the download address is consistent with the version of the test software package of the object to be tested stored in the first computing device; If the version of the test software package of the object under test indicated by the download address is inconsistent with the version of the test software package of the object under test stored in the first computing device, it is determined that the test software package of the object under test has been updated.

6. The method according to any one of claims 1-5, characterized in that, The step of generating a target test configuration package based on the target test software package includes: Based on the target test package and configuration package generation rules, the target test configuration package is generated; The configuration package generation rules are used to describe the rules for generating test configuration packages.

7. The method according to any one of claims 1-6, characterized in that, After generating the target test configuration package based on the target test software package, the method further includes: The target test configuration package is stored at the storage location of the first computing device indicated by the first storage path, wherein the first storage path includes version information of the target test configuration package.

8. The method according to any one of claims 1-7, characterized in that, Before sending the target test configuration package to the second computing device, the method further includes: Receive a first acquisition request from the second computing device; The first acquisition request is used to request the acquisition of the target test configuration package.

9. The generation method according to any one of claims 1-8, characterized in that, Sending the target test configuration package to the second computing device includes: If the second computing device is verified to be legitimate, the target test configuration package is sent to the second computing device.

10. A testing system, characterized in that, The testing system includes a first computing device and a third computing device; The first computing device is used to obtain the download information of the test software package of the test object based on the feature information of the test object. The feature information of different test objects is different. It is also used to obtain a target test package for the object under test based on the download information, in the case that the test package for the object under test is updated, wherein the target test package includes test information describing the latest version for testing the object under test; and is also used to generate a target test configuration package based on the target test package, wherein the target test configuration package is used to test the object under test. The third computing device is used to obtain the target test configuration package and to test the object to be tested based on the target test configuration package.

11. A computing device, characterized in that, include: Memory and processor The memory is used to store program instructions; The processor is configured to execute the program instructions, causing the computing device to perform the method as described in any one of claims 1-9.

Images