A software error seeding method and system based on software requirements

Abstract

This invention relates to the field of software testing technology, and proposes a software bug-planting method and system based on software requirements. The method includes the following steps: analyzing software requirements to determine software requirement characteristics and their characteristic states; determining combinations of characteristic states for multiple software requirement characteristics; identifying valid characteristic state combinations to generate identified characteristic state combinations, and determining the software output of the identified characteristic state combinations; constructing software errors for the identified characteristic state combinations based on the software output; and using the software errors to bug-plant the source program to generate bug-planted software. This invention can assess the software test coverage of software requirements based on software requirements, and simultaneously assess the ability of software testing to discover software problems using the bug-planted source program as the implementation carrier. Therefore, it can simultaneously assess and accept the two core objectives of software testing, greatly improving the effectiveness and sufficiency of software test acceptance.

Description

Technical Field

[0001] This invention generally relates to the field of software testing technology. Specifically, this invention relates to a software bug seeding method and system based on software requirements. Background Technology

[0002] Software testing is an important way to verify whether software can achieve its specified functional requirements, and it is also an effective means of discovering software defects. Therefore, determining whether software testing has fully verified the software requirements and discovered software problems is an issue that must be considered during software testing acceptance.

[0003] Currently, software testing and acceptance are mainly conducted in two ways. One approach starts with the software requirements, reviewing the software test documentation at key stages to ensure it covers the requirements outlined in the documentation. However, this method relies solely on the test documentation; the software itself doesn't participate in the acceptance process, thus lacking supporting verification data and making it difficult to evaluate the acceptance effectiveness. The other approach starts with the software source code, using testing tools to calculate source code test coverage during software testing and reviewing the coverage figures in the statistics file during software testing and acceptance. However, this method is detached from the software requirements, only calculating coverage at the programming language level. Therefore, a method is needed that effectively combines software requirements and the software source code during the software testing and acceptance process. Summary of the Invention

[0004] To at least partially solve the aforementioned problems in the prior art, this invention proposes a software bug seeding method based on software requirements, characterized by comprising the following steps:

[0005] Analyze software requirements to determine their characteristics and status.

[0006] Determine the combination of feature states for multiple software requirement features;

[0007] Valid feature state combinations are identified to generate identified feature state combinations, and the software output of the identified feature state combinations is determined.

[0008] A software error is constructed based on the software output as the combination of the identifier feature states; and

[0009] The software bug is used to bug-plant the source program to generate bug-planting software.

[0010] In one embodiment of the present invention, analyzing software requirements to determine software requirement characteristics and their characteristic states includes:

[0011] Analyzing the execution conditions of software requirements, the set C of software requirement characteristics is expressed as follows:

[0012] C = {Ci |i=1,2……N}

[0013] Where N represents the number of software requirement features, C i Represents the i-th software requirement feature; and

[0014] Let the i-th software requirement feature C i Feature state set S i It can be expressed as the following formula:

[0015] S i ={S (i，j) |j=1,2……M}

[0016] Where M represents the i-th software requirement feature C i The number of characteristic states, S (i，j) Let C represent the i-th software requirement feature. i The j-th feature state.

[0017] In one embodiment of the present invention, determining the feature state combination of multiple software requirement features includes calculating the feature state combination of multiple software requirement features using a Cartesian product algorithm, expressed as follows:

[0018] S1×S2…S N ={(x1, x2, ..., x...} N |x1∈S1^x2∈S2…x N ∈S N}

[0019] In one embodiment of the present invention, identifying valid feature state combinations to generate identified feature state combinations, and determining the software output of the identified feature state combinations, includes the following steps:

[0020] Based on the application context of the software requirements, eliminate impossible and unassessable feature state combinations to determine effective feature state combinations.

[0021] Valid feature state combinations are identified to generate identifier feature state combinations; and

[0022] The software output set P&O, which determines multiple combinations of identifier feature states, is expressed as follows:

[0023] P&O = {P&O} k |k=1,2…V}

[0024] Where V represents the number of combinations of identifier feature states, P&O k This represents the software output of the k-th identifier feature state combination.

[0025] In one embodiment of the present invention, constructing a software error based on the combination of identifier feature states as the software output includes the following steps:

[0026] The assessment requirements for the identification feature state combinations and their software outputs are determined based on the software's functional characteristics, boundary characteristics, performance characteristics, and interface characteristics; and

[0027] The software error set (ERR) is constructed based on the aforementioned assessment requirements, where the software error set is represented by the following formula:

[0028] ERR = {ERR} i |i=1,2……Z}

[0029] Where Z represents the number of software errors, ERR i This indicates the i-th software error.

[0030] In one embodiment of the present invention, the method of using the software error to error-seed the source program to generate error-seeding software includes the following steps:

[0031] Determine the location where the software error occurs within the combination of the identifier feature states; and

[0032] Using equivalence class partitioning and source program structure-oriented design methods, the software error set is encoded and implemented in the source program to generate error seeding software.

[0033] In one embodiment of the present invention, the software bug seeding method based on software requirements further includes:

[0034] Test cases were executed on the error-seeding software, and the execution results and software problems found were recorded; and

[0035] The number of software problems and the number of software errors are compared to evaluate and accept the software.

[0036] This invention also proposes a software bug seeding system based on software requirements, which includes:

[0037] The feature state analysis module is configured to analyze software requirements to determine software requirement features and their feature states;

[0038] The feature identification module is configured to determine feature state combinations of multiple software requirement features, identify valid feature state combinations to generate identified feature state combinations, and determine the software output of the identified feature state combinations.

[0039] A software error generation module is configured to construct a software error based on the software output as the combination of identifier feature states; and

[0040] Error-seeding module, which is configured to use the software errors to error-seed the source program to generate error-seeded software.

[0041] The present invention also proposes a computer-readable storage medium having a computer program stored thereon, the computer program performing the steps according to the method when executed by a processor.

[0042] The present invention also proposes an instruction processing system, comprising:

[0043] A processor, configured to execute machine-executable instructions; and

[0044] A memory having machine-executable instructions stored thereon, which, when executed by a processor, perform the steps according to the method.

[0045] This invention offers at least the following advantages: Addressing the problem of existing technologies failing to effectively integrate software requirements and source code during software testing and acceptance, this invention designs software errors based on a thorough and comprehensive analysis of software requirements. It employs a structured method to seed errors in the source code, thereby constructing a closed-loop assessment framework for software testing and acceptance. By inputting test cases into this framework, the effectiveness and sufficiency of the test cases can be verified. Furthermore, by analyzing the framework's output (i.e., the problems discovered by the software test cases), the software testing work can be evaluated, and software testing acceptance can be completed. This achieves the goal of conducting a closed-loop assessment of software testing work by integrating software requirements and source code. Attached Figure Description

[0046] To further illustrate the advantages and other features of the various embodiments of the present invention, a more specific description of the embodiments of the present invention will be presented with reference to the accompanying drawings. It is understood that these drawings depict only typical embodiments of the invention and are therefore not intended to limit its scope. In the drawings, identical or corresponding parts will be indicated by the same or similar reference numerals for clarity.

[0047] Figure 1 A computer system implementing the system and / or method according to the present invention is shown.

[0048] Figure 2 The diagram shows a flowchart of a software bug seeding method based on software requirements in one embodiment of the present invention.

[0049] Figure 3 A schematic diagram illustrating the structure of a software requirement in one embodiment of the present invention is shown.

[0050] Figure 4A schematic diagram of a software requirement feature state combination and its design output is shown in one embodiment of the present invention.

[0051] Figure 5 A flowchart illustrating a software design error in one embodiment of the present invention is shown.

[0052] Figure 6 The diagram illustrates a process of seeding errors into a software source program according to one embodiment of the present invention. Detailed Implementation

[0053] It should be noted that the components in the various figures may be shown exaggeratedly for illustrative purposes and are not necessarily to scale. In each figure, the same reference numerals are used for components that are identical or have the same function.

[0054] In this invention, unless otherwise specified, "arranged on," "arranged above," and "arranged on" do not exclude the possibility of an intermediate element between them. Furthermore, "arranged on or above" merely indicates the relative positional relationship between two components, and in certain cases, such as when the product orientation is reversed, it can also be converted to "arranged below or under," and vice versa.

[0055] In this invention, the various embodiments are merely intended to illustrate the solutions of the invention and should not be construed as limiting.

[0056] In this invention, unless otherwise specified, the quantifiers “a” and “one” do not exclude scenarios involving multiple elements.

[0057] It should also be noted that, in the embodiments of the present invention, only a portion of the components or parts may be shown for clarity and simplicity. However, those skilled in the art will understand that, under the teachings of the present invention, necessary components or parts can be added as needed for specific scenarios. Furthermore, unless otherwise stated, features in different embodiments of the present invention can be combined with each other. For example, a feature in the second embodiment can replace a corresponding or functionally identical or similar feature in the first embodiment, and the resulting embodiment will also fall within the scope of disclosure or description of this application.

[0058] It should also be noted that, within the scope of this invention, the terms "same," "equal," and "equal to" do not imply that the two values ​​are absolutely equal, but rather allow for a certain reasonable margin of error. In other words, the terms also encompass "substantially the same," "substantially equal," and "substantially equal to." Similarly, in this invention, the directional terms "perpendicular to," "parallel to," etc., also encompass the meanings of "substantially perpendicular to" and "substantially parallel to."

[0059] Furthermore, the numbering of the steps in the methods of the present invention does not limit the execution order of the method steps. Unless otherwise specified, the method steps may be executed in different orders.

[0060] This invention can be used for software testing and acceptance. After software testing is completed, bug seeding is performed on the software source code based on software requirements analysis, thereby constructing a closed-loop evaluation framework. After the software test cases are re-input into this closed-loop evaluation framework, evaluation results can be output, and software testing evaluation and acceptance can be completed based on the quantified evaluation results.

[0061] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0062] Figure 1 An instruction processing system 100 implementing the system and / or method according to the present invention is shown. Unless otherwise specified, the method and / or system according to the present invention can be implemented in... Figure 1 The instructions shown are executed in instruction processing 100 to achieve the purpose of this invention.

[0063] like Figure 1 As shown, the instruction processing system 100 includes a central processing unit (CPU) 101, a memory 102, a memory mapping register 103, an external address bus 104, an external data bus 105, a control bus 106, and on-chip peripherals / registers mapped to I / O space 107. The CPU 101 executes machine-executable instructions and controls the operation of the entire system. The memory 102 stores machine-executable instructions and includes non-volatile memory (ROM / Flash) and volatile memory (SARAM, DARAM B0, B1, B2). The non-volatile memory can, for example, store Basic Input / Output System (BIOS) data for basic routines used to implement information transfer at startup, while the volatile memory provides faster access speeds for the system's running memory. The memory mapping register 103 maps different memory units to a unified address space for easy access by the CPU 101. The external address bus 104 transmits memory addresses issued by the CPU 101 to specify the memory unit to be accessed. The external data bus 105 is used for data transmission. The control bus 106 is used for transmitting control signals to control the operation of various components. The on-chip peripherals / registers mapped to the I / O space 107 are used to control peripherals.

[0064] When the present invention is Figure 1When implemented on the instruction processing system 100, the software requirements can be used as the original basis to assess the extent to which the software tests cover the software requirements. At the same time, the source program with error seeding can be used as the implementation carrier to directly assess the ability of the software tests to discover software problems. Therefore, the two core objectives of software testing can be assessed and accepted at the same time, which greatly improves the effectiveness and sufficiency of software test acceptance.

[0065] Furthermore, the embodiments can be provided as computer program products that may include one or more machine-readable media on which machine-executable instructions are stored, which, when executed by one or more machines such as a computer, computer network, or other electronic equipment, may cause one or more machines to perform operations according to the embodiments of the present invention. Machine-readable media may include, but are not limited to, floppy disks, optical disks, CD-ROMs (compact disc read-only memory) and magneto-optical disks, ROMs (read-only memory), RAMs (random access memory), EPROMs (erasable programmable read-only memory), EEPROMs (electrically erasable programmable read-only memory), magnetic or optical cards, flash memory, or other types of media / machine-readable media suitable for storing machine-executable instructions.

[0066] Furthermore, various embodiments can be downloaded as computer program products, wherein the program can be transmitted from a remote computer (e.g., a server) to a requesting computer (e.g., a client) via a communication link (e.g., a modem and / or a network connection) using one or more data signals implemented and / or modulated by a carrier wave or other propagation medium. Therefore, the machine-readable medium used herein may include such a carrier wave, but this is not required.

[0067] In this invention, the modules of the system according to the invention can be implemented using software, hardware, firmware, or a combination thereof. When a module is implemented using software, its function can be implemented through computer program flow. For example, the module can be implemented using code segments (such as code segments in languages ​​like C and C++) stored in a storage device (such as a hard disk, memory, etc.), wherein the corresponding function of the module can be implemented when the code segment is executed by a processor. When a module is implemented using hardware, its function can be implemented by setting a corresponding hardware structure. For example, the module's function can be implemented by hardware programming a programmable device such as a field-programmable gate array (FPGA), or by designing an application-specific integrated circuit (ASIC) that includes multiple transistors, resistors, capacitors, and other electronic devices. When a module is implemented using firmware, the module's function can be written into a read-only memory such as an EPROM or EEPROM in the form of program code, and the corresponding function of the module can be implemented when the program code is executed by a processor. In addition, some functions of the module may need to be implemented by separate hardware or by working in cooperation with the hardware. For example, the detection function is implemented by the corresponding sensor (such as a proximity sensor, accelerometer, gyroscope, etc.), the signal transmission function is implemented by the corresponding communication device (such as a Bluetooth device, infrared communication device, baseband communication device, Wi-Fi communication device, etc.), the output function is implemented by the corresponding output device (such as a display, speaker, etc.), and so on.

[0068] Figure 2 This diagram illustrates a flowchart of a software bug seeding method based on software requirements, according to one embodiment of the present invention. This method is applied to the acceptance phase after software testing has been completed and test cases have been incorporated into configuration management, such as... Figure 2 As shown, the method includes the following steps:

[0069] Step 1: Analyze the software requirements and extract the software's requirement features and their characteristic states. Software requirement features could include, for example, the emission intensity and emission angle of a laser emission function. Taking the emission angle requirement as an example, it can have two characteristic states: 30° and 60°.

[0070] Step 2: Identify the combination of requirement feature states and their design outputs. This involves analyzing all software requirement feature state combinations, eliminating those that do not meet the software usage requirements, identifying the usable requirement feature state combinations, and analyzing their corresponding software design outputs.

[0071] Step 3: Design software errors for the identified composite components. This involves designing software errors based on the composite's requirement characteristics, state properties, and software design output elements. Software errors need to consider requirements in terms of functionality, boundaries, performance, and interfaces.

[0072] Step 4: Perform software error seeding on the source program. This involves using equivalence class partitioning and structured design methods to seed the designed software errors in the source program, recording the total number of software errors N, and identifying the software that has been seeded with errors as V.ES.

[0073] Based on the above steps, the closed-loop evaluation framework can be constructed. Furthermore, software test cases can be re-entered into this closed-loop evaluation framework to complete software test acceptance, including the following steps:

[0074] Step 5: Implement the assessment, which involves running test cases on the V.ES version of the software, recording the test case execution results and the total number of software problems M found during the execution of the test cases.

[0075] Step Six: Conduct software testing evaluation and acceptance. Calculate the percentage of problems found during software testing, M / N, and use this indicator as the assessment criterion for software testing acceptance. When this indicator is 1, it indicates that the software testing is sufficient; when the indicator is less than 1, it indicates that the software testing work has omissions or is insufficient.

[0076] The steps of this method are explained in detail below with reference to the accompanying drawings.

[0077] Figure 3 A schematic diagram illustrating the structure of a software requirement in one embodiment of the present invention is shown. For example... Figure 3 As shown, software requirements include software input, execution conditions, processing, and output. In step one, the decision conditions in the software requirements are analyzed. Assuming the software requirements have N requirement characteristics, the set C of requirement characteristics can be expressed as follows:

[0078] C = {C i |i=1,2…N}

[0079] Let the i-th demand feature C i The j-th feature state is represented as S (i，j) The i-th demand feature C i Feature state set S i It can be expressed as the following formula:

[0080] S i ={S (i，j) |j=1,2……M}

[0081] Where M represents the i-th demand feature C i The number of characteristic states.

[0082] In step two, the Cartesian product algorithm is first used to calculate the feature state combinations of all software requirement features. The Cartesian algorithm is expressed as follows:

[0083] A×B={(x,y)|x∈A^y∈B}

[0084] The Cartesian product algorithm is used to calculate the feature state combinations of all software requirement features, expressed as follows:

[0085] S1×S2…S N ={(x1, x2, ..., x...} N |x1∈S1^x2∈S2…x N ∈S N}

[0086] Furthermore, considering the application context of the software requirements, combinations that are impossible or have no assessment value are eliminated, and all remaining valid combinations are identified. The software design output corresponding to each identified combination is then analyzed. Figure 4 This diagram illustrates a combination of software requirement feature states and its design output according to an embodiment of the present invention. Figure 4 As shown, V identified characteristic state combinations can be obtained, and their software design output set P&0 can be expressed as follows:

[0087] P&O = {P&O} k |k=1,2…V}

[0088] Among them, P&O k This represents the k-th software design output.

[0089] In step three, the identified combination of software errors is designed. This involves analyzing the existence of assessment requirements for each combination of characteristic states and the software design output from the aspects of function, boundary, performance, and interface. Software errors with assessment requirements are then designed accordingly. Figure 5 A flowchart illustrating a software design error in one embodiment of the present invention is shown. Figure 5 As shown, the density and number of design software errors are determined in conjunction with the requirements of software testing and verification. Software error design needs to follow two principles: first, the logical position of the designed software errors cannot be higher than the logical level of the characteristic state combination; second, the designed software errors should be logically independent and unrelated. The set of designed software errors, ERR, can be expressed as follows:

[0090] ERR = {ERR} i |i=1,2……Z}

[0091] Where Z represents the total number of software errors in the design, ERR i This indicates the i-th software error.

[0092] In step four, software error seeding is performed on the source program. This involves analyzing the location (input, processing, condition constraint, or output) of each software error in the ERR set within its required characteristic state combination. Combining the implementation structure and characteristics of the software source program, equivalence class partitioning and structure-oriented design methods are used to encode and implement the designed software error set ERR in the software source program, which is known as software error seeding. Figure 6 This diagram illustrates a process of seeding errors into a software source program according to one embodiment of the present invention. Figure 6 As shown, the principle of error seeding is that software errors do not affect the compilation and operation of the software. After error seeding is completed, the software V.ES version is obtained, which can be used as the implementation vehicle for software testing and acceptance assessment.

[0093] In one embodiment of the present invention, a software error seeding system based on software requirements is also proposed, comprising:

[0094] The feature state analysis module is configured to analyze software requirements to determine software requirement features and their feature states;

[0095] The feature identification module is configured to determine feature state combinations of multiple software requirement features, identify valid feature state combinations to generate identified feature state combinations, and determine the software output of the identified feature state combinations.

[0096] A software error generation module is configured to construct a software error based on the software output as the combination of identifier feature states; and

[0097] Error-seeding module, which is configured to use the software errors to error-seed the source program to generate error-seeded software.

[0098] This invention effectively combines software requirements and software source code to construct a closed-loop assessment framework for software testing, effectively filling the technological gap in existing software testing and acceptance methods. Specifically, this invention uses software requirements as the primary basis to assess the extent to which software testing covers those requirements. Simultaneously, using the bug-planted source code as the implementation vehicle, it directly assesses the software testing's ability to discover software problems. Therefore, it can simultaneously assess and accept the two core objectives of software testing. Furthermore, each step of this invention has clearly defined inputs and follows scientific methods, ensuring objectivity and rigor and eliminating the interference of subjective uncertainties. Moreover, the entire implementation process of this invention generates detailed records, documenting the design process, supporting data, and assessment results for each step, guaranteeing the transparency and reproducibility of the acceptance process.

[0099] Although various embodiments of the invention have been described above, it should be understood that they are presented by way of example only and not as limitations. It will be apparent to those skilled in the art that various combinations, modifications, and alterations can be made without departing from the spirit and scope of the invention. Therefore, the breadth and scope of the invention disclosed herein should not be limited by the exemplary embodiments disclosed above, but should be defined solely by the appended claims and their equivalents.

Claims

1. A software bug seeding method based on software requirements, characterized in that, Includes the following steps: Analyze software requirements to determine their characteristics and status. Determine the combination of feature states for multiple software requirement features; Valid feature state combinations are identified to generate identified feature state combinations, and the software output of the identified feature state combinations is determined. A software error is constructed based on the combination of the identifier feature states as the software output. as well as The software bug is used to bug-plant the source program to generate bug-planting software.

2. The software bug seeding method based on software requirements according to claim 1, characterized in that, Analyzing software requirements to determine their characteristics and status includes: Analyzing the execution conditions of software requirements, the set C of software requirement characteristics is expressed as follows: C={C i |i=1,2…N} Where N represents the number of software requirement features, C i Represents the i-th software requirement feature; and Let the i-th software requirement feature C i Feature state set S i It can be expressed as the following formula: S i ={S (i，j) |j=1,2…M} Where M represents the i-th software requirement feature C i The number of characteristic states, S (i，j) Let C represent the i-th software requirement feature. i The j-th feature state.

3. The software bug seeding method based on software requirements according to claim 2, determining the feature state combination of multiple software requirement features includes calculating the feature state combination of multiple software requirement features using the Cartesian product algorithm, expressed as the following formula: S1×S2…S N ={(x1,x2…x N )|x1∈S1∧x2∈S2…x N ∈S N }。 4. The software bug seeding method based on software requirements according to claim 3, characterized in that, Identifying valid feature state combinations to generate identified feature state combinations, and determining the software output of the identified feature state combinations, includes the following steps: Based on the application context of the software requirements, eliminate impossible and unassessable feature state combinations to determine effective feature state combinations. Valid feature state combinations are identified to generate identified feature state combinations; as well as The software output set P&O, which determines multiple combinations of identifier feature states, is expressed as follows: P&O={P&O k |k=1.2…V} Where V represents the number of combinations of identifier feature states, P&O k This represents the software output of the k-th identifier feature state combination.

5. The software bug seeding method based on software requirements according to claim 4, characterized in that, Constructing a software error based on the combination of the identifier feature states output by the software includes the following steps: The assessment requirements for the identification feature state combinations and their software outputs are determined based on the software's functional characteristics, boundary characteristics, performance characteristics, and interface characteristics; and The software error set (ERR) is constructed based on the aforementioned assessment requirements, where the software error set is represented by the following formula: ERR={ERR i |i=1,2…Z} Where Z represents the number of software errors, ERR i This indicates the i-th software error.

6. The software bug seeding method based on software requirements according to claim 5, characterized in that, Using the aforementioned software error to generate error-seeding software from the source program includes the following steps: Determine the location where the software error occurs within the combination of the identifier feature states; as well as Using equivalence class partitioning and source program structure-oriented design methods, the software error set is encoded and implemented in the source program to generate error seeding software.

7. The software bug seeding method based on software requirements according to claim 6, characterized in that, Also includes: Implement test cases on the error-seeding software and record the execution results of the test cases and the software problems found; as well as The number of software problems and the number of software errors are compared to evaluate and accept the software.

8. A software bug seeding system based on software requirements, characterized in that, include: The feature state analysis module is configured to analyze software requirements to determine software requirement features and their feature states; The feature identification module is configured to determine feature state combinations of multiple software requirement features, identify valid feature state combinations to generate identified feature state combinations, and determine the software output of the identified feature state combinations. A software error generation module is configured to construct a software error based on the combination of the identifier feature states as the software output. as well as Error-seeding module, which is configured to use the software errors to error-seed the source program to generate error-seeded software.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it performs the steps of the method according to any one of claims 1-7.

10. An instruction processing system, characterized in that, include: A processor, which is configured to execute machine-executable instructions; as well as A memory having machine-executable instructions stored thereon, which, when executed by a processor, perform the steps of the method according to any one of claims 1-7.

Images