Software testing method and device, electronic equipment and storage medium
By dynamically adjusting the priority of software test cases, the problems of low testing efficiency and insufficient adaptability in traditional testing methods are solved, achieving more efficient and accurate software testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- LCFC HEFEI ELECTRONICS TECH
- Filing Date
- 2026-02-04
- Publication Date
- 2026-06-26
Smart Images
Figure CN122285485A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of testing technology, and in particular to a software testing method, apparatus, electronic device, and storage medium. Background Technology
[0002] In today's rapidly evolving software industry, software testing, as a crucial link in ensuring software quality, is becoming increasingly important. Traditional automated software testing methods mostly employ fixed test strategies and test case execution sequences. This prevents prioritizing testing of modules or functions more prone to problems, resulting in low testing efficiency and difficulty in quickly identifying defects. Furthermore, with continuous software updates and iterations, fixed test strategies and test cases cannot adapt to changes in a timely manner, impacting the accuracy and comprehensiveness of testing and failing to meet the ever-increasing demands for software quality assurance. Summary of the Invention
[0003] This application provides a software testing method, apparatus, electronic device, and storage medium to at least solve the above-mentioned technical problems existing in the prior art.
[0004] A first aspect of this application provides a software testing method, the method comprising:
[0005] Obtain multiple types of test cases for the software under test and the initial priority of each test case; each test case includes multiple sub-test cases. Execute at least some of the test sub-cases in each test case to obtain execution result data and execution process data for at least some of the test sub-cases; Based on the execution result data and execution process data corresponding to each test sub-case, determine the priority adjustment value of the corresponding test case; Based on the initial priority and priority adjustment value corresponding to each test case, the target priority of the corresponding test case is determined; the target priority is used to characterize the execution order of the test cases. Based on the execution order of each test case, multiple types of test cases are executed to obtain the test results of the software under test; the test results of the software are used to characterize the performance of the software.
[0006] In one implementation, when the execution result data indicates that a test sub-case has a defect, the execution process data includes the current defect severity and the historical average defect severity; based on the execution result data and execution process data corresponding to each test sub-case, the priority adjustment value of the corresponding test case is determined, including: Obtain the preset defect adjustment coefficients for various test cases; Based on the current defect severity, the historical average defect severity, and the defect adjustment coefficient, determine the priority adjustment value for the corresponding test cases.
[0007] In one possible implementation, when the execution result data indicates that the test sub-case has no defects but the execution time exceeds a first preset threshold, the execution process data includes the current execution time and the historical average execution time; based on the execution result data and execution process data corresponding to each test sub-case, the priority adjustment value of the corresponding test case is determined, including: Obtain preset time adjustment coefficients for various test cases; Based on the current execution time, the historical average execution time, and the time adjustment factor, determine the priority adjustment value for the corresponding test cases.
[0008] In one possible implementation, multiple types of test cases for the software under test and the initial priority of each test case are obtained, including: Obtain the test cases for the software under test and the test types corresponding to each test case; Based on the test type, determine the priority parameters for each type of test case; Based on priority-related parameters, the initial priority of each test case is determined.
[0009] In one possible implementation, the execution process data includes the current response time and the upper limit response time; based on the execution result data and execution process data corresponding to each test sub-case, the priority adjustment value of the corresponding test case is determined, including: Obtain preset real-time adjustment coefficients for various test cases; Based on the current response time, the upper limit response time, and the real-time adjustment coefficient, determine the priority adjustment value for the corresponding test cases.
[0010] In one possible implementation, multiple types of test cases are executed according to the execution order of each test case to obtain the test results of the software under test, including: Based on the execution order of each test case, each test sub-test case in each test case is executed at least once. When the test parameters for the test sub-test case meet the preset conditions, the test results of the software under test are obtained. The test parameters for the test sub-test case include the total number of times the test sub-test case is executed, the total number of defects in the test sub-test case, and the total test time of the test sub-test case.
[0011] In one implementation, priority-related parameters include code complexity factor, historical defect rate factor, and functional importance factor.
[0012] A second aspect of this application provides a software testing apparatus, the apparatus comprising: The first acquisition unit is used to acquire multiple types of test cases for the software under test and the initial priority of each test case; the test cases include multiple test sub-test cases. The second acquisition unit is used to execute at least some of the test sub-cases in each test case to obtain execution result data and execution process data for at least some of the test sub-cases. The first determining unit is used to determine the priority adjustment value of the corresponding test cases based on the execution result data and execution process data corresponding to each test sub-test case. The second determining unit is used to determine the target priority of each test case based on the initial priority and priority adjustment value corresponding to each test case; the target priority is used to characterize the execution order of the test cases. The third acquisition unit is used to execute multiple types of test cases according to the execution order of each test case to obtain the test results of the software under test; the test results of the software are used to characterize the performance of the software.
[0013] A third aspect of this application provides an electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by at least one processor, which enables the at least one processor to perform the method of this application.
[0014] A fourth aspect of this application provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method of this application.
[0015] This application involves obtaining multiple types of test cases for the software under test and their corresponding initial priorities. Each test case includes multiple sub-test cases. At least a portion of the sub-test cases within each test case are executed, yielding execution result data and execution process data for each sub-test case. Based on the execution result data and execution process data for each sub-test case, the priority adjustment value for the corresponding test case is determined. Based on the initial priority and priority adjustment value for each test case, the target priority for the corresponding test case is determined. The target priority is used to characterize the execution order of the test cases. Based on the execution order of each test case, multiple types of test cases are executed to obtain the test results for the software under test. The test results are used to characterize the performance of the software. This application, by executing the sub-test cases within each test case and readjusting the priorities of various test cases based on the executed data, can prioritize the execution of test cases more valuable for discovering software defects, thereby improving the efficiency and accuracy of software testing. In addition, due to the clustering distribution characteristics of software defects, serious defects are often concentrated in specific modules, and some sub-test cases can almost cover the core path. The execution process data (time consumption, resource consumption, exception throwing, etc.) can also indicate the overall complexity and potential defect density of such test cases. Therefore, this embodiment can further improve testing efficiency and reduce unnecessary computing power consumption by executing at least some test sub-test cases to determine the priority adjustment value.
[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description
[0017] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of this application are illustrated in the drawings by way of example and not limitation, in which: In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts.
[0018] Figure 1 A schematic diagram illustrating the implementation flow of the software testing method according to an embodiment of this application is shown; Figure 2 This paper illustrates a schematic diagram of the application process of the software testing method according to an embodiment of this application; Figure 3 A schematic diagram of the composition structure of the software testing apparatus according to an embodiment of this application is shown; Figure 4 A schematic diagram of the composition structure of an electronic device according to an embodiment of this application is shown. Detailed Implementation
[0019] To make the objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] This application provides a software testing method that can be applied to electronic devices, such as PCs, servers, etc. Figure 1 and Figure 2 As shown, the method includes: S101: The electronic device obtains multiple test cases for the software under test and the initial priority of each test case; the test cases include multiple test sub-cases.
[0021] In this step, a test case is a set of inputs, execution conditions, and expected results designed to verify whether the software meets specific requirements or functions. In simpler terms, by executing test cases and comparing the software's execution results with the expected results, the quality of the software is determined. To ensure the comprehensiveness and accuracy of software testing, test cases typically include multiple types. For example, in practical applications, when the software is a company expense control software, the test cases may include expense-related types such as user authentication, travel application, reimbursement, and financial settlement. The initial priority of each type of test case can be customized, such as setting all test cases to the same initial priority. Alternatively, based on whether the test purpose of each test case targets the core functions of the software, the initial priority of test cases targeting the core functions can be set to a higher priority, and the initial priority of other test cases can be set to a lower priority. It should be noted that the determination of the initial priority of various test cases in this application includes, but is not limited to, the two methods mentioned above, and will not be enumerated further in this embodiment.
[0022] S102: The electronic device executes at least some of the test sub-cases in each test case to obtain execution result data and execution process data for at least some of the test sub-cases.
[0023] In this application, each type of test case includes at least one test sub-test case. In this embodiment, for each type of test case, some test sub-test cases under that test case can be executed, or all test sub-test cases under that test case can be executed. Specifically, test sub-test cases are usually composed of scripts or code. The software reads the running data or execution steps included in the script or code, calls the interface to execute the corresponding steps, and finally obtains the execution result data and execution process data for each executed test sub-test case by capturing the return value or page. Among them, the execution result data represents the output result after the software executes the test sub-test case, and the execution process data represents the process data of the software executing the test sub-test case. For example, when the test sub-test case is the aforementioned user authentication type sub-test case, the execution result data can be whether the user can log in normally after entering the correct username and password, that is, whether the login success interface can be displayed. Correspondingly, the execution process data can be the time when the login success interface is displayed after the user enters the correct username and password.
[0024] S103: The electronic device determines the priority adjustment value of the corresponding test cases based on the execution result data and execution process data corresponding to each test sub-case.
[0025] In this application, a priority adjustment value corresponding to the execution result data and execution process data can be found and determined according to a preset mapping relationship table. The mapping relationship table represents the one-to-one correspondence between the priority adjustment value and the execution result data and execution process data. For example, continuing with the aforementioned user authentication type test case, when the execution result data shows that the login success interface pops up after the user enters the correct username and password, and the execution process data indicates that the pop-up page takes less than 3 seconds, the priority adjustment value is 0; when the execution result data shows that the login success interface pops up after the user enters the correct username and password, and the execution process data indicates that the pop-up page takes 5 to 10 seconds, the priority adjustment value is +5; when the execution result data shows that the login success interface does not pop up after the user enters the correct username and password, the priority adjustment value is +10. When there are multiple test sub-test cases participating in the execution of various test cases, the priority adjustment value of each type of test case can be determined by averaging the priority adjustment values corresponding to the execution result data and execution process data of each test sub-test case.
[0026] S104: The electronic device determines the target priority of each test case based on the initial priority and priority adjustment value corresponding to each test case; the target priority is used to characterize the execution order of the test cases.
[0027] In this step, the initial priority and the priority adjustment value are added together to obtain the target priority for each type of test case. The priority adjustment value can be positive or negative. A positive number indicates that the target priority is obtained by adding to the initial priority. A negative number indicates that the target priority is obtained by subtracting from the initial priority. It can be understood that in this embodiment, a larger target priority value indicates that the test case is more valuable for discovering software defects. A smaller target priority value indicates that the test case is less important for discovering software defects.
[0028] S105: Electronic devices execute multiple test cases according to the execution order of each test case to obtain the test results of the software under test; the test results of the software are used to characterize the performance of the software.
[0029] In this application, as described above, the target priority value reflects the value of various test cases in discovering software defects. Therefore, this embodiment determines the execution order of various test cases based on the target priority; for example, the higher the target priority, the earlier the execution order; and the lower the target priority, the later the execution order. The software executes various test cases according to their target priorities and the execution order indicated by those priorities, effectively shortening the software testing time and improving the accuracy of software testing. The software test results are reflected in the execution results of various test cases. If the number of results that do not match the expected results exceeds a preset performance standard value, the software test results indicate that the software performance is unqualified and requires further improvement and optimization. If the number of results that do not match the expected results is lower than or equal to the preset performance standard value, the software test results indicate that the software performance is qualified and can be shipped for use.
[0030] In the scheme shown in steps S101-S105, multiple types of test cases for the software under test and their corresponding initial priorities are obtained. Each test case includes multiple sub-test cases. At least some of the sub-test cases in each test case are executed to obtain execution result data and execution process data for each sub-test case. Based on the execution result data and execution process data corresponding to each sub-test case, the priority adjustment value of the corresponding test case is determined. Based on the initial priority and priority adjustment value of each test case, the target priority of the corresponding test case is determined. The target priority is used to characterize the execution order of the test cases. According to the execution order of each test case, multiple types of test cases are executed to obtain the test results for the software under test. The test results of the software are used to characterize the performance of the software. This application, by executing sub-test cases in various types of test cases and redetermining and adjusting the priorities of various types of test cases based on the data after execution, can prioritize the execution of test cases that are more valuable for discovering software defects, thereby improving the efficiency and accuracy of software testing.
[0031] In some alternative solutions, when the execution result data indicates that a test sub-case has a defect, the execution process data includes the current defect severity and the historical average defect severity. Based on the execution result data and execution process data corresponding to each test sub-case, the priority adjustment value of the corresponding test case is determined, including: Obtain the preset defect adjustment coefficients for various test cases; Based on the current defect severity, the historical average defect severity, and the defect adjustment coefficient, determine the priority adjustment value for the corresponding test cases.
[0032] In this application, the execution result data includes two types of results: one indicating the presence of a defect, and the other indicating the absence of a defect. The presence of a defect indicates that the software's output for the test sub-case does not match the expected result, while the absence of a defect indicates that the software's output for the test sub-case matches the expected result. When the execution result data indicates that the test sub-case has a defect, the execution process data includes the current defect severity and the historical average defect severity. The defect severity indicates the degree to which the defect in the test sub-case affects the software's functionality. For example, when the test sub-case is a login function, a defect severity of 1 corresponds to typos on the login page; a defect severity of 2 corresponds to the default prompt text on the login page not being automatically cleared after entering the username; a defect severity of 3 corresponds to bypassing the login page and entering the backend by replaying with any password; and a defect severity of 4 corresponds to the database being locked after 5 consecutive login attempts, preventing all users from accessing the system. The historical average defect severity is the average defect severity that has occurred in this type of test sub-case.
[0033] When the execution result data indicates that a test sub-case has a defect, the priority adjustment value is determined based on the current defect severity and the historical average defect severity of the test sub-case. Specifically, the priority adjustment value for each type of test case can be calculated using formula (1): Formula (1) in, This indicates the priority adjustment value. To test the current defect level of the sub-test case. This represents the historical average defect severity of this type of test case. This is a preset defect adjustment coefficient for various test cases, which is an empirical value and is usually set between 0.05 and 0.2. This indicates that the priority adjustment value is positive. It assigns higher priority rewards to test sub-cases with more severe or unexpected defects, automatically allocating subsequent testing resources to high-risk areas and prioritizing test sub-cases more prone to problems, thereby improving the detection rate of software testing.
[0034] In some optional solutions, when the execution result data indicates that the test sub-case has no defects but the execution time exceeds a first preset threshold, the execution process data includes the current execution time and the historical average execution time; based on the execution result data and execution process data corresponding to each test sub-case, the priority adjustment value of the corresponding test case is determined, including: Obtain preset time adjustment coefficients for various test cases; Based on the current execution time, the historical average execution time, and the time adjustment factor, determine the priority adjustment value for the corresponding test cases.
[0035] In this application, a preset threshold is set for the execution time of test sub-cases. When the execution result data indicates that the test sub-case has no defects but the execution time exceeds the first preset threshold, that is, although the execution result data indicates that the software output results for the test sub-case are consistent with the expected results, the execution time of the test sub-case is long, the priority adjustment value of various test cases is calculated by formula (2): Formula (2) in, This indicates the priority adjustment value. This is the current execution time of the test sub-case. This represents the historical average execution time of this type of test case. This is a preset time adjustment coefficient for various test cases, based on experience, and typically set between 0.05 and 0.2. By identifying test sub-cases that are defect-free but take a long time to execute, their priority can be dynamically reduced, avoiding wasting excessive resources in subsequent test cycles.
[0036] In some optional solutions, multiple types of test cases for the software under test and the initial priority of each test case are obtained, including: Obtain the test cases for the software under test and the test types corresponding to each test case; Based on the test type, determine the priority parameters for each type of test case; Based on priority-related parameters, the initial priority of each test case is determined.
[0037] Furthermore, in some alternative schemes, priority-related parameters include code complexity factor, historical defect rate factor, and feature importance factor.
[0038] In this application, the initial priority of various test cases of the software is calculated based on priority-related parameters. Among them, priority-related parameters include code complexity factor, historical defect rate factor and functional importance factor, as well as code complexity, historical defect rate and functional importance corresponding to various test cases. It can be understood that code complexity represents the complexity of the script / code corresponding to various test cases; historical defect rate represents the probability of defects appearing in various test cases in the past multiple tests; functional importance represents the test importance of the software function corresponding to various test cases, that is, whether the test function corresponding to various test cases is the core function of the software. Different types of test cases have different code complexity, historical defect rate and functional importance. Among them, code complexity and functional importance can be customized by software developers according to the development difficulty, and historical defect rate can be determined based on the execution results of various test cases in the past multiple tests. The sum of code complexity factor, historical defect rate factor and functional importance factor is 1, and its specific value can be set according to actual needs. The initial priority W corresponding to various test cases is calculated according to formula (3): Formula (3) = Code complexity factor × code complexity + historical defect rate factor × historical defect rate + function importance factor × function importance It can comprehensively determine the initial priority of various test cases (test cases of the same type have the same initial priority) by integrating multi-dimensional data, so as to ensure the rationality and comprehensiveness of subsequent resource allocation.
[0039] In some optional solutions, the execution process data includes the current response time and the maximum response time; based on the execution result data and execution process data corresponding to each test sub-case, the priority adjustment value of the corresponding test case is determined, including: Obtain preset real-time adjustment coefficients for various test cases; Based on the current response time, the upper limit response time, and the real-time adjustment coefficient, determine the priority adjustment value for the corresponding test cases.
[0040] In this application, the execution process data may also include the current response time and the upper limit response time of the test sub-case. The current response time represents the response time of the software currently executing the test sub-case; the upper limit response time represents the maximum tolerable response time without affecting the user's experience of using the software. The priority adjustment values for various test cases can also be calculated using formula (4): θ Formula (4) in, This indicates the priority adjustment value. θ is the real-time adjustment coefficient, typically between 0.1 and 0.3. This is the maximum response time. This represents the current response time. The real-time adjustment coefficient can be customized by software developers based on actual software needs. The current response time can be calculated in real-time using devices such as timers, while the upper limit response time can be determined based on empirical values. It's understandable that for software with real-time requirements, response speed has a significant impact on software performance. This embodiment, by introducing the response time dimension, allows the software to prioritize testing sub-test cases with higher real-time requirements, ensuring timely software response.
[0041] In some alternative solutions, multiple types of test cases are executed according to the execution order of each test case to obtain the test results of the software under test, including: Based on the execution order of each test case, each test sub-test case in each test case is executed at least once. When the test parameters for the test sub-test case meet the preset conditions, the test results of the software under test are obtained. The test parameters for the test sub-test case include the total number of times the test sub-test case is executed, the total number of defects in the test sub-test case, and the total test time of the test sub-test case.
[0042] Combination Figure 2 As shown in this application, the execution order of each test case is determined by the target priority. The software prioritizes the execution of test cases with higher target priorities. Each test sub-case can be executed once or multiple times. Specifically, each test sub-case can be executed once sequentially according to the target priority of its category. If the test parameters of the test case do not meet the preset conditions after one round, the test sub-cases are iteratively executed in a second, third, ... Nth round until the test parameters meet the preset conditions. The test parameters include the total number of executions of the test sub-cases, the total number of defects in the test sub-cases, and the total test time of the test sub-cases. The preset conditions include: the total number of executions of the test sub-cases equals the execution count threshold, the total number of defects in the test sub-cases equals the defect count threshold, and the total test time of the test sub-cases equals the test time threshold. Multiple test parameters can be used in combination or individually. This allows for the simultaneous controllability of risk, cost, and time, while achieving efficient software testing.
[0043] This application also provides a software testing device, such as... Figure 3 As shown, the device includes: The first acquisition unit 301 is used to acquire multiple types of test cases for the software under test and the initial priority of each test case; the test cases include multiple test sub-test cases. The second acquisition unit 302 is used to execute at least some of the test sub-cases in each test case to obtain execution result data and execution process data for at least some of the test sub-cases. The first determining unit 303 is used to determine the priority adjustment value of the corresponding test case based on the execution result data and execution process data corresponding to each test sub-test case. The second determining unit 304 is used to determine the target priority of each test case based on the initial priority and priority adjustment value corresponding to each test case; the target priority is used to characterize the execution order of the test cases. The third acquisition unit 305 is used to execute multiple types of test cases according to the execution order of each test case to obtain the test results of the software under test; the test results of the software are used to characterize the performance of the software.
[0044] In some alternative solutions, when the execution result data indicates that the test sub-case has a defect, the execution process data includes the current defect level and the historical average defect level; the first determining unit 303 is used to obtain the preset defect adjustment coefficient for various types of test cases; and based on the current defect level, the historical average defect level and the defect adjustment coefficient, the priority adjustment value of the corresponding test case is determined.
[0045] In some optional solutions, when the execution result data indicates that the test sub-case has no defects but the execution time exceeds the first preset threshold, the execution process data includes the current execution time and the historical average execution time; the first determining unit 303 is used to obtain the preset time adjustment coefficient for various types of test cases; and based on the current execution time, the historical average execution time and the time adjustment coefficient, the priority adjustment value of the corresponding test case is determined.
[0046] In some optional solutions, the first acquisition unit 301 is used to acquire the test cases of the software under test and the test types corresponding to each test case; based on the test types, determine the priority-related parameters for each type of test case; and based on the priority-related parameters, determine the initial priority corresponding to each test case.
[0047] In some alternative solutions, the execution process data includes the current response time and the upper limit response time; the first determining unit 303 is used to obtain the preset real-time adjustment coefficients for various test cases; and based on the current response time, the upper limit response time, and the real-time adjustment coefficients, to determine the priority adjustment value of the corresponding test case.
[0048] In some optional solutions, the third acquisition unit 305 is used to execute each test sub-case in each test case at least once according to the execution order of each test case. When the test parameters for the test sub-case meet the preset conditions, the test result of the software under test is obtained. The test parameters for the test sub-case include the total number of executions of the test sub-case, the total number of defects in the test sub-case, and the total test time of the test sub-case.
[0049] In some alternatives, priority-related parameters include code complexity factor, historical defect rate factor, and feature importance factor.
[0050] It should be noted that the software testing device in this application embodiment solves the problem in a similar way to the aforementioned software testing method. Therefore, the implementation process, implementation principle, and beneficial effects of the software testing device can be found in the description of the implementation process, implementation principle, and beneficial effects of the aforementioned method, and will not be repeated.
[0051] According to embodiments of this application, this application also provides an electronic device and a readable storage medium.
[0052] Figure 4 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.
[0053] like Figure 4 As shown, device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage unit 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.
[0054] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0055] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as software testing methods. For example, in some embodiments, the software testing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the software testing method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform software testing methods by any other suitable means (e.g., by means of firmware).
[0056] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.
[0057] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0058] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on 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 of the foregoing.
[0059] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0060] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0061] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.
[0062] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.
[0063] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.
[0064] 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.
Claims
1. A software testing method, characterized in that, The method includes: Obtain multiple types of test cases for the software under test and the initial priority of each test case; the test cases include multiple test sub-cases. Execute at least some of the test sub-cases in each test case to obtain execution result data and execution process data for the at least some test sub-cases; Based on the execution result data and execution process data corresponding to each test sub-case, the priority adjustment value of the corresponding test case is determined; Based on the initial priority and priority adjustment value corresponding to each test case, the target priority of the corresponding test case is determined; the target priority is used to characterize the execution order of the test cases. According to the execution order of each test case, the multiple types of test cases are executed to obtain the test results of the software under test; the test results of the software are used to characterize the performance of the software.
2. The software testing method according to claim 1, characterized in that, When the execution result data indicates that there is a defect in the test sub-case, the execution process data includes the current defect severity and the historical average defect severity. The determination of the priority adjustment value for each test case based on the execution result data and execution process data corresponding to each test sub-case includes: Obtain the preset defect adjustment coefficients for various test cases; Based on the current defect severity, the historical average defect severity, and the defect adjustment coefficient, determine the priority adjustment value for the corresponding test cases.
3. The software testing method according to claim 1 or 2, characterized in that, When the execution result data indicates that the test sub-case has no defects but the execution time exceeds a first preset threshold, the execution process data includes the current execution time and the historical average execution time; The determination of the priority adjustment value for each test case based on the execution result data and execution process data corresponding to each test sub-case includes: Obtain preset time adjustment coefficients for various test cases; Based on the current execution time, the historical average execution time, and the time adjustment factor, determine the priority adjustment value for the corresponding test cases.
4. The software testing method according to claim 1 or 2, characterized in that, The acquisition of multiple test cases for the software under test and the initial priority of each test case includes: Obtain the test cases for the software under test and the test types corresponding to each test case; Based on the test type, determine the priority parameters for each type of test case; Based on the priority-related parameters, the initial priority of each test case is determined.
5. The software testing method according to claim 1, characterized in that, The execution process data includes the current response time and the maximum response time. The determination of the priority adjustment value for each test case based on the execution result data and execution process data corresponding to each test sub-case includes: Obtain preset real-time adjustment coefficients for various test cases; Based on the current response time, the upper limit response time, and the real-time adjustment coefficient, determine the priority adjustment value for the corresponding test cases.
6. The software testing method according to claim 1 or 5, characterized in that, The process of executing the multiple types of test cases according to their execution order to obtain test results for the software under test includes: Based on the execution order of each test case, each test sub-test case in each test case is executed at least once. When the test parameters for the test sub-test case meet the preset conditions, the test result for the software under test is obtained. The test parameters for the test sub-test case include the total number of executions of the test sub-test case, the total number of defects in the test sub-test case, and the total test time of the test sub-test case.
7. The software testing method according to claim 4, characterized in that, The priority-related parameters include code complexity factor, historical defect rate factor, and functional importance factor.
8. A software testing apparatus, characterized in that, The device includes: The first acquisition unit is used to acquire multiple types of test cases for the software under test and the initial priority of each test case; the test cases include multiple test sub-test cases. The second acquisition unit is used to execute at least some of the test sub-cases in each test case to obtain execution result data and execution process data for the at least some test sub-cases. The first determining unit is used to determine the priority adjustment value of the corresponding test case based on the execution result data and execution process data corresponding to each test sub-test case. The second determining unit is used to determine the target priority of each test case based on the initial priority and priority adjustment value corresponding to each test case; the target priority is used to characterize the execution order of the test cases. The third acquisition unit is used to execute the multiple types of test cases according to the execution order of each test case to obtain the test results of the software under test; the test results of the software are used to characterize the performance of the software.
9. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.
10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.