Sequence diagram-based test scenario generation method and related apparatus

Abstract

Embodiments of the present application disclose a sequence diagram-based test scenario generation method, device, equipment, medium and product. The method comprises: acquiring a design sequence diagram and a preset sequence diagram standard. The design sequence diagram comprises interactive elements for describing message passing and control flow between objects. The sequence diagram standard is used for describing rules and requirements for drawing a sequence diagram. Element relationship extraction is performed on the design sequence diagram according to the sequence diagram standard, to obtain mutual relationships between interactive elements in the design sequence diagram. An interactive directed graph for describing interactive element flow is constructed according to the mutual relationships. Each operation path described by the design sequence diagram is extracted from the interactive directed graph, and a target test scenario corresponding to the design sequence diagram is generated according to each operation path. The technical solution of the embodiments of the present application realizes standardization and automation of test scenario generation, guarantees coverage and accuracy of the test scenario, and reduces dependence on experience of test personnel.

Description

Technical Field

[0001] This application relates to the field of test scenario generation technology, and more specifically, to a test scenario generation method based on sequence diagrams, a test case generation device based on sequence diagrams, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Currently, the test scenario generation method involves manually understanding and analyzing the existing software component code to understand its functional logic. Then, based on the developers' testing experience, test scenarios are designed to cover the key logic one by one, and each test scenario is recorded. This test scenario generation method heavily relies on the developers' understanding of the software component logic and their testing experience. It is difficult for a single person to think of all the key logic that needs to be covered for a software component, which can easily lead to omissions. Summary of the Invention

[0003] The embodiments of this application provide a test scenario generation method based on sequence diagrams, a test case generation device based on sequence diagrams, an electronic device, a computer-readable storage medium, and a computer program product, which realizes the standardization and automation of test scenario generation, reduces the dependence on the experience of testers, and avoids subjective bias in the manual generation process.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a test scenario generation method based on sequence diagrams is provided, comprising: acquiring a design sequence diagram and a preset sequence diagram standard, wherein the design sequence diagram includes interactive elements for describing message passing and control flow between objects, and the sequence diagram standard is used to describe the rules and requirements for drawing sequence diagrams; extracting element relationships from the design sequence diagram according to the sequence diagram standard to obtain the mutual relationships between the interactive elements in the design sequence diagram; constructing an interaction directed graph corresponding to the design sequence diagram for describing the flow of the interactive elements according to the mutual relationships; extracting each operation path described by the design sequence diagram from the interaction directed graph, and generating a target test scenario corresponding to the design sequence diagram according to each operation path.

[0006] According to one aspect of the embodiments of this application, a test scenario generation apparatus based on sequence diagrams is provided. The apparatus includes: an acquisition module, configured to acquire a design sequence diagram and a preset sequence diagram standard, wherein the design sequence diagram includes interactive elements for describing message passing and control flow between objects, and the sequence diagram standard is used to describe the rules and requirements for drawing sequence diagrams; an extraction module, configured to extract element relationships from the design sequence diagram according to the sequence diagram standard to obtain the mutual relationships between the interactive elements in the design sequence diagram; a construction module, configured to construct an interactive directed graph corresponding to the design sequence diagram for describing the flow of the interactive elements according to the mutual relationships; and a generation module, configured to extract each operation path described by the design sequence diagram from the interactive directed graph, and generate a target test scenario corresponding to the design sequence diagram according to each operation path.

[0007] In one embodiment of this application, the interaction elements include messages and branches; the extraction module is further used to extract lifelines, messages, and branch segments describing branches from the design sequence diagram; to detect the lifelines, messages, and branch segments according to the sequence diagram standard to obtain detection results; and to extract element relationships from the design sequence diagram based on the detection results to obtain the relationships between messages and between branches in the design sequence diagram.

[0008] In one embodiment of this application, the extraction module is further configured to: detect whether the abstraction levels of each lifeline are consistent according to the lifeline drawing standard; detect whether the arrow of each message corresponds to the lifeline body according to the message drawing standard; and verify whether each message is normal according to the arrow and message description of each message; match the fragment symbols in the branch fragment drawing standard with the fragment symbols of each branch fragment in the design sequence diagram to determine the branch type described by each branch fragment; obtain the branch attributes of the corresponding branch according to the branch type; and verify whether the branch is normal according to the branch attributes and the messages within the branch.

[0009] In one embodiment of this application, the extraction module is further configured to verify that the target class message is drawn normally if the message description of the target class message includes a message jump target and the endpoint lifeline corresponding to the arrow of the target class message is the starting lifeline of the message jump target; and to verify that the target class message is drawn normally if the message description of the target class message includes a preset message end description and the endpoint lifeline corresponding to the arrow of the target class message is the same as the starting lifeline.

[0010] In one embodiment of this application, the extraction module is further configured to: if the branch type is a selective logical branch including a branch description, extract the branch conditions for entering the logical branch from the branch description of the logical branch to obtain the branch attributes of the logical branch; if the branch type is an optional branch, extract the guard conditions for entering the optional branch from the unique fragment description of the branch segment to obtain the branch attributes of the optional branch; if the branch type is a cyclic branch, extract the cyclic meaning of the cyclic branch from the unique fragment description of the branch segment, and determine the exit condition from the cyclic branch based on the optional branches included in the cyclic branch to obtain the branch attributes of the cyclic branch.

[0011] In one embodiment of this application, the extraction module is further configured to identify the message type of each message in the design sequence diagram, and determine the triggering order of each message in the design sequence diagram according to the timeline of the design sequence diagram; determine the relative order between the messages based on the triggering order and the message type of each message; identify the branch type and the position of each branch in the design sequence diagram, and obtain the message flow order within each branch based on the branch type; and determine the interrelationship between the branches based on the branch type, the position of each branch in the design sequence diagram, and the message flow order within each branch.

[0012] In one embodiment of this application, the interaction elements include messages and branches, and the construction module is further configured to treat each message and branch in the design sequence diagram as nodes; determine the parent node, child node, and sibling node of the node, as well as the order relationship between the nodes, according to the mutual relationship; treat the order relationship between the nodes as edges, and construct the interaction directed graph according to each node and the edges.

[0013] In one embodiment of this application, the directed interactive graph further includes a starting node; the generation module is further configured to obtain a business target node and at least two key edges in the directed interactive graph; and determine at least two operation paths based on the path formed by the starting node, the at least two key edges, and the business target node, wherein the operation paths are used to describe a deterministic interaction sequence between objects.

[0014] In one embodiment of this application, the generation module is further configured to, for each key edge, find the first shortest path from the starting node to the key edge, and find whether there is a path from the key edge to the business target node, and obtain the search result; and generate the operation path corresponding to the key edge based on the first shortest path and the search result.

[0015] In one embodiment of this application, the interactive directed graph further includes an end node; the generation module is further configured to: if the search result indicates the existence of a second shortest sub-path from the key edge to the business target node, then search for a third sub-path from the business target node to the end node, and merge the first sub-path, the second sub-path, and the third sub-path to obtain the operation path; if the search result indicates the absence of a path from the key edge to the business target node, then search for a second shortest path from the key edge to the end node, and merge the first shortest path and the second shortest path to obtain the operation path.

[0016] In one embodiment of this application, the apparatus further includes a marking module, configured to obtain the main business process corresponding to the design sequence diagram; identify the message content in the design sequence diagram to determine the target message and target branch with the function name or business description corresponding to the main business process; and mark the target message and the target branch as the target business node in the interactive directed graph.

[0017] In one embodiment of this application, the test scenario includes various test scenarios generated corresponding to each operation path. The generation module is further used to perform feature extraction processing on the message content in the design sequence diagram to obtain at least two message features; perform message classification processing on the at least two message features to obtain corpus classification information of the message content, and perform conflict detection processing on the at least two message features to obtain conflict corpus information; and filter the various test scenarios according to the corpus classification information and the conflict corpus information to obtain the target test scenario.

[0018] In one embodiment of this application, the generation module is further configured to obtain the business logic corresponding to the target test scenario, construct the necessary steps required to generate the test case based on the business logic, obtain the preconditions and expected results required for the test case, and generate the test case corresponding to the design sequence diagram based on the preconditions, the expected results and the necessary steps.

[0019] According to one aspect of the embodiments of this application, an electronic device is provided, including a storage device and a processor; the storage device is used to store one or at least two programs, which, when executed by one or at least two of the processors, cause the electronic device to implement the sequence diagram-based test scenario generation method as described above.

[0020] According to one aspect of the embodiments of this application, the embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor of an electronic device, causes the electronic device to perform the test scenario generation method based on sequence diagrams as described above.

[0021] According to one aspect of the embodiments of this application, this application provides a computer program product, including a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the sequence diagram-based test scenario generation method as described above.

[0022] In the technical solution provided by the embodiments of this application, a design sequence diagram and a preset sequence diagram standard are obtained. The design sequence diagram includes interactive elements used to describe message passing and control flow between objects, and the sequence diagram standard is used to describe the rules and requirements for drawing the sequence diagram. The element relationships of the design sequence diagram are extracted according to the sequence diagram standard to obtain the mutual relationships between interactive elements in the design sequence diagram. The mutual relationships of interactive elements are automatically parsed and analyzed through the sequence diagram standard. Then, an interactive directed graph corresponding to the design sequence diagram is constructed based on the mutual relationships to describe the flow of interactive elements. The interactive directed graph completely expresses the interactive process in the design sequence diagram. The interactive directed graph can be used to globally analyze and cover the interactive logic in the design sequence diagram. Each operation path described by the design sequence diagram is extracted from the interactive directed graph, so that the test coverage is accurate to each operation path. Then, the target test scenario corresponding to the design sequence diagram is automatically generated according to each operation path, realizing the standardization and automation of test scenario generation, ensuring the coverage and accuracy of test scenarios, reducing the dependence on the experience of testers, and avoiding subjective bias in the manual generation process.

[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0025] Figure 1 This is a schematic diagram of one implementation environment involved in this application;

[0026] Figure 2This is a flowchart illustrating an exemplary embodiment of the present application of a test scenario generation method based on sequence diagrams;

[0027] Figure 3 This is a schematic diagram illustrating a design sequence diagram as shown in an exemplary embodiment of this application;

[0028] Figure 4 This is a schematic diagram of the interface of the editing design sequence diagram shown in an exemplary embodiment of this application;

[0029] Figure 5 This is a flowchart illustrating another test scenario generation method based on sequence diagrams, as shown in an exemplary embodiment of this application.

[0030] Figure 6 This is a schematic diagram illustrating a jump-type message as an exemplary embodiment of this application;

[0031] Figure 7 This is a schematic diagram illustrating another type of jump message, as shown in an exemplary embodiment of this application;

[0032] Figure 8 This is a schematic diagram illustrating an end-of-life message as an exemplary embodiment of this application;

[0033] Figure 9 This is a schematic diagram illustrating a logical branch in an exemplary embodiment of this application;

[0034] Figure 10 This is a schematic diagram illustrating an optional branch in an exemplary embodiment of this application;

[0035] Figure 11 This is a schematic diagram illustrating a loop branch in an exemplary embodiment of this application;

[0036] Figure 12 This is a schematic diagram illustrating an abnormal branch in an exemplary embodiment of this application;

[0037] Figure 13 This is a flowchart illustrating an exemplary embodiment of the present application of a test scenario generation method based on sequence diagrams;

[0038] Figure 14 This is a flowchart illustrating a test scenario generation method based on sequence diagrams, as shown in another exemplary embodiment of this application.

[0039] Figure 15 This is a schematic diagram illustrating an interactive directed graph, as shown in another exemplary embodiment of this application;

[0040] Figure 16 This is a flowchart illustrating a test scenario generation method based on sequence diagrams, as shown in another exemplary embodiment of this application;

[0041] Figure 17 This is a flowchart illustrating a test scenario generation method based on sequence diagrams, as shown in another exemplary embodiment of this application;

[0042] Figure 18 This is a schematic diagram illustrating a test scenario generation system as shown in an exemplary embodiment of this application;

[0043] Figure 19 This is a flowchart illustrating a test scenario generation method based on sequence diagrams, as shown in another exemplary embodiment of this application;

[0044] Figure 20 This is a structural block diagram of a sequence diagram-based test scene generation apparatus, as illustrated in an exemplary embodiment of this application.

[0045] Figure 21 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0047] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or at least two hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0048] The flowcharts shown in the accompanying diagrams are merely illustrative and do not necessarily include all content and operations, nor do they necessarily have to be executed in the described order. For example, some operations may be broken down, while others may be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0049] It should also be noted that "at least two" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0050] Please see Figure 1 , Figure 1 This is a schematic diagram of an implementation environment related to this application. The implementation environment includes a terminal 10 and a server 20.

[0051] Terminal 10 is used to obtain the design sequence diagram of the target object input. The terminal can send the design sequence diagram to the server, wherein the design sequence diagram includes interactive elements for describing message passing and control flow between objects.

[0052] Server 20 is used to obtain a preset sequence diagram standard, which describes the rules and requirements for drawing sequence diagrams. Then, according to the sequence diagram standard, the element relationships of the design sequence diagram are extracted to obtain the mutual relationships between interactive elements in the design sequence diagram. Based on the mutual relationships, an interactive directed graph corresponding to the design sequence diagram is constructed to describe the flow of interactive elements. Then, each operation path described by the design sequence diagram is extracted from the interactive directed graph, and the target test scenario corresponding to the design sequence diagram is generated based on each operation path.

[0053] The server 20 can send test scenarios to the terminal 10, and then the terminal 10 can generate test cases for the design sequence diagram based on the test scenarios. Alternatively, the server can generate test cases based on the test scenarios and then send the test cases to the terminal 10 for software testing.

[0054] In some embodiments, the terminal 10 can also implement the test case generation process independently. That is, the terminal 10 obtains the sequence diagram identifier, extracts the element relationship of the design sequence diagram according to the sequence diagram standard, obtains the mutual relationship between the interactive elements in the design sequence diagram, then constructs the interactive directed graph, and then generates the test scenario corresponding to the design sequence diagram.

[0055] The aforementioned terminal 10 can be any electronic device capable of drawing sequence diagrams, such as a smartphone, tablet, laptop, computer, smart voice interaction device, smart home appliance, vehicle terminal, or aircraft. The server 20 can be an independent physical server, a server cluster or distributed system consisting of at least two physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. This document does not impose any restrictions on these aspects.

[0056] In one example, the parameters involved in the server deployment environment are shown in Tables 1 and 2 below. Table 1 shows the hardware parameters of the deployment environment, and Table 2 shows the software parameters of the deployment environment.

[0057]

[0058]

[0059] Table 1

[0060]

[0061] Table 2

[0062] Terminal 10 and server 20 establish a communication connection via a network beforehand, enabling them to communicate with each other. The network can be a wired network or a wireless network, and this is not a limitation.

[0063] It should be noted that in the specific embodiments of this application, the sequence diagrams involve objects. When the embodiments of this application are applied to specific products or technologies, permission or consent from the objects is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0064] The following details the various implementation details of the technical solutions in the embodiments of this application:

[0065] like Figure 2 As shown, Figure 2 This is a flowchart illustrating a sequence diagram-based test scenario generation method according to an embodiment of this application. This method can be applied to... Figure 1 In the implementation environment shown, the method can be executed by a terminal or a server, or by both a terminal and a server. In this embodiment, the method is described using the server as an example. The test scenario generation method based on sequence diagrams can include steps S210 to S240, which are detailed below:

[0066] S210. Obtain the design sequence diagram and the preset sequence diagram standard. The design sequence diagram includes interactive elements used to describe message passing and control flow between objects. The sequence diagram standard is used to describe the rules and requirements for drawing sequence diagrams.

[0067] In this application embodiment, a sequence diagram is a Unified Modeling Language (UML) interaction diagram that shows the dynamic collaboration between at least two objects by describing the temporal order in which messages are sent between them. Designing a sequence diagram is the implementation of system use cases. It refers to a sequence diagram drawn during the software design process to demonstrate the interactive behavior between system objects, illustrating how a specific system works to complete the interaction, and describing the collaborative process of components of a specified technology platform. In order to describe the interaction between objects, the design sequence diagram includes interactive elements for describing message passing and control flow between objects.

[0068] In one example, the interaction elements include messages and branches. Messages are a way of representing communication between objects, which are arranged sequentially on lifelines. Branches show at least two messages originating from the same point and pointing to different objects or different lifelines of the same object. They are an important representation of control flow in sequence diagrams.

[0069] In this context, objects can be drawn into design sequence diagrams according to the implementation logic of software components in the sequence diagram drawing interface, following the UML standard. UML is a standardized language for visual modeling of software systems; it defines a set of graphical symbols and rules that clearly describe the structure, behavior, and interactions of a software system. For example... Figure 3 As shown, this is a design sequence diagram of the payment login process provided in an embodiment of this application; in the sequence diagram drawing interface, objects can perform editing functions such as searching, modifying, deleting, and authorizing on the design sequence diagram, such as... Figure 4 As shown, in Figure 3 Based on the design sequence diagram shown, the message information of "1.4 Start the network process" is edited.

[0070] Standard UML sequence diagrams are not specifically designed for generating test scenarios. Some key information for generating test scenarios is either not indicated in the sequence diagram or is not standardized. Therefore, the sequence diagram standard preset in this application is a standard set up to enable the programmatic generation of test scenarios based on the design sequence diagram. Unlike the UML standard, which describes the rules and requirements for drawing sequence diagrams, the role of the sequence diagram standard is to uniformly define the meaning and format of each interaction element to ensure that the design sequence diagram can meet the needs of automated parsing.

[0071] S220. Extract the element relationships from the design sequence diagram according to the sequence diagram standard to obtain the mutual relationships between interactive elements in the design sequence diagram.

[0072] As described above, the sequence diagram standard ensures that the element definitions and structures in the design sequence diagram meet a unified format, facilitating automated parsing and analysis. The sequence diagram standard parses and identifies each interaction element in the design sequence diagram, and extracts the relationships between interaction elements according to the standard. These relationships include the execution order, dependency, and mutual exclusion relationships between interaction elements. The extracted element relationships can then be integrated to obtain the mutual relationships between interaction elements in the design sequence diagram. These mutual relationships constitute the complete flow and logical relationships between the elements in the sequence diagram, guiding the generation of test scenarios.

[0073] In one example, a large AI model can be trained based on sequence graph standards and sample design sequence graphs. By inputting the designed sequence graphs into the large AI model, the relationships between interactive elements in the designed sequence graphs can be obtained.

[0074] S230. Construct an interaction-directed graph corresponding to the design sequence graph to describe the flow of interactive elements based on the mutual relationships.

[0075] In this embodiment, an interactive directed graph is used to describe the flow of interactive elements, and the flow of interactive elements has a direction. Interactive elements can be treated as nodes, and edges are constructed between nodes based on the relationships between interactive elements, thus obtaining the interactive directed graph. The structure of this interactive directed graph should cover all interactive elements and their logical relationships to ensure that the graph can completely express the interactive flow in the design sequence diagram.

[0076] In one example, to ensure the integrity of the interactive directed graph, the interactive directed graph also includes the graph start node S and the graph end node E.

[0077] S240. Extract each operation path described by the design sequence diagram from the interaction directed graph, and generate the target test scenario corresponding to the design sequence diagram based on each operation path.

[0078] Interaction directed graphs can fully express the steps involved in constructing a series of interaction elements between objects in a design sequence diagram. These steps, combined in a certain order, generate an operation path.

[0079] In this embodiment of the application, the interactive directed graph can be traversed to obtain each operation path described by the design sequence graph, each test scenario can be generated through each operation path, and then the target test scenario can be obtained by combining and filtering each test scenario, and then test cases can be generated based on the target test scenario.

[0080] In this embodiment of the application, there are at least two operation paths, and at least two corresponding test scenarios. To ensure the sequential execution of subsequent test cases, target test scenarios corresponding to the design sequence diagram are generated based on each operation path, including:

[0081] Feature extraction is performed on the message content in the design sequence diagram to obtain at least two message features; message classification is performed on the at least two message features to obtain corpus classification information of the message content; conflict detection is performed on the at least two message features to obtain conflict corpus information; and at least two test scenarios are selected based on the corpus classification information and conflict corpus information to obtain the target test scenario.

[0082] In this embodiment of the application, key information such as message type, keywords, data parameters, message length, and context is obtained from each message content through feature extraction technology, resulting in at least two message features, such as semantic features, context features, and type features.

[0083] In this embodiment, corpus classification information refers to the category information to which each message belongs after classification, such as "identity verification," "payment processing," and "error handling." Based on the extracted message features, the message content is divided into different corpus categories, which facilitates understanding the business meaning and operational logic of the messages. Classification rules (such as keywords or specific semantic tags) can be set to initially divide the message content; for example, messages containing the keywords "login" and "verification" can be classified into the "identity verification" category. Alternatively, text classification algorithms (such as Support Vector Machine (SVM), Naive Bayes classification, etc.) can be used to automatically classify messages, automatically identifying each category of messages through model training, thereby obtaining corpus classification information.

[0084] It is understandable that different message types or contents may have logical conflicts. The purpose of conflict detection is to identify and avoid these potential problems. Conflict types include semantic conflicts where two messages are semantically incompatible, data conflicts where two messages operate on the same data resource (such as inventory or balance) and the operations are inconsistent, and sequence conflicts. Logical analysis of message content is performed based on corpus classification information and features to find potential conflict points and generate conflict corpus information.

[0085] In this embodiment, based on corpus classification information and conflicting corpus information, target test scenarios that best match business logic and testing requirements are selected from at least two test scenarios. For example, test scenarios containing specific categories of corpus are selected, such as verifying whether messages of the "identity verification" and "payment processing" categories are executed according to the correct process. Scenarios containing conflicting messages are eliminated to avoid logical contradictions. For example, if a scenario contains both "payment successful" and "payment failed," then that scenario is excluded. Alternatively, test scenarios of key message categories, such as payment and identity verification, can be selected based on business priority.

[0086] By following the steps above, test scenarios with real business value can be efficiently selected, ensuring test coverage while reducing unnecessary conflicts and redundancy, and improving the accuracy and logical consistency of tests.

[0087] In this embodiment, a design sequence diagram and a preset sequence diagram standard are obtained. The design sequence diagram includes interactive elements used to describe message passing and control flow between objects, and the sequence diagram standard describes the rules and requirements for drawing the sequence diagram. The element relationships in the design sequence diagram are extracted according to the sequence diagram standard to obtain the interrelationships between interactive elements. The sequence diagram standard enables the automated parsing and analysis of the interrelationships between interactive elements. Based on these interrelationships, an interactive directed graph corresponding to the design sequence diagram is constructed to describe the flow of interactive elements. This interactive directed graph fully expresses the interactive process in the design sequence diagram. The interactive directed graph allows for global analysis and coverage of the interactive logic in the design sequence diagram. Each operation path described in the design sequence diagram is extracted from the interactive directed graph, making test coverage precise down to each operation path. Then, the target test scenario corresponding to the design sequence diagram is automatically generated based on each operation path, achieving standardization and automation of test scenario generation. This ensures the coverage and accuracy of the test scenarios, reduces reliance on tester experience, and avoids subjective biases in the manual generation process.

[0088] In one embodiment of this application, another test scenario generation method based on sequence diagrams is provided, which can be applied to... Figure 1 The implementation environment shown is illustrated using the example of the method being executed by a server. Figure 5 As shown, this test scenario generation method based on sequence diagrams... Figure 2 Based on S210 to S240 shown, Figure 2 The S220 shown is extended to S510 to S530; the interaction elements include messages and branches; S510 to S530 are described in detail below:

[0089] S510. Extract the lifeline, message, and branch fragment used to describe the branch from the design sequence diagram.

[0090] In this embodiment, lifelines are used to represent the existence of objects in a sequence diagram over a period of time, and branch fragments are used to describe branches. Lifelines, messages, and branch fragments have different representations, such as... Figure 3 As shown, the lifeline is a vertical dashed line, and the branch segments are enclosed by a rectangle. Therefore, the lifeline, message, and branch segments can be extracted from the design sequence diagram based on their representation.

[0091] S520. Detection results are obtained by detecting lifelines, messages, and branch segments according to sequence diagram standards.

[0092] The sequence diagram standard uniformly defines the meaning and format of lifelines, messages, and branch segments. The meaning and format of lifelines, messages, and branch segments can be checked according to the sequence diagram standard to obtain the detection results of whether lifelines, messages, and branch segments conform to the sequence diagram standard.

[0093] In one example, sequence graph standards include lifeline drawing standards, message drawing standards, and branch segment drawing standards. The detection of lifelines, messages, and branch segments according to the sequence graph standards includes:

[0094] The system checks whether the abstraction levels of each lifeline are consistent according to the lifeline drawing standard; it checks whether the arrow of each message corresponds to the lifeline body according to the message drawing standard, and verifies whether each message is normal based on the arrow and message description; it matches the fragment symbols in the branch fragment drawing standard with the fragment symbols of each branch fragment in the design sequence diagram to determine the branch type described by each branch fragment; it obtains the branch attributes of the corresponding branch according to the branch type, and verifies whether the branch is normal based on the branch attributes and the messages within the branch.

[0095] The lifeline drawing standard requires that the abstraction level of lifelines be consistent. The abstraction level refers to the level or granularity of the object represented by the lifeline in the sequence diagram. For example, the abstraction level of the client part is a process. If the logic within a process is too complex, it can be broken down into xxx process: yyy module, such as... Figure 3 Each lifeline in the framework is abstracted at a level of process, with the main process being the UI module and the main process being the login module. The abstract layer of the backend consists of backend services or PaaS infrastructure components. Different system boundaries that communicate with a given system are represented by a lifeline, such as... Figure 3 The underlying infrastructure. Therefore, it checks whether the abstraction levels of each lifeline in the design sequence diagram are consistent. If the abstraction levels are consistent, the result is obtained as to whether the lifelines conform to the lifeline drawing standards.

[0096] The message drawing standard specifies that each message in the design sequence diagram has a unique, non-repeating number. It also requires that the arrow of each message correspond to the lifeline subject. Therefore, checking whether the arrow of each message corresponds to the lifeline subject is crucial. For example, for an interaction requiring passive object participation, a message needs to be drawn, and the arrow of that message must correspond to the lifeline subject "object." Furthermore, the standard specifies that different message arrows indicate different message types, and different message types correspond to different message descriptions. Therefore, based on the arrow and message description of each message, we can verify whether each message is drawn correctly, whether the meaning of each message matches the arrow and message description, and whether the message conforms to the second detection result of the message drawing standard. For example, if the message description is "requesting the object to do xx," but the arrow of the message does not point to the object, then the message drawing is abnormal.

[0097] In one example, when the message is a target class message, each message is verified to be normal based on the arrow and message description, including:

[0098] If the message description of the target message includes the message jump target, and the endpoint lifeline corresponding to the arrow of the target message is the starting lifeline of the message jump target, then the target message is drawn normally.

[0099] In a sequence diagram, if a process involves a jump, the message corresponding to that process is a target message, i.e., a jump message. To clarify the process corresponding to the target message, the message description of the target message must include the message jump target when drawing the target message. The message jump target is the destination to which the message needs to be adjusted, and the endpoint lifeline corresponding to the arrow of the target message is the starting point lifeline of the message jump target, so as to indicate that the target message jumps to the message jump target. The message jump target can be a message or a branch, and the message description includes the type identifier of the message jump target.

[0100] The message description for the target message is: Jump msg: ${target message number}, where $ indicates the message number, the target message number is the specific message number to which the message jumps, and this msg is a type identifier, such as... Figure 6 As shown, if the message description of target message 2.26 is: Jump to msg: 2.10, the target message number is 2.10, then jump to message 2.10, and the endpoint lifeline corresponding to the arrow of message 2.26 is the starting lifeline of 2.10, then it means that the meaning of message 2.26 matches the arrow and message description, and message 2.26 is normal.

[0101] The message description for a target message is: Jump fragment identifier: {fragment description}. If the fragment identifier is a logical branch (alt), the message description also includes {branch description}. The fragment description and branch description together constitute the message jump target. Figure 7 As shown, the target message 2.16 means to jump to a branch of the alt segment. The message description of message 2.16 is: Jump alt: {segment description}: {branch description}, where alt is the type identifier of the logical branch. For example, if the endpoint lifeline corresponding to the arrow in message 2.16 is the starting lifeline of the first message 2.17 corresponding to the branch description, it means to jump to message 2.17. The meaning of message 2.16 matches the arrow and message description, so message 2.16 is normal.

[0102] If the message description of the target message includes a preset message end description, and the endpoint lifeline and the starting lifeline corresponding to the arrow of the target message are consistent, then the target message is verified to be drawn normally.

[0103] In a sequence diagram, when a message interaction occurs and the process ends, this message is a target message, i.e., an ending message. A preset message ending description is used to indicate the end of the process. This preset message ending description includes a preset description format and description text. Furthermore, the endpoint lifeline corresponding to the arrow of the target message points to itself; that is, the endpoint lifeline and the starting lifeline are consistent, indicating that the target message is functioning correctly. For example... Figure 8 As shown, the message description of message 1.16 is: "[Process Ended]", where [] is the description format for end-of-process messages, and "Process Ended" is the description text. This indicates that the meaning of message 1.16 matches the arrow and message description, so message 1.16 is normal.

[0104] The branch segment drawing standard sets different meanings for different branch segments. Each branch segment has a segment symbol, and different segment symbols represent different branch types. Therefore, the segment symbols in the branch segment drawing standard can be matched with the segment symbols of each branch segment in the design sequence diagram to determine the branch type described by each branch segment. Based on the branch type, the branch attributes of the corresponding branch can be obtained, and the branch can be verified as normal based on the branch attributes and the messages within the branch.

[0105] Branch attributes are used to represent the unique characteristics of a branch, including branch conditions. For example, the branch attributes of a logical branch include the branch conditions for entering the branch; the branch attributes of a loop branch include the loop termination conditions. In this way, messages within a branch can be matched with branch attributes to determine whether the messages within the branch are associated with the branch attributes. If they are associated, it means that the branch is normal.

[0106] In one example, the branch attributes of the corresponding branch are retrieved based on the branch type, including:

[0107] If the branch type is a selective logical branch that includes a branch description, then the branch conditions for entering the logical branch are extracted from the branch description of the logical branch to obtain the branch attributes of the logical branch; if the branch type is an optional branch, then the guard conditions for entering the optional branch are extracted from the unique fragment description of the branch fragment to obtain the branch attributes of the optional branch; if the branch type is a cyclic branch, then the cyclic meaning of the cyclic branch is extracted from the unique fragment description of the branch fragment, and the exit condition of the cyclic branch is determined according to the optional branches included in the cyclic branch to obtain the branch attributes of the cyclic branch.

[0108] If the branch type is a selective logical branch (alt), this selective logical branch describes a branch with at least two options. Each option's branch has a corresponding branch description, which describes the conditions for entering that option's branch. Therefore, the branch attributes of the selective logical branch can be extracted from the branch descriptions. It is worth noting that each selective logical branch corresponds to a branch segment with a segment description; the segment description and the branch description differ in position and representation. For example... Figure 9 As shown, the selective logic branch 90 includes two option branches 910 and 920, described as [Manual login successful] and [Manual login failed], respectively. If manual login is successful, the message in branch 910 is executed to determine whether the message in branch 910 is associated with "Manual login successful", that is, to determine whether the message meets the constraints of the branch condition. If manual login fails, the message in branch 920 is executed to determine whether the message meets the constraints of the branch condition, and to determine whether the selected line logic branch 90 is normal.

[0109] If the branch type is optional (opt), it means that this branch will only be executed if the guard condition is true; otherwise, the branch will be skipped and execution will continue. The guard condition for entering the optional branch is extracted from the unique fragment description of the branch segment to obtain the branch attributes. For example... Figure 10 As shown, the fragment description of optional branch 100 is "Network process does not exist", which means that it will only be executed if the network process does not exist, and message 2.3 in this branch will be executed.

[0110] If the branch type is a loop, it indicates that the message interaction within this branch is cyclical. The fragment description of the branch segment is the business meaning of this cycle. Therefore, the cyclic meaning of the loop branch is extracted from the unique fragment description of the branch segment. It is understandable that the loop can exit; optional branches are used in the loop branch to represent the exit from the loop. Therefore, the exit condition is extracted from the branch fragments corresponding to the optional branches included in the loop branch. Furthermore, the branch fragment drawing standard requires that optional branches must include a message that exits the loop. For example... Figure 11As shown, the loop branch 110 includes an optional branch 111. The branch segment description of the optional branch 111 is the loop exit condition. The optional branch 111 includes the message 1.33 that exits the loop. Therefore, it can be determined that the message description of message 1.33 is associated with the loop branch 110 and the optional branch 111, thereby determining whether the loop branch 110 is normal.

[0111] In this embodiment of the application, for messages indicating continued loop logic and messages indicating interrupted loop logic within a loop branch, it is necessary to determine whether the message description matches the meaning of the message in order to determine whether the loop branch is normal. For example... Figure 11 In the code, message 1.37 is used to indicate the continuation of the loop logic, and the message description is: Continue loop: {loop description}, where the loop description is a branch segment description of the loop branch; message 1.310 is used to indicate the interruption of the loop logic, and the message description is: Exit loop: {loop description}; it is worth noting that message 1.310 and message 1.33 have the same message description, but message 1.33 has a different meaning within optional branch 111.

[0112] In other embodiments of this application, the branch type also includes an exception handling branch try-catch, used to represent exception handling logic, such as... Figure 12 As shown, exception handling branches are represented by alt fragments, which are described as: [try-catch]{alt fragment description}. The branch descriptions are try, catch, and finally. Here, try represents a path that may throw an exception, catch represents the capture and handling of exceptions thrown in try, and the path identifier in finally will be executed regardless of whether an exception occurs. This finally branch can be ignored.

[0113] It should be noted that, in the embodiments of this application, the fragment descriptions of the alt fragment, opt fragment, and loop fragment are globally unique.

[0114] S530. Based on the detection results, extract the element relationships from the design sequence diagram to obtain the relationships between messages and branches in the design sequence diagram.

[0115] In this embodiment of the application, if the detection results indicate that the lifeline, message, and branch segments all conform to the sequence diagram standard, it means that the design sequence diagram has contained the key information for generating the test scenario and can be automatically parsed and analyzed. Therefore, the relationship between messages in the design sequence diagram is extracted to obtain the mutual relationship between messages, and the relationship between branches in the design sequence diagram is extracted to obtain the mutual relationship between branches.

[0116] If the detection results indicate that the lifeline, message, or branch segment does not conform to the sequence diagram standard, it means that the designed sequence diagram does not contain the key information for generating the test scenario. In this case, a message indicating that the designed sequence diagram does not meet the requirements needs to be output so that the relevant parties can modify the designed sequence diagram until the lifeline, message, or branch segment in the modified designed sequence diagram conforms to the sequence diagram standard.

[0117] It should be noted that, Figure 5 For further details on S210, S230 to S240 shown, please refer to [link / reference]. Figure 2 S210, S230 to S240 shown will not be described again here.

[0118] In this embodiment of the application, the sequence diagram standard can be used to analyze the relationship between messages and branches, including the triggering order of messages, the dependencies between different messages, and the logical flow of conditional branches. This makes the test scenario generation more logical and ensures that all branches, abnormal paths, and the state of each object can be covered in the test, thereby improving the test coverage and accuracy of the system.

[0119] This application provides another test scenario generation method based on sequence diagrams, which can be applied to... Figure 1 The implementation environment shown in this embodiment is illustrated by taking the method being executed by a server as an example. Figure 13 As shown, this test scenario generation method based on sequence diagrams... Figure 5 Based on what is shown, Figure 5 The S530 shown is extended to S1310 to S1340, and S1310 to S1340 are described in detail below:

[0120] S1310. Identify the message type of each message in the design sequence diagram, and determine the triggering order of each message in the design sequence diagram according to the timeline of the design sequence diagram.

[0121] S1320. Determine the relative order of messages based on the triggering order of each message and the message type of each message.

[0122] In this embodiment of the application, the message type can be determined according to the arrows and message descriptions in the design sequence diagram. The message type includes ordinary messages and special messages. Ordinary messages include synchronous messages, asynchronous messages, etc., and special messages include jump messages, end messages, etc.

[0123] It is understandable that the design sequence diagram uses a two-dimensional graphical structure to represent the interaction relationship between objects. The two-dimensional diagram has two coordinate axes: the vertical axis represents the time axis, and time extends downwards along the vertical line, showing the order in which the interaction occurs; the horizontal axis represents the individual objects in the collaboration process, arranged horizontally from left to right in the diagram. Therefore, the triggering order of each message can be determined from top to bottom according to the time axis.

[0124] The relative order of messages refers to their sequential relationship in the triggering order, used to establish dependencies between messages; for example, if message A is triggered before message B, then A takes precedence over B. For ordinary messages and ending messages, their relative order directly depends on the timeline order, meaning the earlier message takes precedence over the later one. For jump messages, the jump target is determined from the message description. The jump target depends on the jump message; after the jump message is triggered, the next message to be triggered is the one corresponding to the jump target.

[0125] S1330. Identify the branch type of each branch in the design sequence diagram and the position of each branch in the design sequence diagram, and obtain the message flow order within each branch according to the branch type.

[0126] S1340. Determine the relationships between branches based on the position of each branch in the design sequence diagram and the message flow order within the branch.

[0127] In this embodiment, the branch type can be determined based on the segment identifier of the branch fragment, including selective logic branches, optional branches, loop branches, and exception branches; the message flow within a branch refers to the execution order of each message within a specific branch path, wherein the message flow order in each branch path is parsed according to the branch type; for selective logic branches, the internal message flow order is recorded in each optional branch, for example, the order of message A->B is recorded in optional branch 1, and the order of message C->D is recorded in optional branch 2; for loop branches, the execution order of messages in each loop is recorded, for example, message X->Y->Z, to ensure that the execution order is consistent in different loop iterations; for exception branches, the message flow after an exception occurs is recorded. For example, the processing flow of jumping to the catch branch after an exception occurs in the try branch ensures that the order of the exception flow is recorded completely.

[0128] The position of a branch in the design sequence diagram can be determined by image recognition or by the trigger time of the branch segment on the timeline.

[0129] By observing the position of branches in the sequence diagram, we can determine the relative positional relationship between two branches. Then, by combining the message flow order within the branches, we can determine whether the messages between the branches are related, and thus determine whether there is a relationship between the two branches. For example, if the relative positional relationship between two branches is that branch 1 includes branch 2, then we can directly determine that there is a dependency relationship between branch 1 and branch 2.

[0130] If the relative positional relationship between two branches is non-inclusive, such as adjacent or non-adjacent, assuming that the message flow order within branch 1 and branch 2 determines that the messages between branch 1 and branch 2 are mutually exclusive, then it is determined that there is no mutual relationship between branch 1 and branch 2; assuming that the message flow order within branch 1 and branch 2 determines that the messages between branch 1 and branch 2 are dependent, then it is determined that there is a dependency relationship between branch 1 and branch 2.

[0131] It should be noted that, Figure 13 For detailed information on S210, S510-S520, and S230-S240 shown in the diagram, please refer to [link / reference needed]. Figure 5 S210, S510~S520, and S230~S240 shown will not be described again here.

[0132] In this embodiment of the application, the above steps can clearly determine the relationships between messages and between branches, ensuring the correctness and robustness of message logic and branch logic.

[0133] This application also provides another test scenario generation method based on sequence diagrams, which can be applied to... Figure 1 The implementation environment shown in this embodiment is illustrated by taking the method being executed by a server as an example. Figure 14 As shown, in Figure 2 Based on what is shown, Figure 2 The S230 shown is extended to S1410 to S1430, where the interaction elements include messages and branches. S1410 to S1430 are described in detail below:

[0134] S1410. Treat each message and branch in the design sequence diagram as a node.

[0135] S1420. Determine the parent node, child node, and sibling node of a node, as well as the order relationship between nodes, based on their mutual relationships.

[0136] S1430. Treat the order relationship between nodes as edges, and construct an interactive directed graph based on each node and edge.

[0137] In this embodiment, each message and branch in the sequence graph is treated as a node. The relative order between messages and branches can be determined based on their interrelationships. Therefore, the parent, child, and sibling nodes of each node can be determined. The order relationships between messages and branches are treated as edges. Based on this order, all nodes and all edges are used to construct an interactive directed graph. Specifically, this embodiment provides a conceptual table of directed graph construction algorithm names, as shown in Table 3 below.

[0138]

[0139] Table 3

[0140] In one example, the branch attributes of a branch are used as nodes, such as the branch conditions for entering a branch and the messages within the branch, with the messages within the branch being child nodes of the branch conditions.

[0141] like Figure 15 As shown, it is an interactive directed graph, in which numbered nodes are message nodes and meaning-numbered nodes are branch nodes. For example, nodes 1510, 1520, 1530 and 1540 are branch descriptions of the alt branch, node 1550 is a fragment description of the loop branch, node 1560 is a fragment description of the opt branch, and so on.

[0142] The sources of graph nodes are mainly twofold: the first is messages or branches in a sequence graph, where each message or branch can be considered a node; the second is virtual nodes, such as the graph start node S and the graph end node E.

[0143] It should be noted that, Figure 14 For further details regarding S210-S220 and S240 shown, please refer to [link / reference]. Figure 2 S210 to S220 and S240 shown in the figure will not be described again here.

[0144] In this embodiment of the application, by representing each message and branch as a node in a directed graph, and the transmission order of the nodes as directed edges between the nodes, the design sequence graph can be constructed to fully express the interaction flow in the design sequence graph.

[0145] In one embodiment of this application, another test scenario generation method based on sequence diagrams is also provided, which can be applied to... Figure 1 The implementation environment shown in this embodiment is illustrated by taking the method being executed by a server as an example. Figure 16 As shown, this test scenario generation method based on sequence diagrams... Figure 14 Based on what is shown, Figure 2The S240 shown is expanded to S1610 to S1620. The interactive directed graph also includes a starting node. S1610 to S1620 are described in detail below:

[0146] S1610. Obtain the business target node and at least two critical edges in the interactive directed graph.

[0147] In this embodiment of the application, key edges in the interactive directed graph can be identified using graph algorithms. The key edges are all the edges in the directed graph, ensuring that all messages or conditions are in the generated test path.

[0148] In one example, critical edges are those corresponding to all important message passing, branching, exception handling, and other key operations in the sequence graph. For example, obtaining critical edges includes: obtaining the node corresponding to the target branch in the directed graph of the interaction, and determining the critical edge from at least two edges associated with the node corresponding to the target branch; where the target branch is a branch including branch conditions, such as the starting point of any conditional branch (e.g., alt or opt fragments), which is marked as a critical edge. Conditional branches control the flow and are key points in the test path; the target branch is a loop branch, and the edges at the starting and ending points of all loop structures (e.g., loop fragments) should be marked as critical edges. These boundaries determine the entry and exit conditions of the loop, which helps to test the boundary cases of the loop logic.

[0149] In one example, if an edge carries a data dependency, meaning its output data is used by subsequent messages, then this edge is designated as a critical edge. Such edges are crucial when testing data streams. Alternatively, edges that depend on at least two nodes can be designated as critical edges.

[0150] In one example, if important attributes (such as "must be tested" or "critical path") are marked on specific edges during the design of the sequence diagram, these edges can be directly used as critical edges. For example, if the main business process corresponding to the sequence diagram is login and payment, then the messages or branches associated with login and payment are marked as important attributes, and the edges corresponding to the important attributes are used as critical edges.

[0151] In this embodiment, the business target node includes the main business functions and process nodes in the interaction directed graph; the target business node can be pre-marked in the interaction directed graph, and before obtaining the target business node, it also includes:

[0152] Obtain the main business process corresponding to the design sequence diagram; identify the message content in the design sequence diagram to determine the target message and target branch with the function name or business description corresponding to the main business process; mark the branch attributes corresponding to the target message and target branch as target business nodes in the interaction directed graph.

[0153] For example, if the main business process corresponding to the design sequence diagram is login and payment, and the function name or business description corresponding to the main business process is payment, login, verification, etc., then the message content in the design sequence diagram is identified by keywords, and the target messages and target branches with function names or business descriptions such as object login, payment confirmation, order submission, etc. are taken as target business nodes and marked in the interaction directed graph.

[0154] In other embodiments of this application, in a directed graph, nodes with higher degrees (i.e., nodes connected to more other nodes) are key nodes in the business process, and nodes with out-degree and in-degree greater than a preset threshold can be used as business target nodes.

[0155] In other embodiments of this application, the entire graph is divided into several subgraphs, and the central node in each subgraph is analyzed. For example, the node that is accessed or connected most frequently in a certain subgraph can be regarded as the business target node of that subprocess.

[0156] S1620. Based on the path formed by the starting node, at least two critical edges, and the business target node, determine at least two operation paths, and generate the target test scenario corresponding to the design sequence diagram based on each operation path.

[0157] In this embodiment of the application, an operation path is explored for each key edge to obtain at least two operation paths described by the design sequence graph; wherein, path 1 is composed of the starting node and a key edge, and path 2 is composed of the key edge and the business target node, thereby obtaining the operation path corresponding to the key edge.

[0158] In one example, determining the operation path includes:

[0159] For each critical edge, find the first shortest path from the starting node to the critical edge, and check if there is a path from the critical edge to the business target node; merge the first shortest path and the search results to obtain the operation path corresponding to the critical edge.

[0160] The Dijkstra algorithm and the Bellman-Ford algorithm can be used to find the first shortest path from the starting node S to the critical edge (ignoring skipping edges in this process). Based on this, it is necessary to find whether there is a path from the critical edge to the business target node. In one example, if the search result indicates that there is a critical edge to the business target node, the Dijkstra algorithm and the Bellman-Ford algorithm are further used to find the second shortest path from the critical edge to the business target node, and the third path from the business target node to the end node. The first shortest path, the second shortest path, and the third shortest path are merged into a complete path. The generated path covers all critical edges from the starting node S to the end node E. During the merging, it is ensured that there are no skipping or duplicate nodes in the path, so that the entire path remains smooth and continuous.

[0161] In another example, if it is impossible to find a path back to the main business target node, then the second shortest path from the critical edge to E is explored instead; that is, if the search result indicates that there is no path from the critical edge to the business target node, the second shortest path from the critical edge to the end node is searched, and the operation path is obtained by merging the first shortest path and the second shortest path. During the merging, it is ensured that there are no skipped or repeated nodes in the path, so that the entire path remains smooth and continuous.

[0162] To prevent the generation of a large number of duplicate operation paths, if at least two key edges derive completely identical operation paths, only one is retained. The final set of operation paths is the set of all operation paths described by the design sequence diagram.

[0163] In another example, starting from the starting node S, we proceed along each path until we reach the ending node E. We record the key edges and business target nodes traversed along each path. After all paths have been traversed, we remove duplicate paths from the path set and retain each unique path. The paths that pass through more than a preset threshold of key edges and business target nodes are selected as the operation paths.

[0164] In this embodiment, the operation path describes a deterministic sequence of interactions between objects. By combining these interaction messages and summarizing them using an AI model, the test scenario corresponding to this operation path can be derived. The AI ​​model is pre-trained based on sample interaction messages and sample test scenarios. For example, an operation path might look like this:

[0165] S->1.1 Start the instant messaging application->1.2 Start the main process->1.3 Check if uin exists->1.4 Start the network process->If uin exists, perform automatic login->1.24 Trigger automatic login->1.25 Execute automatic login->1.26 Automatic login->1.27 Return automatic login information->1.28 Save: aakey->1.29 Clear->1.30 Set payment login in progress->1.31 Save a2auth domain list into memory cache->1.32 Notify of successful automatic login->Attempt payment login->1.34 Payment login->Pay login response timeout (no response for more than 30-40 seconds)->1.311 Continue loop: Attempt payment login->Attempt payment login->1.34 Payment login->Pay login response is timely->1.35 Verify a2auth Ticket validity -> Valid -> 1.37 Payment login -> 1.38 Attempt to obtain login status -> 1.39 Query login status -> Obtain login status -> 1.40 Update login status -> 1.41 Update login status - update operation -> 1.44 Write business login status to local cache -> 1.45 Create social payment login status -> 1.46 Write social login status to cache -> 1.47 Redirect to msg: 1.52 -> 1.52 Payment login response -> 1.53 Save a2auth Session cached in memory -> 1.54 Exit loop: Attempt payment login -> 1.56 Set payment login not performed -> 1.57 Set cache to main process -> 2.1 Use function -> 2.2 Check network process is normal -> 2.7 Send CGI corresponding to function -> 2.8 Check CGI domain -> Domain matches [Payment function] -> 2.9 Check payment login state -> Payment login state exists -> 2.10 Request payment CGI -> Business is social payment -> 2.17 Verify social login state -> 2.18 Get social login state from local cache -> 2.20 Security verification -> 2.23 Decompress and decrypt request packet -> 2.24 Forward -> 2.25 Encrypt and compress response packet -> 2.26 Redirect msg: 2.27 -> 2.27 Payment CGI -> 2.28 Notify payment CGI request successful -> 2.29 Request object executes payment function -> 2.30 [End of process] -> E.

[0166] After understanding the above operation path using an AI big model, the test scenario can be summarized as follows: After the instant messaging application successfully logs in automatically, the first payment login response times out. After retrying, the second payment login is successful, and then the social payment function in the instant messaging application can be used normally.

[0167] It should be noted that, Figure 16For further details regarding S210-S220 and S1410-S1430 shown, please refer to [link to detailed description]. Figure 14 S210~S220 and S1410~S1430 shown will not be described again here.

[0168] In this embodiment, the operation path of each key edge is determined by the starting node, key edge and business target node, so that the operation path covers the business target node and can form a series of complete but not cumbersome interaction steps, thereby generating a variety of test scenarios and ensuring the comprehensiveness of the test scenarios.

[0169] It is worth noting that, in one embodiment of this application, another test scenario generation method based on sequence diagrams is also provided. This test scenario generation method based on sequence diagrams can be applied to... Figure 1 The implementation environment shown is illustrated using the example of the method being executed by a server. Figure 17 As shown, this test scenario generation method based on sequence diagrams... Figures 2 to 16 Based on the above, the process of generating test cases in S240 is extended to S1710 to S1730. S1710 to S1730 are described in detail below:

[0170] S1710. Obtain the business logic corresponding to the target test scenario, and construct the necessary steps for test cases based on the business logic.

[0171] S1720. Obtain the prerequisites and expected results required for the test cases.

[0172] S1730. Generate test cases corresponding to the design sequence diagram based on the preconditions, expected results, and necessary steps.

[0173] In this embodiment, the business logic describes how the system responds to object input, performs operations, or outputs results under different conditions. The business logic in the test scenario includes the sequence of process nodes and operational dependencies. For example, the purchase process of an e-commerce platform includes "login -> add items to cart -> checkout and payment -> order confirmation." The key steps for each scenario are identified in the business logic; for example, in the purchase process, "login," "add items," and "payment" are core steps. Each key step is further refined into specific operational steps. For example, the "payment" step may require sub-steps such as selecting a payment method, entering payment information, and confirming payment. The order of each step is determined according to the business logic to ensure that test cases can execute according to the actual operation process; for example, login and adding items to the cart must be completed before payment.

[0174] In this embodiment of the application, the preconditions are the state or environment settings that the system should meet before the test is executed to ensure that the test cases can run correctly. For example, the expected result is the expected state or output after each step in the test case is executed, which is used to verify whether the system behavior conforms to the design.

[0175] Test cases are composed of preconditions, necessary steps, and expected results, as shown in Table 4 below. Each row represents a test case, and the table headers are: Test Case Type, Automation, Test Case Name, Preconditions, Test Case Steps, and Expected Result.

[0176]

[0177]

[0178] Table 4

[0179] It should be noted that, Figure 17 For further details regarding S210 to S230 shown, please refer to [link to relevant documentation]. Figure 2 S210 to S230 shown in the figure will not be described again here.

[0180] In this embodiment of the application, based on the test scenario, the input data, expected output and execution conditions of the test cases can be further supplemented to form a complete set of test cases to facilitate testing.

[0181] This application also provides a test scenario generation method based on sequence diagrams, which is applied to a test scenario generation system, such as... Figure 18 As shown, the test scenario generation system includes a sequence graph management system, a feature library system, and an automatic test scenario generation system. The sequence graph management system is a B / S architecture, while the feature library system and the automatic test scenario generation system are backend services.

[0182] The sequence diagram management system is a typical management information system, employing a browser / server (BS) architecture. Objects can open a browser, access the system's website, and draw design sequence diagrams according to UML standards based on the software component implementation logic. Besides drawing sequence diagrams, objects can also perform management functions such as searching, modifying, deleting, and authorizing sequence diagrams. Furthermore, to facilitate integration with external systems, the system provides an API interface for querying structured JSON data of a specific sequence diagram, allowing external programs to parse and process the diagram.

[0183] The feature library system characterizes the natural language corpus appearing in the sequence graph, selects appropriate implementation methods for the features (feature classification), and maintains the conflict relationships between features. The results of these processing steps by the feature library system are used by the automatic test case generation system as reference material during the generation process.

[0184] The test scenario automatically generates the system's execution process, such as Figure 19 As shown, it includes:

[0185] S1910. Preparation of basic sequence diagram data. The sequence diagram provided by the sequence diagram management system is checked against the sequence diagram standard. If it does not conform to the sequence diagram standard, the developers are required to make modifications before saving. For the sequence diagram standard, please refer to the aforementioned embodiment, which will not be repeated here.

[0186] S1920. Analyze the sequence diagram, analyze the interaction relationships in the sequence diagram, and construct an interaction directed graph. Each message in the sequence diagram describes the interaction action between two lifeline entities, while a series of messages describes how a functional logic is implemented by at least two lifeline entities working together. Therefore, in order to make it easier for the program to identify the relationships between messages / branches in the sequence diagram, this embodiment of the application analyzes the relationships between messages / branches in the sequence diagram according to the requirements of the sequence diagram standard, and draws a directed graph describing the flow of messages / branches according to certain rules.

[0187] S1930. Traverse the directed graph to derive the operation paths covering all edges. Test case paths describe a series of interaction steps between the system and objects. If each step is considered a node, then this series of steps can be seen as a path generated by combining at least two nodes in a certain order. Therefore, to generate test cases, we can traverse the directed graph described above and derive all operation paths described in the design sequence diagram. These operation paths form the skeleton of the final generated test cases.

[0188] S1940. Derive the corresponding test scenario from an operation path. Each operation path represents a certain deterministic sequence of interactions. Therefore, by combining these interaction messages and summarizing them through a large model, the test scenario corresponding to this operation path can be derived.

[0189] In this embodiment, test scenarios covering all scenarios in the design sequence diagram are automatically derived based on the design sequence diagram. Specifically, the relationships between messages / branches in the sequence diagram are analyzed, a directed graph model is constructed based on the messages / branches in the sequence diagram, key edges in the directed graph are analyzed, and a path is explored in the directed graph for each key edge. A test scenario is automatically summarized based on each path, thus preparing for the generation of practically usable test cases. In this way, by analyzing all operation paths contained in the sequence diagram through the program, it no longer relies on the experience of testers and their understanding of the software workflow, avoiding the problem of omissions in the analyzed test scenarios due to human factors. The efficiency of automatically deriving all test scenarios through the program is greatly improved compared to using human brains to analyze the functional logic of software components, gradually summarize various test scenarios, and record them. Under normal circumstances, it only takes 60 seconds to derive all test scenarios from a design sequence diagram of medium complexity using this method.

[0190] This application describes an apparatus embodiment that can be used to execute the sequence diagram-based test scenario generation method described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the above embodiments of the sequence diagram-based test scenario generation method.

[0191] This application provides a test scenario generation device based on sequence diagrams, such as... Figure 20 As shown, the device is configured on the server and includes:

[0192] The acquisition module 2010 is used to acquire design sequence diagrams and preset sequence diagram standards. The design sequence diagrams include interactive elements used to describe message passing and control flow between objects, and the sequence diagram standards are used to describe the rules and requirements for drawing sequence diagrams.

[0193] Extraction module 2020 is used to extract element relationships from the design sequence diagram according to the sequence diagram standard, and obtain the mutual relationships between the interactive elements in the design sequence diagram;

[0194] Construction module 2030 is used to construct an interactive directed graph corresponding to the design sequence graph to describe the flow of interactive elements based on the mutual relationships;

[0195] The generation module 2040 is used to extract each operation path described by the design sequence graph from the interaction directed graph, and generate the target test scenario corresponding to the design sequence graph according to each operation path.

[0196] In one embodiment of this application, based on the foregoing scheme, the interaction elements include messages and branches; the extraction module is further used to extract lifelines, messages, and branch segments describing branches from the design sequence diagram; to detect the lifelines, messages, and branch segments according to the sequence diagram standard to obtain detection results; and to extract element relationships from the design sequence diagram based on the detection results to obtain the mutual relationships between messages and between branches in the design sequence diagram.

[0197] In one embodiment of this application, based on the foregoing scheme, the extraction module is further configured to: detect whether the abstraction levels of each lifeline are consistent according to the lifeline drawing standard; detect whether the arrow of each message corresponds to the lifeline body according to the message drawing standard; and verify whether each message is normal according to the arrow and message description of each message; match the fragment symbols in the branch fragment drawing standard with the fragment symbols of each branch fragment in the design sequence diagram to determine the branch type described by each branch fragment; obtain the branch attributes of the corresponding branch according to the branch type; and verify whether the branch is normal according to the branch attributes and the messages within the branch.

[0198] In one embodiment of this application, based on the foregoing scheme, the extraction module is further configured to verify that the target class message is drawn normally if the message description of the target class message includes a message jump target, and the endpoint lifeline corresponding to the arrow of the target class message is the starting lifeline of the message jump target; and to verify that the target class message is drawn normally if the message description of the target class message includes a preset message end description, and the endpoint lifeline corresponding to the arrow of the target class message is consistent with the starting lifeline.

[0199] In one embodiment of this application, based on the foregoing scheme, the extraction module is further configured to: if the branch type is a selective logical branch including a branch description, extract the branch conditions for entering the logical branch from the branch description of the logical branch to obtain the branch attributes of the logical branch; if the branch type is an optional branch, extract the guard conditions for entering the optional branch from the unique fragment description of the branch segment to obtain the branch attributes of the optional branch; if the branch type is a cyclic branch, extract the cyclic meaning of the cyclic branch from the unique fragment description of the branch segment, and determine the exit conditions for the cyclic branch based on the optional branches included in the cyclic branch to obtain the branch attributes of the cyclic branch.

[0200] In one embodiment of this application, based on the foregoing scheme, the extraction module is further configured to identify the message type of each message in the design sequence diagram, and determine the triggering order of each message in the design sequence diagram according to the timeline of the design sequence diagram; determine the relative order between the messages based on the triggering order and the message type of each message; identify the branch type of each branch in the design sequence diagram and the position of each branch in the design sequence diagram, and obtain the message flow order within each branch based on the branch type of each branch; determine the interrelationship between the branches based on the branch type of each branch, its position in the design sequence diagram, and the message flow order within the branch.

[0201] In one embodiment of this application, based on the foregoing scheme, the interaction elements include messages and branches, and the construction module is further configured to treat each message and branch in the design sequence diagram as nodes; determine the parent node, child node, and sibling node of the node, as well as the order relationship between the nodes, according to the mutual relationship; treat the order relationship between the nodes as edges, and construct the interaction directed graph according to each node and the edges.

[0202] In one embodiment of this application, based on the foregoing scheme, the interactive directed graph further includes a starting node; the generation module is further configured to obtain the business target node and at least two key edges in the interactive directed graph; and determine at least two operation paths based on the path formed by the starting node, the at least two key edges and the business target node, wherein the operation paths are used to describe a deterministic interaction sequence between objects.

[0203] In one embodiment of this application, based on the foregoing scheme, the generation module is further configured to, for each key edge, find the first shortest path from the starting node to the key edge, and find whether there is a path from the key edge to the business target node; and generate the operation path corresponding to the key edge according to the first shortest path and the search result.

[0204] In one embodiment of this application, based on the foregoing scheme, the interactive directed graph further includes an end node; the generation module is further configured to, if the search result indicates the existence of a second shortest sub-path from the key edge to the business target node, find a third sub-path from the business target node to the end node, and merge the first sub-path, the second sub-path, and the third sub-path to obtain the operation path; if the search result indicates the absence of a path from the key edge to the business target node, find a second shortest path from the key edge to the end node, and merge the first shortest path and the second shortest path to obtain the operation path.

[0205] In one embodiment of this application, based on the foregoing scheme, the device further includes a marking module, used to obtain the main business process corresponding to the design sequence diagram; identify the message content in the design sequence diagram to determine the target message and target branch with the function name or business description corresponding to the main business process; and mark the target message and the target branch as the target business node in the interactive directed graph.

[0206] In one embodiment of this application, based on the aforementioned scheme, the test scenario includes various test scenarios generated corresponding to each operation path. The generation module is further used to perform feature extraction processing on the message content in the design sequence diagram to obtain at least two message features; perform message classification processing on the at least two message features to obtain corpus classification information of the message content, and perform conflict detection processing on the at least two message features to obtain conflict corpus information; and filter the various test scenarios according to the corpus classification information and the conflict corpus information to obtain the target test scenario.

[0207] In one embodiment of this application, based on the foregoing scheme, the generation module is further configured to obtain the business logic corresponding to the target test scenario, construct the necessary steps required to generate the test cases according to the business logic; obtain the preconditions and expected results required for the test cases; and generate the test cases corresponding to the design sequence diagram according to the preconditions, the expected results and the necessary steps.

[0208] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module and unit performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0209] Embodiments of this application also provide an electronic device, including one or at least two processors and a storage device, wherein the storage device is used to store one or at least two computer programs, which, when executed by one or at least two processors, enable the electronic device to implement the sequence diagram-based test scenario generation method as described above.

[0210] Figure 21 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0211] It should be noted that, Figure 21 The computer system 2100 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0212] like Figure 21As shown, the computer system 2100 includes a central processing unit (CPU) 2101, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on a program stored in read-only memory (ROM) 2102 or a program loaded from storage portion 2108 into random access memory (RAM) 2103. The RAM 2103 also stores various programs and data required for system operation. The CPU 2101, ROM 2102, and RAM 2103 are interconnected via a bus 2104. An input / output (I / O) interface 2105 is also connected to the bus 2104.

[0213] In some embodiments, the following components are connected to the I / O interface 2105: an input section 2106 including a keyboard, mouse, etc.; an output section 2107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 2108 including a hard disk, etc.; and a communication section 2109 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 2109 performs communication processing via a network such as the Internet. A drive 2110 is also connected to the I / O interface 2105 as needed. A removable medium 2111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 2110 as needed so that computer programs read from it can be installed into the storage section 2108 as needed.

[0214] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 2109, and / or installed from removable medium 2111. When the computer program is executed by processor (CPU) 2101, it performs various functions defined in the system of this application.

[0215] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or at least two wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory, flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0216] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or at least two executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and a computer program.

[0217] The units or modules described in the embodiments of this application can be implemented in software or hardware, and can also be located in a processor. The names of these units or modules do not necessarily limit the specific unit or module itself.

[0218] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the sequence diagram-based test scenario generation method described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0219] Another aspect of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of an electronic device reads the computer program from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the sequence diagram-based test scenario generation method provided in the various embodiments above.

[0220] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by at least two modules or units.

[0221] Other embodiments of this application will readily conceive of by considering the specification and practicing the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0222] The above content is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A test scenario generation method based on sequence graphs, characterized in that, The method includes: Obtain design sequence diagrams and preset sequence diagram standards. The design sequence diagrams include interactive elements used to describe message passing and control flow between objects, and the sequence diagram standards are used to describe the rules and requirements for drawing sequence diagrams. The element relationships of the design sequence diagram are extracted according to the sequence diagram standard to obtain the mutual relationships between the interactive elements in the design sequence diagram; Based on the aforementioned relationships, construct an interactive directed graph corresponding to the design sequence graph to describe the flow of the interactive elements; Extract each operation path described by the design sequence graph from the interaction directed graph, and generate the target test scenario corresponding to the design sequence graph based on each operation path.

2. The method according to claim 1, characterized in that, The interactive elements include messages and branches; the step of extracting element relationships from the design sequence diagram according to the sequence diagram standard to obtain the mutual relationships between the interactive elements in the design sequence diagram includes: Extract the lifeline, messages, and branch segments used to describe branches from the design sequence diagram; The lifeline, the message, and the branch segment are detected according to the sequence diagram standard to obtain the detection results. Based on the detection results, the element relationships of the design sequence graph are extracted to obtain the mutual relationships between the messages and the mutual relationships between the branches in the design sequence graph.

3. The method according to claim 2, characterized in that, The sequence graph standard includes a lifeline drawing standard, a message drawing standard, and a branch segment drawing standard; the lifeline, the message, and the branch are detected according to the sequence graph standard, including: The abstraction level of each lifeline is checked against the lifeline drawing standard to determine whether they are consistent. The system detects whether the arrow of each message corresponds to the lifeline body according to the message drawing standard, and verifies whether each message is normal according to the arrow and message description of each message. The fragment symbols in the branch fragment drawing standard are matched with the fragment symbols of each branch fragment in the design sequence diagram to determine the branch type described by each branch fragment; the branch attributes of the corresponding branch are obtained according to the branch type, and the branch is verified to be normal according to the branch attributes and the messages in the branch.

4. The method according to claim 3, characterized in that, The step of verifying whether each message is normal based on the arrow and message description of each message includes: If the message description of a target message includes a message jump target, and the endpoint lifeline corresponding to the arrow of the target message is the starting lifeline of the message jump target, then the target message is verified to be drawn normally. If the message description of the target message includes a preset message end description, and the endpoint lifeline and the starting lifeline corresponding to the arrow of the target message are consistent, then the target message is verified to be drawn normally.

5. The method according to claim 3, characterized in that, The step of obtaining the branch attributes of the corresponding branch according to the branch type includes: If the branch type is a selective logical branch that includes a branch description, then the branch conditions for entering the logical branch are extracted from the branch description of the logical branch to obtain the branch attributes of the logical branch. If the branch type is an optional branch, then the guard conditions for entering the optional branch are extracted from the unique fragment description of the branch fragment to obtain the branch attributes of the optional branch; If the branch type is a loop branch, the loop meaning of the loop branch is extracted from the unique fragment description of the branch fragment, and the exit condition for the loop is determined according to the optional branches included in the loop branch, so as to obtain the branch attribute of the loop branch.

6. The method according to claim 2, characterized in that, The step of extracting element relationships from the design sequence diagram to obtain the relationships between messages and between branches in the design sequence diagram includes: Identify the message type of each message in the design sequence diagram, and determine the triggering order of each message in the design sequence diagram according to the timeline of the design sequence diagram; The relative order of the messages is determined based on the triggering order of each message and the message type of each message; Identify the branch type of each branch in the design sequence diagram and the position of each branch in the design sequence diagram, and obtain the message flow order within each branch according to the branch type; The relationships between the branches are determined based on the branch type of each branch, its position in the design sequence diagram, and the message flow order within the branch.

7. The method according to claim 1, characterized in that, The interactive elements include messages and branches. Constructing the directed interaction graph corresponding to the design sequence graph, which describes the flow of the interactive elements, based on the relationships between them, includes: Each message and branch in the design sequence diagram are treated as nodes; The parent node, child node, and sibling node of the node, as well as the order relationship between the nodes, are determined based on the aforementioned interrelationships. The order relationship between the nodes is used as edges, and the interactive directed graph is constructed based on each node and the edges.

8. The method according to claim 7, characterized in that, The directed interactive graph also includes a starting node; the extraction of each operation path described by the design sequence graph from the directed interactive graph includes: Obtain the business target node and at least two key edges in the interaction directed graph; Based on the path formed by the starting node, the at least two key edges, and the business target node, at least two operation paths are determined, which are used to describe a deterministic sequence of interactions between objects.

9. The method according to claim 8, characterized in that, The step of determining at least two operation paths based on the path formed by the starting node, the at least two critical edges, and the business target node includes: For each critical edge, find the first shortest path from the starting node to the critical edge, and check if there is a path from the critical edge to the business target node to obtain the search results; The operation path corresponding to the key edge is generated based on the first shortest path and the search result.

10. The method according to claim 9, characterized in that, The interactive directed graph also includes an end node; generating the operation path corresponding to the key edge based on the first shortest path and the search result includes: If the search result indicates the existence of a second shortest sub-path from the key edge to the business target node, then a third sub-path from the business target node to the end node is searched, and the first sub-path, the second sub-path, and the third sub-path are merged to obtain the operation path; If the search result indicates that there is no path from the critical edge to the business target node, then the second shortest path from the critical edge to the end node is searched, and the operation path is obtained by merging the first shortest path and the second shortest path.

11. The method according to claim 8, characterized in that, Before obtaining the business target node and at least two key edges in the interactive directed graph, the method further includes: Obtain the main business process corresponding to the design sequence diagram; Identify the message content in the design sequence diagram to determine the target message and target branch that contains the function name or business description corresponding to the main business process; The target message and the target branch are labeled as target business nodes in the interactive directed graph.

12. The method according to any one of claims 1 to 11, characterized in that, The test scenarios include various test scenarios generated for each operation path; generating the target test scenario corresponding to the design sequence diagram based on each operation path includes: Perform feature extraction processing on the message content in the design sequence diagram to obtain at least two message features; Message classification processing is performed on the at least two message features to obtain corpus classification information of message content, and conflict detection processing is performed on the at least two message features to obtain conflict corpus information; The target test scenario is obtained by filtering the various test scenarios based on the corpus classification information and the conflict corpus information.

13. The method according to any one of claims 1 to 11, characterized in that, After generating the target test scenario corresponding to the design sequence diagram based on each operation path, the method further includes: Obtain the business logic corresponding to the target test scenario, and construct the necessary steps to generate the test cases based on the business logic; Obtain the prerequisites and expected results required for the test cases; Test cases corresponding to the design sequence diagram are generated based on the preconditions, the expected results, and the necessary steps.

14. A test scenario generation device based on sequence diagrams, characterized in that, include: The acquisition module is used to acquire design sequence diagrams and preset sequence diagram standards. The design sequence diagrams include interactive elements used to describe message passing and control flow between objects, and the sequence diagram standards are used to describe the rules and requirements for drawing sequence diagrams. The extraction module is used to extract element relationships from the design sequence diagram according to the sequence diagram standard, so as to obtain the mutual relationships between the interactive elements in the design sequence diagram; The construction module is used to construct an interactive directed graph corresponding to the design sequence graph to describe the flow of the interactive elements based on the interrelationships. The generation module is used to extract each operation path described by the design sequence diagram from the interaction directed graph, and generate the target test scenario corresponding to the design sequence diagram based on each operation path.

15. An electronic device, characterized in that, include: Storage devices and processors; The storage device is configured to store one or at least two programs that, when executed by one or at least two of the processors, cause the electronic device to perform the method of any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the processor of the electronic device, causes the electronic device to perform the method of any one of claims 1 to 13.

17. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, wherein the processor of the electronic device reads from the computer-readable storage medium and executes the computer program to cause the electronic device to perform the method of any one of claims 1 to 13.

Images