Description language for functional properties of mobile application software and application of description language

Abstract

The invention discloses a description language for functional properties of mobile application software, which comprises the following steps of: initialization setting of a mobile application: completing initialization operation and preliminary setting operation of the application according to the mobile application to be tested and a defined initialization function, the initialization operation is executed before the performance test is executed; applying preconditions of properties: setting one or more conditional statements for describing a software state required to be met before testing the functional properties of the software; setting an interaction scene of the application property: setting an operation sequence which should be executed by the application, wherein the sequence is used for simulating an interaction action between a user and application software; according to the to-be-tested property of the application, after any operation, namely when the user interface is in any state, assert assertions and post-condition clauses are set to complete post-condition verification; and if the assert statement is not established, indicating that the relevant property error of the application is found.

Description

Technical Field

[0001] The present invention belongs to the field of mobile platform automated testing technology and is a software function property description language designed for mobile platform testing technology based on software properties, which specifically helps technicians to realize an efficient and fast software function property definition process. Background Art

[0002] Mobile applications have been involved in all aspects of people's lives, providing convenient and effective help for people's daily lives. Users often attach great importance to the practicality of applications, so major companies are trying their best to ensure the quality and reliability of applications. However, due to problems such as test prediction, applications are still not fully tested. A recent empirical study shows that non-crash functional errors account for a large proportion of mobile application errors (about 65.4%), so how to effectively ensure the functional correctness of mobile applications is a critical issue.

[0003] Manual testing is one of the most common methods for verifying functional correctness and usually involves writing graphical user interface (GUI) tests or directly interacting with the application. In this process, testers compare expected application behavior (e.g., defined by assertions in GUI tests) with actual behavior to identify potential inconsistencies or functional errors. However, manual testing is often costly and has limited coverage, usually only touching the main paths of the application and may miss some critical functional errors. On the other hand, automated GUI testing techniques are good at automatically exploring applications, but are usually limited in finding functional errors due to the lack of test oracles. Summary of the invention

[0004] The goal of the present invention is to design a software functional property description language to simply and quickly define the properties of the mobile application to be tested, and the content of the property description includes but is not limited to initialization operations, preconditions, interaction scenarios and postconditions. This makes it easy for the post-sequence automation tool to generate a large number of random event traces to verify whether the application meets the required properties. These event traces drive the application to output different application states (such as GUI pages). According to whether the states of these outputs match the defined properties, the present invention can verify whether the property is normal.

[0005] The description language of the functional properties of mobile application software proposed in the present invention comprises the following steps:

[0006] Step 1: Initialization setting of mobile application: define initialization function according to the functional properties of the mobile application to be tested, complete the initialization operation and preliminary setting operation of the application, and the initialization operation is completed before performing the property test;

[0007] Step 2, setting of preconditions for application properties: The description language of the present invention helps technicians to concisely set one or more conditional statements for describing the software status that needs to be met before testing the functional properties of the software.

[0008] Step 3, interactive scenario setting of application properties: technicians can use the description language of the present invention to set the sequence of operations that the application should perform, which is used to simulate the interactive actions between the user and the application software. Finally, technicians can use the description language of the present invention to set the assertion and post-condition clause to complete the post-condition verification after any operation, that is, when the user interface is in any state, according to the properties to be tested by the application. If there is a situation where the assert statement is not established, it indicates that the relevant properties of the application are found to be wrong.

[0009] In step 1 of the present invention, the initialization settings of the mobile application are composed of the @initialize() decorator and the corresponding function. The technician can choose whether to set it according to the situation. If the tested application does not need any initialization operation, the technician can choose to skip this step and directly proceed to the subsequent property definition step. If you choose to perform initialization settings, the initialization content includes but is not limited to:

[0010] Skip the welcome interface of the application. When the application is first enabled, there will often be a welcome interface. In order not to affect the subsequent testing process, technicians can set the operation sequence in the initialization function to skip the welcome interface of the application.

[0011] Skip the login interface. Some applications may have a login interface when they are started. The technician needs to set the operation sequence in the initialization function to skip the login interface.

[0012] Pass some initial data to the application. The initial data of the application needed in the subsequent testing process can also be added by technicians in the initialization function.

[0013] In the present invention, the specific operation of the initialization function can be realized by configuring an external UI interaction tool, and the default tool of the present invention is uiautomator2. The technician can use other interaction tools by modifying the dsl.py configuration document.

[0014] In step 2 of the present invention, the precondition setting of the application property test is composed of the @precondition() decorator and one or more conditional clauses, and logical operators (such as not, and, or, etc.) are used to combine these clauses. These preconditions are used to determine whether the application has reached the requirements for starting to perform subsequent serialization operations by whether they are met.

[0015] In the present invention, the form of precondition (pred) includes: clause, not pred, pred or pred, predand pred, etc., which describe the application status. Clause represents a conditional judgment clause, not is a basic Boolean logic operator used to negate a Boolean value; and is used to judge whether two conditions are true at the same time, and the result is true only when both conditions are true; or is used to judge whether at least one of the two conditions is true, and the result is false only when both conditions are false.

[0016] The composition of the conditional judgment clause usually includes the value judgment of data variables, the number or value judgment of components, etc., including but not limited to:

[0017] The number of controls that meet a certain property in the current interface is greater than, less than, or equal to a specific number;

[0018] The other property values ​​of the controls that meet a certain property in the current interface are greater than, less than, or equal to a specific number;

[0019] The other property values ​​of the controls that meet a certain property in the current interface are equal to a Boolean constant or a string constant;

[0020] The value of a data variable is greater than, less than, or equal to a numeric constant;

[0021] The value of a data variable is equal to a Boolean constant or a string constant.

[0022] The application component related information required by the present invention is obtained. The present invention defaults to the interface of the uiautomator2 tool to achieve interaction with the mobile device, including component positioning through the selector, interface components and component properties and other data acquisition. The present invention supports technicians to modify the configuration file and use other tools to achieve interaction with the mobile device.

[0023] In step 3 of the present invention, the property setting of the application property test is composed of the @rule() decorator and related functions. The property setting mainly includes two aspects: the setting of the operation sequence and the post-condition assertion verification.

[0024] The operation sequence setting mainly includes but is not limited to: conditional statements, loop statements, arithmetic operations, function calls, and UI event execution. The execution of UI events is implemented by the interface of the uiautomator2 tool by default in the present invention. The present invention also supports technicians to use other tools to implement interactive work with mobile devices by modifying configuration files.

[0025] In terms of post-condition assertions, the technician sets one or more assert statements. The description language of the present invention is practical and is not limited to being added at the end of the execution sequence to check the termination state. The description language of the present invention can add assertions after any operation is executed to check whether a specific state meets the requirements, that is, set assertions when the user interface is in any state to complete the post-condition verification. If there is a situation where the assert statement is not established, it indicates that an error in the relevant properties of the application is found. If not, it indicates that no relevant property errors are found in this test. The composition of the conditional judgment statement is the same as the aforementioned conditional judgment clause.

[0026] The present invention also proposes an application of the above description language in defining software functional properties.

[0027] The invention of the description language has the following beneficial effects:

[0028] This description language can help technicians to quickly and conveniently define the properties of software functions, and at the same time help property-based automated testing tools to test a wider range of more practical software functional properties. Specifically, when using a property-based automated testing tool configured with this description language, in order to test the different properties of mobile applications, technicians only need to write a python file and use the @initialize() initialization decorator, @precondition() precondition decorator, and @rule() property decorator to complete the initialization operation of the application, the verification of whether the application property test preconditions are met, the design of the sequence of operations to be performed, and the assertion verification of the postconditions that should be met after the operation is performed. Finally, the technician selects the test application and test equipment and uses the property-based automated testing tool to start the automated testing of the relevant properties. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0030] Figure 1 It is a schematic diagram of the core grammar of the description language of the present invention.

[0031] Figure 2 is a schematic diagram of an embodiment of the present invention. DETAILED DESCRIPTION

[0032] The present invention is further described in detail with reference to the following specific embodiments and drawings. Except for the contents specifically mentioned below, the detailed processes and method tips of the present invention are common knowledge and common common sense in the art, and the present invention has no special restrictions.

[0033] The present invention discloses a description language (PDL) for the functional properties of mobile application software. In this language, the properties of mobile application software are composed of three modules: precondition, interaction scenario, and postcondition, which are used to describe the expected results of the mobile application software after executing certain operations under certain conditions. PDL uses one or more groups of decorators and function implementations to complete simple and fast software functional property definition operations. The precondition contains one or more conditional statements, which are used to describe the state that the software needs to meet before executing the property. This language uses an ordinary function of Python to describe the interactive scenario and postcondition of the software functional property, and then uses a decorator to decorate the function, indicating that the function is a property description of a software. In the interactive scenario, this language supports a rich API for defining a series of operation statements. This language uses assertions plus conditional clauses to describe the postconditions of the software functional properties, that is, the expected performance of the software after the interactive scenario is executed. PDL supports users to place assertion statements after any graphical user interface state to define postconditions to detect whether any state meets the requirements, and does not limit the assertion statement to be placed only after the entire interactive scenario is completed. The present invention is used to describe the functional properties of mobile application software and can be used for testing mobile application software.

[0034] The method for defining the functional properties of mobile application software proposed in the present invention helps technicians to effectively and conveniently define the properties to be tested for mobile applications. The definition process includes the following steps:

[0035] Step 1: Initialization of the mobile application: After deciding the nature and mobile application you want to test, define functions to complete the initialization of the application and some pre-test setup operations. These operations will be completed before performing the nature test.

[0036] Step 2: Precondition setting step for application property test: Set one or more conditional statements to let the automation tool determine whether the current state of the mobile application meets the relevant requirements of the property test. If not, the operation sequence of subsequent tests cannot be executed.

[0037] Step 3: Interaction scenario setting steps for application property testing: Set the sequence of operations that should be performed after the application meets the preconditions. That is, you can set a series of basic UI operations required to test the property of the application. Finally, according to the properties of the application to be tested, set one or more assert statements to determine the application status that should be satisfied after executing all or part of the operation sequence. If there is a situation where the assert statement is not true, it means that the relevant property of the application is found to be wrong.

[0038] The PDL of the present invention is a computer language designed based on Python language for the field of "mobile platform testing method based on software functional properties". PDL uses one or more groups of decorators and function implementations to complete simple and fast software functional property definition operations. It provides a broader and more comprehensive software functional property definition for automated testing tools to perform tests based on software functional properties.

[0039] The @initialize() decorator is used to initialize the function, which is responsible for performing necessary application initialization operations before the execution of automated tests.

[0040] The @precondition() decorator contains one or more conditional clauses, defining conditions that must be met by the GUI before an interactive operation can be performed.

[0041] The @rule() decorator is used to annotate software functional properties functions, which define various interactive operations and one or more assertions as post-condition verifications.

[0042] Step 1: Define the initialization operation of the mobile application, mainly using the @initialize() decorator and the defined initialization function to implement the initialization operation of the mobile application, such as skipping the welcome interface of the mobile application, skipping the login interface of the mobile application, passing some data to the application, etc. The execution content of the initialization function will be completed before the test is executed.

[0043] The initialization operation of the mobile application described in step 1 includes but is not limited to:

[0044] (1) Skip the welcome interface of the application. When an application is first enabled, it often displays a welcome interface. In order not to affect the subsequent testing process, you can set an operation sequence in the initialization function to skip the welcome interface of the application.

[0045] (2) Skip the login interface. Some applications may have a login interface when they are started. You need to set an operation sequence in the initialization function to skip the login interface.

[0046] (3) Pass some initial data to the application. The initial data of the application needed in the subsequent testing process can also be added in the initialization function.

[0047] If the application under test does not require any initialization operations, you can choose to skip this step and proceed directly to the subsequent property definition step.

[0048] The preconditions for the application property test described in step 2 are mainly implemented by using the @precondition() decorator with one or more conditional judgment clauses. Whether these preconditions are met is used to determine whether the application has met the requirements for starting serialization operations.

[0049] Step 2: The settings of the precondition list (pred) include but are not limited to:

[0050] (1)clause

[0051] (2) not pred

[0052] (3)pred or pred

[0053] (4) pred and pred

[0054] Among them, not is a logical operator, which is one of the basic Boolean logic operations. Its function is to negate the Boolean value. and is also a basic Boolean logic operator, which is often used in logical operations to determine whether two conditions are true at the same time. Only when the conditions on both sides of and are true at the same time, the clause is true. or is one of the basic Boolean logic operators, which is used to determine whether at least one of the two conditions is true. Only when both inputs are false, the result of the clause is false.

[0055] The clause represents a conditional judgment clause, which includes but is not limited to the following:

[0056] (1) The number of controls that meet a certain property in the current interface is greater than, less than, or equal to a specific number;

[0057] (2) The values ​​of other properties of the controls that meet a certain property in the current interface are greater than, less than, or equal to a specific number;

[0058] (3) The other property values ​​of the controls that meet a certain property in the current interface are equal to a Boolean constant or a string constant;

[0059] (4) The value of a data variable is greater than, less than, or equal to a certain numeric constant;

[0060] (5) The value of a data variable is equal to a Boolean constant or a string constant.

[0061] The interface components and component properties are acquired by default through the interface of the uiautomator2 tool to achieve interactive operation with the mobile device. In addition, the present invention supports the use of other tools to achieve interactive work with the mobile device by modifying the configuration file. Table 1 shows an example of some controls:

[0062] Table 1 Control type examples

[0063] Control Name Control Purpose Common scenarios TextView Display text content Title, paragraph, prompt information EditText Area where the user can enter text Username or password input box, search bar Button Click the button Submit, Save, Confirm, Cancel buttons ImageView Show image Display pictures, icons, user avatars CheckBox Checkbox Sets the options of the page, used when selecting multiple items RadioButton Radio Button Select gender, single choice questionnaire Switch Switch Control Turn notifications on or off, enable or disable features SeekBar Sliders Volume control, brightness adjustment

[0064] In the process of obtaining the corresponding components of the interface, you can use the corresponding selector to achieve it. Commonly used selectors are as follows:

[0065] ·text,textContains,textMatches,textStartsWith

[0066] ·className,classNameMatches,description,descriptionContains

[0067] ·checkable,checked,clickable,longClickable

[0068] ·scrollable,enabled,focusable,focused,selected

[0069] ·packageName,packageNameMatches

[0070] ·resourceId,resourceIdMatches

[0071] ·index,instance

[0072] The property setting of the application property test described in step 3 is mainly completed by using the @rule() decorator in conjunction with the defined function implementation. Set a series of basic UI operations required to test the property of the application in the function. Finally, according to the properties of the application to be tested, set one or more assert statements to determine the application status that should be satisfied after executing all or part of the operation sequence. If there is a situation where the assert statement is not true, it means that an error in the relevant properties of the application is found. If not, it means that no relevant property errors were found in this test, and the automated testing tool will further execute the relevant test process.

[0073] The execution sequence of step 3 includes but is not limited to:

[0074] (1) Conditional statements

[0075] (2) Loop statements

[0076] (3) Arithmetic operations

[0077] (4) Function call

[0078] (5) UI event execution

[0079] The execution of UI events is mainly achieved through the interface of the uiautomator2 tool to interact with the mobile device. The present invention also supports the use of other tools to interact with the mobile device by modifying the configuration file. Table 2 shows some common operations:

[0080] Table 2 Operation examples

[0081]

[0082]

[0083] Assert statements can be added after any operation is executed to check whether a specific state meets the requirements. In order to improve practicality, the present invention is not limited to adding it only at the end of the execution sequence to check only the termination state. One or more assert statements can be added. If all assertions pass normally, it proves that the test did not find any problems with the set properties.

[0084] The property setting of the application property test described in step 3 is mainly divided into two parts: execution sequence definition and post-condition assertion. The definition part of the execution sequence is mainly composed of set conditional statements, loop statements, arithmetic operations, function calls and UI event execution. Among them, the UI event part is completed using the object d of uiaotomator2. For example, d(resourceId="player_playback_button").click(), resourceID sets the number of the component to be operated, and click() transmits the click event to the component. The assertion part of the post-condition is mainly implemented using assertion. The assertion statement can be added after any operation is executed to check whether a specific state meets the requirements. The present invention does not limit it to being added at the end of the execution sequence to only check the termination state. If all assertions pass normally, it proves that this test did not find any problems with the set properties. If not, it means that no relevant property errors were found in this test, and the automated testing tool will further execute the relevant test process.

[0085] The present invention uses the corresponding selector by default through the interface of the uiautomator2 tool to realize the interaction with the mobile device and obtain the data such as the interface component and the component property. In addition, the interactive work with the mobile device can also be realized by modifying the configuration file dsl.py and carrying other tools.

[0086] Example

[0087] The complete PDL code of this embodiment is as follows Figure 2 As shown. This embodiment takes OmniNotes as the object, which is an application for recording and managing notes. The property selected in this embodiment is: after deleting a tag, the tag should be successfully deleted, and the annotation content of other tags should remain unchanged.

[0088] Step 1: Define the initialization operation of the mobile application. In this embodiment, the initialization function is set to skip the initialization interface of OmniNotes to prepare for the subsequent property-based test:

[0089]

[0090]

[0091] Its meaning is:

[0092] The first line is the decorator @initialize() for the initialization operation, which is used to decorate the following function, indicating that the function is an initialization function and will be executed before starting the test.

[0093] Lines 2-7 define the initialization function, which automatically skips the welcome interface of OmniNotes. Lines 4-5 skip the welcome interface in turn, and finally lines 6-7 click the OK button to enter the main interface of the application, and the initialization operation is completed.

[0094] Step 2, setting the preconditions for the application property test. In this embodiment, the object d of uiautomator2 is used to locate the component using resourceId:

[0095] @precondition(lambda self:d(resourceId="it.feio.android.omninotes:id / menu_tag").exists()and"#"in d(resourceId="it.feio.android.omninotes:id / detail_content").info["text"])

[0096] Use the @precondition() decorator to set the preconditions for the test. In this embodiment, the preconditions include: whether there is a component with resourceId as menu_tag in the interface, and whether the text content of the component with resourceId as detail_content contains "#" (i.e., whether the tag item already exists in the record). The two conditional clauses are connected by the logical operator and, indicating that the preconditions are met only when both conditions are met at the same time.

[0097] Step 3, property setting of the application property test. In this embodiment, a UI operation is used to delete an item in the tag list, and then determine whether the content of other tags has changed:

[0098]

[0099]

[0100] The first line is the property definition decorator @rule(), which is used to decorate the following function (lines 2-11), indicating that this function is a property definition function, which is mainly responsible for setting the operation sequence and making post-condition assertions.

[0101] Line 3 uses uiautomator2 to obtain the text content of the component whose resourceId is detail_content and stores it in the variable origin_content.

[0102] Line 4 performs UI operations. Click the button whose resourceId is menu_tag to let the application open the tag list.

[0103] Line 5 uses the random function (random) to randomly select an already checked item in the tag list, indicating that the tag will be deleted later, and the selected tag item is stored in the select_tag variable.

[0104] Line 6 obtains the text content of the select_tag component whose resourceId is md_title, and stores the obtained string in the select_tag_name variable after segmentation.

[0105] Lines 7-8 perform UI operations, click the select_tag tag, uncheck the select_tag tag, and confirm.

[0106] Line 9 obtains the updated content in the component whose resourceId is detail_content after the select_tag tag is cancelled and stores it in the new_content variable.

[0107] Line 10 performs string operations on origin_content obtained in line 3, removing the select_tag_name substring, indicating the content that should be obtained when the properties are correct, and stores it in the origin_content_exlude_tag variable.

[0108] Line 11 uses the assert statement to determine whether the postcondition is satisfied. not d(textContains=select_tag_name).exists() indicates that the tag whose textContains value is equal to the select_tag_name variable value should not exist, that is, the tag selected in line 5 should be deleted normally. new_content==origin_content_exlude_tag indicates that the text content after deleting the tag should be consistent with the ideal text content, that is, the annotation content of the remaining tags should remain unchanged after deleting the specified tag.

[0109] In this embodiment, the property of the OmniNotes application "after deleting a tag, the tag should be successfully deleted, and the annotation content of other tags should remain unchanged" is defined by using the present invention. This includes the initialization definition of the application, the definition of preconditions and the definition of properties. In the embodiment, only one application property is defined, but in the process of using the present invention, the properties defined can be one or more, and each property can be set with its own unique preconditions, event sequences and postcondition assertions. In the embodiment, only assertions are added at the end of the execution event sequence, but when using the description language of the present invention, corresponding assertions can be added after any event.

[0110] The protection content of the present invention is not limited to the above examples. Without departing from the spirit and scope of the present invention, changes and advantages that can be thought of by those skilled in the art are included in the present invention and are protected by the attached claims.

Claims

1. A description language for the functional properties of mobile application software, characterized in that: The following steps are involved: Step 1: Initialization and setup of mobile application: According to the mobile application to be tested and the defined initialization function, complete the initialization and preliminary setup of the application. The initialization is completed before the property test is performed. Step 2: Setting preconditions for application properties: Setting one or more conditional statements to describe the software status that needs to be met before testing the software functional properties; Step 3: Set the interactive scenario of the application properties: Set the sequence of operations that the application should perform, which is used to simulate the interaction between the user and the application software; according to the nature of the application to be tested, after any operation, that is, when the user interface is in any state, set the assertion and post-condition clause to complete the post-condition verification; if there is a situation where the assert statement is not established, it indicates that an error in the relevant nature of the application is found.

2. The description language of the functional properties of mobile application software as claimed in claim 1, characterized in that: In step 1, if the tested application does not need any initialization operation, skip this step and proceed directly to the subsequent property definition step; if you choose to perform initialization settings, the initialization settings of the mobile application consist of the @initialize() decorator and the corresponding function, and the initialization content includes: Skip the welcome screen of the application: Set the operation sequence in the initialization function to skip the welcome screen of the application; Skip the login interface: Set the operation sequence in the initialization function to skip the login interface; Pass initial data to the application: Add the initial data of the application needed for subsequent testing in the initialization function.

3. The description language of the functional properties of mobile application software as claimed in claim 2, characterized in that: The specific interactive operations defined in the initialization function are completed by an external UI interactive tool; the external UI interactive tool is uiautomator2 or an interactive tool selected by modifying the dsl.py configuration document.

4. The description language of the functional properties of mobile application software as claimed in claim 1, characterized in that: In step 2, the precondition setting of the application property test consists of the @precondition() decorator and one or more conditional clauses, and logical operators are used to combine the clauses; the precondition is used to determine whether the application has met the requirements for starting to execute subsequent serialization operations by whether it is met.

5. The description language of the functional properties of mobile application software as claimed in claim 4, characterized in that: The form of the precondition includes expressions describing the application state including clause, not pred, pred or pred, pred and pred; wherein, Clause means a conditional judgment clause; Not is a basic Boolean logical operator used to negate a Boolean value. and is used to determine whether two conditions are true at the same time. The result is true only when both conditions are true; or is used to determine whether at least one of two conditions is true. The result is false only when both conditions are false.

6. The description language of the functional properties of mobile application software as claimed in claim 1, characterized in that: In step 3, the property setting of the application property test is composed of the @rule() decorator and related functions; the property setting includes: setting of the operation sequence and post-condition assertion verification.

7. The description language of the functional properties of mobile application software as claimed in claim 6, characterized in that: The operation sequence setting includes: conditional statements, loop statements, arithmetic operations, function calls, and UI event execution; The UI event execution is implemented through the interface of the uiautomator2 tool or by modifying the configuration file to select the external UI interaction tool to be used to implement the interaction with the mobile device; The post-condition assertion requires setting one or more assert statements, and setting conditional judgment clauses in the assert statement; adding an assertion after any operation is executed to check whether a specific state meets the requirements, that is, setting an assertion when the user interface is in any state to complete the post-condition verification; if there is a situation where the assert statement is not established, it indicates that the relevant property error of the application is found; If it does not exist, it means that no errors of related nature were found in this test.

8. The description language of the functional properties of mobile application software as claimed in claim 5 or 7, characterized in that: The composition of the conditional judgment clause includes the value judgment of the data variable, the number or value judgment of the component, including: The number of controls that meet a certain property in the current interface is greater than, less than, or equal to a specific number; The other property values ​​of the controls that meet a certain property in the current interface are greater than, less than, or equal to a specific number; The other property values ​​of the controls that meet a certain property in the current interface are equal to a Boolean constant or a string constant; The value of a data variable is greater than, less than, or equal to a numeric constant; The value of a data variable is equal to a Boolean constant or a string constant.

9. The description language of the functional properties of mobile application software as claimed in claim 8, characterized in that: The required application component related information is obtained through the interface of the uiautomator2 tool to interact with the mobile device, including component positioning through the selector, interface components and component property data acquisition; or the tool used is selected by modifying the configuration file to interact with the mobile device.

10. Use of a description language as claimed in any one of claims 1 to 9 in defining software functional properties.

Images