Automatic testing method and system

Abstract

The invention discloses an automatic testing method and system, and relates to the technical field of software testing. The test method comprises the following steps: establishing communication connection between a script end and a client; the script end compiles an SDK interface automatic test case, packages the SDK interface automatic test case and related information into request information in a Json format, and sends the request information to the client; the client side receives the request information transmitted by the script side, analyzes the request information and determines calling information; the analyzed request information is converted based on the calling information, so that the analyzed request information conforms to the native language type corresponding to the client side; performing SDK interface testing based on the converted request information and calling information, packaging test result data into a Json format, and returning the test result data to the script end; and the script end receives the test result data which is returned by the client and is packaged into the Json format, 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 in particular to an automated testing method and system. Background Art

[0002] With the rapid development of mobile Internet, mobile client SDK (Software Development Kit) has become an important part of mobile application development, facilitating 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 SDK has become an important issue that needs to be solved 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 and require a lot of human resources, and the client application workload is large and inefficient. In addition, it is difficult for manual testing methods to cover the coverage usage scenarios of all parameters in the Android or IOS SDK interface, such as parameter length, size, quantity, type and other inputs, resulting in potential defects that are difficult to be discovered in a timely manner. Although white box testing and unit testing methods can gradually improve the interface through code analysis, their perspective often stands on the developer's side, lacking test coverage in an integrated environment, and it is difficult to fully evaluate the performance of the SDK in a real integrated testing environment, and the limitations are quite obvious. Moreover, the existing testing methods mainly rely on the native testing frameworks of their respective platforms, such as JUnit for Android and XCTest for IOS, which use native languages ​​(such as Java or Kotlin for Android, Objective-C or Swift for IOS) to write SDK interface unit test cases. This requires familiarity with the native language of a specific platform to write SDK interface unit test cases, which is highly language-dependent and places high technical requirements on test developers. Different platforms need to write test codes in their respective native languages, which increases development costs and script compilation time costs, reduces test flexibility, and results in low testing efficiency. Due to the limitations of unit testing, concurrent execution under integration testing is usually not supported, and the execution efficiency of complex business logic is low. Because the testing framework is limited to a specific platform and has poor scalability, it is difficult to manage unified test logic scripts across platforms under the same business logic, which brings additional complexity to the testing of multi-client SDKs.

[0004] Therefore, for the mobile client SDK development process, 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 also ensures 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, low testing efficiency, poor scalability and insufficient testing coverage of the testing framework and testing method in the prior art.

[0006] To achieve the purpose of the present invention, the present invention adopts the following technical solutions: According to a first aspect of the present invention, there is provided an automated testing method, comprising: The script side and the client side establish a communication connection; The script end writes SDK interface automated test cases, and encapsulates the SDK interface automated test cases and related information into request information in Json format and sends it to the client; The client receives the request information transmitted by the script end, and 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 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 end; The script end 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.

[0007] 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 according to the converted request information and the determined call information and based on the reflection method of different client systems.

[0008] 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 also includes: after executing the call of the call information, judging whether the type of the SDK interface callback method is an asynchronous method or a synchronous method by 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 native language callback method in the global variable class of the client in advance.

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

[0010] A second aspect of the present invention provides an automated testing system, including a script end and a client end for establishing a communication connection; The script end is configured to write SDK interface automated test cases, and encapsulate the SDK interface automated test cases and 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; The client is configured to receive the request information transmitted by the script end, parse the request information, and determine the call information; 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 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.

[0011] According to some embodiments of the present invention, the script side includes: A test case writing module, used to write SDK interface automation test cases according to the interface information to be tested of the client; A Json format encapsulation module is used to encapsulate the SDK interface automated test cases and related information into Json format request information; 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.

[0012] According to some embodiments of the present invention, the script side further includes: The first judgment module is used to judge whether the test result data is consistent with the expected result; if consistent, it is determined that the SDK interface automated test case has passed and is marked with PASS; if inconsistent, it is determined that the SDK interface automated test case has failed and is marked with FAIL; the marked test result data is stored in the form of a test report.

[0013] According to some embodiments of the present invention, the client comprises: A request parsing module, used to parse the request information in Json format sent by the script end, determine the legitimacy of the request information, and determine the call information according to the request information; A parameter serialization conversion module, 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; A reflection execution module, used for executing the call of the call information according to the converted request information and the determined call information and based on the reflection method of different client systems; The second judgment module is used 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; The deserialization module is used to convert the acquired test result data in the native language type into the test result data in the Json format and return it to the script end.

[0014] According to a third aspect of the present application, a terminal is provided, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the above-mentioned automated testing method when running the computer program.

[0015] According to a fourth aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is executed by a processor, the terminal where the storage medium is located is controlled to execute the above-mentioned automated testing method.

[0016] According to the technical solution provided by the present invention, at least the following beneficial effects are achieved: according to the interface method to be called obtained from the client system, the script end can use a variety of scripting languages ​​(such as C#, Java, Python, etc.) to write SDK interface automation test cases, and then uniformly encapsulate the request information in Json format and send it to the client, which greatly reduces the dependence on the native language of the client system and reduces the learning cost. Through the transmission method of Json format, the decoupling of the test script and the client SDK is higher, and the complexity of expansion and maintenance is reduced. After the client of different systems receives the request information in a uniform encapsulation format, the request information is parsed to determine the call information, that is, to determine the target class and method to be called, and then the parsed request information is converted into the native language type that conforms to the client system, and then the interface test is performed based on the reflection method of different client systems. The same SDK interface automation test case can be applied to clients of multiple different systems for testing, 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 end.

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

[0018] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The above and / or additional aspects and advantages of the present invention will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which: Figure 1 A flowchart of an automated testing method according to an embodiment of the present invention; Figure 2 A schematic diagram of content requirements for dynamic reflection conversion and return based on the source code of the native language Android; Figure 3 A schematic diagram of content requirements for dynamic reflection conversion and return based on the source code of the native language IOS; Figure 4 This is the Json format data code diagram requested by the script side to the client; Figure 5 A schematic diagram of the structure of concurrent execution of an embodiment of the present invention; Figure 6 is a structural block diagram of the script end of an embodiment of the present invention; Figure 7 4 is a structural block diagram of a client according to an embodiment of the present invention. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with 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 intended to limit the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0021] It should be noted that, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first", "second", etc. 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 "many" is more than two, greater than, less than, exceed, etc. are understood to exclude the number itself, and above, below, within, etc. are understood to include the number itself.

[0022] This application aims to propose a general mobile client SDK automated testing method and system, based on a dynamic reflection mechanism and a unified JSON format communication protocol, focusing on in-depth verification of the underlying logic interface of the SDK, and does not involve testing of the interface layer (Presentation Layer) or interface toolkit (UIKit, etc.). By focusing on the interface verification of the core functional modules, the automated testing of the interface logic layer is realized, which is decoupled from the testing requirements of the user interaction layer, thereby ensuring the efficiency and stability of the test. Through standardized data transmission and result feedback mechanisms, the SDK interfaces of Android and IOS can be quickly adapted to achieve consistent logic verification across platforms. Multiple clients are executed concurrently, and the capabilities are further improved, which improves the testing efficiency, meets the efficient testing requirements of complex business scenarios, and optimizes the development and testing process of the mobile client SDK. It solves the problems of strong language dependence, low testing efficiency, poor scalability, and insufficient testing coverage of the testing framework and testing methods in the prior art.

[0023] like Figure 1 As shown, the first embodiment of the present application provides an automated testing method, comprising the following steps: Step S100: The script end and the client end establish a communication connection.

[0024] In this step, when the script end and the client are in the same local area network, the two interact through IP addresses and use the HTTP protocol to achieve communication. When the script end and the client are in different local area networks, or in scenarios where 4G, 5G networks or no network need to be tested, it is necessary to connect the device terminal device through different client data lines to connect the two network open services in port forwarding mode. For example, Android's adb forward or IOS iproxy command forwards the service port open by the client to the port of the script end running machine through the data line for network data communication. The script end communicates with the client device through the locally forwarded port and transmits the data to the client for interaction requests.

[0025] Step S200: The script end writes an SDK interface automated test case, and encapsulates the SDK interface automated test case and its related information into a Json format request message and sends it to the client.

[0026] Before writing SDK interface automated test cases (test cases written in code) on the script side, the script side needs to convert normal functional test cases (test cases described in Chinese) or product requirement documents into SDK interface automated test cases, and organize the native SDK interfaces to be tested (native languages ​​such as classes and method interfaces of IOS platform language Objective-C / Swift or classes and method interfaces of Android platform Java / Kotlin language) that need to be executed through SDK interface automated test cases. Mainly through normal functional 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 automated test cases, and clarify their related information. The related information includes the target classes and methods that need to be called, specifically determining the class name, method name, and the required parameter types and parameter order, to provide a basic basis for writing SDK interface automated test cases.

[0027] Based on the above relevant information, the script side writes the corresponding SDK interface automated test cases. The specific process is as follows: The native SDK interface to be tested is sorted out according to the above SDK interface automation test cases, and the specific classes and methods are determined. Then the script side dynamically obtains the native language class, method and specific parameter name and type of the native SDK interface to be tested from the client by requesting specific class and method parameters. The main purpose is to convert the native language class of the native SDK interface to be tested into the agreed standard type format and return it. If the class and method exist and can be called, the specific Json serialized content is returned. If the class and method do not exist or cannot be called, the content that the class and method cannot be called is returned, so that the tester can call the SDK native language interface according to the returned content even if he is not familiar with or does not understand the native language at all.

[0028] According to the above SDK interface automated test case, 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 class method construction example of the dynamic reflection extraction returned by the client in the native language by requesting the client's general interface getInterfaceParams. In this construction example, the class name, method name, request field name, request field type, etc. that need to be included in the Json construction example of the SDK interface to be returned need to be obtained.

[0029] It should be noted that due to the particularity of the iOS native language, it is impossible to obtain the names and fields required by 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 ".h" type header files of the relevant classes of iOS, and store the field names and types required by the relevant classes and methods in the iOS client. When the iOS client is started, it is loaded into the memory to provide dynamic reflection for the script side.

[0030] The following are the Json serialized content codes returned to the script side through the two client native language reflections obtained through the classes and methods requested by the script side.

[0031] like Figure 2 The following is a schematic diagram of the Json serialization content requirements based on the native language Android, which is dynamically reflected and converted according to the source code of the native SDK interface to be tested on the Android client and returned to the script end; Figure 3 The figure shows the Json serialization content requirement diagram based on the native language IOS, which is dynamically reflected and converted according to the source code of the native SDK interface to be tested on the IOS client and returned to the script end.

[0032] based on Figure 2 and Figure 3In the return example, the alignment test method and field type are constructed into the corresponding SDK interface request Json format data, which is used when calling the native SDK interface when writing SDK interface automated test cases. When the field type is a non-basic type (such as int, bool, str, etc.), the Json construction of the field should be transmitted as a dictionary type. When the field type is a basic type, it is transmitted as a computer-general type such as int, bool, str, etc. Finally, according to the determined target class is RongCoreClient and the method is setConversationToTop, the single interface construction script side requests the Json format data code to the client side as follows Figure 4 shown.

[0033] According to the target test class and method, the client can construct and generate the script-side test Json request required by the native SDK interface to be tested through the above steps, and then send the Json content of the request to the client to test the native SDK interface.

[0034] Determine the test case script according to the target process of the SDK interface automated test case. Usually, a test case script will contain multiple SDK interface requests and executions. When writing related 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 calling order of each test case.

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

[0036] It should be noted that each SDK interface automated test case can be designed as an independent task without dependencies. The SDK interface requests sent by each task are guaranteed to be independent of each other and do not share states or resources (use isolated sessions or environments if necessary).

[0037] Based on the independence between the above-mentioned SDK interface automation test cases, it supports the concurrent execution of SDK interface automation test cases in multi-threaded or multi-process mode. If concurrent testing is required, each thread or process is responsible for the complete process of an SDK interface automation test case. The script end 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 the SDK version number integrated by the client, the client device IP and port, the device type and other information; on the other hand, the version number of the SDK interface automation test case for each task executed is corresponding to the SDK version number to be tested, and only the same version of the SDK is supported for each test; if different versions of SDK tests need to be executed, different versions of the SDK need to be tested according to the version number of the SDK interface automation test case. Each time a different version of the task is executed, the script end's request carries additional version information and client type information, which is distributed to various types of clients of different SDK versions through the configuration of the configuration center to implement concurrent testing, thereby improving test efficiency. The structural diagram of concurrent execution is shown in the figure below. Figure 5 shown.

[0038] Step S300, the client receives the request information transmitted by the script end, and parses the request information to determine 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; and performs SDK interface testing based on the converted request information and call information, and encapsulates the test result data into Json format and returns it to the script end.

[0039] In this step, if the script side and the client need to interact through the HTTP protocol, an HTTP server needs to be established on the client side to parse the Json format request information sent by the script side and determine the legality of the request information. For example, determine whether the calling 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, the call failure is returned, and the reason for the call failure is indicated in the return data. For example, the class or method does not exist, the parameter type and quantity are wrong, and other information.

[0040] In this step, after determining that the request information is legal, the client determines the calling information based on the request information. The calling information in this application refers to the target class and method.

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

[0042] The call information (target class and method) is called 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 Android's method.invoke and IOS's method.invoke.

[0043] After executing the call information (target class and method), the type of the SDK interface callback method is comprehensively judged through native language reflection (such as Androidmethod.getReturnType() and IOS signature.methodReturnType and whether there are callback parameters). If the return parameter is void and the input parameter has callback and other similar methods, the type of the SDK interface callback method can be considered to be an asynchronous method, otherwise it is a synchronous method.

[0044] If it is a synchronous method, the native SDK interface to be tested will be executed immediately and the interface execution result data will be returned. Specifically, after waiting for the execution of the native SDK interface to be completed, the execution result data of the executed native SDK interface will be stored for subsequent processing and returned to the script end. 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, that is, the native SDK interface callback method; the dictionary with the input parameter type string as the name and the callback method as the value will store the registered content in the global variable class of the client, and when the target class and method are executed, the global variable class storing the callback method is retrieved, and the registered callback method is written to the input of the target class and method to be executed, such as the callback parameter, and 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, it marks the execution of the SDK interface as completed, stores the data for subsequent processing and returns it to the script end.

[0045] It should be noted that the difference between synchronous methods and asynchronous methods is that synchronous methods usually return execution result data immediately, while asynchronous methods cannot confirm the returned execution time. Therefore, it is necessary to add a default timeout to asynchronous methods to avoid long asynchronous callback waiting time, which will cause subsequent input test cases to be blocked for a long time. If the data returned by the native SDK interface callback method is still not received after the scheduled time, relevant information such as timeout will be returned to the script side, such as SDK interface execution timeout.

[0046] After obtaining the test result data (i.e., the result data returned by the execution of the native SDK interface stored above), a deserialization operation is performed to convert the test result data of the native language type into the test result data in Json format through the deserialization module and return it to the script end. This request to the SDK interface is completed.

[0047] Step S400: The script end 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.

[0048] 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 automated test case has passed and marked as PASS; if the test result data is inconsistent with the expected result, it is determined that the SDK interface automated test case has failed and marked as FAIL; then all interface test request input parameters, client returned parameters, expected results and marked test result data are stored in the form of a test report.

[0049] A second aspect of the present application provides an automated testing system, including a script end and a client end, wherein the script end and the client end establish a communication connection.

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

[0051] Client: configured to receive request information transmitted by the script end, parse the request information, and 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; and configured to perform SDK interface testing based on the converted request information and call information, and encapsulate the test result data into Json format and return it to the script end.

[0052] It should be noted that when the script end and the client are in the same LAN, the two interact through IP addresses and use the HTTP protocol to achieve communication. When the script end and the client are in different LANs, or in scenarios where 4G, 5G networks or no network are required to be tested, it is necessary to connect the device terminal device through different client data lines to connect the two network open services in port forwarding mode. For example, Android's adb forward or IOS iproxy command forwards the service port open by the client to the port of the script end running machine through the data line for network data communication. The script end communicates with the client device through the locally forwarded port and transmits data to the client for interactive requests.

[0053] In some specific embodiments of the present application, Figure 6 As 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.

[0054] in, The test case writing module is used to write SDK interface automation test cases based on the client's interface information to be tested; Json format encapsulation module, used to encapsulate SDK interface automated test cases and related information into Json format request information; 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 based on the test result data.

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

[0056] In some specific embodiments of the present application, Figure 7 As 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.

[0057] in, The request parsing module is used to parse the request information in Json format sent by the script end, determine the legitimacy of the request information, and determine the call information based on the request information; The parameter serialization conversion module is used to convert the parsed request information based on the call information to make it conform to the native language type corresponding to the client system; A reflection execution module, used for executing the call of the call information according to the converted request information and the determined call information and based on the reflection method of different client systems; The second judgment module is used 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 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, the callback method of the native language needs to be registered in the global variable class of the client in advance; The deserialization module is used to convert the acquired test result data in native language type into test result data in Json format and return it to the script end.

[0058] The above-mentioned automatic testing system can be implemented through an integrated circuit or a chip, and is not specifically limited in this application.

[0059] By adopting the automated testing method and system in the above technical solution, the script side allows the use of multiple scripting languages ​​(such as Python, C#, Java, etc.) to write SDK interface automated test cases to achieve language independence. Through the unified generated encapsulation interface, the impact of platform differences on the test logic is reduced, and a set of test cases can be used on Android and IOS platforms. The client uses the dynamic reflection mechanism of the native language of Android and IOS to directly call the SDK interface, which can be developed once. The interface method changes and parameter changes do not need to be re-encapsulated by the native interface again, and can be dynamically called. Through the transmission method of Json format, the test script is more decoupled from the client SDK, reducing the complexity of expansion and maintenance. It supports dynamic interface detection and calling, and can quickly adjust the calling parameters and methods according to the test requirements to adapt to the rapid iteration of different versions of SDK. It supports concurrent execution of tests on multiple clients at the same time, significantly shortens the test cycle, provides an efficient concurrent scheduling mechanism, and can complete the execution of a large number of test cases in a short time, which is particularly suitable for fast regression test scenarios. The execution results of multiple clients can be integrated into a unified test report to facilitate the statistics and analysis of test results.

[0060] The third aspect of the present application also provides a terminal, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the above-mentioned automated testing method when running the computer program.

[0061] Specifically, the processor may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this 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.

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

[0063] 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, or an EEPROM, CD-ROM or other optical disk storage, optical disk storage (including compact disc, laser disc, optical disk, digital versatile disc, Blu-ray disc, etc.), magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

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

[0065] The fourth aspect embodiment of the present application also provides a computer-readable storage medium, which includes a stored computer program, wherein when the computer program is executed by the processor, the terminal where the storage medium is located is controlled to execute the above-mentioned automated testing method.

[0066] It will be appreciated by those skilled in the art that all or some of the steps and systems in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or transient medium). As known to those skilled 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 include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media generally contain computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

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

[0068] The embodiments of the present invention are described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Various changes can be made within the knowledge scope of ordinary technicians in the technical field without departing from the purpose of the present invention.

Claims

1. An automated testing method, characterized in that: include: The script side and the client side establish a communication connection; The script end writes SDK interface automated test cases, and encapsulates the SDK interface automated test cases and related information into request information in Json format and sends it to the client; The client receives the request information transmitted by the script end, and parses the request information to determine the calling information; and converting the parsed request information based on the call information to make it conform to the native language type corresponding to the client; And performing SDK interface test based on the converted request information and the call information, and encapsulating the test result data into Json format and returning it to the script end; The script end 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.

2. The automated testing method according to claim 1, characterized in that: The step of performing SDK interface testing based on the converted request information and the call information includes: The calling of the calling information is executed according to the converted request information and the determined calling information and based on the reflection method of different client systems.

3. The automated testing method according to claim 2, characterized in that: 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, judging whether the type of the SDK interface callback method is an asynchronous method or a synchronous method by the method return type; If it is a synchronous method, the SDK interface is executed directly and returns the interface execution result data; If it is an asynchronous method, you need to register the callback method of the native language in the global variable class of the client in advance.

4. The automated testing method according to claim 1, characterized in that: The script end 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, including: Determine whether the test result data is consistent with the expected result; If they are consistent, it is determined that the SDK interface automated test case has passed and is marked as PASS; If they are inconsistent, it is determined that the SDK interface automated test case fails and is marked as FAIL; The marked test result data is stored in the form of a test report.

5. An automated testing system, characterized in that: Includes script side and client side for establishing communication connection; The script end is configured to write SDK interface automated test cases, and encapsulate the SDK interface automated test cases and 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; The client is configured to receive the request information transmitted by the script end, and parse the request information to determine the call information; and is configured to convert the parsed request information based on the call information so as to conform to the native language type corresponding to the client; And it is configured to perform SDK interface test 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.

6. The automated testing system according to claim 5, characterized in that: The script side includes: A test case writing module, used to write SDK interface automation test cases according to the interface information to be tested of the client; A Json format encapsulation module is used to encapsulate the SDK interface automated test cases and related information into Json format request information; 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.

7. The automated testing system according to claim 5, characterized in that: The script side also includes: The first judgment module is used to judge whether the test result data is consistent with the expected result; if consistent, it is determined that the SDK interface automated test case has passed and is marked with PASS; if inconsistent, it is determined that the SDK interface automated test case has failed and is marked with FAIL; the marked test result data is stored in the form of a test report.

8. The automated testing system according to claim 5, characterized in that: The client comprises: A request parsing module, used to parse the request information in Json format sent by the script end, determine the legitimacy of the request information, and determine the call information according to the request information; A parameter serialization conversion module, 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; A reflection execution module, used for executing the call of the call information according to the converted request information and the determined call information and based on the reflection method of different client systems; The second judgment module is used 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; The deserialization module is used to convert the acquired test result data in the native language type into the test result data in the Json format and return it to the script end.

9. A terminal comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor runs the computer program, the automated testing method according to any one of claims 1 to 4 is executed.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein when the computer program is executed by a processor, the terminal where the storage medium is located is controlled to execute the automated testing method according to any one of claims 1 to 4.

Images