Distributed test system combined with formal operating environment

Abstract

The invention discloses a distributed test system combined with a formal operating environment. The distributed test system comprises a task scheduling module, a script processing module and a security sandbox, the security sandbox and the script processing module interact with a formal operation environment; wherein the task scheduling module is used for responding to a request from a test terminal, decomposing the request into test tasks and distributing the test tasks according to the load condition of the script processing module; the script processing module comprises a task packaging unit, an instruction packaging unit and a dynamic injection engine and is used for injecting a test script into the security sandbox after the test script is generated according to the test task; the security sandbox is used for executing the test script and obtaining a test result. According to the technical scheme, real-time dynamic injection of the script can be achieved, the timeliness of script updating is improved, browser simulation is achieved under the condition that the script is not limited by a browser driver, mobile device simulation and API test browsing function simulation are supported, and isolated operation is guaranteed through a safety sandbox when the script is executed.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of automatic software testing, and in particular to a distributed testing system combined with a formal running environment. BACKGROUND

[0002] With the popularity of cloud native applications, in the front-end development delivery process, UI function and API interface testing requirements present dynamic, high concurrency characteristics and close association with formal running environment characteristics. Currently, commonly used test frameworks such as Selenium, but the test node needs to be pre-deployed with a version number matching the driver, which has a strong dependence on the environment, and if the browser is updated, the driver cannot be used; at the same time, the test framework does not support fine-grained control of API interface set, and the judgment logic of page loading state is complex, if the test logic is modified, the entire test environment needs to be re-published, which causes the entire automation pipeline to be interrupted; at the same time, testing based on the formal running environment may also affect the formal environment.

[0003] Although with the development of cloud services, cloud testing platforms have also begun to popularize, but the cloud testing platform provides a remote browser, but its closed script management limits the implementation of new logic.

[0004] Therefore, there is an urgent need for a testing solution to solve the following problems: 1. Execution dynamics: allow real-time transmission and execution of test logic through network API; 2. Execution isolation: ensure the safety of the test system host during testing, and do not affect the operation of the formal running environment; 3. Distributed capability: need to solve the installation problem of complex environment, and realize the load balancing of test tasks under high concurrency. SUMMARY

[0005] To achieve the above purpose, the present application provides a distributed testing system combined with a formal running environment, comprising a task scheduling module, a script processing module and a security sandbox; wherein the security sandbox and the script processing module interact with the formal running environment; The task scheduling module is used to respond to requests from the test terminal, extract test basic information, decompose into one or more test tasks, and distribute according to the load of the script processing module; the information of the test task includes: test subject information, test function, test parameter and running result; The script processing module includes a task encapsulation unit, an instruction encapsulation unit and a dynamic injection engine, which is used to generate a test script according to a test task; the task encapsulation unit obtains the test task, parses the data packet of the test task, and extracts the constituent factor that can generate the test script; the instruction encapsulation unit generates a code segment corresponding to the test task according to the constituent factor and the test parameter; the dynamic injection engine generates a test script according to the script segment and the constituent factor, and injects the test script into the security sandbox; The secure sandbox is used for executing the test script and obtaining a test result.

[0006] The constituent factor is a variable object, a method of the object and a property defined for a running instruction in the test script executed for the test subject information and the test function.

[0007] Further, the script processing module further comprises a FastAPI gateway for providing an interface and responding to a test task. The task scheduling module allocates the test task to one or more idle FastAPI gateways in sequence.

[0008] Further, the test parameter comprises an instance identifier corresponding to the running test task, and the return result comprises the instance identifier and a variable name or a variable structure corresponding to the running result. The information of the test function supports an instruction and a packaged function provided by a script language. When the running instruction is executed, an interface of an official running environment is supported.

[0009] The secure sandbox is an independent running environment composed of a Docker container and a Playwright engine. The Docker container determines an environment for executing the test, including a browser type, related plug-ins and functions, and sends an instruction for starting a browser instance to the Playwright engine. The Playwright engine defines a most basic browser container variable, and a running logic is controlled by a test script and an interface parameter.

[0010] Further, the test parameter supports an interface address of the official running environment.

[0011] If the multiple test tasks are associated tasks, the codes of the test tasks are merged into a test script and injected into the secure sandbox for execution.

[0012] According to the application, real-time dynamic injection of a script can be realized, time effectiveness of script updating is improved, browser simulation is realized without being limited by a browser driver, a mobile device is simulated, API test browsing function is simulated, and running isolation is ensured by the secure sandbox when the script is executed. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1A distributed test system structure schematic diagram provided according to an embodiment of the present application is provided. Figure 2 A security sandbox executes a test task timing diagram in a distributed test system provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0014] The present application provides a distributed test system combined with a formal running environment, a test script combined with the formal running environment is generated through distributed task generation, the test script is dynamically injected into a security sandbox to implement execution of a test function, and an execution result is obtained according to a requirement.

[0015] The specific implementation of the present application is described in detail below with reference to the accompanying drawings.

[0016] The distributed test system structure of the present application is shown in Figure 1 The distributed test system structure of the present application is shown in The P100 task scheduling module is used to respond to a request from a test terminal, extract test basic information, decompose into one or more test tasks, and distribute according to the load condition of the script processing module.

[0017] In the present application, the code specification for generating a test task is agreed, and the task is split according to the basic function contained in a test request.

[0018] Further, for the function to be executed by each task, the instruction, instruction parameter related variable naming, and variable structure are agreed, including classifying the information of each test task, which can be simply classified as: test subject information, test function, test parameter, and return result. The test parameter at least includes an instance identifier corresponding to the running test task this time; the return result includes a variable name or variable structure corresponding to the instance identifier and the running result.

[0019] Specifically, the information of the test function supports the instruction provided by the script language, and also supports the encapsulated function; the test parameter is a parameter value related to the instruction of the test function; the interface of the formal running environment is supported when the instruction is executed; therefore, the interface address of the formal running environment is supported in the test parameter; wherein, the instruction and the function can be set in advance for selection when used.

[0020] In the present application, a case is provided, the request of the test terminal is to test the positioning function of a certain page based on latitude and longitude; in the task device module, the request is decomposed into the following tasks: 1) Determine the positioning function of the test subject information; In this task, the test subject information is defined as a simulated mobile device, and the variable name of the simulated mobile device is agreed to be: iPhone 12 Pro Max ; The test function sets the browser's location, and the agreed-upon command is as follows: browser.new_context(con) ; The test parameter convention requires the definition of parameter names and values ​​when the command is executed. For example, latitude and longitude variables and their values ​​are represented as follows: browser =p.webkit.launch(headless=False) Con='**iphone_12_pro_max,geolocation={'lonqitude':116.39014,' latitude':39.913904} #Set device latitude and longitude' context =browser.new_context(con) The returned results are the instance identifier and the execution result, where the instance identifier is represented as... iphone_12_pro_max, The result of the operation is expressed as context ; 2) Functional verification: In this task, functional verification is provided for the positioning function: the test subject information is defined as a simulated mobile device, the test function is defined as a verification command, and the test parameters are defined as instance identifier, running result, verification running command, and verification method; among them, the parameter values ​​of the verification running command also support the interface address of the formal running environment; the return result is instance identifier and running result; In this case, the test subject information is still a simulated mobile device, and the variable name for the simulated mobile device is agreed to be: iPhone 12 Pro Max ; The test function is represented as follows: page.goto(loca), page.content(); The test parameters are: page = context.new_page() loca='https: / / map.baidu.com / mobile / webapp / index / index / foo=bar / tab= place') Page_html = page.content() If multiple test tasks need to implement independent and concurrently executable functions, the instance identifier of each task should be set to independent identifier information; if multiple test tasks are related and have sequential functions, the instance identifiers of each task should be consistent. For example, in the case provided by this invention, the instance identifiers of the two tasks are kept consistent.

[0021] When the task scheduling module sends a test task to the script processing module, it also passes in configuration information, which is used by the script processing module to generate a validity verification request.

[0022] The P110 script processing module can generate test scripts based on test tasks. Structurally, the script processing module includes a FastAPI gateway, a task encapsulation unit, an instruction encapsulation unit, and a dynamic injection engine. Specifically: P111: The FastAPI gateway is used to provide interfaces and respond to test tasks; In the P100 task scheduling module, test tasks can be sequentially assigned to an idle FastAPI gateway based on the specific business requirements of the test tasks; multiple tasks can also be assigned to multiple FastAPI gateways; the FastAPI gateway calls the task encapsulation unit and instruction encapsulation unit based on the specific test task information.

[0023] FastAPI Gateway provides API interfaces that support the HTTP protocol and use the Pydantic model to verify based on configuration information to prevent malicious code injection attacks. It also provides complete Swagger test cases and API call logs, making API call relationships clear.

[0024] The P112 task encapsulation unit obtains information from the test task through the FastAPI gateway, parses the test task's data packet, and extracts the constituent factors that can generate test scripts.

[0025] The constituent factors are variable objects, object methods, and properties defined for the execution instructions in the test scripts that target the test subject information and test functions. The parameter values ​​of the constituent factors are generated by the instruction encapsulation unit.

[0026] The P113 instruction encapsulation unit generates code snippets corresponding to the test tasks based on the constituent factors and test parameters. The code snippets can be used as parameter values ​​for the constituent factors.

[0027] In this invention, since the running instructions and their parameter values ​​both support the interface address of the formal running environment, if the test parameters include the address of the formal running environment, then the system interacts with the P120 formal running environment to obtain the running results, and encapsulates the running results as parameters into the code snippet of the test task.

[0028] The P114 dynamic injection engine generates test scripts based on the constituent factors and code snippets. After the test scripts are generated, they are injected into the security sandbox.

[0029] In the example provided by this invention, test scripts for two tasks are generated respectively: 1) The test script for the task "Location function to determine test subject information" is generated as follows: iphone_12_pro_max = p.devices['iPhone 12 Pro Max'] # Simulate mobile phone devices browser = p.webkit.launch(headless=False) # To display the simulated device Con='**iphone_12_pro_max,geolocation={'lonqitude':116.39014,' latitude':39.913904} #Set device latitude and longitude' context =browser.new_context(con) This code snippet specifies the latitude and longitude for the settings of the simulated mobile device.

[0030] 4) The following test script was generated for the task "Function Verification": In the example provided by this invention, the functional verification interface is Baidu Maps, and the generated test code is as follows: page = context.new_page() loca='https: / / map.baidu.com / mobile / webapp / index / index / foo=bar / tab= place') page.goto(loca) # Open Baidu Maps Page_html = page.content() This code snippet opens Baidu Maps in the browser of a simulated mobile device at a specified latitude and longitude, returns the location information obtained from Baidu Maps, and determines whether the pre-known location at that latitude and longitude is within the range of the location information obtained from Baidu Maps.

[0031] If multiple test tasks are related, the code for each test task can be merged into a single test script and injected into the security sandbox. For example, in the case provided in this invention, the scripts corresponding to two tasks are merged: A simulated mobile browser is opened, the device's latitude and longitude are set to (116.39014, 39.913904) (Beijing Palace Museum), the browser is granted permission to obtain the device's location information, and after execution, the device's location information is obtained. Page_html ).

[0032] This invention provides a test script editing function, allowing testers to observe, adjust, and improve the code content via a test terminal. For example, code to close the browser can be added at appropriate locations in the script. browser.close () ), code to adjust the waiting time.

[0033] In the example provided by this invention, the code was adjusted by the tester as follows: iphone_12_pro_max = p.devices['iPhone 12 Pro Max'] # Simulate mobile phone devices browser = p.webkit.launch(headless=False) # To display the simulated device context = browser.new_context( **iphone_12_pro_max, Locale='zh-CN' geolocation={"lonqitude':116.39014,'latitude':39.913904} #Set device geolocation latitude permissions=['geolocation'], # Grant the device location permissions ） page = context.new_page() loca='https: / / map.baidu.com / mobile / webapp / index / index / foo=bar / tab= place') page.goto(loca) # Open Baidu Maps page.wait_for_load_state(state='networkidle') # Wait for all network requests to finish page.wait _for_timeout(30000) Page_html = page.content() The P130 security sandbox is an independent runtime environment composed of Docker containers and the Playwright engine, which features isolation, security, and portability.

[0034] In the secure sandbox, the Docker container determines the environment for executing the test, such as the browser type, related plugins and functions, and sends an instruction to the Playwright engine to start a browser instance; The Playwright engine defines only the most basic browser container variables. Its execution logic is implemented through two methods: test script control and interface parameter control, to achieve API testing and UI testing.

[0035] The Playwright engine responds to Docker container instructions to start a specified browser instance. By default, it disables the loading of all non-target resources (images, videos, audio, etc.) to improve running efficiency.

[0036] Error and exception information is captured throughout the entire testing process and input to a specified output endpoint. The output endpoint supports file reports, push notifications, and screen printing.

[0037] For example, the `exec` method in Python can be used to execute character-based UI / API test scripts in a browser.

[0038] The browser-based testing task proposed in this invention, and the execution process of the security sandbox, are as follows: Figure 2 As shown: The Docker container sends a request to the Playwright engine to select the browser type, start the browser instance, and disable image, audio, and video loading. The Playwright engine then executes the test script and returns the test results. Furthermore, it can generate a test report and output it to a specified terminal.

[0039] The distributed testing system provided by this invention supports a large number of high-concurrency interface calls. The client does not need to install any environment, only a network. At the test script execution end, Docker containers are used to achieve operating system-level isolation, and Python-playwright sandbox is used to restrict script API access permissions, providing double protection for host security.

[0040] The above-disclosed embodiments are merely a few specific examples of the present invention. However, the present invention is not limited thereto, and any variations that can be conceived by those skilled in the art should fall within the protection scope of the present invention.

Claims

1. A distributed test system incorporating a formal operating environment, characterized by, The task scheduling module, the script processing module and the security sandbox are included, wherein the security sandbox and the script processing module interact with the formal running environment; The task scheduling module is used for responding to the request from the test terminal, extracting test basic information, decomposing into one or more test tasks, and distributing according to the load condition of the script processing module; the information of the test task includes test subject information, test function, test parameter and running result; The script processing module includes a task encapsulation unit, an instruction encapsulation unit and a dynamic injection engine, which is used for generating a test script according to the test task; the task encapsulation unit obtains the test task, parses the data packet of the test task, and extracts the constituent factor of the test script; the instruction encapsulation unit generates a code segment corresponding to the test task according to the constituent factor and the test parameter; the dynamic injection engine generates a test script according to the script segment and the constituent factor, and injects the test script into the security sandbox; The security sandbox is used for executing the test script and obtaining the test result.

2. The distributed test system of claim 1, wherein, The script processing module further includes a FastAPI gateway for providing an interface and responding to the test task; The task scheduling module distributes the test task to one or more idle FastAPI gateways in sequence; the FastAPI gateway calls the task encapsulation unit and the instruction encapsulation unit according to the information of the specific test task.

3. The distributed test system of claim 1, wherein, The test parameter includes an instance identifier corresponding to the running test task; the return result includes the instance identifier and the variable name or variable structure corresponding to the running result; The information of the test function supports the instructions provided by the script language and the encapsulated functions; When the running instruction is executed, the interface of the formal running environment is supported.

4. The distributed test system of claim 1, wherein, The security sandbox is an independent running environment composed of a Docker container and a Playwright engine; The Docker container determines the environment for executing the test, including the browser type, related plug-ins and functions, and sends a command for starting a browser instance to the Playwright engine; The Playwright engine defines the most basic browser container variable, and the running logic is controlled by the test script and the interface parameter.

5. The distributed test system of claim 1, wherein, The constituent factor is a variable object, object method and attribute defined for the running instruction in the test script executed for the test subject information and the test function.

6. The distributed test system of claim 3, wherein, The test parameter supports the interface address of the formal running environment; if the test parameter is the interface address of the formal running environment, the instruction encapsulation unit interacts with the formal running environment, obtains the running result, and encapsulates the running result into the code segment of the test task as a parameter.

7. The distributed test system of claim 3, wherein, If the multiple test tasks are associated tasks, the code of each test task is merged into a test script which is injected into the security sandbox for execution.

Images