Disclosure of Invention
In view of this, the present disclosure provides a test case generating method, a device, a computer device and a storage medium, so as to solve the technical problems of low automation degree and high test cost of PLC program testing in the industrial control field.
An embodiment of a first aspect of the present disclosure provides a test case generating method, including:
Determining a coverage condition of a control flow based on a control flow graph of a source program to be tested; the control flow graph characterizes the control flow relation among all program sentences in the source program to be tested; the control flow coverage condition comprises covering all control flow paths in the source program to be tested;
Generating a target test case; the target test case is used for testing all control flow paths in the source program to be tested.
According to the embodiment of the invention, the target test cases meeting the control flow coverage conditions are generated, so that the high coverage rate test cases meeting the specified coverage rate criterion can be generated for the source program to be tested in a short time, the test efficiency and the test automation degree of industrial control software are improved, and the test cost is reduced.
In an embodiment of the present disclosure, before determining the control flow coverage requirement based on the control flow graph of the source program to be tested, the method further includes:
Identifying a plurality of grammar units from the character sequence of the source program to be tested;
Constructing a grammar parsing tree according to the plurality of grammar units;
Screening effective program content in the grammar parsing tree to obtain an abstract grammar tree;
And constructing a control flow graph of the source program to be tested based on key sentences in the abstract syntax tree, wherein the key sentences refer to sentences representing control flow executing nodes in the source program to be tested.
The embodiment of the disclosure can reduce redundant information by screening the effective program content in the grammar parsing tree, and focus the program on a key part; constructing an abstract syntax tree is helpful for expressing the syntax structure of the program more clearly, and is convenient for subsequent analysis and processing; the control flow graph of the source program to be tested is constructed through the key sentences in the abstract grammar tree, so that the execution sequence and the conditional branch relation among different sentences in the program can be displayed, and the control flow path coverage rate of the source program to be tested in test can be improved.
In an embodiment of the present disclosure, the abstract syntax tree includes a plurality of node statements, and the constructing a control flow graph of the source program to be tested based on key statements in the abstract syntax tree includes:
taking a first sentence, a skip sentence and a next sentence of the skip sentence in the plurality of node sentences as key sentences;
constructing a basic block based on all sentences between two adjacent key sentences;
And based on the execution sequence of each statement in the source program to be tested, if two adjacent basic blocks meet the condition of sequential execution, connecting the two adjacent basic blocks according to the execution sequence to obtain a control flow diagram of the source program to be tested.
In an embodiment of the present disclosure, the control flow coverage requirement includes a control flow coverage model; the determining the coverage condition of the control flow based on the control flow graph of the source program to be tested comprises the following steps:
Identifying a plurality of control flow paths from the control flow graph;
Generating a test case based on a preset coverage rule and program information of the source program to be tested; the program information comprises an input variable, an output variable and a PLC state;
the test case is applied to the source program to be tested, and the coverage rate of a control flow path is determined based on a test result;
and if the coverage rate is larger than a preset coverage rate, taking the test case as the control flow coverage model.
In an embodiment of the present disclosure, the generating the target test case includes:
Iteratively generating initial test cases to obtain a plurality of initial test cases;
And combining the plurality of initial test cases according to the PLC states corresponding to the plurality of first test cases one by one to obtain a target test case.
In an embodiment of the present disclosure, the PLC states include a PLC start state and a PLC end state; combining the plurality of initial test cases according to the PLC states corresponding to the plurality of first test cases one by one to obtain a target test case, wherein the method comprises the following steps:
and combining the first test case and the other first test case when the PLC ending state of the first test case is the PLC starting state of the other first test case aiming at any one of the plurality of first test cases.
In the embodiment of the present disclosure, the iterative generation of the initial test cases, to obtain a plurality of initial test cases, includes:
screening a target path from a candidate path pool of the control flow coverage model; the target path is an uncovered control flow path; in the first iteration scene, the candidate path pool comprises all control flow paths;
performing inverse processing on the first path constraint of the target path to obtain a second path constraint;
When a set of symbolic variables meeting the second path constraint exists, the set of symbolic variables are used as the first test case;
Deleting the target path from the candidate path pool to obtain a new candidate path pool, and repeatedly executing the screening of the target path from the candidate path pool of the control flow coverage model; performing inverse processing on the first path constraint of the target path to obtain a second path constraint; and when a set of symbolic variables meeting the second path constraint exists, taking the set of symbolic variables as the first test case until the target path does not exist in a candidate path pool.
Embodiments of a second aspect of the present disclosure provide a test case generating apparatus, the apparatus including:
The coverage condition generation module is used for determining the coverage condition of the control flow based on the control flow graph of the source program to be tested; the control flow graph characterizes the control flow relation among all program sentences in the source program to be tested; the control flow coverage condition comprises covering all control flow paths in the source program to be tested;
the target test case generation module is used for generating a target test case; the target test case is used for testing all control flow paths in the source program to be tested.
An embodiment of a third aspect of the present disclosure provides an electronic device, where the electronic device includes a memory and a processor, where the memory and the processor are communicatively connected to each other, and the memory stores computer instructions, and the processor executes the computer instructions, thereby executing the test case generating method described in the first aspect.
Embodiments of the fourth aspect of the present disclosure provide a computer-readable storage medium having stored thereon computer instructions for causing a computer to execute the test case generating method according to the first aspect.
Additional aspects and advantages of the disclosure will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the disclosure.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
It is noted that unless otherwise indicated, technical or scientific terms used in this disclosure should be given the ordinary meaning as understood by one of ordinary skill in the art to which this disclosure pertains.
In accordance with the disclosed embodiments, a test case generating method embodiment is provided, it being noted that the steps shown in the flowcharts of the figures may be performed in a computer system, such as a set of computer executable instructions, and that although a logical order is shown in the flowcharts, in some cases the steps shown or described may be performed in an order other than that shown or described herein.
In this embodiment, a test case generating method is provided, and fig. 1 is a flowchart of a test case generating method according to an embodiment of the disclosure, as shown in fig. 1, where the flowchart includes the following steps:
step S101, determining a coverage condition of the control flow based on the control flow graph of the source program to be tested.
The control flow graph characterizes the control flow relation among all program sentences in the source program to be tested; the control flow override condition includes overriding all control flow paths in the source program under test.
In some embodiments, as shown in fig. 2, before step S101, the method further includes step S201-step S204:
Before step S201, a grammar definition of ST language is obtained from IEC 61131-3 standard, a grammar specification file for parsing ST source code is written according to the grammar definition, and lexical analysis, grammar analysis and semantic analysis of source code are implemented based on the grammar specification. As shown in fig. 3, fig. 3 shows a flow chart of lexical analysis, grammatical analysis and semantic analysis of a segment of ST source code.
Step S201, identifying a plurality of grammar units from the character sequence of the source program to be tested.
In the step, firstly, reading a character sequence of a program to be tested through a lexical analyzer defined by IEC 61131-3 standard ST language grammar; nonsensical factors (such as blank characters and notes) are ignored according to the grammar specification, the character sequence is divided into a plurality of meaningful lexical units (token), and a token list containing the plurality of meaningful lexical units is output.
Step S202, constructing a grammar parsing tree according to the plurality of grammar units.
In this step, the syntax parser is based on the order of the respective lexical units combined according to the syntax rules, thereby constructing a syntax parse tree.
Step S203, filtering the effective program content in the grammar parsing tree to obtain an abstract grammar tree.
In this step, first, a syntax parsing tree is traversed according to a semantic analyzer, and semantic error correlation checking is performed on source codes, for example: checking the type, checking the scope and life cycle of the variables, checking the context-related meaning of the grammar structure, and confirming whether a problem exists in the code logic or not to obtain a grammar analysis tree without semantic errors; after obtaining a parse tree without semantic errors, as shown in FIG. 4: traversing the grammar analysis tree without semantic errors based on a listener mechanism, separating and removing invalid program contents, and constructing an abstract grammar tree. The listener mechanism accesses the syntax analysis tree nodes layer by layer, provides an enter () method when entering each node, and provides an exit () method when leaving the node.
Step S204, a control flow graph of the source program to be tested is constructed based on key sentences in the abstract syntax tree, wherein the key sentences refer to sentences representing control flow execution nodes in the source program to be tested.
In some embodiments, as shown in fig. 5, the step 204 includes steps S2041-S2043:
S2041, using a first sentence, a skip sentence and a next sentence of the skip sentence in the plurality of node sentences as key sentences.
And S2042, constructing a basic block based on all sentences between two adjacent key sentences.
S2043, based on the execution sequence of each statement in the source program to be tested, if two adjacent basic blocks meet the condition of sequential execution, connecting the two adjacent basic blocks according to the execution sequence, and obtaining a control flow diagram of the source program to be tested.
After the abstract syntax tree is obtained in the above steps S2041-S2043, the source code sentence may be divided into basic blocks according to the abstract syntax tree content, for example: taking a first sentence, all skip sentences and the next sentence of all skip sentences of the program as key sentences, wherein all sentences between the two key sentences form a basic block. According to program logic, if two basic blocks can be continuously executed during the execution of a program, the two basic blocks can be connected to construct a source program control flow graph.
In some embodiments, the control flow coverage requirements include an ST language control flow coverage model; the supported coverage criteria, the minimum coverage rate required, the maximum allowed iteration number, the ST source program POU inheritance implementation relation, the ST source program variable list and the program control flow graph can be combined to generate the ST language control flow coverage model. Fig. 6 shows a process of generating an ST language control flow coverage model. The supported coverage criterion, the minimum coverage rate of the requirement and the allowed maximum iteration number are obtained by user input; the ST source program POU inherits the realization relation and the ST source program variable list is obtained when the source code is analyzed; the control flow graph is obtained by traversing an abstract syntax tree.
In some embodiments, as shown in fig. 7, the control flow coverage requirements include a control flow coverage model; step S101 includes steps S1011 to S1014:
Step S1011 identifies a plurality of control flow paths from the control flow graph.
In particular, on a control flow graph basis, it is desirable to identify different control flow paths, i.e., various possible paths from the start point to the end point of the program. These paths should cover various situations and logical branches in the program.
Step S1012, generating a test case based on a preset coverage rule and program information of the source program to be tested; the program information includes input variables, output variables, and PLC states.
Specifically, test cases may be designed to cover each identified control flow path based on user-provided coverage criteria, as well as program information, such as input variables, output variables, and PLC states of the source program. The maximum number of iterations and minimum coverage in the user parameters can be used to set the termination conditions and coverage requirements for the test, as shown in fig. 6.
Step S1013, applying the test case to the source program to be tested for testing, and determining the coverage rate of the control flow path based on the test result.
Step S1014, if the coverage rate is larger than a preset coverage rate, the test case is used as the control flow coverage model.
In steps S1013-S1014, the designed test cases may be first applied to the ST language program to perform a test, and a control flow path passed by each test case when executed may be recorded; then according to the test result, analyzing the covered control flow paths, determining which paths are effectively covered and which paths are not covered yet; then, according to the analysis result, the test cases are adjusted and supplemented to ensure the integrity and the effectiveness of the coverage model; and finally, confirming whether the test case covers all control flow paths of the ST language program, thereby generating a complete control flow coverage model.
Step S102, generating a target test case; the target test case is used for testing all control flow paths in the source program to be tested.
In some embodiments, the coverage condition of the control flow determined in step S101, that is, to cover all control flow paths in the source program under test, may be embodied by an ST language control flow coverage model. The ST language control flow coverage model is input into a dynamic symbol execution engine, and a target test case can be output.
In the disclosed embodiments, the dynamic symbol execution engine is built based on dynamic symbol execution techniques, depth-first search strategies, PLC states, and satisfiability modulo theory. The dynamic symbol execution engine comprises an executor, a filter and an SMT solver; the executor comprises a label type three address code program actual executor corresponding to a source program based on the PLC state and an SMT-LIB format code symbol executor based on a dynamic symbol execution technology.
A tagged triple address code is an intermediate representation between a high-level language and machine code, equivalent to a source program, consisting of tags and statement content. The tags include a general sentence tag Lx (x represents a sentence number, the same applies hereinafter), a skip sentence tag cj_lx, an unconditional skip sentence tag UCJ _lx, an IF sentence start tag if_lx, an ELSE sentence tag else_lx, an IF sentence END tag end_if_lx, a WHILE sentence tag while_lx, a WHILE sentence END tag end_while_lx, and a LOOP body start tag loop_lx. Statement content includes conventional assignment statements and jump statements labeled with goto. The program actual executor is used for executing the ST source program according to given input, and collecting the execution result, the PLC ending state and the control flow path information of the execution coverage as the basis of the dynamic symbol executor.
Since the ST source code cannot be directly input to the satisfiability modulo theory solver, it is necessary to convert the ST source code into SMT-LIB format by a symbol executor. The conversion rule comprises: converting the data type keywords in the ST language into an initial capital form, wherein the custom identifier is unchanged; for basic data types, directly using the data types provided in the SMT-LIB, for data types with range constraints, limiting the range by adding predicate constraints to the SMT-LIB code; for an operator expression, converting it into the form of a prefix expression; and splitting the call of the object-oriented POU attribute into independent attributes for processing. The symbol executor is used for acquiring the constraint on the actual execution result path, and acquiring candidate path information by reversing the constraint condition.
And the candidate path filter is used for selecting a path which is not covered as a target path from all candidate paths according to the depth-first search strategy and the path coverage condition stored in the ST language control flow coverage model.
The candidate path constraint solver is used for processing propositional logic parts in candidate path constraints according to a DPLL (T) algorithm, wherein the DPLL is responsible for processing logic in a specific field, and the T is a modularized theoretical solver. In processing the formula with the adjectives, the solver uses E-Matching techniques to find examples that may satisfy the quantisation formula. In the solution process, constraint propagation techniques are used to reduce the search space. When solutions satisfying all constraints are found, the solver constructs a model to expose the solutions, i.e., single-cycle test cases of the PLC program.
Wherein the program actual executor and the symbol executor together form an executor part in the theory of dynamic symbol execution technology, and together with the candidate path filter and the candidate path constraint solver, form a dynamic symbol execution engine as shown in fig. 8.
In some embodiments, as shown in fig. 9, the step 102 includes steps S1021-S1022:
Step S1021, iteratively generating initial test cases to obtain a plurality of initial test cases.
In some embodiments, the step S1021 further includes steps a 1-a 4:
Step a1, screening a target path from a candidate path pool of the control flow coverage model; the target path is an uncovered control flow path; in the first iteration scenario, the candidate path pool contains all control flow paths.
And a2, performing inverse processing on the first path constraint of the target path to obtain a second path constraint.
And a step a3, when a group of symbolic variables meeting the second path constraint exists, taking the group of symbolic variables as the first test case.
Step a4, deleting the target path from the candidate path pool to obtain a new candidate path pool, and repeatedly executing to screen the target path from the candidate path pool of the control flow coverage model; performing inverse processing on the first path constraint of the target path to obtain a second path constraint; and when a set of symbolic variables meeting the second path constraint exists, taking the set of symbolic variables as the first test case until the target path does not exist in a candidate path pool.
In the steps a 1-a 4, a candidate path which is not covered is selected from a candidate path pool by using a candidate path filter, and formal constraint on the candidate path is acquired by using a symbol executor; inverting the obtained formalized constraints, combining the formalized constraints into an SMT-LIB code program, inputting the SMT-LIB code program into an SMT solver, and if the solver outputs 'sat', indicating that a group of solutions can be found so that the candidate path is established, otherwise, indicating that no solution exists; if the solution exists, analyzing the model file, and acquiring the solution as a group of single-period test cases (namely initial test cases); and then iteratively generating a plurality of single-period test cases.
The process of generating the single-cycle test case is as shown in fig. 10, before invoking the SMT solver to calculate the path constraint, firstly, determining whether the path is covered, if so, directly jumping out of calculation in order to avoid wasting calculation resources; if not already covered, then call the SMT solver to calculate the path constraints. If the SMT solver returns "sat", a set of solutions can be found that meet the path constraint, then the solution model obtains a single cycle test case.
Step S1022, combining the initial test cases according to the PLC states corresponding to the first test cases one by one to obtain the target test case.
In the step, the PLC states include a PLC start state and a PLC end state. The multiple initial test cases may be combined to obtain the target test case by: and combining the first test case and the other first test case when the PLC ending state of the first test case is the PLC starting state of the other first test case aiming at any one of the plurality of first test cases.
Specifically, a plurality of single-period test cases generated in an iteration manner may be combined according to the occurrence sequence of the PLC state to form a multi-period test case set (i.e., a target test case), for example: when the PLC ending state corresponding to one single-period test case is the PLC starting state corresponding to another single-period test case, the PLC ending state and the PLC starting state can be combined.
In some embodiments, the step S1022 further includes: acquiring an initial PLC state according to the content of the ST language control flow coverage model, and randomly generating a group of test cases as initial test cases for any one of the never-occurring PLC states to start a dynamic symbol execution process; after the program is executed by the actual executor, an execution path and a PLC end state are generated, the path is input into a dynamic symbol execution result candidate path filter, a group of candidate paths are obtained and added into a candidate path pool; calling the single-period test case generation method to generate a single-period test case which is not only a part of the final multi-period test case set, but also the input of the next dynamic symbol execution process; after a plurality of single-period test cases are generated in an iteration mode, a single-period test case combination method based on the PLC state appearance sequence is used for combining the single-period test cases to form a multi-period test case set.
Specifically, the generating flow of the multi-period test case set is shown in fig. 11, and before the generating flow is executed, the data structures required for initializing the model are covered according to the ST language control flow, including a candidate path pool and a PLC state pool, and then a circulation process is started. Firstly, selecting a PLC state from a PLC state pool, randomly generating a group of test cases on the basis of the PLC state, and obtaining a coverage path after the actual execution of a program. And reversing the condition constraint on the coverage path through a candidate path filter, and adding the obtained multiple candidate paths into a candidate path pool. And selecting a candidate path, acquiring path constraint of the candidate path, inputting the path constraint into an SMT solver to calculate a group of test cases, and recording the corresponding PLC state. If the state is new, the state is added to the state pool. This set of test cases will also be used as the next input. And repeatedly executing the dynamic symbol execution flow until the candidate path pool is empty. At this time, a new PLC state is selected, and the above steps are repeatedly performed until no new PLC state is generated.
The technical scheme provided by the embodiment of the disclosure can comprise the following beneficial effects:
The embodiment of the disclosure provides a method for generating an IEC 61131-3 standard ST language automation test case, which is characterized in that an abstract syntax tree is obtained according to the definition and analysis of a source code of an ST language standard syntax, program information is obtained through traversing the abstract syntax tree to construct a source program control flow diagram, and an ST language control flow coverage model is generated based on the control flow diagram. And the ST language control flow coverage model is used as input of a dynamic symbol execution engine, guides the dynamic symbol execution process, iteratively generates single-period test cases, and finally combines to obtain a multi-period test case set. The method is based on a dynamic symbol execution technology, and the problem of path explosion when the program scale is overlarge in the traditional symbol execution technology is solved. The method fills the blank that the traditional test case generation method cannot generate the high coverage rate test case for the PLC program, improves the quality of the generated test case, and reduces the test cost.
Furthermore, the application provides a data structure of the PLC state, the PLC state is used for describing the periodic execution result of the PLC, the appearance sequence of the PLC state is used as a standard when the single-period test case is combined, and the problem that the conventional method cannot adapt to the periodic execution of the PLC and the maintenance characteristic of the internal variable value is solved.
Corresponding to the implementation manner of the test case generating method, the embodiment of the disclosure further provides a test case generating device, which is used for executing the test case generating method described in any one of the embodiments illustrated in fig. 1 to 11. As shown in fig. 12, the test case generating device includes:
The coverage condition generation module is used for determining the coverage condition of the control flow based on the control flow graph of the source program to be tested; the control flow graph characterizes the control flow relation among all program sentences in the source program to be tested; the control flow coverage condition comprises covering all control flow paths in the source program to be tested;
the target test case generation module is used for generating a target test case; the target test case is used for testing all control flow paths in the source program to be tested.
Optionally, the apparatus further includes:
The grammar unit identification module is used for identifying a plurality of grammar units from the character sequence of the source program to be detected;
A syntax analysis tree construction module for constructing syntax analysis tree according to the plurality of syntax units;
The abstract syntax tree generation module is used for screening effective program contents in the syntax analysis tree to obtain an abstract syntax tree;
the control flow graph construction module is used for constructing a control flow graph of the source program to be tested based on key sentences in the abstract syntax tree, wherein the key sentences refer to sentences representing control flow execution nodes in the source program to be tested.
Optionally, the abstract syntax tree includes a plurality of node statements, and the control flow graph construction module is further configured to: taking a first sentence, a skip sentence and a next sentence of the skip sentence in the plurality of node sentences as key sentences; constructing a basic block based on all sentences between two adjacent key sentences; and based on the execution sequence of each statement in the source program to be tested, if two adjacent basic blocks meet the condition of sequential execution, connecting the two adjacent basic blocks according to the execution sequence to obtain a control flow diagram of the source program to be tested.
Optionally, the control flow coverage requirement includes a control flow coverage model; the coverage condition generation module is further to: identifying a plurality of control flow paths from the control flow graph; generating a test case based on a preset coverage rule and program information of the source program to be tested; the program information comprises an input variable, an output variable and a PLC state; the test case is applied to the source program to be tested, and the coverage rate of a control flow path is determined based on a test result; and if the coverage rate is larger than a preset coverage rate, taking the test case as the control flow coverage model.
Optionally, the target test case generating module includes:
the initial test case generation unit is used for iteratively generating initial test cases to obtain a plurality of initial test cases;
and the target test case generating unit is used for combining the plurality of initial test cases according to the PLC states corresponding to the plurality of first test cases one by one to obtain the target test case.
Optionally, the PLC state includes a PLC start state and a PLC end state; the target test case generating unit is further configured to: and combining the first test case and the other first test case when the PLC ending state of the first test case is the PLC starting state of the other first test case aiming at any one of the plurality of first test cases.
Optionally, the initial test case generating unit is further configured to: screening a target path from a candidate path pool of the control flow coverage model; the target path is an uncovered control flow path; in the first iteration scene, the candidate path pool comprises all control flow paths; performing inverse processing on the first path constraint of the target path to obtain a second path constraint; when a set of symbolic variables meeting the second path constraint exists, the set of symbolic variables are used as the first test case; deleting the target path from the candidate path pool to obtain a new candidate path pool, and repeatedly executing the screening of the target path from the candidate path pool of the control flow coverage model; performing inverse processing on the first path constraint of the target path to obtain a second path constraint; and when a set of symbolic variables meeting the second path constraint exists, taking the set of symbolic variables as the first test case until the target path does not exist in a candidate path pool.
The test case generating device provided by the above embodiment of the present disclosure and the test case generating method provided by the embodiment of the present disclosure have the same beneficial effects as the method adopted, operated or implemented by the application program stored therein, because of the same inventive concept.
The embodiment of the disclosure also provides an electronic device for executing the test case generation method. Referring to fig. 13, a schematic diagram of an electronic device according to some embodiments of the present disclosure is shown. As shown in fig. 13, the electronic device 13 includes: a processor 1300, a memory 1301, a bus 1302 and a communication interface 1303, wherein the processor 1300, the communication interface 1303 and the memory 1301 are connected through the bus 1302; the memory 1301 stores a computer program executable on the processor 1300, and when the processor 1300 runs the computer program, the method for generating test cases provided by any of the embodiments illustrated in fig. 1 to 11 of the present disclosure is executed.
The memory 1301 may include a high-speed random access memory (Random Access Memory, RAM), and may further include a non-volatile memory (non-volatile memory), such as at least one disk memory. The communication connection between the system network element and the at least one other network element is implemented via at least one communication interface 1303 (which may be wired or wireless), and the internet, a wide area network, a local network, a metropolitan area network, etc. may be used.
Bus 1302 may be an ISA bus, a PCI bus, an EISA bus, or the like. The buses may be classified as address buses, data buses, control buses, etc. The memory 1301 is configured to store a program, and after receiving an execution instruction, the processor 1300 executes the program, and the test case generation method disclosed in any of the foregoing embodiments illustrated in fig. 1 to 11 may be applied to the processor 1300 or implemented by the processor 1300.
Processor 1300 may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the methods described above may be performed by integrated logic circuitry in hardware in processor 1300 or by instructions in software. The processor 1300 may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU for short), a network processor (Network Processor, NP for short), etc.; but may also be a Digital Signal Processor (DSP), application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The various methods, steps and logic blocks of the disclosure in the embodiments of the disclosure may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present disclosure may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in the memory 1301, and the processor 1300 reads the information in the memory 1301, and in combination with its hardware, performs the steps of the above method.
The electronic device provided by the embodiment of the disclosure and the test case generation method provided by the embodiment of the disclosure are the same in the same inventive concept, and have the same beneficial effects as the method adopted, operated or implemented by the electronic device.
The present disclosure further provides a computer readable storage medium corresponding to the test case generating method provided in the foregoing embodiment, referring to fig. 14, the computer readable storage medium is shown as an optical disc 30, and a computer program (i.e. a program product) is stored thereon, where the computer program, when executed by a processor, performs the test case generating method provided in any of the foregoing embodiments.
It should be noted that examples of the computer readable storage medium may also include, but are not limited to, a phase change memory (PRAM), a Static Random Access Memory (SRAM), a Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a flash memory, or other optical or magnetic storage medium, which will not be described in detail herein.
The computer-readable storage medium provided by the above-described embodiments of the present disclosure has the same advantageous effects as the method adopted, operated or implemented by the application program stored therein, because the same inventive concept is adopted by the test case generation method provided by the embodiments of the present disclosure.
It should be noted that:
In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the disclosure may be practiced without these specific details. In some instances, well-known structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the disclosure, various features of the disclosure are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be construed as reflecting the following schematic diagram: i.e., the claimed disclosure requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this disclosure.
Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features but not others included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the disclosure and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.
While the invention has been described with respect to the preferred embodiments, it will be apparent to those skilled in the art that various changes and substitutions can be made herein without departing from the scope of the invention. Therefore, the protection scope of the present disclosure shall be subject to the protection scope of the claims.