Diagnostic component management method, electronic device, storage medium, and program product

Abstract

The application discloses a diagnosis component management method, an electronic device, a storage medium and a program product, and relates to the technical field of computers. In the application, program languages in diagnosis software are divided into multiple test items, and the program languages corresponding to the test items are encapsulated as underlying components, so that the underlying components can be used individually. The acquisition mode of the underlying components in the stress testing tool is set as a function expression mode to identify underlying components matched with the hardware device, the speed of building the stress testing tool is improved, the underlying components, the performance test cases and the stress testing tool are managed independently, the underlying component versions are managed uniformly, the maintenance and management of the underlying components do not need manual participation, and the management standardization of the underlying components is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a diagnostic component control method, electronic device, storage medium, and program product. Background Technology

[0002] With the rapid development of information technology, the market demand for servers, as core devices for data processing and storage, continues to expand. Different application scenarios place diverse demands on server performance, stability, energy efficiency, and size, driving the diversification of server products. In the server manufacturing process, diagnostic components have become a key factor in testing. To ensure that shipped products fully meet customer needs and guarantee product quality, server diagnostics are performed during factory testing. This includes stress testing key components such as CPU, memory, hard drive, GPU, and network card under specific conditions (such as temperature), and checking the machine's current status, such as link, basic component information, and system logs. This diagnostic process improves product reliability and pass rate, meeting various customer requirements. Ensuring the rapid import and iteration of diagnostic software for different products, and supporting unified management and upgrades across factories in various locations, is a challenge that must be addressed. Currently, the modularity of diagnostic components is insufficient, leading to redundant development across different projects and hard-coded functions. Frequent code modifications result in low efficiency in importing diagnostic software during rapid product iteration. Unclear functional divisions require version modifications for each model during upgrades, leading to inconsistent version usage across factories and making management difficult. In general, diagnostic component management relies heavily on manual processes and cannot be handled through a unified and automated system. Summary of the Invention

[0003] This application provides a diagnostic component management method, electronic device, storage medium, and program product to at least solve the problems in the related art of diagnostic component management, which are characterized by reliance on manual processing and inconsistent component version usage, making it impossible to process them in a unified and automated manner through a system.

[0004] This application provides a method for managing diagnostic components, including:

[0005] The diagnostic software program code is divided into multiple test item program codes according to the diagnostic functions, and the program code corresponding to the test item is encapsulated into a low-level component, wherein the test item is associated with a performance test case;

[0006] The underlying components are classified, and function expressions are set for the underlying components of the same class, wherein the function expressions are associated with at least one of the test items;

[0007] Obtain the hardware device to be subjected to load performance testing, set up a load testing tool for the hardware device, the load testing tool includes at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item.

[0008] Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the stress testing tool and associate it with the target test item.

[0009] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the diagnostic component control methods described above when executing the computer program.

[0010] The diagnostic software program code is divided into multiple test item program codes according to the diagnostic functions, and the program code corresponding to the test item is encapsulated into a low-level component, wherein the test item is associated with a performance test case;

[0011] The underlying components are classified, and function expressions are set for the underlying components of the same class, wherein the function expressions are associated with at least one of the test items;

[0012] Obtain the hardware device to be subjected to load performance testing, set up a load testing tool for the hardware device, the load testing tool includes at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item.

[0013] Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the stress testing tool and associate it with the target test item.

[0014] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described diagnostic component control methods:

[0015] The diagnostic software program code is divided into multiple test item program codes according to the diagnostic functions, and the program code corresponding to the test item is encapsulated into a low-level component, wherein the test item is associated with a performance test case;

[0016] The underlying components are classified, and function expressions are set for the underlying components of the same class, wherein the function expressions are associated with at least one of the test items;

[0017] Obtain the hardware device to be subjected to load performance testing, set up a load testing tool for the hardware device, the load testing tool includes at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item.

[0018] Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the stress testing tool and associate it with the target test item.

[0019] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of any of the diagnostic component control methods described above:

[0020] The diagnostic software program code is divided into multiple test item program codes according to the diagnostic functions, and the program code corresponding to the test item is encapsulated into a low-level component, wherein the test item is associated with a performance test case;

[0021] The underlying components are classified, and function expressions are set for the underlying components of the same class, wherein the function expressions are associated with at least one of the test items;

[0022] Obtain the hardware device to be subjected to load performance testing, set up a load testing tool for the hardware device, the load testing tool includes at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item.

[0023] Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the stress testing tool and associate it with the target test item.

[0024] This application divides the programming language in diagnostic software into multiple test items, encapsulates the programming language corresponding to each test item into a low-level component, enabling the low-level component to be used independently, and sets the acquisition method of the low-level component in the load testing tool to identify the low-level component matching the hardware device through functional expressions, thereby improving the speed of building the load testing tool, decoupling the management of the low-level component from the performance test cases and the load testing tool, enabling unified management of the low-level component versions, and eliminating the need for manual intervention in the maintenance and management of the low-level component, thus improving the management standardization of the low-level component. Attached Figure Description

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

[0026] Figure 1 This is a diagram illustrating the application environment of a diagnostic component management method in one embodiment of this application.

[0027] Figure 2 This is a flowchart illustrating a diagnostic component management method in one embodiment of this application;

[0028] Figure 3 This is a schematic diagram of a customized overall architecture based on functional expressions in one embodiment of this application;

[0029] Figure 4 This is a timing diagram of the interaction of functional expressions in one embodiment of this application;

[0030] Figure 5 This is a structural block diagram of a diagnostic component control device in one embodiment of this application;

[0031] Figure 6 This is an internal structural diagram of a computer device in one embodiment of this application. Detailed Implementation

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

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

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

[0035] Diagnostic system software consists of different components. In software development, systems are often divided into multiple functional modules or components, each with its specific function and role. Currently, the management of diagnostic components is largely manual and cannot be achieved through unified and automated system processing.

[0036] The current diagnostic component management process has the following deficiencies:

[0037] Insufficient modularity: The components lack modularity and expression configuration, which leads to frequent code modifications required for feature updates, seriously affecting the product launch schedule;

[0038] Version import requires a lot of manual operation: the existing technical solution defines the version independently in the product configuration file, and the configuration file needs to be manually updated in batches when importing the version;

[0039] There is no unified version management mechanism: Versions need to be released manually, which leads to missed updates or inconsistent versions in factories in different regions;

[0040] The version changelog is not user-friendly: the current technology uses email to release changes, which requires searching through emails to view the changelog, making it inconvenient to view changelogs from several years ago.

[0041] Diagnostic testing is a critical step in ensuring product reliability and stability during server manufacturing. However, existing server diagnostic software management methods face the following technical challenges:

[0042] Development efficiency: Duplication of development between different products, insufficient modularity, and the need for hard coding of customized requirements seriously affect the development efficiency of diagnostic software.

[0043] Import efficiency: Different products have separate versions of diagnostic components, which require manual batch updates during import, severely impacting import efficiency.

[0044] Integrated construction of factories in multiple locations: During the rapid introduction and integrated construction of global factory diagnostic software, the existing processing methods have led to management difficulties and the inability to update diagnostic components consistently, which seriously affects the rapid production scheduling of multiple products in factories in various locations.

[0045] The diagnostic component management method provided in this application can be applied to, for example... Figure 1The application environment shown is as follows. The component management platform connects to factories in various locations via a version control center. The platform includes a platform layer, a software layer, and a product layer. The platform layer contains cross-platform languages ​​supported by the underlying components, including x86, non-x86, and various brand-specific languages. The software layer includes a basic library, test items, and modular interfaces. The basic library stores performance test cases, and the test items store the code implementing the corresponding test functions. The modular interfaces are used for interaction and communication. The product layer categorizes the underlying components according to the functions of the hardware devices they are applicable to. Hardware device functions are divided into general functions and customized functions, further categorized into computing products, storage products, artificial intelligence products, and other products. The version control center monitors the versions of the underlying components in the component management platform in real time and releases the latest versions of the underlying components to factories in various locations, enabling factories to use a unified version of the underlying components for diagnostic testing. This application achieves centralized and unified management of components through a layered design of platform-based and expression-based diagnostic software, automatic upgrades of innovative components, and unified management of components. The purpose of this application is to enable automatic updates of diagnostic components in various factories, ensure consistent component versions across different factories, reduce human intervention during the upgrade process, and thus achieve rapid import of diagnostic components for various products, meeting the market's demand for efficient and high-quality diagnostic software.

[0046] like Figure 2 As shown, an embodiment of this application provides a diagnostic component management method, including the following steps:

[0047] Step S1: Divide the program code in the diagnostic software into program code for multiple test items according to the diagnostic function, and encapsulate the program code corresponding to the test items into underlying components, wherein the test items are associated with performance test cases;

[0048] Step S2: Classify the underlying components and set function expressions for underlying components of the same category, wherein the function expression is associated with at least one test item;

[0049] Step S3: Obtain the hardware device to be tested for load performance, set up a load testing tool for the corresponding hardware device, the load testing tool contains at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item.

[0050] Step S4: Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the load testing tool and associate it with the target test item.

[0051] This application divides the programming language in diagnostic software into multiple test items, encapsulates the programming language corresponding to each test item into low-level components, and enables these low-level components to be used independently. The low-level components in the load testing tool are obtained by identifying the low-level components that match the hardware device through functional expressions, which improves the speed of building the load testing tool. The low-level components are decoupled from the performance test cases and the load testing tool, enabling unified management of low-level component versions. The maintenance and management of low-level components do not require manual intervention, thus improving the standardization of low-level component management.

[0052] In this embodiment, the program code in the diagnostic software is divided into multiple test item code according to the diagnostic function, and the program code corresponding to the test item is encapsulated into a low-level component. The test item is associated with the performance test case, including:

[0053] The diagnostic software is platformized into a platform layer, a basic software layer, and a functional layer.

[0054] Identify the language type of the program code in the diagnostic software and store the language type of the program code within the platform layer;

[0055] The programming language in the diagnostic software is divided into multiple test items according to the diagnostic function, and the programming language corresponding to the test items is stored in the basic software layer.

[0056] Obtain the performance test cases associated with the test items, set up a basic library in the basic software layer to store the performance test cases, and store the associated linked list of performance test cases and test items;

[0057] The programming language corresponding to the test item is encapsulated as a low-level component, and a modular interface is set for the low-level component. The modular interface is then stored in the basic software layer.

[0058] The underlying components are categorized by function, and the underlying components are stored in the functional layer.

[0059] In the layered design of diagnostic software, the lower-level components play a crucial role in directly interacting with the hardware and operating system. The following are key considerations and implementation strategies for the design of lower-level components: Platform Adaptability: Lower-level components need to be able to run on various operating systems and hardware platforms, thus requiring good platform adaptability. Cross-Platform Programming Language and Tool Selection: Choosing programming languages ​​that can run across platforms, or using platform-independent development frameworks and libraries, ensures that lower-level components can be compiled and executed on different operating systems.

[0060] In this embodiment, the programming language corresponding to the test item is encapsulated as a low-level component, and a modular interface is set for the low-level component. The modular interface is stored in the basic software layer, including:

[0061] Set up an operating system abstraction layer, encapsulate the modular interface of the test items using the operating system abstraction layer, encapsulate the programming language corresponding to the test items as the underlying component, and store the modular interface in the basic software layer, and interact and communicate with the underlying component through the modular interface.

[0062] The operating system abstraction layer (OSA) design involves defining a clearly defined OSA layer that encapsulates OS-specific function calls and interfaces. This allows underlying components to share code and logic across different operating systems while reducing platform-specific dependencies. Modular interfaces are also encapsulated for underlying components, enabling them to be used independently.

[0063] In this embodiment, the underlying components are classified into ordinary functions and customized functions, and test items are associated in the functional layer according to the classification of ordinary functions and customized functions.

[0064] The interface design of the underlying components should be flexible and stable, allowing upper-layer modules to access their functionality securely and efficiently. A modular interface design approach is adopted to break down the underlying components into independent modules, each responsible for a specific function, interacting and communicating through clear interfaces. Test items are categorized and stored for easy retrieval and maintenance.

[0065] In this embodiment, when using the operating system abstraction layer to encapsulate the modular interface of the test items, it further includes:

[0066] Determine whether the test item interacts with the hardware device;

[0067] In response to the interaction between the test item and the hardware device, a standardized hardware interface is set for the test item. The standardized hardware interface interacts with the hardware device through a unified data format and transmission protocol.

[0068] If interaction with hardware devices is required, define standardized hardware interfaces to simplify the development and maintenance of hardware drivers, while providing a unified data format and transmission protocol.

[0069] In this embodiment, running the target function expression and obtaining the underlying component that matches the hardware device as the target underlying component through the function expression includes:

[0070] Obtain the target function expression of the load testing tool. The target function expression includes obtaining hardware properties, checking hardware properties, keyword checking, refreshing hardware properties, comparing hardware properties, and obtaining all properties.

[0071] Run the target function expression and obtain the target hardware attributes in the corresponding target performance test case based on the content of the target function expression;

[0072] Obtain the attributes of the hardware device, compare the attributes of the hardware device with the attributes of the target hardware, and determine the underlying components that match the attributes of the hardware device.

[0073] The identified underlying components that match the attributes of the hardware device are used as the target underlying components.

[0074] Load testing tools are used in the diagnostic software development process to test and evaluate system performance and stability. Designing load testing tools requires consideration of the following aspects: Adaptability to various machine types: The load testing tool needs to be able to run on hardware devices with different performance and configurations to simulate performance under different load conditions. Performance simulation and test cases: Design diverse performance test cases covering different aspects of load, such as CPU, memory, and I / O, to reflect the differences in software performance under different hardware configurations. Resource utilization optimization: Optimize the resource utilization of the load testing tool to ensure its stable operation on various hardware devices without causing additional system burden, such as reducing the occupation of system resources (e.g., memory, CPU). During server production load testing, abnormal data from various components on the production side will be captured, such as machine failures, production interruptions, and product quality issues.

[0075] In this embodiment, the diagnostic component management method further includes:

[0076] Set the target defective hardware device;

[0077] Obtain the detection results of the load testing tool on the target defective hardware device, identify abnormal data in the detection results, and determine the accuracy score of the load testing tool on the target defective hardware device;

[0078] If the accuracy score of the load testing tool for detecting the target defective hardware device is greater than the first threshold, the load testing tool is deemed qualified.

[0079] If the accuracy score of the load testing tool for detecting the target defective hardware device is less than or equal to the first threshold, the load testing tool is deemed unqualified. Based on the detection results, the unqualified underlying components in the load testing tool are identified, and the code of the underlying components is optimized based on the detection results.

[0080] This application uses a test result verification method to continuously optimize the code of the underlying components, thereby improving the detection accuracy of the load testing tool.

[0081] Among these features, the expression processing engine, based on the platform's core functions, enables rapid adaptation to customized customer requirements. Customizing requirement expressions significantly reduces the frequency of code updates, allowing for customization changes and requirements to be implemented through configuration. Functional expressions also enable the rapid import of test items corresponding to the testing requirements of load testing tools.

[0082] The functional expression approach of this application is not simply to call the underlying components, but to find the underlying components that match the hardware device through hardware attribute parameters, and then use them to form a load testing tool to test the hardware device.

[0083] The basic function expressions include functions such as getting hardware properties, checking hardware properties, keyword checking, refreshing hardware properties, comparing hardware properties, and getting all properties.

[0084] 1. Obtain hardware properties:

[0085] Expression name: `get_hardware_property`;

[0086] Parameter: `property_name` (string) - Hardware property name;

[0087] Return value: Property value (string or number);

[0088] Note: This expression is used to retrieve the value of a specified hardware attribute.

[0089] 2. Check hardware properties:

[0090] Expression name: `check_hardware_property`;

[0091] Parameters: `property_name` (string), `expected_value` (string or number);

[0092] Return value: Boolean (True / False);

[0093] Note: This expression is used to check whether the hardware properties match the expected values.

[0094] 3. Keyword check:

[0095] Expression name: `keyword_check`;

[0096] Parameters: `property_name` (string), `keyword` (string);

[0097] Return value: Boolean (True / False);

[0098] Note: This expression is used to check whether a hardware attribute value contains a specific keyword.

[0099] 4. Refresh hardware properties:

[0100] Expression name: `refresh_hardware_property`;

[0101] Parameter: `property_name` (string);

[0102] Return value: None;

[0103] Note: This expression is used to refresh the specified hardware properties.

[0104] 5. Configure hardware properties:

[0105] Expression name: `set_hardware_property`;

[0106] Parameters: `property_name` (string), `value` (string or number);

[0107] Return value: None;

[0108] Note: This expression is used to set the value of the specified hardware attribute.

[0109] 6. Compare hardware attributes:

[0110] Expression name: `compare_hardware_properties`;

[0111] Parameters: `property_name1` (string), `property_name2` (string);

[0112] Return value: Boolean (True / False);

[0113] Note: This expression is used to compare whether two hardware attribute values ​​are the same.

[0114] 7. Check the attribute range:

[0115] Expression name: `check_property_range`;

[0116] Parameters: `property_name` (string), `min_value` (numeric value), `max_value` (numeric value);

[0117] Return value: Boolean (True / False);

[0118] Note: This expression is used to check whether the hardware attribute value is within the specified range.

[0119] 8. Get all attributes

[0120] Expression name: `get_all_properties`;

[0121] Parameters: None;

[0122] Return value: dictionary(property name: property value);

[0123] Note: This expression is used to retrieve all hardware properties and their corresponding values.

[0124] A customized overall architecture based on function expressions, such as Figure 3 As shown. These configuration expressions can be easily called in diagnostic software to perform various hardware attribute operations, improving the efficiency of diagnostic development and maintenance. The platform provides the above basic expressions; for customized needs, only these expressions need to be maintained, achieving the goal of zero code. When the diagnostic version is updated, only the expression maintenance needs to be updated to meet the functional requirements.

[0125] like Figure 4 As shown, in this embodiment, obtaining the target hardware attributes in the corresponding target performance test case based on the content of the target function expression includes:

[0126] The underlying component requests hardware data based on the content of the target function expression. The underlying component reads the hardware data information of the hardware devices it supports, formats the hardware data information, and returns the formatted hardware data information as the target hardware attribute.

[0127] In this embodiment, the process of obtaining the attributes of the hardware device, comparing the attributes of the hardware device with the attributes of the target hardware, and determining the underlying components that match the attributes of the hardware device includes:

[0128] When comparing the attributes of a hardware device with those of a target hardware device, the similarity between the attributes of the hardware device and the attributes of the target hardware is obtained.

[0129] If the similarity is 100%, then the underlying component corresponding to the target hardware attribute will be used as the target underlying component.

[0130] If the similarity is not 100%, the underlying component list is returned in descending order of similarity, and the similarity value is noted in the underlying component list. A reminder is issued to update the underlying component information, and the underlying component with the highest similarity value is adjusted to match the attributes of the hardware device. The adjusted underlying component is then used as the target underlying component.

[0131] Among them, the target underlying component can be accurately selected based on similarity. If they are inconsistent, a list of underlying components arranged in descending order of similarity can be provided, so that new underlying components can be formed by modifying the most similar underlying components.

[0132] In this embodiment, when determining the underlying component that matches the attributes of the hardware device, the method further includes:

[0133] Identify whether the language type of the program code of the underlying components that match the attributes of the hardware device is consistent;

[0134] In response to consistency, the underlying component that matches the attributes of the hardware device will be used as the target underlying component;

[0135] In response to inconsistencies, the underlying components with inconsistent language types in the program code are converted to the target underlying component after language type conversion.

[0136] By maintaining consistency in the programming languages ​​of the underlying components contained in the load testing tool, the smooth operation of the load testing tool can be guaranteed. Moreover, the load testing tool is a diagnostic software filled with the programming languages ​​corresponding to the underlying components, which can realize the load performance test of hardware devices.

[0137] In this embodiment, the diagnostic component management method further includes:

[0138] Obtain the applicable hardware devices for each underlying component, and classify and manage the underlying components according to the functions of the applicable hardware devices. The functions of the hardware devices are classified into computing products, storage products, artificial intelligence products, and other products.

[0139] Product component classification management: By classifying the current product form, we can reuse existing technologies as much as possible while meeting the needs of subsequent product iterations, and classify the product ownership.

[0140] First, based on the level of customer engagement, products can be categorized as either non-customized or customized if the customer's engagement is high.

[0141] Secondly, based on the product's function, it can be divided into computing, storage, and AI products. This dimensional division helps to distinguish the product's focus, allowing for more targeted product component categorization.

[0142] Furthermore, products can be categorized based on their CPU instruction set, such as x86 or non-x86, and further classified into multiple brand types. Since the CPU is the most critical component, its differences will affect the functional division of other components.

[0143] like Figure 2 As shown, in this embodiment, the diagnostic component management method further includes:

[0144] Step S5: Set the version number of the underlying component, and modify its version number in response to the upgrade of the underlying component.

[0145] Specifically, the target underlying component code stored in the load testing tool is checked for updates according to a preset cycle, and if so, the target underlying component is upgraded through a modular interface.

[0146] When the code of the target underlying component of the load testing tool is updated, the load testing tool is automatically upgraded, realizing an automated processing method. This enables unified management of underlying component versions, and the maintenance and management of underlying components do not require manual intervention, thus improving the management standardization of underlying components.

[0147] In this embodiment, setting a version number for the underlying component and modifying its version number in response to an upgrade of the underlying component includes:

[0148] The version number of the same type of underlying components includes the major version number and the revision number. The length of the version number of the same type of underlying components is fixed, and the structure of the version number of the same type of underlying components is [major version number].[revision number];

[0149] Get the version number of each underlying component in the same category, sort the version numbers of the underlying components in the same category in order and set them as the revision number. The revision number is automatically updated according to the latest version number of each test item.

[0150] Define the major version number based on the version number of the test item in the revision version number, and set the major version number to be updated when there are compatibility changes to the test items contained in the underlying components.

[0151] The automatic update method for the underlying components is as follows:

[0152] By using an automatic component version update mechanism, the modification of the component version during the upgrade process is reduced, and the correct use of the component version is ensured while automatically upgrading the version.

[0153] First, define version numbers for the same major component category. Define version numbers according to the product classification. Version numbers are defined in a multi-level manner and have a fixed length.

[0154] Secondly, in the version definition of the major category, only the major version number is defined, and the major category is only updated when the major version is updated.

[0155] Secondly, the diagnostic control program, when obtaining the components required by the current product, only finds the latest version under the major version number based on the matching relationship. This achieves the goal of automatically updating when diagnostic components are updated, eliminating the need for manual modification of configuration files one by one.

[0156] These definitions ensure that during automatic updates and version matching, the system can select the correct latest minor version to update based on the major version number, while simplifying version number comparison and management.

[0157] The version numbering rules for the underlying components are as follows:

[0158] Version number grading definition: For the same type of underlying components, a multi-level version number structure V = (v1, v2,..., v , selected )(v k ∈ N + ) is adopted; where v k represents the version number of the k-th underlying component in the same type of underlying components, n is the number of version numbers of the underlying components in the same type of underlying components, and V represents the set of version numbers of the underlying components included in the same type of underlying components.

[0159] Among them, the first m levels (m < n) are defined as major version numbers, which are updated only when the component architecture changes.

[0160] Major version number stability principle:

[0161] V major = (v1,..., v m );

[0162] V major is the major version number, that is, the major version number is determined by the first m levels of the version numbers of the n underlying components in the version number set V.

[0163] The major version number is not updated when the component compatibility remains unchanged, avoiding frequent configuration changes.

[0164] Intelligent version matching: When the main control program matches components according to product requirements:

[0165] Extract the required major version number ; R represents component compatibility, and the major version number V R represents the value when the compatibility of all underlying components in the same type of underlying components is R.

[0166] In the component library Filter the matching set:

[0167] ;

[0168] C i represents the i-th underlying component in the component library C, V i represents the version number corresponding to the i-th underlying component, represents the first m levels of the version number of the underlying component C i as the major version number.

[0169] Automatically select the latest revision: ; represents the revised part of the underlying component C i , that is, the version numbers from the m + 1-th level to the n-th level. C selectedThe formula means: From the matching set M, select the underlying component with the largest version number after the nm level of the revision number, and take the largest revision number in lexicographical order.

[0170] The version number structure for the underlying components is set as: [Major Version Number].[Revision Number], where the major version number remains fixed and is only updated when component compatibility changes. The revision number is automatically updated based on the latest version number of each test item.

[0171] The software's basic functions are platformized, while customized functions are updated via expressive methods. This reduces the frequency of version updates; customized functions only require modifications to maintenance information, enabling rapid customization. This method categorizes diagnostic components based on product categories, maximizing the replication of diagnostic components across different products. By defining component version numbers, the major version number of the diagnostic component for each product category is separated from the actual version number of the diagnostic component, achieving automatic version matching and rapid import of diagnostic components, significantly reducing workload during version upgrades.

[0172] like Figure 2 As shown, in this embodiment, the diagnostic component management method further includes:

[0173] Step S6: In response to the upgrade of the underlying components, perform functional verification on the upgraded underlying components, and release the upgraded underlying components after the functional verification is passed.

[0174] To ensure consistency of diagnostic components across different factories, a version release center server manages these components. The release center server periodically checks the MD5 values ​​of components from different factories to ensure they match those on the central server. If a discrepancy is found, an alert is triggered for version control personnel. Upon receiving the alert, relevant personnel investigate the cause of the discrepancy and update the version to the corresponding factory. This unified component management strategy ensures version consistency across factories worldwide, enabling rapid and consistent component import into factories globally.

[0175] To address the issues with existing manual component releases, an automated component release strategy is implemented on the version control server. First, after receiving a component verified by the front-end, it is initially released in a canary release phase to one production factory. Based on the factory's corresponding products, coverage is automatically matched and the component is imported into that product. Once basic functionality is verified and confirmed to be working correctly, it is quickly imported into all products within that factory. Second, based on time-based verification settings, if no issues arise from batch version imports within a certain period (typically days) in the canary release factory, it is then automatically released to all other factories. Finally, this automated canary release mechanism, ensuring quality and efficiency in the import of product diagnostic software, guarantees the quality of the diagnostic software release. This canary release process for diagnostic software ensures both quality and efficiency, meeting the dual requirements of production for both.

[0176] This solution maximizes the reuse of diagnostic components and enables customized requirement expression processing, facilitating the rapid development and import of diagnostic components for new products. During version import, automatic publishing and updates reduce manual intervention during the release process, ensuring rapid and high-quality import to factories across different locations and guaranteeing version consistency. Versions are uniformly published through the component center server, achieving version consistency across factories and facilitating version management in all locations.

[0177] In the aforementioned diagnostic component management method, the programming language in the diagnostic software is divided into multiple test items, and the programming language corresponding to the test items is encapsulated as a low-level component, enabling the low-level component to be used independently. The low-level component in the load testing tool is obtained by identifying the low-level component that matches the hardware device through functional expressions, which improves the speed of building the load testing tool. The low-level component is decoupled from the performance test cases and the load testing tool, so that the low-level component version is managed uniformly. The maintenance and management of the low-level component do not require manual intervention, which improves the management standardization of the low-level component.

[0178] The aforementioned diagnostic component management method optimizes the entire process of diagnostic component development, updating, release, and import, enabling high reusability of diagnostic components across different products and facilitating rapid development. It achieves this through platformization of basic software functions and expression-based updates for customized functions. Furthermore, the separate definition of component version numbers enables automatic version matching, significantly simplifying the version upgrade process. Centralized management of the unified release and canary release mechanism for diagnostic components ensures the quality of the product diagnostic software while improving release efficiency, meeting the dual demands of production for both quality and efficiency.

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

[0180] In one embodiment, such as Figure 5 As shown, a diagnostic component management device 10 is provided, including: a bottom-level component construction module 1, a function expression setting module 2, a load testing tool setting module 3, a bottom-level component management module 4, a category management module 5, a version number management module 6, and a release module 7.

[0181] The underlying component module 1 is used to divide the program code in the diagnostic software into multiple test items according to the diagnostic function, and encapsulate the program code corresponding to the test items into underlying components, wherein the test items are associated with performance test cases.

[0182] The function expression setting module 2 is used to classify the underlying components and set function expressions for the underlying components of the same category, wherein the function expression is associated with at least one test item.

[0183] The load testing tool setting module 3 is used to obtain the hardware device to be subjected to load performance testing, set the load testing tool for the corresponding hardware device, and the load testing tool contains at least one target test item corresponding to the load performance test content. It also obtains the target function expression and target performance test case corresponding to the target test item.

[0184] The underlying component management module 4 is used to run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the load testing tool and associate it with the target test item.

[0185] In this embodiment, the program code in the diagnostic software is divided into multiple test item code according to the diagnostic function, and the program code corresponding to the test item is encapsulated into a low-level component. The test item is associated with the performance test case, including:

[0186] The diagnostic software is platformized into a platform layer, a basic software layer, and a functional layer.

[0187] Identify the language type of the program code in the diagnostic software and store the language type of the program code within the platform layer;

[0188] The programming language in the diagnostic software is divided into multiple test items according to the diagnostic function, and the programming language corresponding to the test items is stored in the basic software layer.

[0189] Obtain the performance test cases associated with the test items, set up a basic library in the basic software layer to store the performance test cases, and store the associated linked list of performance test cases and test items;

[0190] The programming language corresponding to the test item is encapsulated as a low-level component, and a modular interface is set for the low-level component. The modular interface is then stored in the basic software layer.

[0191] The underlying components are categorized by function, and the underlying components are stored in the functional layer.

[0192] In this embodiment, the programming language corresponding to the test item is encapsulated as a low-level component, and a modular interface is set for the low-level component. The modular interface is stored in the basic software layer, including:

[0193] Set up an operating system abstraction layer, encapsulate the modular interface of the test items using the operating system abstraction layer, encapsulate the programming language corresponding to the test items as the underlying component, and store the modular interface in the basic software layer, and interact and communicate with the underlying component through the modular interface.

[0194] In this embodiment, when using the operating system abstraction layer to encapsulate the modular interface of the test items, it further includes:

[0195] Determine whether the test item interacts with the hardware device;

[0196] In response to the interaction between the test item and the hardware device, a standardized hardware interface is set for the test item. The standardized hardware interface interacts with the hardware device through a unified data format and transmission protocol.

[0197] In this embodiment, running the target function expression and obtaining the underlying component that matches the hardware device as the target underlying component through the function expression includes:

[0198] Obtain the target function expression of the load testing tool. The target function expression includes obtaining hardware properties, checking hardware properties, keyword checking, refreshing hardware properties, comparing hardware properties, and obtaining all properties.

[0199] Run the target function expression and obtain the target hardware attributes in the corresponding target performance test case based on the content of the target function expression;

[0200] Obtain the attributes of the hardware device, compare the attributes of the hardware device with the attributes of the target hardware, and determine the underlying components that match the attributes of the hardware device.

[0201] The identified underlying components that match the attributes of the hardware device are used as the target underlying components.

[0202] In this embodiment, obtaining the target hardware attributes in the corresponding target performance test case based on the content of the target function expression includes:

[0203] The underlying component requests hardware data based on the content of the target function expression. The underlying component reads the hardware data information of the hardware devices it supports, formats the hardware data information, and returns the formatted hardware data information as the target hardware attribute.

[0204] In this embodiment, the process of obtaining the attributes of the hardware device, comparing the attributes of the hardware device with the attributes of the target hardware, and determining the underlying components that match the attributes of the hardware device includes:

[0205] When comparing the attributes of a hardware device with those of a target hardware device, the similarity between the attributes of the hardware device and the attributes of the target hardware is obtained.

[0206] If the similarity is 100%, then the underlying component corresponding to the target hardware attribute will be used as the target underlying component.

[0207] If the similarity is not 100%, the underlying component list is returned in descending order of similarity, and the similarity value is noted in the underlying component list. A reminder is issued to update the underlying component information, and the underlying component with the highest similarity value is adjusted to match the attributes of the hardware device. The adjusted underlying component is then used as the target underlying component.

[0208] In this embodiment, when determining the underlying component that matches the attributes of the hardware device, the method further includes:

[0209] The system identifies whether the language type of the program code of the underlying component that matches the attributes of the hardware device is consistent. If they are consistent, the underlying component that matches the attributes of the hardware device is used as the target underlying component. Otherwise, the underlying component whose program code language type is inconsistent is converted to a different language type and then used as the target underlying component.

[0210] In this embodiment, the classification management module 5 is used for:

[0211] Obtain the applicable hardware devices for each underlying component, and classify and manage the underlying components according to the functions of the applicable hardware devices. The functions of the hardware devices are classified into computing products, storage products, artificial intelligence products, and other products.

[0212] In this embodiment, the version number management module 6 is used for:

[0213] Set a version number for the underlying component, and modify the version number in response to upgrades of the underlying component.

[0214] In this embodiment, setting a version number for the underlying component and modifying its version number in response to an upgrade of the underlying component includes:

[0215] The version number of the same type of underlying components includes the major version number and the revision number. The length of the version number of the same type of underlying components is fixed, and the structure of the version number of the same type of underlying components is [major version number].[revision number];

[0216] Get the version number of each underlying component in the same category, sort the version numbers of the underlying components in the same category in order and set them as the revision number. The revision number is automatically updated according to the latest version number of each test item.

[0217] Define the major version number based on the version number of the test item in the revision version number, and set the major version number to be updated when there are compatibility changes to the test items contained in the underlying components.

[0218] In this embodiment, the publishing module 7 is used for:

[0219] In response to the upgrade of the underlying components, the upgraded underlying components are functionally verified, and the upgraded underlying components are released after the functional verification is passed.

[0220] In the aforementioned diagnostic component management device, the programming language in the diagnostic software is divided into multiple test items, and the programming language corresponding to the test items is encapsulated as a low-level component, enabling the low-level component to be used independently. The low-level component in the load testing tool is obtained by identifying the low-level component that matches the hardware device through functional expressions, which improves the speed of building the load testing tool. The low-level component is decoupled from the performance test cases and the load testing tool, so that the low-level component version is managed uniformly. The maintenance and management of the low-level component do not require manual intervention, which improves the management standardization of the low-level component.

[0221] For a description of the features in the embodiment corresponding to the diagnostic component control device, please refer to the relevant description in the embodiment corresponding to the diagnostic component control method, which will not be repeated here.

[0222] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the diagnostic component control method.

[0223] In one embodiment, the electronic device may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores diagnostic component management data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a diagnostic component management method.

[0224] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the diagnostic component control method when running:

[0225] The diagnostic software divides the program code into multiple test items according to the diagnostic functions, and encapsulates the program code corresponding to the test items into underlying components, where the test items are associated with performance test cases.

[0226] Classify the underlying components and set function expressions for the underlying components of the same category, wherein the function expression is associated with at least one test item;

[0227] Obtain the hardware device to be subjected to load performance testing, set up the load testing tool for the corresponding hardware device, the load testing tool contains at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item.

[0228] Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the load testing tool and associate it with the target test item.

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

[0230] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described embodiments of the diagnostic component control method:

[0231] The diagnostic software divides the program code into multiple test items according to the diagnostic functions, and encapsulates the program code corresponding to the test items into underlying components, where the test items are associated with performance test cases.

[0232] Classify the underlying components and set function expressions for the underlying components of the same category, wherein the function expression is associated with at least one test item;

[0233] Obtain the hardware device to be subjected to load performance testing, set up the load testing tool for the corresponding hardware device, the load testing tool contains at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item.

[0234] Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the load testing tool and associate it with the target test item.

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

[0236] The diagnostic software divides the program code into multiple test items according to the diagnostic functions, and encapsulates the program code corresponding to the test items into underlying components, where the test items are associated with performance test cases.

[0237] Classify the underlying components and set function expressions for the underlying components of the same category, wherein the function expression is associated with at least one test item;

[0238] Obtain the hardware device to be subjected to load performance testing, set up the load testing tool for the corresponding hardware device, the load testing tool contains at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item.

[0239] Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the load testing tool and associate it with the target test item.

[0240] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

Claims

1. A method for controlling diagnostic components, characterized in that, include: The diagnostic software program code is divided into multiple test item program codes according to the diagnostic functions, and the program code corresponding to the test item is encapsulated into a low-level component, wherein the test item is associated with a performance test case; The underlying components are classified, and function expressions are set for the underlying components of the same class, wherein the function expressions are associated with at least one of the test items; Obtain the hardware device to be subjected to load performance testing, set up a load testing tool for the hardware device, the load testing tool includes at least one target test item corresponding to the load performance test content, and obtain the target function expression and target performance test case corresponding to the target test item. Run the target function expression, obtain the underlying component that matches the hardware device through the function expression as the target underlying component, store the target underlying component in the load testing tool and associate it with the target test item; Specifically, the program code in the diagnostic software is divided into multiple test items according to the diagnostic function, and the program code corresponding to each test item is encapsulated into a low-level component. The association between each test item and a performance test case includes: The diagnostic software is platformized into a platform layer, a basic software layer, and a functional layer. Identify the language type of the program code in the diagnostic software and store the language type of the program code within the platform layer; The programming language in the diagnostic software is divided into multiple test items according to the diagnostic function, and the programming language corresponding to the test items is stored in the basic software layer. The programming language corresponding to the test item is encapsulated as a low-level component, and a modular interface is set for the low-level component, and the modular interface is stored in the basic software layer. The underlying components are categorized according to their functions, and the underlying components are stored in the functional layer according to their categories. The step of running the target function expression and obtaining the underlying component matching the hardware device as the target underlying component through the function expression includes: Obtain the target function expression of the load testing tool, which includes obtaining hardware attributes, checking hardware attributes, keyword checking, refreshing hardware attributes, comparing hardware attributes, and obtaining all attributes. Run the target function expression, and obtain the target hardware attributes in the corresponding target performance test case based on the content of the target function expression; Obtain the attributes of the hardware device, compare the attributes of the hardware device with the attributes of the target hardware, and determine the underlying component that matches the attributes of the hardware device; The underlying component that matches the attributes of the hardware device is selected as the target underlying component.

2. The diagnostic component control method according to claim 1, characterized in that, The method of dividing the program code in the diagnostic software into multiple test items according to the diagnostic function, and encapsulating the program code corresponding to the test items into low-level components, wherein the test items are associated with performance test cases, further includes: Obtain the performance test case associated with the test item, set up a basic library in the basic software layer to store the performance test case, and store the association list between the performance test case and the test item.

3. The diagnostic component control method according to claim 2, characterized in that, The step of encapsulating the programming language corresponding to the test item into a low-level component, setting a modular interface for the low-level component, and storing the modular interface in the basic software layer includes: An operating system abstraction layer is set up, and the modular interface of the test item is encapsulated by the operating system abstraction layer. The programming language corresponding to the test item is encapsulated as a low-level component, and the modular interface is stored in the basic software layer. Interaction and communication with the low-level component are carried out through the modular interface.

4. The diagnostic component control method according to claim 3, characterized in that, When encapsulating the modular interface of the test item using the operating system abstraction layer, the following is also included: Determine whether the test item interacts with the hardware device; In response to the interaction between the test item and the hardware device, a standardized hardware interface is set for the test item. The standardized hardware interface interacts with the hardware device through a unified data format and transmission protocol.

5. The diagnostic component control method according to claim 1, characterized in that, The step of obtaining the target hardware attributes in the corresponding target performance test case based on the content of the target function expression includes: The underlying component requests hardware data based on the content of the target function expression. The underlying component reads the hardware data information of the hardware devices it supports running. The underlying component formats the hardware data information and returns the formatted hardware data information as the target hardware attribute.

6. The diagnostic component control method according to claim 1, characterized in that, The step of obtaining the attributes of the hardware device, comparing the attributes of the hardware device with the attributes of the target hardware, and determining the underlying components that match the attributes of the hardware device includes: When comparing the attributes of the hardware device with the attributes of the target hardware, the similarity between the attributes of the hardware device and the attributes of the target hardware is obtained; In response to the similarity being 100%, the underlying component corresponding to the target hardware attribute is taken as the target underlying component; If the similarity is not 100%, the underlying component list is returned in descending order of similarity, and the similarity value is noted in the underlying component list. A reminder is issued to update the underlying component information, and the underlying component with the highest similarity value is adjusted to match the attributes of the hardware device. The adjusted underlying component is then used as the target underlying component.

7. The diagnostic component control method according to claim 1, characterized in that, When determining the underlying components that match the attributes of the hardware device, the following are also included: Identify whether the language type of the program code of the underlying components that match the attributes of the hardware device is consistent; In response to consistency, the underlying component that matches the attributes of the hardware device will be used as the target underlying component; In response to inconsistencies, the underlying components with inconsistent language types in the program code are converted to the target underlying component after language type conversion.

8. The diagnostic component control method according to claim 1, characterized in that, The method further includes: Obtain the hardware devices applicable to each underlying component, and classify and manage the underlying components according to the functions of the applicable hardware devices, wherein the functions of the hardware devices are classified as computing products, storage products, artificial intelligence products and other products.

9. The diagnostic component control method according to claim 1, characterized in that, The method further includes: A version number is set for the underlying component, and its version number is modified in response to the upgrade of the underlying component.

10. The diagnostic component control method according to claim 9, characterized in that, Setting a version number for the underlying component, and modifying its version number in response to an upgrade of the underlying component, includes: The version number of the same type of underlying components is set to include a major version number and a revision number. The length of the version number of the same type of underlying components is fixed. The structure of the version number of the same type of underlying components is [major version number].[revision number]; Obtain the version number of each underlying component in the same class of underlying components, sort the version numbers of the underlying components in the same class in sequence and set them as the revision version number, and automatically update the revision version number according to the latest version number of each test item; The major version number is defined based on the version number of the test item in the revised version number, and the major version number is set to be updated when there are compatibility changes in the test items included in the underlying component.

11. The diagnostic component control method according to claim 1, characterized in that, The method further includes: In response to the upgrade of the underlying component, the upgraded underlying component is functionally verified, and the upgraded underlying component is released after the functional verification is passed.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the diagnostic component control method as described in any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the diagnostic component control method as described in any one of claims 1 to 11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the diagnostic component control method as described in any one of claims 1 to 11.

Images