A method for generating appium scripts from annotated variants

Abstract

The application is a method for generating Appium script from annotated variations, adding annotations to an Appium script code in a specific syntax to express the number of repetitions of a certain script line and variable requirements; inputting the annotated script into Xtext syntax to generate an Xtext syntax tree; inputting the Xtext syntax tree into Xtend code to process different components differently, and finally generating a new Appium script that meets the user's requirements expressed in the annotations. The application mainly consists of three parts: Appium script code annotation syntax, Xtext syntax for parsing annotated scripts, and Xtend syntax for generating new scripts from Xtext syntax trees. The application realizes the generation of a large number of similar codes from the original code with simple annotations, effectively solving the time-consuming and laborious problem of writing a large number of similar test scripts.

Description

Technical Field

[0001] This invention relates to the fields of software engineering and language technology, and in particular to a method for generating Appium scripts from annotation mutations. Background Technology

[0002] For software testing engineers, performing numerous similar but distinct tests on code is a frequent task. This often results in a significant time commitment spent writing test scripts. Similarly, machine learning research frequently requires large amounts of data for training. Researchers also face the challenge of writing repetitive code or scripts to provide training samples. Therefore, a tool that can quickly generate such scripts is essential.

[0003] Appium is a commonly used automated testing framework for mobile applications, supporting automation of native, mobile web, and hybrid applications on iOS, Android, and Windows desktop platforms. Users can write automated test scripts based on Appium to simulate actions such as clicks, gestures, and input for automated code testing.

[0004] Xtext is a plugin tool for Eclipse that allows users to define their own text-based, domain-specific language and create custom programming languages. We designed annotations with a specific syntax that Xtext can recognize and parse to extract user requirements, thereby automatically generating large batches of scripts. Summary of the Invention

[0005] The purpose of this invention is to leverage a domain-specific language to generate new Appium scripts that are similar to but not identical to the original scripts, based on an existing set of Appium scripts, by annotating these scripts with specific syntax. This invention proposes a method for generating Appium scripts through annotation mutation. A special annotation representing user requirements is designed and input into the Xtext grammar to obtain a corresponding parsing tree. This parsing tree is then input into the accompanying Xtend code for step-by-step parsing, resulting in new Appium scripts that meet user requirements. This helps testers conduct more comprehensive testing or obtains large amounts of training data for machine learning purposes.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A method for generating Appium scripts from annotation mutations, characterized by comprising the following steps:

[0008] Step A: Design specific keywords and syntax to represent the user's variation requirements for the script, and add annotations to the existing Appium script according to the user's requirements and certain syntax.

[0009] Step B: Design the Xtext grammar, which can accept the script from Step A as input and output its corresponding parsing tree;

[0010] Step C: Design Xtend code to parse and convert the syntax analysis book obtained in Step B;

[0011] Step D: Complete the annotation attachment for the Appium script according to the requirements of Step A, and use the new script as the input of the program to generate a brand new Appium script that meets the user's requirements.

[0012] The above-described method for generating Appium scripts from annotation mutations is characterized in that, in step A, specific keywords and syntax are set to represent the user's mutation requirements for the script. The implementation process includes the following steps:

[0013] Step A1: Specify a section of code at the beginning of the file that starts with '#@module start{config}' and ends with '#@module end{config}' to indicate that no changes are needed in this script, representing import information or initial variable design.

[0014] Step A2: Define a string that begins with '#@tree' followed by a pair of parentheses containing several letters and numbers to represent the folder structure;

[0015] Step A3: It is stipulated that code can exist that starts with '#@modulestart xxx' and ends with '#@moduleend xxx', where xxx represents that it can be named arbitrarily, to indicate that this script is a module named xxx;

[0016] Step A4: Define that each line of original script can be transformed into a script block consisting of any number of comment lines and one script line. The script line serves as the basic template for the newly generated script, while the comment lines are used to mark the requirements and characteristics of the new script. It is agreed that when a script line has no comment line, the original script line will remain unchanged in the new script.

[0017] Step A5: Specify the form of the function call for script behavior, and the variables can contain at most one integer variable;

[0018] Step A6: Specify that comment lines can be '#@once', meaning that the following script line will only appear once in the new script;

[0019] Step A7: Specify that comment lines can be '#@any', which means that the following script line will appear 1 to 10 times in the new script;

[0020] Step A8: Specify that comment lines can be '#@optional', meaning that the following script lines will be generated 0 to 10 times in the new script;

[0021] Step A9: Specify that comment lines can begin with '#@param' to indicate variable changes required in subsequent script lines;

[0022] Step A10: The comment line can be in the form of '#@param(x:int / string)', where x represents any number, int / string represents int or string, and the 'x:int / string' part can be repeated multiple times with commas as separators. The meaning of this line is that the (x+1)th variable in the following script line should be changed to any variable of type int or string.

[0023] Step A11: Specify that the comment line can be in the form of '#@param(x:int:<3)', indicating that the generated integer variable must be less than 3, supporting 5 requirements: <, >, <=, >=, = (less than, greater than, less than or equal to, greater than or equal to, equal to).

[0024] Step A12: Specify that the comment line can be in the form of '#@param(x:string:***.abc)', indicating that the generated string variable should be in the form of ***.abcd (*** represents any number or letter character), which can be used to generate filenames in batches;

[0025] Step A13: When multiple comment lines exist, if they conflict with each other, the comment line closest to the script line shall prevail;

[0026] Step A14: Specify that the comment line can be '#@out xxx', where xxx is the name of an existing module, indicating that the code related to this module is required to be output. If such an annotation exists in the code, the output module will be based on the requirements of this annotation; otherwise, the converted code of all modules will be output.

[0027] Step A15: In accordance with the provisions of steps A1-A14, annotate the existing Appium script to generate a new script as the input for step B.

[0028] The above-described method for generating Appium scripts from annotation mutations is characterized in that, in step B, an Xtext grammar is designed to parse the script with specific annotations in step A into a syntax tree. The implementation process includes the following steps:

[0029] Step B1: Design a non-terminal symbol Script to represent the entire script, which contains four components: config, treeStruct, modulelist, and outputlist;

[0030] Step B2: Design the non-terminal symbol Config and the terminal symbol ConfigContent to represent the unchanging part at the very beginning of the script;

[0031] Step B3: Design the non-terminal symbol Treestruct and the terminal symbol Treelayout to represent the part of the script that represents the folder structure;

[0032] Step B4: Design a non-terminal symbol Module to represent the script of a module, which begins with ModulePrefix, ends with ModuleSuffix, and is in between ModuleContent;

[0033] Step B5: Design the terminators ModulePrefix and ModuleSuffix. ModulePrefix is ​​'#@modulestart xxx', where xxx is any string representing the module name. ModuleSuffix is ​​'#@moduleendxxx', where xxx is the module name in the corresponding ModulePrefix. Both represent the beginning and end of the module.

[0034] Step B6: Design a non-terminal symbol ModuleContent to represent the module content, which contains several ScriptBlocks;

[0035] Step B7: Design the non-terminal symbol ScriptBlock to represent a script block, specifically in the form of several lines of annotations plus one line of code, including two parts: AnnotationLine and ScriptLine;

[0036] Step B8: Design non-terminal annotation lines, including four annotation line formats: OPTIONAL, ONCE, ANY, or AnnoParam;

[0037] Step B9: Design the terminal symbols OPTIONAL, ONCE, ANY to indicate the number of times the script line appears. Specifically, they are '#@optional', '#@once', or '#@any';

[0038] Step B10: Design a non-terminal symbol AnnoParam to represent the annotation line related to the variable requirement. It contains a terminal symbol INT, which is an integer representing the variable position; a terminal symbol PARAM_TYPE, which can be converted to 'int' or 'string' to represent the required variable type; and a series of non-terminal symbols Claim to represent the required variable requirements.

[0039] Step B11: Design a non-terminal symbol Claim, which can be converted into StringClaim or Operator. StringClaim represents a description related to string requirements, and Operator represents a description related to integer requirements.

[0040] Step B12: Design the terminal symbol Outputmodule to indicate the output requirement, specifically '#out xxx', where xxx is the name of the existing module.

[0041] The above-described method for generating Appium scripts from annotation mutations is characterized in that the implementation process of designing the Xtend code in step C, which can parse the output of the Xtext grammar and correspond to the Xtext in step B, includes the following steps:

[0042] Step C1: Obtain the Config content and directly add it to the final result;

[0043] Step C2: Obtain the contents of Treestruct and determine if they meet the syntax requirements. If they do, use them as the folder structure; otherwise, use the default contents as the folder structure.

[0044] Step C3: Obtain the contents of modulelist and perform subsequent processing on each module;

[0045] Step C4: Get the moduleprefix from the module, get the module name, and check if it is duplicated. If it is not duplicated, add the module to the recorded module list; otherwise, use the new module with the same name to overwrite the old record.

[0046] Step C5: Obtain the modulecontent from the module and read its contents, which should be a series of scriptblock code blocks organized as a list;

[0047] Step C6: For each scriptblock, read all its annotation lines and its scriptline;

[0048] Step C7: For each annotation line, record its content in the data structure according to its content. If the content conflicts with the previous record, the previous content will be overwritten; otherwise, they will coexist.

[0049] Step C8: For each line of code (scriptline), parse its function name and parameter list;

[0050] Step C9: Based on the annotation records, function names, and parameter lists obtained in steps C7 and C8, after steps such as obtaining a random string, obtaining a random number, and string concatenation, a new code segment is obtained from the transformation of this line of code.

[0051] Step C10: Parse the outputlist module and concatenate the code according to the requirements. If there are no requirements, concatenate all the code from step C9 to obtain the final output.

[0052] The above-described method for generating Appium scripts from annotation mutations is characterized in that the implementation process of obtaining the Appium script that meets user requirements in step D includes the following steps:

[0053] Step D1: Create a new folder named src in the editor generated by Xtext;

[0054] Step D2: Place the annotated script that was finally written in step A into the src folder, with the script name ending in '.dmodel';

[0055] Step D3: A new script will appear in the src-gen folder, with the default name '1.py';

[0056] Step D4: Complete the generation of the new Appium script.

[0057] This invention combines automated testing methods with domain-specific language tools to generate a large number of similar code from original code with simple annotations. This saves software testers and machine learning researchers a significant amount of time by directly generating a large number of test scripts, effectively solving the problem of the time-consuming and laborious process of writing a large number of similar test scripts. Attached Figure Description

[0058] Figure 1 This is an overall flowchart of an embodiment of the present invention.

[0059] Figure 2 This is a schematic diagram of the Xtext grammar structure in an embodiment of the present invention.

[0060] Figure 3 This is a schematic diagram of the Xtend code function in an embodiment of the present invention.

[0061] Figure 4 This is a schematic diagram of an Appium script with annotations in an embodiment of the present invention. Detailed Implementation

[0062] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0063] Figure 1 This is an overall flowchart of an embodiment of the present invention. The purpose of this invention is to provide a method for generating Appium scripts from annotation mutations. This method, based on the existing version of the Appium script code, mainly consists of three parts: Appium script code annotation syntax, Xtext syntax that can parse the annotated script, and Xtend syntax that corresponds to the Xtext syntax and can generate a new script by parsing the syntax tree generated from the Xtext. This achieves the generation of a large number of similar code from the original code with simple annotations, effectively solving the problem of the time-consuming and laborious process of writing a large number of similar test scripts. Figure 1 As shown, the present invention includes the following steps:

[0064] Step A: Design specific keywords and syntax to represent the user's variation requirements for the script, and add annotations to the existing Appium script according to the user's requirements and certain syntax.

[0065] Step B: Design the Xtext grammar, which can accept the script from Step A as input and output its corresponding parsing tree;

[0066] Step C: Design Xtend code to parse and convert the syntax analysis book obtained in Step B;

[0067] Step D: Complete the annotation attachment for the Appium script according to the requirements of Step A, and use the new script as the input of the program to generate a brand new Appium script that meets the user's requirements.

[0068] The annotation specification designed in step A, consisting of specific keywords and syntax, can represent the user's variation requirements for the script. The design includes the following sub-steps:

[0069] Step A1: Specify a section of code at the beginning of the file that starts with '#@module start{config}' and ends with '#@module end{config}' to indicate that no changes are needed in this script, representing import information or initial variable design.

[0070] Step A2: Define a string that begins with '#@tree' followed by a pair of parentheses containing several letters and numbers to represent the folder structure;

[0071] Step A3: It is stipulated that code can exist that starts with '#@modulestart xxx' and ends with '#@moduleend xxx', where xxx represents that it can be named arbitrarily, to indicate that this script is a module named xxx;

[0072] Step A4: Define that each line of original script can be transformed into a script block consisting of any number of comment lines and one script line. The script line serves as the basic template for the newly generated script, while the comment lines are used to mark the requirements and characteristics of the new script. It is agreed that when a script line has no comment line, the original script line will remain unchanged in the new script.

[0073] Step A5: Specify the form of the function call for script behavior, and the variables can contain at most one integer variable;

[0074] Step A6: Specify that comment lines can be '#@once', meaning that the following script line will only appear once in the new script;

[0075] Step A7: Specify that comment lines can be '#@any', which means that the following script line will appear 1 to 10 times in the new script;

[0076] Step A8: Specify that comment lines can be '#@optional', meaning that the following script lines will be generated 0 to 10 times in the new script;

[0077] Step A9: Specify that comment lines can begin with '#@param' to indicate variable changes required in subsequent script lines;

[0078] Step A10: The comment line can be in the form of '#@param(x:int / string)', where x represents any number, int / string represents int or string, and the 'x:int / string' part can be repeated multiple times with commas as separators. The meaning of this line is that the (x+1)th variable in the following script line should be changed to any variable of type int or string.

[0079] Step A11: Specify that the comment line can be in the form of '#@param(x:int:<3)', indicating that the generated integer variable must be less than 3, supporting 5 requirements: <, >, <=, >=, = (less than, greater than, less than or equal to, greater than or equal to, equal to).

[0080] Step A12: Specify that the comment line can be in the form of '#@param(x:string:***.abc)', indicating that the generated string variable should be in the form of ***.abcd (*** represents any number or letter character), which can be used to generate filenames in batches;

[0081] Step A13: When multiple comment lines exist, if they conflict with each other, the comment line closest to the script line shall prevail;

[0082] Step A14: Specify that the comment line can be '#@out xxx', where xxx is the name of an existing module, indicating that the code related to this module is required to be output. If such an annotation exists in the code, the output module will be based on the requirements of this annotation; otherwise, the converted code of all modules will be output.

[0083] Step A15: In accordance with the provisions of steps A1-A14, annotate the existing Appium script to generate a new script as the input for step B.

[0084] like Figure 2 As shown, Figure 2 This is a schematic diagram of the Xtext grammar structure in an embodiment of the present invention. The designed Xtext grammar is used to parse the script with specific annotations in step A and output the corresponding syntax tree. The design process specifically includes the following steps:

[0085] Step B1: Design a non-terminal symbol Script to represent the entire script, which contains four components: config, treeStruct, modulelist, and outputlist;

[0086] Step B2: Design the non-terminal symbol Config and the terminal symbol ConfigContent to represent the unchanging part at the very beginning of the script;

[0087] Step B3: Design the non-terminal symbol Treestruct and the terminal symbol Treelayout to represent the part of the script that represents the folder structure;

[0088] Step B4: Design a non-terminal symbol Module to represent the script of a module, which begins with ModulePrefix, ends with ModuleSuffix, and is in between ModuleContent;

[0089] Step B5: Design the terminators ModulePrefix and ModuleSuffix. ModulePrefix is ​​'#@modulestart xxx', where xxx is any string representing the module name. ModuleSuffix is ​​'#@moduleendxxx', where xxx is the module name in the corresponding ModulePrefix. Both represent the beginning and end of the module.

[0090] Step B6: Design a non-terminal symbol ModuleContent to represent the module content, which contains several ScriptBlocks;

[0091] Step B7: Design the non-terminal symbol ScriptBlock to represent a script block, specifically in the form of several lines of annotations plus one line of code, including two parts: AnnotationLine and ScriptLine;

[0092] Step B8: Design non-terminal annotation lines, including four annotation line formats: OPTIONAL, ONCE, ANY, or AnnoParam;

[0093] Step B9: Design the terminal symbols OPTIONAL, ONCE, ANY to indicate the number of times the script line appears. Specifically, they are '#@optional', '#@once', or '#@any';

[0094] Step B10: Design a non-terminal symbol AnnoParam to represent the annotation line related to the variable requirement. It contains a terminal symbol INT, which is an integer representing the variable position; a terminal symbol PARAM_TYPE, which can be converted to 'int' or 'string' to represent the required variable type; and a series of non-terminal symbols Claim to represent the required variable requirements.

[0095] Step B11: Design a non-terminal symbol Claim, which can be converted into StringClaim or Operator. StringClaim represents a description related to string requirements, and Operator represents a description related to integer requirements.

[0096] Step B12: Design the terminal symbol Outputmodule to indicate the output requirement, specifically '#out xxx', where xxx is the name of the existing module.

[0097] like Figure 3 As shown, Figure 3This is a schematic diagram of the Xtend code functionality in an embodiment of the present invention. The designed Xtend code can parse the syntax analysis tree output in step B and generate a corresponding new Appium script. The design of the Xtend code includes the following sub-steps:

[0098] Step C1: Obtain the Config content and directly add it to the final result;

[0099] Step C2: Obtain the contents of Treestruct and determine if they meet the syntax requirements. If they do, use them as the folder structure; otherwise, use the default contents as the folder structure.

[0100] Step C3: Obtain the contents of modulelist and perform subsequent processing on each module;

[0101] Step C4: Get the moduleprefix from the module, get the module name, and check if it is duplicated. If it is not duplicated, add the module to the recorded module list; otherwise, use the new module with the same name to overwrite the old record.

[0102] Step C5: Obtain the modulecontent from the module and read its contents, which should be a series of scriptblock code blocks organized as a list;

[0103] Step C6: For each scriptblock, read all its annotation lines and its scriptline;

[0104] Step C7: For each annotation line, record its content in the data structure according to its content. If the content conflicts with the previous record, the previous content will be overwritten; otherwise, they will coexist.

[0105] Step C8: For each line of code (scriptline), parse its function name and parameter list;

[0106] Step C9: Based on the annotation records, function names, and parameter lists obtained in steps C7 and C8, after steps such as obtaining a random string, obtaining a random number, and string concatenation, a new code segment is obtained from the transformation of this line of code.

[0107] Step C10: Parse the outputlist module and concatenate the code according to the requirements. If there are no requirements, concatenate all the code from step C9 to obtain the final output.

[0108] like Figure 4 As shown, Figure 4This is a schematic diagram of an annotated Appium script in an embodiment of the present invention. In step D, annotations are added to the Appium script according to the requirements in step A, and the new script is used as input to the program to obtain a brand-new Appium script that meets the user's requirements. Specifically, this includes the following steps:

[0109] Step D1: Create a new folder named src in the editor generated by Xtext;

[0110] Step D2: Place the annotated script that was finally written in step A into the src folder, with the script name ending in '.dmodel';

[0111] Step D3: A new script will appear in the src-gen folder, with the default name '1.py';

[0112] Step D4: Complete the generation of the new Appium script.

[0113] The above descriptions are embodiments of the present invention, but the specific embodiments described herein are merely illustrative and not intended to limit the invention. Any omissions, modifications, or equivalent substitutions made within the scope of the claims of this invention without departing from the principles and spirit of the invention should be included within the protection scope of this disclosure.

Claims

1. A method for generating Appium scripts from annotation mutations, characterized in that, Includes the following steps: Step A: Design specific keywords and syntax to represent the user's variation requirements for the script, and add annotations to the existing Appium script according to the user's requirements and certain syntax. Step A involves setting specific keywords and syntax to represent the user's requirements for script variation. The implementation process includes the following steps: Step A1: Specify a section of code at the beginning of the file that starts with '#@module start {config}' and ends with '#@module end {config}'. This indicates that no changes are needed in this script and represents the import information or initial variable design. Step A2: Define a string that begins with '#@tree' followed by a pair of parentheses containing several letters and numbers to represent the folder structure; Step A3: Specify that there exists code that starts with '#@modulestart xxx' and ends with '#@moduleend xxx', where xxx represents any name, to indicate that this script is a module named xxx; Step A4: Define that each line of original script can be transformed into a script block consisting of any number of comment lines and one script line. The script line serves as the basic template for the newly generated script, while the comment lines are used to mark the requirements and characteristics of the new script. It is agreed that when a script line has no comment line, the original script line will remain unchanged in the new script. Step A5: Specify the form of the function call for script behavior, and the variables can contain at most one integer variable; Step A6: Specify that comment lines can be '#@once', meaning that the following script line will only appear once in the new script; Step A7: Specify that comment lines can be '#@any', which means that the following script line will appear 1 to 10 times in the new script; Step A8: Specify that comment lines can be '#@optional', meaning that the following script lines will be generated 0 to 10 times in the new script; Step A9: Specify that comment lines can begin with '#@param' to indicate variable changes required in subsequent script lines; Step A10: Specify that the comment line can be in the form of '#@param(x:int / string)', where x represents any number, int / string represents int or string, and the 'x:int / string' part is repeated multiple times when separated by commas. This line means that the (x+1)th variable in the following script line should be changed to any variable of type int or string. Step A11: Specify that the comment line can be in the form of '#@param(x:int:<3)', indicating that the generated integer variable must be less than 3, supporting 5 requirements: <, >, <=, >=, = (less than, greater than, less than or equal to, greater than or equal to, equal to). Step A12: Specify that the comment line can be in the form of '#@param(x:string:***.abc)', indicating that the generated string variable should be in the form of ***.abcd, where *** represents any number or letter character, used for batch generating filenames; Step A13: When multiple comment lines exist, if they conflict with each other, the comment line closest to the script line shall prevail; Step A14: Specify that the comment line can be '#@out xxx', where xxx is the name of an existing module, indicating that the code related to this module is required to be output. If such an annotation exists in the code, the output module will be based on the requirements of this annotation; otherwise, the converted code of all modules will be output. Step A15: According to the provisions of steps A1-A14, annotate the original Appium script to generate a new script as the input for step B; Step B: Design the Xtext grammar, which takes the script from Step A as input and outputs its corresponding parsing tree; Step C: Design Xtend code to parse and convert the syntax analysis book obtained in Step B; Step D: Complete the annotation attachment for the Appium script according to the requirements of Step A, and use the new script as the input of the program to generate a brand new Appium script that meets the user's requirements.

2. The method for generating Appium scripts from annotation mutations according to claim 1, characterized in that, In step B, the Xtext grammar is designed to parse the script with specific annotations in step A into a syntax tree. The implementation process includes the following steps: Step B1: Design a non-terminal symbol Script to represent the entire script, which contains four components: config, treeStruct, modulelist, and outputlist; Step B2: Design the non-terminal symbol Config and the terminal symbol ConfigContent to represent the unchanging part at the very beginning of the script; Step B3: Design the non-terminal symbol Treestruct and the terminal symbol Treelayout to represent the part of the script that represents the folder structure; Step B4: Design a non-terminal symbol Module to represent the script of a module, which begins with ModulePrefix, ends with ModuleSuffix, and is in between ModuleContent; Step B5: Design the terminators ModulePrefix and ModuleSuffix. ModulePrefix is ​​'#@modulestartxxx', where xxx is any string representing the module name. ModuleSuffix is ​​'#@moduleendxxx', where xxx is the module name in the corresponding ModulePrefix. Both represent the beginning and end of the module. Step B6: Design a non-terminal symbol ModuleContent to represent the module content, which contains several ScriptBlocks; Step B7: Design the non-terminal symbol ScriptBlock to represent a script block, specifically in the form of several lines of annotations plus one line of code, including two parts: AnnotationLine and ScriptLine; Step B8: Design non-terminal annotation lines, including four annotation line formats: OPTIONAL, ONCE, ANY, or AnnoParam; Step B9: Design the terminal symbols OPTIONAL, ONCE, ANY to indicate the number of times the script line appears, specifically '#@optional', '#@once', or '#@any'; Step B10: Design a non-terminal symbol AnnoParam to represent the annotation line related to the variable requirement. It includes a terminal symbol INT, which is an integer representing the variable position; a terminal symbol PARAM_TYPE, which can be converted to 'int' or 'string' to represent the required variable type; and a series of non-terminal symbols Claim, representing the required variable requirements. Step B11: Design a non-terminal symbol Claim and convert it into StringClaim or Operator. The StringClaim represents a description related to string requirements, and the Operator represents a description related to integer requirements. Step B12: Design the terminal symbol Outputmodule to indicate the output requirement, specifically '#out xxx', where xxx is the name of the existing module.

3. The method for generating Appium scripts from annotation mutations according to claim 1, characterized in that, The implementation process of designing the Xtend code in step C, which can parse the output of the Xtext grammar and correspond to the Xtext in step B, includes the following steps: Step C1: Obtain the Config content and directly add it to the final result; Step C2: Obtain the contents of Treestruct and determine if they meet the syntax requirements. If they do, use them as the folder structure; otherwise, use the default contents as the folder structure. Step C3: Obtain the contents of modulelist and perform subsequent processing on each module; Step C4: Get the moduleprefix from the module, get the module name, and check if it is duplicated. If it is not duplicated, add the module to the recorded module list; otherwise, use the new module with the same name to overwrite the old record. Step C5: Obtain the modulecontent from the module and read its contents, which should be a series of scriptblock code blocks organized as a list; Step C6: For each scriptblock, read all its annotation lines and its scriptline; Step C7: For each annotation line, record its content in the data structure according to its content. If the content conflicts with the previous record, the previous content will be overwritten; otherwise, they will coexist. Step C8: For each line of code (scriptline), parse its function name and parameter list; Step C9: Based on the annotation records, function names, and parameter lists obtained in steps C7 and C8, after steps such as obtaining a random string, obtaining a random number, and string concatenation, a new code segment is obtained from the transformation of this line of code. Step C10: Parse the outputlist module and concatenate the code according to the requirements. If there are no requirements, concatenate all the code from step C9 to obtain the final output result.

4. The method for generating Appium scripts from annotation mutations according to claim 1, characterized in that, The process of obtaining the Appium script that meets the user's requirements in step D includes the following steps: Step D1: Create a new folder named src in the editor generated by Xtext; Step D2: Place the annotated script that was finally written in step A into the src folder, with the script name ending in '.dmodel'; Step D3: A new script will appear in the src-gen folder, with the default name '1.py'; Step D4: Complete the generation of the new Appium script.

Images