Equipment scheduling method and device based on hardware-in-loop test, electronic equipment and storage medium
By acquiring equipment parameters and historical data, and rationally configuring test cases and cabinets, the problem of low efficiency in hardware-in-the-loop testing was solved, and the optimization of equipment status and efficient utilization of resources were achieved.
Patent Information
- Application Number
- CN202511572128.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-30
- Publication Date
- 2026-02-24
AI Technical Summary
Existing hardware-in-the-loop testing technology fails to be properly configured according to the rack status, resulting in low testing efficiency and insufficient resource utilization.
By acquiring the current equipment parameters and historical test data of the test equipment, and using the estimated planning information to determine the target test cases, we can ensure that the estimated time meets the preset average time and maximizes the estimated value, and rationally configure test cases and racks.
It improves testing efficiency by comprehensively considering equipment status, optimizing the execution time and value of test cases, and increasing resource utilization.
Smart Images

Figure CN121560735A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of testing technology, and more specifically, to a device scheduling method, apparatus, electronic device, and storage medium based on hardware-in-the-loop testing. Background Technology
[0002] With the continuous development of vehicle testing technology, Hardware-in-the-Loop (HIL) testing technology is increasingly being used in vehicle testing. For a specific component or function of a vehicle, all test cases are sent to a rack for testing. Currently, all test cases for a single task can be sent to a single rack; all test cases for a single task can be split into multiple tasks and sent to multiple racks; or all test cases for a single task can be sent to multiple racks one by one. However, these testing methods do not consider the actual state of the racks, have low testing efficiency, and fail to allocate resources reasonably according to different rack states. Therefore, how to reasonably configure test cases and racks and improve testing efficiency is a problem that needs to be solved. Summary of the Invention
[0003] The purpose of some embodiments of this application is to provide a device scheduling method, apparatus, electronic device, and storage medium based on hardware-in-the-loop testing. Through the technical solutions of the embodiments of this application, device parameters of the current test device are obtained. These device parameters include at least a device identifier, device status, and device information. The device status includes online or offline status, and the device information includes hardware information and hardware utilization. Based on predetermined estimated planning information, target test cases corresponding to the device parameters are determined. The predetermined estimated planning information includes the test device and the corresponding test cases. The estimated planning information is based on historical test data to determine the estimated time of the test cases on each test device. The corresponding estimated value is used to ensure that the estimated time meets the preset average time and the estimated value is greater than the preset value. The target test case is sent to the current test device. In this embodiment of the application, the estimated time and estimated value are determined by analyzing historical test data to determine the estimated planning information, that is, to determine the optimal test case to be executed by each test device. Then, during actual testing, the device parameters of the current test device need to be obtained, and combined with the obtained estimated planning information, the target test case corresponding to the current test device is determined, so that the execution time of the target test case tends to the preset average time and the estimated value is maximized. This not only comprehensively considers the status of the test device but also makes reasonable configuration of the test device and test cases, thereby improving testing efficiency.
[0004] In a first aspect, some embodiments of this application provide a device scheduling method based on hardware-in-the-loop testing, including: Obtain the device parameters of the current test device, wherein the device parameters include at least device identifier, device status and device information, wherein the device status includes online or offline, and the device information includes hardware information and hardware utilization; Based on the predetermined estimated planning information, target test cases corresponding to the equipment parameters are determined. The predetermined estimated planning information includes test equipment and test cases corresponding to the test equipment. The estimated planning information is based on historical test data to determine the estimated time and corresponding estimated value of the test cases on each test equipment, so that the estimated time meets the preset average time and the estimated value is greater than the preset value. Send the target test case to the current test device.
[0005] Some embodiments of this application determine the estimated time and value of historical test data to establish estimated planning information, that is, to determine the optimal test cases to be executed for each test device. Then, during actual testing, it is necessary to obtain the device parameters of the current test device and combine them with the obtained estimated planning information to determine the target test cases corresponding to the current test device. This makes the execution time of the target test cases approach the preset average time and maximizes the estimated value. This not only comprehensively considers the status of the test device but also makes reasonable configuration of the test device and test cases, thereby improving testing efficiency.
[0006] Optionally, the estimated planning information is obtained in the following manner: Retrieve historical test cases for historical test tasks; The test cases are executed using each test device to obtain test results corresponding to the test device. The test results include at least the execution result, test time, device preset resource information, and hardware execution environment. The historical test cases and corresponding test results are determined as the historical test data; Using a preset value assessment algorithm and the test results, the estimated value of each test case on different test devices is determined, and the estimated time corresponding to the test case is determined based on the test time. The preset value assessment algorithm is calculated by applying different weights to preset resource information of the device, test results, test time, and test environment. Based on the correspondence between the estimated value and the estimated time, the estimated value information for each test case tested on different test devices is determined. Using a preset planning algorithm and the estimated value information, the estimated planning information for test cases and test equipment is determined, wherein the preset planning algorithm includes at least a dynamic programming algorithm or a greedy algorithm.
[0007] Some embodiments of this application obtain historical test data, determine the estimated time and value of the historical test data, and determine the estimated planning information, that is, determine the optimal test cases to be executed by each test device, thereby improving the efficiency of test case testing.
[0008] Optionally, the step of using a preset value assessment algorithm and the test results to determine the estimated value of each test case on different test devices includes: Based on the device's preset resource information, test time, and each parameter in the test environment, the weight of the same test case is set on different test devices. The estimated value of the test case on the same test device is determined based on multiple weights on the same test device.
[0009] Some embodiments of this application determine the weight of each parameter for a test device based on the device's preset resource information, test time, and various parameters of the test environment in the test case test. Then, the multiple weights of the test device are multiplied together to obtain the estimated value of the test case on the test device. By comprehensively considering multiple factors, the efficiency of test case execution is improved.
[0010] Optionally, determining the estimated time corresponding to the test case based on the test time includes: Based on the testing time of the same test case on different testing devices, determine the average execution time or the maximum execution time respectively; The average execution time or maximum execution time is determined as the estimated time for the test case on each test device.
[0011] In some embodiments of this application, based on the test time of the same test case on different test devices, the maximum execution time or the average execution time can be selected as the estimated time for the test case on the test device. Optionally, the method further includes: Based on the estimated planning information, for the same test equipment, the estimated values of different test cases are sorted from largest to smallest to obtain a sorting result, so that the test equipment can perform tests according to the sorting result.
[0012] Some embodiments of this application prioritize the estimated planning information for each test device based on the estimated value of the test cases, ensuring that high-value test cases are executed first and avoiding a decrease in the overall estimated value due to subsequent test device shutdowns or other unavailable environments.
[0013] Optionally, the method further includes: If the target test case fails to be tested by the current testing device, the target test case will be identified as blacklist information of the current testing device.
[0014] In some embodiments of this application, when a test case fails to be deployed, the temporary blacklist information of the test case on the test device is recorded to restrict the deployment of the test case to that environment. The estimated value information is recalculated and the estimated planning information is replanned. During the recalculation and planning process, the test case-rack information in the blacklist is restricted based on the temporary blacklist to prevent the test case from being deployed to test devices that cannot be deployed.
[0015] Optionally, the method further includes: If the test cases to be tested on the current test device are not obtained from historical test data, then a pre-set estimated value is obtained, and the current test device is tested according to the pre-set estimated value.
[0016] Secondly, some embodiments of this application provide a device scheduling apparatus based on hardware-in-the-loop testing, including: The acquisition module is used to acquire the device parameters of the current test device. The device parameters include at least device identifier, device status, and device information. The device status includes online or offline, and the device information includes hardware information and hardware utilization. The determination module is used to determine the target test cases corresponding to the equipment parameters based on the pre-determined estimated planning information. The pre-determined estimated planning information includes the test equipment and the test cases corresponding to the test equipment. The estimated planning information is based on historical test data to determine the estimated time and corresponding estimated value of the test cases on each test equipment, so that the estimated time meets the preset average time and the estimated value is greater than the preset value. The sending module is used to send the target test case to the current test device.
[0017] Some embodiments of this application determine the estimated time and value of historical test data to establish estimated planning information, that is, to determine the optimal test cases to be executed for each test device. Then, during actual testing, it is necessary to obtain the device parameters of the current test device and combine them with the obtained estimated planning information to determine the target test cases corresponding to the current test device. This makes the execution time of the target test cases approach the preset average time and maximizes the estimated value. This not only comprehensively considers the status of the test device but also makes reasonable configuration of the test device and test cases, thereby improving testing efficiency.
[0018] Optionally, the apparatus further includes a setup module, the setup module being used for: Retrieve historical test cases for historical test tasks; The test cases are executed using each test device to obtain test results corresponding to the test device. The test results include at least the execution result, test time, device preset resource information, and hardware execution environment. The historical test cases and corresponding test results are determined as the historical test data; Using a preset value assessment algorithm and the test results, the estimated value of each test case on different test devices is determined, and the estimated time corresponding to the test case is determined based on the test time. The preset value assessment algorithm is calculated by applying different weights to preset resource information of the device, test results, test time, and test environment. Based on the correspondence between the estimated value and the estimated time, the estimated value information for each test case tested on different test devices is determined. Using a preset planning algorithm and the estimated value information, the estimated planning information for test cases and test equipment is determined, wherein the preset planning algorithm includes at least a dynamic programming algorithm or a greedy algorithm.
[0019] Some embodiments of this application obtain historical test data, determine the estimated time and value of the historical test data, and determine the estimated planning information, that is, determine the optimal test cases to be executed by each test device, thereby improving the efficiency of test case testing.
[0020] Optionally, the establishment module is used for: Based on the device's preset resource information, test time, and each parameter in the test environment, the weight of the same test case is set on different test devices. The estimated value of the test case on the same test device is determined based on multiple weights on the same test device.
[0021] Some embodiments of this application determine the weight of each parameter for a test device based on the device's preset resource information, test time, and various parameters of the test environment in the test case test. Then, the multiple weights of the test device are multiplied together to obtain the estimated value of the test case on the test device. By comprehensively considering multiple factors, the efficiency of test case execution is improved.
[0022] Optionally, the establishment module is used for: Based on the testing time of the same test case on different testing devices, determine the average execution time or the maximum execution time respectively; The average execution time or maximum execution time is determined as the estimated time for the test case on each test device.
[0023] In some embodiments of this application, based on the test time of the same test case on different test devices, the maximum execution time or the average execution time can be selected as the estimated time for the test case on the test device. Optionally, the establishment module is used for: Based on the estimated planning information, for the same test equipment, the estimated values of different test cases are sorted from largest to smallest to obtain a sorting result, so that the test equipment can perform tests according to the sorting result.
[0024] Some embodiments of this application prioritize the estimated planning information for each test device based on the estimated value of the test cases, ensuring that high-value test cases are executed first and avoiding a decrease in the overall estimated value due to subsequent test device shutdowns or other unavailable environments.
[0025] Optionally, the establishment module is used for: If the target test case fails to be tested by the current testing device, the target test case will be identified as blacklist information of the current testing device.
[0026] In some embodiments of this application, when a test case fails to be deployed, the temporary blacklist information of the test case on the test device is recorded to restrict the deployment of the test case to that environment. The estimated value information is recalculated and the estimated planning information is replanned. During the recalculation and planning process, the test case-rack information in the blacklist is restricted based on the temporary blacklist to prevent the test case from being deployed to test devices that cannot be deployed.
[0027] Optionally, the establishment module is used for: If the test cases to be tested on the current test device are not obtained from historical test data, then a pre-set estimated value is obtained, and the current test device is tested according to the pre-set estimated value.
[0028] Thirdly, some embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it can implement the device scheduling method based on hardware-in-the-loop testing as described in any embodiment of the first aspect.
[0029] Fourthly, some embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the device scheduling method based on hardware-in-the-loop testing as described in any embodiment of the first aspect.
[0030] Fifthly, some embodiments of this application provide a computer program product, the computer program product including a computer program, wherein when the computer program is executed by a processor, it can implement the device scheduling method based on hardware-in-the-loop testing as described in any embodiment of the first aspect. Attached Figure Description
[0031] To more clearly illustrate the technical solutions of some embodiments of this application, the accompanying drawings used in some embodiments of this application will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0032] Figure 1 A flowchart illustrating a device scheduling method based on hardware-in-the-loop testing provided in this application embodiment; Figure 2 This is a schematic diagram of a test task being issued to a single rack, as provided in an embodiment of this application. Figure 3 A schematic diagram illustrating the average splitting of a test task into multiple sub-tasks and their distribution to multiple server racks, as provided in this embodiment of the application. Figure 4 This is a schematic diagram illustrating the distribution of test cases to multiple cabinets for each test case provided in the embodiments of this application; Figure 5 A schematic diagram of a device scheduling device based on hardware-in-the-loop testing is provided in an embodiment of this application; Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0033] The technical solutions of some embodiments of this application will now be described with reference to the accompanying drawings.
[0034] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0035] With the continuous development of vehicle testing technology, hardware-in-the-loop (HIL) testing technology is also being used more and more in vehicle testing. All test cases for a certain component or function of a vehicle are sent to the rack for testing. Currently, all test cases for a single execution task can be sent to a single rack for execution; all test cases for a single execution task can be split into multiple tasks and sent to multiple racks for execution; or all test cases for a single execution task can be sent to multiple racks one by one for execution.
[0036] like Figure 2 The diagram illustrates an execution scheme for distributing all test cases for a single task to a single rack. This scheme is straightforward and simple, representing the most common task execution method. It eliminates the need to consider the status of other HIL racks, focusing solely on the target rack where the test task needs to be distributed. After configuring the relevant test execution environment, the test task can be executed.
[0037] like Figure 3 The diagram illustrates an execution scheme that splits all test cases from a single task into multiple tasks and distributes them across multiple server racks. This scheme identifies currently available server racks and, based on the number of available racks, divides the test cases into multiple sub-tasks. These sub-tasks are then distributed to different server racks for execution. This scheme improves the utilization of idle HIL racks and helps reduce the overall execution time of test tasks.
[0038] like Figure 4 The diagram illustrates an execution scheme that distributes all test cases for a single task to multiple server racks one by one. This scheme requires real-time monitoring to automatically select unexecuted test cases from the task and distribute them when server rack equipment is available, continuing until all test cases for the test task have been executed. Compared to the scheme of evenly splitting the task, this approach makes more efficient use of idle server racks and offers greater flexibility in distributing test cases.
[0039] The execution scheme of distributing all test cases of a single task to a single rack is straightforward and simple, but it cannot make full use of the remaining idle available racks for parallel testing, resulting in extremely low resource utilization and the longest execution time for test tasks.
[0040] While splitting all test cases of a single task into multiple tasks and distributing them to multiple racks improves the utilization of idle and available equipment, this approach is too rigid. This method is highly likely to result in significant differences in execution time among the split tasks, leading to insufficient resource utilization.
[0041] The execution strategy of distributing all test cases for a single task to multiple racks, while making more efficient use of available racks, lacks further optimization strategies and simply implements a strategy of distributing test cases only when available. This strategy cannot perceive the execution efficiency of the same test case on different racks, nor can it leverage historical execution experience to optimize the test case distribution strategy, leaving room for improvement in test execution efficiency and pass rate.
[0042] Based on the above testing methods, the actual state of the server rack is not considered, resulting in low testing efficiency and failure to rationally allocate resources according to different rack states. Therefore, how to rationally configure test cases and server racks and improve testing efficiency is a key issue. In view of this, some embodiments of this application provide a device scheduling method based on hardware-in-the-loop testing. This method includes obtaining device parameters of the current test device, wherein the device parameters include at least device identifier, device status, and device information, wherein the device status includes online or offline, and the device information includes hardware information and hardware utilization; determining target test cases corresponding to the device parameters according to pre-determined estimated planning information, wherein the pre-determined estimated planning information includes the test device and the test cases corresponding to the test device, and the estimated planning information is based on historical test data. The data is used to determine the estimated time and corresponding estimated value of test cases on each test device, so that the estimated time meets the preset average time and the estimated value is greater than the preset value. Target test cases are sent to the current test device. In this embodiment, by determining the estimated time and estimated value of historical test data, the estimated planning information is determined, that is, the optimal test case to be executed on each test device is determined. Then, during actual testing, the device parameters of the current test device need to be obtained, and combined with the obtained estimated planning information, the target test case corresponding to the current test device is determined, so that the execution time of the target test case tends to the preset average time and the estimated value is maximized. This not only comprehensively considers the status of the test device but also makes reasonable configuration of the test device and test cases, improving testing efficiency.
[0043] like Figure 1 As shown, embodiments of this application provide a device scheduling method based on hardware-in-the-loop testing, the method comprising: S101. Obtain the device parameters of the current test device; The current test equipment is a HIL cabinet, which includes a host computer and a slave computer. The equipment parameters include at least the equipment identifier, equipment status and equipment information. The equipment status includes whether it is online or offline or whether the host computer and slave computer are successfully connected. The equipment information includes hardware information and hardware utilization. Specifically, the embodiments of this application are applied to a testing system, which includes a server and multiple HIL cabinets, each of which can execute the same or different test cases.
[0044] The server obtains the device parameters of each test device, namely the information of currently idle and available execution rack devices. It needs to obtain the information and status of all rack devices in real time. Using the device status and information (hardware device information, resource utilization) of the rack devices, it generates the planning results for the deployment of test cases to different environments. For example, the rack devices need to provide real-time feedback on their own relevant information, whether the rack device status is idle, whether the rack device environment supports test case deployment, the hardware utilization rate of the rack device, and whether other special rack device resources are ready, etc.
[0045] S102. Based on the predetermined estimated planning information, determine the target test cases corresponding to the equipment parameters. The predetermined estimated planning information includes the test equipment and the test cases corresponding to the test equipment. The estimated planning information is based on historical test data to determine the estimated time and corresponding estimated value of the test cases on each test equipment, so that the estimated time meets the preset average time and the estimated value is greater than the preset value. Specifically, the server pre-acquires historical test data and parses it to obtain the estimated time and estimated value of each test case on different test devices. Based on the correspondence between the estimated time and estimated value, the estimated value information is obtained. Then, a preset planning algorithm is used to plan the estimated value information to obtain the optimal executable test cases on each test device, so that the estimated time of each test case meets the preset average time and the estimated value is greater than the preset value.
[0046] Based on the pre-determined estimated planning information, the server determines the target test case corresponding to the equipment parameters of the current test equipment. That is, the estimated value of the target test case on the current test equipment is greater than the preset value, and the estimated time meets the preset average time.
[0047] S103. Send the target test case to the current test device.
[0048] The server sends the target test cases for each test device to the corresponding test device. The test device, i.e., the HIL rack, tests each target test case and obtains the test results. The number of target test cases can be one or more, and is not specifically limited in this embodiment. In this embodiment, the historical execution result records of test cases are used to calculate the estimated value and estimated time of the test cases being sent to different rack devices by calculating the estimated value and estimated time of the test cases being sent to different rack devices, so as to plan a strategy for sending target test cases to rack devices and meet different testing needs.
[0049] Some embodiments of this application determine the estimated time and value of historical test data to establish estimated planning information, that is, to determine the optimal test cases to be executed for each test device. Then, during actual testing, it is necessary to obtain the device parameters of the current test device and combine them with the obtained estimated planning information to determine the target test cases corresponding to the current test device. This makes the execution time of the target test cases approach the preset average time and maximizes the estimated value. This not only comprehensively considers the status of the test device but also makes reasonable configuration of the test device and test cases, thereby improving testing efficiency.
[0050] Another embodiment of this application further supplements the device scheduling method based on hardware-in-the-loop testing provided in the above embodiments.
[0051] Optionally, the estimated planning information can be obtained in the following ways: Retrieve historical test cases for historical test tasks; Test cases are executed on each test device to obtain test results corresponding to the test device. The test results include at least the execution results, test time, device preset resource information and hardware execution environment. Historical test cases and their corresponding test results are identified as historical test data. Using a pre-defined value assessment algorithm and test results, the estimated value of each test case on different test devices is determined, and the estimated time corresponding to the test case is determined based on the test time. The pre-defined value assessment algorithm is calculated by applying different weights to the device's pre-defined resource information, test results, test time, and test environment. Based on the correspondence between estimated value and estimated time, determine the estimated value information of each test case when tested on different test devices; Using a pre-defined planning algorithm and estimated value information, the estimated planning information for test cases and test equipment is determined. The pre-defined planning algorithm includes at least a dynamic programming algorithm or a greedy algorithm.
[0052] Specifically, the server acquires the historical execution experience of all test cases for each test task, i.e., historical test data. Using this historical test data, the optimal solution for deploying test cases to available devices in the current test equipment can be generated. After each test case is executed, the test equipment records execution information related to each test case, such as execution results, deployed rack equipment information, execution time, and special device resources. These special device resources are specific devices required for testing a particular function. For example, if it is necessary to test the vehicle chassis, but the height of the vehicle chassis does not meet the hardware requirements of the HIL testing equipment, special equipment resources are required, namely a support frame, to meet the testing requirements.
[0053] Based on the historical execution experience information of the test cases and the real-time environment information of the current rack equipment, the server calculates the estimated value of the test cases on a rack equipment by writing a custom algorithm for pre-deployment value. The historical execution experience information includes execution results, execution time, execution environment, etc., while the environmental resource information of the current test equipment, i.e., the rack equipment, includes rack equipment environment configuration, number of activated environments, hardware resource utilization, etc.
[0054] Based on the historical execution time information of test cases on rack devices, the server can use the average execution time, the maximum execution time, or other custom estimated execution time algorithms to obtain the estimated time for each test case on each rack device. Then, using a preset value evaluation algorithm and the test results, the server determines the estimated value of each test case on different test devices. The preset value evaluation algorithm is calculated by applying different weights to preset resource information of the device, test results, test time, and test environment.
[0055] By defining the estimated time and estimated value as the estimated value information for test cases and test equipment, we can obtain the test case-rack distribution estimated information table for all test cases to be issued in this execution task, as shown in Table 1:
[0056] Then, using a preset planning algorithm and the estimated value information, the estimated planning information for test cases and test equipment is determined, wherein the preset planning algorithm includes at least a dynamic programming algorithm or a greedy algorithm.
[0057] Furthermore, the server has obtained the estimated information of all test cases to be deployed in this execution task on the currently available rack devices. Based on dynamic programming, greedy algorithms, or other planning algorithms, the server plans the estimated deployment planning information of test cases and rack devices using the estimated deployment value of each test case on each rack device and historical execution time information. This is the estimated planning information, which ensures that the execution time of test cases on different rack devices tends to be averaged and the overall estimated deployment value of this execution task tends to be maximized.
[0058] The core difference between greedy algorithms and dynamic programming lies in their approaches: greedy algorithms always make decisions based on the current locally optimal choice, without guaranteeing a globally optimal solution; while dynamic programming, by decomposing subproblems, storing and reusing their solutions, ensures a globally optimal solution. This difference stems from their fundamentally different problem-solving strategies: greedy algorithms are more efficient but have limited applicability, while dynamic programming is more general but has higher computational costs. For each rack device, the estimated deployment use case queue information is sorted by estimated deployment value to ensure that high-value use cases are executed first, preventing a decrease in estimated value due to subsequent rack device shutdowns or other environmental unavailability.
[0059] The planning process yields use cases and rack estimates, resulting in a planning table with estimated planning information, as shown in Table 2.
[0060] Some embodiments of this application obtain historical test data, determine the estimated time and value of the historical test data, and determine the estimated planning information, that is, determine the optimal test cases to be executed by each test device, thereby improving the efficiency of test case testing.
[0061] Optionally, a pre-defined value assessment algorithm and test results are used to determine the estimated value of each test case on different test devices, including: Based on the device's preset resource information, test time, and each parameter in the test environment, set the weight of the same test case on different test devices; Based on multiple weights on the same test equipment, the estimated value of test cases on the test equipment is determined.
[0062] Specifically, the server sets the weight of the same test case on different test devices based on the device's preset resource information, test time, and each parameter in the test environment. Then, it calculates the product of multiple weights and uses the resulting product as the estimated value of the test case on the test device.
[0063] For example, for test case 1, the executable cabinets are cabinet A and cabinet B; Based on the device's preset resource information, i.e., the device's special resources, which are essential for test case A, rack A contains these special resources, while rack B does not. Therefore, the weight of the device's special resources in rack A is 1, and the weight in rack B is 0. Furthermore, based on the test time, rack A executes test case 1 for 5 seconds, and rack B executes it for 10 seconds. Thus, rack A's weight for test case 1 is 0.3, and rack B's weight for test case 2 is 0.8. Then, considering the test environment, i.e., the utilization rate of the hardware, rack A's weight is 0.4, and rack B's weight is 0.6. Based on these weights, the product of rack A's weights is 1 × 0.3 × 0.4 = 0.12, and the product of rack B's weights is 0 × 0.8 × 0.6 = 0. These 0.12 and 0 are taken as the estimated values of test case 1 in racks A and B, respectively.
[0064] Some embodiments of this application determine the weight of each parameter for a test device based on the device's preset resource information, test time, and various parameters of the test environment in the test case test. Then, the multiple weights of the test device are multiplied together to obtain the estimated value of the test case on the test device. By comprehensively considering multiple factors, the efficiency of test case execution is improved.
[0065] Optionally, based on the test time, determine the estimated time corresponding to the test cases, including: Based on the testing time of the same test case on different testing devices, determine the average execution time or the maximum execution time respectively; The average execution time or maximum execution time is determined as the estimated time for each test case on each test device.
[0066] In some embodiments of this application, based on the test time of the same test case on different test devices, the maximum execution time or the average execution time can be selected as the estimated time for the test case on the test device. Optionally, the method further includes: Based on the estimated planning information, for the same test equipment, the estimated values of different test cases are sorted from largest to smallest to obtain the sorting results, so that the test equipment can perform tests according to the sorting results.
[0067] Some embodiments of this application prioritize the estimated planning information for each test device based on the estimated value of the test cases, ensuring that high-value test cases are executed first and avoiding a decrease in the overall estimated value due to subsequent test device shutdowns or other unavailable environments.
[0068] Optionally, the method further includes: If the target test case fails to be tested on the current test equipment, the target test case will be added to the blacklist information of the current test equipment.
[0069] Specifically, the server obtains the distribution plan table of all test cases and available rack devices in this execution task. Based on the distribution plan table, i.e. the estimated planning information, the server actually distributes the target test cases to the corresponding estimated environment, i.e., to the corresponding available idle HIL racks.
[0070] When a test case fails to be deployed, the temporary blacklist information of the test case for that device is recorded to restrict the deployment of the test case to that environment. The test case-rack estimated deployment information table is recalculated and the test case-rack estimated deployment plan table is re-planned. For example, if the vehicle equipment model is updated, there may be cases where the test case execution fails.
[0071] During the recalculation and planning process, a temporary blacklist will be used to restrict the use case-rack information in the blacklist to prevent use cases from being sent to racks that cannot be downloaded.
[0072] In some embodiments of this application, when a test case fails to be deployed, the temporary blacklist information of the test case on the test device is recorded to restrict the deployment of the test case to that environment. The estimated value information is recalculated and the estimated planning information is replanned. During the recalculation and planning process, the test case-rack information in the blacklist is restricted based on the temporary blacklist to prevent the test case from being deployed to test devices that cannot be deployed.
[0073] Optionally, the method further includes: If the test cases to be tested on the current test device are not obtained from historical test data, then the pre-set estimated value is obtained, and the current test device is tested according to the pre-set estimated value.
[0074] Specifically, if some use cases of the current task lack historical execution experience information, or if execution experience information does not exist on currently available idle rack equipment, estimations can be made by specifying default estimated value and estimated time, or based on execution experience on other rack equipment.
[0075] During execution, this application embodiment needs to monitor in real time whether new available rack devices are coming online, or whether currently available rack devices become unavailable, or when the current task is completed by the issued use cases. At this time, it is necessary to recalculate and plan the use case-rack estimated distribution information table and the use case-rack estimated distribution planning table in order to obtain the current maximum value and average execution time in real time.
[0076] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.
[0077] Another embodiment of this application provides a device scheduling apparatus based on hardware-in-the-loop testing, used to execute the device scheduling method based on hardware-in-the-loop testing provided in the above embodiments.
[0078] like Figure 5 The diagram shown is a structural schematic of a device scheduling apparatus based on hardware-in-the-loop testing provided in an embodiment of this application. This device scheduling apparatus based on hardware-in-the-loop testing includes an acquisition module 501, a determination module 502, and a sending module 503, wherein: The acquisition module 501 is used to acquire the device parameters of the current test device. The device parameters include at least the device identifier, device status, and device information. The device status includes whether the device is online or offline, and the device information includes hardware information and hardware utilization. The determination module 502 is used to determine the target test cases corresponding to the equipment parameters based on the predetermined estimated planning information. The predetermined estimated planning information includes the test equipment and the test cases corresponding to the test equipment. The estimated planning information is based on historical test data to determine the estimated time and corresponding estimated value of the test cases on each test equipment, so that the estimated time meets the preset average time and the estimated value is greater than the preset value. The sending module 503 is used to send the target test cases to the current test device.
[0079] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0080] Some embodiments of this application determine the estimated time and value of historical test data to establish estimated planning information, that is, to determine the optimal test cases to be executed for each test device. Then, during actual testing, it is necessary to obtain the device parameters of the current test device and combine them with the obtained estimated planning information to determine the target test cases corresponding to the current test device. This makes the execution time of the target test cases approach the preset average time and maximizes the estimated value. This not only comprehensively considers the status of the test device but also makes reasonable configuration of the test device and test cases, thereby improving testing efficiency.
[0081] Another embodiment of this application further supplements the description of the device scheduling apparatus based on hardware-in-the-loop testing provided in the above embodiments.
[0082] Optionally, the device further includes a setup module, which is used for: Retrieve historical test cases for historical test tasks; Test cases are executed on each test device to obtain test results corresponding to the test device. The test results include at least the execution results, test time, device preset resource information and hardware execution environment. Historical test cases and their corresponding test results are identified as historical test data. Using a pre-defined value assessment algorithm and test results, the estimated value of each test case on different test devices is determined, and the estimated time corresponding to the test case is determined based on the test time. The pre-defined value assessment algorithm is calculated by applying different weights to the device's pre-defined resource information, test results, test time, and test environment. Based on the correspondence between estimated value and estimated time, determine the estimated value information of each test case when tested on different test devices; Using a pre-defined planning algorithm and estimated value information, the estimated planning information for test cases and test equipment is determined. The pre-defined planning algorithm includes at least a dynamic programming algorithm or a greedy algorithm.
[0083] Some embodiments of this application obtain historical test data, determine the estimated time and value of the historical test data, and determine the estimated planning information, that is, determine the optimal test cases to be executed by each test device, thereby improving the efficiency of test case testing.
[0084] Optionally, modules are created for: Based on the device's preset resource information, test time, and each parameter in the test environment, set the weight of the same test case on different test devices; Based on multiple weights on the same test equipment, the estimated value of test cases on the test equipment is determined.
[0085] Some embodiments of this application determine the weight of each parameter for a test device based on the device's preset resource information, test time, and various parameters of the test environment in the test case test. Then, the multiple weights of the test device are multiplied together to obtain the estimated value of the test case on the test device. By comprehensively considering multiple factors, the efficiency of test case execution is improved.
[0086] Optionally, modules are created for: Based on the testing time of the same test case on different testing devices, determine the average execution time or the maximum execution time respectively; The average execution time or maximum execution time is determined as the estimated time for each test case on each test device.
[0087] In some embodiments of this application, based on the test time of the same test case on different test devices, the maximum execution time or the average execution time can be selected as the estimated time for the test case on the test device. Optionally, modules are created for: Based on the estimated planning information, for the same test equipment, the estimated values of different test cases are sorted from largest to smallest to obtain the sorting results, so that the test equipment can perform tests according to the sorting results.
[0088] Some embodiments of this application prioritize the estimated planning information for each test device based on the estimated value of the test cases, ensuring that high-value test cases are executed first and avoiding a decrease in the overall estimated value due to subsequent test device shutdowns or other unavailable environments.
[0089] Optionally, modules are created for: If the target test case fails to be tested on the current test equipment, the target test case will be added to the blacklist information of the current test equipment.
[0090] In some embodiments of this application, when a test case fails to be deployed, the temporary blacklist information of the test case on the test device is recorded to restrict the deployment of the test case to that environment. The estimated value information is recalculated and the estimated planning information is replanned. During the recalculation and planning process, the test case-rack information in the blacklist is restricted based on the temporary blacklist to prevent the test case from being deployed to test devices that cannot be deployed.
[0091] Optionally, modules are created for: If the test cases to be tested on the current test device are not obtained from historical test data, then the pre-set estimated value is obtained, and the current test device is tested according to the pre-set estimated value.
[0092] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0093] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.
[0094] This application also provides a computer-readable storage medium storing a computer program thereon. When the program is executed by a processor, it can implement the operation of any embodiment of the device scheduling method based on hardware-in-the-loop testing provided in the above embodiments.
[0095] This application also provides a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the operation of any embodiment of the device scheduling method based on hardware-in-the-loop testing provided in the above embodiments.
[0096] like Figure 6 As shown, some embodiments of this application provide an electronic device 600, which includes a memory 610, a processor 620, and a computer program stored in the memory 610 and executable on the processor 620. When the processor 620 reads the program from the memory 610 via a bus 630 and executes the program, it can implement any of the methods included in the above-described device scheduling method based on hardware-in-the-loop testing.
[0097] Processor 620 can process digital signals and can include various computing architectures. For example, it can be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 620 can be a microprocessor.
[0098] The memory 610 can be used to store instructions executed by the processor 620 or data related to the execution of instructions. These instructions and / or data may include code for implementing some or all of the functions of one or more modules described in the embodiments of this application. The processor 620 of this disclosure embodiment can be used to execute the instructions in the memory 610 to implement the methods shown above. The memory 610 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.
[0099] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0100] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology 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.
[0101] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
Claims
1. A device scheduling method based on hardware-in-the-loop testing, characterized in that, The method includes: Obtain the device parameters of the current test device; Based on the predetermined estimated planning information, target test cases corresponding to the equipment parameters are determined. The predetermined estimated planning information includes test equipment and test cases corresponding to the test equipment. The estimated planning information is based on historical test data to determine the estimated time and corresponding estimated value of the test cases on each test equipment, so that the estimated time meets the preset average time and the estimated value is greater than the preset value. Send the target test case to the current test device.
2. The device scheduling method based on hardware-in-the-loop testing according to claim 1, characterized in that, The estimated planning information is obtained through the following methods: Retrieve historical test cases for historical test tasks; The test cases are executed using each test device to obtain test results corresponding to the test device. The test results include at least the execution result, test time, device preset resource information, and hardware execution environment. The historical test cases and corresponding test results are determined as the historical test data; Using a preset value assessment algorithm and the test results, the estimated value of each test case on different test devices is determined, and the estimated time corresponding to the test case is determined based on the test time. The preset value assessment algorithm is calculated by applying different weights to preset resource information of the device, test results, test time, and test environment. Based on the correspondence between the estimated value and the estimated time, the estimated value information for each test case tested on different test devices is determined. Using a preset planning algorithm and the estimated value information, the estimated planning information for test cases and test equipment is determined, wherein the preset planning algorithm includes at least a dynamic programming algorithm or a greedy algorithm.
3. The device scheduling method based on hardware-in-the-loop testing according to claim 2, characterized in that, The process of determining the estimated value of each test case on different testing devices using a pre-defined value assessment algorithm and the test results includes: Based on the device's preset resource information, test time, and each parameter in the test environment, the weight of the same test case is set on different test devices. The estimated value of the test case on the same test device is determined based on multiple weights on the same test device.
4. The device scheduling method based on hardware-in-the-loop testing according to claim 2, characterized in that, The step of determining the estimated time corresponding to the test case based on the test time includes: Based on the testing time of the same test case on different testing devices, determine the average execution time or the maximum execution time respectively; The average execution time or maximum execution time is determined as the estimated time for the test case on each test device.
5. The device scheduling method based on hardware-in-the-loop testing according to claim 4, characterized in that, The method further includes: Based on the estimated planning information, for the same test equipment, the estimated values of different test cases are sorted from largest to smallest to obtain a sorting result, so that the test equipment can perform tests according to the sorting result.
6. The device scheduling method based on hardware-in-the-loop testing according to claim 1, characterized in that, The method further includes: If the target test case fails to be tested by the current testing device, the target test case will be identified as blacklist information of the current testing device.
7. The device scheduling method based on hardware-in-the-loop testing according to claim 1, characterized in that, The method further includes: If the test cases to be tested on the current test device are not obtained from historical test data, then a pre-set estimated value is obtained, and the current test device is tested according to the pre-set estimated value.
8. A device scheduling apparatus based on hardware-in-the-loop testing, characterized in that, The device includes: The acquisition module is used to acquire the device parameters of the current test device; The determination module is used to determine the target test cases corresponding to the equipment parameters based on the pre-determined estimated planning information. The pre-determined estimated planning information includes the test equipment and the test cases corresponding to the test equipment. The estimated planning information is based on historical test data to determine the estimated time and corresponding estimated value of the test cases on each test equipment, so that the estimated time meets the preset average time and the estimated value is greater than the preset value. The sending module is used to send the target test case to the current test device.
9. The device scheduling device based on hardware-in-the-loop testing according to claim 8, characterized in that, The apparatus further includes a setup module, the setup module being used for: Retrieve historical test cases for historical test tasks; The test cases are executed using each test device to obtain test results corresponding to the test device. The test results include at least the execution result, test time, device preset resource information, and hardware execution environment. The historical test cases and corresponding test results are determined as the historical test data; Using a preset value assessment algorithm and the test results, the estimated value of each test case on different test devices is determined, and the estimated time corresponding to the test case is determined based on the test time. The preset value assessment algorithm is calculated by applying different weights to preset resource information of the device, test results, test time, and test environment. Based on the correspondence between the estimated value and the estimated time, the estimated value information for each test case tested on different test devices is determined. Using a preset planning algorithm and the estimated value information, the estimated planning information for test cases and test equipment is determined, wherein the preset planning algorithm includes at least a dynamic programming algorithm or a greedy algorithm.
10. The device scheduling apparatus based on hardware-in-the-loop testing according to claim 9, characterized in that, The establishment module is used for: Based on the device's preset resource information, test time, and each parameter in the test environment, the weight of the same test case is set on different test devices. The estimated value of the test case on the same test device is determined based on multiple weights on the same test device.
11. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the device scheduling method based on hardware-in-the-loop testing as described in any one of claims 1-7.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, characterized in that, when the program is executed by a processor, it can implement the device scheduling method based on hardware-in-the-loop testing as described in any one of claims 1-7.