A cross-frame system testing method and related device
By converting element coordinates to absolute coordinates and switching frames during cross-frame system testing, the problems of low testing efficiency and poor accuracy in existing technologies are solved, achieving efficient and accurate system testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HUNAN XIAOSUAN TECH INFORMATION CO LTD
- Filing Date
- 2026-02-06
- Publication Date
- 2026-05-29
AI Technical Summary
Existing cross-framework system testing suffers from low testing efficiency and poor accuracy, especially when switching between Appium and UiAutomator2 frameworks, which can easily lead to interruptions, inconsistencies in coordinate systems, and test disruptions.
By acquiring test page data from the current frame, converting element coordinates to absolute coordinates in the target frame, and switching to the target frame without restarting or closing the process, the system test can continue.
It improves the accuracy and efficiency of cross-frame system testing, reduces test interruptions, solves the positioning drift problem caused by coordinate system inconsistency, and achieves seamless frame switching.
Smart Images
Figure CN122111875A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of system testing technology, and in particular to a cross-framework system testing method and related equipment. Background Technology
[0002] Currently, there are two main modes of mobile automated testing: Appium, an automated testing framework (using the WebDriver protocol, a browser remote control protocol standardized by the World Wide Web Consortium), employs a client / server (C / S) architecture. The client sends Hypertext Transfer Protocol (HTTP) requests, while the server parses JSON using the JSON-Wire protocol. Its advantages include cross-platform compatibility and support for hybrid applications (WebView). However, its disadvantages include a long communication chain (HTTP -> TCP -> Android Debug Bridge (ADB) -> Bootstrap), resulting in slow execution and difficulty in handling system-level pop-ups or frequent gestures.
[0003] UiAutomator2, an Android automated testing framework (U2 / Remote Procedure Call RPC protocol), directly starts an HTTP server (HTTPServer) within the Android device, and directly calls the system's underlying application programming interface (API) via JSON-RPC. Its advantages include extremely fast execution speed (milliseconds); its disadvantages include process mutual exclusion with Appium's underlying service (Uiautomator2-server) and a lack of cross-platform management capabilities.
[0004] Existing pain points of hybrid use: Service mutual exclusion caused an interruption: The Android system allows only one instrumentation process to run at a time. Starting U2 while Appium is running will force the system to kill the former, causing the test to be interrupted.
[0005] Context loss and time consumption: The traditional "kill process-restart" switching method will cause the App to restart and the page state (Session) to be lost. Restarting the Instrumentation service is usually time-consuming, which seriously affects the testing efficiency.
[0006] Inconsistent coordinate systems: Appium is based on WebView relative coordinates, while U2 is based on screen absolute coordinates. The two systems have calculation discrepancies on devices with virtual buttons or notch screens, resulting in misaligned clicks.
[0007] This shows that current cross-framework system testing suffers from low testing efficiency and poor accuracy. Summary of the Invention
[0008] This application provides a cross-framework system testing method and related equipment, which can solve the problems of low testing efficiency and poor accuracy in cross-framework system testing.
[0009] In a first aspect, embodiments of this application provide a cross-framework system testing method, which includes: When a framework switching instruction is received, the test page data of the target device under the current framework is obtained; the test page data includes the coordinates of multiple elements in the test page of the target device; Transform the coordinates of each element to the target frame to obtain the absolute coordinates of each element; Switch from the current frame to the target frame based on the absolute coordinates of all elements, and continue performing system testing on the target device.
[0010] Optionally, the coordinates of each element are transformed to the target frame to obtain the absolute coordinates of each element, including: Obtain the target device's physical width, physical height, and system bar height; For each element, based on the device's physical width, device's physical height, and system bar height, the element's coordinates are transformed to the target frame to obtain the element's absolute coordinates.
[0011] Optionally, based on device resolution, pixel density, and system bar height, the element's coordinates are transformed to the target frame to obtain the element's absolute coordinates, including: Through the formula:
[0012]
[0013] Calculate the absolute coordinates of the elements ; in, The x-coordinate of the element. y is the ordinate of the element. This represents the ratio of the device's physical width to its logical width. This represents the ratio of the device's physical height to its logical height. , This is the screen edge compensation value. Indicates the height of the system bar.
[0014] Optionally, switch from the current frame to the target frame based on the absolute coordinates of all elements, and continue performing system testing on the target device, including: Switch instance execution control from the current framework to the target framework; Within the target framework, test operations are performed based on the absolute coordinates of all elements to achieve system testing of the target device.
[0015] Optionally, switching instance execution rights from the current framework to the target framework includes: Pause instance operations in the current framework, release the lock on the current framework, release instance execution rights in the current framework, and transfer the instance executor to the target framework.
[0016] Optionally, when a framework switching instruction is received, the system testing method also includes: Block data writing to the current framework and enable simulated heartbeat to keep the current framework alive.
[0017] Secondly, embodiments of this application provide a cross-framework system testing apparatus, comprising: The acquisition module is used to acquire the test page data of the target device under the current framework when a framework switching instruction is received; the test page data includes the coordinates of multiple elements in the test page of the target device; The switching module is used to transform the coordinates of each element to the target frame, obtaining the absolute coordinates of each element; The test module is used to switch from the current frame to the target frame based on the absolute coordinates of all elements, and continue to perform system tests on the target device.
[0018] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned cross-framework system testing method.
[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned cross-framework system testing method.
[0020] The above-mentioned solution in this application has the following beneficial effects: In the embodiments of this application, when a frame switching instruction is received, the test page data of the target device under the current frame is obtained. Then, the coordinates of each element are transformed to the target frame to obtain the absolute coordinates of each element. Finally, based on the absolute coordinates of all elements, the system switches from the current frame to the target frame to continue executing system testing on the target device. Transforming the element coordinates of the test page to the target frame enables the positioning of elements in different test frames, solving the positioning drift problem caused by inconsistencies in coordinate systems. This effectively improves the accuracy of cross-frame system testing. Furthermore, this method eliminates the need for forced process closure or restart, reducing test interruptions during frame switching and improving system testing efficiency.
[0021] Other beneficial effects of this application will be described in detail in the following detailed description section. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 A flowchart illustrating a cross-frame system testing method provided in an embodiment of this application; Figure 2 A schematic diagram of the structure of a cross-frame system testing apparatus provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation
[0024] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0025] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0026] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0027] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."
[0028] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0029] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0030] To address the issues of low testing efficiency and poor accuracy in existing cross-frame system testing, this application provides a cross-frame system testing method. This method, upon receiving a frame switching command, acquires the test page data of the target device within the current frame, then transforms the coordinates of each element to the target frame to obtain the absolute coordinates of each element. Finally, based on the absolute coordinates of all elements, it switches from the current frame to the target frame to continue executing system testing on the target device. Specifically, transforming the element coordinates of the test page to the target frame enables accurate positioning of elements across different test frames, resolving the positioning drift problem caused by coordinate system inconsistencies. This effectively improves the accuracy of cross-frame system testing. Furthermore, this method eliminates the need for forced process closure or restart, reducing test interruptions during frame switching and improving system testing efficiency.
[0031] The following is an illustrative example of the cross-framework system testing method provided in this application.
[0032] like Figure 1 As shown, the cross-framework system testing method provided in this application includes the following steps: Step 11: When a framework switching instruction is received, obtain the test page data of the target device under the current framework.
[0033] The target device mentioned above is the device used for system testing. The framework switching command mentioned above is issued by the gateway of the target device to indicate the start of the test framework switch. The test page data mentioned above includes the coordinates of multiple elements in the test page (i.e., the test interface) of the target device (these coordinates are in the coordinate system used by the current framework). The elements are the basic interactive or displayable units in the test page (such as test command buttons such as "Start Device", "Issue Test Command", and "Stop Data Acquisition"). The current framework mentioned above can be the Appium framework.
[0034] For example, the getPageSource() interface can be used to obtain test page data.
[0035] It should be noted that when a frame switching instruction (such as switch_to("u2")) is received, the data writing of the current frame is blocked, and a simulated heartbeat is started to keep the current frame alive.
[0036] Step 12: Transform the coordinates of each element to the target frame to obtain the absolute coordinates of each element.
[0037] The target framework mentioned above can be the U2 framework.
[0038] In some embodiments of this application, the step of transforming the coordinates of each element to the target frame to obtain the absolute coordinates of each element includes: The first step is to obtain the target device's physical width, physical height, and system bar height.
[0039] For example, the ADB command dumpsys window can be used to obtain the physical width, physical height, and system bar height of the target device (referring to the vertical size of the native system UI bar at the top or bottom of the device screen).
[0040] The second step is to transform the coordinates of each element to the target frame based on the device's physical width, device's physical height, and system bar height, thereby obtaining the element's absolute coordinates.
[0041] Specifically, through the formula:
[0042]
[0043] Calculate the absolute coordinates of the elements .
[0044] in, The x-coordinate of the element. y is the ordinate of the element. This represents the ratio of the device's physical width to its logical width. This represents the ratio of the device's physical height to its logical height. , This is the screen edge compensation value. Indicates the height of the system bar.
[0045] It's important to note that the underlying APIs of the UiAutomator2 (U2) framework (such as click(), swipe(), longClick(), etc.) only support absolute screen coordinates (with the top-left corner of the device screen as the origin (0,0) and the bottom-right corner as the maximum coordinates (device physical width, device physical height)). These interfaces directly manipulate the physical touch layer of the screen and must be passed absolute coordinates based on physical pixels. Appium obtains logical coordinates from the WebContext. Without formula conversion, U2 will be unable to interpret the coordinate meaning, resulting in operation failures such as invalid clicks, clicks at incorrect locations, and misaligned swipes. Absolute coordinates are a necessary prerequisite for U2 to perform UI interaction operations.
[0046] Step 13: Switch from the current frame to the target frame according to the absolute coordinates of all elements, and continue to perform system testing on the target device.
[0047] In some embodiments of this application, the steps of switching from the current frame to the target frame according to the absolute coordinates of all elements and continuing to perform system testing on the target device include: The first step is to switch instance execution control from the current framework to the target framework.
[0048] Specifically, pause instance operations in the current framework, release the lock on the current framework, release the instance execution rights of the current framework, and transfer the instance execution rights (such as the execution rights of the Instrumentation instance) to the target framework.
[0049] For example, the main monitoring thread listens to ADB channel data in real time. Upon receiving a data packet containing a thread handover signature, it immediately interrupts its current task, parses the data packet type (confirming it's an "Appium→U2" switching instruction), and sends a "pause signal" to the Appium worker thread (Thread-A). Upon receiving the signal, Thread-A immediately stops its current Instrumentation instance operation (if an instruction is being executed, it waits for the instruction to complete before pausing), and calls the `unlock()` method of `ReentrantLock` to release its hold on the unique Instrumentation instance. The main monitoring thread then wakes up the U2 worker thread (Thread-B, which by default blocks and waits using the `Object.wait()` method) which is in a "waiting state." Once awakened, Thread-B immediately calls the `lock()` method of `ReentrantLock` to preempt the execution rights of the Instrumentation instance.
[0050] The second step is to perform test operations based on the absolute coordinates of all elements within the target framework to achieve system testing of the target device.
[0051] Specifically, after obtaining instance execution rights, instance tests are continued to be executed within the target framework to achieve system testing of the target device.
[0052] The system parses U2 commands and absolute coordinates from data packets, calls the resident Instrumentation instance in memory to execute the corresponding operation (such as clicking or swiping), and encapsulates the execution result (success / failure, return value) into JSON format and feeds it back to the gateway through the ADB multiplexing channel.
[0053] The daemon updates the "thread execution status table", marks the current execution right as thread U2 (Thread-B), and notifies the main monitoring thread to continue listening for subsequent switching instructions.
[0054] For example, when Appium encounters a "Permission Request" pop-up (system-level) during login, it cannot locate the desired position. The gateway issues a switch command, and the Appium thread suspends. After the U2 thread takes over, it uses pre-calculated absolute coordinates, such as (X=500, Y=1200), to directly click the "Allow" button on the pop-up. After clicking, Thread-B reports the result: {"status": 0, "msg": "click success", "data": null}; the daemon updates the status table: "Current execution right: U2 thread", awaiting further instructions.
[0055] It's important to note that upon receiving the `switch_to("appium")` instruction, the gateway initiates a reverse switching process, switching back from U2 exclusive mode to Appium mode. The core objective is to return execution control from the U2 thread to the Appium thread, restoring the Appium framework to its normal working state, without restarting the app or losing session state. The specific implementation process roughly consists of five steps: 1. The gateway stops simulating heartbeats and prepares to unlock the channel: The script sends switch_to("appium") to immediately terminate the "Appium Session simulated heartbeat" thread (which originally sent Ping requests to the Appium Server every so often to trick the Server into thinking the client was online).
[0056] 2. Reverse handover of execution control of the target device daemon process: U2 Thread Pause and Lock Release: After receiving the reverse switching signal, the main monitoring thread of the target device sends a "pause signal" to the U2 thread (Thread-B). After Thread-B completes the currently executing U2 instruction, it calls the ReentrantLock.unlock() method to release the right to occupy the Instrumentation instance. Appium Thread Wake-up and Lock Acquisition: The main monitoring thread wakes up the Appium thread (Thread-A) that is in a "suspended state". After Thread-A is woken up, it immediately calls the ReentrantLock.lock() method to reclaim the exclusive execution rights of the Instrumentation instance. Thread state update: The dual-mode daemon updates the "Thread Execution Right Status Table", marks the current execution right as "Appium Thread (Thread-A)", and sends a "Reverse Switching Ready Complete" signal to the PC gateway.
[0057] 3. Unlock the Appium channel at the gateway and resume session communication: After receiving the "ready to complete" signal from the target device, the PC gateway immediately unlocks the Appium channel and forwards the Appium commands (such as retrieving page elements and inputting text) in the cache queue to the Appium Server. The gateway sends a "reconnection request" to the Appium Server, carrying the original Session ID. After the Appium Server verifies the validity of the Session, it resumes normal communication with the test script (because of the previous simulated heartbeat, the Session was not timed out and its state is fully preserved). If necessary, the gateway will also perform a reverse conversion from "U2 absolute coordinates to Appium relative coordinates" to restore the element coordinates after the U2 operation to an Appium-compatible format for use by subsequent Appium commands.
[0058] 4. Appium threads resume normal operation: After the Appium thread (Thread-A) on the target device acquires execution rights to the Instrumentation instance, it resumes listening for instructions from the Appium Server. Thread-A receives instructions from the Appium Server, calls the Instrumentation instance to execute the corresponding operation, and the operation result is fed back to the Appium Server through the ADB multiplexing channel, and then fed back to the test script by the Server. At this time, the context of the Appium framework (page state, element cache, session information, etc.) is completely consistent with that before the switch, and the test script can seamlessly continue to execute subsequent processes without re-initializing or restarting the App.
[0059] 5. Resource reuse and maintenance: After the reverse switch is completed, the ADB physical channel remains in multiplexing state, and the gateway continues to monitor the channel connection status to ensure that the Appium channel and the U2 channel share the same Socket connection. The U2 thread of the dual-mode daemon process of the target device re-enters the "waiting state" to wait for the next switch instruction. The Instrumentation instance remains resident in memory and is not destroyed, providing a basis for subsequent switches.
[0060] For example, the specific implementation code of this application is as follows: #1. Initial state: The Appium framework is performing operations; driver=webdriver.Remote("http: / / 127.0.0.1:4723 / wd / hub",desired_caps); driver.find_element(By.ID,"username").send_keys("test"); #Appium operations; driver.find_element(By.ID,"password").send_keys("123456"); #2. Switch to the U2 framework and perform system-level pop-up handling (Appium cannot handle this efficiently). switch_to("u2"); u2_click(x=150,y=300); #U2 absolute coordinate operation, close system pop-up window; u2_swipe(x1=200,y1=500,x2=200,y2=300); #3. Switch back to the Appium framework (triggering step S4 reverse recovery process); switch_to("appium"); #4. Tests can continue seamlessly (no need to re-initialize, page state is preserved); driver.find_element(By.ID,"login_btn").click(); #Continue with the Appium operation to verify the login result; assert "Login successful" in driver.page_source.
[0061] It is worth mentioning that by converting the element coordinates of the test page to the target frame, the coordinate position of the element can be located in different test frames, which solves the positioning drift problem caused by the inconsistency of coordinate systems and effectively improves the accuracy of cross-frame system testing. Moreover, this method does not require the execution of steps such as forcibly closing the process or restarting, reducing test interruptions when switching frames and improving system testing efficiency.
[0062] In addition, this application has the following technical advantages: 1. Zero context loss: The "restart service" mechanism has been abandoned. The switching process does not reload or refresh the page, and memory data (such as CAPTCHA cache) is completely preserved.
[0063] 2. Improved switching efficiency: Compared to the waiting time of traditional solutions, the switching based on thread locks in this solution is only in milliseconds.
[0064] 3. Precise coordinates: Automatically compensates for differences in status bar height and resolution, solving the click displacement problem when using heterogeneous frames.
[0065] 4. High stability: By using connection reuse and heartbeat spoofing at the gateway layer, Binder transaction failures and Socket timeouts are effectively avoided.
[0066] The following is an exemplary description of the cross-framework system testing apparatus provided in this application.
[0067] like Figure 2 As shown, this application embodiment provides a cross-framework system testing apparatus, the cross-framework system testing apparatus 200 including: The acquisition module 201 is used to acquire the test page data of the target device under the current framework when a framework switching instruction is received; the test page data includes the coordinates of multiple elements in the test page of the target device; Switching module 202 is used to transform the coordinates of each element to the target frame to obtain the absolute coordinates of each element; Test module 203 is used to switch from the current frame to the target frame according to the absolute coordinates of all elements, and continue to perform system tests on the target device.
[0068] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.
[0069] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0070] like Figure 3 As shown, an embodiment of this application provides a terminal device, wherein the terminal device D10 of this embodiment includes: at least one processor D100 ( Figure 3 The diagram shows only one processor, a memory D101, and a computer program D102 stored in the memory D101 and executable on the at least one processor D100, wherein the processor D100 executes the computer program D102 to implement the steps in any of the above method embodiments.
[0071] Specifically, when the processor D100 executes the computer program D102, upon receiving a frame switching instruction, it acquires the test page data of the target device under the current frame, then transforms the coordinates of each element to the target frame to obtain the absolute coordinates of each element. Finally, based on the absolute coordinates of all elements, it switches from the current frame to the target frame to continue executing the system test on the target device. Transforming the element coordinates of the test page to the target frame enables the positioning of elements in different test frames, solving the positioning drift problem caused by inconsistencies in coordinate systems. This effectively improves the accuracy of cross-frame system testing. Furthermore, this method eliminates the need for forced process closure or restart, reducing test interruptions during frame switching and improving system testing efficiency.
[0072] The processor D100 can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.
[0073] In some embodiments, the memory D101 may be an internal storage unit of the terminal device D10, such as a hard disk or memory of the terminal device D10. In other embodiments, the memory D101 may be an external storage device of the terminal device D10, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the terminal device D10. Furthermore, the memory D101 may include both internal and external storage units of the terminal device D10. The memory D101 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory D101 can also be used to temporarily store data that has been output or will be output.
[0074] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.
[0075] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments above.
[0076] If the integrated unit is implemented as 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, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a cross-framework system testing method apparatus / terminal device, recording media, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.
[0077] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0078] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0079] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention.
Claims
1. A cross-framework system testing method, characterized in that, include: When a framework switching instruction is received, the test page data of the target device under the current framework is obtained; The test page data includes the coordinates of multiple elements in the test page of the target device; Transform the coordinates of each element to the target frame to obtain the absolute coordinates of each element; Based on the absolute coordinates of all elements, switch from the current frame to the target frame and continue performing system testing on the target device.
2. The system testing method according to claim 1, characterized in that, The step of transforming the coordinates of each element to the target frame to obtain the absolute coordinates of each element includes: Obtain the physical width, physical height, and system bar height of the target device; For each element, based on the device's physical width, device's physical height, and system bar height, the element's coordinates are transformed to the target frame to obtain the element's absolute coordinates.
3. The system testing method according to claim 2, characterized in that, The step of transforming the coordinates of the element to the target frame based on the device resolution, pixel density, and system bar height to obtain the absolute coordinates of the element includes: Through the formula: Calculate the absolute coordinates of the elements ; in, The x-coordinate of the element. y is the ordinate of the element. This represents the ratio of the device's physical width to its logical width. This represents the ratio of the device's physical height to its logical height. , This is the screen edge compensation value. Indicates the height of the system bar.
4. The system testing method according to claim 3, characterized in that, The step of switching from the current frame to the target frame according to the absolute coordinates of all elements, and continuing to perform system testing on the target device, includes: Switch instance execution rights from the current framework to the target framework; Within the target framework, test operations are performed based on the absolute coordinates of all elements to achieve system testing of the target device.
5. The system testing method according to claim 4, characterized in that, The step of switching instance execution rights from the current framework to the target framework includes: Suspend the instance operation of the current framework, release the lock on the current framework, release the instance execution rights of the current framework, and transfer the instance executor to the target framework.
6. The system testing method according to claim 5, characterized in that, When a framework switching instruction is received, the system testing method further includes: Block data writing to the current frame and enable simulated heartbeat to keep the current frame alive.
7. A cross-frame system testing device, characterized in that, include: The acquisition module is used to acquire test page data of the target device under the current framework when a framework switching instruction is received; The test page data includes the coordinates of multiple elements in the test page of the target device; A switching module is used to transform the coordinates of each element to the target frame to obtain the absolute coordinates of each element; The testing module is used to switch from the current frame to the target frame according to the absolute coordinates of all elements, and continue to perform system testing on the target device.
8. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the cross-framework system testing method as described in any one of claims 1 to 6.
9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the cross-framework system testing method as described in any one of claims 1 to 6.