A test method, device and readable storage medium of a software development kit

Abstract

The embodiment of the application provides a kind of software development kit test method and related equipment, can reuse the test case in business test, without re-generating test case in SDK test, improve the test efficiency of SDK.The method comprises: calling the test case and test script generated when executing business test on target application, and the test case includes the test data corresponding to the target application and business execution condition;Determine the call interface for test data in business execution condition;Interface method adaptation is carried out to the call interface, to obtain the target method corresponding to the software development kit SDK to be tested;Call target method to execute test data, and obtain response result;Response result is matched with the expected value in test script, to obtain the test result corresponding to the SDK to be tested.

Description

Technical Field

[0001] This application relates to the field of software development, and more particularly to a method, apparatus, and readable storage medium for testing a software development kit. Background Technology

[0002] A software development kit (SDK) is generally a collection of development tools used by software engineers to create application software for specific software packages, software frameworks, hardware platforms, operating systems, etc.

[0003] As SDKs become increasingly prevalent in software development, automated testing tools for SDKs are also being integrated into the entire software development process. Currently, SDK testing primarily involves generating and storing test cases for the SDK's external interfaces, loading and executing these test cases, and generating corresponding test case reports.

[0004] However, due to the characteristics of different programming languages, in order to adapt the testing of SDKs for different programming languages, it is necessary to modify the test cases corresponding to the SDKs of each programming language. This will prolong the testing time of SDKs when testing SDKs of multiple programming languages, thereby reducing the testing efficiency of SDKs. Summary of the Invention

[0005] This application provides a testing method and related equipment for a software development kit (SDK), which can reuse test cases from business testing without modifying the test cases, thereby improving the testing efficiency of the SDK.

[0006] One embodiment of this application provides a testing method for a software development kit, including:

[0007] Invoke the test cases and test scripts generated when performing business tests on the target application. The test cases include the test data corresponding to the target application and the business execution conditions.

[0008] Identify the API calls for the test data within the business execution conditions;

[0009] The API calls are adapted to match the target methods of the SDK under test.

[0010] The target method is invoked to execute the test data, and the response result is obtained;

[0011] The response results are matched with the expected values ​​in the test script to obtain the test results for the SDK under test.

[0012] Another aspect of this application provides a software development kit testing apparatus, comprising:

[0013] The first calling unit is used to call the test cases and test scripts generated when performing business tests on the target application. The test cases include the test data corresponding to the target application and the business execution conditions.

[0014] The determination unit is used to determine the calling interface for the test data in the business execution conditions;

[0015] The adaptation unit is used to adapt the interface method of the calling interface to obtain the target method corresponding to the software development kit (SDK) under test.

[0016] The second invocation unit is used to invoke the target method to execute the test data and obtain the response result;

[0017] The matching unit is used to match the response result with the expected value in the test script to obtain the test result corresponding to the SDK under test.

[0018] In one possible design, the second calling unit is also used for:

[0019] The framework of the programming language corresponding to the SDK under test is invoked to encapsulate the SDK under test into an SDK service;

[0020] The SDK service is identified as the target process, which is a resident process in the system memory.

[0021] The second invocation unit calls the target method to execute the test data, and the response results include:

[0022] The target process loads and calls the target method to execute test data and obtain response results.

[0023] In one possible design, the determining element is also used for:

[0024] If the version of the SDK under test is updated, then determine the update content corresponding to the version update of the SDK under test;

[0025] Update the SDK to be tested according to the update content corresponding to the version update of the SDK to be tested.

[0026] In one possible design, the unit determines the updates to the SDK under test based on the version update content, including:

[0027] Replace the SDK under test with the version update corresponding to the update content;

[0028] Load the replaced SDK to be tested in order to update the SDK under test;

[0029] or,

[0030] For each version update of the SDK under test, the SDK under test is updated using a hot update method.

[0031] In one possible design, the device further includes:

[0032] Analysis unit, the analysis unit is used for:

[0033] When the target method is called to execute test data, CPU data, disk data, network data, input / output system data, and memory data are collected in real time.

[0034] A test analysis report is generated based on data from the central processing unit, disk, network, input / output system, and memory.

[0035] In one possible design, the adapter unit is specifically used for:

[0036] If the address writing rules of the called interface conform to the preset rules, then the target method is determined according to the address writing rules of the called interface;

[0037] If the address writing rules of the called interface do not conform to the preset rules, the target method is determined according to the called interface and the preset interface method mapping table.

[0038] In one possible design, the first calling unit is also used for:

[0039] Obtain the configuration information for the SDK under test, including the language version of the SDK under test, the service address of the SDK under test, and the address of the preset interface method mapping table;

[0040] The SDK to be tested is invoked based on the language version of the SDK service to be tested and the service address of the SDK to be tested. The SDK to be tested is the SDK corresponding to any one of N programming languages, where N is an integer greater than or equal to 1.

[0041] Retrieve the preset interface method mapping table based on the address of the preset interface method mapping table.

[0042] Another embodiment of this application provides a computer device, including a memory, a processor, and a bus system; wherein the memory is used to store a program, the bus system is used to connect the memory and the processor to enable communication between the memory and the processor; the processor is used to execute the program in the memory, and the processor is used to execute the testing method of the software development kit described above according to the instructions in the program code.

[0043] Another aspect of this application provides a computer storage medium including instructions that, when executed on a computer, cause the computer to perform the testing method of the software development kit described in the above aspects.

[0044] In summary, it can be seen that in this embodiment of the application, when testing the SDK, the test cases and test scripts corresponding to the target application that has completed business testing are reused. At the same time, the methods of the SDK under test corresponding to the interfaces in the test cases are determined by the conversion method of interfaces and methods, and the test is executed by calling the SDK under test. Since it is not necessary to modify the test cases every time, the testing time of the SDK is reduced and the testing efficiency of the SDK is improved. Attached Figure Description

[0045] Figure 1 A schematic diagram comparing the architectures of software development kit testing and business testing provided in the embodiments of this application:

[0046] Figure 2 This is a schematic diagram illustrating data transformation of test cases when testing a software development kit, as provided in an embodiment of this application.

[0047] Figure 3 A schematic diagram of a test process for a software development kit provided in an embodiment of this application;

[0048] Figure 4 Another test process diagram for the software development kit provided in the embodiments of this application;

[0049] Figure 5 A flowchart illustrating the testing method for the software development kit provided in this application embodiment;

[0050] Figure 6 A schematic diagram illustrating interface method adaptation during SDK testing, provided as an embodiment of this application;

[0051] Figure 7 A schematic diagram illustrating the driver service of the SDK under test provided in this application embodiment;

[0052] Figure 8 A schematic diagram of the virtual structure of the software development kit testing device provided in the embodiments of this application;

[0053] Figure 9 This is a schematic diagram of the hardware structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0054] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0055] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The division of modules appearing in this application is merely a logical division; in practical applications, other division methods may be used. For example, multiple modules may be combined or integrated into another system, or some feature vectors may be ignored or not executed. Additionally, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interface, and the indirect coupling or communication connection between modules may be electrical or other similar forms, none of which are limited in this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separate, may or may not be physical modules, or may be distributed among multiple circuit modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution in this application.

[0056] Please see Figure 1 , Figure 1 This diagram illustrates a comparison of business testing and SDK testing frameworks in this application. Business testing involves the system testing the target application, generating test cases and scripts during the testing process. SDK testing involves users calling the target application through the SDK. Therefore, for SDK testing, test cases and scripts from the original backend testing can be reused. Figure 1 As shown, it includes the use case layer, adaptation layer, driver layer, SDK layer, and business layer.

[0057] Figure 1 Test case 101 in the text is a test case generated during the business testing of the target application. This test case includes test data and test execution conditions. The test execution conditions are which interface is called to perform what kind of test on the target application.

[0058] Adaptation Layer: The test script sends the test request (a test request for business testing of the target application) to the adaptation layer. The adaptation layer, based on configuration parameters and interface method mapping data, sends the test data to the driver service. The configuration parameters include the language version of the SDK to be tested, the address of the driver service for that language version of the SDK, and the address of external storage data (the address of external storage storing the interface method mapping relationship). This interface method mapping is mainly used to map and convert between interfaces and methods in the SDK, thereby dynamically loading and calling methods in the SDK based on the method name to initiate calls to the target application. The following section combines... Figure 3 Explanation:

[0059] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating data transformation of test cases provided in an embodiment of this application, wherein, as shown... Figure 2 As shown, test case 201 includes a Uniform Resource Locator (URL): "http: / / 127.0.0.1:12345 / refund / create". "http: / / 127.0.0.1:12345 / refund / create" represents the address of the API call, where "refund" represents the class and "create" represents the method. "method: post" indicates the request method for the method in the SDK under test, i.e., calling the method in the SDK under test via "post". body{"a": 1, "b": 2} represents the input parameters in the method call corresponding to the SDK under test. Data transformation of test case 201 yields the invoke in 202: {"class": "refund", "method": "create"}, indicating which class and which method should be called when calling the method in the SDK under test, with parameters {"a": 1, "b": 2}, which is the "refund" parameter in the URL of this test case. The class and method referenced by "create" can be obtained through the interface method mapping table as {"class": "refund", "method": "create"}, and the input parameters of the method as {"a": 1", "b": 2}.

[0060] The driver service encapsulates the SDK to be tested into an SDK service and sets it as a resident process in system memory. This allows the SDK to be called via hot reloading and dynamic invocation during testing. The driver service can use reflection and dynamic invocation to call methods in SDKs corresponding to different programming languages ​​within the SDK layer. Reflection encapsulates the components of a class into other objects, dynamically retrieving attributes of the class or object during application runtime.

[0061] In the business layer, the methods in the SDK under test are called to execute the test data in the test cases, obtain the response results of the target application, and match the response results with the expected values ​​in the test script to obtain the test results of the SDK.

[0062] Because the testing method of the software development kit in this application can test SDKs corresponding to multiple programming languages, an interface method adaptation layer 102 is needed to adapt the methods of SDKs corresponding to multiple programming languages ​​(it can be understood that these multiple programming languages ​​include, but are not limited to, commonly used programming languages ​​such as Java and C++). This allows test cases to adapt to SDK process testing corresponding to different programming languages. For example, the Java driver service in 103 can obtain the interface corresponding to the test data contained in the test execution conditions of the test case through interface method adaptation 102. Then, it obtains the method in the Java SDK through a preset interface method mapping table, and executes the test data in the test case by calling the method to obtain the response result of the target application 104. Then, it matches the response result with the expected value corresponding to the test data contained in the test script to obtain the test result of the SDK under test. In this way, since test cases and test scripts of business tests can be reused during SDK testing, there is no need to spend extra time generating SDK test cases, which can reduce SDK testing time and improve SDK testing efficiency.

[0063] The following is combined with Figure 3 For a description of the testing process for the software development kit of this application, please refer to [link / reference]. Figure 3Test case 301 is a test case generated during business testing of the target application. Interface method adaptation 302 can determine that the test execution conditions in the test case include the calling interface for the test data. Then, interface method adaptation is performed on the calling interface to obtain the target method corresponding to the SDK under test. At the same time, the SDK under test can be encapsulated into a service through 303 and set as a resident process in system memory. After obtaining the target method corresponding to the SDK under test, the target method can be called through the resident process to test the test data and obtain the response result of the target application 304. Then, the test result of the SDK corresponding to the Java programming language is determined by the response result and the expected value of the test data in the test script.

[0064] The testing method for the software development kit provided in this application embodiment is described below based on business characteristics and data flow.

[0065] like Figure 4 The test case 401 is a test case generated by the target application 404 during the business testing process. For example, test case 4061 in data flow includes:

[0066] url: http / / 127.0.0.1:12345 / refund / create

[0067] method: post

[0068] body{"a": 1, "b": 2};

[0069] Wherein, "url:http: / / 127.0.0.1:12345 / refund / create" represents the address of the SDK interface to be tested, that is, which interface needs to be called, method:post indicates that the method of requesting the SDK to be tested is "post"; body{"a":1","b":2} represents the parameters of the method in the SDK to be tested.

[0070] Then, by adapting the 402 error to the data in 4061, the data in 4062 is obtained:

[0071] {

[0072] "invoke" {"class": "refund", "method": "create"}

[0073] "params" {"a": 1, "b": 2}.

[0074] }

[0075] The referenced class and method can be obtained through the interface method mapping table as {"class": "refund", "method": "create"}, and the input parameters of the method are {"a": 1", "b": 2}.

[0076] It should be noted that when adapting interface methods, it is also necessary to obtain the corresponding business characteristics, namely the interface method mapping table and configuration information. The configuration information includes the language version of the SDK under test (such as Java, C++, etc.), the driver service address corresponding to the language version (since the SDK resides in the system memory as a service, the corresponding process can be found in the process through the driver service address to dynamically load and call the calling service in the SDK), and the address of external storage data (that is, the external storage address that stores the interface method mapping table). The interface method mapping table can be obtained through the address of the external storage data. The interface method mapping table is mainly used to map and convert the interface and the methods in the SDK, so that the driver service 403 can dynamically load and call the methods in the SDK according to the method name, thereby realizing the test of the target application 404 and obtaining the test results.

[0077] In the 405 service characteristics, after determining the driver service address, the corresponding process can be found in system memory through that address. The method name to be called can be determined through the interface method mapping table in the 405 error. Then, the SDK method corresponding to that method name can be dynamically loaded and called through the corresponding process. This allows testing of the background parameters by inputting the method's parameters into test cases, yielding test results. During the dynamic invocation of SDK methods through the corresponding process, performance data, such as CPU data, memory data, and I / O system data, can be read in real time. This performance data can then be used to analyze issues such as memory leaks and performance bottlenecks in the SDK. Simultaneously, code coverage information can be obtained. SDKs for different programming languages ​​can obtain code coverage information in different ways. For example, C++ can use gcov for coverage collection, while Java can use jcov or jacoco for coverage collection, thus identifying uncovered program code for supplementary test coverage.

[0078] It is understandable that after calling the target method to execute the test data and obtaining the running result, the running result can be matched with the expected value corresponding to the test data in the test script to obtain the test result.

[0079] Based on the above introduction, the testing method of the software development kit in this application will be described from the perspective of the software development kit testing device.

[0080] Please see Figure 5 One embodiment of the testing method for the software development kit in this application includes:

[0081] 501. Call the test cases and test scripts generated when performing business tests on the target application.

[0082] In this embodiment, the software development kit (SDK) testing device can invoke test cases and test scripts generated during business testing of the target application. The test cases include test data corresponding to the target application and business execution conditions (including, but not limited to, the test process, test interface, and test environment required to execute the test data). For example, a test case could be "adding customer information with an empty name, adding customer information with a name exceeding 20 Chinese characters, or adding customer information with a name containing single quotes." The business execution conditions include, for example, the test environment, test process, and calling interface required for the target application. It is understood that business testing of the target application is performed before testing the SDK under test. During the testing of the target application, corresponding test cases and test scripts are generated. The test data in the test cases generated during business testing of the target application is executed using methods in the SDK under test. Therefore, test cases and test scripts from the background testing can be reused for testing the SDK under test.

[0083] 502. Determine the API calls for test data in the business execution conditions.

[0084] In this embodiment, after obtaining the business execution conditions, the software development kit testing device can parse the business execution conditions and then obtain the calling interface for the test data in the business execution conditions. The SDK to be tested is the SDK corresponding to any one of N programming languages, where N is an integer greater than or equal to 1.

[0085] 503. Adapt the API call method to obtain the target method corresponding to the SDK under test.

[0086] In this embodiment, since the SDK under test can be programmed in different programming languages, the test conditions and test data required for the external development interface of the SDK under test will be different for different programming languages. Therefore, it is necessary to adapt the calling interface to obtain the target method in the SDK under test for the calling interface.

[0087] Specifically, the software development kit (SDK) testing device can first determine the address writing rules of the called interface and then determine whether these rules conform to preset rules. These preset rules refer to the fact that the address of the called interface includes both "class" and "method". To determine whether the address writing rules of the called interface conform to the preset rules, it is only necessary to check whether the address of the called interface includes both "class" and "method". The following section will further explain... Figure 2 Please provide an explanation, such as Figure 2 The address of the API call shown in 201, "url: http: / / 127.0.0.1:12345 / refund / create", includes the class and method being called, conforming to preset rules. Therefore, the target method can be determined based on the rules for writing API call addresses, resulting in... Figure 2 The “invoke”{“class”:“refund”,“method”:“create”} shown in 202 means that the “create” method in the “refund” class of the SDK under test is invoked. The “create” method in the “refund” class is the target method. If the address writing rules of the calling interface do not conform to the preset rules, the target method is determined according to the calling interface and the preset interface method mapping table.

[0088] As can be understood, a mapping is a collection of key / value pairs that store keys and values. Given a key, its corresponding value can be determined through the mapping. This pre-defined interface method mapping table stores multiple interfaces, including those callable by the SDK to be tested, and multiple methods corresponding to those interfaces. For example, if the "Error interface" defines a unique "RuntimeError method," then in the pre-defined interface method mapping table, the "Error interface" and the "RuntimeError method" are mapped together. Similarly, if the "Message interface" defines a unique "ProtoMessage method," then in the pre-defined interface method mapping table, the "Message interface" and the "ProtoMessage method" are mapped together. Once the calling interface is determined, the corresponding method can be found in the pre-defined interface method mapping table. Furthermore, the above mapping relationship between calling interfaces and methods is only an example; other mapping relationships between calling interfaces and methods are possible and not limited to this.

[0089] It should be noted that the preset interface method mapping table is obtained by the software development kit testing device through the address of external storage data in the configuration file. The function of the preset interface method mapping table is to convert the called interface into a specific method in the SDK.

[0090] The following is combined with Figure 6 For instructions on interface method adaptation, please refer to [link / reference]. Figure 6 , Figure 6 This is a schematic diagram illustrating the interface method adaptation provided in the embodiments of this application. The interface method adaptation includes configuration information 601 and an interface method mapping table 602. The configuration information 601 can be stored in a fixed cache 6011, a database 6012, or a configuration file 6013. The cache 6011 can be, for example, shared memory or Redis. Redis is an abbreviation for Remote DIctionary Server, which is an open-source, cross-platform, non-relational database written in ANSI C, conforming to the Berkeley Software Distribution (BSD) license, supporting networks, and providing in-memory, distributed, and optionally persistent key-value storage. It also provides application programming interfaces (APIs) in multiple languages.

[0091] The configuration information 601 includes the programming language of the SDK under test, the driver service address corresponding to the programming language of the SDK under test, the interface method mapping table address, and other configurations required for SDK testing. Among them, the programming language of the SDK under test refers to the programming language in which the SDK was written, such as the SDK under test written in Java; the driver service address refers to the address through which the SDK under test can be found when it is called; and the interface method mapping table address is the address where the interface method mapping table is stored.

[0092] The interface method mapping table 602 can be obtained through its address. This table converts the API calls in the test cases for the test data into specific methods in the SDK under test. For the same test data, SDKs programmed in different programming languages ​​may call different methods. Therefore, different versions of the interface method mapping table can be maintained based on the programming language version of the SDK under test. Figure 6 The 603 error includes interface method mapping tables for the SDKs corresponding to both C++ and Java programming languages. When determining the target method called in the SDK under test based on the calling interface, if the address writing rules of the calling interface conform to preset rules, the target method is directly determined based on the interface address in the calling interface, such as... Figure 6As shown in 604, the interface address is "http: / / 127.0.0.1:12345 / refund / create". The call interface 605 is "refund / create". By converting the interface address of the call interface according to certain rules, we can get the class shown in 606 and the method shown in 607. Here, "refund" is the class and "create" is the method, which means calling the create method in the refund class. The call interface can also be "payment / create" as in 605, the class can be "payment" as in 606, and the method can be "create.order" as in 607.

[0093] Understandable Figure 6 The interfaces 605, 606, and 607 mentioned are just examples. Of course, there can be other interfaces, classes, and methods that can be called, and there are no specific limitations.

[0094] 504. Call the target method to execute the test data and obtain the response result.

[0095] In this embodiment, after obtaining the target method, the software development kit (SDK) testing device further calls the target method to execute test data and obtain response results. Specifically, it can call the framework of the programming language corresponding to the SDK under test to encapsulate the SDK under test into an SDK service. Then, it determines the SDK service as the target process, which is a resident process in system memory. The target process loads and calls the target method to execute test data and obtain response results. That is, the software development kit testing device can first encapsulate the SDK under test into a service and set the service as a resident process in system memory. In this way, when calling the SDK under test for testing, it can be loaded and called using a hot-start method. For example, if the SDK under test is an SDK written in the Java programming language, the Spring Boot architecture can be used to encapsulate the SDK under test into a service. At the same time, using the reflection mechanism, the determined target method is loaded according to the class and method name, and the target method is called to execute test data and obtain response results.

[0096] The following is combined with Figure 7 The driver service of the SDK under test in this embodiment is described below. This driver service encapsulates the SDK under test in the corresponding language, encapsulates the SDK under test as a service, and sets the service as a process resident in the operating system's memory. This service can receive parameters, which are divided into two parts: one part indicates the loading and invocation of the target method in the SDK under test, and the other part is the parameter passed to the target method. Please refer to [link to relevant documentation]. Figure 7 , Figure 7A schematic diagram of the driver service 700 of the SDK under test provided in this application embodiment includes:

[0097] 701. Process resident in memory, that is, setting the SDK under test as a process that resides in system memory. For example, setting a service as a resident process in system memory. For example, in the Android system, calling the timer (setRepeating) method of the alarm clock service (AlarmManager) to start the driver service of the SDK under test once every period of time can achieve the goal of setting the service encapsulated by the SDK under test as a resident service in system memory. Of course, there are other ways as well, and the specifics are not limited.

[0098] 702. The system reads performance data and collects real-time CPU, disk, network, I / O, and memory data when the target method is called to execute test data. Based on this data, a test analysis report for the SDK under test is generated. In other words, during the testing of the SDK under test, the software development kit testing device can collect real-time performance data of the system resources consumed during the testing process, such as CPU, disk, network, and memory data. This allows for analysis of the system resources consumed during the testing process to identify issues such as memory leaks and performance bottlenecks.

[0099] 703. Coverage Test Analysis: During the testing of the SDK under test, code coverage analysis can also be performed. SDKs programmed in different programming languages ​​require different methods for code coverage analysis. For example, if the SDK under test is programmed in C++, coverage can be collected using gcov technology in C++. If the SDK under test is programmed in Java, coverage can be collected using Java's jcov or jacoco technology. This allows for the collection of uncovered program code for different programming languages, thus supplementing test coverage.

[0100] 704. Encapsulate the SDK into a service, that is, encapsulate the SDK under test into a service and set it to reside in memory. For example, if the SDK under test is written in the Java programming language, the Spring Boot architecture can be used to encapsulate the SDK under test into a service. At the same time, the reflection mechanism can be used to load the target method according to the class and method name, and execute the test data through the target method to obtain the test results.

[0101] 705. Dynamic Loading and Hot Reloading of SDK. If the version of the SDK under test is updated, the update content corresponding to the update is determined; the SDK under test is updated according to the update content; when updating the SDK under test according to the update content, the SDK under test can be replaced according to the update content, and the replaced SDK can be loaded to update the SDK under test. Alternatively, when updating the SDK under test, a hot reloading method can be used to update the SDK under test according to the update content. The hot reloading method is related to the language characteristics of the programming language. For example, for Java services, the update of the SDK under test can be initiated by adding an agent in the JVM.

[0102] Understandably, version updates here refer to improvements to the current version of the SDK under test to address vulnerabilities or to updates that add new features. This involves obtaining the update details of the SDK under test and updating it accordingly. For example, with an SDK for image recognition technology, if the image recognition algorithm in that SDK is updated, the new algorithm can be obtained and the SDK updated accordingly. Alternatively, during the update, the image recognition algorithm in the SDK can be replaced with the updated algorithm, and then the SDK can be reloaded. Hot updates can also be used to update the image recognition algorithm without reloading the SDK.

[0103] 706. Dynamically calling methods in the SDK via parameters. That is, after obtaining the target method and the passed-in test data, the target method in the SDK can be dynamically called via test parameters. For example, in Java, reflection can be used to dynamically load and call the target method. This dynamic calling can mask the differences between SDKs of different programming languages. Therefore, as can be seen from the above description of driver service 700, in this application, the SDK under test can be encapsulated as a service and set as a resident process in system memory. Thus, when calling the SDK under test, it can be called dynamically. Furthermore, when the version of the SDK under test is updated, it can be updated via hot update. Additionally, performance data of the SDK during testing can be collected in real time to generate an SDK test analysis report.

[0104] 505. Match the response results with the expected values ​​in the test script to obtain the test results corresponding to the SDK under test.

[0105] In this embodiment, after the software development kit (SDK) testing device calls the target method to execute test data and obtains the response result, it can match the response result with the expected value in the test script to obtain the test result corresponding to the SDK under test. That is, the test script includes an expected value corresponding to the test data. After obtaining the response result through SDK testing, the response result can be matched with the expected value. If the match is successful, it means the test for the SDK under test has passed; if the match is unsuccessful, it means the test for the SDK under test has failed, and the tester needs to adjust the SDK under test.

[0106] In summary, it can be seen that in this embodiment of the application, when testing the SDK, the test cases and test scripts corresponding to the target application that has completed business testing are reused. At the same time, the methods of the SDK under test corresponding to the interfaces in the test cases are determined by the conversion method of interfaces and methods, and the test is executed by calling the SDK under test. Since it is not necessary to modify the test cases every time, the testing time of the SDK is reduced and the testing efficiency of the SDK is improved.

[0107] The embodiments of this application have been described above from the perspective of testing methods for software development kits. The embodiments of this application will now be described below from the perspective of testing devices for software development kits.

[0108] Please see Figure 8 This application provides a software development kit (SDK) testing device, which includes:

[0109] The first calling unit 801 is used to call the test cases and test scripts generated when performing business tests on the target application. The test cases include the test data corresponding to the target application and the business execution conditions.

[0110] Unit 802 is used to determine the calling interface for the test data in the business execution conditions;

[0111] The adaptation unit 803 is used to adapt the calling interface method to obtain the target method corresponding to the software development kit (SDK) under test.

[0112] The second invocation unit 804 is used to invoke the target method to execute the test data and obtain the response result;

[0113] Matching unit 805 is used to match the response result with the expected value in the test script to obtain the test result corresponding to the SDK under test.

[0114] In one possible design, the second calling unit 804 is also used for:

[0115] The framework of the programming language corresponding to the SDK under test is invoked to encapsulate the SDK under test into an SDK service;

[0116] The SDK service is identified as the target process, which is a resident process in the system memory.

[0117] The second invocation unit calls the target method to execute the test data, and the response results include:

[0118] The target process loads and calls the target method to execute test data and obtain response results.

[0119] In one possible design, the determining unit 802 is also used for:

[0120] If the version of the SDK under test is updated, then determine the update content corresponding to the version update of the SDK under test;

[0121] Update the SDK to be tested according to the update content corresponding to the version update of the SDK to be tested.

[0122] In one possible design, the determining unit 802 updates the SDK under test according to the update content corresponding to the version update of the SDK under test, including:

[0123] Replace the SDK under test with the version update corresponding to the update content;

[0124] Load the replaced SDK to be tested in order to update the SDK under test;

[0125] or,

[0126] For each version update of the SDK under test, the SDK under test is updated using a hot update method.

[0127] In one possible design, the software development kit testing apparatus also includes:

[0128] Analysis unit 806, analysis unit 806 is used for:

[0129] When the target method is called to execute test data, CPU data, disk data, network data, input / output system data, and memory data are collected in real time.

[0130] A test analysis report is generated based on data from the central processing unit, disk, network, input / output system, and memory.

[0131] In one possible design, the adapter unit 803 is specifically used for:

[0132] If the address writing rules of the called interface conform to the preset rules, then the target method is determined according to the address writing rules of the called interface;

[0133] If the address writing rules of the called interface do not conform to the preset rules, the target method is determined according to the called interface and the preset interface method mapping table.

[0134] In one possible design, the first calling unit 801 is also used for:

[0135] Obtain the configuration information for the SDK under test, including the language version of the SDK under test, the service address of the SDK under test, and the address of the preset interface method mapping table;

[0136] The SDK to be tested is invoked based on the language version of the SDK service to be tested and the service address of the SDK to be tested. The SDK to be tested is the SDK corresponding to any one of N programming languages, where N is an integer greater than or equal to 1.

[0137] Retrieve the preset interface method mapping table based on the address of the preset interface method mapping table.

[0138] In summary, it can be seen that in this embodiment of the application, when testing the SDK, the test cases and test scripts corresponding to the target application that has completed business testing are reused. At the same time, the methods of the SDK under test corresponding to the interfaces in the test cases are determined by the conversion method of interfaces and methods, and the test is executed by calling the SDK under test. Since it is not necessary to modify the test cases every time, the testing time of the SDK is reduced and the testing efficiency of the SDK is improved.

[0139] This application also provides another software development kit testing device, such as... Figure 9 As shown, for ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of this application. This software development kit (SDK) testing device can be any terminal device, including mobile phones, tablets, PDAs (Personal Digital Assistants), POS (Point of Sales), in-vehicle computers, etc. Taking a mobile phone as an example:

[0140] Figure 9 This diagram illustrates a partial structural design of a mobile phone related to the software development kit testing apparatus provided in this embodiment. (Reference) Figure 9 The mobile phone includes components such as a radio frequency (RF) circuit 910, a memory 920, an input unit 930, a display unit 940, a sensor 950, an audio circuit 960, a wireless fidelity (WiFi) module 970, a processor 980, and a power supply 990. Those skilled in the art will understand that... Figure 9 The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0141] The following is combined with Figure 9 A detailed introduction to each component of a mobile phone:

[0142] The RF circuit 910 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with the processor 980; additionally, it transmits uplink data to the base station. Typically, the RF circuit 910 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, etc. Furthermore, the RF circuit 910 can also communicate wirelessly with networks and other devices. The aforementioned wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, and Short Messaging Service (SMS).

[0143] The memory 920 can be used to store software programs and modules. The processor 980 executes various functions and data processing of the mobile phone by running the software programs and modules stored in the memory 920. The memory 920 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 920 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0144] The input unit 930 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the mobile phone. Specifically, the input unit 930 may include a touch panel 931 and other input devices 932. The touch panel 931, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 931), and drive the corresponding connected devices according to a pre-set program. Optionally, the touch panel 931 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 980, and can also receive and execute commands sent by the processor 980. In addition, the touch panel 931 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 931, the input unit 930 may also include other input devices 932. Specifically, other input devices 932 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0145] The display unit 940 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile phone. The display unit 940 may include a display panel 941, which may optionally be configured as a Liquid Crystal Display (LCD), Organic Light-Emitting Diode (OLED), or similar display. Further, a touch panel 931 may cover the display panel 941. When the touch panel 931 detects a touch operation on or near it, it transmits the information to the processor 980 to determine the type of touch event. Subsequently, the processor 980 provides corresponding visual output on the display panel 941 based on the type of touch event. Although in Figure 9 In this embodiment, the touch panel 931 and the display panel 941 are two separate components to realize the input and output functions of the mobile phone. However, in some embodiments, the touch panel 931 and the display panel 941 can be integrated to realize the input and output functions of the mobile phone.

[0146] The mobile phone may also include at least one sensor 950, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 941 according to the ambient light level, and the proximity sensor can turn off the display panel 941 and / or backlight when the phone is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity, which can be used for applications that recognize the phone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometer, taps), etc. Other sensors that may be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0147] Audio circuit 960, speaker 961, and microphone 962 provide an audio interface between the user and the mobile phone. Audio circuit 960 converts received audio data into electrical signals and transmits them to speaker 961, where speaker 961 converts them into sound signals for output. On the other hand, microphone 962 converts collected sound signals into electrical signals, which are received by audio circuit 960, converted into audio data, and then processed by processor 980 before being transmitted via RF circuit 910 to, for example, another mobile phone, or the audio data can be output to memory 920 for further processing.

[0148] WiFi is a short-range wireless transmission technology. Mobile phones, through the WiFi module 970, can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 9 The WiFi module 970 is shown, but it is understood that it is not an essential component of a mobile phone and can be omitted as needed without changing the essence of the invention.

[0149] The processor 980 is the control center of the mobile phone, connecting various parts of the phone through various interfaces and lines. It executes software programs and / or modules stored in the memory 920, and calls data stored in the memory 920 to perform various functions and process data, thereby providing overall monitoring of the phone. Optionally, the processor 980 may include one or more processing units; preferably, the processor 980 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 980.

[0150] The mobile phone also includes a power supply 990 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 980 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0151] Although not shown, mobile phones may also include a camera, Bluetooth module, etc., which will not be described in detail here.

[0152] In this embodiment of the application, the processor 980 included in the terminal can perform the operations performed by the software development kit testing device described above.

[0153] This application also provides a computer-readable storage medium storing a computer program thereon. When executed by a computer, the computer program implements the method flow related to the software development kit (SDK) testing apparatus in any of the above method embodiments. Correspondingly, the computer can be the aforementioned SSD testing apparatus.

[0154] This application also provides a computer program or a computer program product including a computer program, which, when executed on a computer, causes the computer to implement the method flow related to the software development kit (SDK) testing device in any of the above method embodiments. Correspondingly, the computer can be the aforementioned SSD testing device.

[0155] In the above Figures 3 to 7 In any of the embodiments corresponding to any of the accompanying drawings, the implementation may be entirely or partially carried out by software, hardware, firmware, or any combination thereof. When implemented in software, it may be implemented entirely or partially in the form of a computer program product.

[0156] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0157] It should be understood that the processor mentioned in this application can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0158] It should also be understood that the number of processors in this application can be one or more, and can be adjusted according to the actual application scenario. This is merely an illustrative example and is not intended to limit the application. The number of memory in the embodiments of this application can be one or more, and can be adjusted according to the actual application scenario. This is merely an illustrative example and is not intended to limit the application.

[0159] It should also be noted that when the software development kit testing device includes a processor (or processing unit) and a memory, the processor in this application may be integrated with the memory, or the processor and the memory may be connected through an interface. The specific configuration can be adjusted according to the actual application scenario and is not limited.

[0160] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0161] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0162] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0163] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0164] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or other device, etc.) to execute this application. Figures 3 to 7 All or part of the steps of the method described in any of the accompanying drawings.

[0165] It should be understood that the storage medium or memory mentioned in this application may include volatile memory or non-volatile memory, or both. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0166] It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memories.

[0167] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A testing method for a software development kit, characterized in that, include: The test cases and test scripts generated during the business testing of the target application are invoked. The test cases and test scripts are reused test cases and test scripts generated during the business testing of the target application. The test cases include the test data corresponding to the target application and the business execution conditions. Determine the calling interface for the test data in the business execution conditions; The interface call is adapted to obtain the target method corresponding to the SDK under test, where SDK is a software development kit; Based on the method name of the target method, the target method is dynamically invoked to execute the test data and obtain the response result; The response result is matched with the expected value in the test script to obtain the test result corresponding to the SDK under test; Before adapting the interface method to the called interface, the method further includes: Obtain the configuration information for the SDK under test, including the language version of the SDK under test, the service address of the SDK under test, and the address of the preset interface method mapping table; The SDK under test is invoked according to its language version and service address. The SDK under test is an SDK corresponding to any one of N programming languages, where N is an integer greater than or equal to 1. Obtain the preset interface method mapping table based on the address of the preset interface method mapping table.

2. The test method according to claim 1, characterized in that, The method further includes: The framework of the programming language corresponding to the SDK under test is invoked to encapsulate the SDK under test into an SDK service; The SDK service is identified as the target process, which is a resident process in system memory. The execution of the test data by calling the target method and obtaining the response results include: The target process loads and calls the target method to execute the test data and obtain the response result.

3. The test method according to claim 1, characterized in that, The method further includes: If the version of the SDK under test is updated, then determine the update content corresponding to the version update of the SDK under test; Update the SDK under test according to the update content corresponding to the version update of the SDK under test.

4. The test method according to claim 3, characterized in that, The step of updating the SDK under test according to the update content corresponding to the version update of the SDK under test includes: Replace the SDK under test according to the update content corresponding to the version update of the SDK under test; Load the replaced SDK under test to update the SDK under test; or, For the update content corresponding to the version update of the SDK under test, the SDK under test shall be updated in the manner of hot update.

5. The test method according to claim 1, characterized in that, The method further includes: When the target method is invoked to execute the test data, CPU data, disk data, network data, input / output system data, and memory data are collected in real time. A test analysis report for the SDK under test is generated based on the central processing unit data, the disk data, the network data, the input / output system data, and the memory data.

6. The test method according to any one of claims 1 to 5, characterized in that, The process of adapting the calling interface to obtain the target method corresponding to the software development kit (SDK) under test includes: If the address writing rules of the calling interface conform to the preset rules, then the target method is determined according to the address writing rules of the calling interface; If the address writing rules of the calling interface do not conform to the preset rules, the target method is determined according to the calling interface and the preset interface method mapping table.

7. A software development kit testing device, characterized in that, include: The first calling unit is used to call the test cases and test scripts generated when performing business tests on the target application. The test cases and test scripts are reused test cases and test scripts generated during the business testing of the target application. The test cases include the test data corresponding to the target application and the business execution conditions. The determining unit is used to determine the calling interface for the test data in the business execution conditions; An adaptation unit is used to adapt the calling interface to the interface method in order to obtain the target method corresponding to the SDK under test, wherein the SDK is a software development kit; The second invocation unit is used to dynamically invoke the target method to execute the test data according to the method name of the target method, and obtain the response result; A matching unit is used to match the response result with the expected value in the test script to obtain the test result corresponding to the SDK under test. The device is also used for: Obtain the configuration information for the SDK under test, including the language version of the SDK under test, the service address of the SDK under test, and the address of the preset interface method mapping table; The SDK under test is invoked according to its language version and service address. The SDK under test is an SDK corresponding to any one of N programming languages, where N is an integer greater than or equal to 1. Obtain the preset interface method mapping table based on the address of the preset interface method mapping table.

8. The apparatus according to claim 7, characterized in that, The second calling unit is also used for: The framework of the programming language corresponding to the SDK under test is invoked to encapsulate the SDK under test into an SDK service; The SDK service is identified as the target process, which is a resident process in system memory. The execution of the test data by calling the target method and obtaining the response results include: The target process loads and calls the target method to execute the test data and obtain the response result.

9. The apparatus according to claim 7, characterized in that, The determining unit is further configured to: If the version of the SDK under test is updated, then determine the update content corresponding to the version update of the SDK under test; Update the SDK under test according to the update content corresponding to the version update of the SDK under test.

10. The apparatus according to claim 9, characterized in that, The determining unit updates the SDK under test according to the update content corresponding to the version update of the SDK under test, including: Replace the SDK under test according to the update content corresponding to the version update of the SDK under test; Load the replaced SDK under test to update the SDK under test; or, For the update content corresponding to the version update of the SDK under test, the SDK under test shall be updated in the manner of hot update.

11. A computer device, characterized in that, include: Memory, processor, and bus system; The memory is used to store programs, and the bus system is used to connect the memory and the processor so that the memory and the processor can communicate. The processor is used to execute the program in the memory, and the processor is used to execute the test method according to any one of claims 1 to 6 according to the instructions in the program code.

12. A computer storage medium, characterized in that, It includes instructions that, when executed on a computer, cause the computer to perform the test method according to any one of claims 1-6.

13. A computer program product, characterized in that, The computer program product includes instructions that, when executed on a computer device, cause the computer device to perform the test method as described in any one of claims 1 to 6.

Images