Processing resource allocation method, apparatus, medium, and device

Abstract

Embodiments of the present disclosure disclose a processing resource allocation method, device, medium and equipment. In the test process, the test cases with the same identifier set are divided into the same set according to the identifier set of the test cases, and the target processing resource is allocated to each test case set according to the total processing resource demand of each test case set and the corresponding pre-allocated processing resource, so that the test cases included in each test case set are tested by the target processing resource, thereby avoiding the problem that the test process cannot be normally performed due to unreasonable allocation of processing resources, even error, and improving the overall utilization of processing resources.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method, apparatus, medium, and device for processing resource allocation. Background Technology

[0002] As the collaborative network system center of the key-base cascaded test range, the test range platform provides support for tasks such as network attack and defense drills, cybersecurity talent training, and scientific evaluation of cybersecurity technologies. The platform needs to implement core functions such as data collection, processing, and sharing between different modules, and provide support for various tasks in key-base cascaded scenarios through a multi-service system to ensure system collaboration efficiency, performance, and reliability.

[0003] In related technologies, test cases are written in advance to conduct tests on the target platform. However, the testing process involves multiple test cases to conduct concurrent testing or stress testing in parallel or a combination of serial and parallel methods. This can lead to problems such as the inability to reasonably allocate processing resources in the test platform, such as the number of processor cores and memory, resulting in the test process failing to proceed normally or even reporting errors, and the overall utilization rate of processing resources being low. Summary of the Invention

[0004] This disclosure provides a method, apparatus, medium, and device for allocating processing resources, avoiding problems such as test processes failing or even errors due to unreasonable allocation of processing resources, thereby improving the overall utilization rate of processing resources.

[0005] To address the aforementioned technical problems, the present disclosure provides the following technical solutions: A method for processing resource allocation includes: Obtain multiple test cases, each of which carries an identifier set, the identifier set including a test domain identifier and a test priority identifier; Test cases with the same identifier set are grouped into the same set to obtain at least one test case set; Obtain the total processing resource requirements for each set of test cases; Based on the total processing resource requirement of each test case set and the corresponding pre-partitioned processing resources, the target processing resources corresponding to each test case set are determined. The included test cases are tested using the target processing resources of each set of test cases.

[0006] A resource allocation processing device, comprising: The first acquisition unit is used to acquire multiple test cases, each of which carries an identifier set, the identifier set including a test domain identifier and a test priority identifier; A partitioning unit is used to divide test cases with the same identifier set into the same set, resulting in at least one test case set. The second acquisition unit is used to acquire the total processing resource requirements for each set of test cases; The determining unit is configured to determine the target processing resources corresponding to each set of test cases based on the total processing resource requirements of each set of test cases and the corresponding pre-divided processing resources. A test unit is used to test the included test cases using the target processing resources of each set of test cases.

[0007] In some implementations, the determining unit includes: The filtering subunit is used to filter out a set of candidate test cases with unallocated processing resources from each set of test cases, and to filter out a set of target test cases with the highest priority identified by the test priority identifier from each set of candidate test cases; The first acquisition subunit is used to acquire the first processing resource to be allocated from the pre-divided processing resources corresponding to the target test case set; The first determining subunit is used to determine the differential resource requirement of the target test case set when the total processing resource requirement of the target test case set is greater than the processing resource requirement of the corresponding first processing resource. The second determining subunit is used to determine the target test domain identifier corresponding to the target test case set, and the next test priority identifier after the test priority identifier corresponding to the target test case set; The first partitioning subunit is used to partition the second processing resources with the differential resource requirement from the pre-partitioned processing resources corresponding to the target identifier set to the target test case set. The target identifier set includes the target test domain identifier and the next test priority identifier. The third determining subunit is used to determine the first processing resource and the second processing resource as the target processing resource of the target test case set, and mark the target processing resource as an allocated processing resource; The fourth determining subunit is used to determine the target test case set as a test case set with allocated processing resources, and return to execute the step of filtering out candidate test case sets without allocated processing resources from each test case set until each test case set is updated to a test case set with allocated processing resources, thereby obtaining the target processing resources corresponding to each test case set.

[0008] In some implementations, the first determining subunit is used for: When the total processing resource requirement of the target test case set is greater than the processing resource quantity of the corresponding first processing resource, the difference between the total processing resource requirement and the processing resource quantity of the first processing resource is determined to obtain the differential resource requirement of the target test case set.

[0009] In some implementations, the first acquisition subunit is used for: Obtain the pre-partitioned processing resources corresponding to the target test case set; When there is a third processing resource with an already allocated processing resource identifier in the pre-partitioned processing resources, the processing resources other than the third processing resource in the pre-partitioned processing resources are determined as the first processing resources to be allocated.

[0010] In some implementations, the first acquisition subunit is further configured to: When there is no processing resource with an allocated processing resource identifier in the pre-partitioned processing resources, the pre-partitioned processing resources are determined as the first processing resources to be allocated.

[0011] In some implementations, the determining unit further includes: The second partitioning subunit is used to partition a fourth processing resource from the first processing resource when the total processing resource requirement of the target test case set is less than the processing resource quantity of the corresponding first processing resource; The fifth determining subunit is used to determine the fourth processing resource as the target processing resource of the target test case set.

[0012] In some embodiments, the second acquisition unit includes: The second acquisition subunit is used to acquire the test case processing resource requirements and parallel test resource requirements for each of the test case sets. The sixth determining subunit is used to determine the sum of the test case processing resource requirements and the corresponding parallel test resource requirements for each test case set, so as to obtain the total processing resource requirements for each test case set.

[0013] A computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the above-described processing resource allocation method.

[0014] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-described processing resource allocation method when executing the computer program.

[0015] A computer program product or computer program includes computer instructions stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium and executes the computer instructions to implement the aforementioned processing resource allocation method.

[0016] This embodiment of the disclosure obtains multiple test cases, each test case carrying an identifier set, the identifier set including a test domain identifier and a test priority identifier; divides test cases with the same identifier set into the same set to obtain at least one test case set; obtains the total processing resource requirement of each test case set; determines the target processing resource corresponding to each test case set based on the total processing resource requirement of each test case set and the corresponding pre-divided processing resources; and tests the included test cases using the target processing resource of each test case set.

[0017] Therefore, by dividing test cases with the same identifier set into the same set during the testing process, and allocating corresponding target processing resources to each test case set according to the total processing resource requirements of each test case set and the corresponding pre-allocated processing resources, the test cases included in each test case set can be tested using the target processing resources of each test case set. This avoids the problem of the test process failing to proceed normally or even reporting errors due to unreasonable allocation of processing resources, and improves the overall utilization rate of processing resources.

[0018] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0020] Figure 1 This is a schematic diagram of a processing resource allocation system provided in an embodiment of this disclosure.

[0021] Figure 2 This is a flowchart illustrating the resource allocation method provided in an embodiment of the present disclosure.

[0022] Figure 3This is a flowchart illustrating the process of determining the target processing resources corresponding to each test case set, as provided in an embodiment of this application.

[0023] Figure 4 This is a flowchart illustrating the sequential execution of test cases in accordance with the written logical order provided in the embodiments of this application.

[0024] Figure 5 This is a flowchart illustrating the parallel execution of test cases in the logical order provided in the embodiments of this application.

[0025] Figure 6 This is a schematic diagram of the processing resource allocation architecture provided in the embodiments of this application.

[0026] Figure 7 This is a schematic diagram illustrating the addition of a control service in the service management layer, as provided in an embodiment of this application.

[0027] Figure 8 This is a schematic diagram of the processing resource allocation device provided in an embodiment of the present disclosure.

[0028] Figure 9 A schematic diagram of the structure of a computer device provided in an embodiment of this disclosure. Detailed Implementation

[0029] To enable those skilled in the art to better understand the solutions of this application, the technical solutions of the embodiments of this disclosure 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 skilled in the art without creative effort are within the scope of protection of this application.

[0030] It should be noted that while some processes described in the specification, claims, and accompanying drawings contain multiple steps that appear in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not represent any particular order of execution. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0031] Please see Figure 1 , Figure 1 This is a schematic diagram of a resource allocation system provided in an embodiment of this disclosure. It includes a server 140, an Internet connection 130, a gateway 120, and a client 110, etc.

[0032] Client 110 includes, but is not limited to, mobile phones, tablets, pre-configured desktop computers, laptops, tablet computers, and other electronic devices. Client 110 can communicate with the Internet 130 via wired or wireless means to exchange data.

[0033] Server 140 refers to a computer system or cloud platform that provides storage services to client 110, and includes a database for storing related operations of client 110. Compared to a regular client 110, server 140 has higher requirements in terms of stability, security, and performance. Server 140 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines), etc., and the server stores pre-defined timing logic.

[0034] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator between two systems using different communication protocols, data formats, languages, or even completely different architectures. It also provides filtering and security functions. Test cases sent from client 110 to server 140 are forwarded to the corresponding server via gateway 120, and test results returned from server 140 to client 110 are also forwarded to the corresponding client via gateway 120.

[0035] The voice processing method of this disclosure can be implemented on server 140.

[0036] Server 140 acquires multiple test cases, each test case carrying an identifier set, the identifier set including a test domain identifier and a test priority identifier; test cases with the same identifier set are grouped into the same set to obtain at least one test case set; the total processing resource requirement of each test case set is acquired; based on the total processing resource requirement of each test case set and the corresponding pre-allocated processing resources, the target processing resource corresponding to each test case set is determined; and the included test cases are tested using the target processing resource of each test case set.

[0037] It should be noted that, Figure 1 The schematic diagram of the processing resource allocation system shown is merely an example. The processing resource allocation system and scenario described in this disclosure are intended to more clearly illustrate the technical solutions of this disclosure and do not constitute a limitation on the technical solutions provided in this disclosure. As those skilled in the art will know, with the evolution of video processing and the emergence of new business scenarios, the technical solutions provided in this disclosure are also applicable to similar technical problems.

[0038] In this embodiment, the description will be from the perspective of a processing resource allocation device. Specifically, the processing resource allocation device can be integrated into a computer device that has a storage unit and a microprocessor installed, thus having computing power. The computer device can be a server or a terminal device. In this embodiment, the computer device will be described as a server.

[0039] Please see Figure 2 , Figure 2 This is a flowchart illustrating a processing resource allocation method provided in an embodiment of this disclosure. The processing resource allocation method includes: In step 201, multiple test cases are obtained, each test case carrying an identifier set, which includes a test domain identifier and a test priority identifier.

[0040] The test cases are standardized sets of test instructions designed to verify the correctness of specific service functions (such as power dispatching services and communication data transmission services) in the key-based cascade test range. They include test steps, input data, and expected results, and are the core execution unit for integration testing. Each test case carries an identifier set, which is a combination of core attribute tags bound to the test case. This unique identifier identifies the resource requirement dimension of the test case and serves as the core basis for grouping and resource allocation. It includes a test domain identifier and a test priority identifier, with no additional redundant attributes to ensure accurate grouping. The test domain identifier is a tag representing the key-based industry domain to which the test case belongs, used to achieve cross-domain resource isolation, such as communications (dx), power (dl), transportation (jt), and e-government (zw). The test priority identifier is a tag representing the importance of the test case, used to ensure priority resource protection. The levels are divided into, for example, p0 (highest priority, core business testing), p1 (medium priority, routine business testing), and p2 (lowest priority, non-core business testing). The identifier set for each test case is, for example, "dl-p0" (power industry, highest priority test case) and "dx-p1" (communication industry, medium priority test case).

[0041] Specifically, the test domain identifier and test priority identifier for each test case are labels that testers assign to each test case based on the importance and test priority of the business scenario in the key-based cascade test range when writing the test cases.

[0042] From the test case library at the system's test case layer, all test cases to be executed are read (this can be a single batch or a specified range of test cases). The identifier set carried by each test case is parsed, and the bound test domain identifier and test priority identifier are extracted. This provides a unified and clear dimensional basis for subsequent test case grouping and resource allocation, solving the pain point of existing technology test cases lacking unified resource association identifiers and resulting in chaotic grouping. Through the dual identifier limitation of domain and priority, the resource requirement attributes of test cases are accurately identified, laying the foundation for subsequent isolation allocation and priority assurance.

[0043] In step 202, test cases with the same identifier set are grouped into the same set to obtain at least one test case set.

[0044] In this application embodiment, a grouping rule is provided for test cases: only when the test domain identifier and test priority identifier of two test cases are completely identical are they grouped into the same set; the system traverses all test cases to be executed, aggregates them according to the above rule, and generates at least one set of test cases that do not overlap (such as “dl-p0”, “dl-p1”, “dx-p1”, and “jt-p2”, etc.).

[0045] Specifically, since the resource requirements (domain, priority) of test cases within the same set are completely consistent, resource contention caused by mixing test cases of different dimensions is avoided; multiple scattered test cases are transformed into a small aggregated set of test cases, and resources only need to be allocated to the set in the future, without having to process each test case individually, thus improving the efficiency of resource allocation.

[0046] In step 203, the total processing resource requirements for each set of test cases are obtained.

[0047] The total processing resource requirement is the total amount of processing resources required for the normal and stable execution of a single test case set. It serves as a quantitative basis for resource allocation, and the processing resources include, but are not limited to, the number of CPU cores and the amount of memory.

[0048] In some embodiments, obtaining the total processing resource requirement for each set of test cases includes: (1) Obtain the test case processing resource requirements and parallel test resource requirements for each test case set; (2) Determine the sum of the test case processing resource requirements and the corresponding parallel test resource requirements for each test case set, and obtain the total processing resource requirements for each test case set.

[0049] The resource requirement for test case processing is the sum of the basic execution resource requirements of all test cases in a single test case set. It represents the minimum total resources required for the normal serial execution of the test case set (excluding parallel overhead), corresponding to the sum of the minimum processing resource thresholds for a single test case. It forms the basis of resource accounting, ensuring test cases can execute. Testers can input the required processing resources for each test case before testing. By calculating the sum of the required processing resources for all test cases in the same test case set, the resource requirement for test case processing of the test case set can be obtained. The resource requirement for parallel testing is an additional amount of resources reserved to avoid resource conflicts and peak overload when multiple threads execute in parallel within the test case set. It serves as a buffer for parallel execution, resolving resource contention issues during parallelism and ensuring stable execution of test cases. Parallel buffers can be reserved according to a fixed proportion of the resource requirement for test case processing, or the resource peak gap during parallelism can be calculated based on the maximum number of parallel executions, reserving buffer resources just enough to meet the peak. There are no restrictions here.

[0050] Specifically, after knowing the resource requirements for test case processing and parallel testing for each test case set, the total resource requirements for each test case set can be obtained by calculating the sum of the resource requirements for test case processing and parallel testing.

[0051] In step 204, the target processing resources for each test case set are determined based on the total processing resource requirements of each test case set and the corresponding pre-partitioned processing resources.

[0052] The pre-allocated processing resources are based on rules combining domain isolation and priority hierarchy, reserving basic processing resources in advance for each identifier set dimension. The total core resources of the system (CPU cores and memory) are divided into the following two parts: (1) Industry Resource Pool: Resources are allocated equally according to the number of industry sectors (e.g., 20% of the total resources for each of the 4 industries, with 20% reserved); (2) Priority Resource Pool: Within each industry resource pool, sub-resource pools are pre-defined according to the ratio of p0:p1:p2=5:4:1. Ultimately, in each industry sector, the pre-allocated processing resources of priority p0 account for 10% of the total processing resource pool, the pre-allocated processing resources of priority p1 account for 8% of the total processing resource pool, and the pre-allocated processing resources of priority p2 account for 2% of the total processing resource pool.

[0053] Specifically, based on the total processing resource requirements of each test case set and the corresponding pre-allocated processing resources, the target processing resources allocated to each test case set during the subsequent actual testing process are determined.

[0054] In some implementations, the target processing resources for each test case set are determined based on the total processing resource requirements of each test case set and the corresponding pre-partitioned processing resources, including: (1) Select a set of candidate test cases with unallocated processing resources from each set of test cases, and select a set of target test cases with the highest priority from each set of candidate test cases; (2) Obtain the first processing resource to be allocated from the pre-partitioned processing resources corresponding to the target test case set; (3) When the total processing resource requirement of the target test case set is greater than the processing resource requirement of the corresponding first processing resource, the differential resource requirement of the target test case set is determined; (4) Determine the target test domain identifier corresponding to the target test case set, and the next test priority identifier after the test priority identifier corresponding to the target test case set; (5) Allocate the second processing resources with the differential resource requirements from the pre-partitioned processing resources corresponding to the target identifier set to the target test case set, wherein the target identifier set includes the target test domain identifier and the next test priority identifier; (6) The first processing resource and the second processing resource are determined as the target processing resources of the target test case set, and the target processing resources are marked as allocated processing resources; (7) Determine the target test case set as the test case set with allocated processing resources, and return to the step of filtering out the candidate test case set without allocated processing resources from each test case set until each test case set is updated to the test case set with allocated processing resources, so as to obtain the target processing resources corresponding to each test case set.

[0055] This process involves iterating through all grouped test case sets in the system (such as "dl-p0", "dl-p1", "dx-p0", and "jt-p2"); checking the resource allocation status flag of each set (system defaults to "unallocated", "allocated", and "allocated"); and including all sets marked "unallocated" in the candidate set (e.g., initially, all sets are "unallocated", so the candidate set is all sets); comparing the test priority flags of all sets in the candidate set, and selecting the set with the highest priority as the current target set (e.g., if the candidate set includes three test case sets, "dl-p0", "dx-p0", and "dl-p1", with the highest priority being p0, then "dl-p0" and "dx-p0" are selected as the target test case sets). This ensures that high-priority sets are allocated first, addressing the pain point of disordered resource allocation and low-priority sets crowding out high-priority resources in existing technologies.

[0056] Specifically, since it is unclear whether the pre-partitioned processing resources corresponding to the target test case set have been allocated to other test case sets with higher priority in the same industry, it is necessary to obtain the first processing resource to be allocated (i.e., the unallocated resources can be allocated) in the pre-partitioned processing resources corresponding to the target test case set.

[0057] If the total processing resource requirement of the target test case set is greater than the processing resource requirement of the corresponding first processing resource, it indicates that the corresponding first processing resource cannot meet the testing needs of all test cases in the target test case set. Therefore, it is necessary to determine the differential resource requirement of the target test case set. Based on the target test domain identifier corresponding to the target test case set, determine the next test priority identifier after the test priority identifier corresponding to the target test case set. Allocate the differential resource requirement from the pre-partitioned processing resources corresponding to the target identifier set whose test domain identifier is the target test domain identifier and whose test priority identifier is the next test priority identifier, and assign the second processing resource to the target test case set. This determines the first and second processing resources as the target processing resources for the target test case set, and marks the target processing resources as allocated processing resources. The target test case set is determined as the test case set with allocated processing resources, and the process returns to the step of filtering out candidate test case sets without allocated processing resources from each test case set until each test case set is updated to a test case set with allocated processing resources, thus obtaining the target processing resources corresponding to each test case set.

[0058] For example, if the target test case set is identified as "dl-p0" and its differential resource requirement is 2%, then the next test priority is identified as p1. The pre-configured pre-allocated processing resources for "dl-p1" are 8%, and 2% of these are allocated to the target test case set. This allocated 2% of processing resources is then marked as allocated processing resources. Therefore, the target processing resources for the target test case set are its own pre-allocated processing resources (10%) plus 2%, totaling 12%. Subsequently, the remaining test case sets with priorities p1 and p2 are allocated their corresponding target processing resources.

[0059] In this way, by filtering the unallocated candidate set, locking the highest priority target set, prioritizing the use of the first processing resources to be allocated from its own pre-allocated resources, allocating the difference amount of second processing resources from the next lower priority pre-allocated resources in the same industry when resources are insufficient, and marking the allocated resources and iterating in a loop until the full set is allocated, this approach not only follows the high-priority priority allocation rule, completely solving the pain points of disordered resource allocation and low-priority test cases crowding out high-priority core business test resources in existing technologies, but also avoids mutual interference between test resources in different key domains through resource allocation constraints of limited supplementation within the same industry and isolation across industries. At the same time, based on the accurate calculation of the total processing resource demand and the resources to be allocated, only the difference resources are supplemented as needed, reducing the problems of resource waste and insufficient allocation. Furthermore, the iterative mechanism ensures that all test case sets can obtain target processing resources in an orderly manner. Ultimately, this achieves the orderliness, accuracy, and stability of resource allocation in multi-domain and multi-priority test scenarios in the key-based cascade test range, effectively ensuring the priority execution of core business tests and the efficient advancement of various test tasks.

[0060] In some implementations, when the total processing resource requirement of the target test case set is greater than the processing resource requirement of the corresponding first processing resource, the differential resource requirement of the target test case set is determined, including: When the total processing resource requirement of the target test case set is greater than the processing resource quantity of the corresponding first processing resource, the difference between the total processing resource requirement and the processing resource quantity of the first processing resource is determined to obtain the differential resource requirement of the target test case set.

[0061] If the total processing resource requirement of the target test case set is greater than the processing resource requirement of the corresponding first processing resource, it means that the remaining first processing resource of the target test case set is insufficient. The difference in processing resource requirement between the total processing resource requirement and the first processing resource requirement needs to be calculated so that it can be supplemented by dividing from the low-priority pre-allocated processing resources.

[0062] Specifically, the differential resource requirement is determined by calculating the difference between the total processing resource requirement and the processing resource quantity of the first processing resource. For example, if the total processing resource requirement is 12% and the processing resource quantity of the first processing resource is 10%, then the differential resource requirement is 12% - 10% = 2%.

[0063] Therefore, by directly calculating the difference in resource requirements when the total processing resource requirements of the target test case set exceed its corresponding first processing resource requirements, the resource gap of the high-priority test case set is accurately quantified. This provides a clear and feasible quantitative basis for subsequent on-demand allocation of resources from the low-priority pre-allocated resources in the same industry. It effectively solves the problem of blind, insufficient, or excessive use of low-priority resources caused by unclear resource gaps in existing technologies. It not only ensures the complete resource requirements of the high-priority test case set to support its stable execution, but also follows the principle of on-demand supplementation to avoid resource waste. At the same time, it smoothly connects the preceding and following resource allocation processes, ensuring that the overall resource allocation logic is coherent, accurate, and efficient.

[0064] In some implementations, obtaining the first processing resource to be allocated from the pre-partitioned processing resources corresponding to the target test case set includes: (1.1) Obtain the pre-partitioned processing resources corresponding to the target test case set; (1.2) When there is a third processing resource with an allocated processing resource identifier in the pre-divided processing resources, the processing resources other than the third processing resource in the pre-divided processing resources are determined as the first processing resources to be allocated.

[0065] Since allocated processing resources are marked with an "assigned processing resource identifier," determining the first processing resource to be allocated among the pre-allocated processing resources corresponding to the target test case set requires first obtaining the pre-allocated processing resources corresponding to the target test case set and then identifying which processing resources are marked with the "assigned processing resource identifier." The marked processing resources have already been allocated to test case sets with higher priority. Therefore, if a third processing resource with an assigned processing resource identifier exists among the pre-allocated processing resources, all processing resources other than the third processing resource are determined as the first processing resource to be allocated.

[0066] In this way, by first accurately acquiring the pre-partitioned processing resources specific to the target test case set, and then identifying and excluding third processing resources marked with "allocated processing resource identifier" (i.e. resources already allocated to higher priority sets in the same pre-partitioned resource pool), the first processing resource to be allocated is clearly identified. This not only avoids the conflict problem of duplicate allocation of pre-partitioned resources from the source, but also accurately locks the currently available basic resources, ensuring the exclusivity of higher priority resource allocation. At the same time, it strictly conforms to the pre-partitioning rules of industry isolation and priority layering, providing an accurate basis for subsequent judgment on whether to supplement differential resources. Ultimately, it improves the compliance, accuracy and reliability of multi-service test resource allocation in the key-base cascade test range.

[0067] In some implementations, the method further includes: When there is no processing resource with an allocated processing resource identifier in the pre-partitioned processing resources, the pre-partitioned processing resources are determined as the first processing resources to be allocated.

[0068] If there is no processing resource with an allocated processing resource identifier in the pre-partitioned processing resources, it means that the corresponding pre-partitioned processing resource has not been allocated to other test case sets. Therefore, all pre-partitioned processing resources can be identified as the first processing resources to be allocated.

[0069] Therefore, when there is no allocated identifier for pre-partitioned processing resources, all pre-partitioned resources are directly identified as the first processing resources to be allocated. This simplifies the resource screening process, improves the efficiency of resource allocation, and ensures that the target test case set can obtain sufficient dedicated pre-partitioned resources. This avoids relying on low-priority resources for supplementation in the initial stage, laying a solid foundation for the subsequent stable execution of tests on the target set, and further improving the flexibility and reliability of resource allocation in the key-based cascade test range.

[0070] In some implementations, the method further includes: (1) When the total processing resource requirement of the target test case set is less than the processing resource amount of the corresponding first processing resource, a fourth processing resource with a processing resource amount equal to the total processing resource requirement is allocated from the first processing resource. (2) The fourth processing resource is determined as the target processing resource of the target test case set.

[0071] Specifically, the total processing resource requirement of the target test case set is retrieved, and it is determined whether the total requirement is less than the first processing resource. If the determination is true, the corresponding resource quantity is separately allocated from the first processing resource according to the value of the total processing resource requirement as the fourth processing resource. The fourth processing resource is marked as the target processing resource of the target test case set.

[0072] For example, the total processing resource requirement of the target test case set "dx-p1" (telecommunications industry p1 priority) is 6 core CPUs + 6GB memory, and the corresponding first processing resource is 8 core CPUs + 8GB memory. Then, 6 cores + 6GB are allocated from the 8 cores + 8GB as the fourth processing resource, and the remaining 2 cores + 2GB are still used as the pre-allocated processing resource corresponding to the dx industry p1 priority.

[0073] Therefore, when the total processing resource requirement of the target test case set is less than the corresponding first processing resource, a fourth processing resource equal to the total requirement is allocated from the first processing resource as the target processing resource. This avoids the waste caused by excessive occupation of pre-allocated resources, reserves available resources for other unallocated sets of the same priority in the same industry, simplifies the allocation process without the need to supplement differential resources, improves allocation efficiency, ensures stable test execution, and improves the accuracy and utilization of key-based cascade test range resource allocation.

[0074] In some implementations, the method further includes: When the total processing resource requirement of the target test case set is less than the processing resource amount of the corresponding first processing resource, the first processing resource is determined as the target processing resource of the target test case set, and the first processing resource is evenly distributed to each test case included in the target test case set.

[0075] In another implementation, if the total processing resource requirement of the target test case set is less than the processing resource amount of the corresponding first processing resource, all the first processing resources can be directly determined as the target processing resources of the target test case set, and then the first processing resources can be evenly distributed to each test case included in the target test case set.

[0076] For example, if the target test case set includes 5 test cases, and the corresponding total processing resource requirement is 8%, which is less than the corresponding first processing resource requirement of 10%, then the 10% first processing resource will be evenly distributed among these 5 test cases, meaning that each test case can use 2% of the processing resources.

[0077] Please see Figure 3 , Figure 3This is a flowchart illustrating the process of determining the target processing resources corresponding to each test case set in this application embodiment. The test cases to be executed are used as the process input; these test cases are instruction sets for verifying service functions in the target range. The identifier set of the test cases is obtained by extracting the test domain identifier (e.g., dl, dx) and test priority identifier (e.g., p0 / p1 / p2) bound to each test case (i.e., the identifier set). This is the core basis for subsequent grouping and resource allocation. Test case sets are divided according to the identifier set. Test cases with completely identical identifier sets (same domain and same priority) are grouped together to obtain test case sets (e.g., "dl-p0", "dx-p1" sets), achieving accurate clustering of test cases and locking in units for resource allocation. The corresponding pre-allocated processing resources are located based on the identifier of the test case set, finding its dedicated industry resource pool and priority sub-pool (i.e., pre-allocated processing resources). For example, the dx-p1 set corresponds to the p1 priority sub-pool under the communication industry resource pool, clarifying the basic source of resource allocation. The total processing resource requirement of the test case set (the sum of the basic requirement and the parallel redundancy requirement) is compared to see if it is less than the corresponding pre-allocated processing resource amount. If so, the resource allocation process proceeds directly; otherwise, a priority preemption mechanism is triggered (i.e., the difference is supplemented from the pre-allocated resources of lower priority in the same industry to resolve the resource gap). Regardless of whether preemption is triggered, the target processing resources (pre-allocated resources combined with preempted resources) are ultimately allocated equally according to the number of test cases within the set, ensuring fairness of resource allocation for test cases within the same set. The target processing resources are marked as allocated, confirmed as "in use," to avoid duplicate allocation, and the test is started.

[0078] In step 205, the included test cases are tested using the target processing resources of each test case set.

[0079] After determining the target processing resources corresponding to each test case set, the target processing resources (CPU, memory) are scheduled to the execution queue of that set to ensure dedicated availability of resources. Test cases within the set are executed serially or in parallel based on the target processing resources (the number of parallel executions is dynamically calculated by the amount of target processing resources, with 10%-15% elastic redundancy reserved). Within a single test case, the steps are executed sequentially. After all test cases within the set have been executed, the system releases the target processing resources and returns them to the corresponding pre-allocated resource pool for use by subsequent sets.

[0080] Dedicated processing resources avoid resource contention across collections, resolving the issue of resource conflicts causing test case execution failures during concurrent testing in existing technologies, and ensuring the stability of test execution; parallel execution based on target processing resources maximizes resource utilization and shortens the testing cycle of batch test cases; resources are released after test case execution to avoid long-term resource occupation and improve overall resource utilization.

[0081] For details, please refer to Figure 4 and Figure 5 , Figure 4 This is a flowchart illustrating the sequential execution of test cases according to the written logical order provided in the embodiments of this application. Figure 5 This is a flowchart illustrating the parallel execution of test cases in the logical order provided in this application embodiment. For serial execution, before test execution, the necessary input data (such as business parameters, configuration information, etc.) is prepared, which is a prerequisite for test initiation. The test process is started, entering the formal execution phase; the preconditions / initial steps of the test are verified (such as whether the service under test is successfully connected and whether the initial data is loaded). If it fails, it directly jumps to stop the test; if it succeeds, it enters the core business phase. Business logic 1: Execute the first core business step (such as specific functional operations such as data query). Verify the execution result of business logic 1 (such as whether the query result meets expectations). If it fails, the test is terminated; if it succeeds, it enters the subsequent business phase. Execute the Nth core business step (N represents multiple subsequent business phases in the process, which is a representation of process reuse, such as exporting data after querying). Verify the execution result of business logic N. If it fails, the test is terminated; if it succeeds, the process continues. Regardless of whether any intermediate phase fails or all business logics are executed successfully, this step will be entered, terminating the current test process. After the test is completed, the temporary data generated during the process is cleaned up to avoid polluting the test environment and ensure the accuracy of subsequent tests.

[0082] For parallel execution, pre-test preparations include preparing the necessary input data and environment configurations (such as business parameters). The test process begins, entering the formal execution phase. Initial test conditions are verified (e.g., whether the service under test is available and whether the initial data is ready). If failure occurs, the test is stopped immediately; if successful, two independent business logics are started simultaneously (executed in parallel). Parallel business logic 1 and parallel business logic N are independent business steps with no sequential dependency (e.g., querying user basic information and querying user order lists), and will be executed concurrently (rather than sequentially) to save test time. The execution results of parallel business logic 1 and parallel business logic N are verified separately. If either step fails, the test is stopped immediately; only if both steps succeed will the subsequent parallel business logic N+1 proceed. Parallel business logic N+1 is a subsequent business that depends on the results of the first two parallel steps (e.g., merging user information and order data to generate a report), and will only execute after the first two parallel logics have succeeded. The execution result of this step is verified; if it fails, the test is stopped; if successful, the process continues. Regardless of whether any step fails or all steps succeed, the current test process will terminate. After the test, temporary data (such as test-generated reports and temporary records) will be cleaned up to avoid contaminating the test environment.

[0083] As described above, this embodiment of the disclosure obtains multiple test cases, each test case carrying an identifier set, the identifier set including a test domain identifier and a test priority identifier; divides test cases with the same identifier set into the same set to obtain at least one test case set; obtains the total processing resource requirement of each test case set; determines the target processing resource corresponding to each test case set based on the total processing resource requirement of each test case set and the corresponding pre-divided processing resources; and tests the included test cases using the target processing resource of each test case set.

[0084] Therefore, by dividing test cases with the same identifier set into the same set during the testing process, and allocating corresponding target processing resources to each test case set according to the total processing resource requirements of each test case set and the corresponding pre-allocated processing resources, the test cases included in each test case set can be tested using the target processing resources of each test case set. This avoids the problem of the test process failing to proceed normally or even reporting errors due to unreasonable allocation of processing resources, and improves the overall utilization rate of processing resources.

[0085] Please see Figure 6 , Figure 6 This is a schematic diagram of the processing resource allocation architecture provided in an embodiment of this application. The processing resource allocation architecture includes a storage layer, a common layer, a service management layer, a use case layer, an execution layer, and a result display layer.

[0086] The storage layer is a component in an integration testing framework / system that provides data storage services, offering reliable and efficient storage support for various data generated during testing. Its role is to isolate upper-layer modules from the details of the underlying database implementation, providing standard data storage and access services to upper-layer modules. It supports multiple database types to meet diverse storage needs and is a crucial component of the testing framework's data infrastructure. It supports various database types, including relational databases (such as MySQL and PostgreSQL), document databases (such as MongoDB), and graph databases (such as Neo4j and Nebula), suitable for storing structured, unstructured, and relational data, respectively. The storage layer adopts an object-oriented design pattern, encapsulating the specific implementations of different databases into different modules or classes, achieving decoupling and allowing for easy addition of support for new database types. It provides unified database operation functions to the upper layer, shielding the differences between different database implementations and supporting basic CRUD operations as well as advanced query aggregation operations. It also supports database connection pooling, transaction management, and caching to improve access efficiency and ensure data integrity.

[0087] The common layer is the foundational module of the integration testing framework / system, providing common functions and services to support and facilitate the operation of the entire system. The common layer mainly consists of three parts: configuration management, log management, and a common function library. The configuration management module manages system configurations uniformly, supporting multiple configuration sources and dynamic modification. This includes connection parameters for various databases in the storage layer, server addresses, test execution parameters, etc. This module also supports dynamic modification and hot updating of configuration items, facilitating configuration adjustments during system runtime. The log management module provides unified logging functionality, supporting multiple log levels and output methods, as well as advanced features such as log formatting and log file scrolling, facilitating the management and analysis of system runtime logs. The common function library mainly provides utility functions for test case execution, data processing, database operations, and general tools. These include: test case execution-related functions that can obtain and judge the results of each step, store test case execution results, and support multi-threaded / multi-process execution of test cases; data processing functions that can process and parse test data; encapsulation of functions for various database operations in the storage layer, providing a unified interface for upper-layer calls; and general utility functions including time / date processing, file / directory operations, etc. The common function library is designed following the principles of loose coupling and high cohesion, providing basic service support for upper-layer business modules and improving code maintainability, scalability, and reusability. Based on the storage layer, the common layer provides basic and general configuration management, logging, and general utility function support for the entire testing framework / system. Based on these basic services, upper-layer business modules can focus on their core logic, improving code maintainability, reusability, and system scalability.

[0088] The service management layer is a module specifically designed for managing and controlling services (Server) and clients (Client). It comprises two main components: the server-side processor (ServerHandler) and the client-side processor (ClientHandler). ServerHandler is primarily responsible for starting and stopping service processes. Based on the configuration management functions of the common layer, it sets the list of services to be started or stopped in the configuration file. ServerHandler provides a unified service operation interface function, shielding the differences in start / stop methods for different services. Before test execution, it starts all or some of the required services according to the configuration file. After test execution, it automatically stops and cleans up all previously started service processes. ServerHandler provides service start / stop logging and exception handling functions based on the common layer's log management module. ClientHandler manages and controls client usage, maintains a scalable client pool, uniformly manages various types of client instances, and supports configuring default options and parameters for clients. ClientHandler also supports easily extending new types of clients and integrating them into the client pool. Based on the common layer's log management module, it provides client operation logging and exception handling functions. The service management layer, based on the common layer, provides unified management and lifecycle control for services and their clients, enabling the test execution framework to flexibly configure and manage the services under test. The service management layer also facilitates the extension of new types of services and clients, and updates to the common layer configuration. By encapsulating service and client management logic within the service management layer, the test framework becomes more modular, configurable, and scalable, while also being more stable and reliable. Scalability is as follows: Figure 7 As shown, Figure 7 This diagram illustrates the addition of a control service to the service management layer as provided in this embodiment of the application. When adding a new service, server3, simply add the process name and path of server3 to the configuration module of the public layer, and then add the corresponding function operation for client3 in the ClientHander.

[0089] The test case layer is the core module responsible for writing and managing test cases. Based on the common and service management layers, it provides flexible test case writing methods, supporting both sequential and parallel execution modes, while maintaining decoupling from the specific implementation of the service under test. Test case writers only need to focus on the test objectives and expected results, without needing to understand the service implementation details, and interact with the service layer through encapsulated unified client functions. The test case layer also provides advanced features such as test case management, version control, and data-driven approaches, improving the efficiency of test case writing and maintenance and the system's scalability. As the core of the testing framework, the test case layer provides testers with a one-stop solution for test case writing and execution, balancing flexibility and maintainability. In sequential execution mode, test cases will execute each step in the logical order they are written. This mode is suitable for test scenarios with clear sequential requirements, such as simulating user operation processes. The logic for writing test cases in sequential execution is as follows: Figure 4 As shown. Parallel execution mode supports running multiple different business logics or performing different operations simultaneously on multiple threads, which can be used for constructing exception scenarios or simultaneous interaction of multiple services. The default supported concurrency mainly depends on the number of CPUs on the running machine, but a maximum concurrency can also be specified. The logic for writing parallel execution test cases is as follows: Figure 5 As shown.

[0090] The execution layer is the core component of the key-based cascaded test range integration testing system. It is responsible for executing test cases, featuring dynamic resource allocation, dual-mode test case execution, and end-to-end result acquisition. It receives test cases (including test case steps, priority tags, and industry domain tags) written from the test case layer and executes and collects results from these cases. The execution layer provides two execution modes: single test case execution and batch test case execution. In single test case execution mode, each step is precisely controlled and results are tracked in real time. The execution layer executes each step defined in the test case sequentially. During the execution of each step, it interacts with the service layer, triggering corresponding test operations and obtaining execution results. The execution layer tracks and records the execution status, logs, and other information of each step in real time for subsequent analysis and reporting. In batch test case execution mode, multiple test cases can be run automatically. It automatically reads all specified test cases (supporting filtering by industry tags and priority tags), and executes them using a combination of parallel scheduling and sequential execution, recording the results of each step of each test case in turn. The execution layer tracks and records the execution status, logs, and other information of each step of each test case in real time for subsequent analysis and reporting.

[0091] The results display layer is a module within the integration testing framework / system specifically responsible for displaying the execution results of the execution layer tests. It presents various information and data generated during the test run in an intuitive and user-friendly manner, including test case execution results, statistical data, detailed log locations, etc., providing testers and related personnel with comprehensive feedback on the execution status. The results display layer mainly consists of an overall test results summary, test case result details, and log viewing. The overall test results summary aggregates high-level results of the entire test execution process, including key indicators such as the total number of test cases, the number of successes, the number of failures, the number of errors, and the number of skips, intuitively reflecting the overall execution status of the test. Test case result details provide detailed execution result information for each executed test case, including the test case name, execution time, status (pass / fail / error / skipped), and step logs. Users can accurately understand the specific execution status of each test case. The log viewing provides detailed logs generated during test execution, which are important for analyzing and debugging problems. The execution results display the log storage location for each test case, making it convenient for users to find and track log information of interest.

[0092] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a processing resource allocation device provided in an embodiment of the present disclosure. The processing resource allocation device is applied to a server and may include a first acquisition unit 801, a partitioning unit 802, a second acquisition unit 803, a determination unit 804, and a testing unit 805, etc.

[0093] The first acquisition unit 801 is used to acquire multiple test cases, each of which carries an identifier set, the identifier set including a test domain identifier and a test priority identifier; The partitioning unit 802 is used to partition test cases with the same identifier set into the same set to obtain at least one test case set; The second acquisition unit 803 is used to acquire the total processing resource requirements of each set of test cases; The determining unit 804 is used to determine the target processing resources corresponding to each test case set based on the total processing resource requirements of each test case set and the corresponding pre-partitioned processing resources. Test unit 805 is used to test the included test cases using the target processing resources of each set of test cases.

[0094] In some implementations, the determining unit includes: The filtering subunit is used to filter out a set of candidate test cases with unallocated processing resources from each set of test cases, and to filter out a set of target test cases with the highest priority identified by the test priority identifier from each set of candidate test cases; The first acquisition subunit is used to acquire the first processing resource to be allocated from the pre-divided processing resources corresponding to the target test case set; The first determining subunit is used to determine the differential resource requirement of the target test case set when the total processing resource requirement of the target test case set is greater than the processing resource requirement of the corresponding first processing resource. The second determining subunit is used to determine the target test domain identifier corresponding to the target test case set, and the next test priority identifier after the test priority identifier corresponding to the target test case set; The first partitioning subunit is used to partition the second processing resources with the differential resource requirement from the pre-partitioned processing resources corresponding to the target identifier set to the target test case set. The target identifier set includes the target test domain identifier and the next test priority identifier. The third determining subunit is used to determine the first processing resource and the second processing resource as the target processing resource of the target test case set, and mark the target processing resource as an allocated processing resource; The fourth determining subunit is used to determine the target test case set as a test case set with allocated processing resources, and return to execute the step of filtering out candidate test case sets without allocated processing resources from each test case set until each test case set is updated to a test case set with allocated processing resources, thereby obtaining the target processing resources corresponding to each test case set.

[0095] In some implementations, the first determining subunit is used for: When the total processing resource requirement of the target test case set is greater than the processing resource quantity of the corresponding first processing resource, the difference between the total processing resource requirement and the processing resource quantity of the first processing resource is determined to obtain the differential resource requirement of the target test case set.

[0096] In some implementations, the first acquisition subunit is used for: Obtain the pre-partitioned processing resources corresponding to the target test case set; When there is a third processing resource with an already allocated processing resource identifier in the pre-partitioned processing resources, the processing resources other than the third processing resource in the pre-partitioned processing resources are determined as the first processing resources to be allocated.

[0097] In some implementations, the first acquisition subunit is further configured to: When there is no processing resource with an allocated processing resource identifier in the pre-partitioned processing resources, the pre-partitioned processing resources are determined as the first processing resources to be allocated.

[0098] In some implementations, the determining unit further includes: The second partitioning subunit is used to partition a fourth processing resource from the first processing resource when the total processing resource requirement of the target test case set is less than the processing resource quantity of the corresponding first processing resource; The fifth determining subunit is used to determine the fourth processing resource as the target processing resource of the target test case set.

[0099] In some embodiments, the second acquisition unit includes: The second acquisition subunit is used to acquire the test case processing resource requirements and parallel test resource requirements for each of the test case sets. The sixth determining subunit is used to determine the sum of the test case processing resource requirements and the corresponding parallel test resource requirements for each test case set, so as to obtain the total processing resource requirements for each test case set.

[0100] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0101] As described above, in this embodiment, the first acquisition unit 801 acquires multiple test cases, each test case carrying an identifier set, the identifier set including a test domain identifier and a test priority identifier; the partitioning unit 802 partitions test cases with the same identifier set into the same set, obtaining at least one test case set; the second acquisition unit 803 acquires the total processing resource requirement of each test case set; the determination unit 804 determines the target processing resource corresponding to each test case set based on the total processing resource requirement of each test case set and the corresponding pre-partitioned processing resource; and the testing unit 805 tests the included test cases using the target processing resource of each test case set.

[0102] Figure 9This is a partial structural block diagram of a computer device 1000 implementing an embodiment of the present disclosure. The computer device 1000 can vary significantly due to different configurations or performance characteristics, and may include one or more central processing units (CPUs) 422 (e.g., one or more processors) and a memory 432, and one or more storage media 430 (e.g., one or more mass storage devices) storing application programs 442 or data 444. The memory 432 and storage media 430 may be temporary or persistent storage. The program stored in the storage media 430 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server 500. Furthermore, the CPU 422 may be configured to communicate with the storage media 430 and execute the series of instruction operations in the storage media 430 on the server 500.

[0103] Computer device 1000 may also include one or more power supplies 425, one or more wired or wireless network interfaces 450, one or more input / output interfaces 458, and / or one or more operating systems 441, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0104] The central processing unit 422 in the computer device 1000 can be used to execute the processing resource allocation method of the present disclosure embodiment: acquiring a plurality of test cases, each test case carrying an identifier set, the identifier set including a test domain identifier and a test priority identifier; dividing test cases with the same identifier set into the same set to obtain at least one test case set; acquiring the total processing resource requirement of each test case set; determining the target processing resource corresponding to each test case set based on the total processing resource requirement of each test case set and the corresponding pre-allocated processing resources; and testing the included test cases using the target processing resource of each test case set.

[0105] This disclosure also provides a computer-readable storage medium for storing program code for executing the processing resource allocation methods of the foregoing embodiments: acquiring multiple test cases, each test case carrying an identifier set, the identifier set including a test domain identifier and a test priority identifier; dividing test cases with the same identifier set into the same set to obtain at least one test case set; acquiring the total processing resource requirement of each test case set; determining the target processing resource corresponding to each test case set based on the total processing resource requirement of each test case set and the corresponding pre-allocated processing resources; and testing the included test cases using the target processing resource of each test case set.

[0106] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the aforementioned processing resource allocation method.

[0107] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0108] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0109] It should be understood that in the description of the embodiments of this disclosure, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0110] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0111] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

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

[0114] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0115] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0116] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A method for processing resource allocation, characterized in that, include: Obtain multiple test cases, each of which carries an identifier set, the identifier set including a test domain identifier and a test priority identifier; Test cases with the same identifier set are grouped into the same set to obtain at least one test case set; Obtain the total processing resource requirements for each set of test cases; Based on the total processing resource requirement of each test case set and the corresponding pre-partitioned processing resources, the target processing resources corresponding to each test case set are determined. The included test cases are tested using the target processing resources of each set of test cases.

2. The resource allocation method according to claim 1, characterized in that, The step of determining the target processing resources for each test case set based on the total processing resource requirements and the corresponding pre-partitioned processing resources for each test case set includes: From each of the test case sets, a set of candidate test cases with unallocated processing resources is selected, and from each of the candidate test case sets, a set of target test cases with the highest priority identified by the test priority identifier is selected; Obtain the first processing resource to be allocated from the pre-partitioned processing resources corresponding to the target test case set; When the total processing resource requirement of the target test case set is greater than the processing resource requirement of the corresponding first processing resource, the difference in resource requirement of the target test case set is determined. Determine the target test domain identifier corresponding to the target test case set, and the next test priority identifier after the test priority identifier corresponding to the target test case set; The second processing resource, which allocates the differential resource requirement from the pre-partitioned processing resources corresponding to the target identifier set, is allocated to the target test case set. The target identifier set includes the target test domain identifier and the next test priority identifier. The first processing resource and the second processing resource are determined as the target processing resources of the target test case set, and the target processing resources are marked as allocated processing resources; The target test case set is determined as the test case set with allocated processing resources, and the step of filtering out candidate test case sets without allocated processing resources from each test case set is returned until each test case set is updated to a test case set with allocated processing resources, thereby obtaining the target processing resources corresponding to each test case set.

3. The resource allocation method according to claim 2, characterized in that, When the total processing resource requirement of the target test case set is greater than the processing resource requirement of the corresponding first processing resource, the differential resource requirement of the target test case set is determined, including: When the total processing resource requirement of the target test case set is greater than the processing resource quantity of the corresponding first processing resource, the difference between the total processing resource requirement and the processing resource quantity of the first processing resource is determined to obtain the differential resource requirement of the target test case set.

4. The resource allocation method according to claim 2, characterized in that, The step of obtaining the first processing resource to be allocated from the pre-partitioned processing resources corresponding to the target test case set includes: Obtain the pre-partitioned processing resources corresponding to the target test case set; When there is a third processing resource with an already allocated processing resource identifier in the pre-partitioned processing resources, the processing resources other than the third processing resource in the pre-partitioned processing resources are determined as the first processing resources to be allocated.

5. The resource allocation method according to claim 4, characterized in that, The method further includes: When there is no processing resource with an allocated processing resource identifier in the pre-partitioned processing resources, the pre-partitioned processing resources are determined as the first processing resources to be allocated.

6. The resource allocation method according to claim 2, characterized in that, The method further includes: When the total processing resource requirement of the target test case set is less than the processing resource requirement of the corresponding first processing resource, a fourth processing resource with a processing resource requirement equal to the total processing resource requirement is allocated from the first processing resource. The fourth processing resource is determined as the target processing resource for the target test case set.

7. The resource allocation method according to any one of claims 1 to 6, characterized in that, The step of obtaining the total processing resource requirements for each of the test case sets includes: Obtain the resource requirements for test case processing and parallel testing for each of the test case sets; The total processing resource requirement for each test case set is obtained by determining the sum of the test case processing resource requirements and the corresponding parallel test resource requirements for each test case set.

8. A resource allocation processing device, characterized in that, include: The first acquisition unit is used to acquire multiple test cases, each of which carries an identifier set, the identifier set including a test domain identifier and a test priority identifier; A partitioning unit is used to divide test cases with the same identifier set into the same set, resulting in at least one test case set. The second acquisition unit is used to acquire the total processing resource requirements for each set of test cases; The determining unit is configured to determine the target processing resources corresponding to each set of test cases based on the total processing resource requirements of each set of test cases and the corresponding pre-divided processing resources. A test unit is used to test the included test cases using the target processing resources of each set of test cases.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to execute the processing resource allocation method according to any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the processing resource allocation method according to any one of claims 1 to 7.

Images