Software defect detection methods, apparatus, equipment and storage media

Abstract

This application discloses a software defect detection method, apparatus, device, and storage medium, relating to the field of software technology. The software defect detection method includes: acquiring interface configuration information of the software to be detected; wherein the interface configuration information is used to indicate the interfaces included in the software to be detected and the interface parameters corresponding to each interface; for each interface, executing the interface based on the interface parameters corresponding to the interface to obtain the software state after the interface is executed; determining whether the software to be detected has defects based on the software state after each interface is executed and a preset detection specification; wherein the preset detection specification is used to specify the rules followed by the software state corresponding to the interfaces included in the software when the software is qualified; this solves the problem of low accuracy in existing software defect detection methods.

Description

Technical Field

[0001] This application relates to the field of software technology, and in particular to methods, apparatus, equipment and storage media for software defect detection. Background Technology

[0002] With the development of the software industry, more and more software systems are being developed. To increase software reliability, various testing methods are typically used to detect software defects. However, these testing methods usually select a portion of the vast set of use cases for testing, making it difficult to guarantee the completeness of software testing and resulting in low accuracy in software defect detection. Summary of the Invention

[0003] This application provides a software defect detection method, apparatus, device, and storage medium, which solves the problem of low accuracy in existing software defect detection methods.

[0004] To achieve the above technical objectives, the embodiments of this application adopt the following technical solutions:

[0005] In a first aspect, embodiments of this application provide a software defect detection method, comprising: acquiring interface configuration information of the software to be detected; wherein the interface configuration information is used to indicate the interfaces included in the software to be detected and the interface parameters corresponding to each interface; for each interface, executing the interface based on the interface parameters corresponding to the interface to obtain the software state after executing the interface; determining whether the software to be detected has defects based on the software state after executing each interface and a preset detection specification; wherein the preset detection specification is used to specify the rules followed by the software state corresponding to the interfaces included in the software when the software is qualified.

[0006] In this embodiment, the interface configuration information of the software to be tested is obtained. Then, for each interface, the interface is executed based on the corresponding interface parameters to obtain the software state after the interface is executed. Then, based on the software state after each interface execution and the preset detection specifications, it is determined whether the software to be tested has defects. The complete interface configuration information of the software to be tested is used as the data source for software defect detection, rather than just detecting through a partial set of test cases. This can comprehensively simulate the running state of the software. Furthermore, by using various preset detection specifications to detect the software state after the software interface execution, the accuracy of the detection is ensured.

[0007] In one embodiment, the interface parameters include interface execution priority and interface execution parameters; for each interface, the interface is executed based on the interface parameters corresponding to the interface to obtain the software state after the interface is executed, including: based on the interface execution priority, the interfaces are executed sequentially according to the interface execution parameters with the same initial software state, and the first software state after the interface is executed is output respectively;

[0008] Based on the interface execution priority, the interfaces are executed sequentially according to the interface execution parameters with the same first software state, and the second software state after the interface execution is output respectively; until no new software state is generated in the software state queue, the software state queue records the initial software state and the software state after the interface execution, and the software states recorded in the software state queue are all different.

[0009] In one embodiment, the method further includes: establishing association information between the software states before and after the execution of the interfaces, based on the execution order of the interfaces.

[0010] In one embodiment, the first software state or the second software state is output through the following steps: establishing an execution queue of interface execution parameters corresponding to the interface according to the interface execution priority; traversing the interface execution parameters in the execution queue, executing the corresponding interface according to the interface execution parameters and the software state applied to the execution interface, and outputting the first software state or the second software state respectively.

[0011] In one embodiment, the association information between software states before and after the execution of the interface is established according to the execution order of the interface, including: establishing a directed graph, the directed graph including nodes corresponding to the software states, and connecting nodes corresponding to two software states with association information with directed edges.

[0012] In one embodiment, the preset detection specifications include deadlock specifications; determining whether the software to be detected has defects based on the software state after each interface is executed and the preset detection specifications includes: detecting correlation information through the deadlock specifications to determine whether the software to be detected has defects; and / or, the preset detection specifications include liveness check specifications; determining whether the software to be detected has defects based on the software state after each interface is executed and the preset detection specifications includes: detecting correlation information through the liveness check specifications to determine whether the software to be detected has defects.

[0013] In one embodiment, the preset detection specifications include security detection specifications; determining whether the software to be detected has defects based on the software state after each interface is executed and the preset detection specifications includes: detecting the software state corresponding to each interface through the security detection specifications to determine whether the software to be detected has defects.

[0014] Secondly, embodiments of this application provide a software defect detection device, comprising: an acquisition module, configured to acquire interface configuration information of software to be detected; wherein the interface configuration information is used to indicate the interfaces included in the software to be detected and the interface parameters corresponding to each interface; an execution module, configured to execute the interface for each interface based on the interface parameters corresponding to the interface, and obtain the software state after the interface is executed; and a detection module, configured to determine whether the software to be detected has defects based on the software state after each interface is executed and a preset detection specification; wherein the preset detection specification is used to specify the rules followed by the software state corresponding to the interfaces included in the software when the software is qualified.

[0015] In one embodiment, the interface parameters include interface execution priority and interface execution parameters; the execution module is specifically used to: execute interfaces sequentially according to the interface execution parameters based on the interface execution priority and with the same initial software state, and output the first software state after executing the interface respectively; execute interfaces sequentially according to the interface execution parameters based on the interface execution priority and with the same first software state, and output the second software state after executing the interface respectively; until no new software state is generated in the software state queue, the software state queue records the initial software state and the software state after executing the interface, and the software states recorded in the software state queue are all different.

[0016] In one embodiment, the detection module is used to establish the association information between the software states before and after the execution of the interface, based on the execution order of the interface.

[0017] In one embodiment, the execution module is specifically used to: establish an execution queue of interface execution parameters corresponding to the interface according to the interface execution priority; traverse the interface execution parameters in the execution queue, execute the corresponding interface according to the interface execution parameters and the software state applied to the execution interface, and output the first software state or the second software state respectively.

[0018] In one embodiment, the detection module is specifically used to: establish a directed graph, which includes nodes corresponding to software states, and nodes corresponding to two software states that have association information are connected by directed edges.

[0019] In one embodiment, the preset detection specifications include a deadlock specification; the detection module is specifically used to detect correlation information through the deadlock specification to determine whether the software to be detected has defects; and / or, the preset detection specifications include a liveness check specification; the detection module is specifically used to: detect correlation information through the liveness check specification to determine whether the software to be detected has defects.

[0020] In one embodiment, the preset detection specifications include security detection specifications; the detection module is specifically used to: detect the software status corresponding to each interface through the security detection specifications, and determine whether the software to be detected has defects.

[0021] Thirdly, this application provides an electronic device, including: a processor, and a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement the software defect detection method provided in the first aspect above.

[0022] Fourthly, this application provides a computer-readable storage medium storing an information transmission implementation program, which, when executed by a processor, implements the software defect detection method provided in the first aspect.

[0023] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method provided in the first aspect above.

[0024] The beneficial effects described in the second, third, fourth and fifth aspects of this application can be referred to the analysis of the beneficial effects in the first aspect, and will not be repeated here. Attached Figure Description

[0025] Figure 1 A flowchart illustrating a software defect detection method provided in an embodiment of this application;

[0026] Figure 2 A flowchart illustrating another software defect detection method provided in an embodiment of this application;

[0027] Figure 3 A flowchart illustrating another software defect detection method provided in an embodiment of this application;

[0028] Figure 4 A flowchart illustrating another software defect detection method provided in an embodiment of this application;

[0029] Figure 5 A flowchart illustrating another software defect detection method provided in an embodiment of this application;

[0030] Figure 6 A schematic diagram of a directed graph provided in an embodiment of this application;

[0031] Figure 7 This is a schematic diagram of the structure of a software defect detection device provided in an embodiment of this application;

[0032] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] The features and exemplary embodiments of various aspects of this application will now be described in detail. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only configured to explain this application and are not configured to limit this application. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples of this application.

[0034] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations; nor should they be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0035] With the development of the software industry, more and more software systems are being developed. For example, distributed software systems (DMS) are software systems that support distributed processing; they are systems that execute tasks on a multiprocessor architecture interconnected by communication networks. These include distributed operating systems, distributed programming languages ​​and their compilers (interpreters), distributed file systems, and distributed database systems. To increase software reliability, various testing methods are typically used to detect software defects. However, these methods usually select a subset of use cases from a large set of test cases. For complex distributed software testing, it is necessary to simulate various possible scenarios in the testing environment to discover whether the software has defects, which is inefficient. Furthermore, it is difficult to guarantee the completeness of software testing, resulting in low accuracy in software defect detection.

[0036] To address the aforementioned technical problems, embodiments of this application provide a software defect detection method. The execution entity of the software defect detection method provided in this application can be an electronic device with data processing capabilities, such as a computer or server. The server can be a single server or a server cluster composed of multiple servers. In some embodiments, the server cluster can also be a distributed cluster. This application does not limit the execution entity of this software defect detection method.

[0037] Figure 1 A flowchart illustrating a software defect detection method provided in one embodiment of this application is shown.

[0038] like Figure 1 As shown, the method may include the following steps:

[0039] S110: Obtain the interface configuration information of the software to be tested.

[0040] The software to be tested can be user-configured software, such as system software and application software.

[0041] Interface configuration information indicates the interfaces (or interface functions) included in the software to be tested, as well as the interface parameters corresponding to each interface. Interface parameters for an interface can include the interface execution priority and the corresponding interface execution parameters. The interface execution priority indicates the order in which interfaces are executed, while the interface execution parameters indicate the necessary data for executing the interface. Interface execution parameters can be one or more, without limitation. This interface configuration information can be obtained through data interaction with the software server. Specifically, it can be obtained directly through data interaction with the software server, or it can be obtained by interacting with the software server to acquire the software source code and then parsing the source code to obtain the interface configuration information.

[0042] For example, the execution priority of the initialization interface is L1 (there is usually only one L1 level, but there can be multiple other levels), and the execution priority of other interfaces is L2, L3, etc. When executing interfaces, the execution order from first to last is L1, L2, L3. Interfaces of the same level are not called in any particular order, and the order in which they are executed can be chosen at will.

[0043] S120: For each interface, execute the interface based on the corresponding interface parameters to obtain the software state of the interface after execution.

[0044] Executing an interface based on its corresponding interface parameters can refer to assigning interface parameters to the interface and then executing the interface. In this application, executing an interface based on its corresponding interface parameters can also be described as running the interface (or interface function) based on its corresponding interface parameters. The software state of the interface can also be referred to as the interface's execution result, which characterizes the result after executing the interface based on its parameters. For example, a set of interface parameters corresponds to one software state of the interface; that is, running the same interface based on multiple sets of different interface parameters can yield multiple different software states (or execution results).

[0045] In one embodiment, such as Figure 2 As shown, S120: For each interface, execute the interface based on the interface parameters corresponding to the interface to obtain the software state after executing the interface, which may include:

[0046] S1201, based on the interface execution priority, executes the interfaces sequentially according to the interface execution parameters with the same initial software state, and outputs the first software state after executing the interface respectively.

[0047] The initial software state can be preset. Based on the interface execution priority, the interfaces are executed sequentially according to the interface execution parameters with the same initial software state, so that the first software state after the interface is executed can be output respectively.

[0048] For example, assuming the initial software state is a card balance of 10, the consumption interface and the card return interface are executed according to the corresponding interface execution parameters based on the balance of 10, and the first software state after executing the consumption interface and the card return interface can be output respectively.

[0049] Furthermore, the software to be tested may include multiple interfaces. For interfaces with different execution priorities, the interfaces are executed sequentially according to their execution priorities, based on their execution parameters and the same initial software state, and the software state after execution is output. For interfaces with the same execution priority, they are executed separately according to their execution parameters with the same initial software state (they can be executed synchronously or sequentially), and the first software state after execution is output. The initial software states corresponding to interfaces with different execution priorities may be the same or different.

[0050] Referring to the example of interface execution priority in S110, the execution of an L1-level interface outputs the software state S1 after the L1-level interface execution; then the execution of an L2-level interface outputs the software state S2 after the L2-level interface execution; then the execution of an L3-level interface outputs the software state S3 after the L3-level interface execution. This process continues until all interfaces have been executed, thus obtaining the software state after each interface execution.

[0051] S1202, based on the interface execution priority, execute the interfaces sequentially according to the interface execution parameters with the same first software state, and output the second software state after the interface execution, until no new software state is generated in the software state queue.

[0052] The software state queue records the initial software state and the software state after executing the interface. Each software state recorded in the software state queue is unique; that is, the software state queue records all software states mentioned in this embodiment, but each software state is recorded only once. For example, after outputting the first software state, the first software state is deduplicated before being recorded in the software state queue. Then, the interface is executed based on the software states in the software state queue that did not participate in the interface execution, and the software state queue is updated synchronously until all software states in the software state queue have executed the interface, and no new software states are generated in the software state queue. This ensures a comprehensive simulation of the software states generated during software operation.

[0053] Furthermore, the execution principle of S1202 is the same as that of S1201. For the interface execution process of S1202, please refer to the description of S1201, which will not be repeated here.

[0054] In one embodiment, an execution queue can be created, and the output of the first software state and the second software state can be implemented using a queue-based sequential execution method. Specifically, as shown... Figure 3 As shown, S1201 may include S121 to S122:

[0055] S121, Establish an execution queue for the interface execution parameters corresponding to the interface based on the interface execution priority.

[0056] Specifically, an execution queue for the execution parameters of each interface can be established based on the interface execution priority. This execution queue contains the execution parameters of each interface in sequence. For example, they can be arranged from front to back as follows: execution parameter C1 for L1 level interfaces, execution parameter C2 for L2 level interfaces, execution parameter C3 for L3 level interfaces, and so on.

[0057] S122, traverse the interface execution parameters in the execution queue, execute the corresponding interface according to the interface execution parameters and the software state applied by the execution interface, and output the first software state or the second software state respectively.

[0058] Exemplarily, referring to the example of S121, first, execute the interface execution parameter C1 in the execution queue, execute the corresponding interface according to the interface execution parameter C1, and output the software state S1 after the interface execution; then, execute the interface execution parameter C2 in the execution queue, execute the corresponding interface according to the interface execution parameter C2, and output the software state S2 after the interface execution; then, execute the interface execution parameter C3 in the execution queue, execute the corresponding interface according to the interface execution parameter C3, and output the software state S3 after the interface execution. Until all the interface execution parameters in the execution queue are executed.

[0059] Further, in the above example, if the output software states S1, S2, and S3 are obtained by executing the interface based on the initial software state, then the software states S1, S2, and S3 are the first software states; if the output software states S1, S2, and S3 are obtained by executing the interface based on the first software state, then the software states S1, S2, and S3 are the second software states.

[0060] S130, determine whether the software to be detected has defects according to the software state after each interface execution and the preset detection specification.

[0061] Among them, the preset detection specification is used to stipulate the rules followed by the software states corresponding to the interfaces that the software can include in the case of qualified software. The preset detection specification can be pre-configured in the local storage or obtained immediately from other devices. Based on the preset detection specification, it can be determined whether the software to be detected has defects according to the software state after the interface execution. For example, if the software state after each interface execution conforms to the regulations of the preset detection specification, it means that the software has no defects and is qualified. On the contrary, if the software state after each interface execution does not conform to the regulations of the preset detection specification, it means that the software has defects.

[0062] Further, it can be determined whether the software to be detected has defects by a configuration file parser according to the software state after each interface execution and the preset detection specification.

[0063] Exemplarily, the configuration file parser can be selected as configparser, minIni, etc.

[0064] In this embodiment, the interface configuration information of the software to be tested is obtained. Then, for each interface, the interface is executed based on the corresponding interface parameters to obtain the software state after the interface is executed. Then, based on the software state after each interface execution and the preset detection specifications, it is determined whether the software to be tested has defects. The complete interface configuration information of the software to be tested is used as the data source for software defect detection, rather than just detecting through a partial set of test cases. That is, by detecting all the interfaces included in the software, the software state generated by the software operation can be fully simulated. Furthermore, by using various preset detection specifications to detect the software state after the software interface execution, the accuracy of the detection is ensured.

[0065] In one embodiment, prior to executing S130, association information may also be generated for use in step S130 to determine whether the software to be detected has defects, such as... Figure 4 As shown, the method may further include:

[0066] S140, based on the execution order of the interfaces, establish the association information between the software states before and after the execution of the interfaces.

[0067] In this embodiment of the application, the association information between the software states before and after the execution of the interface is established according to the execution order of the interface. The association information of an interface can characterize the association between the software states corresponding to that interface, such as characterizing adjacent software states. This association information can be used in step S130 to determine whether the software to be detected has defects.

[0068] Furthermore, in one embodiment, such as Figure 5 As shown, S140 may include:

[0069] Construct a directed graph, which can include nodes corresponding to software states. Nodes corresponding to two software states that have relationship information are connected by directed edges.

[0070] It is understandable that a directed edge is a connecting edge that points to another node. If a directed edge points from one node to another node, it means that the next adjacent change state of the software state corresponding to that node is the software state corresponding to the other node.

[0071] For example, in conjunction with the example in S122, a directed graph can be as follows: Figure 6 As shown, S1 is the initial software state, S2 is the software state after S1 is changed, and S3 is the software state after S2 is changed. It can be seen that S1, S2, and S3 have related information. By connecting S1, S2, and S3 with directed edges according to the order of change, a directed graph can be obtained.

[0072] When constructing a directed graph, the software state of a newly generated interface, relative to the software states of existing interfaces in the directed graph, can be referred to as a node to be added. We can check whether the node to be added already exists in the directed graph. If it doesn't, the node to be added is stored in the directed graph, and directed edges are used to connect it to related nodes. Specifically, the directed edges start from related nodes and point to the new node. Conversely, if the node to be added already exists in the directed graph, directed edges are used to connect it to related nodes.

[0073] In this embodiment of the application, a directed graph is used to represent the change process of the software state, and the directed graph can be used to determine whether the software to be detected has defects.

[0074] In one embodiment, the preset detection specifications may include a deadlock specification, a liveness check specification, and a safety check specification. When determining whether the software to be tested has a defect, any one of these specifications can be used individually, or multiple specifications can be used in combination. When multiple specifications are used in combination, if any one specification determines that the software to be tested has a defect, then the software is determined to have a defect. The following explains how to determine the presence of defects in the software to be tested using the deadlock specification, liveness check specification, and safety check specification:

[0075] When applying deadlock specification detection, S130: Determine whether the software to be detected has defects based on the software state after each interface execution and the preset detection specifications, which may include:

[0076] By examining the relationship information using deadlock specifications, it is possible to determine whether the software under test has defects.

[0077] When detecting relationship information using the deadlock specification, the first step is to determine whether the last software state in the relationship information is the preset final software state. If not, and no other software state is added to the relationship information after the last software state, it indicates that the relationship information is deadlocked and the software to be tested has a defect.

[0078] Furthermore, error messages can be reported to alert the software under test that it has a deadlock defect.

[0079] On the other hand, when applying the activity check specification for testing, S130: determining whether the software to be tested has defects based on the software state after each interface execution and the preset test specification may include:

[0080] By using activity testing to detect correlation information, it is possible to determine whether the software under test has defects.

[0081] Among them, the liveness check specification can detect whether the software state before and after the execution interface represented by the correlation information meets the software requirements, thereby determining whether the software to be tested has defects.

[0082] For example, if the normal operation of software requires the software states to appear in sequence as S1, S2, and S3, and the activity check specification detects that the software states appear in sequence as S1 and S2 as represented by the correlation information, but S3 does not appear, then it is determined that the software to be tested has a defect.

[0083] On the other hand, when applying security testing standards, S130: Based on the software state after each interface execution and the preset testing standards, determine whether the software to be tested has defects, which may include:

[0084] By testing the software status of each interface according to security testing standards, it can be determined whether the software under test has defects.

[0085] Among them, the security testing specifications can detect whether the software state corresponding to each interface is secure, thereby determining whether the software under test has defects.

[0086] In this embodiment, multiple preset testing standards are used to determine whether the software to be tested has defects, thus ensuring the accuracy of the software defect detection results.

[0087] To help understand the software defect detection method provided in the embodiments of this application, a specific example is also provided as follows:

[0088] The software under test implements three functions: card purchase, consumption, and card return. The software has two states: balance and state. Balance represents the card balance, and state represents the card's software status. Balance must be greater than or equal to 0. The range of state is {0, 1, 2, 3}, where 0 indicates an invalid card (the state before purchase); 1 indicates a purchased card (the state after purchase); 2 indicates a consumed card (the state after consumption); and 3 indicates a returned card (the state after return). Specifically, a card purchase operation can only be performed when state = 0, after which the balance is greater than 0. A consumption operation can only be performed when state = 1, after which the balance is greater than or equal to 0. A card return operation can only be performed when state = 1 or state = 2, after which the balance is 0.

[0089] In this example, the preset detection specifications are as follows:

[0090] Deadlock: false / / Indicates no deadlock detection. Safetycheck: state\in{1,2,3}&balance>=0 / / Indicates the card software state can only be one of 1, 2, or 3, and the balance can only be greater than or equal to 0. Livenesscheck: state=1=>state=3 / / Indicates that a successfully purchased card can eventually be cancelled.

[0091] The software's interface configuration information includes: {Purchase Card (amount1): L1, Consumption (amount2): L2, Card Refund: L2} / / L1 and L2 represent the interface execution priority. This configuration indicates that the purchase card interface should be executed first, followed by the consumption and card refund interfaces. The consumption and card refund interfaces are at the same level and have no order. The L1 level is used for system initialization.

[0092] Furthermore, interface parameters may include:

[0093] `amount1\in{10,20,50,100}` / / This indicates that the purchase amount is one of the values ​​in {10, 20, 50, 100}. `amount2\in 0..amount1` / / This indicates that the spending amount is a value between 0 and `amount1`. In practice, `amount2` can be configured to exceed `amount1` to verify cases of overspending.

[0094] Software status query interface: getstate()(balance, state) / / Used to retrieve the card balance and software status, for S120 to obtain the software status after executing the interface. The data structure returned by the getstate interface is consistent with the configured data structure. The setstate interface can be configured as needed.

[0095] Let there be a software state queue Q, a directed graph G, and an execution queue P for interface execution parameters. The software state queue Q stores all software states, and the directed graph G stores the software states output after the interface execution. The directed graph G uses software states as nodes and software state change behaviors as edges. The software defect detection method flow is as follows:

[0096] Take the initial software state from the software state queue Q. Based on this state, traverse the interface parameters of each level in the execution queue P and execute the corresponding interfaces. Then, obtain each group of balances through the software state query interface getstate. The state is used as the first software state S1 (a group of balances and states will be output after each interface is executed). Store the deduplicated S1 into the directed graph G and the software state queue Q. Check S1 through Safetycheck. That is, report an error when the value of the state corresponding to S1 is not in {1,2,3} or the value of the balance corresponding to S1 is less than 0.

[0097] Similarly, take any first software state S1 from the software state queue Q. Based on this state, traverse the interface parameters at each level in the execution queue P and execute the corresponding interfaces at each level. Then, obtain the balance of each group through the software state query interface getstate, and use the state as the software state S2. Check if S2 exists in the directed graph G. If it exists, connect S1 and S2. If it does not exist, add S2 to the directed graph G, connect S1 and S2 in the directed graph G, and store S2 in the software state queue Q. Check S2 through Safetycheck, that is, report an error if the value of the state corresponding to S2 is not in {1,2,3} or the value of the balance corresponding to S2 is less than 0. This continues until all software states in queue Q have participated in interface execution and no new software states are generated in queue Q.

[0098] The directed graph G is inspected using Liveness. The system searches for all software states that the process takes from the initial software state to the final software state. If a software state has state=1, the system checks if the software states that follow that software state have state=3. If no software state=3 is found, an error is reported.

[0099] For Deadlock detection: Since Deadlock is configured as false, no detection is needed, and no error will be reported even if a Deadlock is detected.

[0100] In this embodiment, the interface configuration information of the software to be tested is obtained. Then, for each interface, the interface is executed based on the corresponding interface parameters to obtain the software state after the interface is executed. Then, based on the software state after each interface execution and the preset detection specifications, it is determined whether the software to be tested has defects. The complete interface configuration information of the software to be tested is used as the data source for software defect detection, rather than just detecting through a partial set of test cases. This can comprehensively simulate the running state of the software. Furthermore, by using various preset detection specifications to detect the software state after the software interface execution, the accuracy of the detection is ensured.

[0101] Figures 1-6 The software defect detection method is described below, combined with Figures 7-8 This application describes the apparatus provided in its embodiments. To achieve the above-described functions, the software defect detection apparatus includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art will readily recognize that, based on the algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0102] This application embodiment can, exemplarily, divide a software defect detection device into functional modules based on the above method. The software defect detection device can be divided into functional modules corresponding to each function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, other division methods may be used.

[0103] Figure 7 This paper shows a schematic diagram of the structure of a software defect detection device according to an embodiment of the present application. Figure 7 Each module in the device shown has the ability to implement Figure 1 The functions of each step in the process are defined, and their corresponding technical effects are achieved. For example... Figure 7 As shown, the device may include:

[0104] The acquisition module 710 is used to acquire the interface configuration information of the software to be tested. The interface configuration information indicates the interfaces included in the software to be tested and the corresponding interface parameters for each interface.

[0105] The execution module 720 is used to execute the interface based on the interface parameters corresponding to each interface and obtain the software state after the interface is executed.

[0106] The detection module 730 is used to determine whether the software to be tested has defects based on the software state after each interface is executed and the preset detection specifications. The preset detection specifications are used to define the rules that the software state corresponding to the interfaces included in the software should follow when the software is qualified.

[0107] In this embodiment, the interface configuration information of the software to be tested is obtained. Then, for each interface, the interface is executed based on the corresponding interface parameters to obtain the software state after the interface is executed. Then, based on the software state after each interface execution and the preset detection specifications, it is determined whether the software to be tested has defects. The complete interface configuration information of the software to be tested is used as the data source for software defect detection, rather than just detecting through a partial set of test cases. This can comprehensively simulate the running state of the software. Furthermore, by using various preset detection specifications to detect the software state after the software interface execution, the accuracy of the detection is ensured.

[0108] In one embodiment, the interface parameters include interface execution priority and interface execution parameters.

[0109] Execution module 720 is specifically used for:

[0110] Based on the interface execution priority, with the same initial software state, the interfaces are executed sequentially according to the interface execution parameters, and the first software state after the interface execution is output. Based on the interface execution priority, with the same first software state, the interfaces are executed sequentially according to the interface execution parameters, and the second software state after the interface execution is output, until no new software state is generated in the software state queue.

[0111] The software state queue records the initial software state and the software state after the interface is executed. The software states recorded in the software state queue are all different.

[0112] In one embodiment, the detection module is further configured to establish the association information between the software states before and after the execution of the interface based on the execution order of the interface.

[0113] In one embodiment, the execution module 720 is specifically used for:

[0114] An execution queue for the execution parameters of an interface is established based on the interface execution priority.

[0115] Iterate through the interface execution parameters in the execution queue, execute the corresponding interface according to the interface execution parameters and the software state applied to the execution interface, and output the first software state or the second software state respectively.

[0116] In one embodiment, the detection module is specifically used for:

[0117] Construct a directed graph, which includes nodes corresponding to software states. Nodes corresponding to two software states that have a relationship are connected by directed edges.

[0118] In one embodiment, the preset detection criteria include deadlock criteria.

[0119] Detection module 730 is specifically used for:

[0120] By examining the relationship information using deadlock specifications, it is possible to determine whether the software under test has defects.

[0121] And / or, the preset testing specifications include activity testing specifications.

[0122] Detection module 730 is specifically used for:

[0123] By using activity testing to detect correlation information, it is possible to determine whether the software under test has defects.

[0124] In one embodiment, the preset detection specifications include security detection specifications.

[0125] Detection module 730 is specifically used for:

[0126] By testing the software status of each interface according to security testing standards, it can be determined whether the software under test has defects.

[0127] In this embodiment, the interface configuration information of the software to be tested is obtained. Then, for each interface, the interface is executed based on the corresponding interface parameters to obtain the software state after the interface is executed. Then, based on the software state after each interface execution and the preset detection specifications, it is determined whether the software to be tested has defects. The complete interface configuration information of the software to be tested is used as the data source for software defect detection, rather than just detecting through a partial set of test cases. This can comprehensively simulate the running state of the software. Furthermore, by using various preset detection specifications to detect the software state after the software interface execution, the accuracy of the detection is ensured.

[0128] Figure 8 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown. Figure 8 As shown, the device may include a processor 801 and a memory 802 storing computer program instructions.

[0129] Specifically, the processor 801 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0130] Memory 802 may include mass storage for data or instructions. For example, and not limitingly, memory 802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 802 may include removable or non-removable (or fixed) media, or memory 802 may be non-volatile solid-state memory. Memory 802 may be internal or external to the integrated gateway disaster recovery device.

[0131] In one instance, memory 802 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0132] The processor 801 reads and executes computer program instructions stored in the memory 802 to achieve... Figure 1 The method in the illustrated embodiment achieves... Figure 1 The technical effects achieved by executing the methods in the examples shown are not elaborated here for the sake of brevity.

[0133] In one example, the electronic device may also include a communication interface 803 and a bus 810. Wherein, as... Figure 8 As shown, the processor 801, memory 802, and communication interface 803 are connected through bus 810 and complete communication with each other.

[0134] The communication interface 803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0135] Bus 810 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 810 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0136] The electronic device can execute the software defect detection method in the embodiments of this application, thereby achieving... Figure 1 The technical effects of the described software defect detection method.

[0137] Furthermore, in conjunction with the software defect detection methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the software defect detection methods in the above embodiments.

[0138] In an exemplary embodiment, this application also provides a computer program product that, when run on a computer, enables the computer to implement the software defect detection method described in the above embodiments.

[0139] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0140] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0141] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0142] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0143] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0144] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A software defect detection method, characterized in that, include: Obtain the interface configuration information of the software to be tested; wherein the interface configuration information is used to indicate the interfaces included in the software to be tested and the interface parameters corresponding to each interface, and the interface parameters include the interface execution priority and the interface execution parameters; Based on the interface execution priority, the interfaces are executed sequentially according to the interface execution parameters with the same initial software state, and the first software state after executing the interface is output respectively. Based on the interface execution priority, the interfaces are executed sequentially according to the interface execution parameters with the same first software state, and the second software state after the interface is executed is output respectively. Until no new software states are generated in the software state queue, the software state queue records the initial software state and the software state after executing the interface, and the software states recorded in the software state queue are all different; Based on the software state of the interface, a directed graph is established, which includes nodes corresponding to the software state. Two nodes corresponding to the software state that have association information are connected by directed edges. The directed graph is used to represent the change process of the software state. The presence of defects in the software to be tested is determined based on the directed graph and the preset testing specifications. The preset detection specification is used to define the rules followed by the software state corresponding to the interfaces included in the software when the software is qualified.

2. The software defect detection method as described in claim 1, characterized in that, The first software state or the second software state is output through the following steps: An execution queue for the execution parameters of the interface corresponding to the interface is established according to the execution priority of the interface; Iterate through the interface execution parameters in the execution queue, execute the corresponding interface according to the interface execution parameters and the software state applied to execute the interface, and output the first software state or the second software state respectively.

3. The software defect detection method as described in claim 1, characterized in that, The preset detection specifications include deadlock specifications; The step of determining whether the software to be tested has defects based on the directed graph and preset detection specifications includes: By examining the correlation information using the deadlock specification, it is determined whether the software to be tested has defects. And / or, the preset detection specifications include activity testing specifications; The step of determining whether the software to be tested has defects based on the directed graph and preset detection specifications includes: The correlation information is detected by the activity check specification to determine whether the software to be tested has defects.

4. The software defect detection method according to any one of claims 1-3, characterized in that, The preset testing specifications include safety testing specifications; The step of determining whether the software to be tested has defects based on the directed graph and preset detection specifications includes: The software status corresponding to each interface is checked using the security testing specifications to determine whether the software under test has defects.

5. A software defect detection device, characterized in that, include: The acquisition module is used to acquire the interface configuration information of the software to be tested; wherein the interface configuration information is used to indicate the interfaces included in the software to be tested and the interface parameters corresponding to each interface, and the interface parameters include the interface execution priority and the interface execution parameters. The execution module is used to execute the interfaces according to the interface execution parameters in sequence with the same initial software state, based on the interface execution priority, and output the first software state after executing the interface respectively; Based on the interface execution priority, the interfaces are executed sequentially according to the interface execution parameters with the same first software state, and the second software state after the interface is executed is output respectively. Until no new software states are generated in the software state queue, the software state queue records the initial software state and the software state after executing the interface, and the software states recorded in the software state queue are all different; The detection module is used to establish a directed graph based on the software state of the interface. The directed graph includes nodes corresponding to the software state, and two nodes corresponding to the software states that have association information are connected by directed edges. The directed graph is used to represent the change process of the software state. The detection module is used to determine whether the software to be detected has defects based on the directed graph and preset detection specifications; The preset detection specification is used to define the rules followed by the software state corresponding to the interfaces included in the software when the software is qualified.

6. The software defect detection device as described in claim 5, characterized in that, The execution module is specifically used for: An execution queue for the execution parameters of the interface corresponding to the interface is established according to the execution priority of the interface; Iterate through the interface execution parameters in the execution queue, execute the corresponding interface according to the interface execution parameters and the software state applied to execute the interface, and output the first software state or the second software state respectively.

7. The software defect detection device as described in claim 5, characterized in that, The preset detection specifications include deadlock specifications; The detection module is specifically used for: By examining the correlation information using the deadlock specification, it is determined whether the software to be tested has defects. And / or, the preset detection specifications include activity testing specifications; The detection module is specifically used for: The correlation information is detected by the activity check specification to determine whether the software to be tested has defects.

8. The software defect detection device according to any one of claims 5-7, characterized in that, The preset testing specifications include safety testing specifications; The detection module is specifically used for: The software status corresponding to each interface is checked using the security testing specifications to determine whether the software under test has defects.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the software defect detection method as described in any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the software defect detection method as described in any one of claims 1 to 4.

Images