Test case scheduling method and device, equipment, storage medium and computer program product

Abstract

The invention discloses a test case scheduling method and device, equipment, a storage medium and a computer program product, and relates to the technical field of tests.The method comprises the steps that when a to-be-executed test task sent by a user to a solid state disk is received, a to-be-executed test case contained in the to-be-executed test task is obtained; marking an execution priority corresponding to the to-be-executed test case according to the defect occurrence probability of the to-be-executed test case; querying an available test environment under the current test version and historical execution data of the to-be-executed test case; and scheduling the to-be-executed test case based on the execution priority, the available test environment and the historical execution data. According to the method, the corresponding execution priority is determined according to the defect occurrence probability of the to-be-executed test case, and then the to-be-executed test case is scheduled based on the available test environment under the current test version, the historical execution data of the to-be-executed test case and the execution priority, so that the test efficiency of a test link and the test resource utilization rate are improved.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a test case scheduling method, apparatus, device, storage medium, and computer program product. Background Technology

[0002] With increasing market competition, product development cycles are constantly shortening. Testing, as a crucial part of the product development process, directly determines the product delivery cycle. In the testing phase, rationally scheduling test tasks can reduce testing time, expose problems early, and thus effectively improve testing efficiency and resource utilization. However, the scheduling of test tasks relies on the arrangement of individual test cases within those tasks. Therefore, how to effectively improve testing efficiency and resource utilization has become an important research direction in the industry. Summary of the Invention

[0003] The main purpose of this application is to provide a test case scheduling method, apparatus, device, storage medium, and computer program product, aiming to solve the technical problem of how to effectively improve the testing efficiency and test resource utilization in the testing process.

[0004] To achieve the above objectives, this application provides a test case scheduling method, the method comprising the following steps:

[0005] When a user sends a test task to be executed for a solid-state drive, the test cases to be executed contained in the test task are obtained;

[0006] The execution priority of each test case is assigned based on the probability of its defect occurrence.

[0007] Query the available test environments and historical execution data of the test cases to be executed under the current test version;

[0008] The test cases to be executed are scheduled based on the execution priority, the available test environment, and the historical execution data.

[0009] In one embodiment, the step of marking the execution priority of the test case to be executed according to the probability of defect occurrence of the test case to be executed includes:

[0010] When the probability of the defect occurring in the test case to be executed is within the first probability interval, the execution priority of the test case to be executed is marked according to the historical execution data of the test case to be executed and the preset priority standard;

[0011] When the probability of the defect occurring in the test case to be executed is within the second probability interval, the execution priority of the test case to be executed is marked according to the test strategy and preset priority standard under the current test version.

[0012] When the probability of a defect occurring in the test case to be executed is within the third probability interval, the execution priority corresponding to the test case to be executed is marked as not to be executed.

[0013] In one embodiment, after the step of marking the execution priority of the test case to be executed according to the probability of defect occurrence of the test case to be executed, the method further includes:

[0014] After all the execution priorities of the test cases to be executed have been marked, determine whether there are any abnormalities in the execution priorities;

[0015] If so, return to the step of marking the execution priority of the test case to be executed according to the probability of defect occurrence of the test case to be executed, so as to re-mark the execution priority of the test case to be executed;

[0016] If not, save the execution priority and execute the step of querying the available test environments under the current test version.

[0017] In one embodiment, the step of scheduling the test cases to be executed based on the execution priority, the available test environment, and the historical execution data includes:

[0018] The execution strategy for the test cases to be executed is formulated based on the execution priority, the available testing environment, and the historical execution data.

[0019] Based on the execution strategy, a test case execution list is generated for different test environments, and the test cases to be executed are scheduled using the test case execution list.

[0020] In one embodiment, the step of formulating an execution strategy for the test cases to be executed based on the execution priority, the available testing environment, and the historical execution data includes:

[0021] The target test environment for the test cases to be executed is determined based on the historical execution data.

[0022] Based on the target test environment, determine the environment allocation corresponding to the test cases to be executed in the available test environments;

[0023] The execution order of the test cases to be executed in the available test environment is determined according to the execution priority.

[0024] The execution strategy for the test cases to be executed is formulated based on the environment allocation and the execution order.

[0025] In one embodiment, after the step of formulating the execution strategy for the test cases to be executed based on the execution priority, the available testing environment, and the historical execution data, the method further includes:

[0026] If the execution strategy fails the check, the process returns to the step of formulating the execution strategy for the test cases to be executed based on the execution priority, the available test environment, and the historical execution data, so as to reformulate the execution strategy for the test cases to be executed.

[0027] If the execution strategy passes the check, the execution strategy is saved, and the step of generating the test case execution list corresponding to different test environments based on the execution strategy is executed.

[0028] Furthermore, to achieve the above objectives, this application also proposes a test case scheduling device, which includes:

[0029] The test case acquisition module is used to acquire the test cases to be executed contained in the test task to be executed when it receives a test task to be executed from a user for a solid-state drive.

[0030] The priority labeling module is used to label the execution priority of the test cases to be executed according to the probability of defect occurrence of the test cases to be executed;

[0031] The information query module is used to query the available test environments under the current test version and the historical execution data of the test cases to be executed;

[0032] The test case scheduling module is used to schedule the test cases to be executed based on the execution priority, the available test environment, and the historical execution data.

[0033] In addition, to achieve the above objectives, this application also proposes a test case scheduling device, the device comprising: a memory, a processor, and a test case scheduler stored in the memory and executable on the processor, the test case scheduler being configured to implement the steps of the test case scheduling method described above.

[0034] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a test case scheduler is stored, and when the test case scheduler is executed by a processor, it implements the steps of the test case scheduling method described above.

[0035] In addition, to achieve the above objectives, the present invention also provides a computer program product, the computer program product including a test case scheduler, which, when executed by a processor, implements the steps of the test case scheduling method as described above.

[0036] When this application receives a test task to be executed from a user for a solid-state drive, it obtains the test cases to be executed contained in the test task; it marks the execution priority of the test cases to be executed according to the probability of defect occurrence of the test cases to be executed; it queries the available test environment under the current test version and the historical execution data of the test cases to be executed; and it schedules the test cases to be executed based on the execution priority, the available test environment, and the historical execution data. The method of this application determines the execution priority of the test cases to be executed based on the probability of defect occurrence of the test cases to be executed in the test task, and then schedules the test cases to be executed based on the available test environment under the current test version, the historical execution data of the test cases to be executed, and the execution priority. This achieves dynamic scheduling of test cases by continuously sensing defect information and environmental changes during test execution, thereby effectively improving the testing efficiency and test resource utilization of the testing process. Attached Figure Description

[0037] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a flowchart illustrating the overall scheduling process architecture of the test case scheduling method in this application.

[0040] Figure 2 This is a flowchart illustrating the first embodiment of the test case scheduling method of this application;

[0041] Figure 3 This is a flowchart illustrating the second embodiment of the test case scheduling method of this application;

[0042] Figure 4 This is a flowchart illustrating the third embodiment of the test case scheduling method of this application;

[0043] Figure 5 This is a structural block diagram of the first embodiment of the test case scheduling device of this application;

[0044] Figure 6 This is a schematic diagram of the structure of the test case scheduling device for the hardware operating environment involved in the embodiments of this application.

[0045] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0046] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0047] It should be noted that the executing entity in the embodiments of this application can be a computing service device with data processing, network communication, and program execution functions, such as a smart wearable device, a personal computer, or a mobile phone, or an electronic device capable of implementing the above functions, such as the aforementioned test case scheduling device. The following embodiments will be described using a test case scheduling device as an example. Specifically, the aforementioned test case scheduling device may include an MCP (Model Context Protocol) service layer, an agent service layer, and a scheduling management layer. For details, please refer to... Figure 1 , Figure 1 This is a flowchart illustrating the overall scheduling process architecture of the test case scheduling method in this application.

[0048] exist Figure 1 In this framework, the MCP service layer is a collection of standardized services responsible for providing the information needed by the intelligent agent during runtime. These standardized services may include, but are not limited to, a defect query MCP service (for querying defect information), a test case information MCP service (for obtaining the set of test cases to be executed for a given version), a test strategy query MCP service (for querying test strategies), an execution information MCP service (for querying test case execution results), and a test environment query MCP service (for querying the test environment status). Based on the MCP service layer, the ability of large-scale intelligent agents to acquire information can be enhanced.

[0049] The agent service layer consists of one or more agents based on a large model, each undertaking specific decision-making responsibilities. Based on current execution information and task scheduling, the agent service layer outputs a FIFO (First Input First Output) queue for test case execution, partitioned by environment, using the large model. This queue includes agents for test case priority ranking and execution scheduling. Based on the agent service layer, multiple agents can parse dynamic text information such as test strategies and version bugs, and adjust the scheduling strategy in real time according to defined execution priority rules.

[0050] The scheduling and management layer is responsible for receiving user instructions, coordinating and driving all agents and working modules, and ultimately translating the strategies formulated by the agents into actual test execution actions. It includes a user interface module, a task scheduling module, and a test case execution module. Based on the scheduling and management layer, changes in task execution status can be proactively detected, and test case scheduling strategies can be adjusted in near real-time by invoking multiple agents.

[0051] Overall, the MCP service layer provides data support, the intelligent agent service layer performs decision analysis, and the scheduling management layer drives execution. Together, these three elements enable the dynamic and intelligent scheduling of test cases in this application.

[0052] This application provides a test case scheduling method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the test case scheduling method of this application.

[0053] In this embodiment, the test case scheduling method includes the following steps:

[0054] Step S10: When a test task to be executed is received from the user for the solid-state drive, the test cases to be executed contained in the test task to be executed are obtained.

[0055] It is understood that the above-mentioned test tasks to be performed can be any test tasks for solid-state drives, such as read and write performance test tasks, durability test tasks, reliability (such as temperature, voltage, abnormal power failure, etc.) test tasks, compatibility test tasks, etc., and this embodiment does not limit them.

[0056] In practice, all test cases to be executed in the test task to be executed can be obtained through the test case information MCP service. That is, the task ID of the test task to be executed is read through the test case information MCP service, and then all test cases to be executed in the test task to be executed are obtained according to the task ID.

[0057] Step S20: Mark the execution priority of the test cases to be executed according to the probability of defect occurrence of the test cases to be executed.

[0058] It should be noted that the above probability of defect occurrence represents the probability that the test case to be executed will be blocked due to the current legacy bug, such as 100% (i.e., it will definitely happen), 20% (i.e., there is a probability of it happening), etc.

[0059] It should be understood that the historical execution status of test cases can be obtained through the Execution Information MCP service, and the list of legacy issues for the current version can be obtained through the Defect Query MCP service. Then, based on the historical execution status of test cases and the list of legacy issues, the associated bug information corresponding to the test cases to be executed can be determined. Finally, the probability of defect occurrence for each test case to be executed can be determined based on the associated bug information.

[0060] In practice, bug information significantly impacts the execution priority of test cases. First, if legacy bugs persist, related test cases cannot be executed until they are fixed. Modules with a large number of historical bugs (a module can be understood as a collection of test cases), and where the bug trend across multiple versions does not show significant convergence, indicate that this module still has many issues and requires focused testing. Conversely, if there are many historical bugs but fewer issues in recent versions, it suggests relative stability, and complex test cases for this module can be prioritized to check for problems in certain scenarios.

[0061] Step S30: Query the available test environments under the current test version and the historical execution data of the test cases to be executed.

[0062] It should be noted that the available testing environment mentioned above refers to the environment that can support the execution of test cases under the current version, such as server information for executing test cases, including CPU / memory size / hard disk / network topology, etc. The historical execution data mentioned above refers to the execution data of the test cases to be executed in previous versions or at previous times.

[0063] In its specific implementation, this embodiment can query the available test environments under the current test version through the test environment query MCP service, and query the historical execution data of the test cases to be executed through the test case information MCP service.

[0064] Step S40: Schedule the test cases to be executed based on the execution priority, the available test environment, and the historical execution data.

[0065] Understandably, test cases typically specify environmental requirements. You can first use traditional keyword matching techniques to determine these requirements, then use a large model to assess and check multiple scenarios such as CPU, memory, hard disk, and network topology, combined with historical execution data, to obtain the target environment corresponding to the test cases to be executed. Finally, schedule the test cases to be executed in different target environments according to their execution priorities.

[0066] In this embodiment, when a user sends a test task to the solid-state drive, the method retrieves the test cases to be executed within the test task; it assigns execution priorities to the test cases based on their defect occurrence probabilities; it queries the available test environments under the current test version and the historical execution data of the test cases; and it schedules the test cases based on the execution priorities, the available test environments, and the historical execution data. This method determines the execution priorities of the test cases based on their defect occurrence probabilities, and then schedules them based on the available test environments under the current test version, the historical execution data, and the execution priorities. This allows for continuous monitoring of defect information and environmental changes during test execution to dynamically schedule test cases, effectively improving testing efficiency and resource utilization.

[0067] refer to Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the test case scheduling method of this application.

[0068] In one feasible implementation, step S20 may include:

[0069] Step S201: When the probability of the defect occurring in the test case to be executed is within the first probability interval, mark the execution priority of the test case to be executed according to the historical execution data of the test case to be executed and the preset priority standard.

[0070] It should be noted that the first probability interval mentioned above can be set by the user, for example, it can be set to (0%, 20%), and this embodiment does not limit it in this way.

[0071] It should be understood that the aforementioned historical execution data may include associated bug information and historical execution failure rates for test cases to be executed. Furthermore, the agent has multiple priority determination methods, such as bug information and version strategies. If different methods yield different priorities when judging a test case, how to handle the conflict requires judgment based on the execution priority label. Therefore, the aforementioned preset priority criteria can include the following: test cases that are guaranteed to be blocked by bugs should definitely not be executed; those specified as high priority in the test strategy should be executed first; based on the analysis of the module's historical bug changes, the next best priority should be executed; test cases within the same module should be further differentiated according to priority; finally, all test cases to be executed should be divided into different execution priorities, such as high, medium, and low. Among these, bugs in a test case will be associated with test cases, and the bug will have a probability of recurrence. If the bug is guaranteed to recur or has a high probability of recurrence, the test case will be blocked; the historical version execution record will also record which test cases were blocked by which bug.

[0072] Step S202: When the probability of the defect occurring in the test case to be executed is within the second probability interval, mark the execution priority of the test case to be executed according to the test strategy and preset priority standard under the current test version.

[0073] It should be noted that the above-mentioned second probability interval can be set by the user, for example, it can be set to (20%, 95%), and this embodiment does not limit it.

[0074] Understandably, the execution strategy for a version is generally formulated by the testing team before the start of the current testing round, based on the version's testing objectives and changes. Therefore, the testing strategy for the current test version can include which modules to test, which modules to focus on testing, and which modules need to execute basic test cases first.

[0075] Step S203: When the probability of the defect occurring in the test case to be executed is within the third probability interval, mark the execution priority of the test case to be executed as not to execute.

[0076] It should be noted that the aforementioned third probability interval can be set by the user, for example, it can be set to (95%, 100%), and this embodiment does not limit it in this way.

[0077] It should be understood that when the probability of a defect occurring falls within the third probability interval, it indicates that the corresponding test case to be executed will inevitably or with a high probability of bug reproduction. Therefore, the execution priority of the test case to be executed can be marked as not to be executed.

[0078] Furthermore, new issues may be exposed during testing, leading to more problems in related modules. Two approaches can be taken in this situation: For blocking bugs, the relevant test cases are no longer executed, as execution would inevitably block them, but the related module may contain more bugs requiring pre-testing; for non-reproducible issues, more problems may be discovered in the related module's test cases, requiring pre-testing, and these test cases can be classified as high-risk test cases. Specifically, high-risk test cases can be determined based on the following two criteria: First, use a large model to analyze the conditions for reproducing the blocking issue, and analyze the steps of the test cases to see if they meet the reproduction conditions. If they do, the relevant test cases are no longer executed and are marked as blocked. Second, use a large model to analyze whether the test cases and the newly added bug belong to the same module and whether they involve similar operations. The higher the similarity, the higher the risk, and the priority can be adjusted, allowing for testing earlier.

[0079] In one possible implementation, step S20 may be followed by:

[0080] Step S21: After all the execution priorities of the test cases to be executed are marked, determine whether there is any abnormality in the execution priorities.

[0081] In practical implementation, the following methods can be used to determine whether there are any anomalies in the execution priority: analyze whether the currently defined execution priority meets the priority criteria; analyze whether the currently defined execution priority annotation meets the test strategy; analyze whether the currently defined execution priority takes into account the impact of bugs; and analyze whether test cases that will inevitably block have been removed. When the execution priority meets the priority criteria, meets the test strategy, takes into account the impact of bugs, and removes test cases that will inevitably block, it can be determined that there are no anomalies in the execution priority; when the execution priority does not meet the priority criteria, does not meet the test strategy, does not take into account the impact of bugs, or does not remove test cases that will inevitably block, it can be determined that there are anomalies in the execution priority.

[0082] Step S22: If yes, return to the step of marking the execution priority of the test case to be executed according to the probability of defect occurrence of the test case to be executed, so as to re-mark the execution priority of the test case to be executed.

[0083] Step S23: If not, save the execution priority and execute the step of querying the available test environments under the current test version.

[0084] In this embodiment, when the probability of a defect occurring in the test case to be executed is within a first probability interval, the execution priority of the test case to be executed is marked according to the historical execution data of the test case to be executed and a preset priority standard; when the probability of a defect occurring in the test case to be executed is within a second probability interval, the execution priority of the test case to be executed is marked according to the test strategy under the current test version and a preset priority standard; when the probability of a defect occurring in the test case to be executed is within a third probability interval, the execution priority of the test case to be executed is marked as not to be executed; after all the execution priorities of the test cases to be executed are marked, it is determined whether there is an anomaly in the execution priority; if so, the step of marking the execution priority of the test case to be executed according to the probability of a defect occurring in the test case to be executed is returned to re-mark the execution priority of the test case to be executed; if not, the execution priority is saved, and the step of querying the available test environment under the current test version is executed. The method described in this embodiment can dynamically detect new defects in test cases, reducing the occurrence of environment lock-in problems caused by new defects; at the same time, based on real-time defect correlation analysis, high-risk test cases are executed first, improving the ability to expose bugs in the early stage of testing; in addition, this embodiment also adjusts the test priority in real time, prioritizing the test cases that are required to be tested first in the test strategy, thereby effectively ensuring the accuracy of the scheduling strategy and reducing problems caused by large model illusions.

[0085] refer to Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the test case scheduling method of this application.

[0086] In one feasible implementation, step S40 may include:

[0087] Step S401: Develop an execution strategy for the test cases to be executed based on the execution priority, the available test environment, and the historical execution data.

[0088] It should be noted that the above execution strategy indicates in what environment and in what order the test cases to be executed need to be executed.

[0089] Understandably, each test environment has multiple tags, and each test case also has a tag corresponding to the required test environment. The test case to be executed can be matched with an available test environment based on this tag. Furthermore, test cases within the same test environment can be merged for execution based on specified preparation conditions and optimized execution order, thereby reducing test environment preparation time.

[0090] Step S402: Generate a test case execution list corresponding to different test environments according to the execution strategy, and schedule the test cases to be executed through the test case execution list.

[0091] It should be noted that the above test case execution list may include the FIFO list corresponding to the test cases to be executed in each test environment.

[0092] In one feasible implementation, step S401 may include:

[0093] Step S4011: Determine the target test environment for the test cases to be executed based on the historical execution data.

[0094] Step S4012: Determine the environment allocation corresponding to the test case to be executed in the available test environment based on the target test environment.

[0095] It should be understood that, based on the target test environment, a test environment matching the test cases to be executed can be selected from the available test environments, thereby completing the environment allocation for the test cases to be executed.

[0096] Step S4013: Determine the execution order of the test cases to be executed in the available test environment according to the execution priority.

[0097] In practice, for test cases to be executed in the same test environment, their execution order in the test environment can be determined according to their respective execution priorities. The higher the priority of the test case to be executed, the earlier it will be executed.

[0098] Step S4014: Formulate the execution strategy for the test cases to be executed based on the environment allocation and the execution order.

[0099] Understandably, each test case to be executed has already been marked with an execution priority in the previous steps. Now, it is necessary to collect the target test environment and the currently available test environment for each test case. For example, if test case 1 requires environment A, test case 2 requires environment B, and test case 3 requires environment A, then test cases 1 and 3 are placed in the environment A category. Test cases in the same environment are set to execute in the order of execution and environment allocation according to the already set execution priority and version test strategy.

[0100] In one feasible implementation, step S401 may be followed by:

[0101] Step S401a: If the execution strategy fails the check, return to the step of formulating the execution strategy for the test case to be executed based on the execution priority, the available test environment and the historical execution data, so as to reformulate the execution strategy for the test case to be executed.

[0102] Step S401b: If the execution strategy passes the check, save the execution strategy and execute the step of generating the test case execution list corresponding to different test environments based on the execution strategy.

[0103] This embodiment determines the target test environment for the test cases to be executed based on the historical execution data; determines the environment allocation corresponding to the test cases to be executed in the available test environments based on the target test environment; determines the execution order of the test cases to be executed in the available test environments based on the execution priority; formulates an execution strategy for the test cases to be executed based on the environment allocation and the execution order; generates a test case execution list corresponding to different test environments based on the execution strategy, and schedules the test cases to be executed through the test case execution list; if the execution strategy fails the check, the step of formulating the execution strategy for the test cases to be executed based on the execution priority, the available test environments, and the historical execution data is returned to redefine the execution strategy for the test cases to be executed; if the execution strategy passes the check, the execution strategy is saved, and the step of generating a test case execution list corresponding to different test environments based on the execution strategy is executed. Compared to existing technologies that rely on manual estimation to determine whether the current PID control parameters are optimal, the method described in this embodiment reduces test environment lock-up caused by known issues and improves test resource utilization. At the same time, by accurately matching the test environment with test cases, execution waiting caused by resource mismatch is eliminated, thereby reducing the preparation time for test case preset conditions.

[0104] Reference Figure 5 , Figure 5 This is a structural block diagram of the first embodiment of the test case scheduling device of this application.

[0105] like Figure 5 As shown, the test case scheduling device proposed in this application includes:

[0106] The test case acquisition module 501 is used to acquire the test cases to be executed contained in the test task to be executed when it receives a test task to be executed sent by a user to the solid-state drive.

[0107] The priority labeling module 502 is used to label the execution priority of the test cases to be executed according to the probability of defect occurrence of the test cases to be executed;

[0108] Information query module 503 is used to query the available test environments under the current test version and the historical execution data of the test cases to be executed;

[0109] The test case scheduling module 504 is used to schedule the test cases to be executed based on the execution priority, the available test environment, and the historical execution data.

[0110] In this embodiment, when a user sends a test task to the solid-state drive, the method retrieves the test cases to be executed within the test task; it assigns execution priorities to the test cases based on their defect occurrence probabilities; it queries the available test environments under the current test version and the historical execution data of the test cases; and it schedules the test cases based on the execution priorities, the available test environments, and the historical execution data. This method determines the execution priorities of the test cases based on their defect occurrence probabilities, and then schedules them based on the available test environments under the current test version, the historical execution data, and the execution priorities. This allows for continuous monitoring of defect information and environmental changes during test execution to dynamically schedule test cases, effectively improving testing efficiency and resource utilization.

[0111] Based on the first embodiment of the test case scheduling device described in this application, a second embodiment of the test case scheduling device of this application is proposed.

[0112] In this embodiment, the priority labeling module 502 is further configured to: label the execution priority of the test case to be executed according to the historical execution data of the test case to be executed and the preset priority standard when the probability of the defect occurrence of the test case to be executed is within the first probability interval; label the execution priority of the test case to be executed according to the test strategy under the current test version and the preset priority standard when the probability of the defect occurrence of the test case to be executed is within the second probability interval; and label the execution priority of the test case to be executed as not to be executed when the probability of the defect occurrence of the test case to be executed is within the third probability interval.

[0113] Furthermore, the priority labeling module 502 is also used to determine whether there is an anomaly in the execution priority after all the execution priorities of the test cases to be executed have been labeled; if so, the step of labeling the execution priority corresponding to the test cases to be executed according to the probability of defect occurrence of the test cases to be executed is returned to re-label the execution priority of the test cases to be executed; if not, the execution priority is saved and the step of querying the available test environment under the current test version is executed.

[0114] Furthermore, the test case scheduling module 504 is also used to formulate an execution strategy for the test cases to be executed based on the execution priority, the available test environment, and the historical execution data; generate a test case execution list corresponding to different test environments according to the execution strategy; and schedule the test cases to be executed through the test case execution list.

[0115] Furthermore, the test case scheduling module 504 is also used to determine the target test environment of the test case to be executed based on the historical execution data; determine the environment allocation corresponding to the test case to be executed in the available test environment according to the target test environment; determine the execution order of the test case to be executed in the available test environment according to the execution priority; and formulate the execution strategy of the test case to be executed based on the environment allocation and the execution order.

[0116] Furthermore, the test case scheduling module 504 is also configured to, if the execution strategy fails the check, return to the step of formulating the execution strategy for the test cases to be executed based on the execution priority, the available test environment, and the historical execution data, so as to re-formulate the execution strategy for the test cases to be executed; if the execution strategy passes the check, save the execution strategy and execute the step of generating the test case execution list corresponding to different test environments based on the execution strategy.

[0117] Other embodiments or specific implementations of the test case scheduling device of this application can be found in the above-described method embodiments, and will not be repeated here.

[0118] This application provides a test case scheduling device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the test case scheduling method in Embodiment 1 above.

[0119] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a test case scheduling device suitable for implementing embodiments of this application. The test case scheduling device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 6The test case scheduling device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0120] like Figure 6 As shown, the test case scheduling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the test case scheduling device. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. Input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the test case scheduling device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a test case scheduling device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0121] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0122] The test case scheduling device provided in this application, employing the test case scheduling method in the above embodiments, can solve the technical problem of how to effectively improve the testing efficiency and test resource utilization in the testing process. Compared with the prior art, the beneficial effects of the test case scheduling device provided in this application are the same as those of the test case scheduling method provided in the above embodiments, and other technical features in this test case scheduling device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0123] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0124] 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.

[0125] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the test case scheduling method in the above embodiments.

[0126] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0127] The aforementioned computer-readable storage medium may be included in the test case scheduling device; or it may exist independently and not be assembled into the test case scheduling device.

[0128] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a test case scheduling device, enable the test case scheduling device to write computer program code for performing the operations of this application in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++; and also conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, such as a local area network (LAN) or a wide area network (WAN), or connected to an external computer (e.g., via the Internet using an Internet service provider).

[0129] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0130] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0131] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described test case scheduling method. This solves the technical problem of how to effectively improve the testing efficiency and resource utilization of the testing process. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the test case scheduling method provided in the above embodiments, and will not be repeated here.

[0132] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the test case scheduling method described above.

[0133] The computer program product provided in this application can solve the technical problem of test case scheduling. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the test case scheduling method provided in the above embodiments, and will not be repeated here.

[0134] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A test case scheduling method, characterized in that, The method includes the following steps: When a user sends a test task to be executed for a solid-state drive, the test cases to be executed contained in the test task are obtained; The execution priority of each test case is assigned based on the probability of its defect occurrence. Query the available test environments and historical execution data of the test cases to be executed under the current test version; The test cases to be executed are scheduled based on the execution priority, the available test environment, and the historical execution data.

2. The test case scheduling method as described in claim 1, characterized in that, The step of marking the execution priority of the test cases to be executed according to the probability of defect occurrence of the test cases to be executed includes: When the probability of the defect occurring in the test case to be executed is within the first probability interval, the execution priority of the test case to be executed is marked according to the historical execution data of the test case to be executed and the preset priority standard; When the probability of the defect occurring in the test case to be executed is within the second probability interval, the execution priority of the test case to be executed is marked according to the test strategy and preset priority standard under the current test version. When the probability of a defect occurring in the test case to be executed is within the third probability interval, the execution priority corresponding to the test case to be executed is marked as not to be executed.

3. The test case scheduling method as described in claim 2, characterized in that, After the step of marking the execution priority of the test cases to be executed according to the probability of defect occurrence of the test cases to be executed, the method further includes: After all the execution priorities of the test cases to be executed have been marked, determine whether there are any abnormalities in the execution priorities; If so, return to the step of marking the execution priority of the test case to be executed according to the probability of defect occurrence of the test case to be executed, so as to re-mark the execution priority of the test case to be executed; If not, save the execution priority and execute the step of querying the available test environments under the current test version.

4. The test case scheduling method as described in claim 1, characterized in that, The step of scheduling the test cases to be executed based on the execution priority, the available test environment, and the historical execution data includes: The execution strategy for the test cases to be executed is formulated based on the execution priority, the available testing environment, and the historical execution data. Based on the execution strategy, a test case execution list is generated for different test environments, and the test cases to be executed are scheduled using the test case execution list.

5. The test case scheduling method as described in claim 4, characterized in that, The step of formulating the execution strategy for the test cases to be executed based on the execution priority, the available testing environment, and the historical execution data includes: The target test environment for the test cases to be executed is determined based on the historical execution data. Based on the target test environment, determine the environment allocation corresponding to the test cases to be executed in the available test environments; The execution order of the test cases to be executed in the available test environment is determined according to the execution priority. The execution strategy for the test cases to be executed is formulated based on the environment allocation and the execution order.

6. The test case scheduling method as described in claim 5, characterized in that, Following the step of formulating the execution strategy for the test cases to be executed based on the execution priority, the available testing environment, and the historical execution data, the method further includes: If the execution strategy fails the check, the process returns to the step of formulating the execution strategy for the test cases to be executed based on the execution priority, the available test environment, and the historical execution data, so as to reformulate the execution strategy for the test cases to be executed. If the execution strategy passes the check, the execution strategy is saved, and the step of generating the test case execution list corresponding to different test environments based on the execution strategy is executed.

7. A test case scheduling device, characterized in that, The test case scheduling device includes: The test case acquisition module is used to acquire the test cases to be executed contained in the test task to be executed when it receives a test task to be executed from a user for a solid-state drive. The priority labeling module is used to label the execution priority of the test cases to be executed according to the probability of defect occurrence of the test cases to be executed; The information query module is used to query the available test environments under the current test version and the historical execution data of the test cases to be executed; The test case scheduling module is used to schedule the test cases to be executed based on the execution priority, the available test environment, and the historical execution data.

8. A test case scheduling device, characterized in that, The device includes: a memory, a processor, and a test case scheduler stored in the memory and executable on the processor, the test case scheduler being configured to implement the steps of the test case scheduling method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a test case scheduler is stored on the storage medium. When the test case scheduler is executed by a processor, it implements the steps of the test case scheduling method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a test case scheduler, which, when executed by a processor, implements the steps of the test case scheduling method as described in any one of claims 1 to 6.

Images