An automated testing method and system

Abstract

The present invention discloses an automated testing method and system, which relates to the technical field of software testing. The testing method includes establishing a communication connection between a script side and a client side; the script side writes SDK interface automated test cases, and encapsulates the SDK interface automated test cases and their related information into request information in Json format and sends it to the client side; the client side receives the request information transmitted by the script side, parses the request information, and determines the call information; and converts the parsed request information based on the call information to make it conform to the native language type corresponding to the client side; and performs SDK interface testing based on the converted request information and the call information, and encapsulates the test result data into Json format and returns it to the script side; the script side receives the test result data encapsulated in Json format returned by the client side, and generates a corresponding test report according to the test result data.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and more particularly to an automated testing method and system. Background Art

[0002] With the rapid development of the mobile Internet, the mobile client SDK (Software Development Kit) has become an important part of mobile application development, providing convenience for the rapid integration of various functions, such as payment, push, positioning, communication, etc. However, with the increasing complexity of SDK functions and the diversification of application scenarios, how to effectively test the overall quality and stability of the SDK has become an important problem that needs to be solved urgently in the process of mobile application development.

[0003] In the prior art, there are still many deficiencies in the testing methods for mobile client SDKs. For example, traditional manual testing methods usually rely on graphical clicks, which require a large amount of human resources, with a large workload and low efficiency for client applications. In addition, it is difficult for manual testing methods to cover all parameter coverage usage scenarios in the SDK interfaces of Android or IOS, such as inputs of parameter length, size, quantity, type, etc., resulting in potential defects being difficult to be discovered in a timely manner. Although white-box testing and unit testing methods can gradually improve the interfaces through code analysis, their perspectives often stand on the developer side, lacking test coverage in the integrated environment and being difficult to comprehensively evaluate the performance of the SDK in the real integrated test environment, with obvious limitations. Moreover, existing testing methods mainly rely on the native testing frameworks of their respective platforms. For example, JUnit for the Android platform and XCTest for the IOS platform are used to write SDK interface unit test cases in native languages (such as Java or Kotlin for Android, and Objective-C or Swift for IOS). This leads to the need to be familiar with the native languages of specific platforms for writing SDK interface unit test cases, with strong language dependence and high technical requirements for test developers; different platforms need to write test codes in their respective native languages separately, increasing the development cost, script compilation time cost, reducing the flexibility of testing, and having low testing efficiency; due to the limitations of unit testing, it usually does not support concurrent execution in integrated testing, with low execution efficiency for complex business logics; due to the limitations of the testing framework to specific platforms, it has poor scalability, and it is difficult to manage unified test logic scripts across platforms under the same business logic, bringing additional complexity to the testing of multi-client SDKs.

[0004] Therefore, in the process of developing the mobile client SDK, there is an urgent need for a set of efficient and comprehensive automated testing tools to replace traditional manual testing, integration testing and other methods. While improving testing efficiency and reducing testing costs, it is necessary to ensure the stability and reliability of the SDK, thereby further improving the overall quality and efficiency of mobile application development. Summary of the Invention

[0005] To solve one of the above technical problems, the present invention provides an automated testing method and system, which can solve the problems of strong language dependence of the existing testing framework and testing methods, low testing efficiency, poor scalability, and insufficient testing coverage.

[0006] To achieve the object of the present invention, the present invention adopts the following technical solutions:

[0007] According to the first aspect embodiment of the present invention, an automated testing method is provided, including:

[0008] Establish a communication connection between the script side and the client side;

[0009] The script side writes automated test cases for the SDK interface, and encapsulates the automated test cases for the SDK interface and their related information into request information in Json format and sends it to the client side;

[0010] The client side receives the request information transmitted by the script side, parses the request information to determine the call information; and based on the call information, converts the parsed request information to conform to the native language type corresponding to the client side; and based on the converted request information and the call information, performs SDK interface testing, and encapsulates the test result data into Json format and returns it to the script side;

[0011] The script side receives the test result data encapsulated in Json format returned by the client side, and generates a corresponding test report according to the test result data.

[0012] According to some embodiments of the present invention, the step of performing SDK interface testing based on the converted request information and the call information includes: executing the call of the call information based on the converted request information and the determined call information and based on the reflection method of different client systems.

[0013] According to some embodiments of the present invention, the step of performing SDK interface testing based on the converted request information and the call information further includes: after executing the call of the call information, determining whether the type of the SDK interface callback method is an asynchronous method or a synchronous method through the method return type; if it is a synchronous method, the SDK interface directly executes and returns the interface execution result data; if it is an asynchronous method, it is necessary to register a callback method in the native language in the global variable class of the client in advance.

[0014] According to some embodiments of the present invention, the step that the script end receives the test result data encapsulated in Json format returned by the client and generates a corresponding test report based on the test result data includes: determining whether the test result data is consistent with the expected result; if it is consistent, determining that the SDK interface automation test case passes and marking it with PASS; if it is inconsistent, determining that the SDK interface automation test case fails and marking it with FAIL; storing the marked test result data in the form of a test report.

[0015] A second aspect embodiment of the present invention provides an automated testing system, including a script end and a client that establish a communication connection;

[0016] The script end is configured to write SDK interface automation test cases, encapsulate the SDK interface automation test cases and their related information into request information in Json format, and send it to the client; and is configured to receive the test result data encapsulated in Json format returned by the client and generate a corresponding test report according to the test result data;

[0017] The client is configured to receive the request information transmitted by the script end, parse the request information to determine the call information; and is configured to convert the parsed request information based on the call information to conform to the native language type corresponding to the client; and is configured to perform SDK interface testing based on the converted request information and the call information, and encapsulate the test result data into Json format and return it to the script end.

[0018] According to some embodiments of the present invention, the script end includes:

[0019] A test case writing module for writing SDK interface automation test cases according to the interface information to be tested of the client;

[0020] A Json format encapsulation module for encapsulating the SDK interface automation test cases and their related information into request information in Json format;

[0021] A test report generation module, configured to receive the test result data encapsulated in Json format returned by the client, and generate a corresponding test report according to the test result data.

[0022] According to some embodiments of the present invention, the script side further includes:

[0023] A first judgment module, configured to judge whether the test result data is consistent with the expected result; if consistent, determine that the SDK interface automated test case passes and mark it with PASS; if inconsistent, determine that the SDK interface automated test case fails and mark it with FAIL; store the marked test result data in the form of a test report.

[0024] According to some embodiments of the present invention, the client includes:

[0025] A request parsing module, configured to parse the request information in Json format sent by the script side, judge the legality of the request information, and determine the call information according to the request information;

[0026] A parameter serialization conversion module, configured to convert the parsed request information based on the call information to make it conform to the native language type corresponding to the client;

[0027] A reflection execution module, configured to execute the call of the call information based on the converted request information and the determined call information and based on the reflection method of different client systems;

[0028] A second judgment module, configured to judge whether the type of the SDK interface callback method is an asynchronous method or a synchronous method according to the method return type after executing the call of the call information; if it is a synchronous method, the SDK interface directly executes and returns the interface execution result data; if it is an asynchronous method, it is necessary to register the callback method of the native language in the global variable class of the client in advance;

[0029] A deserialization module, configured to convert the obtained test result data of the native language type into test result data in Json format and return it to the script side.

[0030] According to the third aspect embodiment of the present application, a terminal is provided, including a memory and a processor, where a computer program that can run on the processor is stored on the memory, and when the processor runs the computer program, it executes the above-mentioned automated test method.

[0031] According to an embodiment of the fourth aspect of the present application, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored computer program. When the computer program is run by a processor, it controls the terminal where the storage medium is located to execute the above-mentioned automated testing method.

[0032] According to the technical solution provided by the present invention, it has at least the following beneficial effects: According to the interface method that needs to be called obtained from the client system, the script side can write SDK interface automated test cases in a variety of scripting languages (such as C#, Java, Python, etc.), and then uniformly encapsulate them into request information in Json format and send it to the client. This greatly reduces the dependence on the native language of the client system and reduces the learning cost. Through the Json format transmission method, the decoupling between the test script and the client SDK is higher, reducing the complexity of extension and maintenance. After receiving the request information in the unified encapsulation format by the clients of different systems, they parse the request information to determine the call information, that is, determine the target class and method to be called, and then convert the parsed request information into the native language type that conforms to the client system, and then perform interface testing based on the reflection methods of different client systems. The same SDK interface automated test case can be applied to test multiple clients of different systems, with high test efficiency, strong scalability, and wide coverage. After the test is completed, the test result data executed by the native language SDK interface will be deserialized and encapsulated into Json format and returned to the script side.

[0033] Through the above technical solution, test developers no longer need to master multiple native languages to complete the automated testing of the native interfaces of mobile client SDKs. This not only lowers the technical threshold but also significantly improves the test efficiency, further optimizing the robustness and maintenance process of mobile client SDKs.

[0034] The additional aspects and advantages of the present invention will be partially given in the following description, partially become apparent from the following description, or be understood through the practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The above and / or additional aspects and advantages of the present invention will become apparent and be readily understood from the description of the embodiments in conjunction with the following drawings, where:

[0036] Figure 1 is a flowchart of the automated testing method according to an embodiment of the present invention;

[0037] Figure 2 is a schematic diagram of the content requirements dynamically reflected and returned based on the source code of native language Android;

[0038] Figure 3Schematic diagram of content requirements for dynamic reflection conversion and return of source code based on the native language IOS;

[0039] Figure 4 Code diagram of Json format data from the script side request to the client;

[0040] Figure 5 Schematic diagram of the concurrent execution structure of the embodiments of the present invention;

[0041] Figure 6 Block diagram of the script side of the embodiments of the present invention;

[0042] Figure 7 Block diagram of the client of the embodiments of the present invention. Detailed implementation manners

[0043] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts belong to the scope of protection of the present application.

[0044] It should be noted that although functional module division is performed in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order from the module division in the device or the order in the flowchart. Terms such as "first" and "second" in the specification and the above-mentioned drawings are used to distinguish similar objects, rather than to describe a specific order or sequence. The meaning of several is one or more, the meaning of multiple is two or more, greater than, less than, exceeding, etc. are understood as not including the number itself, and above, below, within, etc. are understood as including the number.

[0045] This application aims to propose a general mobile client SDK automated testing method and system. Based on the dynamic reflection mechanism and a unified JSON format communication protocol, it focuses on deeply verifying the underlying logic interfaces of the SDK and does not involve testing the presentation layer or UIKit (such as). By focusing on the interface verification of the core functional modules, automated testing of the interface logic layer is achieved, decoupling from the testing requirements of the user interaction layer, thereby ensuring the efficiency and stability of testing. Through a standardized data transmission and result feedback mechanism, it can quickly adapt to the SDK interfaces of Android and IOS, achieving consistent logic verification across platforms. Multiple clients execute concurrently, further improving the ability, enhancing the testing efficiency, meeting the high-efficiency testing requirements of complex business scenarios, and optimizing the development and testing processes of the mobile client SDK. It solves the problems in the prior art such as strong language dependence of the testing framework and testing methods, low testing efficiency, poor scalability, and insufficient testing coverage.

[0046] As Figure 1 shown, the first aspect embodiment of this application provides an automated testing method, including the following steps:

[0047] Step S100, the script side and the client establish a communication connection.

[0048] In this step, when the script side and the client are in the same local area network, they interact through the IP address and use the HTTP protocol to achieve communication. When the script side and the client are in different local area networks, or in scenarios where it is necessary to test 4G, 5G networks or no network, etc., it is necessary to connect to the device terminal device through different client data cable connection methods and conduct the communication of the network open service between the two in a port forwarding mode. For example, Android's adb forward or IOS iproxy commands forward and map the service ports opened by the client to the ports of the script side running machine through the data cable for network data communication. The script side communicates with the client device through the locally forwarded port and transmits the data to the client for interaction requests.

[0049] Step S200, the script side writes automated test cases for the SDK interface and encapsulates the automated test cases for the SDK interface and their related information into request information in Json format and sends it to the client.

[0050] Before writing SDK interface automation test cases (cases written in code) on the script side, the script side needs to convert SDK interface automation test cases based on normal function test cases (cases described in Chinese) or product requirement documents, and sort out the native SDK interfaces to be tested that need to be executed through the SDK interface automation test cases (native languages such as classes, method interfaces of Objective-C / Swift for the IOS platform language or classes, method interfaces of Java / Kotlin language for the Android platform). mainly through normal function test cases and product requirement documents, clarify the target classes and methods of the native SDK interfaces to be tested that need to be executed by the SDK interface automation test cases, and clarify their relevant information. The relevant information includes the target classes and methods to be called, specifically determining the class name, method name, and their required parameter types and parameter orders, providing a basic basis for writing SDK interface automation test cases.

[0051] Based on the above relevant information, the script side writes corresponding SDK interface automation test cases, and the specific process is as follows:

[0052] Based on the native SDK interfaces to be tested sorted out by the above SDK interface automation test cases, the specific classes and methods are determined. Then, the script side requests the specific class and method parameters, and first dynamically obtains the classes, methods, and specific parameter names and types of the native language of the native SDK interfaces to be tested from within the client. The main purpose is to convert the classes of the native language of the native SDK interfaces to be tested into a conventional standard type format and return them. If the class and method exist and can be called, the specific Json serialization content is returned. If the class and method do not exist or cannot be called, the content indicating that the class and method cannot be called is returned, so that testers can also call the SDK native language interfaces according to the returned content without being familiar with or not understanding the native language at all.

[0053] Based on the above SDK interface automation test cases, confirm a class to be tested as the target class. For example, after confirming that the target class is RongCoreClient and the method is setConversationToTop, obtain the constructor example of the class method dynamically reflected in the native language returned by the client by requesting the general interface getInterfaceParams of the client. In this constructor example, the class name, method name, request field name, request field type, etc. that need to be included in the Json constructor example of the SDK interface need to be returned.

[0054] It should be noted that due to the particularity of the native language of IOS, it is impossible to obtain the required names and fields of native classes and methods through dynamic reflection at runtime. Therefore, during the packaging and compilation process of the IOS client, an automated script is used to scan the header files of relevant IOS classes of type ".h", and the required field names and types of relevant classes and methods are stored in the IOS client. When the IOS client starts, they are loaded into memory to provide dynamic reflection for the script side.

[0055] The following is the code of the Json serialization content returned by the two native language reflections of the classes and methods requested by the script side to the script side.

[0056] Such as Figure 2 shown is a schematic diagram of the Json serialization content requirements dynamically reflected and returned to the script side based on the native language Android, according to the source code of the native SDK interface to be tested in the Android client; as Figure 3 shown is a schematic diagram of the Json serialization content requirements dynamically reflected and returned to the script side based on the native language IOS, according to the source code of the native SDK interface to be tested in the IOS client.

[0057] Based on Figure 2 and Figure 3 in the return examples, align the test methods and field types to construct the corresponding Json format data for the SDK interface request, which is used when calling the native SDK interface during the writing of SDK interface automated test cases. When the field type is a non-basic type (such as int, bool, str, etc.), the Json should construct this field as a dictionary type for transmission. When the field type is a basic type, it is transmitted in computer general types such as int, bool, str, etc. The final Json format data code for constructing the request from the script side to the client for a single interface with the target class being RongCoreClient and the method being setConversationToTop is as Figure 4 shown.

[0058] According to the target test class and method, the client can construct and generate the script side test Json request required for the native SDK interface to be tested through the above steps. Through the Json content of this request, it is requested to the client for testing this native SDK interface.

[0059] According to the target process of the SDK interface automated test case, determine the test case script. Usually, a test case script will contain multiple SDK interface requests and executions. When writing the relevant SDK interface automated test cases according to the test target process, the request content will send each request to the client in sequence according to the call order of each test case.

[0060] It should be noted that in this application, the script side can dynamically obtain the SDK interfaces and parameters that can be called by the client, and construct requests and parameters in real time. Without viewing the source code, it can be defined and implemented in advance.

[0061] It should be noted that each SDK interface automated test case can be designed as an independent task, without dependencies on each other. Between the SDK interface requests sent by each task, ensure that they are independent of each other and do not share state or resources (if necessary, use isolated sessions or environments).

[0062] Based on the independence between the above SDK interface automated test cases, it supports concurrent execution of SDK interface automated test cases in a multi-threaded or multi-process manner. If concurrent testing is required, each thread or process is responsible for the complete process of an SDK interface automated test case. The script side first sends the test request information to the configuration center instead of the corresponding client. On the one hand, the configuration center mainly stores and records information such as the SDK version number integrated by the client, the client device IP and port, and the device type. On the other hand, the version number of the SDK interface automated test case executed each time has a corresponding relationship with the SDK version number to be tested, and only the same version of the SDK is supported for testing each time. If testing different versions of the SDK is required, different versions of the SDK need to be tested according to the version number of the SDK interface automated test case. When executing tasks of different versions each time, the requests of the script side carry additional version information and client type information through the configuration of the configuration center, and are distributed to various types of clients of different SDK versions to achieve concurrent testing, thereby improving the testing efficiency. The structural schematic diagram of concurrent execution is as Figure 5 shown.

[0063] Step S300: The client receives the request information transmitted by the script side, parses the request information to determine the call information; and based on the call information, converts the parsed request information to conform to the native language type corresponding to the client; and based on the converted request information and call information, performs SDK interface testing, and encapsulates the test result data into Json format and returns it to the script side.

[0064] In this step, when the script side and the client need to interact through the HTTP protocol, an HTTP server needs to be established on the client to parse the Json format request information sent by the script side and determine the legality of the request information. Such as judging whether the call class, method name, parameter length, parameter type, parameter name, etc. match the native SDK interface to be called. If the request information is legal, the subsequent steps are executed. If it is illegal, a call failure is returned, and the reason for the call failure is indicated in the returned data. Such as information that the class or method does not exist, or the parameter type or quantity is incorrect.

[0065] In this step, after the client determines that the request information is legal, it determines the call information according to the request information. The call information in this application refers to the target class and method.

[0066] According to the determined call information (target class and method), the parsed request information in Json format is converted into a native language type that conforms to the Android or IOS system, and the order of method parameters is aligned according to the parameter names of the method. Whether the parameter order is aligned determines whether the corresponding method can be successfully called in the subsequent process.

[0067] Based on the request information converted into the native language type and the determined call information (target class and method), and based on the reflection methods of different client systems such as method.invoke in Android and method.invoke in IOS, the call information (target class and method) is called.

[0068] [[ID=ID=10]]After the call information (target class and method) is called, the type of the SDK interface callback method is comprehensively judged through native language reflection (such as methods like Android method.getReturnType() and IOS signature.methodReturnType and methods such as whether there is a callback parameter). If the return parameter is void and the input parameter has a method like callback, it can be considered that the type of the SDK interface callback method is an asynchronous method, otherwise it is a synchronous method.

[0069] If it is a synchronous method, the native SDK interface to be tested will be immediately executed and the interface execution result data will be returned. Specifically, after waiting for the native SDK interface to finish executing, the execution result data of the executed native SDK interface is stored for subsequent processing and returned to the script side. If it is an asynchronous method, it is necessary to register the native language callback method, that is, the native SDK interface callback method, in the global variable class of the client in advance; a dictionary with the string of the input parameter type as the name and the callback method as the value will store the registration content in the global variable class of the client, and when the target class and method to be executed are called, the global variable class storing the callback method is retrieved, and the registered callback method is written into the input such as the callback parameter of the target class and method to be executed; the retrieval method is retrieved according to the type string of the input parameter; when the registered native SDK interface receives data in the callback method, it marks that the SDK interface has finished executing, stores the data for subsequent processing and returns it to the script side.

[0070] It should be noted that the difference between the synchronous method and the asynchronous method is as follows: The synchronous method usually returns the execution result data immediately, while the asynchronous method cannot confirm the return execution time. Therefore, it is necessary to add a default timeout for the asynchronous method to avoid long waiting times for asynchronous callbacks, which may cause subsequent input test cases to be blocked for a long time. When the data returned by the callback method of the native SDK interface has not been received after exceeding the predetermined time, relevant timeout information, such as the SDK interface execution timeout, etc., is returned to the script side.

[0071] After obtaining the test result data (i.e., the result data returned by the execution of the native SDK interface stored above), an anti - serialization operation is performed to convert the test result data in the native language type into test result data in Json format through the anti - serialization module and return it to the script side. This request for the SDK interface execution ends.

[0072] Step S400: The script side receives the test result data encapsulated in Json format returned by the client and generates a corresponding test report based on the test result data.

[0073] In this step, the script side obtains the test result data encapsulated in Json format and outputs the test result data. At the same time, it determines whether the test result data is consistent with the expected result; if the test result data is consistent with the expected result, it is determined that the SDK interface automation test case passes and is marked as PASS; if the test result data is inconsistent with the expected result, it is determined that the SDK interface automation test case fails and is marked as FAIL; then all the input parameters of the interface test request, the parameters returned by the client, the expected result, and the marked test result data are stored in the form of a test report.

[0074] The second - aspect embodiment of the present application provides an automated test system, including a script side and a client side, and a communication connection is established between the script side and the client side.

[0075] Script side: Configured to write SDK interface automation test cases, encapsulate the SDK interface automation test cases and their related information into request information in Json format and send it to the client side; and configured to receive the test result data encapsulated in Json format returned by the client side and generate a corresponding test report based on the test result data.

[0076] Client side: Configured to receive the request information transmitted by the script side, parse the request information to determine the call information; and configured to convert the parsed request information based on the call information to make it conform to the native language type corresponding to the client side; and configured to perform SDK interface testing based on the converted request information and the call information, and encapsulate the test result data into Json format and return it to the script side.

[0077] It should be noted that when the script side and the client are within the same local area network, they communicate with each other through the IP address and use the HTTP protocol to achieve communication. When the script side and the client are in different local area networks, or in scenarios such as testing 4G, 5G networks or no network, it is necessary to connect to the device terminal device through the method of connecting different client data lines, and conduct the connectivity of the network open services between the two in the port forwarding mode. For example, Android's adb forward or IOS iproxy commands forward and map the service ports opened by the client to the ports of the script-side running machine through the data line for network data communication. The script side communicates with the client device through the locally forwarded port, and transmits the data to the client for interactive requests.

[0078] In some specific embodiments of the present application, such as Figure 6 shown, the script side includes a test case writing module, a Json format encapsulation module, a test report generation module and a first judgment module.

[0079] Among them,

[0080] The test case writing module is used to write SDK interface automated test cases according to the interface information to be tested of the client;

[0081] The Json format encapsulation module is used to encapsulate the SDK interface automated test cases and their related information into Json format request information;

[0082] The test report generation module is used to receive the test result data encapsulated in Json format returned by the client, and generate a corresponding test report according to the test result data.

[0083] The first judgment module is used to judge whether the test result data is consistent with the expected result; if it is consistent, it is determined that the SDK interface automated test case passes and is marked with PASS, if it is inconsistent, it is determined that the SDK interface automated test case fails and is marked with FAIL; the marked test result data is stored in the form of a test report.

[0084] In some specific embodiments of the present application, such as Figure 7 shown, the client includes a request parsing module, a parameter serialization conversion module, a reflection execution module, a second judgment module and a deserialization module.

[0085] Among them,

[0086] The request parsing module is used to parse the Json format request information sent by the script side, judge the legality of the request information, and determine the call information according to the request information;

[0087] A parameter serialization conversion module, which is used to convert the parsed request information based on the call information so that it conforms to the native language type corresponding to the client system;

[0088] A reflection execution module, which is used to execute the call of the call information based on the converted request information and the determined call information and based on the reflection methods of different client systems;

[0089] A second judgment module, which is used to judge whether the SDK interface callback method is an asynchronous method or a synchronous method according to the method return type after executing the call of the call information; if it is a synchronous method, the SDK interface directly executes and returns the interface execution result data; if it is an asynchronous method, it is necessary to register the callback method of the native language in the global variable class of the client in advance;

[0090] A deserialization module, which is used to convert the obtained test result data of the native language type into test result data in Json format and return it to the script side.

[0091] The above-mentioned automated test system can be implemented by integrated circuits or chips, and no specific restrictions are made in this application.

[0092] With the automated test method and system in the above technical solution, the script side allows using multiple scripting languages (such as Python, C#, Java, etc.) to write SDK interface automated test cases, achieving language independence. Through the uniformly generated encapsulated interface, the impact of platform differences on the test logic is reduced, and a set of test cases can be used commonly on Android and IOS platforms. The client uses the dynamic reflection mechanism of Android and IOS native languages to directly call the SDK interface, which only needs to be developed once. When the interface method changes or the parameters change, there is no need to perform secondary encapsulation of the native interface again and it can be dynamically called. Through the Json format transmission method, the decoupling between the test script and the client SDK is higher, reducing the complexity of extension and maintenance. It supports dynamic interface detection and call, can quickly adjust call parameters and methods according to test requirements, and adapt to the rapid iteration of different versions of the SDK. It supports concurrent execution of tests on multiple clients at the same time, significantly shortening the test cycle, providing an efficient concurrent scheduling mechanism, and can complete the execution of a large number of test cases in a short time, especially suitable for rapid regression test scenarios. The execution results of multiple clients can be integrated into a unified test report, facilitating the statistics and analysis of test results.

[0093] The third aspect embodiment of this application also provides a terminal, including a memory and a processor. A computer program that can run on the processor is stored on the memory. When the processor runs the computer program, it executes the above-mentioned automated test method.

[0094] Specifically, the processor may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logical blocks, modules, and circuits described in connection with the disclosure of the present application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0095] Specifically, the processor is connected to the memory through a bus, and the bus may include paths for transmitting information. The bus may be a PCI bus or an EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc.

[0096] The memory may be a ROM or other type of static storage device that can store static information and instructions, a RAM, or other type of dynamic storage device that can store information and instructions. It may also be an EEPROM, a CD-ROM, or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), magnetic disk storage medium, or any other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0097] Optionally, the memory is used to store the code of the computer program for executing the solution of the present application and is controlled by the processor to execute. The processor is used to execute the application program code stored in the memory to implement the actions of the above-mentioned automated test system.

[0098] The embodiment of the fourth aspect of the present application also provides a computer-readable storage medium, and the computer-readable storage medium includes a stored computer program, wherein when the computer program is run by the processor, it controls the terminal where the storage medium is located to execute the above-mentioned automated test method.

[0099] Those of ordinary skill in the art will understand that all or some of the steps and systems disclosed in the above methods can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or can be implemented as hardware, or can be implemented as an integrated circuit, such as an application specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium). As is well known to those of ordinary skill in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that a communication medium typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and can include any information delivery medium.

[0100] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "schematic embodiments", "examples", "specific examples", or "some examples", etc. means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0101] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments, and various changes can be made without departing from the spirit of the present invention within the scope of knowledge possessed by those of ordinary skill in the art.

Claims

1. An automated testing method, characterized in that, Including: The script side and the client establish a communication connection; The script side writes SDK interface automated test cases, and encapsulates the SDK interface automated test cases and their related information into request information in Json format and sends it to the client; The client receives the request information transmitted by the script side, parses the request information, and determines the call information, where the call information refers to the target class and method; And based on the call information, convert the parsed request information to conform to the native language type corresponding to the client, and adjust the order of method parameters according to the parameter names of the method; And based on the converted request information and the call information, perform SDK interface testing, and encapsulate the test result data into Json format and return it to the script side; The script side receives the test result data encapsulated in Json format returned by the client, and generates a corresponding test report according to the test result data; Among them, according to the target process of the SDK interface automated test case, determine the test case script. A test case script will contain multiple SDK interface requests and executions. When writing the relevant SDK interface automated test cases according to the test target process, the request content will send each request to the client in sequence according to the call order of each test case; The script side first sends the test request information to the configuration center, which is used to store and record information such as the SDK version number integrated by the client, the IP and port of the client device, and the device type; the version number of each execution of the SDK interface automated test case task corresponds to the SDK version number to be tested. Each test only supports testing of the same version of the SDK; if it is necessary to test different versions of the SDK, it is necessary to test different versions of the SDK according to the version number of the SDK interface automated test case. When the script side makes requests for different versions of tasks each time, additional version information and client type information are carried through the configuration of the configuration center and distributed to various types of clients of different SDK versions to achieve concurrent testing; Among them, the SDK interface automated test cases are independent of each other, and support concurrent execution of SDK interface automated test cases in a multi-threaded or multi-process manner. If concurrent testing is required, each thread or process is responsible for the complete process of an SDK interface automated test case; Among them, after the call of the call information is executed, judge whether the SDK interface callback method is an asynchronous method or a synchronous method through the method return type; If it is a synchronous method, the SDK interface directly executes and returns the interface execution result data; If it is an asynchronous method, it is necessary to register the callback method of the native language in the global variable class of the client in advance. Specifically, it includes storing the registration content in the global variable class of the client in the form of a dictionary with the string of the input parameter type as the name and the callback method as the value. When executing the target class and method, retrieve the global variable class storing the callback method, and write the registered callback method into the input callback parameter of the target class and method to be executed. The retrieval method is based on the type string of the input parameter. When the registered native SDK interface receives data in the callback method, mark the SDK interface as executed, store the data for subsequent processing, and return it to the script side.

2. The automated test method according to claim 1, wherein The steps of performing SDK interface testing based on the converted request information and the call information include: Execute the call of the call information based on the converted request information, the determined call information, and the reflection method of different client systems.

3. The automated test method according to claim 1, characterized in that, The steps for the script side to receive the test result data encapsulated in Json format returned by the client and generate a corresponding test report include: Judge whether the test result data is consistent with the expected result; If they are consistent, determine that the SDK interface automation test case passes and mark it with PASS; If they are inconsistent, determine that the SDK interface automation test case fails and mark it with FAIL; Store the marked test result data in the form of a test report.

4. An automated testing system, characterized in that, It includes a script side and a client that establish a communication connection; The script side is configured to write SDK interface automation test cases and encapsulate the SDK interface automation test cases and their related information into Json format request information and send it to the client; And is configured to receive the test result data encapsulated in Json format returned by the client and generate a corresponding test report according to the test result data; The client is configured to receive the request information transmitted by the script side, parse the request information, determine the call information, where the call information refers to the target class and method; And is configured to convert the parsed request information based on the call information to make it conform to the native language type corresponding to the client, and align and adjust the order of method parameters according to the parameter names of the method; And is configured to perform SDK interface testing based on the converted request information and the call information, and encapsulate the test result data into Json format and return it to the script side; Among them, according to the target process of the SDK interface automation test case, determine the test case script. A test case script will include multiple SDK interface requests and executions. When writing the relevant SDK interface automation test cases according to the test target process, the request content will send each request to the client in sequence according to the call order of each test case. The script side first sends the test request information to the configuration center, which is used to store information such as the SDK version number integrated by the client, the client device IP and port, and the device type; the version number of the SDK interface automation test case executed each time corresponds to the SDK version number to be tested, and only the same version of the SDK can be tested each time; if different versions of the SDK need to be tested, different versions of the SDK need to be tested according to the version number of the SDK interface automation test case. When different versions of tasks are executed each time, the script side's request carries additional version information and client type information through the configuration of the configuration center, and is distributed to various types of clients of different SDK versions to achieve concurrent testing; Among them, the SDK interface automation test cases are independent of each other, and support concurrent execution of SDK interface automation test cases in a multi-threaded or multi-process manner. If concurrent testing is required, each thread or process is responsible for the complete process of an SDK interface automation test case; Among them, after the call of the call information is executed, the type of the SDK interface callback method is judged as an asynchronous method or a synchronous method through the method return type; If it is a synchronous method, the SDK interface directly executes and returns the interface execution result data; If it is an asynchronous method, the callback method of the native language needs to be registered in the global variable class of the client in advance, specifically including: storing the registration content in the global variable class of the client in a dictionary with the string of the input parameter type as the name and the callback method as the value, and retrieving the global variable class storing the callback method when executing the target class and method, and writing the registered callback method into the input callback parameter of the target class and method to be executed. The retrieval method is retrieved according to the type string of the input parameter; when the registered native SDK interface receives data in the callback method, mark that the SDK interface has been executed, store the data for subsequent processing and return it to the script side.

5. The automated test system according to claim 4, wherein The script side includes: A test case writing module for writing SDK interface automation test cases according to the interface information to be tested of the client; A Json format encapsulation module for encapsulating the SDK interface automation test cases and their related information into Json format request information; A test report generation module for receiving the test result data encapsulated in Json format returned by the client and generating a corresponding test report according to the test result data.

6. The automated test system according to claim 4, wherein The script side also includes: A first judgment module for judging whether the test result data is consistent with the expected result; if it is consistent, it is determined that the SDK interface automation test case passes and is marked with PASS; if it is inconsistent, it is determined that the SDK interface automation test case fails and is marked with FAIL; the marked test result data is stored in the form of a test report.

7. A terminal, comprising a memory and a processor, wherein a computer program capable of running on the processor is stored on the memory, characterized in that When the processor runs the computer program, it executes the automation test method according to any one of claims 1 to 3.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein when the computer program is run by a processor, it controls the terminal where the storage medium is located to execute the automated test method described in any one of claims 1 to 3.

Images