BPEL workflow testing method and related equipment

Abstract

The present application provides a BPEL workflow testing method and related equipment. The method comprises: firstly, converting the BPEL workflow into an activity constraint graph, then determining the feasibility of the BPEL activity path according to the activity constraint graph and obtaining the corresponding test case; then selecting the target test case from the test case according to the generated program dependency graph and determining the priority of the target test; finally, testing the target test case according to the priority. It plays a supporting role in the testing of the BPEL workflow, and can improve the accuracy and efficiency of the test while ensuring the safety of the BPEL workflow test.

Description

Technical Field

[0001] The present application relates to the technical field of business process execution language, and in particular to a BPEL workflow testing method and related equipment. Background Art

[0002] Service-oriented computing (SOC) has changed the traditional understanding of software (application design, delivery and consumption), and also changed the way the information support system of national defense engineering works. The core of SOC is to create a more systematic and effective way to build distributed applications, with the goal of building a world of loosely coupled services that can quickly combine dynamic business processes and applications. As software becomes more agile to meet business needs, many companies are adopting service-centric systems (ScS). Software testing provides a guarantee for the normal function of ScS. In order to confirm the correct function of ScS (especially BPEL workflows), the interoperability between all its components and the integration of these components must be fully tested. Business Process Execution Language (BPEL) workflows require more frequent testing than traditional software, because changes to BPEL workflows may increase with the increase in the number of services involved. With each change to the called service, the BPEL workflow may need to be tested every time. Therefore, a solution is needed to ensure the accuracy and efficiency of the test while ensuring the safety of the BPEL workflow test. Summary of the invention

[0003] In view of this, the purpose of this application is to propose a BPEL workflow testing method and related equipment.

[0004] Based on the above purpose, the present application provides a BPEL workflow testing method, which is characterized by comprising:

[0005] Input BPEL workflow and convert the input BPEL workflow into activity constraint graph;

[0006] Determining the feasibility of the BPEL activity path according to the activity constraint graph, and obtaining at least one test case from the solver;

[0007] Generate a program dependency graph of the BPEL workflow, and select a target test case to run from at least one test case according to the program dependency graph;

[0008] Determining the priority of target test cases corresponding to the BPEL activity according to the program dependency graph;

[0009] The target test case is tested according to the priority of the target test case.

[0010] In some implementations, converting the input BPEL workflow into an activity constraint graph includes:

[0011] The input first BPEL workflow is converted into a first control flow graph, and the second BPEL workflow is converted into a second control flow graph, and an activity constraint graph is generated according to the constraint relationship of the BPEL activity nodes between the first control flow graph and the second control flow graph.

[0012] In some implementations, determining the feasibility of the BPEL activity path according to the activity constraint graph and obtaining at least one test case from a solver includes:

[0013] The activity constraint graph is decomposed into multiple BPEL activity paths, and the multiple BPEL activity paths are respectively symbolically encoded, the feasibility of the multiple BPEL activity paths is determined according to the symbolic encoding, and the test cases corresponding to the feasible BPEL activity paths among the multiple BPEL activity paths are obtained from the solver.

[0014] In some implementations, the plurality of BPEL activity paths are symbolically encoded by path constraints, program order constraints, read-write constraints, synchronization constraints, and message constraints.

[0015] In some implementations, generating a program dependency graph of the BPEL workflow and selecting a target test case to run according to the program dependency graph includes:

[0016] Generate a program dependency graph of the first BPEL workflow and the second BPEL workflow, identify components in the second BPEL workflow that are affected by the first BPEL workflow through a program slicing method based on the program dependency graph, and select target test cases to run based on the components affected by the first BPEL workflow.

[0017] In some implementations, the program dependency graph is determined based on control dependency, data dependency, asynchronous call dependency, correlation dependency, and synchronization dependency, wherein:

[0018] The related dependency indicates that the second activity is related to the first activity if and only if the first activity and the second activity in the program dependency graph are both receiving activities in the BPEL workflow, and the value of the attribute feature of the first activity is a positive value;

[0019] The synchronous dependency indicates that the second activity is synchronously dependent on the first activity if and only if the first activity and the second activity in the program dependency graph are both included in the flow activity and the second activity is the target of a link with the first activity as the source.

[0020] In some implementations, determining the priority of the target test case corresponding to the BPEL activity according to the program dependency graph includes:

[0021] The modification impact of each BPEL activity is calculated according to the program dependency graph of the first BPEL workflow and the second BPEL workflow, and the priority of the corresponding test case is determined according to the modification impact of the BPEL activity.

[0022] Based on the same concept, the present application also provides a BPEL workflow testing device, which is characterized by comprising:

[0023] A modeling module, configured to input a BPEL workflow and convert the input BPEL workflow into an activity constraint graph;

[0024] an acquisition module, configured to determine the feasibility of the BPEL activity path according to the activity constraint graph, and acquire at least one test case from the solver;

[0025] A selection module is configured to generate a program dependency graph of the BPEL workflow, and select a target test case to be run from at least one test case according to the program dependency graph;

[0026] A sorting module, configured to determine the priority of the target test cases corresponding to the BPEL activities according to the program dependency graph;

[0027] The testing module is configured to test the target test case according to the priority of the target test case.

[0028] Based on the same concept, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements any of the methods described above when executing the program.

[0029] Based on the same concept, the present application also provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable the computer to implement any of the methods described above.

[0030] From the above description, it can be seen that the BPEL workflow testing method and related equipment provided by the present application first convert the BPEL workflow into an activity constraint graph, then determine the feasibility of the BPEL activity path and obtain the corresponding test case based on the activity constraint graph; then select the target test case from the test case based on the generated program dependency graph and determine the priority of the target test; finally, test the target test case based on the priority. It plays a supporting role in the testing of the BPEL workflow, and can improve the accuracy and efficiency of the test while ensuring the safety of the BPEL workflow test. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions in the present application or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0032] Figure 1 This is a flow chart of the BPEL workflow testing method according to an embodiment of the present application;

[0033] Figure 2 This is a flow chart of the activity constraint graph conversion method of an embodiment of the present application;

[0034] Figure 3 This is a flow chart of the active node parsing method according to an embodiment of the present application;

[0035] Figure 4 This is a schematic diagram of the BPEL workflow of an embodiment of the present application;

[0036] Figure 5 A schematic diagram of a potential feasible path 1 of a BPEL workflow in an embodiment of the present application;

[0037] Figure 6 A schematic diagram of a potential feasible path 2 of the BPEL workflow in an embodiment of the present application;

[0038] Figure 7 A schematic diagram of a BPEL workflow variant of an embodiment of the present application;

[0039] Figure 8a A program dependency diagram of a BPEL workflow according to an embodiment of the present application;

[0040] Figure 8b A program dependency graph corresponding to a variant of the BPEL workflow of an embodiment of the present application;

[0041] Fig. 9 This is a schematic diagram of a BPEL workflow testing device according to an embodiment of the present application;

[0042] Fig.10 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0043] In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0044] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be the usual meanings understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in the embodiments of the present application do not represent any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements or objects appearing in front of the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0045] As described in the background technology section, the existing BPEL workflow test is still difficult to meet the requirements of test security and accuracy. In the process of implementing this application, the applicant found that the main problems of the existing BPEL workflow test are:

[0046] 1. Since users can only access the service interface, the observability of the service code and structure is limited.

[0047] 2. Due to independent infrastructure, service operations and due to lack of control the provider is the only control mechanism for service evolution.

[0048] 3. Dynamicity and adaptability limit the tester's ability to determine the execution of the called service during the workflow execution.

[0049] 4. Testing costs: the cost of using the service (for services with access quotas or per-use); service disruptions that may be caused by large-scale testing.

[0050] Existing testing methods must take these limitations into account. In order to effectively test and monitor a specific test system, BPEL workflow testing must be able to execute as many test methods as possible and must be easy to deploy. Ease of deployment is an important feature because it usually takes a long time to set up a test environment for a distributed system. However, doing so may increase testing latency, which is unacceptable in BPEL workflow testing in some special environments.

[0051] In view of this, one or more embodiments of this specification provide a BPEL workflow testing solution, which first converts the BPEL workflow into an activity constraint graph, then determines the feasibility of the BPEL activity path based on the activity constraint graph and obtains the corresponding test case; then selects the target test case from the test case based on the generated program dependency graph and determines the priority of the target test; finally, tests the target test case based on the priority. The technical solutions of each specific embodiment of this application are described below.

[0052] refer to Figure 1 The BPEL workflow testing method of an embodiment of the present specification includes the following steps:

[0053] Step S101: input a BPEL workflow, and convert the input BPEL workflow into an activity constraint graph;

[0054] In this step, there can be two BPEL workflows: a first BPEL workflow and a second BPEL workflow. The first BPEL workflow is converted into a first control flow graph, and the second BPEL workflow is converted into a second control flow graph, and an activity constraint graph is generated according to the constraint relationship of the BPEL activity nodes between the first control flow graph and the second control flow graph.

[0055] In some implementation scenarios, it is necessary to test the updated program to find out whether there will be any operation errors after the update. In this case, the program before the update can be generated into a first BPEL workflow, and the updated program can be generated into a second BPEL workflow for subsequent operation testing.

[0056] In this step, it is actually a process of mapping the BPEL workflow and WSDL specification into a control flow graph (BCFG) model. Therefore, the BCFG data model is first defined, and then the BPEL workflow and WSDL (Web Services Description Language) are parsed into a DOM (Document Object Model, DOM for short) data model, and the conversion of the DOM data model to the BCFG data model is completed according to the construction rules of BCFG. After that, the association between the BPEL workflow and WSDL is established. While constructing the BCFG model. According to the interface information contained in the interactive node, search in the corresponding WSDL document, enumerate the Service, Binding, Port, Operation, Parameter (service, binding, port, operation, parameter) defined in the WSDL document in turn, so as to determine the relationship between the path, the active node of the BCFG workflow and the interface.

[0057] Step S102: determining the feasibility of the BPEL activity path according to the activity constraint graph, and obtaining at least one test case from the solver;

[0058] In this step, a BPEL workflow can have multiple BPEL activity paths, each of which can be called a concurrent BPEL activity path. The number of test cases is the same as the number of feasible concurrent BPEL activity paths, which is at least one.

[0059] Step S103: Generate a program dependency graph of the BPEL workflow, and select a target test case to be run from at least one test case according to the program dependency graph;

[0060] In this step, a program dependency graph of the first BPEL workflow and the second BPEL workflow is first generated. Based on the program dependency graph, components in the second BPEL workflow that are affected by the first BPEL workflow are identified through a program slicing method. Target test cases to be run are selected based on the components affected by the first BPEL workflow.

[0061] In this embodiment, there can be many test cases, but for the BPEL to be tested, only a part of them corresponds to the parts before and after the program is modified, so it is necessary to find the target test cases corresponding to the parts before and after the modification to perform the test in order to obtain effective test results.<N,E> ,in:

[0062] N is a set of nodes. There is one entry node in N, and the other nodes represent activities.

[0063] E∈N×N is the set of directed edges, and the edge pointing from X to Y<X,Y> ∈E represents a control, data, or asynchronous call dependency between two activities represented by X and Y.

[0064] Step S104: determining the priority of the target test case corresponding to the BPEL activity according to the program dependency graph;

[0065] In this step, the modification impact of each BPEL activity is calculated according to the program dependency graph of the first BPEL workflow and the second BPEL workflow, and the priority of the corresponding target test case is determined according to the modification impact of the BPEL activity.

[0066] In the present embodiment, the modification impact of BPEL activities is used to measure the test importance of BPEL activities in BPEL workflow applications. In addition, in combination with the modification information (which can be calculated by comparing the difference before and after the update), we can derive the test importance of the target test case through its coverage information. At the same time, according to the test importance of the target test case, we sort the target test case in a specific order. For this reason, the BPEL dependencies between various activities should be analyzed first. In addition to control dependency, data dependency, and asynchronous call dependency, the present application proposes two other program dependencies: correlation dependency and synchronization dependency. Taking these dependencies into account, the BPEL activity dependency graph is used to quantitatively calculate the modification impact of each activity. Thus, the priority order of the corresponding target test case for each activity is determined.

[0067] Step S105: testing the target test case according to the priority of the target test case.

[0068] It can be seen that the BPEL workflow testing method of this embodiment first converts the BPEL workflow into an activity constraint graph, then determines the feasibility of the BPEL activity path based on the activity constraint graph and obtains the corresponding test case; then selects the target test case from the test case based on the generated program dependency graph and determines the priority of the target test; finally, tests the target test case according to the priority. The modeling, test case generation, test case selection and test case sorting of the BPEL workflow test are comprehensively considered, which plays a supporting role in the testing of the BPEL workflow and can improve the accuracy and efficiency of the test while ensuring the safety of the BPEL workflow test.

[0069] In some other embodiments, reference Figure 2 , the step S101 described in the above embodiment specifically includes:

[0070] S201, obtaining a first BPEL workflow and a second BPEL workflow, traversing the first BPEL workflow and the second BPEL workflow in a depth-first manner, and obtaining all BPEL activity nodes of the first BPEL workflow and the second BPEL workflow;

[0071] In this step, the BEPL activity node includes a root node and at least one child node. Each child node may also have its corresponding child node. For the root node in the BEPL activity node, its type needs to be set to domain. <scope>.

[0072] S202, according to the BEPL activity node type, selecting a parsing function corresponding to the BEPL activity node type to parse the activity attribute of the BEPL activity node;

[0073] In this step, the parsing functions can be divided into parsing functions of basic activities, parsing functions of selection / loop structure activities, and parsing functions of concurrent / sequential structure activities according to the activity types.

[0074] Among them, (1) the parsing function of the basic activity reads the activity attributes of the basic activity node from the BPEL workflow. The activity attributes include name, type, predecessor and successor relationship, input and output variables, partner link and port type. In the block structure, only the sequence <sequence>There is a predecessor-successor relationship between the activity nodes under the activity node. (2) The parsing function of the selection / loop structure activity reads the activity attributes of this type of activity node from the BPEL workflow, where the input variables are from the condition <condition>Parse it out and read the corresponding conditions <conditon>(3) The parsing function of concurrent / sequential structure activities reads the activity attributes of the activity nodes of concurrent mechanism activities or sequential structure activities from the BPEL workflow, and reads each of its child nodes.

[0075] S203, extracting and storing the common activity attributes of the BEPL activity nodes;

[0076] S204, storing activity attributes specific to the BEPL activity nodes respectively according to the BEPL activity node types;

[0077] In this embodiment, the common activity attributes and the unique activity attributes of the BEPL activity nodes are stored separately to prepare for the determination of dependency relationships when subsequently generating an activity constraint graph.

[0078] S205 . Generate control flow charts of the first BPEL workflow and the second BPEL workflow respectively according to the activity attributes of the BEPL activity nodes.

[0079] S206, traversing the first control flow graph and the second control flow graph, storing basic activity nodes and structured activity nodes other than the three types of sequential, concurrent and domain in the first control flow graph and the second control flow graph into an activity node set;

[0080] S207, traversing the activity node set, and in response to determining that a structured activity node exists, adding a control dependency relationship formed by the structured activity node and all child activity nodes of the structured activity node to a dependency relationship set;

[0081] S208, creating a common start activity node, making the activity node without control dependency dependent on the common start activity node, adding the control dependency relationship between the common start activity node and the activity node without control dependency to the dependency relationship set, and adding the common start activity node to the activity node set;

[0082] In this step, the control dependency relationship between the co-start activity node and the activity node without control dependency can be analyzed and determined by the following steps:

[0083] Traverse the set of active nodes to determine whether the input variable name of an acquired active node is the same as the output variable name of the predecessor active node of the active node. If they are the same, add this data dependency to the dependency set, then obtain the next active node, and find the data dependency between the active node and the previous active node; determine whether the acquired active node is a structured active node: ① If it is not a structured active node, obtain the predecessor activity of the active node according to the predecessor and successor relationship of the active node, and determine whether the output variable name of the active node is the same as that of its predecessor active node; ② If it is a structured active node, traverse the child active nodes of the structured active node, and determine whether the output variable names of all its child active nodes are the same as the input variable names of the active node. If they are the same, add all these data dependencies to the dependency set. If the active node has no data dependency with all the child active nodes of this structured active node, repeat the above determination until the data dependency of the active node or the top-level active node is found;

[0084] Determine whether the input variable name of the active node itself is equal to the output variable name. If so, add this data dependency to the dependency set;

[0085] If there is a BPEL workflow <while>or <repeatuntil>Loop through the activity nodes and determine whether the input variable name of such activity node is the same as the output variable name of the child activity node of the activity node. If so, add this data dependency to the dependency set. It is also necessary to determine whether there is an anti-data dependency between the child activity nodes of such activity node. If so, add this data dependency to the dependency set.

[0086] S209, finding data dependency relationships among all BPEL activity nodes according to the predecessor and successor relationships and input and output variables of the BPEL activity nodes, and adding the data dependency relationships to the dependency relationship set;

[0087] S210, in response to determining that the names of the partner links of the asynchronous active node and the receiving active node are the same as the names of the port types, there is an asynchronous call dependency relationship between the asynchronous active node and the receiving active node, and the dependency relationship is added to the dependency relationship set;

[0088] S211. Obtain the activity constraint graph according to the activity node set and the dependency relationship set.

[0089] In this embodiment, two BPEL workflows are taken as an example. It can be understood that in some other cases, it is also possible to process multiple BPEL workflows at the same time.

[0090] As can be seen from the above, this embodiment obtains two BPEL workflows and converts them into control flow graphs respectively. By analyzing the control flow graphs, the parts of the activity nodes with control dependencies are directly added to the dependency control set. For the activity nodes without dependency control, a common start activity node is created and depends on the common start activity node, and the activity node set and the corresponding dependency set of all nodes are obtained. Finally, the activity constraint graph is obtained according to the activity node set and the dependency set. This supports the modeling of BPEL workflows.

[0091] As an optional embodiment, refer to Figure 3 , for step S201 in the aforementioned embodiment, it may further include the following steps:

[0092] S301, obtaining a BEPL workflow source file, and finding the root node of the BEPL activity node in the BEPL workflow source file;

[0093] S302, selecting a corresponding interpreter according to the type of the root node, and interpreting the root node;

[0094] S303, obtaining the child nodes under the root node according to the interpretation result;

[0095] S304, selecting a corresponding interpreter according to the type of the sub-node, and interpreting the sub-node;

[0096] S305 , interpreting the child node as a new root node until all BEPL activity nodes of the BEPL workflow are obtained.

[0097] In this embodiment, the root node of the BEPL activity node is first found, and then the root node is used as the basis for interpretation by the interpreter; after the root node is interpreted, the child nodes under the root node are obtained according to the interpretation result for interpretation, and after the child node is selected and the corresponding interpreter is interpreted, the interpreted child nodes are used as the new root node, and the interpretation is repeated until all the BEPL activity nodes in the BEPL workflow source file are found.

[0098] In some other embodiments, step S102 described in the foregoing embodiment specifically includes:

[0099] The input first BPEL workflow is converted into a first control flow graph, and the second BPEL workflow is converted into a second control flow graph, and an activity constraint graph is generated according to the constraint relationship of the BPEL activity nodes between the first control flow graph and the second control flow graph.

[0100] In this embodiment, first, according to the concurrent BPEL activity path coverage criterion (the test set T satisfies the concurrent BPEL activity path coverage criterion of BCFG if and only if for each feasible concurrent BPEL activity path ∈ BCFG, there is at least one test case t∈T that executes it), the activity constraint graph generated from the BPEL workflow under test is decomposed into test paths. Then, each concurrent BPEL activity path is symbolically encoded with several constraints. The symbolic encoding includes not only the constraints of traditional multi-threaded programs (paths, program order, and read-write constraints), but also the constraints of the unique characteristics of BPEL workflow applications (synchronization and message constraints). With the help of the solver, the feasibility of the concurrent BPEL activity path can be quickly determined. If the concurrent BPEL activity path is not feasible, the present application directly abandons testing this path. Otherwise, a valid test case is obtained from the solver (a test case includes a feasible concurrent BPEL activity path and a SOAP message sequence).

[0101] In some embodiments, the solver may be a SMT solver.

[0102] In some other embodiments, the program dependency graph described in the foregoing embodiments is determined based on control dependency, data dependency, asynchronous call dependency, correlation dependency and synchronization dependency, wherein:

[0103] The related dependency means that the second activity is related to the first activity if and only if the first activity and the second activity in the program dependency graph are both receiving activities in the BPEL workflow, and the value of the attribute feature of the first activity is a positive value;

[0104] A synchronous dependency means that the second activity synchronously depends on the first activity if and only if the first activity and the second activity in the program dependency graph are both included in the flow activity and the second activity is the target of a link with the first activity as the source.

[0105] As an example, Ai and Aj are activities corresponding to two activity nodes in the program dependency graph. The related dependency means that activity Aj is relatedly dependent on activity Ai if and only if Ai and Aj are receiving activities in the BPEL workflow that share common properties, and Ai is a start activity whose createInstance attribute (attribute characteristic) has a value of "yes" (positive value).

[0106] Synchronous dependency means that if and only if Ai and Aj are both included in <flow>In the activity and activity Aj has activity Ai as its source <link> When the target is reached, activity Aj is synchronously dependent on activity Ai.

[0107] The following is a specific application scenario. In the development process of a system based on BPEL workflow, some development errors are always inevitably introduced. According to the idea of ​​mutation testing, this application divides the errors in the BPEL workflow sequence into three categories, namely BPEL, WSDL and XPath. The errors in BPEL are mainly some logical errors or some spelling errors related to the execution results. The errors in WSDL are mainly incorrect types, messages, port types and bindings. XPath errors are incorrect uses of XPath expressions, such as extracting wrong content or failing to extract any content.

[0108] The system requires (1) accuracy of test cases. Each test case should find as many errors as possible, and the number of invalid instances generated when using the test case should be reduced as much as possible, preferably zero, so as to reduce the burden on the test server and improve test efficiency.

[0109] (2) Timeliness of testing. When the requirements or environment change, the BPEL workflow will re-combine services to meet the new requirements and environmental changes. Due to the particularity of defense projects, regression testing is required to reduce the time as much as possible and improve testing efficiency.

[0110] Therefore, the system is tested by the method of the aforementioned embodiment of the present application. First, the test cases for effectively testing the BPEL workflow application are generated by the method of the aforementioned embodiment of the present application. Based on the concurrent BPEL activity path coverage criterion, the BPEL workflow application is decomposed into test paths that meet the coverage criterion. Taking into account the association mechanism of DPE semantics and BPEL, each test path is symbolically encoded by the five constraints of the aforementioned embodiment. With the help of the SMT solver, these constraints are solved, and target test cases for effectively testing the BPEL workflow application are obtained. These target test cases can avoid establishing invalid instances, thereby reducing the overhead of the test server.

[0111] In some usage scenarios, when the BPEL workflow recomposes services to meet demand or environmental changes, some unnecessary test case reruns can be eliminated by selecting a target test case to run from at least one test case according to the program dependency graph, thereby improving test efficiency.

[0112] In some usage scenarios, in order to further improve the test efficiency, target test case priority sorting can also be used.

[0113] As a specific example, taking the BPEL workflow of applying for food and fuel support for ships as an example, a specific solution is given in combination with the application embodiment. For intuitive expression, this application uses UML activity diagrams that construct BPEL code (in XML format) to describe these BPEL workflow applications. Figure 4 , describes the ship support application BPEL workflow application. In each activity diagram, a node represents a BPEL activity and an edge represents a transition between two activities.

[0114] In addition, the extracted application information is also used in this embodiment to annotate nodes, such as the input and output parameters of the activity or any XPath Query used by the activities in this BPEL workflow application. In addition, the nodes are numbered A1, A2, ..., A10 in this embodiment. The following is a detailed description of the ship support application BPEL workflow. When receiving ordering information from the client through activities A1 and A2, the ship support application BPEL workflow application simultaneously calls the water and electricity reserve query service and the food reserve query service to query the reserves of water, electricity and food (activities A4 and A5). If the reserves of water, electricity and food are greater than or equal to the customer's input reserves (verified by activity A6), the application will execute activities A7 and A8 to provide water, electricity and food for the ship. Otherwise, this workflow application will call the service RecordService to record failed support information about the client.

[0115] To ensure that no invalid test cases are generated in this BPEL workflow and that the generated test cases can effectively test this workflow, the workflow is first decomposed into concurrent BPEL activity paths. Then, on this basis, constraint modeling is performed on each potential feasible path to determine whether the path is a feasible path. If feasible, a test case for the path is given.

[0116] This workflow can be broken down into two paths, see Figure 5 , 6 , each path is decomposed according to the predicate, Figure 4 The BPEL workflow has only one predicate, so it can only be decomposed into two paths. The BPEL workflow also has a concurrent activity. <link> , all activities in this concurrent activity participate in the execution of each path, and the execution order has no effect on the result.

[0117] The two potential feasible paths are respectively subjected to constraint modeling (path constraints, program order constraints, read-write constraints, synchronization constraints, and message constraints). With the help of the SMT solver Yices, this embodiment can obtain message sequences, for example, water and electricity supply application = "100, 100", food supply application = "200", water and electricity reserves = "500, 500", food reserves = "400", water and electricity supply = "ok", food supply = "ok" and water and electricity supply application = "600, 600", food supply application = "700", water and electricity reserves = "500, 500", food reserves = "400", record = "ok" to effectively test the two potential feasible paths respectively.

[0118] During the use of this BPEL workflow, the programmer made some corrections. Figure 7 , 8a , 8b, it is necessary to quickly test these new BPEL workflows to ensure that the modifications will not cause errors. To this end, first, convert the BPEL workflow and its modified version into their BPEL general form. Through observation, it is found that the BPEL general form of the two BPEL workflows is just to convert Figure 7 The synchronous call in (activity A9) is decomposed into Figure 4 The asynchronous call in (activities A9 and A10). Then, the allowed control set is selected, and the allowed control sets of the two are the same. Finally, the BPEL program dependency graph is established for the two BPEL general forms. The program slicing algorithm shows that the program dependency graphs of the two are isomorphic. Therefore, the modified version of the ship support BPEL workflow is correct and can be used directly without testing, which greatly saves testing time and improves testing efficiency.

[0119] In order to improve the test efficiency more quickly, assume that activities A7 and A9 are modified for the ship support BPEL workflow. First, establish the activity dependency graph of the ship support BPEL workflow, modifiedSet(V2-V1)={A7, A9}. In addition, TIA(A7)=1, TIA(A9)=2. In this embodiment, assume that the corresponding test cases of tests A7 and A9 are t1 and t2, respectively. Therefore, TITC(t1)=1, TITC(t2)=2. Therefore, test case t2 should be rerun first. Thus, the test efficiency can be improved by sorting the test cases.

[0120] It should be noted that the method of the embodiment of the present application can be performed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only perform one or more steps in the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the described method.

[0121] It should be noted that the above describes some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the above embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0122] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a BPEL workflow testing device.

[0123] refer to Fig. 9 , the BPEL workflow testing device comprises:

[0124] The modeling module 901 is configured to input a BPEL workflow and convert the input BPEL workflow into an activity constraint graph;

[0125] An acquisition module 902 is configured to determine the feasibility of the BPEL activity path according to the activity constraint graph and acquire at least one test case from the solver;

[0126] A selection module 903 is configured to generate a program dependency graph of the BPEL workflow, and select a target test case to be run from at least one test case according to the program dependency graph;

[0127] A sorting module 904 is configured to determine the priority of the target test case corresponding to the BPEL activity according to the program dependency graph;

[0128] The testing module 905 is configured to test the target test case according to the priority of the target test case.

[0129] As an optional embodiment, the modeling module 901 is further used for:

[0130] The input first BPEL workflow is converted into a first control flow graph, and the second BPEL workflow is converted into a second control flow graph, and an activity constraint graph is generated according to the constraint relationship of the BPEL activity nodes between the first control flow graph and the second control flow graph.

[0131] As an optional embodiment, the acquisition module 902 is further configured to:

[0132] The activity constraint graph is decomposed into multiple BPEL activity paths, and the multiple BPEL activity paths are respectively symbolically encoded, the feasibility of the multiple BPEL activity paths is determined according to the symbolic encoding, and the test cases corresponding to the feasible BPEL activity paths among the multiple BPEL activity paths are obtained from the solver.

[0133] As an optional embodiment, the acquisition module 902 symbolically encodes multiple BPEL activity paths through path constraints, program sequence constraints, read-write constraints, synchronization constraints, and message constraints.

[0134] As an optional embodiment, the selection module 903 is further used for:

[0135] Generate a program dependency graph of the first BPEL workflow and the second BPEL workflow, identify components in the second BPEL workflow that are affected by the first BPEL workflow through a program slicing method based on the program dependency graph, and select target test cases to run based on the components affected by the first BPEL workflow.

[0136] As an optional embodiment, the program dependency graph in the selection module 903 is determined according to control dependency, data dependency, asynchronous call dependency, correlation dependency and synchronization dependency, wherein:

[0137] A related dependency means that activity Aj is related to activity Ai if and only if both Ai and Aj are receiving activities in the BPEL workflow that share common properties and Ai is a start activity with the createInstance attribute value set to "yes"; a synchronous dependency means that both Ai and Aj are included in <flow>In the activity and activity Aj has activity Ai as its source <link> When the target is reached, activity Aj is synchronously dependent on activity Ai.

[0138] As an optional embodiment, the sorting module 904 is further configured to:

[0139] The modification impact of each BPEL activity is calculated according to the program dependency graph of the first BPEL workflow and the second BPEL workflow, and the priority of the corresponding test case is determined according to the modification impact of the BPEL activity.

[0140] For the convenience of description, the above device is described in terms of functions divided into various modules. Of course, when implementing the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0141] The apparatus of the above embodiment is used to implement the corresponding BPEL workflow testing method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0142] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the BPEL workflow testing method described in any of the above embodiments is implemented.

[0143] Fig.10 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and the device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other through the bus 1050 in the device.

[0144] The processor 1010 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0145] The memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0146] The input / output interface 1030 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0147] The communication interface 1040 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through a wired mode (such as USB, network cable, etc.) or a wireless mode (such as mobile network, WIFI, Bluetooth, etc.).

[0148] The bus 1050 includes a path that transmits information between the various components of the device (eg, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

[0149] It should be noted that, although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040 and the bus 1050, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

[0150] The electronic device of the above embodiment is used to implement the corresponding BPEL workflow testing method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0151] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the BPEL workflow testing method described in any of the above embodiments.

[0152] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0153] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the BPEL workflow testing method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0154] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0155] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present application difficult to understand, the known power supply / ground connection with the integrated circuit (IC) chip and other components may or may not be shown in the provided drawings. In addition, the device can be shown in the form of a block diagram to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform to be implemented in the embodiments of the present application (that is, these details should be fully within the scope of understanding of those skilled in the art). In the case of elaborating specific details (e.g., circuits) to describe exemplary embodiments of the present application, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details or when these specific details are changed. Therefore, these descriptions should be considered to be illustrative rather than restrictive.

[0156] Although the present application has been described in conjunction with specific embodiments of the present application, many replacements, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

[0157] The embodiments of the present application are intended to cover all such substitutions, modifications and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the scope of protection of the present application.< / flow> < / flow> < / repeatuntil> < / while> < / conditon> < / condition> < / sequence> < / scope>

Claims

1. A BPEL workflow testing method, characterized in that: include: Input BPEL workflow and convert the input BPEL workflow into activity constraint graph; The step of converting the input BPEL workflow into an activity constraint graph comprises: converting the input first BPEL workflow into a first control flow graph, converting the second BPEL workflow into a second control flow graph, and generating an activity constraint graph according to the constraint relationship between the BPEL activity nodes of the first control flow graph and the second control flow graph; Determining the feasibility of the BPEL activity path according to the activity constraint graph, and obtaining at least one test case from the solver; Generate a program dependency graph of the BPEL workflow, and select a target test case to run from at least one test case according to the program dependency graph; The generating of a program dependency graph of the BPEL workflow and selecting a target test case to be run from at least one test case according to the program dependency graph comprises: generating a program dependency graph of a first BPEL workflow and a second BPEL workflow, identifying components in the second BPEL workflow affected by the first BPEL workflow by a program slicing method according to the program dependency graph, and selecting a target test case to be run according to the components affected by the first BPEL workflow; Determining the priority of target test cases corresponding to the BPEL activity according to the program dependency graph; The target test case is tested according to the priority of the target test case.

2. The method according to claim 1, characterized in that: Determining the feasibility of the BPEL activity path according to the activity constraint graph and obtaining at least one test case from the solver includes: The activity constraint graph is decomposed into multiple BPEL activity paths, and the multiple BPEL activity paths are respectively symbolically encoded, the feasibility of the multiple BPEL activity paths is determined according to the symbolic encoding, and the test cases corresponding to the feasible BPEL activity paths among the multiple BPEL activity paths are obtained from the solver.

3. The method according to claim 2, characterized in that The multiple BPEL activity paths are symbolically encoded by path constraints, program order constraints, read-write constraints, synchronization constraints and message constraints.

4. The method according to claim 1, characterized in that: The program dependency graph is determined based on control dependency, data dependency, asynchronous call dependency, correlation dependency and synchronization dependency, wherein: The related dependency indicates that the second activity is related to the first activity if and only if the first activity and the second activity in the program dependency graph are both receiving activities in the BPEL workflow, and the value of the attribute feature of the first activity is a positive value; The synchronous dependency indicates that the second activity is synchronously dependent on the first activity if and only if the first activity and the second activity in the program dependency graph are both included in the flow activity and the second activity is the target of a link with the first activity as the source.

5. The method according to claim 2, characterized in that: Determining the priority of the target test case corresponding to the BPEL activity according to the program dependency graph includes: The modification impact of each BPEL activity is calculated according to the program dependency graph of the first BPEL workflow and the second BPEL workflow, and the priority of the corresponding test case is determined according to the modification impact of the BPEL activity.

6. A BPEL workflow testing device, characterized in that: include: A modeling module, configured to input a BPEL workflow and convert the input BPEL workflow into an activity constraint graph; The modeling module is further configured to convert the input first BPEL workflow into a first control flow graph, convert the second BPEL workflow into a second control flow graph, and generate an activity constraint graph according to the constraint relationship between the BPEL activity nodes between the first control flow graph and the second control flow graph; an acquisition module, configured to determine the feasibility of the BPEL activity path according to the activity constraint graph, and acquire at least one test case from the solver; A selection module is configured to generate a program dependency graph of the BPEL workflow, and select a target test case to be run from at least one test case according to the program dependency graph; The selection module is further configured to generate a program dependency graph of the first BPEL workflow and the second BPEL workflow, identify components in the second BPEL workflow that are affected by the first BPEL workflow by a program slicing method according to the program dependency graph, and select a target test case to be run according to the components that are affected by the first BPEL workflow; A sorting module, configured to determine the priority of the target test cases corresponding to the BPEL activities according to the program dependency graph; The testing module is configured to test the target test case according to the priority of the target test case.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 5 when executing the program.

8. A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the method according to any one of claims 1 to 5.

Images