Method and system for automatically testing software

Abstract

The invention discloses a method and system for software automatic testing, and relates to the technical field of computer software testing, and the method comprises the steps: building a constraint initial test target set covering path input and output; dynamically adjusting a test case generation strategy for the demand document; and updating the reconstructed test case to the constraint initial test target set, and constructing a path priority for the second time to complete the software automatic test. According to the invention, the accuracy of test case generation and the demand coverage integrity are improved; dynamic weight distribution of a test path and self-adaptive adjustment of a test case generation strategy are realized, and the coverage capability on a deep path and a high-risk module is effectively improved; the response capability of the test system to frequent iteration and the reuse efficiency of test resources are enhanced, and the software automatic test with higher automation degree, stronger environmental adaptability and more comprehensive coverage is realized on the whole.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software testing, in particular to a method and system for automatic software testing. BACKGROUND

[0002] With the rapid development of information technology, software systems are increasingly widely used in various industries, and their complexity and iteration speed are constantly improving. In the fields of intelligent manufacturing, Internet services, and financial technology, software products are updated more and more frequently, and the requirements for software quality and stability are increasingly stringent. In order to ensure that the software has good reliability before release, software testing as a key link in the research and development process is becoming increasingly important.

[0003] Currently, existing automatic software testing techniques still have problems such as low test case generation efficiency, incomplete coverage, and poor adaptability to dynamically changing software environments in actual application. In particular, when facing complex business logic or frequently iterated software systems, existing methods often rely on a large number of manually preset rules or are difficult to effectively capture deep program paths, resulting in limited automation level and execution effect of testing. This technical defect makes the testing process still require a large amount of human resources for intervention and maintenance, and cannot completely realize efficient and intelligent full-process automated testing. Therefore, there is an urgent need for a solution that can improve the level of test automation, enhance test coverage, and adaptability. SUMMARY

[0004] In view of the problems existing in the prior art method and system for automatic software testing, the present application is proposed.

[0005] Therefore, the problem to be solved by the present application is how to improve the generation efficiency and path coverage of test cases in software automatic testing, and enhance the self-adaptability of the testing system to frequent iteration and complex business logic, in order to realize efficient and intelligent full-process automated testing.

[0006] To solve the above technical problems, the present application provides the following technical solutions: In a first aspect, the present application provides a method for automatic software testing, comprising: obtaining a requirement document of a software to be tested, extracting data dependency relationships of the requirement document through static analysis, analyzing the data dependency relationships in combination with natural language processing technology, and establishing a constraint initial test target set covering path input and output; using the constraint initial test target set to construct path priority, assigning dynamic weights to the executed paths, introducing a monitoring branch mechanism in the software testing system, monitoring the dynamic weights of the executed paths, and dynamically adjusting the test case generation strategy for the requirement document; detecting the test case generation strategy, triggering test case reconstruction, updating the reconstructed test cases to the constraint initial test target set, constructing the path priority again, and completing the automatic software testing.

[0007] As a preferred scheme of the method for automatic testing of software, wherein: the obtaining of the requirement document of the software to be tested comprises obtaining the requirement document of the software to be tested by using an interface definition module in the software testing system; The data dependency relationship of the requirement document is extracted by marking the semantic boundary of the type content of different requirement documents and extracting the functional description rule constraint of the semantic boundary marking according to the structure of the requirement document of the software to be tested; The data dependency relationship of the requirement document is extracted by marking the semantic boundary of the type content of different requirement documents and extracting the functional description rule constraint of the semantic boundary marking according to the structure of the requirement document of the software to be tested;

[0008] As a preferred scheme of the method for automatic testing of software, wherein: the data dependency relationship is analyzed by combining the natural language processing technology, the non-redundant functional description rule constraint is combined with the calling sequence in the interface definition module, the cross-document data dependency network of the non-redundant functional description rule constraint is constructed, the boundary value condition of the non-redundant functional description rule constraint is identified, and the data dependency relationship analyzed by the boundary value condition is analyzed; The constraint initial test target set covering the path input and output is established by defining the data dependency relationship analyzed by the boundary value condition, generating the test target unit with the precondition, and establishing the constraint initial test target set covering the path input and output; The input refers to the requirement document of the software to be tested, and the output refers to the test result output with the requirement document of the software to be tested.

[0009] As a preferred scheme of the method for automatic testing of software, wherein: the path priority is constructed by using the constraint initial test target set, the definition-use path and the precondition associated with the test target unit are extracted from the constraint initial test target set; The path constructed by the constraint initial test target set is prioritized by combining the corresponding faults in the historical defect database of the software non-automatic test; The path is assigned a dynamic weight by collecting the path execution frequency of the prioritized path, deploying a monitoring probe in the prioritized path, collecting the path execution frequency, dynamically matching the data flow of the execution scoring path with the precondition in the constraint initial test target set, and identifying the high-frequency or low-frequency execution path that is not covered.

[0010] As a preferred scheme of the method for automatic testing of software, wherein: the monitoring of the execution path is dynamically weighted, including updating the dynamic weight in the priority score of the path according to the coverage frequency deviation information of the identified high-frequency or low-frequency execution path, increasing the weight of the path that is not covered or fails multiple times, and taking the weight change trend as a condition for inputting the requirement document state of the software to be tested; The dynamic adjustment of the test case generation strategy for the requirement document includes driving the test case generator of the software automatic testing based on the dynamic weight update result, selecting high-frequency test cases generated by the test target unit corresponding to the high-frequency execution path, generating test data satisfying the input space boundary by using the constraint solving technology in combination with the precondition, or selecting low-frequency test cases generated by the test target unit corresponding to the low-frequency execution path, and dynamically adjusting the test case generation strategy for the requirement document.

[0011] As a preferred scheme of the method for automatic testing of software, wherein: the detection of the test case generation strategy includes monitoring the version control of the software to be tested; When the requirement document test case update is detected, the change capture mechanism is triggered, the functional modules, interface definitions and associated test target units involved in the change are identified through difference comparison, and the affected definition-use paths and preconditions are marked; The secondary construction of the path priority includes constructing a test case subset to be optimized and generating a mutant test case adapted to the new path.

[0012] As a preferred scheme of the method for automatic testing of software, wherein: the construction of the test case subset to be optimized includes locating the test target unit to be reconstructed in the constraint initial test target set based on the marked affected path, screening the existing test cases having data dependency with the changed path in combination with the generated corresponding faults in the historical defect database of the non-automatic test, and constructing the test case subset to be optimized; The generation of the mutant test case adapted to the new path includes performing structural analysis on the test cases in the test case subset to be optimized, extracting the matching relationship between the input parameter combination of the test case subset to be optimized and the precondition of the corresponding path, satisfying the input boundary of the precondition after the change by using a constraint solver, and generating the mutant test case adapted to the new path in combination with the input boundary satisfying the precondition after the change; The secondary construction of the path priority includes injecting the generated mutant test case into the constraint initial test target set, synchronously updating the precondition and priority weight of the corresponding path in the constraint initial test target set, re-executing the path priority construction, carrying out the next round of automatic testing, and completing the automatic testing cycle of the software automatic testing.

[0013] In a second aspect, an embodiment of the present application provides a system for automatic software testing, comprising: a requirement analysis and test target generation module configured to obtain a requirement document of a software to be tested, extract a data dependency relationship of the requirement document through static analysis, analyze the data dependency relationship in combination with a natural language processing technique, and establish a constraint initial test target set covering a path input and output; a dynamic path scheduling and test strategy adjustment module configured to construct a path priority using the constraint initial test target set, assign a dynamic weight to an executed path, introduce a monitoring branch mechanism in a software testing system, assign a dynamic weight to an executed path, and dynamically adjust a test case generation strategy for the requirement document; a test case reconstruction and closed-loop optimization module configured to detect the test case generation strategy, trigger test case reconstruction, update the reconstructed test case to the constraint initial test target set, construct a path priority again, and complete automatic software testing.

[0014] In a third aspect, an embodiment of the present application provides a computer device comprising a memory and a processor, and the memory stores a computer program, wherein the processor implements any step of the method for automatic software testing described above when executing the computer program.

[0015] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium storing a computer program, wherein the computer program is executed by a processor to implement any step of the method for automatic software testing described above.

[0016] The present application has the following beneficial effects: the requirement analysis and test target generation module is constructed, the data dependency relationship is automatically extracted from the requirement document and the constraint initial test target set is established in combination with the natural language processing and static analysis techniques, the accuracy of test case generation and the requirement coverage completeness are improved; the dynamic path scheduling and test strategy adjustment module is used to realize the dynamic weight distribution of the test path and the adaptive adjustment of the test case generation strategy by using the path priority model and the runtime monitoring feedback mechanism, the coverage ability for the deep path and the high-risk module is effectively improved; the test case reconstruction and closed-loop optimization module is used to quickly generate the test case adapted to the new version and update the test target set after the software is updated in combination with the change detection and local reconstruction mechanism, the response ability of the testing system to the frequent iteration and the reuse efficiency of the testing resource are significantly enhanced, and the automatic software testing with higher automation degree, stronger environmental adaptability and more comprehensive coverage is realized as a whole. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments description will be briefly introduced as follows. Obviously, the drawings in the following description only represent some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative effort based on these drawings. Among them: Figure 1 A flow chart of a method for automatic software testing provided by an embodiment of the present application.

[0018] Figure 2 A system schematic diagram of a method for automatic software testing provided by an embodiment of the present application.

[0019] Figure 3 A structure schematic diagram of a medium of a method for automatic software testing provided by an embodiment of the present application.

[0020] Figure 4 A structure schematic diagram of a computing device of a method for automatic software testing provided by an embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the above objectives, features and advantages of the present application more apparent, the specific embodiments of the present application will be described in detail below with the drawings of the specification. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should belong to the protection scope of the present application.

[0022] In the following description, many specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced without the specific details, which are not described in the present application, and those skilled in the art can make similar generalizations without departing from the scope of the present application. Therefore, the present application is not limited by the specific embodiments disclosed below.

[0023] Secondly, the "one embodiment" or "embodiment" referred to herein means that the specific features, structures or characteristics can be included in at least one implementation of the present application. "In one embodiment" appearing in different places in the specification does not mean the same embodiment, nor is it an independent or selective embodiment excluding other embodiments.

[0024] The present application is described in detail in conjunction with the schematic diagram. In the detailed description of the embodiments of the present application, the cross-sectional view of the device structure is partially enlarged without the general proportion for the convenience of description, and the schematic diagram is only an example, which should not limit the scope of protection of the present application. In addition, the three-dimensional spatial dimensions of length, width and depth should be included in the actual manufacture.

[0025] Meanwhile, in the description of the present application, it should be noted that the terms "upper, lower, inner and outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first, second or third" are only for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0026] Unless otherwise expressly specified and limited, the terms "mounting, connecting, connecting" in the present application should be understood broadly, for example: it can be fixed connection, detachable connection or integral connection; it can also be mechanical connection, electrical connection or direct connection, it can also be indirectly connected through an intermediate medium, or it can be the internal communication of two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0027] Embodiment Reference Figures 1-4 For the first embodiment of the present application, the embodiment provides a method for automatic testing of software, comprising: S1: obtaining the requirement document of the software to be tested, extracting the data dependency relationship of the requirement document through static analysis, analyzing the data dependency relationship combined with natural language processing technology, and establishing the constraint initial test target set covering the path input and output.

[0028] Among them, obtaining the requirement document of the software to be tested includes obtaining the requirement document of the software to be tested by using the interface definition module in the software testing system; Using the structure of the requirement document of the software to be tested, the semantic boundary of the type content of different requirement documents is identified, and the function description rule constraint of the semantic boundary is extracted; Extracting the data dependency relationship of the requirement document includes preprocessing the function description rule constraint, removing redundant function description rule constraints, mapping redundant function description rule constraints, removing mapped function description rule constraints, and retaining non-redundant function description rule constraints.

[0029] S1.1: analyzing the data dependency relationship combined with natural language processing technology includes constructing the cross-document data dependency network of the non-redundant function description rule constraint combined with the calling sequence in the interface definition module, identifying the boundary value condition of the non-redundant function description rule constraint, and analyzing the extracted data dependency relationship using the boundary value condition; The constraint initial test target set covering the path input and output comprises defining the data dependency analyzed by using the boundary value condition, generating a test target unit with a precondition, and establishing the constraint initial test target set covering the path input and output; The input refers to a requirement document of the software to be tested, and the output refers to a test result output with the requirement document of the software to be tested.

[0030] S2: constructing a path priority by using the constraint initial test target set, assigning a dynamic weight to an executed path, introducing a monitoring branch mechanism in the software testing system, assigning a dynamic weight to the executed path, and dynamically adjusting a test case generation strategy for the requirement document.

[0031] The constructing of the path priority by using the constraint initial test target set comprises extracting a definition-use path and a precondition associated with a test target unit from the constraint initial test target set; The path constructed by the constraint initial test target set is given a priority score in combination with a corresponding fault in a historical defect database of non-automatic software testing; The assigning of the dynamic weight to the executed path comprises collecting a path execution frequency of the priority-scored path, deploying a monitoring probe in the priority-scored path, collecting the path execution frequency, dynamically matching a data stream of the scored path during execution with the precondition in the constraint initial test target set, and identifying an uncovered high-frequency or low-frequency execution path.

[0032] S2.1: the assigning of the dynamic weight to the executed path comprises updating the dynamic weight in the priority score of the path according to coverage frequency deviation information of the identified uncovered high-frequency or low-frequency execution path, increasing the weight of the path that is not covered or repeatedly fails, and taking a weight change trend as a condition for a requirement document state input of the software to be tested; The dynamically adjusting of the test case generation strategy for the requirement document comprises driving a test case generator of the software automatic testing based on a dynamic weight update result, selecting a high-frequency test case generated by a test target unit corresponding to a high-frequency execution path, generating test data satisfying an input space boundary by using a constraint solving technique in combination with the precondition, or selecting a low-frequency test case generated by a test target unit corresponding to a low-frequency execution path, and dynamically adjusting the test case generation strategy for the requirement document.

[0033] S3: detecting the test case generation strategy, triggering test case reconstruction, updating the reconstructed test case to the constraint initial test target set, constructing a path priority again, and completing the software automatic testing.

[0034] The detecting of the test case generation strategy comprises listening to version control of the software to be tested. When detecting the requirement document test case update, the change capture mechanism is triggered, the functional module, interface definition and associated test target unit involved in the change are identified through difference comparison, and the affected definition-use path and preconditions are marked; The secondary path priority construction includes constructing the test case subset to be optimized and generating the mutation test case adapting to the new path.

[0035] S3.1: The test case subset to be optimized includes locating the test target unit to be reconstructed in the constraint initial test target set based on the marked affected path, screening the existing test case having data dependency with the changed path in combination with the corresponding fault in the generated non-automatic test history defect database, and constructing the test case subset to be optimized; The mutation test case adapting to the new path includes performing structural analysis on the test case in the test case subset to be optimized, extracting the input parameter combination matching relationship of the test case subset to be optimized and the preconditions of the corresponding path, using the constraint solver to satisfy the input boundary of the post-change preconditions, and generating the mutation test case adapting to the new path in combination with the input boundary satisfying the post-change preconditions; The secondary path priority construction includes injecting the generated mutation test case into the constraint initial test target set, synchronously updating the preconditions and priority weights of the corresponding path in the constraint initial test target set, re-executing the path priority construction, carrying out the next round of automatic test, and completing the automatic test cycle of software automatic test.

[0036] Further, the technical scheme of the present application forms a closed-loop optimization process with close linkage between steps: first, the S1 step obtains the requirement document through the interface definition module, and extracts the data dependency relationship by combining static analysis and natural language processing technology, and after removing redundancy and semantic analysis, an initial test target set with preconditions is constructed S1.1, providing a structured and high-coverage target basis for subsequent testing; the target set is directly used in the construction of path priority in the S2 step, the initial score is obtained by introducing historical defect data, and the path coverage state is collected in real time by using the monitoring probe during the test execution, and the un-covered or abnormally executed paths are dynamically identified, and then the path weight is updated S2.1 according to the feedback deviation, the adaptive adjustment of the test case generation strategy is realized, and the resources are tilted to the high-risk and difficult-to-cover paths; when the system listens to the version change S3, the reconstruction mechanism is triggered, the affected paths are located based on change impact analysis, and the to-be-optimized subset is selected from the existing test cases S3.1 in combination with historical defect information, the mutation test cases adapted to the new environment are generated by using constraint solving technology and updated to the original target set, the path priority construction and test execution are restarted, and an automatic closed loop of "generation-execution-feedback-reconstruction-regeneration" is formed. The above steps are progressive and related, and together solve the problems of low test case generation efficiency, incomplete coverage and poor adaptability to software dynamic changes in the prior art, and realize the high automation, intelligence and continuous evolution capability of the test process.

[0037] In a preferred embodiment, a system for automatic testing of software, the system comprising a requirement analysis and test target generation module, which obtains the requirement document of the software to be tested, extracts the data dependency relationship of the requirement document through static analysis, analyzes the data dependency relationship in combination with natural language processing technology, and establishes a constraint initial test target set covering the input and output of the path; a dynamic path scheduling and test strategy adjustment module, which constructs path priority using the constraint initial test target set, assigns dynamic weight to the executed path, introduces a monitoring branch mechanism in the software testing system, assigns dynamic weight to the executed path, and dynamically adjusts the test case generation strategy for the requirement document; a test case reconstruction and closed-loop optimization module, which detects the test case generation strategy, triggers test case reconstruction, updates the reconstructed test case to the constraint initial test target set, constructs the path priority again, and completes the automatic testing of the software.

[0038] The above-mentioned each unit module can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to call and execute the operation corresponding to each module by the processor.

[0039] In one embodiment, a computer device, which can be a terminal, is provided, and the computer device includes a processor, a memory, a communication interface, a display screen and an input device connected by a system bus. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is configured to perform wired or wireless communication with external terminals. The wireless communication can be achieved by WIFI, an operator network, NFC (Near Field Communication) or other technologies. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer overlaid on the display screen, or a key, trackball or touchpad arranged on the housing of the computer device, or an external keyboard, touchpad or mouse, etc.

[0040] To sum up, the application improves the accuracy of test case generation and the completeness of requirement coverage by constructing a requirement analysis and test target generation module, combining natural language processing and static analysis technology, automatically extracting data dependency from requirement documents and establishing an initial test target set with constraints. The application effectively improves the coverage of deep paths and high-risk modules by using a path priority model and a runtime monitoring feedback mechanism to realize dynamic weight allocation of test paths and adaptive adjustment of test case generation strategies through a dynamic path scheduling and test strategy adjustment module. The application significantly enhances the response capability of the test system to frequent iterations and the reuse efficiency of test resources by quickly generating test cases adapted to the new version and updating the test target set after software updates through a test case reconstruction and closed-loop optimization module, thereby realizing higher automation, stronger environmental adaptability and more comprehensive coverage of software automatic testing.

[0041] After introducing the method and system of the exemplary embodiments of the application, next, with reference to Figure 3 The computer readable storage medium of the exemplary embodiments of the application is described, please refer to Figure 3The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it implements the steps described in the above method implementation, such as: obtaining the requirements document of the software under test; extracting the data dependencies of the requirements document through static analysis; analyzing the data dependencies using natural language processing technology; establishing a constraint initial test target set covering path inputs and outputs; constructing path priorities using the constraint initial test target set; assigning dynamic weights to the executed paths; introducing a monitoring branch mechanism into the software testing system to monitor the executed paths and assign dynamic weights; dynamically adjusting the test case generation strategy for the requirements document; detecting the test case generation strategy; triggering test case refactoring; updating the refactored test cases to the constraint initial test target set; reconstructing path priorities; and completing automatic software testing. The specific implementation methods of each step will not be repeated here.

[0042] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0043] After introducing the methods and media of exemplary embodiments of the present invention, the following references are made. Figure 4 A computational device for adaptive recovery of low-voltage power grid self-healing control according to an exemplary embodiment of the present invention.

[0044] Figure 4 A block diagram is shown of an exemplary computing device 40 suitable for implementing embodiments of the present invention. The computing device 40 may be a computer system or a server. Figure 4 The computing device 40 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0045] like Figure 4 As shown, the components of computing device 40 may include, but are not limited to: one or more processors or processing units 401, system memory 402, and bus 403 connecting different system components (including system memory 402 and processing unit 401).

[0046] The computing device 40 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computing device 40, including volatile and non-volatile media, and removable and non-removable media.

[0047] The system memory 402 can include computer system readable media in the form of volatile memory, such as random-access memory (RAM) 4021 and / or cache memory 4022. The computing device 40 can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a ROM 4023 can be used for reading a stable, non- volatile, magnetic Figure 4 media (e.g., a "hard disk drive") that is typically carried in a bay of the computing device 40. Although not shown, a magnetic disk drive can also be used for reading and writing a removable, non- volatile magnetic media (e.g., a "floppy disk"), and an optical disk drive can be used for reading and writing a removable, non- volatile optical disk (e.g., a CD-ROM, DVD-ROM or other optical media). In such instances, each drive can be connected to the bus 403 by one or more data media interfaces. The system memory 402 can include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the application. Figure 4

[0048] The program / utility 4025, having a set (at least one) of program modules 4024, can be stored in, for example, system memory 402 and / or another computer readable medium, and loaded into the computer system 400 via the removable storage interface 409, the interface 405 and / or the bus 403. The program modules 4024 include, but are not limited to, boot

[0049] The computing device 40 can also communicate with one or more external devices 404 such as a keyboard, a pointing device, a display, etc. via an input / output (I / O) interface 405. Further, the computing device 40 can communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or the Internet) via a network adapter 406. As Figure 4 illustrated, the network adapter 406 can be communicatively coupled to the other components of the computing device 40 via the bus 403. It should be appreciated that the network adapter 406 can also be utilized to enable connection to other types of networks and / or remote computing devices such as by way of example a mobile telephone network, an Figure 4 extranet, etc.

[0050] ​The processing unit 401 executes various function applications and data processing by running programs stored in the system memory 402, for example, obtains a requirement document of a software to be tested, extracts a data dependency relationship of the requirement document through static analysis, analyzes the data dependency relationship in combination with a natural language processing technology, establishes a constraint initial test target set covering a path input and output, constructs a path priority using the constraint initial test target set, assigns a dynamic weight to an executed path, introduces a monitoring branch mechanism in a software testing system, assigns a dynamic weight to the executed path, dynamically adjusts a test case generation strategy for the requirement document, detects the test case generation strategy, triggers test case reconstruction, updates the reconstructed test case to the constraint initial test target set, constructs a path priority again, and completes automatic software testing.

[0051] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be repeated here.

[0052] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. The device embodiments described above are only schematic, for example, the division of units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some communication interfaces, devices or units, and can be electrical, mechanical or other forms.

[0053] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0054] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0055] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a nonvolatile computer readable storage medium executable by a processor. Based on this understanding, the technical solutions of the present application or the part of the prior art that essentially contributes or the part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0056] Finally, it should be noted that the above embodiments are only specific implementations of the present application, which are used to illustrate the technical solutions of the present application, but not to limit them. The protection scope of the present application is not limited thereto. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can make modifications or easily think of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed by the present application, or make equivalent replacements to some of the technical features; and these modifications, changes or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0057] In addition, although the operations of the method of the present application are described in a specific order in the accompanying drawings, this does not require or imply that the operations must be performed in that specific order, or that all of the shown operations must be performed to achieve the desired result. Additionally or alternatively, some steps can be omitted, combined into one step, and / or divided into multiple steps.

[0058] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and not to limit them. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present application, and they should be covered within the scope of the claims of the present application.

Claims

1. A method for automated software testing, characterized in that: include, Obtain the requirements document of the software to be tested, extract the data dependencies of the requirements document through static analysis, analyze the data dependencies by combining natural language processing technology, and establish an initial test target set covering the input and output of the path; By using the initial test target set of constraints to construct path priorities, dynamic weights are assigned to the executed paths. A monitoring branch mechanism is introduced into the software testing system to monitor the executed paths and assign dynamic weights, thereby dynamically adjusting the test case generation strategy for the requirements document. The test case generation strategy is detected, triggering test case refactoring. The refactored test cases are then updated to constrain the initial test target set, and the path priority is rebuilt to complete the automatic software testing.

2. The method for automated software testing as described in claim 1, characterized in that: The process of obtaining the requirements document for the software under test includes using the interface definition module of the software testing system to obtain the requirements document for the software under test. By utilizing the structure of the requirements document of the software under test, semantic boundary annotation is performed on the content of different types of requirements documents, and functional description rule constraints of semantic boundary annotation are extracted. The process of extracting data dependencies from the requirements document includes preprocessing functional description rule constraints, removing redundant functional description rule constraints, mapping redundant functional description rule constraints, removing mapped functional description rule constraints, and retaining functional description rule constraints that are not redundant.

3. The method for automated software testing as described in claim 2, characterized in that: The analysis of data dependencies using natural language processing technology includes constructing a cross-document data dependency network that is not constrained by redundant functional description rules, combining the calling order in the interface definition module, identifying boundary value conditions that are not constrained by redundant functional description rules, and using the boundary value conditions to analyze the extracted data dependencies. The establishment of the constraint initial test target set covering the input and output of the path includes defining the data dependency relationship analyzed by using boundary value conditions, generating test target units with preconditions, and establishing the constraint initial test target set covering the input and output of the path. The input refers to the requirements document of the software under test, and the output refers to the test results output with the requirements document of the software under test.

4. The method for automated software testing as described in claim 3, characterized in that: The method of constructing path priority using the constrained initial test target set includes extracting the definition-usage path and prerequisites associated with the test target unit from the constrained initial test target set; By combining the faults corresponding to the historical defect database of non-automatic software testing, priority scoring is performed on the paths for constructing the initial test target set of constraints; The process of assigning dynamic weights to the execution paths includes collecting the execution frequency of priority scoring paths, deploying monitoring probes in priority scoring paths, collecting the execution frequency of paths, dynamically matching the data flow of the scoring paths during execution with the preconditions in the initial test target set, and identifying uncovered high-frequency or low-frequency execution paths.

5. The method for automated software testing as described in claim 4, characterized in that: The dynamic weighting of the monitored execution path includes updating the dynamic weight in the path priority score based on the coverage frequency deviation information of the identified uncovered high-frequency or low-frequency execution paths, increasing the weight of uncovered or repeatedly failed execution paths, and using the weight change trend as a condition for the status input of the requirements document of the software under test. The dynamically adjusted test case generation strategy for the requirements document includes a test case generator that drives automatic software testing based on dynamic weight update results, selects high-frequency test cases generated by test target units corresponding to high-frequency execution paths, and uses constraint solving technology to generate test data that satisfies the input space boundary in combination with preconditions, or selects low-frequency test cases generated by test target units corresponding to low-frequency execution paths, and dynamically adjusts the test case generation strategy for the requirements document.

6. The method for automated software testing as described in claim 5, characterized in that: The test case generation strategy includes monitoring the version control of the software under test; When an update to the test cases in the requirements document is detected, the change capture mechanism is triggered. By comparing the differences, the functional modules, interface definitions and associated test target units involved in the change are identified, and the affected definitions, usage paths and preconditions are marked. The secondary construction path priority includes constructing the set of examples to be optimized and generating variant test cases adapted to the new path.

7. The method for automated software testing as described in claim 6, characterized in that: The process of constructing the set of test cases to be optimized includes identifying the affected paths based on tags, locating the test target units that need to be reconstructed in the initial set of constrained test targets, combining the corresponding faults in the generated historical defect database of non-automatic tests, filtering out existing test cases that have data dependencies on the changed paths, and constructing the set of test cases to be optimized. The process of generating variant test cases to adapt to the new path includes performing structural analysis on the test cases in the set of test cases to be optimized, extracting the matching relationship between the combination of input parameters of the set of test cases to be optimized and the preconditions of the corresponding path, using the constraint solver to re-satisfy the input boundaries of the changed preconditions, and generating variant test cases to adapt to the new path by combining the input boundaries of the changed preconditions. The secondary construction of path priority includes injecting the generated variant test cases into the initial test target set of constraints, synchronously updating the preconditions and priority weights of the corresponding paths in the initial test target set of constraints, re-executing the path priority construction, carrying out the next round of automated testing, and completing the automated test cycle of software automated testing.

8. A system for automated software testing, based on the method for automated software testing according to any one of claims 1 to 7, characterized in that: include, The requirements analysis and test target generation module obtains the requirements document of the software under test, extracts the data dependencies of the requirements document through static analysis, analyzes the data dependencies in combination with natural language processing technology, and establishes an initial test target set that covers the input and output of the path. The dynamic path scheduling and test strategy adjustment module uses constraints on the initial test target set to construct path priorities, assigns dynamic weights to the executed paths, introduces a monitoring branch mechanism into the software testing system, monitors the executed paths and assigns dynamic weights, and dynamically adjusts the test case generation strategy for the requirements document. The test case refactoring and closed-loop optimization module detects the test case generation strategy, triggers test case refactoring, updates the refactored test cases to the initial test target set, re-builds path priorities, and completes automatic software testing.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the method for automatic software testing as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the method for automatic software testing as described in any one of claims 1 to 7.

Images