A test sequence scene generation method and device

Abstract

The present invention discloses a test sequence scenario generation method and device, wherein the method comprises: obtaining a full test sequence directed graph and configuration information of the software to be tested; determining that each test sequence of the full test sequence directed graph generates a directed subgraph; and for each test sequence directed subgraph in each test sequence directed subgraph, generating a test sequence scenario of the test sequence directed subgraph according to the test sequence directed subgraph and the corresponding sub-configuration information in the configuration information. When the above method is applied to financial technology (Fintech), after determining that each test sequence of the full test sequence directed graph generates a directed subgraph, a test sequence scenario indicating the calling order, calling resources and constraint relationship of the application program interface can be generated, so that the full test sequence directed graph and configuration information can be reused, thereby improving the efficiency of the test sequence scenario of the application software.

Description

Technical Field

[0001] The present invention relates to the fields of financial technology (Fintech) and computer software, and in particular to a test sequence scenario generation method and device. Background Art

[0002] With the development of computer technology, more and more technologies are applied in the financial field. The traditional financial industry is gradually transforming to Fintech. However, due to the security and real-time requirements of the financial industry, higher requirements are also placed on technology. The application software provides a large number of application program interfaces to the outside world. The relevant functions of the application software can be implemented by calling the application program interfaces. Before the application software goes online, it must be tested in different test sequence scenarios. A test sequence scenario is a sequence consisting of a group of multiple application program interfaces.

[0003] In the current method, each test sequence scenario can only be generated sequentially, that is, each time, the test sequence of each application interface needs to be manually filled in, and then the corresponding data is filled in for each application interface, and the parameter association between each application interface is established. When the next test sequence scenario is generated, it needs to be generated again according to the above process, resulting in low efficiency in generating the test sequence scenario of the application software. Summary of the invention

[0004] The present invention provides a test sequence scenario generation method and device, which solves the problem of low efficiency in generating test sequence scenarios of application software in the prior art.

[0005] In a first aspect, the present invention provides a test sequence scenario generation method, comprising: obtaining a full test sequence directed graph and configuration information of the software to be tested; the full test sequence directed graph comprises multiple nodes and multiple edges; each of the multiple nodes is uniquely mapped to an application interface in each application interface of the software to be tested; the multiple edges indicate the calling order between the application interfaces; the configuration information defines the calling resources of the application interfaces and the constraint relationship between the calling resources; determining each test sequence of the full test sequence directed graph to generate a directed subgraph; for each test sequence directed subgraph in each test sequence directed subgraph, generating a test sequence scenario of the test sequence directed subgraph according to the test sequence directed subgraph and the corresponding sub-configuration information in the configuration information; thereby indicating the application interface and the calling order in the test sequence scenario through the test sequence directed subgraph, and indicating the calling resources of the application interface in the test sequence scenario and the constraint relationship between the calling resources through the sub-configuration relationship.

[0006] In the above method, a full test sequence directed graph and configuration information of the software to be tested are obtained; a mapping relationship in which a unique mapping is established between each of the multiple nodes in the full test sequence directed graph and one of the application interfaces of the software to be tested, and a calling order between the application interfaces is indicated by multiple edges, and the calling resources of the application interfaces and the constraint relationships between the calling resources are defined in the configuration information; therefore, after determining that each test sequence of the full test sequence directed graph generates a directed subgraph, a test sequence scenario that can indicate the calling order, calling resources and constraint relationships of the application interface can be generated for each test sequence directed subgraph according to the test sequence directed subgraph and the corresponding sub-configuration information in the configuration information, so that the full test sequence directed graph and configuration information can be reused, thereby improving the efficiency of the test sequence scenarios of the application software.

[0007] In an optional implementation, the test sequence scenario of each test sequence directed subgraph includes an assertion test prediction scenario; the application program interface in the assertion test prediction scenario includes a test assertion statement; and the test assertion statement is used to indicate the execution status of the application program interface.

[0008] In the above method, the test sequence scenario of each test sequence directed subgraph includes an assertion test prediction scenario, and the test assertion statement in the application interface in the assertion test prediction scenario is used to indicate the execution status of the application interface, so that the test results of the test sequence scenario can be more clearly reflected through the test assertion statement.

[0009] In an optional implementation, during the testing process under the assertion test sequence scenario, if it is determined that the execution status of the application interface indicated by the test assertion statement is execution failure, the test failure under the assertion test sequence scenario is directly determined, and the test under the assertion test sequence scenario is exited.

[0010] In the above method, during the testing process under the assertion test sequence scenario, the test does not continue until the end to determine that the test under the assertion test sequence scenario has failed. Instead, when it is determined that the execution status of the application interface indicated by the test assertion statement is an execution failure, the test failure under the assertion test sequence scenario is directly determined, and the test under the assertion test sequence scenario is exited in advance, thereby saving the time for outputting the test results.

[0011] In an optional implementation, if it is determined that the execution status of the application program interface indicated by all the test assertion statements in the assertion test sequence scenario is successful, then it is determined that the test in the assertion test sequence scenario is successful.

[0012] Under the above method, the test success in the assertion test sequence scenario is determined only when the execution status of the application interface indicated by all test assertion statements in the assertion test sequence scenario is determined to be successful, thereby further verifying through the test assertion statement, thereby increasing the robustness of the test in the assertion test sequence scenario.

[0013] In an optional implementation, each application program interface includes: a first operation interface and a second operation interface; the calling input resource of the second operation interface is the calling output resource of the first operation interface; before the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resource of the first operation interface on the second operation interface side is a locked state, and after the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resource of the first operation interface on the second operation interface side is an available state.

[0014] Under the above method, the calling input resources of the second operation interface are the calling output resources of the first operation interface; before the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resources of the first operation interface on the second operation interface side is a locked state. By constraining the calling output resources, they are available only after indicating that the test of the first operation interface is successful, thereby increasing the protection of the calling resources during the test process.

[0015] In an optional implementation, the method of determining that each test sequence of the directed graph of the full test sequence generates a directed subgraph includes: for each starting node of each directed subgraph generated by each test sequence, executing the following steps: obtaining a target node; the target node is initially the starting node; if the target node has no subsequent node, all edges and nodes indicated by the traversal path from the starting node to the target node are used as a test sequence to generate a directed subgraph; if the target node has at least one subsequent node, the subsequent node of the at least one subsequent node is used as the target node, and the step of obtaining the target node is returned.

[0016] Under the above method, after obtaining the target node, if the target node has no subsequent node, all edges and nodes indicated by the traversal path from the starting node to the target node are traversed as a test sequence to generate a directed subgraph; if the target node has at least one subsequent node, the subsequent node of the at least one subsequent node is used as the target node, and the step of obtaining the target node is returned, so that the target node corresponding to the final application interface can be traversed in one round, and a method for generating a directed subgraph by generating a complete test sequence is given.

[0017] In an optional implementation, the starting node of each directed subgraph generated by each test sequence is a node with an in-degree of 0 in the directed graph of all test sequences; and the out-degree of each node in the generated directed subgraph is less than 2.

[0018] Under the above method, the starting node of each directed subgraph generated by each test sequence is a node with an in-degree of 0 in the directed graph of the full test sequence, so that the application interface corresponding to the initial node of each generated directed subgraph has unconstrained calling resources, and the out-degree of each node in the generated directed subgraph is less than 2, so that each node of the test sequence directed subgraph has only one subsequent node, and after each application interface is tested, only one application interface is determined to be tested, thereby ensuring the test stability of the test sequence scenario of the test sequence directed subgraph.

[0019] In a second aspect, the present invention provides a test sequence scenario generating device, comprising: an acquisition module, used to acquire a full test sequence directed graph and configuration information of the software to be tested; the full test sequence directed graph includes multiple nodes and multiple edges; each of the multiple nodes is uniquely mapped to an application interface in each application interface of the software to be tested; the multiple edges indicate the calling order between the application interfaces; the configuration information defines the calling resources of the application interfaces and the constraint relationship between the calling resources; a processing module, used to determine each test sequence of the full test sequence directed graph to generate a directed subgraph; for each test sequence directed subgraph in each test sequence directed subgraph, a test sequence scenario of the test sequence directed subgraph is generated according to the test sequence directed subgraph and the corresponding sub-configuration information in the configuration information; thereby indicating the application interface and the calling order in the test sequence scenario through the test sequence directed subgraph, and indicating the calling resources of the application interface in the test sequence scenario and the constraint relationship between the calling resources through the sub-configuration relationship.

[0020] In an optional implementation, the test sequence scenario of each test sequence directed subgraph includes an assertion test prediction scenario; the application program interface in the assertion test prediction scenario includes a test assertion statement; and the test assertion statement is used to indicate the execution status of the application program interface.

[0021] In an optional implementation, during the testing process under the assertion test sequence scenario, if it is determined that the execution status of the application interface indicated by the test assertion statement is execution failure, the test failure under the assertion test sequence scenario is directly determined, and the test under the assertion test sequence scenario is exited.

[0022] In an optional implementation, if it is determined that the execution status of the application program interface indicated by all the test assertion statements in the assertion test sequence scenario is successful, then it is determined that the test in the assertion test sequence scenario is successful.

[0023] In an optional implementation, each application program interface includes: a first operation interface and a second operation interface; the calling input resource of the second operation interface is the calling output resource of the first operation interface; before the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resource of the first operation interface on the second operation interface side is a locked state, and after the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resource of the first operation interface on the second operation interface side is an available state.

[0024] In an optional implementation, the processing module is specifically used to: for each starting node of the directed subgraph generated by each test sequence, perform the following steps: obtain a target node; the target node is initially the starting node; if the target node has no subsequent node, all edges and nodes indicated by the traversal path from the starting node to the target node are used as a test sequence to generate a directed subgraph; if the target node has at least one subsequent node, the subsequent node of the at least one subsequent node is used as the target node, and the step of obtaining the target node is returned.

[0025] In an optional implementation, the starting node of each directed subgraph generated by each test sequence is a node with an in-degree of 0 in the directed graph of all test sequences; and the out-degree of each node in the generated directed subgraph is less than 2.

[0026] The above-mentioned second aspect and each beneficial effect of the second aspect can refer to the above-mentioned first aspect and each beneficial effect of the first aspect, and will not be repeated here.

[0027] In a third aspect, the present invention provides a computer device, including a program or an instruction, which, when executed, is used to execute the above-mentioned first aspect and each optional method of the first aspect.

[0028] In a fourth aspect, the present invention provides a storage medium, comprising a program or an instruction, which, when executed, is used to execute the above-mentioned first aspect and each optional method of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 A schematic diagram of the steps of a test sequence scenario generation method provided in an embodiment of the present application;

[0030] Figure 2 A schematic diagram of a directed graph of a full test sequence in a test sequence scenario generation method provided in an embodiment of the present application;

[0031] Figure 3 A schematic diagram of a test sequence directed subgraph in a test sequence scenario generation method provided in an embodiment of the present application;

[0032] Figure 4 A schematic diagram of a test sequence directed subgraph in a test sequence scenario generation method provided in an embodiment of the present application;

[0033] Figure 5 A schematic diagram of a test sequence directed subgraph in a test sequence scenario generation method provided in an embodiment of the present application;

[0034] Figure 6 A schematic diagram of the structure of a test sequence scenario generating device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] In order to better understand the above-mentioned technical scheme, the above-mentioned technical scheme will be described in detail below in combination with the accompanying drawings and specific implementation methods of the specification. It should be understood that the embodiments of the present application and the specific features in the embodiments are detailed descriptions of the technical scheme of the present application, rather than limitations on the technical scheme of the present application. In the absence of conflict, the embodiments of the present application and the technical features in the embodiments may be combined with each other.

[0036] The definitions of the nouns in the embodiments of the present application are first listed below.

[0037] Application Programming Interface (API): API is an application programming interface provided by software services to the outside world. It is usually called in a variety of ways, such as web page (Web) method. Software services are coupled based on interfaces. The correct understanding and calling of interface data and functions are the basis of service integration quality. Therefore, API testing is essential.

[0038] Service under test: The software service that needs to be tested.

[0039] API specification: A document that describes API calling rules and other calling information.

[0040] Test generation: APIs are called through call requests (such as HyperText Transfer Protocol (HTTP) requests). When testing APIs, the values ​​of parameters are usually filled in according to the API specification, and a call request (such as an HTTP request) is constructed and sent to the service under test.

[0041] Test sequence scenario: a set of tests consisting of multiple API sequences.

[0042] When a financial institution (bank, insurance or securities institution) is operating its business (such as a bank's loan business, deposit business, etc.), it can implement relevant functions of the software by calling the application program interface of the financial institution's application software. Before the financial software goes online, it must be tested under different test sequence scenarios.

[0043] In software testing, the test results of a single application interface are generally difficult to verify. Metamorphic testing proposes another solution when the test results are difficult to verify. In metamorphic testing, the characteristics of the application interface itself can be used, or after the application interface is executed, subsequent operations can be used to verify whether the application interface has achieved the expected goal. For example, after the deletion interface is executed, only a returned deletion status code cannot prove that the object to be deleted is indeed deleted. The results of the query interface before and after the deletion interface can be further compared. For example, before the deletion interface is executed, the object to be deleted is still there. If the object to be deleted is no longer there after the query interface is executed twice, the probability of passing the deletion interface test is increased. If the object to be deleted is not removed from the object list after the query interface is executed twice, it means that there is a problem with the query interface and the deletion interface, and the specific problem can be further investigated. Obviously, testing the software through a series of test sequence scenarios of the application interface can better verify the accuracy of the interface.

[0044] The existing technology can only generate each test sequence scenario in sequence, and each time a test sequence scenario is generated, the generation process needs to be repeated, resulting in low efficiency in generating test sequence scenarios for application software. This situation does not meet the needs of financial institutions such as banks and cannot ensure the efficient operation of various businesses of financial institutions.

[0045] For this reason, Figure 1 As shown, the present application provides a test sequence scenario generation method.

[0046] Step 101: Obtain the full test sequence directed graph and configuration information of the software to be tested.

[0047] Step 102: Determine each test sequence of the full test sequence directed graph to generate a directed subgraph.

[0048] Step 103: for each test sequence directed subgraph in the test sequence directed subgraphs, generate a test sequence scenario of the test sequence directed subgraph according to the test sequence directed subgraph and the corresponding sub-configuration information in the configuration information.

[0049] The full test sequence directed graph in step 101 includes multiple nodes and multiple edges, and the full test sequence directed graph is used to generate directed subgraphs for each test sequence. Each of the multiple nodes is uniquely mapped to an application program interface in each application program interface of the software to be tested; and the multiple edges indicate the calling order between the application program interfaces.

[0050] Specifically, the definition of the directed graph of the full test sequence is as follows:

[0051] Scenario:<Nodes,Edges>

[0052] Nodes defines each node in the directed graph of the full test sequence, and Edges represents the possible calling sequence between each application interface.

[0053] A test sequence scenario can be defined as follows:

[0054] ScenarioList∶=<Spec,Actions,DataSets>

[0055] Where: Spec is the API specification; Actions is a collection of operations; DataSets: = {<data_name,data_value>}Used for transferring data between interfaces; it should be noted that calling an application interface can execute one or more operations in Actions.

[0056] Action is defined as follows, corresponding to one of the operations:

[0057] Action∶=<ID,Name,Inputs,Outputs> ;

[0058] Among them, ID indicates the identifier of the operation, which is used to confirm the order of the operation; name indicates the name of the operation's application interface, which needs to be defined in Spec; Inputs indicates the additional input before executing the operation, which overrides the default input; Outputs indicates the parameters that need to be output to DataSets after executing the operation. During the test process, the test system can execute the operations in the test sequence scenario in sequence.

[0059] In addition, the configuration information defines the calling resources of each application interface and the constraint relationship between the calling resources, that is, the description information corresponding to each node in the directed graph of the full test sequence, which may include additional input and output information required by each application interface.

[0060] It should be noted that the test sequence scenarios of each test sequence directed subgraph may include an assertion test prediction scenario; the application program interface in the assertion test prediction scenario includes a test assertion statement; and the test assertion statement is used to indicate the execution status of the application program interface.

[0061] That is to say, for any application interface, you can set a test assertion statement to more comprehensively characterize the execution status of the application interface during the test process. The execution status includes but is not limited to: successful execution and failed execution. You can also set the execution status according to the specific application scenario, such as normal execution, abnormal execution, etc.

[0062] The functions of the test assertion statement may include the following two:

[0063] The first one:

[0064] During the test process under the assertion test sequence scenario, if it is determined that the execution status of the application program interface indicated by the test assertion statement is execution failure, the test failure under the assertion test sequence scenario is directly determined, and the test under the assertion test sequence scenario is exited.

[0065] For example, the interfaces involved in assertion test sequence scenario 1 are: interface A1, interface A2, interface A3, interface A4. An assertion test statement is set in interface A2, and during the test of interface A2, the application interface execution status indicated by the assertion test statement in A2 is execution failure, then the test failure of assertion test sequence scenario 1 is directly determined.

[0066] Second type:

[0067] During the test process in the assertion test sequence scenario, if it is determined that the execution status of the application program interface indicated by all the test assertion statements in the assertion test sequence scenario is successful, then the test in the assertion test sequence scenario is determined to be successful.

[0068] For example, the interfaces involved in the assertion test sequence scenario 2 are: interface B1, interface B2, interface B3, interface B4, interface B5. Assertion test statements are set in interface B2 and interface B5. If both interface B2 and interface B5 are tested successfully during the test of the assertion test sequence scenario 2, it is determined that the test of the assertion test sequence scenario 2 is successful.

[0069] Based on the test assertion statement, in an optional implementation, each application program interface includes: a first operation interface and a second operation interface; the calling input resources of the second operation interface are the calling output resources of the first operation interface; before the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resources of the first operation interface on the second operation interface side is a locked state, and after the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resources of the first operation interface on the second operation interface side is an available state.

[0070] Combine the following Figure 2 , describes the full test sequence directed graph and configuration information in detail.

[0071] It should be noted that the following only lists the configuration information of each application interface, and does not list the specific functional operations performed by each application interface. The operations in the Action in the test sequence scenario may be operations that implement these specific functions, or they may be related operations of the configuration information. In the following configuration information, ResourceName and ResourceList are local variables, and their scope is each application interface; env-ResourceName and env-ResourceList are global variables, and their scope is each application interface. Figure 2 The five application program interfaces shown are illustrated as examples, specifically including: a create interface (Create), a query interface one (Read1), a delete interface (Delete), an update interface (Update) and a query interface two (Read2).

[0072] Create:

[0073] ActionCreate= <ID=0,Name=’Create’,Inputs=[],Outputs=[<ResourceName,’equal’,env-ResourceName> ];

[0074] Outputs = [<ResourceName,’equal’,env-ResourceName> ]

[0075] The items in Outputs mean that the parameter ResourceName in the Create operation is written into the environment parameter env-ResourceName, and the value of the environment parameter env-ResourceName is equal to the value of ResourceName in the Create operation.

[0076] It should be noted that the Create application program interface executes the specific function Create(){}. In fact, during the execution of Create(){}, the resource ResourceName is added to the resource list ResourceList, and then the resource ResourceName is passed to Read1. Passing the ResourceList in Create to the ResourceList in Read1 is not listed in the configuration information.

[0077] Read1:

[0078] ActionRead1= <ID=1,Name=’Read’,

[0079] Inputs=[<Assert1,’assert_in’,[Resource-Name,ResourceList]> ]],

[0080] Outputs = [<ResourceList,’equal’,env-ResourceList> ]

[0081] Among them, the Inputs item refers to receiving the ResourceName resource passed by Create, and checking whether the Resource generated in the previous step is in the response ResourceList according to ResourceName, that is, whether the creation operation is successfully completed (that is, whether create(){} is executed normally); the Inputs item refers to writing the parameter ResourceList in the Read operation into the environment parameter env-ResourceList, and the value of the environment parameter env-ResourceList is equal to the value of ResourceList in the Read operation.

[0082] Delete:

[0083] ActionUpdate= <ID=2,Name=’Update’,

[0084] Inputs=[<ResourceName,’equal’,env-ResourceName> ,

[0085] <Assert2,’assert_ResourceNotExistException’,

[0086] [Resource-Name,env-ResourceList]>],

[0087] Outputs = [<ResourceName,’remove’,env-ResourceList> ]

[0088] The meaning of the Inputs item is that when the parameter ResourceName is generated, the environment parameter env-ResourceName is searched and assigned to the parameter ResourceName in an equal way. An assertion is also added that if the updated object is not in the resource list, an exception should be thrown in response. The meaning of the Outputs item is that according to the request parameter ResourceName, the corresponding item in the environment parameter env-ResourceList is removed.

[0089] It should be noted that env-ResourceName is the resource to be deleted, which is also the resource created by Create and queried in Read1. By assigning env-ResourceName to ResourceName, Delete is told which resource to delete. First, check whether it is in the env-ResourceList list. If it is not, then there is no way to delete it. If it is, then it can be deleted. That is, the value of ResourceName (actually the value of env-ResourceName) is used to remove the corresponding item (env-ResourceName) in env-ResourceList.

[0090] Update:

[0091] ActionDelete= <ID=3,Name=’Delete’,

[0092] Inputs=[<ResourceName,’equal’,env-ResourceName> ],

[0093] Outputs = [<ResourceDetail,’update’,env-ResourceList> ]

[0094] The meaning of the Inputs item is to find the environment parameter env-ResourceName when the parameter ResourceName is generated, and assign it to the parameter ResourceName by equals; the meaning of the Outputs item is to update the value of the corresponding item in the environment parameter env-ResourceList according to the request parameter ResourceDetail. Similar to Delete, except that the next step is to replace the specific resource information of the resource name ResourceName in env-ResourceName with ResourceDetail.

[0095] Read2:

[0096] ActionRead2= <ID=4,Name=’Read’,

[0097] Inputs=[<Assert3,’assert_equal’,[ResourceList,env-ResourceList]> ],Outputs=[]

[0098] The meaning of the item in Inputs is to add equal assertions to determine whether the response parameter ResourceList is equal to the environment parameter env-ResourceList. This step is to verify again, that is, whether it is after deleting the interface call or updating the interface call, compare the current ResourceList with the actual ResourceList to see if they are consistent.

[0099] The above interfaces constitute the Nodes in the scene. The edges in the scene include:<Create,Read1> ,<Read1,Update> ,<Read1,Delete> ,<Delete,Update> ,<Delete,Read2> ,<Update,Read2> .

[0100] It should be noted that Figure 2 The rectangular nodes and solid lines shown belong to the directed graph of the full test sequence. The rectangular nodes correspond to the application interface, and the solid lines correspond to the calling of the application interface. The dotted boxes and ellipses are just the image representations of the resource transfer or constraints of each application interface call, and do not belong to the directed graph of the full test sequence.

[0101] A specific optional implementation of step 102 may be:

[0102] For each starting node of a directed subgraph generated for each test sequence, the following steps are performed: obtaining a target node; the target node is initially the starting node; if the target node has no subsequent node, all edges and nodes indicated by the traversal path from the starting node to the target node are used as a test sequence to generate a directed subgraph; if the target node has at least one subsequent node, the subsequent node of the at least one subsequent node is used as the target node, and the step of obtaining the target node is returned.

[0103] For example, if the start node corresponds to Create, then in the first traversal, the target node corresponds to Create, and the subsequent node has only one Read1; in the second traversal, the target node corresponds to Read1, and the subsequent nodes have Delete and Update; in the third traversal, if the subsequent node chooses Delete to correspond to the target node, then in the fourth traversal, the subsequent node has only one Read2. Then the generated test sequence generates a directed subgraph as < <Create,Read1,Delete,Read2;<Create,Read1> ,<Read1,Delete> ,<Delete,Read2> >.

[0104] It should be noted that, in one possible implementation of the above optional implementation manner:

[0105] The starting node of each directed subgraph generated by each test sequence is a node with an in-degree of 0 in the directed graph of the full test sequence; the out-degree of each node in the generated directed subgraph is less than 2. For example, the starting node of each generated directed subgraph is Create; and there will be no situation in the subgraph where Delete and Update are selected as target nodes at the same time, that is, there is no fork after the node.

[0106] Combine the following Figure 3 to Figure 5 Generate an instance of a directed subgraph for each test sequence.

[0107] Figure 3 It shows that the test sequence generates a directed subgraph. After creating the resource, a query operation is performed to check whether the newly created resource is in the resource list according to the assertion; Figure 4 It shows that in the directed subgraph generated by the test sequence, after the resource is created, a query operation is performed to check whether the newly created resource is in the resource list according to the assertion. If so, the resource list is updated, and the assertion test is performed again in the query interface 2 to determine whether the resource list meets expectations; Figure 5It is shown that the test sequence generates a directed subgraph. After the resource is created, a query operation is performed to check whether the newly created resource is in the resource list based on the assertion. If so, the resource is deleted from the resource list, and the assertion test is performed again in query interface 2 to determine whether the resource list meets expectations.

[0108] Through step 103, the application program interface and the calling order in the test sequence scenario can be indicated through the test sequence directed subgraph, and the calling resources of the application program interface in the test sequence scenario and the constraint relationship between the calling resources can be indicated through the sub-configuration relationship.

[0109] like Figure 6 As shown, the present invention provides a test sequence scenario generation device, including: an acquisition module 601, used to obtain a full test sequence directed graph and configuration information of the software to be tested; the full test sequence directed graph includes multiple nodes and multiple edges; each of the multiple nodes is uniquely mapped to an application interface in each application interface of the software to be tested; the multiple edges indicate the calling order between the application interfaces; the configuration information defines the calling resources of the application interfaces and the constraint relationship between the calling resources; a processing module 602, used to determine each test sequence of the full test sequence directed graph to generate a directed subgraph; for each test sequence directed subgraph in each test sequence directed subgraph, according to the test sequence directed subgraph and the corresponding sub-configuration information in the configuration information, generate a test sequence scenario of the test sequence directed subgraph; thereby indicating the application interface and the calling order in the test sequence scenario through the test sequence directed subgraph, and indicating the calling resources of the application interface in the test sequence scenario and the constraint relationship between the calling resources through the sub-configuration relationship.

[0110] In an optional implementation, the test sequence scenario of each test sequence directed subgraph includes an assertion test prediction scenario; the application program interface in the assertion test prediction scenario includes a test assertion statement; and the test assertion statement is used to indicate the execution status of the application program interface.

[0111] In an optional implementation, during the testing process under the assertion test sequence scenario, if it is determined that the execution status of the application interface indicated by the test assertion statement is execution failure, the test failure under the assertion test sequence scenario is directly determined, and the test under the assertion test sequence scenario is exited.

[0112] In an optional implementation, if it is determined that the execution status of the application program interface indicated by all the test assertion statements in the assertion test sequence scenario is successful, then it is determined that the test in the assertion test sequence scenario is successful.

[0113] In an optional implementation, each application program interface includes: a first operation interface and a second operation interface; the calling input resource of the second operation interface is the calling output resource of the first operation interface; before the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resource of the first operation interface on the second operation interface side is a locked state, and after the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resource of the first operation interface on the second operation interface side is an available state.

[0114] In an optional implementation, the processing module 602 is specifically used to: for each starting node of the directed subgraph generated by each test sequence, perform the following steps: obtain a target node; the target node is initially the starting node; if the target node has no subsequent node, all edges and nodes indicated by the traversal path from the starting node to the target node are used as a test sequence to generate a directed subgraph; if the target node has at least one subsequent node, the subsequent node of the at least one subsequent node is used as the target node, and the step of obtaining the target node is returned.

[0115] In an optional implementation, the starting node of each directed subgraph generated by each test sequence is a node with an in-degree of 0 in the directed graph of all test sequences; and the out-degree of each node in the generated directed subgraph is less than 2.

[0116] An embodiment of the present application provides a computer device, including a program or an instruction. When the program or the instruction is executed, it is used to execute a test sequence scenario generation method and any optional method provided in the embodiment of the present application.

[0117] An embodiment of the present application provides a storage medium, including a program or an instruction, which, when executed, is used to execute a test sequence scenario generation method and any optional method provided in an embodiment of the present application.

[0118] Finally, it should be noted that: those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, optical storage, etc.) containing computer-usable program code.

[0119] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0120] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0121] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A test sequence scenario generation method, characterized in that: include: Obtaining a directed graph of a full test sequence and configuration information of the software to be tested; the directed graph of the full test sequence includes a plurality of nodes and a plurality of edges; Each of the multiple nodes is uniquely mapped to one of the application program interfaces of the software to be tested; the multiple edges indicate the calling sequence between the application program interfaces; the configuration information defines the calling resources of the application program interfaces and the constraint relationship between the calling resources; Determine that each test sequence of the full test sequence directed graph generates a directed subgraph; the test sequence scenario of each test sequence directed subgraph includes an assertion test prediction scenario; The application program interface in the assertion test prediction scenario includes a test assertion statement; the test assertion statement is used to indicate the execution status of the application program interface; For each test sequence directed subgraph in each test sequence directed subgraph, a test sequence scenario of the test sequence directed subgraph is generated according to the test sequence directed subgraph and the corresponding sub-configuration information in the configuration information; thereby, the application program interface and the calling order in the test sequence scenario are indicated through the test sequence directed subgraph, and the calling resources of the application program interface in the test sequence scenario and the constraint relationship between the calling resources are indicated through the sub-configuration relationship.

2. The method according to claim 1, characterized in that During the test process under the assertion test sequence scenario, if it is determined that the execution status of the application program interface indicated by the test assertion statement is execution failure, the test failure under the assertion test sequence scenario is directly determined, and the test under the assertion test sequence scenario is exited.

3. The method according to claim 1, characterized in that If it is determined that the execution status of the application program interface indicated by all the test assertion statements in the assertion test sequence scenario is successful, then it is determined that the test in the assertion test sequence scenario is successful.

4. The method according to claim 1, characterized in that Each of the application program interfaces includes: a first operation interface and a second operation interface; the calling input resource of the second operation interface is the calling output resource of the first operation interface; Before the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resources of the first operation interface on the second operation interface side is a locked state; after the test assertion of the first operation interface indicates that the test of the first operation interface is successful, the execution status of the calling output resources of the first operation interface on the second operation interface side is an available state.

5. The method according to any one of claims 1 to 4, characterized in that: The step of determining that each test sequence of the directed graph of the full test sequence generates a directed subgraph includes: For each starting node of the directed subgraph generated by each test sequence, the following steps are performed: Acquire a target node; the target node is initially the start node; If the target node has no subsequent node, all edges and nodes indicated by the traversal path from the starting node to the target node are used as a test sequence to generate a directed subgraph; if the target node has at least one subsequent node, the subsequent node of the at least one subsequent node is used as the target node, and the step of obtaining the target node is returned.

6. The method according to claim 5, characterized in that The starting node of each directed subgraph generated by each test sequence is a node with an in-degree of 0 in the directed graph of all test sequences; and the out-degree of each node in the generated directed subgraph is less than 2.

7. A test sequence scenario generating device, characterized in that: include: An acquisition module, used to acquire a directed graph of a full test sequence and configuration information of the software to be tested; the directed graph of the full test sequence includes a plurality of nodes and a plurality of edges; Each of the multiple nodes is uniquely mapped to one of the application program interfaces of the software to be tested; the multiple edges indicate the calling sequence between the application program interfaces; the configuration information defines the calling resources of the application program interfaces and the constraint relationship between the calling resources; A processing module, used for determining that each test sequence of the full test sequence directed graph generates a directed subgraph; the test sequence scenario of each test sequence directed subgraph includes an assertion test prediction scenario; The application program interface in the assertion test prediction scenario includes a test assertion statement; the test assertion statement is used to indicate the execution status of the application program interface; for each test sequence directed subgraph in each test sequence directed subgraph, a test sequence scenario of the test sequence directed subgraph is generated according to the test sequence directed subgraph and the corresponding sub-configuration information in the configuration information; thereby indicating the application program interface and the calling order in the test sequence scenario through the test sequence directed subgraph, and indicating the calling resources of the application program interface in the test sequence scenario and the constraint relationship between the calling resources through the sub-configuration relationship.

8. A computer device, characterized in that: The method comprises a program or an instruction, and when the program or the instruction is executed, the method according to any one of claims 1 to 6 is performed.

9. A storage medium, characterized in that: The method comprises a program or an instruction, and when the program or the instruction is executed, the method according to any one of claims 1 to 6 is performed.

Images