Test case adaptive generation method and device based on dynamic scene perception

Abstract

This application proposes a method and device for adaptively generating test cases based on dynamic scenario perception, which includes the following steps: using code detection hooks in the Git repository of the business system to detect code change information, and obtaining the system module corresponding to the code change information as the affected module; if the affected module is a high-risk module, constructing an abnormal test case to test the affected module; if the affected module is not a high-risk module, further determining whether the affected module is a core module, if the affected module is a core module, constructing a normal test case to test the affected module, and if the affected module is not a core module, sampling and executing basic test cases to test the affected module. This solution obtains the system modules that need to be retested by dynamically capturing code changes, so that accurate testing can be performed in frequent code change scenarios, greatly reducing maintenance costs.

Description

Technical Field

[0001] The present application relates to the field of software testing, and in particular to a method and device for adaptively generating test cases based on dynamic scenario perception. Background Art

[0002] In today's software development landscape, especially in industries like medical software, which place extremely high demands on security and reliability, testing faces numerous challenges. With the widespread adoption of agile development models, software project iteration cycles are shrinking, and code changes are becoming increasingly frequent. In this fast-paced development environment, the traditional approach of writing test cases based on product requirements documents and prototypes is becoming increasingly problematic.

[0003] On the one hand, this approach relies heavily on static rules and pre-set scripts, lacking flexibility. Once the code changes, existing test cases often fail to adapt to the new code logic and functional changes, resulting in a large number of test cases becoming invalid and requiring rewriting and maintenance. This not only consumes a large amount of manpower, material resources, and time, significantly increasing testing costs, but also is prone to omissions, making it difficult to ensure comprehensive coverage of all possible test scenarios, resulting in a long-term low test coverage rate.

[0004] On the other hand, while existing automated testing platforms have improved test execution efficiency to a certain extent, they have significant shortcomings when it comes to responding to code changes. These platforms generally lack real-time response mechanisms to the impact of code changes, making it impossible to adjust test data in a timely manner based on code changes. This leads to a disconnect between test data and code versions. This problem is particularly serious in medical projects, as medical software involves the lives and health of patients, and even the smallest flaw can have serious consequences. If problems introduced by code changes are not discovered and fixed promptly during the testing process, the software is likely to fail after release, threatening user safety.

[0005] At the same time, in agile development, each iteration is accompanied by the continuous emergence of new requirements. Current testing processes often only ensure the relative stability of newly required modules, but struggle to comprehensively and accurately test existing functionality. This leads to the accumulation of potential risks during continuous software iteration, severely impacting software quality and reliability and hindering the smooth progress of software development projects. Therefore, an innovative test case generation method is urgently needed to address the challenges existing testing methods face when dealing with frequent code changes and dynamic user scenarios. Summary of the Invention

[0006] The embodiments of the present application provide a method and device for adaptively generating test cases based on dynamic scenario perception, which dynamically captures code changes to obtain system modules that need to be retested, and writes corresponding test cases based on different system modules for testing. This allows accurate testing in scenarios with frequent code changes, greatly reducing maintenance costs.

[0007] In a first aspect, an embodiment of the present application provides a method for adaptively generating test cases based on dynamic scenario perception, the method comprising:

[0008] Use code detection hooks in the Git repository of the business system to detect code change information and obtain the system module corresponding to the code change information as the affected module;

[0009] If the affected module is a high-risk module, an abnormal test case is constructed to test the affected module, wherein when the user's operation frequency on the affected module is greater than a set threshold, the affected module is a high-risk module;

[0010] If the affected module is not a high-risk module, it is further determined whether the affected module is a core module. If the affected module is a core module, a normal test case is constructed to test the affected module. If the affected module is not a core module, a sample of basic test cases is executed to test the affected module. When the affected module affects the core business logic in the business system, the affected module is a core module.

[0011] In a second aspect, an embodiment of the present application provides a device for adaptively generating test cases based on dynamic scene perception, comprising:

[0012] A detection module is used to use a code detection hook to detect code change information in the Git repository of the business system and obtain the system module corresponding to the code change information as the affected module;

[0013] A first test module, if the impact module is a high-risk module, constructs an abnormal test case to test the impact module, wherein when the user's operation frequency on the impact module is greater than a set threshold, the impact module is a high-risk module;

[0014] The second test module, if the affected module is not a high-risk module, further determines whether the affected module is a core module. If the affected module is a core module, a normal test case is constructed to test the affected module. If the affected module is not a core module, a basic test case is sampled and executed to test the affected module. When the affected module affects the core business logic in the business system, the affected module is a core module.

[0015] In a third aspect, an embodiment of the present application provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute a test case adaptive generation method based on dynamic scene perception.

[0016] In a fourth aspect, an embodiment of the present application provides a readable storage medium, in which a computer program is stored. The computer program includes a program code for controlling a process to execute a process. When the program code is executed by a processor, a test case adaptive generation method based on dynamic scene perception is implemented.

[0017] The main contributions and innovations of the present invention are as follows:

[0018] The embodiment of the present application uses code detection hooks to perceive code changes in real time, capture code change information in the business system Git repository, and accurately locate the affected modules; the embodiment of the present application constructs abnormal test cases, normal test cases, or sample execution of basic test cases based on the risk level of the affected module (whether it is a high-risk module) and whether it belongs to the core module, to achieve accurate testing, avoid invalid testing, and improve testing efficiency; the embodiment of the present application obtains user operation paths through tracking points, identifies high-risk modules, focuses on high-frequency scenarios, and improves test coverage. Analyze historical test results, identify stable modules, reduce repeated testing, and further improve test efficiency. In addition, the solution can also automatically distribute test cases in the CI / CD pipeline and generate visual test reports to facilitate developers to locate problems, effectively reduce test maintenance costs in frequent code change scenarios, and ensure software quality.

[0019] The details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0021] Figure 1 is a flowchart of a method for adaptively generating test cases based on dynamic scene perception according to an embodiment of the present application;

[0022] Figure 2 This is a structural block diagram of a test case adaptive generation device based on dynamic scene perception according to an embodiment of the present application;

[0023] Figure 3 Schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0025] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0026] Example 1

[0027] To facilitate understanding of this plan, some of the terms that appear in this plan are explained here:

[0028] Business system: refers to a comprehensive system that uses information technology, especially computer technology, network technology and database technology, to digitally process each link in the enterprise's business process, such as hospital business system, commercial full-process business system, etc.

[0029] System module: refers to each module in the business system, such as the registration module and payment module in the hospital business system, or the enterprise registration module and change registration module in the commercial full-process business system.

[0030] Abnormal test cases: These are test cases in which abnormal input data that is not in line with the norm, exceeds the normal expected range, or has special boundary conditions is constructed to test whether the system module can maintain stable operation in the face of these abnormal conditions without crashing, producing erroneous results, or other abnormal performance.

[0031] Normal test cases: These are use cases that use data input that conforms to normal business logic and expectations to verify whether the system modules can accurately and normally implement the corresponding functions under regular and reasonable usage scenarios.

[0032] Basic test cases: These are test cases that verify whether the basic functions of the system modules are available.

[0033] The embodiment of the present application provides a method for adaptively generating test cases based on dynamic scenario perception, which obtains system modules that need to be retested by dynamically capturing code changes, and writes corresponding test cases based on different system modules for testing, thereby enabling accurate testing in scenarios with frequent code changes, greatly reducing maintenance costs. Specifically, reference Figure 1 , the method comprising:

[0034] Use code detection hooks in the Git repository of the business system to detect code change information and obtain the system module corresponding to the code change information as the affected module;

[0035] If the affected module is a high-risk module, an abnormal test case is constructed to test the affected module, wherein when the user's operation frequency on the affected module is greater than a set threshold, the affected module is a high-risk module;

[0036] If the affected module is not a high-risk module, it is further determined whether the affected module is a core module. If the affected module is a core module, a normal test case is constructed to test the affected module. If the affected module is not a core module, a sample of basic test cases is executed to test the affected module. When the affected module affects the core business logic in the business system, the affected module is a core module.

[0037] In some embodiments, when the code detection hook is triggered, the git diff command is used to obtain the difference information between the versions before and after the code change as the code change information.

[0038] Specifically, create post-receive as a code detection hook in the hooks directory of the Git repository. The main function of the code detection hook is to listen for push events. Once a push event is detected, it means that the code in the Git repository has changed. At this time, the git diff command is used to obtain the code difference information between the two versions before and after the code change as code change information.

[0039] In some specific embodiments, a change analysis script is written. When the code detection hook is triggered, the change analysis script is executed to obtain code change information, and the changed code lines are obtained based on the code change information, and an interface-module mapping table is constructed. Based on the interface-module mapping table, the system module corresponding to the changed code line is obtained as the affected module.

[0040] Specifically, since a change in a piece of code may affect multiple system modules, the number of affected modules in this solution is greater than or equal to 1.

[0041] Specifically, the change analysis script is written using python+git. When the code detection hook is triggered, the change analysis script obtains code change information from the code detection hook and further analyzes the code change information to find out the newly added, modified or deleted code lines as the changed code lines.

[0042] Furthermore, the interface-module mapping table defines the correspondence between each interface in the business system and each system module. The interface to which the changed code line belongs is obtained as the code change interface, and the system module corresponding to the code change interface is obtained from the interface-module mapping table as the affected module.

[0043] Specifically, the interface-module mapping table uses a python+field data structure to store mapping relationships, that is, the interface-module mapping table uses the system module name as a key and the interface list associated with the system module as a corresponding value.

[0044] In some embodiments, multiple operation paths of users in the business system are obtained through tracking, and the operation frequency of each operation path is calculated using a path weight algorithm. Operation paths with an operation frequency greater than a set threshold are selected as high-frequency operation paths, and system modules on high-frequency operation paths are high-risk modules.

[0045] That is, if the affected module obtained by this solution is a system module on a high-frequency operation path, the affected module is a high-risk module.

[0046] Specifically, use the Python + Pandas library to create a tracking function to obtain tracking logs. Through the tracking logs, we can obtain user operation information in the business system, including clicks, browsing, etc. The Pandas library can easily process and analyze these log data to generate multiple operation paths.

[0047] Furthermore, the weighted path algorithm calculates the path weight by calculating the user's stay time and the number of operation steps on different operation paths. The higher the path weight, the higher the operation frequency of the corresponding operation path. Specifically, the formula of the weighted path algorithm is as follows:

[0048]

[0049] in, It represents the total time users spend at each operation step on the path. is the residence time of the ith step, L represents the path length, α is the preset weight coefficient α∈[0.1,0.7], e is the base of natural logarithms.

[0050] Specifically, the weighted path algorithm in this solution comprehensively considers user dwell time and path length. Higher weights indicate more frequent operation of the corresponding action path, and therefore, greater importance. This solution only selects paths with weights above a threshold as high-frequency operation paths, ensuring that test cases focus on high-frequency scenarios for real users. For example, in the same scenario, the top N weighted action paths can be identified as high-frequency operation paths. The specific threshold of N can be dynamically adjusted based on historical data or business needs.

[0051] Exemplarily, abnormal test cases include boundary value testing of maximum / minimum input values, invalid parameter testing by inputting empty values ​​and illegal characters, timeout retry, abnormal operation sequence of concurrent requests, and other test cases. In this solution, the abnormal test cases can also be carried out by using the fuzz testing tool LibFuzzer to automatically generate abnormal input data. By automatically generating abnormal input data through LibFuzzer to perform abnormal testing, it is possible to detect the operation of the module under abnormal input and find potential loopholes.

[0052] In some specific embodiments, historical test results are obtained and analyzed to obtain the defect rate and test coverage of each system module. System modules with a defect rate less than a first size and a test coverage greater than a second size are treated as stable modules, thereby reducing the number of repeated tests on the stable modules.

[0053] In some specific embodiments, a pre-trained reinforcement learning model is constructed, and historical test results are obtained and input into the reinforcement learning model to output a use case generation strategy.

[0054] Furthermore, by analyzing historical test results, stable modules with low defect rates and high test coverage are determined, and test efficiency is improved by reducing the number of repeated tests on stable modules.

[0055] In some specific embodiments, in a medical-related business system, the core modules are modules involving core business logic such as patient registration, doctor consultation, and medical order submission.

[0056] Furthermore, static analysis and detection of the interface-module mapping table is performed to confirm whether the affected module is in the core business logic chain. If so, the affected module is a core module.

[0057] Furthermore, the usage ratio of the impact module on the high-frequency operation path is determined through the tracking log. If the usage ratio is greater than the set threshold, the impact module is used as the core module.

[0058] Furthermore, by analyzing historical test data, if the defect rate of the influencing module is greater than a third value, the influencing module is used as a core module.

[0059] In some specific embodiments, if the impact module is not a core module, it means that the impact module does not belong to the core category of the business system. At this time, some suitable test cases are selected from the existing basic test case set according to the sampling rules, and these extracted test cases are used to check whether the impact module meets the established requirements and standards in terms of various functions, performance and other relevant indicators, so as to discover possible problems or defects in the impact module.

[0060] In some specific embodiments, test tasks are configured in the CI / CD pipeline. When new code is submitted in the business system, a test case report is automatically triggered. According to the type of test case and the affected module, the test case is assigned to different test nodes for execution, thereby realizing automatic distribution of test cases.

[0061] Specifically, this solution collects test results in real time and feeds the results back to the developers, notifying them of the test results by email.

[0062] In some specific embodiments, the plotly tool is used to generate test reports that include test case execution results, code change details, and associated relationships. Test cases that failed due to code changes are indicated in red, and the impact of code changes on test cases is marked in the report to help developers quickly locate the problem.

[0063] Example 2

[0064] Based on the same concept, Figure 2 , this application also proposes a test case adaptive generation device based on dynamic scene perception, including:

[0065] A detection module is used to use a code detection hook to detect code change information in the Git repository of the business system and obtain the system module corresponding to the code change information as the affected module;

[0066] A first test module, if the impact module is a high-risk module, constructs an abnormal test case to test the impact module, wherein when the user's operation frequency on the impact module is greater than a set threshold, the impact module is a high-risk module;

[0067] The second test module, if the affected module is not a high-risk module, further determines whether the affected module is a core module. If the affected module is a core module, a normal test case is constructed to test the affected module. If the affected module is not a core module, a basic test case is sampled and executed to test the affected module. When the affected module affects the core business logic in the business system, the affected module is a core module.

[0068] Example 3

[0069] This embodiment also provides an electronic device, referring to Figure 3 , includes a memory 404 and a processor 402, wherein the memory 404 stores a computer program, and the processor 402 is configured to run the computer program to perform the steps in any of the above method embodiments.

[0070] Specifically, the processor 402 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0071] Memory 404 may include a large-capacity memory 404 for data or instructions. By way of example, and not limitation, memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 404 may include removable or non-removable (or fixed) media. Where appropriate, memory 404 may be internal or external to the data processing device. In certain embodiments, memory 404 is non-volatile memory. In certain embodiments, memory 404 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically alterable ROM (EAROM) or a flash memory (FLASH), or a combination of two or more of these. In appropriate circumstances, the RAM may be a static random access memory (SRAM) or a dynamic random access memory (DRAM), wherein the DRAM may be a fast page mode dynamic random access memory 404 (FPMDRAM), an extended data output dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.

[0072] The memory 404 may be used to store or cache various data files required for processing and / or communication, as well as possible computer program instructions executed by the processor 402 .

[0073] The processor 402 reads and executes computer program instructions stored in the memory 404 to implement any one of the dynamic scenario-aware automated test case adaptive generation methods in the above embodiments.

[0074] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408 , wherein the transmission device 406 is connected to the processor 402 , and the input / output device 408 is connected to the processor 402 .

[0075] Transmission device 406 can be used to receive or transmit data via a network. Specific examples of such networks may include wired or wireless networks provided by the electronic device's communications provider. In one embodiment, the transmission device includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 406 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0076] The input and output devices 408 are used to input or output information. In this embodiment, the input information may be code detection hooks, test cases, etc., and the output information may be test results, etc.

[0077] Optionally, in this embodiment, the processor 402 may be configured to execute the following steps through a computer program:

[0078] A code detection hook is used in the Git repository of the business system to detect code change information and obtain the system module corresponding to the code change information as the affected module;

[0079] If the affected module is a high-risk module, an abnormal test case is constructed to test the affected module, wherein when the user's operation frequency on the affected module is greater than a set threshold, the affected module is a high-risk module;

[0080] If the affected module is not a high-risk module, it is further determined whether the affected module is a core module. If the affected module is a core module, a normal test case is constructed to test the affected module. If the affected module is not a core module, a sample of basic test cases is executed to test the affected module. When the affected module affects the core business logic in the business system, the affected module is a core module.

[0081] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be repeated here.

[0082] In general, various embodiments may be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flow charts, or using some other graphical representation, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or a controller or other computing device, or some combination thereof.

[0083] The embodiments of the present invention may be implemented by computer software that is executable by a data processor of a mobile device, such as in a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets and / or macros may be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. A computer program product may include one or more computer executable components that are configured to perform an embodiment when the program is run. One or more computer executable components may be at least one software code or a portion thereof. In addition, it should be noted at this point that, for example, Figure 3 Any block of the logic flow in the program may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on physical media such as memory chips or memory blocks implemented within the processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs, etc. Physical media are non-transitory media.

[0084] Those skilled in the art should understand that the technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0085] The above embodiments merely illustrate several embodiments of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A test case adaptive generation method based on dynamic scene perception, characterized in that: The following steps are involved: Use code detection hooks in the Git repository of the business system to detect code change information and obtain the system module corresponding to the code change information as the affected module; If the impact module is a high-risk module, an abnormal test case is constructed to test the impact module. When the user's operation frequency on the impact module is greater than the set threshold, the impact module is a high-risk module. Multiple operation paths of the user in the business system are obtained through tracking, and the operation frequency of each operation path is calculated using the path weight algorithm. The operation path with an operation frequency greater than the set threshold is selected as the high-frequency operation path, and the system module on the high-frequency operation path is a high-risk module. The path weight algorithm calculates the path weight by calculating the user's stay time on different operation paths and the number of operation steps. The higher the path weight, the higher the operation frequency of the corresponding operation path. The formula of the path weight algorithm is expressed as follows: in, It represents the total time users spend at each operation step on the path. is the residence time of the ith step, L represents the path length, α is the preset weight coefficient α∈[0.1,0.7], e is the base of natural logarithms; If the affected module is not a high-risk module, it is further determined whether the affected module is a core module. If the affected module is a core module, a normal test case is constructed to test the affected module. If the affected module is not a core module, a sample of basic test cases is executed to test the affected module. The usage ratio of the affected module on the high-frequency operation path is determined by the embedded log. If the usage ratio is greater than the set threshold, the affected module is regarded as the core module. By analyzing the historical test data, if the defect rate of the affected module is greater than the third size, the affected module is regarded as the core module, and the historical test results are obtained. The historical test results are analyzed to obtain the defect rate and test coverage of each system module. The system modules with a defect rate less than the first size and a test coverage greater than the second size are regarded as stable modules to reduce the number of repeated tests on the stable modules.

2. The method for adaptively generating test cases based on dynamic scene perception according to claim 1, characterized in that: When the code detection hook is triggered, the git diff command is used to obtain the difference information between the versions before and after the code change as the code change information.

3. The method for adaptively generating test cases based on dynamic scene perception according to claim 1, characterized in that: Write a change analysis script. When the code detection hook is triggered, execute the change analysis script to obtain code change information, obtain the changed code line based on the code change information, build an interface-module mapping table, and obtain the system module corresponding to the changed code line as the affected module based on the interface-module mapping table.

4. The method for adaptively generating test cases based on dynamic scene perception according to claim 3, characterized in that: The interface-module mapping table defines the correspondence between each interface in the business system and each system module. The interface to which the changed code line belongs is obtained as the code change interface, and the system module corresponding to the code change interface is obtained in the interface-module mapping table as the affected module. In the interface-module mapping table, the system module name is used as the key, and the interface list associated with the system module is used as the corresponding value.

5. A test case adaptive generation device based on dynamic scene perception, characterized in that: include: A detection module is used to use a code detection hook to detect code change information in the Git repository of the business system and obtain the system module corresponding to the code change information as the affected module; The first test module, if the impact module is a high-risk module, then construct an abnormal test case to test the impact module, wherein, when the user's operation frequency on the impact module is greater than the set threshold, the impact module is a high-risk module, and multiple operation paths of the user in the business system are obtained through point tracking, and the operation frequency of each operation path is calculated using the path weight algorithm. The operation path with an operation frequency greater than the set threshold is selected as the high-frequency operation path, and the system module on the high-frequency operation path is a high-risk module, wherein, the path weight algorithm calculates the path weight by calculating the user's stay time on different operation paths and the number of operation steps. The higher the path weight, the higher the operation frequency of the corresponding operation path. The formula of the path weight algorithm is expressed as follows: in, It represents the total time users spend at each operation step on the path. is the residence time of the ith step, L represents the path length, α is the preset weight coefficient α∈[0.1,0.7], e is the base of natural logarithms; The second test module, if the impact module is not a high-risk module, further determine whether the impact module is a core module, if the impact module is a core module, construct a normal test case to test the impact module, if the impact module is not a core module, sample and execute basic test cases to test the impact module, wherein, the usage ratio of the impact module on the high-frequency operation path is determined by the embedded log, if the usage ratio is greater than the set threshold, the impact module is used as the core module; by analyzing the historical test data, if the defect rate of the impact module is greater than the third size, the impact module is used as the core module, and the historical test results are obtained. The historical test results are analyzed to obtain the defect rate and test coverage of each system module, and the system module with a defect rate less than the first size and a test coverage greater than the second size is used as a stable module to reduce the number of repeated tests on the stable module.

6. An electronic device comprising a memory and a processor, characterized in that: The memory stores a computer program, and the processor is configured to run the computer program to execute the method for adaptively generating test cases based on dynamic scene perception according to any one of claims 1 to 4.

7. A readable storage medium, characterized in that: The readable storage medium stores a computer program, which includes program code for controlling a process to execute a process. When the program code is executed by a processor, the method for adaptively generating test cases based on dynamic scene perception according to any one of claims 1 to 4 is implemented.

Images