A markup language-based automated test case generation method and system

Abstract

This invention relates to the field of automated testing technology, and discloses a method and system for generating automated test cases based on markup language. The method includes: acquiring original test requirement text; writing the original test requirement text using markup language to obtain processing test requirement information; identifying a process topology diagram based on multiple operation instructions, multiple parameter constraints, multiple process logic information, and multiple data dependency information; identifying multiple target test scenarios based on the process topology diagram; identifying a test step sequence based on the target test scenarios; generating sub-test cases based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence; summarizing the sub-test cases to obtain multiple sub-test cases, thus completing the automated test case generation. This invention can improve the intelligence level of the automated test case generation process.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology, and in particular to a method and system for generating automated test cases based on markup language. Background Technology

[0002] As the scale and complexity of software systems continue to grow, software testing plays an increasingly crucial role in ensuring product quality and improving development efficiency.

[0003] Currently, common methods for generating automated test cases mainly include: first, code analysis-based techniques; second, model-based methods; and third, keyword-driven test frameworks.

[0004] While existing methods have improved test automation to some extent, they still have significant shortcomings. Test cases generated by code analysis-based methods are often overly focused on code coverage and have weak relevance to business logic, making it difficult to reflect real user operation scenarios. Model-based methods rely heavily on accurate model construction, requiring high levels of expertise from testers, and the models themselves are difficult to maintain synchronously with frequent changes in requirements. Keyword-driven or natural language processing methods lack flexibility in expressing complex test logic, data relationships, and assertion conditions, resulting in low levels of intelligence. Therefore, improving the intelligence level of the automated test case generation process has become an urgent problem to be solved. Summary of the Invention

[0005] This invention provides an automated test case generation method based on markup language and a computer-readable storage medium, the main purpose of which is to improve the intelligence level of the automated test case generation process.

[0006] To achieve the above objectives, this invention provides an automated test case generation method based on a markup language, comprising:

[0007] Obtain the original test requirement text, write the original test requirement text using markup language, and obtain the test requirement information to be processed.

[0008] The test requirement information is parsed to obtain multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information. Among them, the operation instructions, parameter constraints, process logic information and data dependency information are all in one-to-one correspondence.

[0009] The process topology diagram is determined based on multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information.

[0010] Multiple target test scenarios were identified based on the process topology diagram;

[0011] For each of the multiple target test scenarios, perform the following operations:

[0012] Based on the target test scenario, a test step sequence was identified, which includes: a set of environment preparation steps, a set of operation execution steps, and a set of result verification steps.

[0013] Sub-test cases are generated based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence.

[0014] Summarize the sub-test cases to obtain multiple sub-test cases, thus completing the automated test case generation.

[0015] Optionally, the step of writing the original test requirement text using a markup language to obtain processed test requirement information includes:

[0016] The original test requirement text is structured and parsed to obtain multiple test information groups, which include: test object information, test operation information, precondition information and expected result information.

[0017] The test logic relationship information was confirmed based on multiple test information groups;

[0018] Perform the following operation on each of the multiple test information groups:

[0019] Fill the test object information, test operation information, precondition information, and expected result information in the test information group into the preset markup language template to obtain the fill markup language template.

[0020] Summarize the fill markup language templates to obtain multiple fill markup language templates;

[0021] Multiple filler markup language templates are organized according to the test logic relationship information to obtain a markup language document;

[0022] The markup language document is validated to obtain the document validation result, which is either pass or fail.

[0023] If the verification result is successful, the markup language document will be used as the test requirement information.

[0024] If the verification result is unsuccessful, the markup language document is used as the original test requirement text, and the process of performing structured parsing on the original test requirement text is repeated until the verification result is successful.

[0025] Optionally, the structured parsing of the original test requirement text yields multiple test information groups, including:

[0026] The original test requirement text is logically segmented to obtain multiple test requirement text paragraphs;

[0027] Perform the following operation on each of the multiple test requirement text paragraphs:

[0028] The test requirement text paragraph is segmented into words to obtain segmented paragraphs;

[0029] Part-of-speech tagging is performed on segmented paragraphs to obtain part-of-speech tagged paragraphs;

[0030] The test object information and test operation information were identified based on the part-of-speech tagging of the paragraphs.

[0031] Syntactic extraction is performed on the part-of-speech tagged paragraphs to obtain precondition information and expected result information;

[0032] The test information group is obtained by summarizing the test object information, test operation information, precondition information and expected result information;

[0033] The test information groups are aggregated to obtain multiple test information groups.

[0034] Optionally, the step of identifying test logic relationship information based on multiple test information groups includes:

[0035] Extract the first from multiple test information groups The test information group and the first There are 1 test information group, among which... The initial value is 1;

[0036] For the The expected results information in the test information group, the first Test operation information in the test information group and the first Dependency analysis is performed on the precondition information in each test information group to obtain the relationship analysis results, where the relationship analysis results are: dependent or not dependent;

[0037] If the relation analysis result is dependency, then in the first... The test information group and the first Establish sequential execution relationships between test information groups to obtain sequential execution relationship groups;

[0038] If the relational analysis result is independent, then let ,Will As Returning to the extraction of the first from multiple test information groups The test information group and the first The steps for each test information group are repeated until the relational analysis results show a dependency.

[0039] make ,Will As Returning to the extraction of the first from multiple test information groups The test information group and the first The steps for each test information group, until... By summarizing the aforementioned sequential execution relationship groups, multiple sequential execution relationship groups are obtained, among which... The number of test information groups in multiple test information groups;

[0040] Randomly extract prerequisite information from multiple test information groups to obtain target prerequisite information;

[0041] Based on the target prerequisite information and multiple test information groups, several relevant test information groups were identified;

[0042] Extracting the first from multiple related test information groups The relevant test information group and the first There are several related test information groups, among which... The initial value is 1;

[0043] Based on the Test operation information in each relevant test information group and the first The test operation information in each relevant test information group confirms the mutual exclusion determination result, where the mutual exclusion determination result is: mutually exclusive or not mutually exclusive;

[0044] If the mutual exclusion determination result is mutual exclusion, then in the... The relevant test information group and the first Establish branch selection relationships among relevant test information groups to obtain branch selection relationship groups;

[0045] If the mutual exclusion determination result is that they are not mutually exclusive, then let ,Will As Returning to the extraction of the first from multiple related test information groups The relevant test information group and the first The steps for each relevant test information group continue until the mutual exclusion determination result is mutual exclusion;

[0046] make ,Will As Returning to the extraction of the first from multiple related test information groups The relevant test information group and the first The steps for each relevant test information group, until... By summarizing the aforementioned branch selection relationship groups, multiple branch selection relationship groups are obtained, among which... The number of related test information groups in multiple related test information groups;

[0047] The multiple sequential execution relationship groups and the multiple branch selection relationship groups are integrated to obtain test logic relationship information.

[0048] Optionally, the first The expected results information in the test information group, the first Test operation information in the test information group and the first Dependency analysis was performed on the precondition information in each test information group to obtain the relationship analysis results, including:

[0049] For the first The expected results information in the test information group, the first Test operation information in the test information group and the first Keyword extraction is performed on the precondition information in each test information group to obtain the first keyword set, the second keyword set, and the third keyword set;

[0050] The dependency score is calculated based on the first set of keywords, the second set of keywords, and the third set of keywords, using the following formula:

[0051]

[0052] in, Indicates dependency rating. Represents the set of first keywords. Represents the set of second keywords. Represents the third set of keywords. Denotes the cardinality of a set. Indicates intersection, Represents the union;

[0053] Compare the dependency score with the preset dependency threshold. If the dependency score is greater than or equal to the dependency threshold, the relationship analysis result is determined to be a dependency.

[0054] If the dependency score is less than the dependency threshold, the relationship analysis result is determined to be non-dependent.

[0055] Optionally, the step of validating the markup language document to obtain the document validation result includes:

[0056] Perform syntax validation on the markup language document and obtain the syntax validation result, where the syntax validation result is: syntax passed or syntax failed;

[0057] Perform semantic integrity verification on the markup language document to obtain the semantic verification result, where the semantic verification result is: semantic integrity passed or semantic integrity failed;

[0058] Perform logical consistency verification on the markup language document to obtain the logical verification result, where the logical verification result is: logical pass or logical fail;

[0059] If the syntax validation result is "grammar passed", the semantic validation result is "semantic passed", and the logic validation result is "logic passed", then set the document validation result to "validation passed".

[0060] Otherwise, set the document validation result to "validation failed".

[0061] Optionally, the step of determining the process topology based on multiple operation instructions, multiple parameter constraints, multiple process logic information, and multiple data dependency information includes:

[0062] For each of the multiple operation instructions, perform the following operation:

[0063] The operation node is confirmed based on the operation command;

[0064] The parameter constraint corresponding to the operation instruction among multiple parameter constraints is taken as the target parameter constraint;

[0065] The number of constraints is determined based on the target parameter constraints;

[0066] The data dependency information corresponding to the operation instruction among multiple data dependency information is taken as the target data dependency information;

[0067] The number of dependencies was determined based on the target data dependency information;

[0068] The structural complexity is calculated based on the number of constraints and dependencies, as shown in the following formula:

[0069]

[0070] in, Indicates structural complexity. Indicates the number of constraints. Indicates the number of dependencies. Represents the natural logarithm. The maximum number of constraints is preset.

[0071] By binding structural complexity, target parameter constraints, and target data dependency information to operation nodes, the target node is obtained;

[0072] Summarize the target nodes to obtain multiple target nodes;

[0073] The process topology diagram was determined based on multiple target nodes and multiple process logic information.

[0074] Optionally, the identification of multiple target test scenarios based on the process topology diagram includes:

[0075] Branch nodes are identified in the process topology diagram to obtain multiple branch nodes;

[0076] Perform the following operation on each of the multiple branch nodes:

[0077] Multiple node branch paths were identified based on the branch nodes and the process topology diagram;

[0078] Summarize the branch paths from multiple nodes to obtain a set of branch paths;

[0079] The branch path set is combined to obtain multiple complete test paths;

[0080] Perform the following operation for each of the multiple complete test paths:

[0081] Multiple target nodes were identified based on the complete test path;

[0082] Based on multiple target nodes, the number of key nodes, total complexity, and total number of nodes were determined.

[0083] The overall priority score of the path is calculated based on the number of key nodes, the total complexity, and the total number of nodes.

[0084] The overall priority scores of the paths are summarized to obtain the overall priority scores of multiple paths.

[0085] Based on the comprehensive priority scoring of multiple paths, multiple complete test paths for the targets were identified;

[0086] The complete test path for multiple targets is used as a test scenario for multiple targets.

[0087] Optionally, determining the test step sequence based on the target test scenario includes:

[0088] Nodes are extracted from the complete test path corresponding to the target test scenario to obtain multiple target nodes;

[0089] Perform the following operation on each of the multiple target nodes:

[0090] Based on the target node, the first target parameter constraints and the first target data dependency information are identified.

[0091] The first target parameter constraints and the first target data dependency information are instantiated to obtain executable test steps;

[0092] Summarize the executable test steps to obtain multiple executable test steps;

[0093] Multiple executable test steps are categorized to obtain a set of environment preparation steps, a set of operation execution steps, and a set of result verification steps.

[0094] The test step sequence was determined based on the set of environmental preparation steps, the set of operation execution steps, and the set of result verification steps.

[0095] To achieve the above objectives, the present invention also provides an automated test case generation system based on a markup language, comprising:

[0096] The initial text processing module is used to obtain the original test requirement text, write the original test requirement text in markup language to obtain the test requirement information, parse the test requirement information to obtain multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information, among which the operation instructions, parameter constraints, process logic information and data dependency information are all one-to-one correspondences.

[0097] The target scenario acquisition module is used to identify the process topology based on multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information, and to identify multiple target test scenarios based on the process topology.

[0098] The test step confirmation module is used to perform the following operations for each of the multiple target test scenarios: confirm the test step sequence based on the target test scenario, wherein the test step sequence includes: environment preparation step set, operation execution step set, and result verification step set;

[0099] The test case generation module is used to generate sub-test cases based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence. It then summarizes the sub-test cases to obtain multiple sub-test cases, thus completing the automated test case generation.

[0100] To address the above problems, the present invention also provides an electronic device, the electronic device comprising:

[0101] Memory, storing at least one instruction; and

[0102] The processor executes the instructions stored in the memory to implement the markup language-based automated test case generation method described above.

[0103] To address the aforementioned problems, the present invention also provides a computer-readable storage medium storing at least one instruction, which is executed by a processor in an electronic device to implement the aforementioned markup language-based automated test case generation method.

[0104] To address the problems described in the background art, this invention obtains the original test requirement text, processes it using a markup language, and then obtains the test requirement information. This invention transforms the requirements described in natural language into a clearly structured, uniformly formatted machine-readable document, laying the foundation for standardized parsing and processing. The test requirement information is then parsed to obtain multiple operation instructions, parameter constraints, process logic information, and data dependency information. Each operation instruction, parameter constraint, process logic information, and data dependency information corresponds one-to-one. This invention deeply deconstructs the structured document, accurately extracts the core elements constituting test cases, establishes clear correspondences between them, and forms a complete test logic data model, improving the intelligence level of the automated test case generation process. Based on the multiple operation instructions, parameter constraints, process logic information, and data dependency information, a process topology diagram is identified. This invention automatically draws a visual relationship diagram of the sequence of test steps, branch judgments, and data flow based on the extracted logic and data relationships, intuitively presenting the entire complex test process. Based on the process topology diagram, multiple target test scenarios are identified. By automatically identifying and breaking down specific test scenarios requiring individual verification based on different paths, branches, and condition combinations in the flowchart, the intelligence level of the automated test case generation process is improved. For each target test scenario among multiple target test scenarios, the following operations are performed: A test step sequence is determined based on the target test scenario, including: an environment preparation step set, an operation execution step set, and a result verification step set. It is evident that this embodiment of the invention intelligently plans a complete and orderly chain of steps from setting up the environment and executing operations to verifying results for each specific test scenario. Sub-test cases are generated based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence. This embodiment of the invention automatically converts the planned step sequence into standardized test case scripts or code that can be directly recognized and executed by the test engine. Sub-test cases are then aggregated to obtain multiple sub-test cases, completing the automated test case generation. This embodiment of the invention integrates all test scripts generated for different scenarios, ultimately outputting a comprehensive and directly usable automated test case set, achieving fully automated conversion from requirement documents to executable test cases, and improving the intelligence level of the automated test case generation process. Therefore, this invention can improve the intelligence level of the automated test case generation process. Attached Figure Description

[0105] Figure 1 A flowchart illustrating an automated test case generation method based on markup language provided in an embodiment of the present invention;

[0106] Figure 2 A functional block diagram of an automated test case generation system based on markup language provided in an embodiment of the present invention;

[0107] Figure 3 This is a schematic diagram of the structure of an electronic device that implements the automated test case generation method based on markup language, according to an embodiment of the present invention.

[0108] Figure 4 This is a schematic diagram illustrating the test logic relationship information for implementing the markup language-based automated test case generation method according to an embodiment of the present invention.

[0109] Explanation of reference numerals in the attached figures:

[0110] 10. Electronic device; 11. Processor; 12. Memory; 13. Bus.

[0111] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0112] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0113] This application provides a method for generating automated test cases based on a markup language. The execution entity of this method includes, but is not limited to, at least one electronic device that can be configured to execute the method provided in this application, such as a server or a terminal. In other words, the method can be executed by software or hardware installed on a terminal device or a server device, and the software can be a blockchain platform. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster.

[0114] Reference Figure 1 The diagram shown is a flowchart illustrating an automated test case generation method based on markup language according to an embodiment of the present invention. In this embodiment, the automated test case generation method based on markup language includes:

[0115] S1. Obtain the original test requirement text, and write the original test requirement text using markup language to obtain the test requirement information.

[0116] For example, Zhang is a software testing engineer at an internet company. He needs to generate test cases based on the client's requirements. So Zhang obtains the original test requirement text, which is convenient for subsequent markup language writing of the original test requirement text.

[0117] It should be explained that the original test requirements text refers to the text describing the content that the software needs to be tested. For example, it could be: Users should be able to log in to the system using an account and password. The account can be a registered email address or mobile phone number, and the password must be transmitted in encrypted form. After successful login, the page should redirect to the user's personal center homepage and display the user's nickname.

[0118] In detail, the step of writing the original test requirement text using a markup language to obtain processed test requirement information includes:

[0119] The original test requirement text is structured and parsed to obtain multiple test information groups, which include: test object information, test operation information, precondition information and expected result information.

[0120] The test logic relationship information was confirmed based on multiple test information groups;

[0121] Perform the following operation on each of the multiple test information groups:

[0122] Fill the test object information, test operation information, precondition information, and expected result information in the test information group into the preset markup language template to obtain the fill markup language template.

[0123] Summarize the fill markup language templates to obtain multiple fill markup language templates;

[0124] Multiple filler markup language templates are organized according to the test logic relationship information to obtain a markup language document;

[0125] The markup language document is validated to obtain the document validation result, which is either pass or fail.

[0126] If the verification result is successful, the markup language document will be used as the test requirement information.

[0127] If the verification result is unsuccessful, the markup language document is used as the original test requirement text, and the process of performing structured parsing on the original test requirement text is repeated until the verification result is successful.

[0128] It should be explained that filling the test object information, test operation information, precondition information, and expected result information from the test information group into the preset markup language template refers to the process of filling these information into the corresponding positions within the markup language template. Filling the markup language template refers to entering the markup language template containing the test object information, test operation information, precondition information, and expected result information from the test information group. The markup language template is shown below:

[0129] <testcase id="[自动生成的唯一标识符]">

[0130] <object> [Enter test subject information here]< / object>

[0131] <action> [Enter test operation information here]< / action>

[0132] <precondition> [Enter prerequisite information here]< / precondition>

[0133] <expected> [Enter expected result information here]< / expected>

[0134] < / testcase>

[0135] In this context, testCase refers to a test case, id refers to an identifier, testCase id represents the identifier of the test case, object represents the test object, action represents the operation steps, precondition represents the precondition, and expected represents the expected result.

[0136] For example, if the test object information is "username input box on the login page", the test operation information is "enter registered username: 123", the precondition information is "user account: 123 is registered and in normal status", and the expected result information is "display text: 123 in the username input box", then after filling the test object information, test operation information, precondition information, and expected result information in the test information group into the preset markup language template, the resulting fill markup language template is as follows:

[0137] <testcase id="step_001">

[0138] <object> Username input box on the login page< / object>

[0139] <action> Enter your registered username: 123< / action>

[0140] <precondition> User account: 123 is registered and in good standing.< / precondition>

[0141] <expected> The username input box displays the text: 123< / expected>

[0142] < / testcase>

[0143] Here, testCase id="step_001" means that the identifier of the test case is step_001.

[0144] It should be understood that organizing multiple fill markup language templates according to the test logic relationship information means: sorting the multiple fill markup language templates in ascending order according to the test order among the multiple test information groups corresponding to the multiple fill markup language templates recorded in the test logic relationship information. The test order refers to the order in which the multiple test information groups are tested. The markup language document refers to the document obtained after organizing the multiple fill markup language templates according to the test logic relationship information. Processing test requirement information refers to the markup language document when the verification result is passed.

[0145] In detail, the original test requirement text is structured and parsed to obtain multiple test information groups, including:

[0146] The original test requirement text is logically segmented to obtain multiple test requirement text paragraphs;

[0147] Perform the following operation on each of the multiple test requirement text paragraphs:

[0148] The test requirement text paragraph is segmented into words to obtain segmented paragraphs;

[0149] Part-of-speech tagging is performed on segmented paragraphs to obtain part-of-speech tagged paragraphs;

[0150] The test object information and test operation information were identified based on the part-of-speech tagging of the paragraphs.

[0151] Syntactic extraction is performed on the part-of-speech tagged paragraphs to obtain precondition information and expected result information;

[0152] The test information group is obtained by summarizing the test object information, test operation information, precondition information and expected result information;

[0153] The test information groups are aggregated to obtain multiple test information groups.

[0154] It should be explained that logically segmenting the original test requirement text refers to dividing the original test requirement text into periods. For example, if the original test requirement text is: Users should be able to log in to the system using an account and password. The account can be a registered email address or mobile phone number, and the password must be transmitted in encrypted form. After successful login, the page should redirect to the user's personal center homepage and display the user's nickname. Then, after logically segmenting the original test requirement text, the resulting test requirement text segments are: 1. Users should be able to log in to the system using an account and password. 2. The account can be a registered email address or mobile phone number, and the password must be transmitted in encrypted form. 3. After successful login, the page should redirect to the user's personal center homepage and display the user's nickname. The test requirement text segment refers to the original test requirement text after logical segmentation. The word segmentation of the test requirement text paragraph is a process of dividing the test requirement text paragraph into multiple unit words using word segmentation technology (e.g., automatic Chinese word segmentation). The method of dividing the test requirement text paragraph into multiple unit words using word segmentation technology (e.g., automatic Chinese word segmentation) is existing technology and will not be elaborated here. For example, if the test requirement text paragraph is: "Users should be able to log in to the system using their account and password," then after word segmentation, the resulting word segment paragraphs are: 1. User, 2. Should, 3. Able, 4. Through, 5. Account, 6. Password, 7. Login, 8. System. The word segmented paragraph refers to the test requirement text paragraph after word segmentation.

[0155] It is understandable that the part-of-speech tagging of the segmented paragraphs refers to the process of tagging the part of speech of each unit word in the segmented paragraphs. For example, if the segmented paragraphs are: 1. user, 2. should, 3. can, 4. through, 5. account, 6. password, 7. login, 8. system, then after tagging the segmented paragraphs, the tagged paragraphs are: 1. user (noun), 2. should (auxiliary verb), 3. can (auxiliary verb), 4. through (preposition), 5. account (noun), 6. password (noun), 7. login (verb), 8. system (noun). The tagged paragraph refers to the segmented paragraph after tagged part of speech. The test object information is the noun in the tagged paragraph, and the test operation information is the verb in the tagged paragraph. The grammatical extraction of the tagged paragraphs involves using grammatical extraction methods (e.g., dependency parsing) to extract adverbs and object complements from the tagged paragraphs. The method used to extract these adverbs and object complements is existing technology and will not be elaborated here. The adverbs in the tagged paragraphs represent preconditions, and the object complements represent expected results. The test information group refers to the information obtained by summarizing the test object information, test operation information, precondition information, and expected results information.

[0156] Specifically, the process of identifying test logic relationship information based on multiple test information groups includes:

[0157] Extract the first from multiple test information groups The test information group and the first There are 1 test information group, among which... The initial value is 1;

[0158] For the The expected results information in the test information group, the first Test operation information in the test information group and the first Dependency analysis is performed on the precondition information in each test information group to obtain the relationship analysis results, where the relationship analysis results are: dependent or not dependent;

[0159] If the relation analysis result is dependency, then in the first... The test information group and the first Establish sequential execution relationships between test information groups to obtain sequential execution relationship groups;

[0160] If the relational analysis result is independent, then let ,Will As Returning to the extraction of the first from multiple test information groups The test information group and the first The steps for each test information group are repeated until the relational analysis results show a dependency.

[0161] make ,Will As Returning to the extraction of the first from multiple test information groups The test information group and the first The steps for each test information group, until... By summarizing the aforementioned sequential execution relationship groups, multiple sequential execution relationship groups are obtained, among which... The number of test information groups in multiple test information groups;

[0162] Randomly extract prerequisite information from multiple test information groups to obtain target prerequisite information;

[0163] Based on the target prerequisite information and multiple test information groups, several relevant test information groups were identified;

[0164] Extracting the first from multiple related test information groups The relevant test information group and the first There are several related test information groups, among which... The initial value is 1;

[0165] Based on the Test operation information in each relevant test information group and the first The test operation information in each relevant test information group confirms the mutual exclusion determination result, where the mutual exclusion determination result is: mutually exclusive or not mutually exclusive;

[0166] If the mutual exclusion determination result is mutual exclusion, then in the... The relevant test information group and the first Establish branch selection relationships among relevant test information groups to obtain branch selection relationship groups;

[0167] If the mutual exclusion determination result is that they are not mutually exclusive, then let ,Will As Returning to the extraction of the first from multiple related test information groups The relevant test information group and the first The steps for each relevant test information group continue until the mutual exclusion determination result is mutual exclusion;

[0168] make ,Will As Returning to the extraction of the first from multiple related test information groups The relevant test information group and the first The steps for each relevant test information group, until... By summarizing the aforementioned branch selection relationship groups, multiple branch selection relationship groups are obtained, among which... The number of related test information groups in multiple related test information groups;

[0169] The multiple sequential execution relationship groups and the multiple branch selection relationship groups are integrated to obtain test logic relationship information.

[0170] For example, if the multiple test information groups are: M1, M2, M3, M4, M5, then the second and third test information groups extracted from the multiple test information groups are: M2, M3.

[0171] It should be explained that the above refers to the first... The test information group and the first Establishing a sequential execution relationship between test information groups means: [The following is a list of test information groups and their execution order] The test information group and the first Establish data dependencies between test information groups. The sequential execution relationship group is the first group after establishing the sequential execution relationship. The test information group and the first A test information group.

[0172] It should be understood that the random extraction of precondition information from multiple test information groups refers to randomly extracting precondition information from multiple test information groups, and the target precondition information is the precondition information randomly extracted from multiple test information groups. The extraction of the first precondition information from multiple related test information groups... The relevant test information group and the first The method for resolving multiple test information groups and the extraction of the first relevant test information group from multiple test information groups The test information group and the first The method for each test information group is the same, so it will not be repeated here.

[0173] Understandably, multiple related test information groups refer to multiple test information groups consisting of the first... The multiple test information groups derived from the first set of precondition information, where "derived" refers to: the first A set of subsequent test steps associated with each set of prerequisite information. This set of subsequent test steps is only valid if the first... It only becomes meaningful and executable when the first set of preconditions is met. For example, if the first set of preconditions is met... If the multiple test information groups derived from the first set of preconditions are C1 and C2, then the multiple related test information groups are C1 and C2. The statement based on the first... Test operation information in each relevant test information group and the first The test operation information in the relevant test information group confirms the mutual exclusion judgment result, which means: the judgment of the first... Test operation information in each relevant test information group and the first Are there any conflicts in the test operation information within the relevant test information groups? If the first... Test operation information in each relevant test information group and the first If test operation information in a related test information group conflicts, then mutual exclusion will be used as the mutual exclusion determination result; otherwise, non-mutual exclusion will be used as the mutual exclusion determination result. Mutual exclusion refers to the... Test operation information in each relevant test information group and the first Conflicting test operation information within a related test information group, meaning that they are not mutually exclusive, refers to the first... Test operation information in each relevant test information group and the first The test operation information in each related test information group is not conflicting; the conflict refers to the first group of test operations. Test operation information in each relevant test information group and the first Test operations within a single related test information group cannot be executed simultaneously. For example, if the test content is: testing "transferring from account A" and "withdrawing from the same account A", initially assuming account A has 500 yuan, transferring 100 yuan and withdrawing 150 yuan, the two operations read the balance (both 500 yuan) almost simultaneously, calculate the new balance (400 yuan for the transfer, 350 yuan for the withdrawal), and then write the results almost simultaneously—ultimately, depending on which operation is saved last, the account balance will either be 400 yuan (the withdrawal result is overwritten by the transfer, the withdrawal is "invalid") or 350 yuan (the transfer result is overwritten by the withdrawal, the transfer is "invalid"), and will never be the correct value of 250 yuan. (The following is a separate, unrelated sentence: The first part is in the...) The relevant test information group and the first Establishing a branch selection relationship between relevant test information groups refers to: in the first... The relevant test information group and the first Establish a logical relationship for branch selection among the relevant test information groups, whereby branch selection refers to: needing to establish a logical relationship for branch selection in the first... The relevant test information group and the first Select one relevant test information group from among the relevant test information groups for subsequent testing. The branch selection relationship group refers to the group after the branch selection relationship has been established. The relevant test information group and the first The test logic relationship information is the information obtained by integrating the multiple sequential execution relationship groups and the multiple branch selection relationship groups. For example, if the multiple sequential execution relationship groups are: Sequential execution relationship group 1: [Log in to the system → Browse products → Select products], Sequential execution relationship group 2: [Select products → Add to cart → Checkout], Sequential execution relationship group 3: [Checkout → Online payment → View order], Sequential execution relationship group 4: [Checkout → Cash on delivery → View order], and the multiple branch selection relationship groups are: Branch selection relationship group 1: After [Select products], you can execute [Add to cart] or [Add to favorites], Branch selection relationship group 2: When [Checkout], you can choose [Online payment] or [Cash on delivery], Branch selection relationship group 3: After [Online payment], you may get [Payment successful] or [Payment failed], then the test logic relationship information obtained by integrating the multiple sequential execution relationship groups and the multiple branch selection relationship groups is as follows: Figure 4 As shown.

[0174] In detail, the above refers to the first The expected results information in the test information group, the first Test operation information in the test information group and the first Dependency analysis was performed on the precondition information in each test information group to obtain the relationship analysis results, including:

[0175] For the first The expected results information in the test information group, the first Test operation information in the test information group and the first Keyword extraction is performed on the precondition information in each test information group to obtain the first keyword set, the second keyword set, and the third keyword set;

[0176] The dependency score is calculated based on the first set of keywords, the second set of keywords, and the third set of keywords, using the following formula:

[0177]

[0178] in, Indicates dependency rating. Represents the set of first keywords. Represents the set of second keywords. Represents the third set of keywords. Denotes the cardinality of a set. Indicates intersection, Represents the union;

[0179] Compare the dependency score with the preset dependency threshold. If the dependency score is greater than or equal to the dependency threshold, the relationship analysis result is determined to be a dependency.

[0180] If the dependency score is less than the dependency threshold, the relationship analysis result is determined to be non-dependent.

[0181] It should be explained that the above refers to the first... The expected results information in the test information group, the first Test operation information in the test information group and the first Keyword extraction from the precondition information in the first test information group refers to: from the first... Extract all unit words from the expected result information in the first test information group, starting from the first... Extract all unit words from the test operation information in the test information group, starting from the first... Extract all unit words from the precondition information in the first test information group. The first keyword set is composed of words from the first... The first set of keywords is the set of all unit words extracted from the expected result information in the first test information group. The second set of keywords is the set of all unit words extracted from the first test information group. The third keyword set is a collection of all unit words extracted from the test operation information in the first test information group. The set consisting of all unit words extracted from the precondition information in each test information group.

[0182] Understandably, the dependency score reflects the first The expected results information in the test information group, the first Test operation information in the test information group and the first The degree of correlation between the preconditions in each test information group; the higher the dependency score, the better. The expected results information in the test information group, the first Test operation information in the test information group and the first The greater the correlation between the preconditions in each test information group, the better the correlation between the preconditions. The test information group and the first The more likely a test information group is to have a dependency relationship, where the dependency relationship refers to: the first The test operations and prerequisites of each test information group are logically or data-dependent on the first... The expected result of the test information group, i.e. the first test information group. The results of the test information group directly affect the first... The dependency threshold is set manually by the software testing engineers of the internet company based on the average dependency score of multiple pairs of dependent test information groups historically identified. For example, if the average dependency score of multiple pairs of dependent test information groups historically identified is 85, then the dependency threshold is 85. Dependency refers to the first test information group executed. The test information group and the first The test information groups have dependencies; no dependency means that the first test information group has no dependency. The test information group and the first There are no dependencies between the test information groups.

[0183] In detail, the validation of the markup language document to obtain the document validation result includes:

[0184] Perform syntax validation on the markup language document and obtain the syntax validation result, where the syntax validation result is: syntax passed or syntax failed;

[0185] Perform semantic integrity verification on the markup language document to obtain the semantic verification result, where the semantic verification result is: semantic integrity passed or semantic integrity failed;

[0186] Perform logical consistency verification on the markup language document to obtain the logical verification result, where the logical verification result is: logical pass or logical fail;

[0187] If the syntax validation result is "grammar passed", the semantic validation result is "semantic passed", and the logic validation result is "logic passed", then set the document validation result to "validation passed".

[0188] Otherwise, set the document validation result to "validation failed".

[0189] It should be explained that the syntax validation of the markup language document refers to checking whether the markup language document conforms to the XML format. The syntax validation result is the result obtained after performing syntax validation on the markup language document, and the syntax validation result is: syntax passed or syntax failed. Here, syntax passed means that the markup language document conforms to the XML format, and syntax failed means that the markup language document does not conform to the XML format. The semantic integrity verification of the markup language document refers to checking whether all test object information, test operation information, precondition information, and expected result information in the markup language templates of the markup language document have been filled. The semantic verification result refers to the result obtained after performing semantic integrity verification on the markup language document, and the semantic verification result is: semantic pass or semantic fail. Semantic pass means that all test object information, test operation information, precondition information, and expected result information in the markup language templates of the markup language document have been filled in the step of filling the test object information, test operation information, precondition information, and expected result information in the test information group into the preset markup language template. Semantic fail means that there are gaps in all test object information, test operation information, precondition information, and expected result information in the markup language templates of the markup language document.

[0190] It is understood that the logical consistency verification of the markup language document refers to checking whether the order of the test steps in the markup language document is consistent with the test logical relationship information. The logical verification result refers to the result obtained after performing logical consistency verification on the markup language document, and the logical verification result is: logical pass or logical fail. Logical pass means that the order of the test steps in the markup language document is consistent with the test logical relationship information, and logical fail means that the order of the test steps in the markup language document is inconsistent with the test logical relationship information.

[0191] S2. The test requirement information is parsed to obtain multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information. Among them, the operation instructions, parameter constraints, process logic information and data dependency information are all in one-to-one correspondence.

[0192] It should be explained that parsing the test requirement information means extracting multiple test actions to be executed, input conditions and rules for executing multiple test actions, execution order and branching relationships between multiple test actions, and prerequisite data and output data required for the execution of multiple actions from the test requirement information. The multiple specific test actions to be executed are multiple operation instructions, the input conditions and rules for executing multiple test actions are multiple parameter constraints, the execution order between multiple test actions is multiple process logic information, and the prerequisite data and output data required for the execution of multiple actions are multiple data dependency information. The test action refers to an indivisible, most basic operation, such as inputting text. Input conditions and rules refer to the limitations imposed on the specific input values ​​when performing the aforementioned test action, such as the valid range of input values, data type, format, length, and other constraints. Execution order refers to the order in which different test actions are executed. Prerequisite data and output data refer to the data that must be required for the execution of the test action and the data generated after the execution of the test action, respectively. For example, if the test requirement information is: "Test the user registration function, requiring the input of username, password, and email address, and redirecting to the personal center page after successful registration," then parsing the test requirement information yields: 1. Multiple operation instructions (specific test actions): Open the website registration page, enter text in the username input box, enter text in the password input box, enter text in the email input box, click the registration button, and the verification page will redirect. 2. Multiple parameter constraints (input conditions and rules when executing test actions): Username constraints: 6-20 characters long, can only contain letters, numbers, and underscores; Password constraints: 8-16 characters long, must contain letters and numbers; Email constraints: must conform to the email format (e.g., xxx@yyy.zzz). 3. Multiple process logic information (execution order between test actions): Must be executed in the following order: Open registration page → Enter username → Enter password → Enter email → Click the registration button → Verification page redirection. 4. Multiple data dependency information (prerequisite data and output data required for action execution): Prerequisite data (data that needs to be prepared before testing): Unregistered username, such as "newuser2023"; Password that meets the requirements, such as "Pass1234"; Unregistered email address, such as test@example.com. Output data (data generated after the test action is executed): Registration status (success / failure), User ID (generated upon successful registration), URL of the redirected page.

[0193] S3. Based on multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information, the process topology diagram is determined.

[0194] Specifically, the process topology diagram is determined based on multiple operation instructions, multiple parameter constraints, multiple process logic information, and multiple data dependency information, including:

[0195] For each of the multiple operation instructions, perform the following operation:

[0196] The operation node is confirmed based on the operation command;

[0197] The parameter constraint corresponding to the operation instruction among multiple parameter constraints is taken as the target parameter constraint;

[0198] The number of constraints is determined based on the target parameter constraints;

[0199] The data dependency information corresponding to the operation instruction among multiple data dependency information is taken as the target data dependency information;

[0200] The number of dependencies was determined based on the target data dependency information;

[0201] The structural complexity is calculated based on the number of constraints and dependencies, as shown in the following formula:

[0202]

[0203] in, Indicates structural complexity. Indicates the number of constraints. Indicates the number of dependencies. Represents the natural logarithm. The maximum number of constraints is preset.

[0204] By binding structural complexity, target parameter constraints, and target data dependency information to operation nodes, the target node is obtained;

[0205] Summarize the target nodes to obtain multiple target nodes;

[0206] The process topology diagram was determined based on multiple target nodes and multiple process logic information.

[0207] It should be explained that, in the context of identifying the operation node based on the operation instruction, the operation instruction is abstracted into a node. The target parameter constraint refers to the parameter constraint corresponding to the operation instruction among multiple parameter constraints, and the number of constraint conditions refers to the number of constraint conditions within the target parameter constraint. The target data dependency information refers to the data dependency information corresponding to the operation instruction among multiple data dependency information, and the number of dependencies refers to the number of dependency relationships within the target data dependency information. Structural complexity reflects the complexity of the operation node corresponding to the operation instruction; the greater the structural complexity, the more complex and important the operation node. The maximum number of constraints is manually set by the software testing engineers of the internet company based on the maximum number of dependencies historically identified for the operation node. For example, if the maximum number of dependencies historically identified for the operation node is 5, then the maximum number of constraints is 5.

[0208] Understandably, a target node refers to an operational node bound with structural complexity, target parameter constraints, and target data dependency information. A process topology diagram refers to a topological structure diagram obtained by topologically reconstructing multiple target nodes according to multiple process logic information. The method for obtaining this topology diagram by topologically reconstructing multiple target nodes according to multiple process logic information is existing technology and will not be elaborated upon here.

[0209] S4. Based on the process topology diagram, multiple target test scenarios were identified.

[0210] Specifically, the process topology diagram identifies multiple target test scenarios, including:

[0211] Branch nodes are identified in the process topology diagram to obtain multiple branch nodes;

[0212] Perform the following operation on each of the multiple branch nodes:

[0213] Multiple node branch paths were identified based on the branch nodes and the process topology diagram;

[0214] Summarize the branch paths from multiple nodes to obtain a set of branch paths;

[0215] The branch path set is combined to obtain multiple complete test paths;

[0216] Perform the following operation for each of the multiple complete test paths:

[0217] Multiple target nodes were identified based on the complete test path;

[0218] Based on multiple target nodes, the number of key nodes, total complexity, and total number of nodes were determined.

[0219] The path priority score is calculated based on the number of critical nodes, total complexity, and total number of nodes. The calculation formula is as follows:

[0220]

[0221] in, This indicates the overall priority score of the path. Indicates the total complexity. This represents the total number of nodes. Indicates the number of critical nodes;

[0222] The overall priority scores of the paths are summarized to obtain the overall priority scores of multiple paths.

[0223] Based on the comprehensive priority scoring of multiple paths, multiple complete test paths for the targets were identified;

[0224] The complete test path for multiple targets is used as a test scenario for multiple targets.

[0225] It should be explained that the branch node identification in the process topology diagram refers to identifying all nodes with branches in the process topology diagram, and these nodes with branches are called branch nodes. A node branch path refers to the path connected to a branch node in the process topology diagram, and the branch path set is a collection obtained by summing up multiple node branch paths. The path combination in the branch path set refers to traversing the branch path set using a path combination algorithm (such as Cartesian product) to obtain multiple paths, which are the complete test paths. Furthermore, the method of traversing the branch path set using a path combination algorithm (such as Cartesian product) to obtain multiple paths is existing technology and will not be elaborated here.

[0226] Understandably, target nodes refer to nodes in the complete test path, and the number of critical nodes refers to the number of target nodes whose structural complexity exceeds a preset complexity threshold. This complexity threshold is set manually by the software testing engineers of the internet company; optionally, the complexity threshold is 0.3. The total complexity is the sum of the structural complexities corresponding to multiple target nodes, and the total number of nodes refers to the number of target nodes among multiple target nodes. The overall path priority score reflects the importance of the complete test path; the higher the overall path priority score, the more important the complete test path.

[0227] It is understood that identifying multiple target complete test paths based on the comprehensive priority score of multiple paths means: taking multiple complete test paths corresponding to the comprehensive priority scores of multiple paths that are greater than or equal to a preset priority score threshold as multiple target complete test paths. The priority score threshold is set manually by the software testing engineers of the Internet company, and optionally, the priority score threshold is 0.7.

[0228] S5. For each of the multiple target test scenarios, perform the following operations: Based on the target test scenario, determine the test step sequence, which includes: environment preparation step set, operation execution step set, and result verification step set.

[0229] Specifically, the step sequence determined based on the target test scenario includes:

[0230] Nodes are extracted from the complete test path corresponding to the target test scenario to obtain multiple target nodes;

[0231] Perform the following operation on each of the multiple target nodes:

[0232] Based on the target node, the first target parameter constraints and the first target data dependency information are identified.

[0233] The first target parameter constraints and the first target data dependency information are instantiated to obtain executable test steps;

[0234] Summarize the executable test steps to obtain multiple executable test steps;

[0235] Multiple executable test steps are categorized to obtain a set of environment preparation steps, a set of operation execution steps, and a set of result verification steps.

[0236] The test step sequence was determined based on the set of environmental preparation steps, the set of operation execution steps, and the set of result verification steps.

[0237] It should be explained that the node extraction of the complete test path corresponding to the target test scenario refers to extracting all nodes in the complete test path corresponding to the target test scenario, where all nodes are multiple target nodes. The first target parameter constraint refers to the target parameter constraint bound to the target node, and the first target data dependency information refers to the target data dependency information bound to the target node. The instantiation of the target parameter constraints and target data dependency information refers to the process of instantiating the target parameter constraints and target data dependency information. This instantiation process is existing technology and will not be elaborated here. The executable test steps are the instantiated target parameter constraints and target data dependency information.

[0238] Understandably, the environment preparation step set consists of multiple steps for initializing the environment and configuring data from multiple executable test steps; the operation execution step set consists of multiple steps for implementing the core test operations from multiple executable test steps; and the result verification step set consists of multiple steps for verifying the system output or status from multiple executable test steps. The test step sequence refers to the sequence obtained by arranging the environment preparation step set, operation execution step set, and result verification step set in the order of the tests from beginning to end.

[0239] S6. Generate sub-test cases based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence.

[0240] Specifically, the step of generating sub-test cases based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence includes:

[0241] The set of environmental preparation steps, operation execution steps, and result verification steps are standardized and assembled to obtain a preliminary test framework.

[0242] Add data to the initial test framework to obtain sub-test cases.

[0243] It should be explained that the standardized assembly of the environment preparation step set, operation execution step set, and result verification step set refers to the following: First, each environment preparation step in the environment preparation step set is organized, for example, clarifying what needs to be prepared and how to prepare it. Next, each operation execution step in the operation execution step set is organized, ensuring they follow the environment preparation steps immediately. Then, each result verification step in the result verification step set is organized and placed after all execution steps. Finally, the organized environment preparation step set, operation execution step set, and result verification step set are connected sequentially in the order of "environment preparation step set first, operation execution step set in the middle, and result verification step set last." The preliminary test framework is the automated test framework obtained after the standardized assembly of the environment preparation step set, operation execution step set, and result verification step set. Adding data to the preliminary test framework refers to adding metadata to the preliminary test framework. The method for adding metadata to the preliminary test framework is existing technology and will not be elaborated here. Sub-test cases refer to the preliminary test framework after data addition.

[0244] S7. Summarize the sub-test cases to obtain multiple sub-test cases, and complete the automated test case generation.

[0245] For example, once multiple sub-test cases are obtained, Xiao Zhang can test the target software based on these sub-test cases, ultimately completing the automated test case generation.

[0246] To address the problems described in the background art, this invention obtains the original test requirement text, processes it using a markup language, and then obtains the test requirement information. This invention transforms the requirements described in natural language into a clearly structured, uniformly formatted machine-readable document, laying the foundation for standardized parsing and processing. The test requirement information is then parsed to obtain multiple operation instructions, parameter constraints, process logic information, and data dependency information. Each operation instruction, parameter constraint, process logic information, and data dependency information corresponds one-to-one. This invention deeply deconstructs the structured document, accurately extracts the core elements constituting test cases, establishes clear correspondences between them, and forms a complete test logic data model, improving the intelligence level of the automated test case generation process. Based on the multiple operation instructions, parameter constraints, process logic information, and data dependency information, a process topology diagram is identified. This invention automatically draws a visual relationship diagram of the sequence of test steps, branch judgments, and data flow based on the extracted logic and data relationships, intuitively presenting the entire complex test process. Based on the process topology diagram, multiple target test scenarios are identified. By automatically identifying and breaking down specific test scenarios requiring individual verification based on different paths, branches, and condition combinations in the flowchart, the intelligence level of the automated test case generation process is improved. For each target test scenario among multiple target test scenarios, the following operations are performed: A test step sequence is determined based on the target test scenario, including: an environment preparation step set, an operation execution step set, and a result verification step set. It is evident that this embodiment of the invention intelligently plans a complete and orderly chain of steps from setting up the environment and executing operations to verifying results for each specific test scenario. Sub-test cases are generated based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence. This embodiment of the invention automatically converts the planned step sequence into standardized test case scripts or code that can be directly recognized and executed by the test engine. Sub-test cases are then aggregated to obtain multiple sub-test cases, completing the automated test case generation. This embodiment of the invention integrates all test scripts generated for different scenarios, ultimately outputting a comprehensive and directly usable automated test case set, achieving fully automated conversion from requirement documents to executable test cases, and improving the intelligence level of the automated test case generation process. Therefore, this invention can improve the intelligence level of the automated test case generation process.

[0247] like Figure 2 The diagram shown is a functional block diagram of an automated test case generation system based on markup language provided in an embodiment of the present invention.

[0248] The markup language-based automated test case generation system 100 of this invention can be installed in an electronic device. Depending on the functions implemented, the markup language-based automated test case generation system 100 may include an initial text processing module 101, a target scenario acquisition module 102, a test step confirmation module 103, and a test case generation module 104. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and which are stored in the memory of the electronic device.

[0249] The initial text processing module 101 is used to obtain the original test requirement text, write the original test requirement text in markup language to obtain the test requirement information, parse the test requirement information to obtain multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information, wherein the operation instructions, parameter constraints, process logic information and data dependency information are all one-to-one correspondences.

[0250] The target scenario acquisition module 102 is used to identify a process topology diagram based on multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information, and identify multiple target test scenarios based on the process topology diagram.

[0251] The test step confirmation module 103 is used to perform the following operations for each of the multiple target test scenarios: confirm the test step sequence based on the target test scenario, wherein the test step sequence includes: environment preparation step set, operation execution step set and result verification step set;

[0252] The test case generation module 104 is used to generate sub-test cases based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence, summarize the sub-test cases, obtain multiple sub-test cases, and complete the automated test case generation.

[0253] In detail, the modules in the markup language-based automated test case generation system 100 described in this embodiment of the invention employ the same methods as described above. Figure 1 The method used is the same as the markup language-based automated test case generation method described above, and it can produce the same technical effect, so it will not be repeated here.

[0254] like Figure 3 The diagram shown is a structural schematic of an electronic device that implements an automated test case generation method based on markup language, according to an embodiment of the present invention.

[0255] The electronic device 1 may include a processor 10, a memory 11 and a bus 12, and may also include a computer program stored in the memory 11 and capable of running on the processor 10, such as an automated test case generation method program based on markup language.

[0256] The memory 11 includes at least one type of readable storage medium, such as flash memory, portable hard drive, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 11 can be an internal storage unit of the electronic device 1, such as a portable hard drive. In other embodiments, the memory 11 can be an external storage device of the electronic device 1, such as a plug-in portable hard drive, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device 1. Furthermore, the memory 11 includes both internal storage units and external storage devices of the electronic device 1. The memory 11 can be used not only to store application software and various types of data installed on the electronic device 1, such as the code of an automated test case generation method program based on markup language, but also to temporarily store data that has been output or will be output.

[0257] In some embodiments, the processor 10 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor 10 is the control unit of the electronic device, connecting various components of the entire electronic device through various interfaces and lines. It executes programs or modules stored in the memory 11 (e.g., automated test case generation methods based on markup languages) and calls data stored in the memory 11 to perform various functions of the electronic device 1 and process data.

[0258] The bus 12 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus 12 can be divided into an address bus, a data bus, a control bus, etc. The bus 12 is configured to realize the connection and communication between the memory 11 and at least one processor 10, etc.

[0259] Figure 3 Only electronic devices with components are shown; it will be understood by those skilled in the art that... Figure 3 The structure shown does not constitute a limitation on the electronic device 1, and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0260] For example, although not shown, the electronic device 1 may also include a power supply (such as a battery) to power the various components. Preferably, the power supply can be logically connected to the at least one processor 10 through a power management device, thereby enabling functions such as charging management, discharging management, and power consumption management. The power supply may also include one or more DC or AC power supplies, recharging devices, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components. The electronic device 1 may also include various sensors, Bluetooth modules, Wi-Fi modules, etc., which will not be described in detail here.

[0261] Furthermore, the electronic device 1 may also include a network interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a Wi-Fi interface, a Bluetooth interface, etc.), which is typically used to establish communication connections between the electronic device 1 and other electronic devices.

[0262] Optionally, the electronic device 1 may further include a user interface, which may be a display, an input unit (such as a keyboard), and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the electronic device 1 and to display a visual user interface.

[0263] The automated test case generation method program based on markup language stored in the memory 11 of the electronic device 1 is a combination of multiple instructions. When run in the processor 10, it can achieve the following:

[0264] Obtain the original test requirement text, write the original test requirement text using markup language, and obtain the test requirement information to be processed.

[0265] The test requirement information is parsed to obtain multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information. Among them, the operation instructions, parameter constraints, process logic information and data dependency information are all in one-to-one correspondence.

[0266] The process topology diagram is determined based on multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information.

[0267] Multiple target test scenarios were identified based on the process topology diagram;

[0268] For each of the multiple target test scenarios, perform the following operations:

[0269] Based on the target test scenario, a test step sequence was identified, which includes: a set of environment preparation steps, a set of operation execution steps, and a set of result verification steps.

[0270] Sub-test cases are generated based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence.

[0271] Summarize the sub-test cases to obtain multiple sub-test cases, thus completing the automated test case generation.

[0272] Specifically, the processor 10's implementation method for the above instructions can be found in [reference needed]. Figures 1 to 3 The descriptions of the relevant steps in the corresponding embodiments are not repeated here.

[0273] Furthermore, if the modules / units integrated in the electronic device 1 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. The computer-readable storage medium can be volatile or non-volatile. For example, the computer-readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, or a read-only memory (ROM).

[0274] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor of an electronic device, can perform the following:

[0275] Obtain the original test requirement text, write the original test requirement text using markup language, and obtain the test requirement information to be processed.

[0276] The test requirement information is parsed to obtain multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information. Among them, the operation instructions, parameter constraints, process logic information and data dependency information are all in one-to-one correspondence.

[0277] The process topology diagram is determined based on multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information.

[0278] Multiple target test scenarios were identified based on the process topology diagram;

[0279] For each of the multiple target test scenarios, perform the following operations:

[0280] Based on the target test scenario, a test step sequence was identified, which includes: a set of environment preparation steps, a set of operation execution steps, and a set of result verification steps.

[0281] Sub-test cases are generated based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence.

[0282] Summarize the sub-test cases to obtain multiple sub-test cases, thus completing the automated test case generation.

[0283] In the embodiments provided by this invention, it should be understood that the disclosed devices, systems, and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative, and actual implementations may have other classification methods.

[0284] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0285] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0286] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0287] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for generating automated test cases based on a markup language, characterized in that, The method includes: Obtain the original test requirement text, and use markup language to write the original test requirement text to obtain the test requirement information to be processed. The test requirement information is parsed to obtain multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information. Among them, the operation instructions, parameter constraints, process logic information and data dependency information are all in one-to-one correspondence. The process topology diagram is determined based on multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information. Multiple target test scenarios were identified based on the process topology diagram; For each of the multiple target test scenarios, perform the following operations: Based on the target test scenario, a test step sequence was identified, which includes: a set of environment preparation steps, a set of operation execution steps, and a set of result verification steps. Sub-test cases are generated based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence. Summarize the sub-test cases to obtain multiple sub-test cases, thus completing the automated test case generation.

2. The automated test case generation method based on markup language as described in claim 1, characterized in that, The process of writing the original test requirement text using a markup language to obtain processed test requirement information includes: The original test requirement text is structured and parsed to obtain multiple test information groups, which include: test object information, test operation information, precondition information and expected result information. The test logic relationship information was confirmed based on multiple test information groups; Perform the following operation on each of the multiple test information groups: Fill the test object information, test operation information, precondition information, and expected result information in the test information group into the preset markup language template to obtain the fill markup language template. Summarize the fill markup language templates to obtain multiple fill markup language templates; Multiple filler markup language templates are organized according to the test logic relationship information to obtain a markup language document; The markup language document is validated to obtain the document validation result, which is either pass or fail. If the verification result is successful, the markup language document will be used as the test requirement information. If the verification result is unsuccessful, the markup language document is used as the original test requirement text, and the process of performing structured parsing on the original test requirement text is repeated until the verification result is successful.

3. The automated test case generation method based on markup language as described in claim 2, characterized in that, The original test requirement text is structured and parsed to obtain multiple test information groups, including: The original test requirement text is logically segmented to obtain multiple test requirement text paragraphs; Perform the following operation on each of the multiple test requirement text paragraphs: The test requirement text paragraph is segmented into words to obtain segmented paragraphs; Part-of-speech tagging is performed on segmented paragraphs to obtain part-of-speech tagged paragraphs; The test object information and test operation information were identified based on the part-of-speech tagging of the paragraphs. Syntactic extraction is performed on the part-of-speech tagged paragraphs to obtain precondition information and expected result information; The test information group is obtained by summarizing the test object information, test operation information, precondition information and expected result information; The test information groups are aggregated to obtain multiple test information groups.

4. The automated test case generation method based on markup language as described in claim 3, characterized in that, The test logic relationship information identified based on multiple test information groups includes: Extract the first from multiple test information groups The test information group and the first There are 1 test information group, among which... The initial value is 1; For the The expected results information in the test information group, the first Test operation information in the test information group and the first Dependency analysis is performed on the precondition information in each test information group to obtain the relationship analysis results, where the relationship analysis results are: dependent or not dependent; If the relation analysis result is dependency, then in the first... The test information group and the first Establish sequential execution relationships between test information groups to obtain sequential execution relationship groups; If the relational analysis result is independent, then let ,Will As Returning to the extraction of the first from multiple test information groups The test information group and the first The steps for each test information group are repeated until the relational analysis results show a dependency. make ,Will As Returning to the extraction of the first from multiple test information groups The test information group and the first The steps for each test information group, until... By summarizing the aforementioned sequential execution relationship groups, multiple sequential execution relationship groups are obtained, among which... The number of test information groups in multiple test information groups; Randomly extract prerequisite information from multiple test information groups to obtain target prerequisite information; Based on the target prerequisite information and multiple test information groups, several relevant test information groups were identified; Extracting the first from multiple related test information groups The relevant test information group and the first There are several related test information groups, among which... The initial value is 1; Based on the Test operation information in each relevant test information group and the first The test operation information in each relevant test information group confirms the mutual exclusion determination result, where the mutual exclusion determination result is: mutually exclusive or not mutually exclusive; If the mutual exclusion determination result is mutual exclusion, then in the... The relevant test information group and the first Establish branch selection relationships among relevant test information groups to obtain branch selection relationship groups; If the mutual exclusion determination result is that they are not mutually exclusive, then let ,Will As Returning to the extraction of the first from multiple related test information groups The relevant test information group and the first The steps for each relevant test information group continue until the mutual exclusion determination result is mutual exclusion; make ,Will As Returning to the extraction of the first from multiple related test information groups The relevant test information group and the first The steps for each relevant test information group, until... By summarizing the aforementioned branch selection relationship groups, multiple branch selection relationship groups are obtained, among which... The number of related test information groups in multiple related test information groups; The multiple sequential execution relationship groups and the multiple branch selection relationship groups are integrated to obtain test logic relationship information.

5. The automated test case generation method based on markup language as described in claim 4, characterized in that, The first The expected results information in the test information group, the first Test operation information in the test information group and the first Dependency analysis was performed on the precondition information in each test information group to obtain the relationship analysis results, including: For the first The expected results information in the test information group, the first Test operation information in the test information group and the first Keyword extraction is performed on the precondition information in each test information group to obtain the first keyword set, the second keyword set, and the third keyword set. The dependency score is calculated based on the first set of keywords, the second set of keywords, and the third set of keywords, using the following formula: in, Indicates dependency rating. Represents the set of first keywords. Represents the set of second keywords. Represents the third set of keywords. Denotes the cardinality of a set. Indicates intersection, Represents the union; Compare the dependency score with the preset dependency threshold. If the dependency score is greater than or equal to the dependency threshold, the relationship analysis result is determined to be a dependency. If the dependency score is less than the dependency threshold, the relationship analysis result is determined to be non-dependent.

6. The automated test case generation method based on markup language as described in claim 5, characterized in that, The verification of the markup language document to obtain the document verification result includes: Perform syntax validation on the markup language document and obtain the syntax validation result, where the syntax validation result is: syntax passed or syntax failed; Perform semantic integrity verification on the markup language document to obtain the semantic verification result, where the semantic verification result is: semantic integrity passed or semantic integrity failed; Perform logical consistency verification on the markup language document to obtain the logical verification result, where the logical verification result is: logical pass or logical fail; If the syntax validation result is "grammar passed", the semantic validation result is "semantic passed", and the logic validation result is "logic passed", then set the document validation result to "validation passed". Otherwise, set the document validation result to "validation failed".

7. The automated test case generation method based on markup language as described in claim 6, characterized in that, The process topology diagram is determined based on multiple operation instructions, multiple parameter constraints, multiple process logic information, and multiple data dependency information, including: For each of the multiple operation instructions, perform the following operation: The operation node is confirmed based on the operation command; The parameter constraint corresponding to the operation instruction among multiple parameter constraints is taken as the target parameter constraint; The number of constraints is determined based on the target parameter constraints; The data dependency information corresponding to the operation instruction among multiple data dependency information is taken as the target data dependency information; The number of dependencies is determined based on the target data dependency information; The structural complexity is calculated based on the number of constraints and dependencies, as shown in the following formula: in, Indicates structural complexity. Indicates the number of constraints. Indicates the number of dependencies. Represents the natural logarithm. The maximum number of constraints is preset. By binding structural complexity, target parameter constraints, and target data dependency information to operation nodes, the target node is obtained; Summarize the target nodes to obtain multiple target nodes; The process topology diagram was determined based on multiple target nodes and multiple process logic information.

8. The automated test case generation method based on markup language as described in claim 7, characterized in that, The process topology diagram identifies multiple target test scenarios, including: Branch nodes are identified in the process topology diagram to obtain multiple branch nodes; Perform the following operation on each of the multiple branch nodes: Multiple node branch paths were identified based on the branch nodes and the process topology diagram; Summarize the branch paths from multiple nodes to obtain a set of branch paths; The branch path set is combined to obtain multiple complete test paths; Perform the following operation for each of the multiple complete test paths: Multiple target nodes were identified based on the complete test path; Based on multiple target nodes, the number of key nodes, total complexity, and total number of nodes were determined. The overall priority score of the path is calculated based on the number of key nodes, the total complexity, and the total number of nodes. The overall priority scores of the paths are summarized to obtain the overall priority scores of multiple paths. Based on the comprehensive priority scoring of multiple paths, multiple complete test paths for the targets were identified; The complete test path for multiple targets is used as a test scenario for multiple targets.

9. The automated test case generation method based on markup language as described in claim 8, characterized in that, The sequence of test steps determined based on the target test scenario includes: Nodes are extracted from the complete test path corresponding to the target test scenario to obtain multiple target nodes; Perform the following operation on each of the multiple target nodes: Based on the target node, the first target parameter constraints and the first target data dependency information are identified. The first target parameter constraints and the first target data dependency information are instantiated to obtain executable test steps; Summarize the executable test steps to obtain multiple executable test steps; Multiple executable test steps are categorized to obtain a set of environment preparation steps, a set of operation execution steps, and a set of result verification steps. The test step sequence was determined based on the set of environmental preparation steps, the set of operation execution steps, and the set of result verification steps.

10. An automated test case generation system based on a markup language, characterized in that, The system includes: The initial text processing module is used to obtain the original test requirement text, write the original test requirement text in markup language to obtain the test requirement information, parse the test requirement information to obtain multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information, among which the operation instructions, parameter constraints, process logic information and data dependency information are all one-to-one correspondences. The target scenario acquisition module is used to identify the process topology based on multiple operation instructions, multiple parameter constraints, multiple process logic information and multiple data dependency information, and to identify multiple target test scenarios based on the process topology. The test step confirmation module is used to perform the following operations for each of the multiple target test scenarios: confirm the test step sequence based on the target test scenario, wherein the test step sequence includes: environment preparation step set, operation execution step set, and result verification step set; The test case generation module is used to generate sub-test cases based on the environment preparation step set, operation execution step set, and result verification step set in the test step sequence. It then summarizes the sub-test cases to obtain multiple sub-test cases, thus completing the automated test case generation.

Images