Multi-terminal test script fusion execution system, method and device and computer equipment

Abstract

The invention relates to the technical field of automatic testing, in particular to a multi-terminal test script fusion execution system, method and device and computer equipment, and the system comprises an assembly production layer which is used for generating a test unit according to at least one script type included in a test script uploaded to the system and configuration content uploaded to the system, the control layer is used for assembling all the test units to generate a test case according to a method function corresponding to the script type in each test unit; and analyzing a script execution scheme pre-configured in the system, and executing the test case according to the script execution scheme. According to the method, test scripts of different frameworks such as appnium, selenium and requests can be written in the same test script, automatic testing of a complex scene is achieved by combining the calling sequences of different functions in the calling functions, manpower is liberated, and the test efficiency is improved.

Description

Technical Field

[0001] This specification relates to the field of automated testing technology, in particular to multi-terminal test script fusion execution systems, methods, devices and computer equipment. Background Art

[0002] As business grows, the test scenarios involved in daily work are becoming increasingly complex. In today's environment, many complex scenarios require the integrated execution of multi-terminal scripts. Existing automated test scripts only support web UI automation or app-side automated testing, which is no longer sufficient for complex test scenarios.

[0003] Completing complex scenario testing through automated scripts often requires the coordinated use of multiple scripts. Conventional automated testing platforms cannot meet the requirements for coordinating the different scripts in complex test scenarios. Traditional methods require manual effort to determine the timing and relationships between script connections, which consumes time and impacts automated testing efficiency. Alternatively, the use of multiple testing platforms requires manual intervention, defeating the original purpose of automated testing: freeing up human resources. Furthermore, in some data preparation scenarios, it's impossible to schedule scheduled tasks for automatic execution outside of working hours. Summary of the Invention

[0004] In order to solve the problem that automated testing cannot be achieved in the prior art, this specification provides a multi-terminal test script fusion execution system, method, device and computer equipment, wherein the system includes: an assembly production layer, which is used to generate test units based on at least one script type included in the test script uploaded to the system and the configuration content uploaded to the system, wherein the script type is determined according to the unit keyword and all test units are assembled to generate test cases according to the method function corresponding to the script type in each test unit; a control layer, which is used to assemble all test units to generate test cases according to the method function corresponding to the script type in each test unit; and parsing the test execution plan pre-configured in the system, and executing the test case according to the test execution plan, wherein the test execution plan is pre-stored in the database corresponding to the system.

[0005] According to one aspect of the embodiments of this specification, the control layer code further includes a control layer code, the control layer code includes a do_which function, the parsing of a test execution scheme pre-configured in the system, and executing a test case according to the test execution scheme include: the do_which function is used to parse the test execution scheme, the test execution scheme includes: the script execution order, the number of script executions and the script execution method; the system further includes: a request layer, the request layer is used to call a function according to the script type and execute the test script.

[0006] An embodiment of the present specification provides a multi-terminal test script fusion execution method, which is applied to the multi-terminal test script fusion execution system. The method includes: generating a test unit based on at least one script type included in the test script uploaded to the system and the configuration content uploaded to the system, wherein the script type is determined according to the unit keyword; assembling all test units to generate test cases according to the method function corresponding to the script type in each test unit; parsing the test execution plan, and executing the test case according to the test execution plan, wherein the test execution plan is pre-stored in the database corresponding to the system.

[0007] According to one aspect of an embodiment of the present specification, the test script is determined in the following manner: according to the test requirements, at least one end involved in the test requirements is determined, and the at least one end includes: at least one of the web page end, the application end and the server end; the script method corresponding to each end is written and stored in the method function of the test framework corresponding to each end; the unit functions and basic operation functions corresponding to all ends involved in the test requirements are combined to generate a test script file.

[0008] According to one aspect of the embodiments of this specification, the method further includes: obtaining a driver according to configuration content in a configuration file; and determining a script to be executed from the test script according to a category to which each method function in the test script belongs.

[0009] According to one aspect of an embodiment of the present specification, a test execution scheme pre-configured in the system is parsed, and according to the test execution scheme, executing a test case includes: according to the do_which function in the control layer code, parsing the test execution scheme recorded in the database, the test execution scheme including: script execution order, script execution times and script execution method; and performing fusion testing according to the test execution scheme.

[0010] According to one aspect of an embodiment of the present specification, assembling all test units to generate a test case based on the method function corresponding to the script type in each test unit includes: identifying at least one method function in the test script; matching a configuration file according to each script type in the test script to determine the configuration content required to execute the test requirements; generating multiple test units based on the at least one method function and the configuration content; and combining the multiple test units to generate a test case.

[0011] According to one aspect of an embodiment of this specification, when a new class type appears, the method further includes: determining a new configuration file and a new script file corresponding to the new class type, and updating the multi-terminal test script fusion execution system.

[0012] An embodiment of the present specification provides a multi-terminal test script fusion execution device, which includes: a test unit generation unit, which is used to generate a test unit based on at least one script type included in the test script uploaded to the system and the configuration content uploaded to the system, wherein the script type is determined according to the unit keyword; a test case generation unit, which is used to assemble all test units to generate test cases according to the method function corresponding to the script type in each test unit; a script execution unit, which is used to parse the test execution plan and execute the test case according to the test execution plan, and the test execution plan is pre-stored in the database corresponding to the system.

[0013] An embodiment of this specification also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the multi-terminal test script fusion execution method is implemented.

[0014] An embodiment of this specification also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the multi-terminal test script fusion execution method.

[0015] The automation fusion platform in this manual can write test scripts for different frameworks such as Appnium, Selenium, and Requests in the same test script. By combining the calling order of different functions in the calling function, it can realize automated testing of complex scenarios, freeing up manual work and improving testing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1a The figure shows a structural diagram of a multi-terminal test script fusion execution system according to an embodiment of this specification;

[0018] Figure 1b The figure shows a structural diagram of another multi-terminal test script fusion execution system according to an embodiment of this specification;

[0019] Figure 2 The figure shows a flow chart of a multi-terminal test script fusion execution method according to an embodiment of the present specification;

[0020] Figure 3The figure shows a flow chart of a method for determining a test script according to an embodiment of the present specification;

[0021] Figure 4 The figure shows a flow chart of a method for determining a script to be executed according to an embodiment of the present specification;

[0022] Figure 5 The figure shows a flow chart of a method for determining a test execution plan according to an embodiment of the present specification;

[0023] Figure 6 This is a flow chart of a method for generating a test unit according to an embodiment of this specification;

[0024] Figure 7 The figure shows an architecture diagram of a test framework according to an embodiment of the present specification;

[0025] Figure 8 The figure shows a schematic diagram of the structure of a multi-terminal test script fusion execution device according to an embodiment of the present specification;

[0026] Figure 9 The figure shows a schematic diagram of the structure of a computer device according to an embodiment of the present specification.

[0027] Description of the accompanying symbols:

[0028] 110. Assembly production layer;

[0029] 120. Control layer;

[0030] 801. Test unit generation unit;

[0031] 802. Test case generation unit;

[0032] 803, script execution unit;

[0033] 902. Computer equipment;

[0034] 904, processor;

[0035] 906. Memory;

[0036] 908, driving mechanism;

[0037] 910, input / output module;

[0038] 912. Input devices;

[0039] 914. Output device;

[0040] 916. Presentation equipment;

[0041] 918. Graphical User Interface;

[0042] 920, network interface;

[0043] 922, communication link;

[0044] 924. Communication bus. DETAILED DESCRIPTION

[0045] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative work are within the scope of protection of this specification.

[0046] It should be noted that the terms "first," "second," and the like in the description and claims of this specification and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments of this specification described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to these processes, methods, products, or devices.

[0047] This specification provides method operation steps as described in the embodiments or flowcharts, but more or fewer operation steps may be included based on routine or non-creative work. The order of steps listed in the embodiments is only one way of executing the steps among many orderings and does not represent the only execution order. When a system or device product is actually executed, the method can be executed in the order shown in the embodiments or the drawings or in parallel.

[0048] It should be noted that the multi-terminal test script fusion execution system, method, device and computer equipment of this specification can be used in the field of automated testing technology, as well as in the field of software development technology or computer technology. This specification does not limit the application field of the multi-terminal test script fusion execution system, method, device and computer equipment.

[0049] Common testing scenarios in this field include: customer service initiates a service order from the web side and transfers it to the post-loan system web side, supplements and uploads materials from the user app side, and then calls the interface to modify the service order status after the loan. This requires executing the selenium UI automation script on the web side to complete the service order creation and transfer. After the script is executed, it is manually determined whether the result of the previous script execution is completed; after confirming the generation of the service order, the app side is executed, the appnium script completes the material supplement, and after the script execution is completed, the request interface automation script is manually executed to complete the post-loan callback and change the service order status. The entire process requires human intervention, and it is impossible to achieve complete automated execution of use cases. It also requires three local environments to execute or switch between three automation platforms to execute different use cases.

[0050] The automation fusion platform in this manual can write test scripts for different frameworks such as Appnium, Selenium, and Requests in the same test script. By combining the calling order of different functions in the calling function, it can realize automated testing of complex scenarios, freeing up manual work and improving testing efficiency.

[0051] Figure 1a The figure shows a structural diagram of a multi-terminal test script fusion execution system according to an embodiment of the present specification, specifically comprising: an assembly production layer 110 and a control layer 120, wherein the assembly production layer 110 is configured to read the test script and configuration content uploaded to the system, determine at least one script type included in the test script based on a unit keyword, and generate a test unit, wherein the script type corresponds to a terminal;

[0052] The assembly production layer consists of a script named make.py, which contains a make function. The setup class function first calls the make function, which extracts configuration variables from the configuration file and retrieves the driver dialog for the corresponding configuration variable type. The dialog then returns the corresponding driver.

[0053] The control layer 120 is used to assemble all test units to generate test cases based on the method functions corresponding to the script types in each test unit; and to parse the test execution plan pre-configured in the system and execute the test script according to the test execution plan, wherein the test execution plan is pre-stored in the database corresponding to the system. The control layer code is implemented in the driver function run.py. Specifically, all types of scripts are combined through the make function, and scenarios such as serial, parallel or timed execution are implemented according to pre-set settings. The combined results of the make function are then executed through the run function to realize the execution of the test script.

[0054] The control layer in the multi-terminal test script fusion execution system of this manual realizes automatic execution of scripts by dividing the execution stages and execution sequence of test scripts, avoiding the time cost of manual monitoring and waiting.

[0055] The control layer needs to divide the execution into phases. Phases are executed sequentially according to the order of the test units in the test script, determining the execution plan for each phase. Specifically, the execution plan for each phase includes multiple test execution commands, which are parsed by the do_which function. The test script execution command includes the which field and the units field, which indicate the plan and unit to be executed, the number of executions, the timing, or the conditions.

[0056] The execution command of a test script in the embodiment of this specification is as follows:

[0057] {

[0058] 'which': 'asop', 'units': [('test_1 / REQUESTS / m2',1),('test_1 / REQUESTS / m2',1),('test_1 / REQUESTS / m3',1)]}; each line represents a phase, and multiple lines are executed sequentially. In the above code, each part within single quotes within brackets represents a test unit, such as ('test_1 / REQUESTS / m2').

[0059] In the embodiments of this specification, the do_which function is usually pre-stored in the database by the developer or tester to determine the specific test content such as the target test script to be executed, the order in which the target test script is executed, and the number of executions. In this specification, when the test script is executed, the multi-terminal test script fusion execution system reads the do_which function in the database, and the do_which function parses the value corresponding to the which field in the above test execution command, and determines the code execution order (including parallel execution or sequential execution) according to the value. Furthermore, the do_which function parses the value corresponding to the units field in the above test execution command, and performs specific operations according to the value.

[0060] In the embodiment of this specification, the multi-terminal test script fusion execution system also includes a request layer, a result collection layer and a result display layer. Figure 1b The following diagram shows the structure of another multi-terminal test script fusion execution system according to an embodiment of this specification. The request layer is used to call corresponding execution modules or utility functions according to different unit keywords. The result collection layer integrates the test results and reports generated by different frameworks and provides test reports to users according to different solution configurations.

[0061] In this specification, the multi-terminal test script fusion execution system can also be regarded as a multi-terminal test script fusion execution platform. This platform provides multi-environment configuration and is applicable to multiple frameworks such as APPNIUM, SELENIUM, SHELL, AIRTEST, and REQUESTS. The multi-terminal test script fusion execution system integrates unit keywords, configuration files, and a control layer, enabling multi-person use. On this platform, automation scripts across all servers within the same enterprise can be maintained and called, eliminating the need for multi-person coordination and collaboration. There is no need to locally configure multiple environments for execution or switch between multiple automation platforms to execute different test cases.

[0062] Figure 2 The flowchart of a multi-terminal test script fusion execution method according to an embodiment of the present specification is shown. The method is applied to the multi-terminal test script fusion execution system and specifically includes the following steps 201 to 203:

[0063] Step 201 : Generate a test unit according to at least one script type included in a test script uploaded to the system and configuration content uploaded to the system, wherein the script type is determined according to a unit keyword.

[0064] The test scripts and configuration contents read in this step are files or data pre-uploaded to the system, which can be uploaded to the multi-terminal test script fusion execution system by developers and testers.

[0065] For example, developers and testers pre-write a test script named test_1.py. The SELENIUM framework class stores web script method t1, the APPNIUM class stores app-side script method t2, and the REQUEST class stores interface automation method t3. Developers and testers upload the test script file test_1.py to the automated fusion platform of the multi-terminal test script fusion execution system. They also upload the configuration file config_1.py as the Selenium script configuration and the configuration file config_2.py as the APPNium script configuration, completing the upload of the test script and configuration files.

[0066] In this specification, test scripts for different frameworks such as appnium, selenium, requests, etc. can be written in the same test script, and when executing the test script, different methods and execution orders need to be used for different frameworks. Therefore, after reading the test script and configuration content, this step needs to determine which script types are included in the test script based on the unit keyword. Specifically, the unit keywords include but are not limited to: APPNIUM, SELENIUM, SHELL, AIRTEST, REQUESTS or any combination thereof. According to the unit keyword, read the keyword after the class class in the code in the test script to determine the script type included in the test script, and further generate the test unit corresponding to each script type according to the script type. Among them, the script type can be called a class class, including: APPNIUM, SELENIUM, SHELL, AIRTEST, REQUESTS and other class classes. Each class class corresponds to a configuration file.

[0067] In this step, the test unit is the basic unit of testing. It refers to the smallest testable unit, usually a function, method, class, functional module, or subsystem. The test unit is used to verify whether the unit functions as expected.

[0068] As follows: Each element in each array after each unit is the test unit described in this step.

[0069] {

[0070] 'which': 'asop', 'units': [('test_1 / REQUESTS / m2',1),('test_1 / REQUESTS / m2',1),('test_1 / REQUESTS / m3',1)]}; In the above code, each part in single quotes represents a test unit, such as ('test_1 / REQUESTS / m2',1). In this step, a test unit is formed based on one or more method functions and the obtained configuration file.

[0071] Step 202: assemble all test units to generate test cases according to the method functions corresponding to the script types in each test unit.

[0072] In this step, the test case includes multiple test units determined according to the method in step 201. A complete test case includes the test objectives, test environment, input data, test steps, expected results, etc. The purpose of the test case is to verify whether the software functions meet the requirements through specific operation steps and input data.

[0073] In this document, each class contains at least three types of functions: a basic operation function (for example, the setupClass function), a driver function (for example, the run function), and a method function. These three functions together form the foundation of the test framework, helping to organize and execute tests. Among them, the method function is also called a common unit function.

[0074] Among them, the basic running function can call the make function of the production layer assembly in the multi-terminal test script fusion execution system, obtain the configuration file as a parameter, and thus obtain the dirver dialogue; the run function can perform other initialization actions after calling the setupClass function; the ordinary unit function refers to the test method starting with test_, which is used to define specific test cases. Each test method usually tests a specific function or behavior. Each test method will be executed independently in the test class. In this manual, the test methods corresponding to ordinary unit functions are recorded as t1, t2, t3, etc., and multiple test methods can be combined in a test unit to wait for execution. In this step, three test scripts of different types and belonging to different class frameworks can be placed in the same test file.

[0075] Step 203: parse the test execution plan, and execute the test case according to the test execution plan, wherein the test execution plan is pre-stored in a database corresponding to the system.

[0076] In this specification, after uploading the test script to the system, the script execution order is further uploaded to the database. Specifically, the script execution order can be the execution order of the test methods corresponding to the common unit functions in a test script, such as [t1, t2, t3], or [t2, t1, t3], etc. In this specification, the script execution order can be determined by the developers and testers based on the development and testing requirements. This step does not limit the execution order of different test methods in the same test script.

[0077] The automation fusion platform in this manual can write test scripts for different frameworks such as Appnium, Selenium, and Requests in the same test script. By combining the calling order of different functions in the calling function, it can realize automated testing of complex scenarios, freeing up manual work and improving testing efficiency.

[0078] Figure 3 The flowchart of a method for determining a test script according to an embodiment of the present specification specifically includes the following steps 301 to 303 .

[0079] Step 301: Determine at least one end involved in the test requirement according to the test requirement, wherein the at least one end includes at least one of a web page end, an application end, and a server end.

[0080] Among them, the web page side includes: the web side or browser, which is used to automate the testing or operation of web applications (for example, web pages in browsers such as Chrome, Firefox, Safari, etc.) and simulate the user's operation behavior on the web side (for example, click, input, page jump, etc.). Complex test logic can be implemented in combination with a framework (such as Pytest). Automate the login, form submission, and page jump of web pages. The Selenium tool is an automated testing tool suitable for the web side, specifically for the automated operation and testing of web applications. The Selenium tool supports a variety of browsers, operating systems, and programming languages, and can simulate the user's real operations in the browser (such as click, input, page jump, etc.).

[0081] Among them, the application end is: mobile end (supports iOS / Android applications), which is used for automated testing or operation of mobile applications (native applications, hybrid applications, mobile web pages). Supports iOS, Android and Windows platforms. It can be based on the WebDriver protocol and is compatible with Selenium's syntax. Test the button click, sliding, input and other functions of mobile applications. Appium is an automated testing framework for mobile applications, specifically for the automated operation and testing of native applications, hybrid applications and mobile web pages on iOS, Android and Windows platforms. It is based on the WebDriver protocol, allowing developers to use the same set of code to run tests on different mobile platforms.

[0082] Requests corresponds to the server (API / HTTP interface). It is used to send HTTP requests and interact with the server-side API. It is suitable for interface testing, data acquisition, and server-side communication. It supports HTTP methods such as GET, POST, PUT, and DELETE. It processes JSON, form data, and file uploads. It manages cookies, sessions, and authentication (such as OAuth). It tests the response status and data correctness of RESTful APIs.

[0083] Step 302: Write a script method corresponding to each end and store it in a unit function of the test framework corresponding to each end.

[0084] As described above, each test framework has basic run functions, driver functions, and common unit functions. Therefore, in this step, the script methods corresponding to each end are stored in the unit functions of the test framework corresponding to each end, that is, in the common unit functions corresponding to each class.

[0085] Specifically, write web script methods and store them in ordinary unit functions of the class SELENIUM framework, write app-side script methods and store them in ordinary unit functions of the class APPNIUM framework, and write interface automation methods and store them in ordinary unit functions of the class REQUEST framework.

[0086] Step 303: Combine the unit functions and basic operation functions corresponding to all terminals involved in the test requirements to generate a test script file.

[0087] In this specification, when a test script involves multiple terminals, the test framework of each terminal corresponds to basic operation functions, driver functions, and common unit functions. For example, the class SELENIUM framework has its corresponding setupClass function, run function, and common unit functions, and the class APPNIUM framework has its corresponding setupClass function, run function, and common unit functions. Therefore, the unit functions in the test framework of each terminal determined in step 302 are combined with the basic operation functions and driver functions in the test framework of each terminal to form a test script corresponding to the test framework of each terminal.

[0088] Figure 4 The flowchart of a method for determining a script to be executed according to an embodiment of the present specification is shown, specifically including steps 401 and 402:

[0089] Step 401: Obtain the driver according to the configuration content in the configuration file.

[0090] This step is performed by the assembly production layer in the multi-terminal test script fusion execution system. The assembly production layer consists of a script named make.py, which contains the make function. The setup class function first calls the make function. The make function extracts configuration variables from the configuration file and retrieves and returns the driver dialog corresponding to the configuration variable type, thereby obtaining the corresponding driver. For example, the driver can be used to connect to a web page or mobile emulator to launch a browser.

[0091] Step 402: Determine the script to be executed from the test script according to the category to which each method function in the test script belongs.

[0092] This step determines the script to be executed from the test script according to the method of determining the script type according to the unit keyword in the previous step.

[0093] Figure 5 The flowchart of a method for determining a test execution plan according to an embodiment of the present specification is shown, specifically including step 501 and step 502:

[0094] Step 501: Parse the test execution plan recorded in the database according to the do_which function in the control layer code.

[0095] The test execution command includes: script execution order, script execution times and script execution mode.

[0096] The following is a code diagram of the execution command of a test script:

[0097] {

[0098] 'which': 'asop', 'units': [('test_1 / REQUESTS / m1',1),('test_1 / REQUESTS / m2',1),('test_1 / REQUESTS / m3',1)]}; Each single quote in the brackets represents a test unit, and m1, m2, and m3 in each test unit represent three different method functions. test_1 / REQUESTS / m1 represents the REQUESTS method function m1 in the test_1 test script file. 'test_1 / REQUESTS / m1',1 means executing the method function once; 'test_1 / REQUESTS / m3',1 means executing the method function m3 once. The execution command of this test script records the execution order of the three test units, that is, executing method function m1 first, then method function m2, and finally method function m3.

[0099] Step 502: Perform fusion testing on the test cases according to the test execution plan.

[0100] In this specification, a test execution plan includes at least one test execution command. The test script's execution command also defines the execution method for various methods, such as parallel or serial execution. Fusion testing is performed on test cases based on the method functions, the execution order of the multiple method functions, the execution method of the method functions, the number of times each method function is executed, and other information defined in the test script's execution command.

[0101] In this manual, the execution commands of the test scripts can be used to execute multi-terminal scripts in the configured order to complete the writing and execution of the test scripts, saving manpower time, improving work efficiency and saving costs for the company.

[0102] Figure 6 The flowchart of a method for generating a test unit according to an embodiment of the present specification is shown, which specifically includes steps 601 and 604:

[0103] Step 601, identify at least one method function in the test script. In this step, after the system has obtained the test script and configuration file uploaded by the user, the system computer or server identifies the method function in the test script through keyword recognition. In the embodiment of this specification, a complete test script can be a combination of sub-test scripts corresponding to multiple frameworks. The test script corresponding to a framework may correspond to one or more method functions. For example, the test script corresponding to the test_1 / REQUESTS framework corresponds to method functions t1 and t2. For another example, the test script corresponding to the test_1 / REQUESTS framework corresponds to method function m3. This step determines the method function in the test unit by reading the code corresponding to each test unit in the test script.

[0104] Step 602: Match the configuration files according to the script types in the test script to determine the configuration content required to execute the test requirements.

[0105] In this step, the system computer or server matches the corresponding framework and method function type from the system configuration files based on the framework and script type determined in step 601. The script type is determined, and the script configuration required is determined based on the configuration file. For example, for the class SELENIUM framework, the configuration file for the Selenium script is obtained as config_1.py, while for the class APPNIUM framework, the configuration file for the Appnium script is obtained as config_2.py.

[0106] Step 603: Generate multiple test units based on the at least one method function and the configuration content.

[0107] In this step, the test script corresponding to a class type and its corresponding method function are combined with the corresponding configuration content to form the multiple test units. Furthermore, the do_which function is used to determine the test execution order, method, and number of times for the multiple test units, thereby generating a complete test case.

[0108] In this step, the multi-terminal scripts are jointly written by reading the classes of APPNIUM, SELENIUM, SHELL, AIRTEST, and REQUESTS, realizing the storage and flexible calling of test scripts.

[0109] In the embodiments of this specification, as technology develops, new frameworks of the same type or other types of frameworks may need to be added to the platform to increase compatibility with test scenarios.

[0110] In order to achieve the flexibility and high compatibility of automation, this manual can also write new test scripts according to the newly added test requirements, add CLASS files (for example, player classes) to the new test scripts, add a unit keyword corresponding to the new class type to distinguish the script type, generate a new script file, and prepare the corresponding configuration file, add the content of the public driver part to the configuration file, integrate the configuration content and reference library required by the corresponding framework in the configuration file. And store the execution content in the new script file in the run function for execution. Add the support call of the corresponding module to the make function of the assembly production layer, add the differentiation logic of the corresponding type of script to the do_which function to quickly integrate the new framework, modify the method function and execution order, execution number, and execution form for the new script type in the do_which function, and achieve compatibility with the new type of script. You can quickly achieve compatibility with new types of scripts, quickly iterate, be compatible with new technologies, and quickly add new frameworks to complete platform upgrades.

[0111] Figure 7 The following diagram shows the architecture of a test framework according to an embodiment of this specification. In the diagram, each .py script represents a project. Before executing script fusion testing, the test scripts must first be uploaded to the system. For example, the test scripts test_1, test_2, and test_3 are uploaded to the system. Each project theoretically corresponds to five classes, each named: SELENIUM, APPIUM, SHELL, REQUESTS, and AIRTEST.

[0112] Each class must contain at least three types of script execution functions: setupClass, run, and common unit functions. setupClass calls the assembly production layer's make function, passing in a configuration file as a parameter and obtaining the driver dialog. The run function performs other initialization actions after calling setupClass. Common unit functions execute specific functions. The function name is the unit name, and doc is the unit description. It requires code for detailed processes, assertions, configuration variables, and calls to other units.

[0113] In the figure, each configuration file (for example, config_1.py) needs to contain: type and variables.

[0114] The assembly production layer is a script named make.py, which contains a make function. The make function extracts configuration variables from the configuration file, generates the corresponding driver dialog based on the type, and returns it. The control layer code is implemented in run.py. The control layer requires execution phases, which are executed in a completely sequential order. Each phase must contain a "which" field to specify the execution plan. Each phase must also contain a "units" field to indicate the unit to be executed, the number of executions, the timing, or the conditions.

[0115] Figure 8 The figure shows a schematic diagram of the structure of a multi-terminal test script fusion execution device according to an embodiment of this specification. This figure describes the basic structure of the multi-terminal test script fusion execution device, wherein the functional units and modules can be implemented in software, or a general-purpose chip or a specific chip can be used to implement the multi-terminal test script fusion execution. The device specifically includes:

[0116] A test unit generating unit 801 is configured to read a test script and configuration content uploaded to the system, determine at least one script type included in the test script based on a unit keyword, and generate a test unit, wherein the script type corresponds to an end;

[0117] A test case generating unit 802 is configured to generate a test case by assembling all test units according to the method function corresponding to the script type in each test unit;

[0118] The script execution unit 803 is configured to parse the script execution sequence pre-configured in the system and execute the test script according to the execution sequence.

[0119] In this manual, you can write test scripts for different frameworks such as appnium, selenium, and requests in the same test script. By combining the calling order of different functions in the calling function, you can achieve automated testing of complex scenarios, freeing up manual labor and improving test efficiency.

[0120] like Figure 9, which is a schematic diagram of a computer device provided in an embodiment of this specification. The multi-terminal test script fusion execution method described herein can be applied to the computer device. The computer device 902 may include one or more processors 904, such as one or more central processing units (CPUs), each of which may implement one or more hardware threads. The computer device 902 may also include any memory 906 for storing any type of information, such as code, settings, data, and the like. For example, and without limitation, the memory 906 may include any one or more combinations of the following: any type of RAM, any type of ROM, a flash memory device, a hard disk, an optical disk, and the like. More generally, any memory may use any technology to store information. Furthermore, any memory may provide volatile or non-volatile retention of information. Furthermore, any memory may represent a fixed or removable component of the computer device 902. In one embodiment, when the processor 904 executes associated instructions stored in any memory or combination of memories, the computer device 902 may perform any operation of the associated instructions. The computer device 902 also includes one or more drive mechanisms 908, such as a hard disk drive mechanism or an optical disk drive mechanism, for interacting with any memory.

[0121] The computer device 902 may also include an input / output module 910 (I / O) for receiving various inputs (via input devices 912) and for providing various outputs (via output devices 914). A specific output mechanism may include a presentation device 916 and an associated graphical user interface (GUI) 918. In other embodiments, the input / output module 910 (I / O), input devices 912, and output devices 914 may not be included, and the computer device 902 may simply be a computer device in a network. The computer device 902 may also include one or more network interfaces 920 for exchanging data with other devices via one or more communication links 922. One or more communication buses 924 couple the components described above together.

[0122] The communication link 922 may be implemented in any manner, for example, via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 922 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0123] Corresponding to Figures 2 to 6 The method in this specification also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps of the above method are executed.

[0124] The embodiment of this specification also provides a computer-readable instruction, wherein when the processor executes the instruction, the program therein causes the processor to execute the following Figures 2 to 6 The method shown.

[0125] It should be understood that in the various embodiments of this specification, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0126] It should also be understood that in the embodiments of this specification, the term "and / or" is merely a description of the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. Furthermore, the character " / " in this specification generally indicates that the associated objects are in an "or" relationship.

[0127] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this specification.

[0128] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0129] In the several embodiments provided in this specification, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or can be an electrical, mechanical or other form of connection.

[0130] The units described as separate components may or may not be physically separate, and the components shown as units 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 units may be selected according to actual needs to achieve the purpose of the embodiments of this specification.

[0131] In addition, the functional units in the various embodiments of this specification may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0132] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this specification is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of this specification. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0133] Specific embodiments are used in this specification to illustrate the principles and implementation methods of this specification. The description of the above embodiments is only used to help understand the methods and core ideas of this specification. At the same time, for those skilled in the art, based on the ideas of this specification, there will be changes in the specific implementation methods and application scope. In summary, the contents of this specification should not be understood as limiting this specification.

Claims

1. A multi-terminal test script fusion execution system, characterized in that: The system comprises: An assembly production layer, configured to generate test units based on at least one script type included in the test scripts uploaded to the system and the configuration content uploaded to the system, wherein the script type is determined based on a unit keyword and based on the method function corresponding to the script type in each test unit, all test units are assembled to generate test cases; The control layer is used to assemble all test units to generate test cases according to the method functions corresponding to the script type in each test unit; and to parse the test execution plan pre-configured in the system, and execute the test cases according to the test execution plan, wherein the test execution plan is pre-stored in the database corresponding to the system.

2. The system according to claim 1, wherein: The control layer further includes a control layer code, the control layer code includes a do_which function, and the parsing of a test execution scheme pre-configured in the system and executing a test case according to the test execution scheme includes: the do_which function is used to parse the test execution scheme, the test execution scheme including: a script execution order, a script execution number, and a script execution mode; The system further includes a request layer, which is used to call functions according to script types and execute the test scripts.

3. A multi-terminal test script fusion execution method, characterized in that: The method applies the multi-terminal test script fusion execution system according to any one of claims 1-2, including: generating a test unit according to at least one script type included in a test script uploaded to the system and configuration content uploaded to the system, wherein the script type is determined according to a unit keyword; According to the method function corresponding to the script type in each test unit, all test units are assembled to generate test cases; Parse the test execution plan and execute the test case according to the test execution plan, wherein the test execution plan is pre-stored in a database corresponding to the system.

4. The method according to claim 3, characterized in that The test script is determined as follows: According to the test requirements, determine at least one end involved in the test requirements; Write the script method corresponding to each end and store it in the method function of the test framework corresponding to each end; Combine the unit functions and basic operation functions corresponding to all ends involved in the test requirements to generate a test script file.

5. The method according to claim 3, characterized in that The method further comprises: Get the driver according to the configuration content in the configuration file; According to the category to which each method function in the test script belongs, a script to be executed is determined from the test script.

6. The method according to claim 3, characterized in that Parsing a test execution plan pre-configured in the system and executing a test case according to the test execution plan includes: According to the do_which function in the control layer code, the test execution plan recorded in the database is parsed. The test execution plan includes: script execution order, script execution times and script execution mode; Perform fusion testing according to the test execution plan.

7. The method according to claim 3, characterized in that According to the method function corresponding to the script type in each test unit, all test units are assembled to generate test cases including: Identifying at least one method function in the test script; Match configuration files according to the script types in the test script to determine the configuration content required to execute the test requirements; Generate multiple test units using the at least one method function and the configuration content; The multiple test units are combined to generate a test case.

8. The method according to claim 3, characterized in that When a new class type appears, the method further includes: Determine a new configuration file and a new script file corresponding to the new class type, and update the multi-terminal test script fusion execution system.

9. A multi-terminal test script fusion execution device, characterized in that: The device applies the multi-terminal test script fusion execution system according to any one of claims 1-2, including: a test unit generating unit, configured to generate a test unit according to at least one script type included in a test script uploaded to the system and configuration content uploaded to the system, wherein the script type is determined according to a unit keyword; The test case generation unit is used to assemble all test units to generate test cases according to the method function corresponding to the script type in each test unit; The script execution unit is used to parse the test execution plan and execute the test case according to the test execution plan. The test execution plan is pre-stored in the database corresponding to the system.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 3 to 8 is implemented.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 3 to 8 is implemented.

Images