CN117632721A - Method and device for generating test case and electronic equipment - Google Patents
Method and device for generating test case and electronic equipment Download PDFInfo
- Publication number
- CN117632721A CN117632721A CN202311612461.XA CN202311612461A CN117632721A CN 117632721 A CN117632721 A CN 117632721A CN 202311612461 A CN202311612461 A CN 202311612461A CN 117632721 A CN117632721 A CN 117632721A
- Authority
- CN
- China
- Prior art keywords
- source program
- program code
- generating
- code
- test case
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 189
- 238000000034 method Methods 0.000 title claims abstract description 38
- 230000004992 fission Effects 0.000 claims abstract description 25
- 238000005516 engineering process Methods 0.000 claims abstract description 21
- 238000004590 computer program Methods 0.000 claims description 5
- 230000003068 static effect Effects 0.000 claims description 4
- 238000013461 design Methods 0.000 abstract description 7
- 230000007547 defect Effects 0.000 abstract description 6
- 238000013522 software testing Methods 0.000 abstract description 5
- 230000006870 function Effects 0.000 description 19
- 238000010586 diagram Methods 0.000 description 7
- 230000035772 mutation Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 230000014509 gene expression Effects 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 244000298715 Actinidia chinensis Species 0.000 description 1
- 235000009434 Actinidia chinensis Nutrition 0.000 description 1
- 235000009436 Actinidia deliciosa Nutrition 0.000 description 1
- 240000009087 Crescentia cujete Species 0.000 description 1
- 235000005983 Crescentia cujete Nutrition 0.000 description 1
- 235000009797 Lagenaria vulgaris Nutrition 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 238000013142 basic testing Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The application provides a method and a device for generating test cases and electronic equipment, and relates to the technical field of software testing, wherein the method comprises the following steps: acquiring a source program code of software to be tested; carrying out grammar analysis on the source program code to obtain a control flow structure corresponding to the source program code; acquiring a key node of a source program code according to a control flow structure, setting a breakpoint in the key node, and acquiring runtime information corresponding to the breakpoint; and generating a target test case through a fission technology according to the runtime information. In the design, the target test cases covering various edge conditions are automatically generated, so that the workload of manual writing can be reduced, the writing efficiency of the target test cases is improved, in addition, the target test cases generated by the fission technology can also cover more code paths, more potential defects and errors can be found conveniently, and the software quality is improved.
Description
Technical Field
The present invention relates to the field of software testing technologies, and in particular, to a method and an apparatus for generating a test case, and an electronic device.
Background
With the continuous development of the software industry, the software testing is increasingly important in the development of software, and at present, the traditional software testing usually generates test cases manually and then tests the software. However, the manual generation of test cases requires a lot of time and effort, resulting in inefficient test case generation. In addition, the test case generated manually is easy to miss and repeat, so that the test coverage rate is insufficient. In addition, the stability and performance of the software are difficult to ensure by the traditional software testing method. Artificially generated test cases are difficult to cover all possible situations, especially boundary conditions and anomalies, which may result in some hidden defects and vulnerabilities not being found.
Disclosure of Invention
In order to at least overcome the defects in the prior art, the purpose of the application is to provide a method and a device for generating test cases and electronic equipment.
In a first aspect, an embodiment of the present application provides a method for generating a test case, where the method for generating a test case includes:
acquiring a source program code of software to be tested;
carrying out grammar analysis on the source program code to obtain a control flow structure corresponding to the source program code;
acquiring a key node of the source program code according to the control flow structure, setting a breakpoint in the key node, and acquiring runtime information corresponding to the breakpoint;
and generating a target test case through a fission technology according to the runtime information.
In one possible implementation manner, the step of obtaining the key node of the source program code according to the control flow structure, setting a breakpoint at the key node, and obtaining runtime information corresponding to the breakpoint includes:
acquiring line number information of a key node of the source program code according to the control flow structure, and setting a breakpoint at the key node through an open source debugger;
and running the source program code by using the open source debugger, and capturing the runtime information corresponding to the breakpoint.
In one possible implementation manner, after the step of generating the target test case according to the runtime information through a fission technology, the method further includes:
testing the source program code based on the target test case, and judging whether the source program code is executed completely or not;
and if the source program code is executed, carrying out coverage rate analysis on the source program code, obtaining code coverage rate and judging whether the code coverage rate reaches a preset target.
In one possible implementation manner, the step of obtaining the code coverage rate and determining whether the code coverage rate reaches a predetermined target includes:
judging whether the code coverage rate is larger than a set value or not;
if not, resetting the breakpoint according to the key node, and testing;
and if the code coverage rate is larger than the code coverage rate, generating a test report containing the code coverage rate.
In one possible implementation manner, the step of generating the target test case according to the runtime information through a fission technology includes:
generating a first target test case according to the control flow structure and the runtime information;
and fissile is carried out on the first target test case, and a second target test case is generated.
In one possible implementation manner, the step of parsing the source program code to obtain a control flow structure corresponding to the source program code includes:
and carrying out static analysis on the source program code through a grammar analyzer to obtain a control flow structure corresponding to the source program code.
In one possible implementation, the source program code is the Objective-C source program code.
In a second aspect, an embodiment of the present application further provides a device for generating a test case, including:
the receiving module is used for acquiring source program codes of the software to be tested;
the grammar analysis module is used for carrying out grammar analysis on the source program code to obtain a control flow structure corresponding to the source program code;
the setting module is used for acquiring key nodes of the source program codes according to the control flow structure, setting break points on the key nodes and acquiring runtime information corresponding to the break points;
and the generating module is used for generating the target test case through a fission technology according to the runtime information.
In a third aspect, embodiments of the present application further provide an electronic device, including:
a memory for storing one or more programs;
and the processor is used for realizing the method for generating the test case provided by the first aspect when the one or more programs are executed by the processor.
In a fourth aspect, an embodiment of the present application further provides a computer readable storage medium, where a computer program is stored, where the computer program is executed by a processor to implement the method for generating a test case provided in the first aspect.
Based on any one of the aspects, the method, the device and the electronic equipment for generating the test cases can acquire a control flow structure by automatically analyzing the structure and logic of source program codes, set breakpoints at key nodes according to the control flow structure to acquire runtime information, and automatically generate target test cases covering various edge conditions based on a fission technology, so that the workload of manual writing can be reduced, the writing efficiency of the target test cases can be improved, and in addition, the target test cases generated by the fission technology can also cover more code paths, so that more potential defects and errors can be found conveniently, and the software quality can be improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following description will briefly explain the drawings required for the embodiments, it being understood that the following drawings illustrate only some embodiments of the present application and are therefore not to be considered limiting of the scope, and that other related drawings may be obtained according to these drawings without the inventive effort of a person skilled in the art.
FIG. 1 is a schematic flow chart of a method for generating test cases provided in this embodiment;
fig. 2 is a schematic diagram of the substeps of step S300 according to the present embodiment;
fig. 3 is a schematic diagram of the substeps of step S500 provided in the present embodiment;
fig. 4 is a schematic diagram of the substeps of step S520 provided in the present embodiment;
fig. 5 is a schematic diagram of the substeps of step S400 provided in the present embodiment;
fig. 6 is a schematic block diagram of an electronic device according to the present embodiment;
fig. 7 is a schematic diagram of a functional module of a test case generating device according to the present embodiment.
Icon: 700-an electronic device; 710-a processor; 720-a computer-readable storage medium; 730—generating means of test cases; 731-a receiving module; 732-a parse module; 733-a setup module; 734-generation module.
Detailed Description
For the purposes of making the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application, which are generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations.
Thus, the following detailed description of the embodiments of the present application, as provided in the accompanying drawings, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.
It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures.
In the description of the present application, it should be noted that, the azimuth or positional relationship indicated by the terms "upper", "lower", etc. are based on the azimuth or positional relationship shown in the drawings, or the azimuth or positional relationship that is commonly put when the product of the application is used, are merely for convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element to be referred to must have a specific azimuth, be configured and operated in a specific azimuth, and therefore should not be construed as limiting the present application. Furthermore, the terms "first," "second," and the like, are used merely to distinguish between descriptions and should not be construed as indicating or implying relative importance.
It should be noted that, in the case of no conflict, different features in the embodiments of the present application may be combined with each other.
The inventor researches and discovers that in the application development of Objective-C, the current main test implementation scheme can be divided into manual test and automatic test. The main tools for automatic testing comprise XCTest frameworks, OCMock and Kiwi frameworks, and Applium and Calabash tools. While these tools may be used for Objective-C application testing, the use of these tools still requires a significant amount of time and effort to write and maintain test cases, and manually writing test cases tends to be difficult to fully cover all code paths, particularly complex logic branches and edge cases, and furthermore, these tools rarely provide testing for performance bottleneck analysis and exception scene handling.
The present embodiment provides a solution to the above problem, and a detailed description of a specific embodiment of the present application will be given below with reference to the accompanying drawings.
Referring to fig. 1, fig. 1 is a flowchart of a method for generating a test case according to the present embodiment, where the method may include the following steps.
Step S100, obtaining source program codes of the software to be tested.
In this embodiment, the source program code of the software under test may be obtained from an open source code library, where the source program code may be written in one or more programming languages.
And step 200, carrying out syntax analysis on the source program code to obtain a control flow structure corresponding to the source program code.
In this embodiment, the source program code obtained in step S100 may be parsed by a programming language parser or a parsing tool, and various syntax structures in the source program code, for example, expressions, sentences, function definitions, etc., are identified, and at the same time, control flow sentences, for example, conditional sentences (if-else), loop sentences (for, while), jump sentences (break, continue), etc., are identified, so as to extract key information in the source program code, for example, information of class definitions, method declarations, attributes, etc., and further obtain the control flow structures, for example, by identifying if sentences and else sentences, a conditional branch structure in a program may be obtained; by identifying sentences such as for circulation, while circulation and the like, a circulation structure in the program can be obtained; by identifying function calls, call relationships between functions can be obtained. The control flow structure is an abstract representation of the source program code that may reflect the structure and semantics of the source program code. The control flow structure may include line number information, parameter information, string information, etc. of the source program code.
In particular, the control flow structure may be presented in a variety of forms, such as a control flow graph (Control Flow Graph, CFG), text information, and the like. A control flow graph is a graphical representation describing the control flow relationships between individual basic blocks in the source program code. A basic block is a continuous piece of code, without entries and exits, typically ending with a conditional branch or jump statement.
Step S300, obtaining key nodes of the source program codes according to the control flow structure, setting break points on the key nodes, and obtaining runtime information corresponding to the break points.
In this embodiment, according to the control flow structure obtained in step S200, a key node of the source program code may be determined, for example, a decision point of a conditional statement, an entry and an exit of a loop statement, an entry and a return point of a function call, etc., and a breakpoint may be set on the determined key node, so when a program executes to a position of the breakpoint, the program may interrupt execution, and at this time, the runtime information corresponding to the breakpoint may be acquired, where the runtime information may include a value of a parameter, a value of a variable, stack information, etc.
Specifically, the critical node corresponds to an important event in the execution of the source program code, and setting a breakpoint can cause the program to suspend the execution of the program when the program is executed to a specific code location, so as to debug or observe the program state.
In the design, by setting the breakpoint on the key node and executing the program while setting the breakpoint, the code portions can be covered when executing the target test case, so as to ensure that the code of the key node is sufficiently tested and covered.
Step S400, generating a target test case through a fission technology according to the runtime information.
In this embodiment, the target test case may be automatically generated based on a fission (mutation) technology according to the syntax information in the control flow structure obtained in step S200 and the runtime information obtained in step S300.
Fission (mutation) technology may be used to detect potential problems and vulnerabilities in the source program code by changing existing test cases or input data, generating new test cases to test different execution paths, thereby simulating various conditions and scenarios in a real environment. Meanwhile, the fission (mutation) technology can also improve the diversity and coverage rate of test cases, thereby improving the test effect and quality.
Based on the design, the method for generating the test cases can automatically analyze the structure and logic of the source program codes to obtain the control flow structure, set breakpoints at the key nodes according to the control flow structure to obtain the runtime information, and automatically generate the target test cases covering various edge conditions based on the fission technology, so that the workload of manual writing can be reduced, the writing efficiency of the target test cases can be improved, in addition, the target test cases can also cover more code paths, more potential defects and errors can be found conveniently, and the software quality can be improved.
In one possible implementation, referring to fig. 2, step S300 may include the following sub-steps.
Step S310, obtaining the line number information of the key node of the source program code according to the control flow structure, and setting a breakpoint at the key node through an open source debugger.
In this embodiment, the line number information of the key node of the source program code may be obtained according to the control flow structure obtained in step S200, and a breakpoint may be set at the key node by the on-source debugger according to the line number information of the key node marked in the source program code.
Specifically, the API of the open source debugger may be imported in a Python script, for example, interacting with the LLDB using the Python API of the LLDB, setting a breakpoint at the key node, and capturing context information at the time of program execution.
Illustratively, the open source debugger may be LLDB (Low Level Debugger), and LLDB may be used to debug a variety of programming languages, including C, C ++, objective-C, and Swit, among others.
Step S320, running the source program code by using the open source debugger, and capturing the runtime information corresponding to the breakpoint.
In this embodiment, when a breakpoint is set at the key node by the on-source debugger, the API of the on-source debugger may be used to run the source program code and trigger the set breakpoint. When a program is executed to the breakpoint, a Python script is triggered, and the API of the open source debugger can be used to obtain the runtime information corresponding to the breakpoint, where the runtime information may include a variable value, a function call stack, and the like.
Specifically, the open source debugger may be LLDB (Low Level Debugger), the LLDB provides a Python script interface, and the runtime information corresponding to the breakpoint may be obtained when the program is executed to the breakpoint by interacting with the LLDB through the Python script.
In the design, the Python script interacts with the LLDB, so that the automatic breakpoint setting can be realized, the workload of manually writing test cases is reduced, and the codes of the key nodes can be ensured to be fully tested and covered.
In one possible implementation, after generating the target test case according to the runtime information through a fission technology, the target test case may be applied to a test framework, and the target test case is executed to evaluate coverage and performance of the target test case.
Specifically, the generated target test case can be executed through an XCTest framework, and the execution conditions, such as whether the test passes or not, the execution time and the like, are monitored. The XCTest framework may be used for unit testing, performance testing, UI testing, etc. for writing and executing applications. Meanwhile, the program state during test execution can be further monitored through the LLDB, for example, the program can be paused during test execution, the values of variables can be checked, the call stack of functions can be observed, and the like, so that problems and errors in the target test case can be found conveniently.
If manual testing is performed, it is difficult to fully simulate abnormal conditions and performance bottlenecks, which easily results in reduced stability and performance of applications in the face of complex scenarios, while in this embodiment, by combining an XCTest framework and an LLDB debugger to execute and monitor the execution conditions of the target test cases, various runtime parameters and environmental conditions can be simulated, abnormal processing and performance of the software can be automatically tested, robustness and high performance of applications can be ensured, and in addition, code coverage can be gradually improved, potential problems and errors can be found, thereby improving quality and reliability of the software
Referring to fig. 3, after step S400, the method for generating a test case may further include the following steps.
And step S510, testing the source program code based on the target test case, and judging whether the source program code is executed completely or not.
In this embodiment, the test framework may be used to test the source program code based on the target test case, and by monitoring the trigger condition of the breakpoint and the execution condition of the test logic, it may be determined whether the source program code is executed completely. Illustratively, the test framework may be an XCTest framework.
Specifically, if all breakpoints set have been triggered and the associated test logic has been executed, then the source code may be deemed to be executed, at which point coverage analysis may be performed on the source code. If a code path is not executed in the test process, that is, the source program code is not executed, other functions can be continuously executed from the next breakpoint until the code is executed.
When the source program code fails to execute, the source program code is considered to be executed, and the coverage analysis is performed on the source program code without re-executing the source program code.
And step S520, if the source program code is executed, carrying out coverage rate analysis on the source program code, obtaining code coverage rate and judging whether the code coverage rate reaches a preset target.
In this embodiment, if it is determined in step S510 that the source program code is executed, a code coverage tool, such as JaCoCo, emma, etc., may be used to perform coverage analysis on the source program code and obtain the code coverage, so as to determine whether the target test case covers each portion of the source program code, where the code coverage may include statement coverage, branch coverage, path coverage, etc.
In the design, by testing the target test case, judging whether the source program code is executed completely or not and judging whether the code coverage rate reaches a preset target or not, the coverage rate and the performance of the target test case can be effectively evaluated and optimized, meanwhile, the test efficiency can be improved, and the software quality can be improved.
In one possible implementation, referring to fig. 4, step S520 may further include the following sub-steps.
Step S521, determining whether the code coverage is greater than a set value.
And step S522, if not, resetting the breakpoint according to the key node, and testing.
And step S523, if the code coverage rate is greater than the code coverage rate, generating a test report containing the code coverage rate.
In this embodiment, after the code coverage is obtained, the code coverage may be compared with the set value, and whether the code coverage is greater than the set value may be determined, so as to determine whether all important code paths have been covered by the target test case. If the code coverage is smaller than the set value, the breakpoint needs to be reset in step S200, and the target test case is rebuilt. If the code coverage rate is greater than or equal to the set value, a test report containing the code coverage rate can be generated according to a test result, so that the code coverage rate and the execution path coverage condition are further analyzed to evaluate the diversity of the target test case and the improvement condition of the code coverage rate, and performance data of the source program code and the abnormality occurring in the test process can be collected to inform a developer of potential problems and improvement points.
If the source program code fails to execute, it is indicated that the generated target test case does not meet the specification, that is, the generated target test case fails to cover the relevant code path, at this time, the code coverage rate is less than 100%, and the breakpoint needs to be reset in step S200, and the target test case is re-generated. Specifically, the code coverage rate is a measure index for covering code paths of various sentences, branches, functions and the like in the source code by the measurement case. If the code coverage rate is less than 100%, the target test case is not covered to all parts of the source program code. Thus, the set value may be 100%.
During execution of the source program code, it may be temporarily recorded whether the current breakpoint (function) is covered. After the source program code is executed, the code coverage rate may be accumulated, and in step S200, the breakpoint related to the code that fails to execute may be reset, so as to regenerate the corresponding target test case, and ensure that the target test case covers the code portion that includes the critical position.
Specifically, the set value is a preset coverage target, and in actual operation, it is difficult to completely achieve 100% of test coverage due to complexity and diversity of the code function, and thus the set value may be 90%.
The magnitude of the set value may be adjusted according to actual conditions, and is not particularly limited herein.
In the design, whether the code coverage rate reaches a preset target or not is judged, and when the code coverage rate does not reach the preset target, a breakpoint is reset, the target test case is regenerated, and the automatically generated target test case can be covered on more code paths, so that the coverage rate and the effectiveness of the target test case are improved.
In one possible implementation, referring to fig. 5, step S400 may include the following sub-steps.
Step S410, generating a first target test case according to the control flow structure and the runtime information.
In this embodiment, the first target test case may be generated by a fission technology according to the control flow structure obtained in step S200 and the runtime information obtained in step S300.
In the first implementation manner of this embodiment, the control flow structure obtained in step S200 and the runtime information obtained in step S300 may be used to obtain the expression of the breakpoint, extract specific numerical values of LHS (Left Hand Side) and RHS (Right Hand Side) in the expression, use a numerical value capable of being passed through self.xx or a parameter as a variable value, and use another numerical value as a reference value, thereby generating the first target test case.
In the second implementation manner of this embodiment, according to the control flow structure obtained in step S200 and the runtime information obtained in step S300, a constant value and a constant string in the source code program may be extracted, and the extracted constant value and constant string may be used as reference values, so as to generate the first target test case.
In the third implementation manner of this embodiment, the random number may be used as a reference value according to the control flow structure obtained in step S200 and the runtime information obtained in step S300, so as to generate the first target test case.
Step S420, fission is carried out on the first target test case, and a second target test case is generated.
In this embodiment, the first target test case obtained in step S410 may be subjected to fission (mutation), so as to generate a new second target test case, so as to cover different execution paths. The number of the second target test cases may be a plurality.
Specifically, the reference value obtained in step S410 may be fissionally set, for example, 1 is fissionally set to a plurality of values such as-1, 0, 1, etc., and the fissionally set values are set as function parameters and run, so as to generate a new second target test case.
When the first target test case and the second target test case are generated, the granularity of the case generation is a single function, that is, the first target test case and the second target test case are generated corresponding to a certain function. After the second target test case is generated, judging whether all codes of the function are covered or not, if not, continuing to fission the first target test case, and generating a new second target test case until all code blocks are covered; if all codes of the function are covered, ending the generation of the target test case corresponding to the function, continuing to set a breakpoint of the next function, and further generating the corresponding first target test case and second target test case. Thus, multiple target test cases can be generated for a single function to increase the diversity of the target test cases.
After the first target test case and the second target test case are generated, when the execution conditions of the target test cases are executed and monitored through a test framework XCTEST and an open source debugger LLDB, the source program codes can be tested based on the first target test case and the second target test case so as to evaluate the coverage rate and the performance of the first target test case and the second target test case.
In the design, the first target test case is fissile, and the second target test case is generated, so that the diversity and the comprehensiveness of the target test case can be increased, and the code coverage rate is further improved.
In a possible implementation manner, in step S200, when the source program code is parsed to obtain the control flow structure corresponding to the source program code, the syntax parser may perform static analysis on the source program code, and extract key information in the source program code, so as to obtain the control flow structure corresponding to the source program code. The control flow structure may be presented in a variety of forms, such as a control flow graph, text information, and the like. The control flow structure may include line number information, parameter information, string information, etc. of the source program code.
Specifically, the parser may be OCLint, which is a static code parsing tool that may be used for C, C ++ and Objective-C code. The format of the control flow structure output through the parser ocline may be html, json, xcode or the like.
In one possible implementation, the source program code may be the Objective-C source program code.
The inventor researches find that in the prior art, test cases can be generated through a preset test template, so that some basic test cases can be generated quickly, and the time for writing the test cases is saved. However, the preset test templates are usually fixed, and cannot adapt to various different test scenarios and requirements, so that the generated test cases lack diversity and flexibility, and the limited test templates provided in the prior art may result in the failure to generate a comprehensive and effective test case under a specific language or framework, such as a specific programming language or framework like Objective-C. In addition, manual intervention is also required in the process of generating test cases in this way to adjust and confirm the test cases, which increases the complexity of test case generation and reduces the level of automation. The method for generating the test cases can automatically adapt and generate the target test cases aiming at the characteristic of Objective-C through advanced grammar analysis and runtime information processing, so that manual intervention is reduced, and the generation efficiency of the target test cases is improved.
Based on the same inventive concept, the present embodiment further provides an electronic device 700, please refer to fig. 6, and fig. 6 illustrates a block schematic diagram of the electronic device 700. The electronic device 700 includes a test case generating device 730, a computer readable storage medium 720, and a processor 710.
The computer readable storage medium 720 and the processor 710 are directly or indirectly electrically connected to each other to realize data transmission or interaction. For example, the components may be electrically connected to each other via one or more communication buses or signal lines. The test case generating device 730 includes a plurality of software function modules that may be stored in the computer readable storage medium 720 in the form of software or firmware (firmware) or cured in an Operating System (OS) of the test case generating device 730. The processor 710 is configured to execute executable modules stored in the computer-readable storage medium 720, such as software functional modules and computer programs included in the test case generating device 730.
The computer readable storage medium 720 may be, but is not limited to, a random access Memory (Random Access Memory, RAM), a Read Only Memory (ROM), a programmable Read Only Memory (Programmable Read-Only Memory, PROM), an erasable Read Only Memory (Erasable Programmable Read-Only Memory, EPROM), an electrically erasable Read Only Memory (Electric Erasable Programmable Read-Only Memory, EEPROM), etc. Wherein the computer readable storage medium 720 is used for storing a program, and the processor 710 executes the program after receiving an execution instruction.
The processor 710 may be an integrated circuit chip with signal processing capabilities. The processor 710 may be a general-purpose processor 710, including a central processor 710 (Central Processing Unit, CPU for short), a network processor 710 (Network Processor, NP for short), etc.; but may also be a digital signal processor 710 (DSP), application Specific Integrated Circuit (ASIC), field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. The general purpose processor 710 may be a microprocessor 710 or the processor 710 may be any conventional processor 710 or the like.
Referring to fig. 7, an embodiment of the present application further provides a generating device 730 for a test case. The test case generating device 730 includes a plurality of functional modules that can be stored in the form of software in the computer-readable storage medium 720. Functionally, the test case generating device 730 may include a receiving module 731, a parsing module 732, a setting module 733, and a generating module 734. Wherein:
the receiving module 731 may be configured to obtain source program code of the software under test.
In this embodiment, the receiving module 731 may be used to perform step S100 shown in fig. 1, and for a specific description of the receiving module 731, reference may be made to the description of step S100.
The parsing module 732 may be configured to parse the source program code to obtain a control flow structure corresponding to the source program code.
In this embodiment, the parsing module 732 may be used to perform step S200 shown in fig. 1, and for a specific description of the parsing module 732, reference may be made to the description of step S200.
The setting module 733 may be configured to obtain a key node of the source program code according to the control flow structure, and set a breakpoint at the key node, to obtain runtime information corresponding to the breakpoint.
In this embodiment, the setting module 733 may be used to perform step S300 shown in fig. 1, and a specific description of the setting module 733 may refer to a description of the step S300.
The generating module 734 may be configured to generate the target test case via fission techniques based on the runtime information.
In this embodiment, the generating module 734 may be configured to perform the step S400 shown in fig. 1, and for a specific description of the generating module 734, reference may be made to the description of the step S400.
In summary, the embodiment of the application provides a method, a device and an electronic device for generating a test case, which can obtain a control flow structure by automatically analyzing the structure and logic of source program codes, set breakpoints at key nodes according to the control flow structure to obtain runtime information, and automatically generate a target test case covering various edge conditions based on a fission technology, so that the workload of manual writing can be reduced, the writing efficiency of the target test case can be improved, in addition, the target test case generated by the fission technology can also cover more code paths, so that more potential defects and errors can be found conveniently, and the software quality can be improved.
The foregoing description is only of the preferred embodiments of the present application and is not intended to limit the same, but rather, various modifications and variations may be made by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.
It will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned.
Claims (10)
1. A method for generating test cases, the method comprising:
acquiring a source program code of software to be tested;
carrying out grammar analysis on the source program code to obtain a control flow structure corresponding to the source program code;
acquiring a key node of the source program code according to the control flow structure, setting a breakpoint in the key node, and acquiring runtime information corresponding to the breakpoint;
and generating a target test case through a fission technology according to the runtime information.
2. The method for generating test cases according to claim 1, wherein the step of obtaining the key node of the source program code according to the control flow structure, setting a breakpoint at the key node, and obtaining runtime information corresponding to the breakpoint comprises:
acquiring line number information of a key node of the source program code according to the control flow structure, and setting a breakpoint at the key node through an open source debugger;
and running the source program code by using the open source debugger, and capturing the runtime information corresponding to the breakpoint.
3. The method for generating test cases according to claim 1, wherein after the step of generating the target test cases by fission technique according to the runtime information, the method further comprises:
testing the source program code based on the target test case, and judging whether the source program code is executed completely or not;
and if the source program code is executed, carrying out coverage rate analysis on the source program code, obtaining code coverage rate and judging whether the code coverage rate reaches a preset target.
4. The method for generating test cases according to claim 3, wherein the step of acquiring the code coverage and judging whether the code coverage reaches a predetermined target comprises:
judging whether the code coverage rate is larger than a set value or not;
if not, resetting the breakpoint according to the key node, and testing;
and if the code coverage rate is larger than the code coverage rate, generating a test report containing the code coverage rate.
5. The method for generating test cases according to claim 1, wherein the step of generating the target test cases by fission technology according to the runtime information comprises:
generating a first target test case according to the control flow structure and the runtime information;
and fissile is carried out on the first target test case, and a second target test case is generated.
6. The method for generating test cases according to claim 1, wherein the step of parsing the source program code to obtain a control flow structure corresponding to the source program code comprises:
and carrying out static analysis on the source program code through a grammar analyzer to obtain a control flow structure corresponding to the source program code.
7. The method of claim 1, wherein the source code is an Objective-C source code.
8. A test case generating apparatus, comprising:
the receiving module is used for acquiring source program codes of the software to be tested;
the grammar analysis module is used for carrying out grammar analysis on the source program code to obtain a control flow structure corresponding to the source program code;
the setting module is used for acquiring key nodes of the source program codes according to the control flow structure, setting break points on the key nodes and acquiring runtime information corresponding to the break points;
and the generating module is used for generating the target test case through a fission technology according to the runtime information.
9. An electronic device, comprising:
a memory for storing one or more programs;
a processor, which when executed by the processor, implements the method of any of claims 1-7.
10. A computer readable storage medium, having stored thereon a computer program, characterized in that the computer program, when executed by a processor, implements the method according to any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311612461.XA CN117632721A (en) | 2023-11-28 | 2023-11-28 | Method and device for generating test case and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311612461.XA CN117632721A (en) | 2023-11-28 | 2023-11-28 | Method and device for generating test case and electronic equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117632721A true CN117632721A (en) | 2024-03-01 |
Family
ID=90017671
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311612461.XA Pending CN117632721A (en) | 2023-11-28 | 2023-11-28 | Method and device for generating test case and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117632721A (en) |
-
2023
- 2023-11-28 CN CN202311612461.XA patent/CN117632721A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107704392B (en) | Test case processing method and server | |
| US9015671B2 (en) | Integrating program construction | |
| US20110191752A1 (en) | Method and System for Debugging of Software on Target Devices | |
| CN110704306A (en) | Assertion processing method, device, equipment and storage medium in test | |
| CN107329889B (en) | Method for automatically testing C compiler | |
| Usman et al. | TEGDroid: Test case generation approach for android apps considering context and GUI events | |
| CN111104319A (en) | Code coverage rate testing method and device, electronic equipment and storage medium | |
| US10229029B2 (en) | Embedded instruction sets for use in testing and error simulation of computing programs | |
| CN117493188A (en) | Interface testing method and device, electronic equipment and storage medium | |
| CN105354035A (en) | Method for compiling test case of web engineering | |
| CN112084108A (en) | Test script generation method and device and related components | |
| CN110955605A (en) | Method for verifying single step dynamic execution by CPU | |
| CN117632721A (en) | Method and device for generating test case and electronic equipment | |
| Neukirchen et al. | An approach to quality engineering of TTCN-3 test specifications | |
| Kim et al. | A two-step approach for pattern-based API-call constraint checking | |
| CN112162921B (en) | Industrial automation test and control system | |
| KR101251792B1 (en) | Embedded Software Unit Test Automation Tool and Method Using Debugger | |
| Lopes et al. | Static analysis tools, a practical approach for safety-critical software verification | |
| Gossens et al. | View graphs for analysis and testing of programs at different abstraction levels | |
| Duarte et al. | Extraction of probabilistic behaviour models based on contexts | |
| Zhang et al. | Are the Scala Checks Effective? Evaluating Checks with Real-world Projects | |
| Ginelli | Understanding and Improving Automatic Program Repair: A Study of Code-removal Patches and a New Exception-driven Fault Localization Approach | |
| Chockler et al. | Validation of evolving software | |
| CN113190453A (en) | User interface testing method, device, server and medium | |
| Khatak | Test case selection and prioritzation for object-oriented software based on slicing and coupling |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |