SDK automatic test method, storage medium and terminal

Abstract

The embodiment of the invention provides an SDK automatic test method, a storage medium and a terminal, and the method comprises the steps: sequentially sending a test instruction of each to-be-tested case in a to-be-tested case set to a target SDK in a server, so as to obtain the operation output information of the target SDK for the test instruction; the to-be-tested case set comprises one or more to-be-tested cases marked as executable; and receiving operation output information sent by the server, and judging whether each to-be-tested case passes the test or not according to the operation output information. By applying the method, the corresponding to-be-tested cases can be set according to actual business requirements, the target interface in the target SDK is called by utilizing the binary instrumentation codes according to the test instruction corresponding to each to-be-tested case, so that the function of the target interface is operated, the operation information is collected, multi-scene automatic testing can be met, the test result can be obtained in time, and the test efficiency is improved. And the stability and accuracy of a test result are ensured.

Description

Technical Field

[0001] The present invention relates to the field of mobile application testing technology, and in particular to an SDK automated testing method, a storage medium and a terminal. Background Art

[0002] As software development becomes increasingly complex, SDKs often integrate many functions and logics, making it difficult for manual testing to fully cover and efficiently execute. In order to ensure that SDKs maintain consistent high-quality performance across different projects and users, reliable testing methods are needed to ensure that SDKs maintain consistent high-quality performance across different projects and users.

[0003] Traditional automated testing includes Java-based JUnit unit testing. Although this type of automated testing method can test whether the input and output of different SDK methods and functions are correct, it cannot meet actual needs from a business perspective, such as cache verification, crash verification, mobile phone disconnection, calling other system interfaces, etc.

[0004] Traditional automated testing also includes Python-based UI automated testing or non-UI automated testing, but this type of testing requires clicking on the apk file packaged by the SDK, and triggering the SDK to output logs by clicking different buttons on the interface. Therefore, if you want to test whether the SDK function is accurate, you need to click on the interface continuously, and then determine whether the content printed by the log is consistent with expectations. If there are many SDK interfaces, you need to click on the UI interface many times, and there are many logs to be printed at the same time. There may be omissions or duplications in the ADB log capture keywords, which poses a great challenge to the automated result processing. Summary of the invention

[0005] The embodiment of the present invention provides an SDK automated testing method, storage medium and terminal, which sets the test cases according to actual business needs, uses binary plug-in code to call the interface in the target SDK according to the test instructions corresponding to each test case, and collects operation information. It can meet the needs of multi-scenario automated testing, obtain test results in a timely manner, and ensure the stability and accuracy of the test results.

[0006] In a first aspect, an embodiment of the present invention provides an SDK automated testing method, which is applied to a client and includes:

[0007] Sending the test instructions of each test case in the test case set to the target SDK in the server in turn, so as to obtain the running output information of the target SDK for the test instructions; the test case set includes one or more test cases marked as executable;

[0008] Receive the operation output information sent by the server, and determine whether each of the test cases passes the test according to the operation output information.

[0009] In a second aspect, an embodiment of the present invention provides an SDK automated testing method, which is applied to a server, and includes:

[0010] Receive a test instruction from the client, and use the binary stub code to call the corresponding target interface in the target SDK according to the test instruction to run the function of the target interface;

[0011] The operation output information of the target SDK interface is sent to the client so that the client can determine whether the test case corresponding to the test instruction passes the test.

[0012] In a third aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the method steps described in the first aspect or the method steps described in the second aspect are implemented.

[0013] In a fourth aspect, an embodiment of the present invention provides a terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method steps described in the first aspect or the method steps described in the second aspect when executing the computer program.

[0014] The SDK automated testing method, storage medium, and terminal provided by the embodiments of the present invention have the following technical effects:

[0015] The embodiment of the present invention sends the test instructions corresponding to each test case in the test case set to the server through the client. After receiving the test instruction, the server uses the binary stub code to call the interface in the target SDK according to the test instruction to run the function of the target interface, and sends the running output information of the target SDK to the client, so that the client can judge whether each test case passes the test according to the running output message. Applying the above method, the corresponding test case can be set according to actual business needs, and the target interface in the target SDK can be called according to the test instruction by using the binary stub code to run the function of the target interface and collect the running information. It can meet the needs of multi-scenario automated testing, and obtain the test results in time, ensuring the stability and accuracy of the test results. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1A client flow chart of an SDK automated testing method provided by an embodiment of the present invention;

[0018] Figure 2 A flow chart of a SDK automated testing method server provided by an embodiment of the present invention;

[0019] Figure 3 An interactive diagram of an SDK automated testing method provided by an embodiment of the present invention;

[0020] Figure 4 A schematic diagram of the structure of an SDK automated testing client device provided by an embodiment of the present invention;

[0021] Figure 5 A schematic diagram of the structure of an SDK automated testing server device provided by an embodiment of the present invention;

[0022] Figure 6 A block diagram of a terminal provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0024] When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are only examples of devices and methods consistent with some aspects of the present invention as detailed in the attached claims.

[0025] In the description of the present invention, it should be understood that the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0026] As software development becomes increasingly complex, SDKs often integrate many functions and logics, making it difficult for manual testing to fully cover and efficiently execute. In order to ensure that SDKs maintain consistent high-quality performance across different projects and users, reliable testing methods are needed to ensure that SDKs maintain consistent high-quality performance across different projects and users.

[0027] Traditional automated testing includes java-based junit unit testing, but although this type of automated testing method can test whether the input and output of different methods and functions of the SDK are correct, it cannot meet actual needs from a business perspective. Python-based UI automated testing or non-UI automated testing requires clicking on the apk file packaged by the SDK to trigger the SDK to output logs. Therefore, if you want to test whether the SDK function is accurate, you need to click on the interface continuously and then determine whether the content printed in the log is consistent with expectations. If there are many SDK interfaces, you need to click on the UI interface multiple times, and there are many logs to be printed at the same time. Therefore, there may be omissions or duplications in the ADB log capture keywords, which poses a great challenge to the automated result processing.

[0028] In view of the above problems, the present invention provides an SDK automated testing method, a storage medium and a terminal. In the following, each step of the SDK automated testing method in the embodiment of the present invention will be described in more detail with reference to the accompanying drawings and embodiments.

[0029] Figure 1 A client flow chart of an SDK automated testing method provided by an embodiment of the present invention. Figure 1 As shown, the method of the embodiment of the present invention may include the following steps:

[0030] S101, sending the test instructions of each test case in the test case set to the target SDK in the server in turn to obtain the running output information of the target SDK for the test instructions; the test case set includes one or more test cases marked as executable.

[0031] Traditional junit unit testing cannot meet actual needs from a business perspective. Therefore, in an embodiment of the present invention, one or more corresponding test cases can be set according to actual business needs. When the one or more test cases need to be tested, the one or more test cases can be saved as a test case set, and each test case is marked as executable to indicate that each test case is in a testable state. The test instructions of each test case in the test case set are sent to the target SDK in the server in sequence using an automated testing method to obtain the running output information of the target SDK for the test instructions.

[0032] Therefore, before sending the test instructions of each test case in the test case set to the target SDK in the server in turn to obtain the running output information of the target SDK for the test instructions, it is necessary to run the automated testing framework first. The automated testing framework is used to automatically execute the test cases marked as executable in the test case set.

[0033] Optionally, when building an automated test framework, first import the pytest module in the Python code. Pytest is a very mature and full-featured Python test framework that can support simple unit tests and complex functional tests. Mark each test case in the test case set as executable, create a new execution entry file, and write the main method in the file. This method can execute the test of each test case in the test case set through the pytest module.

[0034] There are many ways to automate execution. For example, you can start a scheduled task in the task scheduler on a Windows PC. The scheduled task specifies the main file of the python script entry in the above solution and sets the running time to achieve automated testing within the specified time. Or when the system is Linux, you can set a crontab scheduled task to execute the main file of the entry in the python code of the above solution and set the running time to achieve automated testing within the specified time. You can also create a new project to be tested in the Jenkins server, configure the source code address, specify the execution entry function, and set the execution time to achieve automated testing.

[0035] When automated testing is required, first execute the adb command in the python script corresponding to the automated testing framework to start the APK program on the server to ensure that the APK program is in the startup and running state. The APK includes the target SDK and starts the code in the binary file encapsulated in the above APK program.

[0036] Since the automated test framework is built with Python code and is located on the client, while the target SDK may be written in a variety of codes and is located on the server, the two cannot communicate directly. Therefore, it is necessary to build an information channel for communication between the client and the server. The binary file core engine on the server is written in C language and integrates the Javascript engine V8. If the code containing V8 is injected into the target process, the target process can communicate with the injected Javascript engine through a special information channel, and additional operations can be performed on the target process through the Javascript code. Therefore, the information channel can be built with the help of JS code to achieve communication between the client and the server.

[0037] Before sending the test instructions of each test case in the test case set to the target SDK in the server in turn to obtain the running output information of the target SDK for the test instructions, first run the automated testing framework and start the information channel, and connect the client and the server through the information channel to ensure smooth communication.

[0038] Optionally, after the client is connected to the server through an information channel, the test instructions of each test case in the test case set are sent to the target SDK in the server in turn to obtain the running output information of the target SDK for the test instructions. Specifically including:

[0039] S101.1, for any case to be tested, sending a test request of the case to be tested to the information channel;

[0040] S101.2, after receiving the test request, the information channel obtains a test instruction corresponding to the test logic of the test request;

[0041] S101.3, the information channel sends the test instruction to the target SDK in the server.

[0042] Optionally, for any case to be tested, a test request for any case to be tested is sent to the information channel. After receiving the test request, the information channel obtains the test instruction corresponding to the test logic of the test request and sends the test instruction to the target SDK in the server.

[0043] As can be seen from the above, the information channel is to inject the code containing V8 into the target process. Through a special information channel, the target process can communicate with the injected Javascript engine, and can perform additional operations in the target process through the Javascript code. Therefore, the Javascript code can be used to write the test instructions corresponding to the test logic of each test case in the test case set. When the information channel receives a test request for any test case, the test instruction corresponding to any test case can be directly called. Of course, when receiving a test request for any test case, the corresponding test instruction can be written using Javascript code according to the test request for calling. For example, when the test request of any test case is to test the addition of the target SDK, two values ​​can be input to the target SDK, so the test instruction can be to call the addition test interface and two values. If you want to change the test logic of the test request, such as adding 3 to the addition result, the test instruction can be to call the addition test interface and two values, and add 3 to the result.

[0044] Based on any of the above optional embodiments, S102, receiving the operation output information sent by the server, and judging whether each of the test cases passes the test according to the operation output information.

[0045] In an embodiment of the present invention, after the client sends the test instruction to the target SDK in the server, the target SDK will perform corresponding operations according to the test instruction, and output corresponding operation information, and feedback it to the client so that the client can determine whether the test case corresponding to the above test instruction passes the test.

[0046] Specifically, the client receives the operation output information sent by the server. If the operation output information meets the preset requirements, it is determined that the test case corresponding to the test instruction has passed the test. The preset requirements can be set according to the situation of each test case. For example, the test case is to test the addition of the target SDK, and the corresponding test instruction is to call the addition test interface, and two values ​​1 and 2, then the output result should be 3. If the operation output information sent by the server is 3, it means that the target SDK is running normally and the test case has passed the test.

[0047] In summary, an embodiment of the present invention provides an SDK automated testing method, which is applied to the client, automatically executes the test process of each case to be tested in the case set to be tested through an automated testing framework, and communicates with the server through an information channel. After sending the test request to the information channel, the information channel obtains the test instruction corresponding to the test logic of the test request, and sends the test instruction to the server to obtain the running output information of the target SDK for the test instruction; receives the running output information sent by the server, and determines whether each case to be tested passes the test according to the running output information. By applying the above method, the corresponding case to be tested can be set according to actual business needs, meet multi-scenario automated testing, and obtain test results in a timely manner to ensure the stability and accuracy of the test results.

[0048] Figure 2 The following is a flow chart of a SDK automated testing method server provided by an embodiment of the present invention. Figure 2 As shown, the method of the embodiment of the present invention may include the following steps:

[0049] S201, receiving a test instruction from a client, and using a binary stub code to call a corresponding target interface in a target SDK according to the test instruction to run a function of the target interface.

[0050] In the embodiment of the present invention, when the server receives the test instruction from the client, the test instruction is actually sent by the information channel, but some test instructions may need to modify the running behavior of the target SDK, and the target SDK cannot modify its own running logic. Therefore, the binary stub code can be used to call the target interface in the target SDK according to the test instruction to run the function of the target interface. Specifically including:

[0051] S201.1, receiving a test instruction from the client, and determining target interface information of a target SDK called by the test instruction.

[0052] Optionally, after receiving the test instruction, the server may determine the target interface information of the target SDK to be called by the test instruction.

[0053] Specifically, since the target SDK is generally encapsulated in an APK program, when the server receives a test instruction, it first sends the test instruction to the APK program encapsulating the target SDK. The APK program may include multiple SDKs, and each SDK also includes multiple interfaces. When a test instruction is received, it is necessary to respond quickly to determine the SDK interface that needs to be called by the test instruction. The quick response to determine the SDK interface that needs to be called by the test instruction can be achieved by declaring a filtering intent.

[0054] By declaring filter intents, developers can achieve decoupling and flexibility between components, allowing applications to dynamically select and launch appropriate components based on user operations or system events. For example, an application can declare an intent filter to respond to a specific action. When the user performs the action, the system automatically finds and launches a matching component to handle the intent.

[0055] Specifically, to ensure that the filter intent receives the test command first, the filter intent can be declared in the initial onCreate of the target SDK life cycle, that is, the filter intent is declared in the demo layer, which is located in the APK program but outside the target SDK. First, create an object, then dynamically register a broadcast receiver to receive the test command, and establish an intent filter to determine the SDK interface that the test command needs to call.

[0056] Therefore, after the APK program receives the test instruction, the filtering intent in the demo layer in the APK program receives the test instruction and can determine the target interface information of the target SDK called by the test instruction.

[0057] S201.2, loading a binary file, and passing the target interface information to the binary file; the binary file includes binary plug-in code information; the binary plug-in code information includes code for calling one or more interfaces in the target SDK;

[0058] S201.3, run the code for calling the target interface in the binary file to call the target interface in the target SDK.

[0059] Optionally, as can be seen from the above, some test instructions may need to modify the running behavior of the target SDK, and the target SDK cannot modify its own running logic. Therefore, the binary instrumentation method can be used to write a binary file according to the test cases in the test case set. The binary file contains code that can call one or more interfaces in the target SDK. The binary file can be used to modify the running behavior and related information of the target SDK. The binary file and the target SDK are separate and independent, and are both encapsulated in the APK program, but a binary file loading mechanism can be established in the demo layer to associate the binary file and the target SDK for communication.

[0060] After determining the target interface information of the target SDK called by the test instruction through the filtering intent in the demo layer of the APK program, load the binary file, pass the target SDK interface information to the binary file, run the code for calling the target interface in the binary file to call the target interface in the target SDK, and modify the interface parameters as needed to run the functions of the target interface.

[0061] Based on any of the above optional embodiments, S202, the running output information of the target SDK is sent to the client, so that the client can determine whether the test case corresponding to the test instruction passes the test.

[0062] In the embodiment of the present invention, the code for calling the target interface in the binary file is run to call the target interface in the target SDK and run the function of the target interface. After the target SDK runs, there will be corresponding running output information. The running output information can be sent to the above-mentioned client so that the client can determine whether the test case corresponding to the test instruction has passed the test. Specifically including:

[0063] S202.1, sending the operation output information of the target SDK to an information channel used for communication between the client and the server;

[0064] S202.2, the information channel sends the operation output information to the client, so that the client can determine whether the test case corresponding to the test instruction passes the test.

[0065] Optionally, the program in the binary file calls the corresponding interface in the target SDK. After the target SDK runs, the binary file outputs the execution result of the corresponding interface, that is, the running output information. The server sends the running output information to the information channel, and the information channel sends the running output information to the client, so that the client can judge whether the test case corresponding to the test instruction passes the test. Of course, the running output information can also be judged in the Javascript code of the information channel, and the judgment result is sent to the client.

[0066] In summary, an embodiment of the present invention provides an SDK automated testing method, which is applied to the server side and communicates with the client through an information channel. After receiving the test instruction from the client, the declared filtering intent in the demo layer in the APK program can determine the target interface information of the target SDK called by the test instruction, load and pass the target interface information to a binary file containing the code for calling one or more interfaces in the target SDK, run the code for calling the target interface in the binary file to call the target interface in the target SDK, and run the function of the target interface. The running output information of the target SDK is sent to the client so that the client can determine whether the test case corresponding to the test instruction has passed the test. By applying the above method, the binary file can be used to modify the running behavior of the target SDK and collect the running output information according to the test instruction, so as to meet the requirements of multi-scenario automated testing, obtain the test results in a timely manner, and ensure the stability and accuracy of the test results.

[0067] The above describes the operation process of the client and the server respectively, but the overall operation process is interactive between the client and the server. For details, please refer to Figure 3 , Figure 3 An interactive diagram of an SDK automated testing method provided by an embodiment of the present invention. Figure 3 It can be seen that when the client wants to test any case to be tested, it sends a test request for any case to be tested to the information channel. The information channel receives the test request, obtains the test instruction corresponding to the test request according to the test logic of the test request, and sends the test instruction to the server. After receiving the test instruction, the server determines the target interface information of the target SDK called by the test instruction. Load the binary file, pass the target interface information to the binary file, run the code that calls the target interface in the binary file to call the target interface in the target SDK, and run the function of the target interface. After the target interface is run, the corresponding operation output information will be generated. The server sends the operation output information of the target SDK to the information channel, and the information channel sends the operation output information of the target SDK to the client. After the client receives the operation output information of the target SDK, it determines whether any of the above-mentioned cases to be tested has passed the test based on the operation output information. At this point, the interaction process between the client and the server is completed.

[0068] The following are embodiments of the device of the present invention, which can be used to implement the method embodiments of the present invention. For details not disclosed in the device embodiments of the present invention, please refer to the method embodiments of the present invention.

[0069] See also Figure 4 , which is a structural diagram of an SDK automated testing client device provided in an embodiment of the present invention.

[0070] The SDK automated testing method client device 400 in the embodiment of the present invention includes: a test instruction sending module 401 and a test case determination module 402 .

[0071] A test instruction sending module is used to send the test instruction of each test case in the test case set to the target SDK in the server in turn, so as to obtain the running output information of the target SDK for the test instruction; the test case set includes one or more test cases marked as executable;

[0072] The test case judgment module is used to receive the operation output information sent by the server, and judge whether each test case passes the test according to the operation output information.

[0073] It should be noted that the SDK automated test client device provided in the above embodiment only uses the division of the above functional modules as an example when executing the SDK automated test client method. In actual applications, the above functional distribution can be completed by different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the SDK automated test client device provided in the above embodiment and the SDK automated test client method embodiment belong to the same concept. Therefore, for details not disclosed in the embodiment of the device of the present invention, please refer to the embodiment of the SDK automated test client method of the present invention, which will not be repeated here.

[0074] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0075] See also Figure 5 , is a structural diagram of an SDK automated testing server device provided in an embodiment of the present invention.

[0076] The SDK automated testing method server device 500 in the embodiment of the present invention includes: a test instruction receiving module 501 and an operation output information sending module 502 .

[0077] A test instruction receiving module is used to receive a test instruction from a client, and call a corresponding target interface in a target SDK according to the test instruction to run the function of the target interface;

[0078] The operation output information sending module is used to send the operation output information of the target SDK to the client, so that the client can judge whether the test case corresponding to the test instruction passes the test.

[0079] It should be noted that the SDK automated testing server device provided in the above embodiment only uses the division of the above functional modules as an example when executing the SDK automated testing server method. In actual applications, the above functional distribution can be completed by different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the SDK automated testing server device and the SDK automated testing server method embodiment provided in the above embodiment belong to the same concept. Therefore, for details not disclosed in the embodiment of the device of the present invention, please refer to the embodiment of the SDK automated testing server method of the present invention, which will not be repeated here.

[0080] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0081] The embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the steps of the method of any of the above embodiments are implemented. The computer-readable storage medium may include, but is not limited to, any type of disk, including a floppy disk, an optical disk, a DVD, a CD-ROM, a micro drive, and a magneto-optical disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory device, a magnetic card or an optical card, a nanosystem (including a molecular memory IC), or any type of medium or device suitable for storing instructions and / or data.

[0082] An embodiment of the present invention further provides a terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any of the above-mentioned method embodiments when executing the program.

[0083] Figure 6 A block diagram of a terminal provided by an embodiment of the present invention. Figure 6 , an embodiment of the present invention provides a terminal 600, including: a processor (processor) 601, a communication interface (Communications Interface) 602, a memory (memory) 603 and a communication bus 604, wherein the processor 601, the communication interface 602, and the memory 603 complete mutual communication through the communication bus 604. The processor 601 can call the logic instructions in the memory 603 to execute the following method, including: sending the test instructions of each case to be tested in the case set to be tested to the target SDK in the server in turn, so as to obtain the running output information of the target SDK for the test instructions; the case set to be tested includes one or more cases to be tested marked as executable; receiving the running output information sent by the server, and judging whether each case to be tested passes the test according to the running output information.

[0084] Or execute the following method, including: receiving a test instruction from the client, calling the corresponding target interface in the target SDK according to the test instruction to run the function of the target interface; sending the running output information of the target SDK to the client, so that the client can determine whether the test case corresponding to the test instruction passes the test.

[0085] The terminal structure block diagram shown in the embodiment of the present invention does not constitute a limitation on the terminal 600. The terminal 600 may include more or fewer components than those shown in the figure, or combine certain components, or adopt a different component arrangement.

[0086] The embodiment of the present invention discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the methods provided by the above-mentioned method embodiments, for example, including: sending the test instructions of each test case in the test case set to the target SDK in the server in turn to obtain the running output information of the target SDK for the test instructions; the test case set includes one or more test cases marked as executable; receiving the running output information sent by the server, and judging whether each test case passes the test according to the running output information. Or including: receiving the test instruction of the client, calling the corresponding target interface in the target SDK according to the test instruction to run the function of the target interface; sending the running output information of the target SDK to the client, so that the client can judge whether the test case corresponding to the test instruction passes the test.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An SDK automated testing method, applied to the client, It is characterized in that include: Sending the test instructions of each test case in the test case set to the target SDK in the server in turn, so as to obtain the running output information of the target SDK for the test instructions; the test case set includes one or more test cases marked as executable; Receive the operation output information sent by the server, and determine whether each of the test cases passes the test according to the operation output information.

2. The method according to claim 1, It is characterized in that Before sending the test instructions of each test case in the test case set to the target SDK in the server in turn to obtain the running output information of the target SDK for the test instructions, the method further includes: Running an automated testing framework, wherein the automated testing framework is used to automatically send the test cases marked as executable in the test case set; An information channel is started, where the information channel is used for communication between the client and the server.

3. The method according to claim 1 or 2, It is characterized in that The step of sending the test instructions of each test case in the test case set to the target SDK in the server in turn includes: For any case to be tested, sending a test request of the case to be tested to the information channel; After receiving the test request, the information channel obtains a test instruction corresponding to the test logic of the test request; The information channel sends the test instruction to the target SDK in the server.

4. The method according to any one of claims 1 to 3, It is characterized in that The receiving the operation output information sent by the server, and judging whether each of the test cases passes the test according to the operation output information, comprises: Receive the operation output information sent by the server, and if the operation output information meets the preset requirements, determine that each of the test cases has passed the test.

5. An SDK automated testing method, applied to the server side, It is characterized in that include: Receive a test instruction from the client, and use the binary stub code to call the corresponding target interface in the target SDK according to the test instruction to run the function of the target interface; The operation output information of the target SDK is sent to the client so that the client can determine whether the test case corresponding to the test instruction passes the test.

6. The method according to claim 5, It is characterized in that The receiving of the test instruction from the client and calling the corresponding target interface in the target SDK according to the test instruction by using the binary plug-in code include: Receive a test instruction from the client, and determine the target interface information of the target SDK called by the test instruction; Loading a binary file, passing the target interface information to the binary file; the binary file includes binary plug-in code information; the binary plug-in code information includes code for calling one or more interfaces in the target SDK; The code for calling the target interface in the binary file is run to call the target interface in the target SDK.

7. The method according to claim 6, It is characterized in that The receiving of the test instruction from the client and determining the target interface information of the target SDK called by the test instruction includes: Receive a test instruction from the client, and determine the target interface information of the target SDK called by the test instruction through the filtering intent in the demo layer of the APK program; the filtering intent is used to respond to determine the target SDK interface called by each instruction; The binary file and the target SDK are packaged in the APK program.

8. The method according to any one of claims 5 to 7, It is characterized in that The sending the running output information of the target SDK interface to the client so that the client can judge whether the test case corresponding to the test instruction passes the test, includes: Sending the running output information of the target SDK to an information channel; the information channel is used for communication between the client and the server; The information channel sends the operation output information to the client, so that the client can determine whether the test case corresponding to the test instruction passes the test.

9. A computer-readable storage medium having a computer program stored thereon, It is characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 4 or the method according to any one of claims 5 to 8 is implemented.

10. A terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, It is characterized in that When the processor executes the computer program, the method according to any one of claims 1 to 4 or the method according to any one of claims 5 to 8 is implemented.

Images