A method and apparatus for testing an SDK used for developing an application

Abstract

The embodiments disclosed in the specification provide a method and device for testing an SDK used for developing an application. In order to save the SDK tester from the work burden of developing an application sample for testing based on the SDK and improve the testing efficiency, a native interface of a tested function module of the SDK is encapsulated into a protocol interface. On the one hand, each protocol interface corresponding to the tested function module of the SDK is compiled into a program for testing, referred to as a tested program herein. On the other hand, the tester only needs to write a test script capable of calling the protocol interface.

Description

Technical Field

[0001] This specification relates to the field of information technology in several embodiments, and more particularly to a method and apparatus for testing an SDK used to develop applications. Background Technology

[0002] A Software Development Kit (SDK) can be understood as a collection of development tools used to develop applications. Typically, the SDK is provided to application software developers, who then use the SDK to develop their applications, which run on specific operating system platforms (such as Windows, Android, etc.).

[0003] In practice, SDK providers need to test the SDKs they provide to developers to ensure that the SDK's functionality adequately meets application development requirements. However, existing SDK testing methods are inefficient. Summary of the Invention

[0004] Several embodiments of this specification provide a method and apparatus for testing SDKs used in application development, in order to improve the testing efficiency of SDKs.

[0005] According to a first aspect of several embodiments of this specification, a method for testing an SDK used for developing applications is provided, comprising:

[0006] Based on a preset interface encapsulation protocol, several native interfaces of the tested functional module of the SDK are encapsulated into several protocol interfaces. The several native interfaces are defined according to the native language of the operating system on which the application runs, and the several protocol interfaces are defined according to a scripting language.

[0007] The program to be tested is compiled based on the aforementioned protocol interfaces, and the test script is written accordingly.

[0008] The test script is run to send test instructions to the program under test; wherein the test instructions are used to call the plurality of protocol interfaces to execute the target test task, and the target test task is used to simulate the application functions developed based on the functional module under test;

[0009] Run the program under test, and based on the test instructions, call the several native interfaces to execute the target test task.

[0010] According to a second aspect of several embodiments of this specification, a computing device is provided, including a memory and a processor; the memory is used to store computer instructions executable on the processor, and the processor is used to implement the method of the first aspect when executing the computer instructions.

[0011] According to a third aspect of several embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect.

[0012] According to four aspects of several embodiments of this specification, an apparatus for testing an SDK used for developing applications is provided, comprising:

[0013] The interface encapsulation module, based on a preset interface encapsulation protocol, encapsulates several native interfaces of the tested functional module of the SDK into several protocol interfaces, wherein the several native interfaces are defined according to the native language of the operating system on which the application runs, and the several protocol interfaces are defined according to a scripting language.

[0014] The compilation module compiles the program under test based on the aforementioned protocol interfaces and writes the test scripts.

[0015] The test instruction sending module runs the test script and sends test instructions to the program under test; wherein, the test instructions are used to call the plurality of protocol interfaces to execute the target test task, and the target test task is used to simulate the application functions developed based on the functional module under test;

[0016] The test task execution module runs the program under test, and based on the test instructions, calls the several native interfaces to execute the target test task.

[0017] In the above technical solution, to save SDK testers the burden of developing application samples for testing based on the SDK and improve testing efficiency, the native interfaces of the SDK's tested functional modules are encapsulated into protocol interfaces. On one hand, the various protocol interfaces corresponding to the SDK's tested functional modules are compiled into programs for testing, referred to as the "test program" in this paper. Since the test program is compiled from the protocol interfaces and does not involve front-end page development, it is essentially a semi-finished application product stripped of front-end display capabilities but containing at least some of the SDK's functional modules. On the other hand, only test scripts that can call the protocol interfaces need to be written. Writing test scripts is relatively simple; by using the test scripts to call the protocol interfaces in the test program, the test program can be instructed to further call the native interfaces encapsulated by the protocol interfaces to perform test tasks. Attached Figure Description

[0018] Figure 1 An example of an existing SDK testing architecture is shown.

[0019] Figure 2An exemplary illustration shows the SDK testing architecture provided in this disclosure.

[0020] Figure 3 An exemplary process is provided for testing an SDK used to develop an application.

[0021] Figure 4 This is a schematic diagram of the structure of a computing device provided in this disclosure.

[0022] In the accompanying drawings, identical or corresponding reference numerals denote identical or corresponding parts. Any number of elements in the drawings is for illustrative purposes only and not for limitation, and any naming is for distinction only and has no limiting meaning. Detailed Implementation

[0023] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0024] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0025] The current SDK testing method involves testers developing an application sample based on the SDK and installing it on the corresponding operating system platform. Testers then use this application sample to interact with its front-end page (UI). The application sample responds to UI interactions, performing various tests. Testers then evaluate the SDK's functionality based on the test results.

[0026] However, developing application samples is a significant undertaking, especially the front-end development, which poses a considerable burden for testers. For example, front-end development requires consideration of compatibility with the operating system platform on which the application sample runs, addressing the complexity of the SDK within the application sample and its calls to underlying operating system interfaces, navigating the platform's access restrictions (meaning testers can only obtain test results by observing the front-end page effects, not accessing the underlying runtime parameters), and dealing with the platform's computational resource limitations (e.g., the difficulty in readily expanding memory as needed for testing), among other challenges.

[0027] Figure 1 An example of an existing SDK testing architecture is shown. Figure 1 As shown, the application sample is installed on a specific operating system platform (such as Android). The application sample mainly includes the SDK and business layer code (mainly front-end interaction-related code). Users interact with the front-end page of the application sample to test the application sample.

[0028] This disclosure takes into account that if testing can be separated from the operating system platform environment in which the application runs, then there will be no need to spend so much effort developing application samples, especially eliminating the need for front-end development of application products to adapt to the operating system platform. This can save the workload of testers and improve testing efficiency.

[0029] Therefore, in one or more embodiments of this disclosure, to reduce the workload of SDK testers in developing application samples for testing based on the SDK and improve testing efficiency, the native interfaces of the SDK's tested functional modules are encapsulated into protocol interfaces. On one hand, the various protocol interfaces corresponding to the SDK's tested functional modules are compiled into programs for testing, referred to herein as the program under test. Since the program under test is compiled from the protocol interfaces and does not involve the development of the program's front-end pages, it is essentially a semi-finished application product stripped of front-end display capabilities but containing at least some functional modules of the SDK. On the other hand, only test scripts that can call the protocol interfaces need to be written. The writing of test scripts is relatively simple. By using the test scripts to call the protocol interfaces in the program under test, the program under test can be instructed to further call the native interfaces encapsulated by the protocol interfaces to perform test tasks.

[0030] Figure 2 An exemplary illustration shows the SDK testing architecture provided in this disclosure. For example... Figure 2As shown, this architecture includes a test program and test scripts that can run in any software system environment (such as containers on a cloud server). The test program includes an SDK and interface encapsulation protocol code. The test program exposes protocol interfaces. When a protocol interface is called, the test program further calls the corresponding native interface of the SDK based on the built-in encapsulated protocol code. The test script specifies the test tasks, calls the protocol interfaces, and drives the test program to further execute test tasks based on the native interfaces.

[0031] The technical solutions provided in this disclosure are described in detail below with reference to the accompanying drawings.

[0032] Figure 3 An exemplary process is provided for testing a method of SDK used for developing applications, including the following steps:

[0033] S300: Based on a preset interface encapsulation protocol, several native interfaces of the tested functional module of the SDK are encapsulated into several protocol interfaces.

[0034] S302: Compile the program to be tested based on the aforementioned protocol interfaces, and write the test script.

[0035] S304: Run the test script and send test instructions to the program under test.

[0036] S306: Run the program under test, and based on the test instructions, call the several native interfaces to execute the target test task.

[0037] Figure 3 The illustrated method can be applied to any computer device or cluster of computer devices. The system environment on the device does not have to be the operating system platform (such as Android or Windows) on which the application to be developed runs. In some embodiments, the device can be a cloud server or server cluster, and the system environment of the device can be a virtual runtime environment on the cloud server, which is generally referred to as a container. A common container is, for example, a Docker container.

[0038] The SDK described in this disclosure is used to develop applications, such as map service applications.

[0039] An SDK typically includes several functional modules. These modules can be understood as underlying functional modules that provide basic support for the application's business functions. An application has an embedded SDK, and the application's business functions require calling the corresponding functional modules of the SDK to be implemented.

[0040] When testing the SDK, you can choose to test some or all of its functional modules. Each functional module can include one or more native interfaces, which are interfaces defined according to the native language of the operating system on which the application runs. For example, if the native language of the operating system is C or C++, then the native interfaces can be interfaces defined in C or C++.

[0041] Furthermore, it should be noted that a native interface of a functional module can be understood as a wrapper around a functional function. When an application needs to implement a certain business function, it needs to call the native interface of the SDK's functional module to obtain support from the underlying functionality.

[0042] The interface encapsulation protocol described in this disclosure can be defined by testers. It is used to further encapsulate the native interfaces of the SDK's functional modules into protocol interfaces that can be recognized by scripting languages ​​(meaning they can be invoked by commands sent by scripts). Typically, a native interface can be encapsulated into a protocol interface, and there is a one-to-one correspondence between the native interface and the protocol interface. It should be noted that the interface mentioned in this document refers to the Application Programming Interface (API).

[0043] The scripting languages ​​described in this disclosure are text-based code languages ​​that are relatively user-friendly for code writers, making script writing simpler. Common scripting languages ​​include Go and Python.

[0044] The test program described in this disclosure is a program compiled based on the protocol interface. In specific implementation, the SDK can be component-based tested, that is, several protocol interfaces corresponding to a single functional module of the SDK can be compiled into a test program, with different functional modules corresponding to different test programs, or the protocol interfaces of multiple functional modules of the SDK can be compiled into a test program.

[0045] The reason for compiling the test program based on a protocol interface (rather than a native interface) is that the test instructions in the test script are written in a scripting language, which is difficult for the native interface to recognize, thus making it difficult for the test script to call the native interface. Therefore, this disclosure employs a protocol bridging technique to encapsulate the native interface into a protocol interface that can be called by a scripting language, and then compiles the protocol interface into the test program. This enables the test script to call the protocol interface to drive the test program to execute test tasks. Generally, the test program mainly includes an SDK and interface encapsulation protocol code, and the test program exposes the protocol interface externally.

[0046] Since the program under test is compiled based on the protocol interface, there is no need to consider the operating system platform environment for the application to run. It does not involve front-end development and is not an application sample. However, it can be understood as a semi-finished application with at least some functional modules of the SDK built in, but stripped of front-end display capabilities. Such a semi-finished application can run in any system environment, and testers can easily test the functionality of the SDK built into the semi-finished application.

[0047] In this disclosure, the test script sends test instructions to the test program, the purpose of which is to call several protocol interfaces to execute the target test task. The purpose of the target test task is to simulate the functionality of an application developed based on the functional module under test.

[0048] It should be noted that the concept of test tasks in this disclosure differs from that in the prior art. Prior art test tasks are implemented by testers operating application samples installed on a specific operating system. Such test tasks are driven by the UI interaction between the testers and the application samples, and therefore are described from a business function perspective (i.e., the UI level). In contrast, the test tasks in this disclosure are automatically executed by the program under test, driven by test scripts. These test scripts describe the test tasks from the perspective of the low-level interaction between the SDK code and the intended application's business layer code. This allows the testing work to more closely resemble the low-level technical testing of the SDK's functional effects, overcomes the permission restrictions of specific operating systems, and facilitates the acquisition of low-level runtime parameters of the application under test during test task execution.

[0049] In some embodiments, the test instruction may specify at least one of the following attributes of the target test task: the timing of the calls to the plurality of protocol interfaces; the material resources in the application page to be simulated; and the layout of the material resources in the application page to be simulated.

[0050] When the test script runs, it can automatically simulate referencing the resource materials specified by the tester, simulate the page layout specified by the tester, and sequentially call the various protocol interfaces of the functional module under test according to the timing specified by the tester, thereby completing the creation of a test case. This test case sends test instructions to the program under test, driving the program under test to execute the corresponding test tasks.

[0051] In this disclosure, unit testing is performed on individual functional modules of the SDK, meaning that test cases can sequentially call each protocol interface of the functional module in a certain time sequence.

[0052] In some embodiments, the data exchange format for test instructions can be JSON. Accordingly, in this embodiment, the native language can be C++, and the scripting language can be Python.

[0053] In some embodiments, testers can use preset test script templates to write test scripts, further reducing the workload of writing test scripts.

[0054] In some embodiments, testers can manually execute a preset interface encapsulation protocol to encapsulate native interfaces into protocol interfaces. In other embodiments, to save testers' workload, a SWIG plugin (an existing open-source tool) can be run to encapsulate several native interfaces of the tested functional module into several protocol interfaces based on the interface specification document of the SDK's tested functional module and the preset interface encapsulation protocol built into the SWIG plugin.

[0055] In the technical solution disclosed herein, SDK modular testing can be implemented, meaning that each functional module of the SDK can be tested independently. For example, there can be N functional modules of the SDK to be tested, which are divided into M groups, where M is greater than 1 and N is greater than M. The functional modules in different groups are then tested based on different testing environments.

[0056] Using different testing environments allows for parallel testing of multiple functional modules within the same SDK, improving testing efficiency. Different testing environments also isolate different functional modules from each other during testing, preventing interference between them and improving test accuracy.

[0057] The testing environment described above can be any system environment (software runtime environment), such as a container on a cloud server. A common container is a Docker container.

[0058] Furthermore, this disclosure allows for the acquisition of runtime parameters of the program under test during the execution of the target test task, as well as the execution results of the program under test during the execution of the target test task, to form a test report. Since it is no longer subject to the permission restrictions of a specific operating system platform, it is possible to obtain the underlying runtime parameters of the program under test, resulting in an objective and quantitative test report. For example, disinfectant technology (a dynamic detection enhancement technology) can be used to obtain some runtime parameters of the program under test, and memory detection technology can be used to obtain some runtime parameters of the program under test.

[0059] Furthermore, the program under test can be run to render page effect images, which are then added to the test report. These page effect images demonstrate the page effects corresponding to the application functions simulated by the target test task. Different programs under test corresponding to the same functional module can render page effect images when executing the same test task, allowing testers to easily compare these images and evaluate the test results.

[0060] If the target device for the test (such as a cloud server) does not have rendering hardware (i.e., a GPU), then the open-source SwiftShader rendering tool can be invoked to render the page effect image based on the CPU of the target device.

[0061] In some embodiments, if one or more native interfaces of the functional module under test are updated, the program under test can be updated accordingly, and the updated program under test can be tested based on the test script.

[0062] In addition, after the SDK has been tested, the SDK that has passed the functional tests can be provided to the customer (i.e. the developer) for application development. The customer may subsequently provide feedback on some issues with the SDK. In this case, the testers can refer to the issues raised by the customer and rewrite the test scripts to test one or more functional modules in the SDK.

[0063] This disclosure also provides an apparatus for testing an SDK used for developing applications, comprising:

[0064] The interface encapsulation module, based on a preset interface encapsulation protocol, encapsulates several native interfaces of the tested functional module of the SDK into several protocol interfaces, wherein the several native interfaces are defined according to the native language of the operating system on which the application runs, and the several protocol interfaces are defined according to a scripting language.

[0065] The compilation module compiles the program under test based on the aforementioned protocol interfaces and writes the test scripts.

[0066] The test instruction sending module runs the test script and sends test instructions to the program under test; wherein, the test instructions are used to call the plurality of protocol interfaces to execute the target test task, and the target test task is used to simulate the application functions developed based on the functional module under test;

[0067] The test task execution module runs the program under test, and based on the test instructions, calls the several native interfaces to execute the target test task.

[0068] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods of embodiments of this disclosure.

[0069] This disclosure also proposes a computer program product for implementing the methods of the embodiments of this disclosure.

[0070] This disclosure also provides a computing device, including a memory and a processor; the memory is used to store computer instructions that can be executed on the processor, and the processor is used to implement the methods of the embodiments of this disclosure when executing the computer instructions.

[0071] Figure 4 This is a schematic diagram of the structure of a computing device provided in this disclosure. The computing device 15 may include, but is not limited to, a processor 151, a memory 152, and a bus 153 connecting different system components (including the memory 152 and the processor 151).

[0072] The memory 152 stores computer instructions that can be executed by the processor 151, enabling the processor 151 to perform the methods of any embodiment of this disclosure. The memory 152 may include a random access memory (RAM) 1521, a cache memory 1522, and / or a read-only memory (ROM) 1523. The memory 152 may also include a program tool 1525 having a set of program modules 1524, including but not limited to: an operating system, one or more application programs, other program modules, and program data. One or more combinations of these program modules may include an implementation of a network environment.

[0073] Bus 153 may include, for example, a data bus, an address bus, and a control bus. The computing device 15 can also communicate with external devices 155 via I / O interface 154, such as a keyboard or a Bluetooth device. The computing device 150 can also communicate with one or more networks via network adapter 156, such as a local area network (LAN), a wide area network (WAN), or a public network. As shown, network adapter 156 can also communicate with other modules of the computing device 15 via bus 153.

[0074] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0075] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

[0076] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0077] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0078] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0079] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0080] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0081] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0082] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the functions specified in one or more boxes. In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0083] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0084] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0085] It should also be noted that 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 limitation, 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.

[0086] The foregoing has described several embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0087] The terminology used in the various embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the various embodiments of this specification. The singular forms “a,” “described,” and “the” as used in the various embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0088] It should be understood that although the terms first, second, third, etc., may be used to describe various information in various embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of various embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0089] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the method embodiments are basically similar to the method embodiments and are therefore described simply; relevant parts can be referred to the descriptions of the method embodiments. The method embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. When implementing the embodiments of this specification, the functions of each module can be implemented in one or more software and / or hardware. Alternatively, some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0090] The above description is merely a preferred embodiment of the various embodiments of this specification and is not intended to limit the various embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the various embodiments of this specification should be included within the protection scope of the various embodiments of this specification.

Claims

1. A method for testing an SDK used to develop applications, comprising: Based on a preset interface encapsulation protocol, several native interfaces of the tested functional module of the SDK are encapsulated into several protocol interfaces. The several native interfaces are defined according to the native language of the operating system on which the application runs, and the several protocol interfaces are defined according to a scripting language. The program to be tested is compiled based on the aforementioned protocol interfaces, and the test script is written accordingly. The test script is run to send test instructions to the program under test; wherein the test instructions are used to call the plurality of protocol interfaces to execute the target test task, and the target test task is used to simulate the application functions developed based on the functional module under test; Run the program under test, and based on the test instructions, call the several native interfaces to execute the target test task.

2. The method as described in claim 1, wherein, The SDK has N functional modules to be tested. These N modules are divided into M groups, where M is greater than 1 and N is greater than M. The functional modules in different groups are tested based on different testing environments.

3. The method as described in claim 1, based on a preset interface encapsulation protocol, encapsulates several native interfaces of the tested functional module of the SDK into several protocol interfaces, including: Run the SWIG plugin, and based on the interface specification document of the functional module under test in the SDK, as well as the preset interface encapsulation protocol built into the SWIG plugin, encapsulate several native interfaces of the functional module under test into several protocol interfaces.

4. The method as described in claim 1, wherein, The test instruction specifies at least one of the following attributes of the target test task: The timing of invoking the aforementioned protocol interfaces; The resource materials in the application page that need to be simulated; The layout of the resource materials for the application page that needs to be simulated.

5. The method of claim 1, further comprising: If one or more native interfaces of the functional module under test are updated, the program under test is updated accordingly, and the updated program under test is tested based on the test script.

6. The method of claim 1, further comprising: The test report is generated by obtaining the running parameters of the program under test during the execution of the target test task and the execution results of the program under test during the execution of the target test task.

7. The method of claim 6, further comprising: Run the program under test, render the page effect image, and add the page effect image to the test report; The page effect image is used to display the page effect corresponding to the application function simulated by the target test task.

8. The method of claim 7, wherein the method is applied to the target device; Render the page's visual effects, including: The SwiftShader rendering tool is invoked to render the page effect image based on the CPU of the target device.

9. The method according to any one of claims 1-8, wherein the application is a map service application.

10. A computing device, comprising a memory and a processor; the memory being configured to store computer instructions executable on the processor, the processor being configured to implement the method of any one of claims 1 to 9 when executing the computer instructions.

11. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any one of claims 1 to 9.

Images