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

Abstract

The invention provides a test case self-adaptive generation method and device based on dynamic scene perception, and the method comprises the following steps: detecting code change information in a Git warehouse of a business system through employing a code detection hook, and obtaining a system module corresponding to the code change information as an influence module; if the influence module is a high-risk module, constructing an abnormal test case to test the influence module; and if the influence module is not a high-risk module, further judging whether the influence module is a core module, if the influence module is the core module, constructing a normal test case to test the influence module, and if the influence module is not the core module, sampling and executing a basic test case to test the influence module. According to the scheme, the system module needing to be tested again is obtained by dynamically capturing the code change, so that accurate testing can be carried out in a frequent code change scene, and the maintenance cost is greatly reduced.

Description

Technical Field

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

[0002] In today's software development field, especially in industries such as medical software that have extremely high requirements for safety and reliability, the testing work faces many severe challenges. With the widespread application of the agile development model, the iteration cycle of software projects continues to shorten, and code changes become more frequent. In this fast-paced development environment, the drawbacks of the traditional method of disassembling and writing test cases based on product requirement documents and prototype diagrams are becoming increasingly prominent.

[0003] On the one hand, this method highly depends on static rules and preset scripts and lacks flexibility. Once the code changes, the original test cases often cannot adapt to the new code logic and function changes in a timely manner, resulting in a large number of test cases becoming invalid and needing to be rewritten and maintained. This not only consumes a large amount of manpower, material resources, and time, greatly increasing the testing cost, but also easily leads to omissions, making it difficult to ensure full coverage of all possible test scenarios and keeping the test coverage at a relatively low level for a long time.

[0004] On the other hand, although existing automated testing platforms have improved the test execution efficiency to a certain extent, they have obvious deficiencies in dealing with code changes. These platforms generally lack a real-time response mechanism for the impact of code changes and cannot adjust test data in a timely manner according to code changes, resulting in a disconnection between test data and code versions. In medical industry projects, this problem is particularly serious because medical software involves the life and health of patients, and any minor defect may cause serious consequences. If problems introduced by code changes cannot be discovered and fixed in a timely manner during the testing process, there is a high probability that the software will malfunction after going online, threatening user safety.

[0005] At the same time, in the agile development process, new requirements emerge continuously with each iteration. The current testing process can only ensure the relative stability of newly added requirement modules, but it is difficult to comprehensively and accurately test the original functions. This causes potential risks to accumulate continuously during the continuous iteration of the software, seriously affecting the quality and reliability of the software and hindering the smooth progress of software development projects. Therefore, there is an urgent need for an innovative test case generation method to solve the problems encountered by existing testing methods in the face of frequent code changes and dynamic user scenarios. Summary of the Invention

[0006] The embodiment of the present application provides a method and device for adaptively generating test cases based on dynamic scenario perception. By dynamically capturing code changes to obtain system modules that need to be retested, and writing corresponding test cases based on different system modules for testing, accurate testing can be performed in the scenario of frequent code changes, greatly reducing the maintenance cost.

[0007] In a first aspect, the embodiment of the present application provides a method for adaptively generating test cases based on dynamic scenario perception, the method comprising: Using a code detection hook 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, wherein when the operation frequency of the user on the affected module is greater than a set threshold, the affected module is a high-risk 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. If the affected module is not a core module, sampling and executing a basic test case to test the affected module, wherein when the affected module affects the core business logic in the business system, the affected module is a core module.

[0008] In a second aspect, the embodiment of the present application provides a device for adaptively generating test cases based on dynamic scenario perception, comprising: A detection module, configured to use a code detection hook 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; A first test module, if the affected module is a high-risk module, constructing an abnormal test case to test the affected module, wherein when the operation frequency of the user on the affected module is greater than a set threshold, the affected module is a high-risk module; A second test 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. If the affected module is not a core module, sampling and executing a basic test case to test the affected module, wherein when the affected module affects the core business logic in the business system, the affected module is a core module.

[0009] In a third aspect, the embodiment of the present application provides an electronic device, comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute a method for adaptively generating test cases based on dynamic scenario perception.

[0010] 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 method for adaptively generating test cases based on dynamic scene perception is implemented.

[0011] The main contributions and innovations of the present invention are as follows: 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 in a targeted manner according to the risk level of the affected module (whether it is a high-risk module) and whether it belongs to the core module, so as to achieve accurate testing, avoid invalid testing, and improve testing efficiency; the embodiment of the present application obtains the user operation path through the buried point, determines the high-risk module, focuses on high-frequency scenarios, and improves the test coverage. Analyze historical test results, identify stable modules, reduce repeated tests, 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.

[0012] 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

[0013] 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: Figure 1 is a flow chart of a method for adaptively generating test cases based on dynamic scene perception according to an embodiment of the present application; Figure 2 It 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; Figure 3 It is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0014] Exemplary embodiments will be described in detail herein, and examples thereof are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. On the contrary, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0015] It should be noted that: In other embodiments, the steps of the corresponding methods are not necessarily executed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step for description in other embodiments.

[0016] Embodiment 1 To facilitate understanding of this solution, some terms appearing in this solution are explained herein: 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 business process, such as a hospital business system, a full-process business system for commercial matters, etc.

[0017] 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 full-process business system for commercial matters.

[0018] Abnormal test case: It is a test case that constructs some abnormal input data that does not conform to the norm, exceeds the normal expected range, or has special boundary conditions, etc., to test whether the system module can maintain stable operation in the face of these abnormal situations without crashing, producing incorrect results, or other abnormal manifestations.

[0019] Normal test case: It is a test case that uses data input that conforms to normal business logic and expectations to verify whether the system module can accurately and normally implement the corresponding functions in a regular and reasonable usage scenario.

[0020] Basic test case: It is a test case that verifies whether the basic functions of the system module are available.

[0021] The embodiment of the present application provides a method for adaptively generating test cases based on dynamic scenario perception. By dynamically capturing code changes, the system modules that need to be retested are obtained, and corresponding test cases are written based on different system modules for testing. Thus, accurate testing can be carried out in the scenario of frequent code changes, greatly reducing the maintenance cost. Specifically, referring to Figure 1 , the method includes: Using a code detection hook 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, an abnormal test case is constructed to test the affected module. Wherein, when the operation frequency of the user on the affected module is greater than the set threshold, the affected module is a high-risk module; 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, the basic test case is sampled and executed to test the affected module. Wherein, when the affected module affects the core business logic in the business system, the affected module is a core module.

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

[0023] Specifically, create post-receive in the hooks directory of the Git repository as the code detection hook. 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 the code change information.

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

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

[0026] Specifically, the change analysis script is written in Python + Git. After the code detection hook is triggered, the change analysis script obtains code change information from the code detection hook processing, and finds the added, modified, or deleted code lines as the changed code lines by further analyzing the code change information.

[0027] Furthermore, the interface-module mapping table defines the corresponding relationships between each interface in the business system and various system modules. The interface to which the changed code lines belong 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. Specifically, the interface-module mapping table stores the mapping relationships using Python + field data structures. That is to say, in the interface-module mapping table, the system module name is used as the key, and the list of interfaces associated with the system module is used as the corresponding value.

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

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

[0030] Specifically, the buried point function is created using Python + pandas library to obtain the buried point logs. The operation information of users in the business system, including clicks, browsing, etc., is obtained through the buried point logs. The pandas library can conveniently process and analyze these log data to generate multiple operation paths.

[0031] Furthermore, the weight path algorithm calculates the path weight by calculating the stay time of users 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. Specifically, the formula of the weight path algorithm is expressed as follows:

[0032] Among them, represents the total stay time of each operation step of the user on this path, is the stay time of the i-th step, L represents the path length, α is the preset weight coefficient α ∈ [0.1, 0.7], e is the base of the natural logarithm.

[0033] Specifically, the weight path algorithm in this solution comprehensively considers the user's stay time and path length. The higher the weight value, the higher the operation frequency of the corresponding operation path, and the higher the importance of the operation path. This solution only selects the paths with weight values higher than the threshold as high-frequency operation paths, so as to ensure that the test cases focus on the high-frequency scenarios of real users. For example, in the same scenario, the operation paths ranked top N in terms of weight value can be determined as high-frequency operation paths, and the specific N threshold can be dynamically adjusted according to historical data or business requirements.

[0034] Exemplarily, the exception test cases include boundary value tests for inputting the maximum / minimum values, invalid parameter tests by inputting null values and illegal characters, tests for timeout retries, abnormal operation sequences for concurrent requests, etc. In this solution, the exception test cases can also be performed by using the fuzz testing tool LibFuzzer to automatically generate abnormal input data. Performing exception tests by automatically generating abnormal input data through LibFuzzer can detect the running conditions of the affected module under abnormal inputs and discover potential leakage points.

[0035] In some specific embodiments, historical test results are obtained, and the defect rate and test coverage rate of each system module are analyzed from the historical test results. The system modules with defect rates less than the first magnitude and test coverage rates greater than the second magnitude are regarded as stable modules, and the number of repeated tests on the stable modules is reduced.

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

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

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

[0039] Furthermore, through static analysis and detection of the interface-module mapping table, it is confirmed whether the affected module is on the core business logic chain. If so, the affected module is a core module.

[0040] Further, by judging the usage proportion of the affected module on the high-frequency operation path through the buried point logs, if the usage proportion is greater than the set threshold, the affected module is regarded as a core module.

[0041] Furthermore, by analyzing the historical test data, if the defect rate of the affected module is greater than the third magnitude, the affected module is regarded as a core module.

[0042] In some specific embodiments, if the impact module is not a core module, it indicates that the impact module does not belong to the core scope of the business system. At this time, select some appropriate test cases from the existing basic test case set according to the sampling rules, and use these extracted test cases to check whether the impact module meets the established requirements and standards in terms of various functions, performances, and other related indicators, so as to discover possible problems or defects of the impact module.

[0043] In some specific embodiments, configure test tasks in the CI / CD pipeline. When there is a new code submission in the business system, automatically trigger the report of test cases, and allocate the test cases to different test nodes for execution according to the type of test cases and the affected modules, so as to realize the automatic distribution of test cases.

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

[0045] In some specific embodiments, use the plotly tool to generate a test report. The test report includes the execution results of test cases, detailed information on code changes, and association relationships. Use red color to indicate that the test case fails due to code changes, and mark the impact of code changes on the test case in the report to help developers quickly locate the problem.

[0046] Embodiment 2 Based on the same concept, referring to Figure 2 , this application also proposes a test case adaptive generation device based on dynamic scenario perception, including: A detection module, which is used to detect code change information using a code detection hook in the Git repository of the business system, and obtain the system module corresponding to the code change information as the impact module; A first test module, if the impact module is a high-risk module, then construct abnormal test cases to test the impact module, where when the operation frequency of the user on the impact module is greater than a set threshold, the impact module is a high-risk module; A second test module, if the impact module is not a high-risk module, then further determine whether the impact module is a core module. If the impact module is a core module, then construct normal test cases to test the impact module. If the impact module is not a core module, then sample and execute basic test cases to test the impact module, where when the impact module affects the core business logic in the business system, the impact module is a core module.

[0047] Embodiment 3 This embodiment also provides an electronic device. Refer to Figure 3 , which includes a memory 404 and a processor 402. A computer program is stored in the memory 404, and the processor 402 is configured to run the computer program to execute the steps in any of the above method embodiments.

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

[0049] Among them, the memory 404 may include a mass storage 404 for data or instructions. By way of example and not limitation, the memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid state drive (SSD), a flash memory, an optical disc, a magneto-optical disc, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. In a suitable case, the memory 404 may include removable or non-removable (or fixed) media. In a suitable case, the memory 404 may be internal or external to the data processing device. In a specific embodiment, the memory 404 is a non-volatile memory. In a specific embodiment, the memory 404 includes a read-only memory (ROM) and a random access memory (RAM). In a suitable case, 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, or a combination of two or more of these. In a suitable case, the RAM may be a static random access memory (SRAM) or a dynamic random access memory (DRAM), where the DRAM may be a fast page mode dynamic random access memory (FPMDRAM), an extended date out dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.

[0050] The memory 404 can 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.

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

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

[0053] The transmission device 406 can be used to receive or send data via a network. Specific examples of the above network may include wired or wireless networks provided by the communication provider of the electronic device. In one example, the transmission device includes a network adapter (abbreviated as NIC), which can be connected to other network devices through a base station and thus communicate with the Internet. In one example, the transmission device 406 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0054] The input / output device 408 is used to input or output information. In this embodiment, the input information can be code detection hooks, test cases, etc., and the output information can be test results, etc.

[0055] Optionally, in this embodiment, the above processor 402 can be set to execute the following steps through a computer program: 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 affected module is a high-risk module, construct an abnormal test case to test the affected module, where when the operation frequency of the user on the affected module is greater than the set threshold, the affected module is a high-risk module; If the affected module is not a high-risk module, further determine whether the affected module is a core module. If the affected module is a core module, construct a normal test case to test the affected module. If the affected module is not a core module, sample and execute the basic test case to test the affected module, where when the affected module affects the core business logic in the business system, the affected module is a core module.

[0056] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation manners, and will not be elaborated herein.

[0057] Generally, various embodiments can be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects of the present invention can be implemented in hardware, while other aspects can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the present invention is not limited thereto. Although various aspects of the present invention can be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, as a non-limiting example, the blocks, devices, systems, technologies, or methods described herein can be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or a controller or other computing device, or some combination thereof.

[0058] Embodiments of the present invention can be implemented by computer software, which can be executed by a data processor of a mobile device, such as in a processor entity, or implemented by hardware, or implemented by a combination of software and hardware. A computer software or program (also referred to as a program product), including software routines, applets, and / or macros, can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. The computer program product can include one or more computer-executable components configured to execute the embodiments when the program runs. One or more computer-executable components can be at least one software code or a part thereof. Additionally, in this regard, it should be noted that any block in the logical flow, as Figure 3 described, can represent a program step, or interconnected logical circuits, blocks, and functions, or a combination of program steps and logical circuits, blocks, and functions. The software can be stored on physical media such as memory chips or storage blocks implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs. The physical media is a non-transitory medium.

[0059] Those skilled in the art should understand that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, 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, it should be considered as within the scope described in this specification.

[0060] The above embodiments only represent several implementation manners of the present application. Their descriptions are relatively specific and detailed, but should not be construed as limiting the scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A test case adaptive generation method based on dynamic scenario perception, characterized in that, Including the following steps: Use a code detection hook 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 affected module is a high-risk module, construct abnormal test cases to test the affected module. Wherein, when the operation frequency of the user on the affected module is greater than the set threshold, the affected module is a high-risk module; If the affected module is not a high-risk module, further determine whether the affected module is a core module. If the affected module is a core module, construct normal test cases to test the affected module. If the affected module is not a core module, sample and execute the basic test cases to test the affected module. Wherein, when the affected module affects the core business logic in the business system, the affected module is a core module.

2. The test case adaptive generation method based on dynamic scenario perception according to claim 1, characterized in that, When the code detection hook is triggered, use the git diff command to obtain the difference information between the versions before and after the code change as the code change information.

3. The test case adaptive generation method based on dynamic scenario perception according to claim 1, characterized in that, Write a change analysis script. After the code detection hook is triggered, execute the change analysis script to obtain the code change information, and based on the code change information, obtain the changed code lines, construct an interface-module mapping table, and based on the interface-module mapping table, obtain the system module corresponding to the changed code lines as the affected module.

4. The test case adaptive generation method based on dynamic scenario perception according to claim 3, characterized in that, The interface-module mapping table defines the corresponding relationship between each interface in the business system and each system module. Obtain the interface to which the changed code line belongs as the code change interface, and obtain the system module corresponding to the code change interface in the interface-module mapping table as the affected module. Wherein, in the interface-module mapping table, the system module name is used as the key, and the list of interfaces associated with the system module is used as the corresponding value.

5. The test case adaptive generation method based on dynamic scenario perception according to claim 1, characterized in that, Obtain multiple operation paths of the user in the business system through buried points, use the path weight algorithm to calculate the operation frequency of each operation path, select the operation paths with an operation frequency greater than the set threshold as high-frequency operation paths, and the system modules on the high-frequency operation paths are high-risk modules.

6. The test case adaptive generation method based on dynamic scenario perception according to claim 5, characterized in that, The path weight algorithm calculates the path weight by calculating the residence time of the user 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.

7. The test case adaptive generation method based on dynamic scenario perception according to claim 1, characterized in that, Obtain the historical test results, analyze the historical test results to obtain the defect rate and test coverage rate of each system module, and use the system modules with a defect rate less than the first size and a test coverage rate greater than the second size as stable modules, and reduce the number of repeated tests on the stable modules.

8. A test case adaptive generation device based on dynamic scenario perception, characterized in that, Including: A detection module, configured to use a code detection hook 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; A first test module, if the affected module is a high-risk module, construct abnormal test cases to test the affected module. Wherein, when the operation frequency of the user on the affected module is greater than the set threshold, the affected module is a high-risk module; 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, normal test cases are constructed to test the affected module. If the affected module is not a core module, basic test cases are sampled and executed to test the affected module, where the affected module is a core module when the affected module affects the core business logic in the business system.

9. An electronic device, including a memory and a processor, characterized in that, A computer program is stored in the memory, and the processor is configured to run the computer program to execute the method for adaptively generating test cases based on dynamic scenario perception according to any one of claims 1-7.

10. A readable storage medium, characterized in that, A computer program is stored in the readable storage medium, and the computer program includes program code for controlling a process to execute the process. When the program code is executed by a processor, the method for adaptively generating test cases based on dynamic scenario perception according to any one of claims 1-7 is implemented.

Images