Compatibility test method and system for applet, storage medium and program product
By using dynamic sandbox technology and adaptive component injection, the problems of high cost and limited coverage in mini-program compatibility testing are solved, enabling efficient and low-cost compatibility testing across platforms.
Patent Information
- Application Number
- CN202511499889.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-20
- Publication Date
- 2026-03-03
AI Technical Summary
Existing methods for testing the compatibility of mini-programs require the use of real devices, resulting in high testing costs and limited coverage.
By obtaining the code package and test parameters of the mini-program under test, an environment description file is generated. An isolated test environment is created using a dynamic sandbox engine. Target adaptation components are selected from a preset resource pool and injected into the sandbox instance. Test cases are executed using test scripts to obtain test results.
Dynamically configure test parameters, build different test environments, be compatible with the interface differences of different test platforms, reduce testing costs, improve coverage, and eliminate the need for real device testing.
Smart Images
Figure CN121597557A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software testing technology, and in particular to a compatibility testing method, system, storage medium, and program product for a mini-program. Background Technology
[0002] As more and more applications are installed on electronic devices (such as smartphones, tablets, and personal computers), these devices are becoming increasingly bloated, making lightweight mini-programs increasingly popular. To ensure that mini-programs function correctly on different models, platforms, and versions, compatibility testing is necessary. However, existing mini-program compatibility testing methods typically rely on traditional real devices, requiring the use of various real mobile devices with different versions of multiple platforms installed, followed by running automated scripts or manually performing compatibility tests. This results in high testing costs and limited test coverage. Summary of the Invention
[0003] This application provides a method, system, storage medium, and program product for compatibility testing of mini-programs, in order to solve the problems of high testing costs and limited test coverage in existing mini-program compatibility testing methods.
[0004] In a first aspect, embodiments of this application provide a compatibility testing method for a mini-program, the method comprising: Obtain the code package of the mini-program to be tested and the test parameters used to test the mini-program to be tested, wherein the test parameters support dynamic configuration; Based on the code package of the mini-program to be tested and the test parameters, an environment description file is generated; The environment description file is parsed using a dynamic sandbox engine, and a sandbox instance is created based on the parsing results. The sandbox instance is used to provide an isolated test environment that meets the requirements of the test parameters. Select a target adaptation component from a preset resource pool and inject the target adaptation component into the sandbox instance. The preset resource pool contains multiple adaptation components. Different adaptation components among the multiple adaptation components are used to be compatible with the interface differences of different test platforms and expose a unified standard interface to the test script. The target adaptation component is the adaptation component among the multiple adaptation components that matches the test parameters. The test script is used to call the standard interface to execute test cases and obtain test results.
[0005] Optionally, the test parameters include equipment parameters and platform parameters; The process of generating an environment description file based on the code package of the mini-program under test and the test parameters includes: According to the preset rule template, the device parameters, the platform parameters, and the code package of the mini-program under test are concatenated to obtain a structured data file. The preset rule template is used to constrain the concatenation rules of the device parameters, platform parameters, and the code package of the mini-program under test. The structured data file is identified as the environment description file.
[0006] Optionally, the device parameters and platform parameters are determined and configured based on historical compatibility issue data, or are automatically predicted based on artificial intelligence models.
[0007] Optionally, the platform parameters include platform type and platform version; The step of selecting a target adaptation component from a preset resource pool and injecting the target adaptation component into the sandbox instance includes: Select an adaptation component from the preset resource pool that matches the platform type and the platform version, and determine the selected adaptation component as the target adaptation component; Inject the target adaptation component into the sandbox instance.
[0008] Optionally, before selecting the compatible component matching the platform type and platform version from the preset resource pool, the method further includes: Obtain the interface differences for each platform type across different platform versions; The interface differences are standardized and mapped to obtain multiple adaptation components for each platform type under different platform versions; Based on the aforementioned multiple adaptation components, the preset resource pool is established.
[0009] Optionally, after executing test cases by calling the standard interface using the test script and obtaining test results, the method further includes: By comparing the test results corresponding to different sandbox instances, a comparison result is obtained, wherein the test result includes user interface images, interface response data and / or log data; Based on the comparison results, a test report is generated and displayed, wherein data in the test report that show differences are highlighted.
[0010] Optionally, after executing test cases by calling the standard interface using the test script and obtaining test results, the method further includes: Send a sandbox release command to the dynamic sandbox engine to release the sandbox instance using the dynamic sandbox engine.
[0011] Secondly, embodiments of this application also provide a testing system, which includes a user interaction module, an environment configuration generation module, a dynamic sandbox engine, a cross-platform difference adaptation module, an automated testing module, and a difference analysis module. The user interaction module is used to receive the code package of the mini-program under test and the test parameters for testing the mini-program under test input by the user, and send the received code package of the mini-program under test and the test parameters to the environment configuration generation module, wherein the test parameters support dynamic configuration. The environment configuration generation module is used to generate an environment description file based on the code package of the mini-program under test and the test parameters, and send the environment description file to the dynamic sandbox engine; The dynamic sandbox engine is used to parse the environment description file and create a sandbox instance based on the parsing result. The sandbox instance is used to provide an isolated test environment that meets the test parameter requirements. The cross-platform difference adaptation module is used to select a target adaptation component from a preset resource pool and inject the target adaptation component into the sandbox instance. The preset resource pool stores multiple adaptation components in advance. Different adaptation components among the multiple adaptation components are used to be compatible with the interface differences of different test platforms and expose a unified standard interface to the test script. The target adaptation component is the adaptation component among the multiple adaptation components that matches the test parameters. The automated testing module is used to call the standard interface using the test script to execute test cases and obtain test results. The difference analysis module is used to perform difference analysis on the test results and return the difference analysis results to the user interaction module. The user interaction module is also used to display the results of the difference analysis.
[0012] Thirdly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the compatibility testing method for the applet described in the first aspect.
[0013] Fourthly, embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the compatibility testing method for the applet described in the first aspect.
[0014] The technical solutions provided in this application have the following advantages compared with the prior art: The method provided in this application embodiment involves: acquiring the code package of the mini-program under test and test parameters for testing the mini-program under test, wherein the test parameters support dynamic configuration; generating an environment description file based on the code package of the mini-program under test and the test parameters; parsing the environment description file using a dynamic sandbox engine and creating a sandbox instance based on the parsing result, wherein the sandbox instance provides an isolated test environment that meets the requirements of the test parameters; selecting a target adaptation component from a preset resource pool and injecting the target adaptation component into the sandbox instance, wherein the preset resource pool pre-stores multiple adaptation components, and different adaptation components among the multiple adaptation components are used to be compatible with the interface differences of different test platforms and expose a unified standard interface to the test script; the target adaptation component is the adaptation component among the multiple adaptation components that matches the test parameters; and using the test script to call the standard interface to execute test cases and obtain test results. The above methods enable dynamic configuration of test parameters according to different testing needs, thereby constructing different test environments and improving test coverage. At the same time, by injecting target adaptation components that match the test parameters into the sandbox instance, test scripts can call the standard interfaces provided by the target adaptation components for testing, thus ensuring compatibility with the interface differences of different test platforms and meeting the cross-platform testing needs of mini-programs without relying on traditional real devices, thereby reducing testing costs. Attached Figure Description
[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 This is a schematic diagram of the structure of a testing system provided in an embodiment of this application; Figure 2 A flowchart illustrating a compatibility testing method for a mini-program provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of another testing system provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of a compatibility testing device for a mini-program provided in an embodiment of this application; Figure 5 This is a schematic diagram of a testing device provided in an embodiment of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0019] The compatibility testing method for mini-programs provided in this application can be applied to a testing system. This testing system can be implemented by a cloud platform (such as a cloud server), a terminal (such as a mobile phone, personal computer, tablet, etc.), or a combination of both. This application does not impose specific limitations. For ease of understanding, the following explanation uses a cloud platform as an example of a testing system. This testing system may include a user interaction module, an environment configuration generation module, a dynamic sandbox engine, a cross-platform difference adaptation module, an automated testing module, and a difference analysis module, such as... Figure 1 As shown in the diagram. The user interaction module provides a user interface for configuring test parameters, uploading the code package of the mini-program under test, and viewing test reports. The environment configuration generation module generates an environment description file based on the user-configured test parameters and a preset rule template, then passes it to the dynamic sandbox engine. This dynamic sandbox engine can create isolated test environments based on container or virtual machine technology, enabling the mini-program to run in different simulated environments (such as different operating system versions, different memory, different screen resolutions, different network conditions, etc.). The cross-platform difference adaptation module handles API differences between different platforms and injects appropriate adaptation components into the sandbox instance to ensure that test scripts can run in different environments. The automated testing module uses test scripts to call standard interfaces to execute test cases and obtain test results. It can execute multiple test cases in parallel and record test results, such as UI rendering, API response, and performance metrics (such as refresh rate, memory leaks, etc.). The difference analysis module can locate cross-platform inconsistencies through image comparison (such as document object model (DOM) tree and pixel-level comparison), API return data analysis, and log analysis.
[0020] See Figure 2 , Figure 2 This is a flowchart illustrating a compatibility testing method for a mini-program provided in an embodiment of this application. Figure 2 As shown, the compatibility testing method for this mini-program may include the following steps: Step S201: Obtain the code package of the mini-program to be tested and the test parameters used to test the mini-program to be tested. The test parameters support dynamic configuration.
[0021] It should be noted that the compatibility testing method for mini-programs provided in this application can be applied to cloud platforms or local devices. For ease of explanation, subsequent embodiments will use a cloud platform as an example.
[0022] Specifically, the aforementioned mini-program to be tested can be any mini-program that requires compatibility testing. The aforementioned test parameters refer to the device parameters (such as device model, operating system version, resolution, etc.) and platform parameters (such as platform type, platform version, etc.) required for participating in the compatibility testing of the mini-program to be tested. These test parameters are used to simulate the test environment for the compatibility testing of the mini-program to be tested.
[0023] When obtaining the code package of the mini-program to be tested, the user can upload the code package to the cloud platform for acquisition. When obtaining test parameters, the user can manually configure them on the cloud platform, or the cloud platform can automatically predict them based on an artificial intelligence model; this application embodiment does not impose specific limitations.
[0024] Step S202: Generate an environment description file based on the code package and test parameters of the mini-program to be tested.
[0025] Specifically, the aforementioned environment description file refers to a file describing the test environment obtained according to a preset rule template, which can be used to guide the generation of the test environment.
[0026] Step S203: Use the dynamic sandbox engine to parse the environment description file and create a sandbox instance based on the parsing results. The sandbox instance is used to provide an isolated test environment that meets the test parameter requirements.
[0027] Specifically, the aforementioned dynamic sandbox engine is used to create isolated test environments through virtualization technologies (such as virtual machines, containers, etc.), allowing each test process to be completed within its own space. The sandbox instance described above can provide an isolated test environment that meets the requirements of the test parameters. It can simulate the hardware (such as CPU / GPU / sensor type, etc.) and software environment (such as permission configuration, etc.) of the test equipment, and supports dynamically injecting abnormal conditions (such as simulated conditions like network latency, low battery, etc.).
[0028] Step S204: Select the target adaptation component from the preset resource pool and inject the target adaptation component into the sandbox instance. The preset resource pool contains multiple adaptation components. Different adaptation components among the multiple adaptation components are used to be compatible with the interface differences of different test platforms and expose a unified standard interface to the test script. The target adaptation component is the adaptation component among the multiple adaptation components that matches the test parameters.
[0029] Specifically, the aforementioned pre-set resource pool can store multiple adaptation components. Different adaptation components can be compatible with the interface differences of different testing platforms and expose a unified standard interface to the test scripts for easy invocation. For example, assuming that the mini-program under test needs to perform compatibility tests on platform 1, platform 2, and platform 3 respectively during the testing process, adaptation components for platform 1, platform 2, and platform 3 can be pre-created. In this way, after the sandbox instances for each platform are created, the adaptation components for each platform can be injected into the respective sandbox instances for the test scripts to invoke.
[0030] Step S205: Use the test script to call the standard interface to execute the test cases and obtain the test results.
[0031] Specifically, the test scripts and test cases mentioned above are pre-written. The standard interfaces mentioned above are exposed to the test scripts by the target adaptation components. The test results mentioned above may include, but are not limited to, user interface images, interface response data, log data, etc.
[0032] In this embodiment, test parameters can be dynamically configured according to different test requirements, thereby constructing different test environments and improving test coverage. At the same time, by injecting target adaptation components that match the test parameters into the sandbox instance, the test script can call the standard interface provided by the target adaptation component for testing, thereby being compatible with the interface differences of different test platforms and meeting the cross-platform testing requirements of mini-programs without relying on traditional real devices, thus reducing testing costs.
[0033] In an optional embodiment, the test parameters include device parameters and platform parameters; step S202 above, generating an environment description file based on the code package of the app under test and the test parameters, includes: According to the preset rule template, the device parameters, platform parameters and the code package of the mini-program under test are concatenated to obtain a structured data file. The preset rule template is used to constrain the concatenation rules of the device parameters, platform parameters and the code package of the mini-program under test. The structured data file is identified as the environment description file.
[0034] Specifically, the aforementioned preset rule template can be used to constrain the concatenation rules of device parameters, platform parameters, and the code package of the mini-program under test, thereby obtaining a standard environment description file. As an optional implementation, the rule template can be a JSON data template. It requires the user to select test parameters and upload the code package according to the fields in this JSON structure; otherwise, an environment description file cannot be generated. The JSON structure of this rule template can be as follows: { Device parameters: {"Device Model": "e.g., a specific model from a particular mobile phone manufacturer", "System": "such as iOS, Android, HarmonyOS, etc." Version: "e.g., 15.0, 11, 3.0, etc." "Screen resolution": "e.g., 375x812 (iPhone 13), 414x896 (iPhone 11), 360x780 (common on Android), etc." Device Pixel Ratio (DPR): "e.g., 2.0, 3.0, etc." "Network environment simulation": "such as Wireless Fidelity (WiFi), Fourth Generation Mobile Communication Technology (4G), Third Generation Mobile Communication Technology (3G), Second Generation Wireless Telephone Technology (2G), weak network (packet loss rate / latency / bandwidth limitations), offline, etc." "System language": "such as Chinese, English, etc." "Time Zone": "e.g., Coordinated Universal Time (UTC) + 8", "Font size": "e.g., standard, large, extra large, etc." "Other": "Such as GPS location permissions, camera permissions, Bluetooth status, storage space limits, battery level, etc." Platform parameters: {"Platform Type":"such as Platform 1, Platform 2, Platform 3, etc."} "Platform version": "e.g., version 2.0.0 - 2.25.0 for platform 1, version 10.1.60 - 10.2.80 for platform 2, etc." "Test Mini Program": The code package of the mini program to be tested } Using the above method, device parameters, platform parameters, and the code package of the mini-program under test can be concatenated according to preset rule templates to obtain an environment description file, which facilitates the subsequent simulation of an isolated test environment by the dynamic sandbox engine based on this environment description file.
[0035] In one alternative embodiment, the device parameters and platform parameters are determined and configured based on historical compatibility issue data, or are automatically predicted based on an artificial intelligence model.
[0036] As an optional implementation, the aforementioned device and platform parameters can be determined by the user based on historical compatibility issue data and then manually configured. For example, assuming the user knows from historical compatibility issue data that the user interface (UI) of the app under test will differ across platforms under the parameter combination of "iOS 15.4 system + low memory mode + notch screen", the user can configure the app according to this parameter combination to obtain test data.
[0037] As another alternative implementation, the aforementioned device and platform parameters can be automatically predicted based on artificial intelligence models (such as DeepSeek models, OpenAI models, etc.). For example, assuming that the artificial intelligence model, based on big data analysis, determines that the combination of "low-end Android devices + 2G networks + high-brightness screens" is commonly used in Southeast Asia, the artificial intelligence model can automatically configure this parameter combination to obtain test data.
[0038] The above methods allow users to customize test data or automatically determine test data based on artificial intelligence models, thereby achieving greater coverage and meeting the testing needs of various scenarios.
[0039] In an optional embodiment, the platform parameters include platform type and platform version; step S204 above, selecting the target adaptation component from the preset resource pool and injecting the target adaptation component into the sandbox instance, includes: Select compatible components from the preset resource pool that match the platform type and platform version, and determine the selected compatible components as the target compatible components; Inject the target adaptation component into the sandbox instance.
[0040] Specifically, different platform types require different adapter components. Within the same platform type, different platform versions may use the same or different adapter components, depending on the interface differences between the platform versions. Therefore, when determining the target adapter component, both platform type and platform version parameters need to be considered to identify a target adapter component that matches both.
[0041] When cross-platform compatibility testing is required, multiple adaptable components of any version under multiple different platform types can be selected and injected into multiple independent sandbox instances. This allows the test environment of each platform to be simulated in multiple independent sandbox instances to perform cross-platform compatibility testing.
[0042] When cross-version compatibility testing is required, multiple adaptation components of different versions under the same platform type can be selected and injected into multiple independent sandbox instances. This allows the test environment of different versions of the platform to be simulated in multiple independent sandbox instances for cross-version compatibility testing.
[0043] Using the above methods, the required target adaptation components can be accurately determined based on the platform type and platform version, thereby accurately simulating the required test environment to meet the testing needs of cross-platform compatibility testing, cross-version compatibility testing, etc.
[0044] In an optional embodiment, before step S204 above, which involves selecting an adaptation component from a preset resource pool that matches the platform type and platform version, the method further includes: Obtain the interface differences for each platform type across different platform versions; Standardize the mapping of interface differences to obtain multiple adaptation components for each platform type under different platform versions; A preset resource pool is established based on multiple adaptable components.
[0045] Specifically, when establishing a pre-defined resource pool, the interface differences for each platform type across different platform versions can be obtained through Hook technology (a programming technique used to insert custom logic when a specific event occurs) or the platform's Application Programming Interface (API) documentation. These interface differences can be determined based on the interface's naming conventions, parameter settings, and behavior. Then, these interface differences are standardized and mapped. This standardization includes, but is not limited to, parameter conversion and behavior correction. This yields multiple adaptable components for each platform type across different platform versions. Based on these adaptable components, a pre-defined resource pool is then established. This allows for the injection of appropriate adaptable components into the sandbox instance after each instance creation, ensuring compatibility with interface differences across different testing platforms and exposing a unified standard interface for test scripts.
[0046] In an optional embodiment, after step S205 above, where the test case is executed by calling the standard interface using the test script and the test result is obtained, the method further includes: Compare the test results corresponding to different sandbox instances to obtain comparison results, which include user interface images, interface response data and / or log data; Based on the comparison results, a test report is generated and displayed, with data showing discrepancies highlighted.
[0047] Specifically, after obtaining the test results for each sandbox instance, the cloud platform can compare the test results for different sandbox instances to obtain comparative results, such as comparisons of user interface images, interface response performance, and log data. Based on these comparison results, a test report can be generated and displayed, facilitating user viewing and comparative analysis.
[0048] In an optional implementation, after step S205 above, where the test cases are executed by calling the standard interface using the test script and the test results are obtained, the method further includes: Send a sandbox release command to the dynamic sandbox engine to release the sandbox instance using the dynamic sandbox engine.
[0049] Specifically, after the cloud platform completes the test, it can send sandbox release commands such as DELETE / sandbox / {id} to the dynamic sandbox engine. In this way, the dynamic sandbox engine can persist valuable states (such as crash logs) to the object storage service (OSS) and release the sandbox instance, thereby releasing unused resources in a timely manner and improving the overall performance of the cloud platform.
[0050] See Figure 3 , Figure 3 This is a schematic diagram of the structure of a testing system provided in an embodiment of this application, such as... Figure 3 As shown, the testing system includes a user interaction module 301, an environment configuration generation module 302, a dynamic sandbox engine 303, a cross-platform difference adaptation module 304, an automated testing module 305, and a difference analysis module 306. The user interaction module 301 is used to receive the code package of the mini-program under test and the test parameters for testing the mini-program under test input by the user, and sends the received code package of the mini-program under test and the test parameters to the environment configuration generation module 302. The test parameters support dynamic configuration. The environment configuration generation module 302 is used to generate an environment description file based on the code package and test parameters of the mini-program under test, and send the environment description file to the dynamic sandbox engine 303; The dynamic sandbox engine 303 is used to parse environment description files and create sandbox instances based on the parsing results. The sandbox instance is used to provide an isolated test environment that meets the test parameter requirements. The cross-platform difference adaptation module 304 is used to select the target adaptation component from the preset resource pool and inject the target adaptation component into the sandbox instance. The preset resource pool contains multiple adaptation components. Different adaptation components among the multiple adaptation components are used to be compatible with the interface differences of different test platforms and expose a unified standard interface to the test script. The target adaptation component is the adaptation component that matches the test parameters among the multiple adaptation components. The automated testing module 305 is used to execute test cases by calling standard interfaces using test scripts and obtain test results; The difference analysis module 306 is used to perform difference analysis on the test results and return the difference analysis results to the user interaction module 301. User interaction module 301 is also used to display the results of difference analysis.
[0051] Specifically, the user interaction module 301 can receive the code package of the mini-program under test and the test parameters for testing the mini-program under test input by the user, and send the received code package and test parameters to the environment configuration generation module 302. The test parameters support dynamic configuration. In other words, the user interaction module 301 provides an interface for the user to configure test parameters, upload the code package of the mini-program under test, and view test reports. The environment configuration generation module 302 generates an environment description file based on the code package and test parameters of the mini-program under test, and sends the environment description file to the dynamic sandbox engine 303. That is, the environment configuration generation module 302 can generate an environment description file according to the test parameters configured by the user and a preset rule template, and then send it to the dynamic sandbox engine 303. The dynamic sandbox engine 303 parses the environment description file and creates a sandbox instance based on the parsing results. The sandbox instance provides an isolated test environment that meets the requirements of the test parameters. The dynamic sandbox engine 303 can create isolated test environments based on container or virtual machine technology, enabling the mini-program to run in different simulated environments (such as different operating system versions, different memory, different screen resolutions, different network conditions, etc.). The cross-platform difference adaptation module 304 selects the target adaptation component from a preset resource pool and injects it into the sandbox instance. The preset resource pool contains multiple adaptation components, which are used to ensure compatibility with interface differences across different test platforms and expose a unified standard interface to the test script. The target adaptation component is the one among these components that matches the test parameters. In other words, the cross-platform difference adaptation module 304 can handle API differences between different platforms and inject appropriate adaptation components into the sandbox instance to ensure that the test script can run in different environments. An adaptation component is essentially a runtime middleware designed to adapt to API differences in the same functionality across different platforms. It standardizes the mapping of native platform APIs (e.g., mapping wx.request from platform 1 and my.httpRequest from platform 2 to a unified interface uni.request). Developers pre-develop adaptation components (e.g., WeChat-JS-Bridge-Polyfill.js for platform 1 simulation, Ant-Container-Toolkit.js for platform 2 simulation, and TT-Microapp-Runtime-Shim.js for platform 3 simulation). These components are pre-built into the resource pool of the cross-platform difference adaptation module 304. When the cross-platform difference adaptation module 304 detects that a platform needs to be tested, it injects the corresponding adaptation component into the dynamic sandbox.The cross-platform compatibility module 304 exposes a unified standard interface to the automated testing module 305. Therefore, the adaptibility component ensures that when a test script operates a function of the mini-program under test, it only needs to call the unified mapped standard interface `uni.request` to access API interfaces on different platforms, thus achieving cross-platform compatibility testing (i.e., compatibility testing of the mini-program under test running in different sandbox testing environments). The automated testing module 305 uses test scripts to call standard interfaces to execute test cases and obtain test results. It can execute multiple test cases in parallel and record test results, such as UI rendering, API response, and performance metrics (e.g., refresh rate, memory leaks). The difference analysis module 306 performs difference analysis on the test results and returns the results to the user interaction module 301 for display. The difference analysis module 306 can locate cross-platform inconsistencies through image comparison (e.g., document object model (DOM) tree and pixel-level comparison), API return data analysis, and log analysis.
[0052] The compatibility testing process for mini-programs based on this testing system is as follows: 1. Issue test parameters.
[0053] Users select test parameters, such as platform parameters and device parameters, on the cloud platform operation interface, and after configuration, send them to the environment configuration generation module 302.
[0054] 2. Generate environment description files.
[0055] The environment configuration generation module 302 generates an environment description file based on the test parameters and sends it to the dynamic sandbox engine 303.
[0056] 3. Create a sandbox instance.
[0057] The dynamic sandbox engine performs a 303 parsing of the environment description file and creates a sandbox instance based on the parsing results.
[0058] 4. Send a notification that the sandbox instance creation is complete.
[0059] After the sandbox instance is created, a sandbox instance creation completion notification will be sent to the cross-platform difference adaptation module 304.
[0060] 5. Inject the adapter components.
[0061] The cross-platform adaptation module 304 injects the corresponding adaptation components into the sandbox instance (for example, the WeChat JS Bridge Polyfill adaptation component is injected into the platform 1 environment, and the Ant Container Toolkit adaptation component is loaded into the platform 2 environment). Each sandbox instance mounts a unique file system view (used to achieve independent isolation between different sandbox instances; if there are multiple sandbox instances, multiple file system views are mounted), thus completing the test environment. The file system view is a virtualized, dynamically configurable directory mapping layer. It can place the sandbox instances (test environment spaces for different platforms) created by the dynamic sandbox engine 303 under different virtual system directories, thereby achieving test environment isolation.
[0062] 6. Start automated testing.
[0063] 7. Call the standard interface.
[0064] When the cloud platform calls the automated testing module 305, the test script calls the standard interface to execute test cases. This standardized instruction means that when the test script executes a functional test, it only needs to access the standard interface uni.request provided by the cross-platform difference adaptation module 304. The adaptation component, which has been injected with a sandbox instance, will access the corresponding platform API and return response data to the cross-platform difference adaptation module 304, which in turn returns it to the automated testing module 305, thus achieving compatibility testing across multiple platforms.
[0065] 8. Obtain test results.
[0066] Test cases are executed within the automated testing module 305. When test cases are executed, they call the standard interfaces provided by the cross-platform difference adaptation module 304, thereby accessing the APIs of different platforms according to the adaptation components to achieve cross-platform testing.
[0067] 9. Generate a test report.
[0068] After the test is completed, the difference analysis module 306 (through machine learning or image comparison technology) generates a visual test report, highlights the cross-platform differences, and then sends the test report back to the cloud platform operation interface. Then, it sends the DELETE / sandbox / {id} command to the dynamic sandbox engine 303 to persist valuable states (such as crash logs) to OSS and destroy a previously created sandbox instance, thus ending the entire compatibility testing process.
[0069] See Figure 4 , Figure 4 This is a schematic diagram of a compatibility testing device for a mini-program provided in an embodiment of this application. Figure 4 As shown, the compatibility testing device 400 for this mini-program includes: The first acquisition module 401 is used to acquire the code package of the mini-program to be tested and the test parameters used to test the mini-program to be tested. The test parameters support dynamic configuration. The first generation module 402 is used to generate an environment description file based on the code package and test parameters of the mini-program to be tested. Create module 403 to parse the environment description file using the dynamic sandbox engine and create a sandbox instance based on the parsing results. The sandbox instance is used to provide an isolated test environment that meets the test parameter requirements. The injection module 404 is used to select the target adaptation component from the preset resource pool and inject the target adaptation component into the sandbox instance. The preset resource pool contains multiple adaptation components. Different adaptation components among the multiple adaptation components are used to be compatible with the interface differences of different test platforms and expose a unified standard interface to the test script. The target adaptation component is the adaptation component among the multiple adaptation components that matches the test parameters. Execution module 405 is used to execute test cases by calling standard interfaces using test scripts and obtain test results.
[0070] Furthermore, the test parameters include device parameters and platform parameters; the first generation module 402 includes: The splicing submodule is used to splice device parameters, platform parameters, and the code package of the mini-program under test according to a preset rule template to obtain a structured data file. The preset rule template is used to constrain the splicing rules of device parameters, platform parameters, and the code package of the mini-program under test. The determination submodule is used to determine the structured data file as an environment description file.
[0071] Furthermore, the equipment parameters and platform parameters are determined and configured based on historical compatibility issue data, or are automatically predicted based on artificial intelligence models.
[0072] Furthermore, the platform parameters include platform type and platform version; the injection module 404 includes: The selection submodule is used to select the adaptation components that match the platform type and platform version from the preset resource pool, and to determine the selected adaptation components as the target adaptation components. The injection submodule is used to inject the target adaptable component into the sandbox instance.
[0073] Furthermore, the compatibility testing device 400 for the mini-program also includes: The second acquisition module is used to acquire the interface differences of each platform type under different platform versions; The mapping module is used to standardize the mapping of interface differences and obtain multiple adaptation components corresponding to each platform type under different platform versions; The module is used to create a preset resource pool based on multiple adapter components.
[0074] Furthermore, the compatibility testing device 400 for the mini-program also includes: The comparison module is used to compare the test results corresponding to different sandbox instances and obtain the comparison results. The test results include user interface images, interface response data and / or log data. The second generation module is used to generate a test report based on the comparison results and display the test report, in which data with differences are highlighted.
[0075] Furthermore, the compatibility testing device 400 for the mini-program also includes: The release module is used to send sandbox release commands to the dynamic sandbox engine so that the dynamic sandbox engine can release the sandbox instance.
[0076] It should be noted that the compatibility testing device 400 of the mini program can implement the steps of the mini program compatibility testing method provided in any of the aforementioned method embodiments, and can achieve the same technical effect, which will not be elaborated here.
[0077] like Figure 5 As shown in the illustration, this application also provides a testing device, including a processor 511, a communication interface 512, a memory 513, and a communication bus 514, wherein the processor 511, the communication interface 512, and the memory 513 communicate with each other through the communication bus 514. Memory 513 is used to store computer programs; In one embodiment of this application, the processor 511, when executing the program stored in the memory 513, implements the applet compatibility testing method provided in any of the foregoing method embodiments.
[0078] It should be noted that the testing device can be a cloud platform, a terminal device, or other devices capable of implementing the compatibility testing method for the mini-program in the above embodiments. This application does not impose specific limitations on the embodiments.
[0079] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the compatibility testing method for the applet as provided in any of the foregoing method embodiments.
[0080] In addition, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the compatibility testing method for the applet as provided in any of the foregoing method embodiments.
[0081] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0082] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.
Claims
1. A compatibility testing method for a WeChat Mini Program, characterized in that, The method includes: Obtain the code package of the mini-program to be tested and the test parameters used to test the mini-program to be tested, wherein the test parameters support dynamic configuration; Based on the code package of the mini-program to be tested and the test parameters, an environment description file is generated; The environment description file is parsed using a dynamic sandbox engine, and a sandbox instance is created based on the parsing results. The sandbox instance is used to provide an isolated test environment that meets the requirements of the test parameters. Select a target adaptation component from a preset resource pool and inject the target adaptation component into the sandbox instance. The preset resource pool contains multiple adaptation components. Different adaptation components among the multiple adaptation components are used to be compatible with the interface differences of different test platforms and expose a unified standard interface to the test script. The target adaptation component is the adaptation component among the multiple adaptation components that matches the test parameters. The test script is used to call the standard interface to execute test cases and obtain test results.
2. The method according to claim 1, characterized in that, The test parameters include equipment parameters and platform parameters; The process of generating an environment description file based on the code package of the mini-program under test and the test parameters includes: According to the preset rule template, the device parameters, the platform parameters, and the code package of the mini-program under test are concatenated to obtain a structured data file. The preset rule template is used to constrain the concatenation rules of the device parameters, platform parameters, and the code package of the mini-program under test. The structured data file is identified as the environment description file.
3. The method according to claim 2, characterized in that, The device parameters and platform parameters are determined and configured based on historical compatibility issue data, or are automatically predicted based on artificial intelligence models.
4. The method according to claim 2, characterized in that, The platform parameters include the platform type and platform version; The step of selecting a target adaptation component from a preset resource pool and injecting the target adaptation component into the sandbox instance includes: Select an adaptation component from the preset resource pool that matches the platform type and the platform version, and determine the selected adaptation component as the target adaptation component; Inject the target adaptation component into the sandbox instance.
5. The method according to claim 4, characterized in that, Before selecting the compatible component matching the platform type and platform version from the preset resource pool, the method further includes: Obtain the interface differences for each platform type across different platform versions; The interface differences are standardized and mapped to obtain multiple adaptation components for each platform type under different platform versions; Based on the aforementioned multiple adaptation components, the preset resource pool is established.
6. The method according to claim 1, characterized in that, After executing test cases by calling the standard interface using the test script and obtaining test results, the method further includes: By comparing the test results corresponding to different sandbox instances, a comparison result is obtained, wherein the test result includes user interface images, interface response data and / or log data; Based on the comparison results, a test report is generated and displayed, wherein data in the test report that show differences are highlighted.
7. The method according to claim 1, characterized in that, After executing test cases by calling the standard interface using the test script and obtaining test results, the method further includes: Send a sandbox release command to the dynamic sandbox engine to release the sandbox instance using the dynamic sandbox engine.
8. A testing system, characterized in that, The testing system includes a user interaction module, an environment configuration generation module, a dynamic sandbox engine, a cross-platform difference adaptation module, an automated testing module, and a difference analysis module. The user interaction module is used to receive the code package of the mini-program under test and the test parameters for testing the mini-program under test input by the user, and send the received code package of the mini-program under test and the test parameters to the environment configuration generation module, wherein the test parameters support dynamic configuration. The environment configuration generation module is used to generate an environment description file based on the code package of the mini-program under test and the test parameters, and send the environment description file to the dynamic sandbox engine; The dynamic sandbox engine is used to parse the environment description file and create a sandbox instance based on the parsing result. The sandbox instance is used to provide an isolated test environment that meets the test parameter requirements. The cross-platform difference adaptation module is used to select a target adaptation component from a preset resource pool and inject the target adaptation component into the sandbox instance. The preset resource pool contains multiple adaptation components, and different adaptation components among the multiple adaptation components are used to be compatible with the interface differences of different test platforms and expose a unified standard interface to the test script. The target adaptation component is the adaptation component among the multiple adaptation components that matches the test parameters. The automated testing module is used to call the standard interface using the test script to execute test cases and obtain test results. The difference analysis module is used to perform difference analysis on the test results and return the difference analysis results to the user interaction module. The user interaction module is also used to display the results of the difference analysis.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the compatibility testing method for the applet as described in any one of claims 1-7.
10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the compatibility testing method for the applet as described in any one of claims 1-7.