Software development kit test method, storage medium, and electronic device

Abstract

The application discloses a software development kit test method, a storage medium and an electronic device, relates to the technical field of smart home / smart home, and the software development kit test method comprises the following steps: analyzing a plurality of test items of a software development kit to be tested from a test request; obtaining a target test macro in a test framework according to a dependency relationship between each test item and each test item except the test item, and a test requirement of each test item; generating a test program of each test item based on a test function in the target test macro and the dependency relationship and the test requirement; merging the test programs of the plurality of test items, obtaining a test case of the software development kit to be tested, and testing the software development kit to be tested based on the test case. The application realizes comprehensive and automatic testing of the SDK, can improve the testing efficiency and standardization, and effectively improves the testing accuracy.

Description

Technical Field

[0001] This application relates to the field of smart home / intelligent home technology, and in particular to a software development kit testing method, storage medium, and electronic device. Background Technology

[0002] A Software Development Kit (SDK) generally refers to a collection of development tools used by software engineers to create application software for specific software packages, frameworks, hardware platforms, operating systems, etc. With increasing levels of intelligence, more and more external developers are integrating SDKs into smart devices and using the APIs (Application Programming Interfaces) provided by the SDKs to encapsulate upper-layer applications, enabling rapid development of applications based on the IoT (Internet of Things) platform. To ensure the stability of the SDK, it needs to be tested before deployment.

[0003] In existing SDK testing methods, testers often set up environments and write code for different functional tests, interface tests, and unit tests one by one, and then manually observe the test results to perform functional interface tests, integration tests, or unit tests on the SDK. This method has low testing efficiency and the test results are greatly affected by human interference, resulting in poor test accuracy. Summary of the Invention

[0004] This application provides a software development kit (SDK) testing method, storage medium, and electronic device to address the shortcomings of manual SSD testing in the prior art, which suffers from low testing efficiency and poor test result accuracy, thereby improving testing efficiency and test result accuracy.

[0005] This application provides a software development kit testing method, including:

[0006] Obtain a test request and parse out multiple test items from the test request for the Software Development Kit (SDK) to be tested;

[0007] For each test item, the target test macro in the test framework is obtained based on the dependency relationship between each test item and other test items, as well as the test requirements of each test item.

[0008] Based on the test functions in the target test macro, as well as the dependencies and test requirements, a test program for each test item is generated.

[0009] The test programs of the multiple test items are merged to obtain the test cases of the SDK to be tested, and the SDK to be tested is tested based on the test cases.

[0010] According to the software development kit testing method provided in this application, the step of generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes:

[0011] Based on the test functions in the target test macro, as well as the dependencies and the first test requirement in the test requirements, an initial test program is generated for each test item;

[0012] Based on the second test requirement in the test requirements, determine the assertion position and assertion type corresponding to each test item;

[0013] Based on the assertion location, an assertion corresponding to the assertion type is added to the initial test program, and a test program for each test item is generated based on the addition result.

[0014] According to a software development kit (SDK) testing method provided in this application, the step of testing the SDK under test based on the test cases includes:

[0015] Execute the assertions at each assertion position in the test program for each test item in the test case;

[0016] If, based on the assertion execution result, it is determined that the actual test output of the SDK under test at any assertion position corresponding to any test item is inconsistent with the expected test output, a prompt message is generated and the assertion execution result is output; the prompt message is used to indicate that the SDK under test failed the test under any test item.

[0017] According to a software development kit (SDK) testing method provided in this application, the step of testing the SDK under test based on the test cases includes:

[0018] For each test item, perform the following steps:

[0019] Based on the first target test function in the test program of the current test project in the test case, the test program of the current test project is initialized.

[0020] The current test item is tested based on the initialized test program;

[0021] Once it is determined that the current test project has been completed, the test space and test thread occupied by the current test project are released based on the second target test function in the test program of the current test project.

[0022] According to a software development kit (SDK) testing method provided in this application, the step of testing the SDK under test based on the test cases includes:

[0023] Based on the test requirements of each test item, and if it is determined that there is a dependency between the test results of the SDK under test and the target data, the target data is simulated and generated; the target data is the data output by the target device that the device to which the SDK under test belongs depends.

[0024] The SDK to be tested is tested based on the test cases and simulated target data.

[0025] According to the software development kit testing method provided in this application, the step of generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes:

[0026] For each test item, perform the following steps:

[0027] If the current test project is determined to be a multi-parameter test based on the test requirements of the current test project, then the third target test function is selected from the test functions in the target test macro according to the parameter type of the multi-parameter test corresponding to the current test project.

[0028] Based on the third target test function, the multiple parameters are divided into the same test group;

[0029] Based on the test group and the dependencies, a test program for the current test project is generated, and the test program is a test program with multiple parameters.

[0030] According to the software development kit testing method provided in this application, the step of generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes:

[0031] If, based on the dependency relationship, it is determined that each test item depends on a target test item other than each test item, a fourth target test function is selected from the test functions in the target test macro;

[0032] Based on the fourth target test function, the basic test program for each test item is derived from the test class to which the test program for the target test item belongs.

[0033] Based on the aforementioned testing requirements, the basic testing program is updated.

[0034] Based on the update results, obtain the test program for each test item.

[0035] According to the software development kit (SDK) testing method provided in this application, the step of merging the test programs of the multiple test items to obtain test cases for the SDK to be tested includes:

[0036] The test programs of the multiple test projects are added to the test template of the software development kit to obtain the test cases; the test template of the software development kit includes a main function shared by the test programs of the multiple test projects.

[0037] This application also provides a software development kit testing system, including:

[0038] The parsing module is used to obtain test requests and parse multiple test items of the software development kit (SDK) to be tested from the test requests;

[0039] The acquisition module is used to acquire the target test macro in the test framework for each test item, based on the dependency relationship between each test item and other test items, as well as the test requirements of each test item.

[0040] The generation module is used to generate a test program for each test item based on the test functions in the target test macro, as well as the dependencies and the test requirements;

[0041] The testing module is used to merge the test programs of the multiple test items, obtain the test cases of the SDK to be tested, and test the SDK to be tested based on the test cases.

[0042] This application also provides an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the software development kit testing method as described above through the computer program.

[0043] This application also provides a computer-readable storage medium comprising a stored program, wherein the program, when executed, implements a software development kit testing method as described above.

[0044] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the software development kit testing method described above.

[0045] The software development kit (SDK) testing method, storage medium, and electronic device provided in this application automatically generate test programs for each test item in the SSD based on the dependencies and testing requirements of each test item. This is achieved by retrieving the corresponding target test macros from the testing framework, calling the test functions within these macros, and merging the test programs for multiple test items. This process enables automated testing of the SSD. Throughout the testing process, relying on the testing framework, test code is automatically and conveniently generated online based on the testing requirements and dependencies of each test item. This comprehensive automated testing of the SSD not only improves testing efficiency and standardization but also significantly enhances testing accuracy. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a schematic diagram of the hardware environment for a software development kit testing method according to an embodiment of this application;

[0049] Figure 2 This is one of the flowcharts illustrating the testing method for the software development kit provided in this application;

[0050] Figure 3 This is the second flowchart illustrating the testing method for the software development kit provided in this application;

[0051] Figure 4 This is a schematic diagram of the structure of the software development kit testing system provided in this application;

[0052] Figure 5 This is a schematic diagram of the electronic device provided in this application. Detailed Implementation

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

[0054] It should be noted that the terms "first," "second," etc., used in 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 of this application described herein can be implemented in orders other than those 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 apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0055] According to one aspect of the embodiments of this application, a software development kit (SDK) testing method is provided. This SSD testing method is widely applicable to whole-house intelligent digital control application scenarios such as smart homes, smart home ecosystems, and intelligence house ecosystems. Optionally, in this embodiment, the above-mentioned SSD testing method can be applied to applications such as... Figure 1 The hardware environment shown consists of terminal device 102 and server 104. For example... Figure 1 As shown, server 104 is connected to terminal device 102 via a network and can be used to provide services (such as application services) to the terminal or clients installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data processing services for server 104.

[0056] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity), Bluetooth. The terminal device 102 may not be limited to PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projector, smart TV, smart clothes rack, smart curtains, smart audio-visual equipment, smart socket, smart speaker, smart speaker box, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart robot vacuum cleaner, smart window cleaning robot, smart mopping robot, smart air purifier, smart steam oven, smart microwave oven, smart water heater, smart air purifier, smart water dispenser, smart door lock, etc.

[0057] The following is combined Figure 2-3 The testing method for the software development kit in this application is described in detail. For example... Figure 2 The diagram shown is one of the flowcharts illustrating the testing method for the software development kit provided in this application. The specific steps include:

[0058] Step 201: Obtain the test request and parse out multiple test items of the Software Development Kit (SDK) to be tested from the test request;

[0059] The test request is used to request testing of the Software Development Kit (SDK). It can be entered by the user on the front-end page or sent by a third-party device; this embodiment does not specifically limit this. The test request includes multiple test items for the SDK to be tested, and the specific number of test items can be set according to the actual testing scenario requirements.

[0060] The software development kit to be tested is the SDK that needs to be tested. It can be an SDK built into various smart devices, such as SDKs built into home appliances and network devices.

[0061] The SDK's different test items include various functional tests, unit tests, and interface tests.

[0062] Optionally, a listener can be set to listen for test requests in real time; when a test request is received, it can be parsed to obtain multiple test items of the software development kit to be tested.

[0063] Step 202: For each test item, obtain the target test macro in the test framework based on the dependency relationship between each test item and other test items, as well as the test requirements of each test item.

[0064] The testing framework includes various pre-configured test macros. These frameworks can be pre-configured within the SDK testing project for testing the SDK, pre-built based on testing requirements, or open-source frameworks such as the Googletest framework. The Googletest framework is an open-source testing framework developed by the Google testing technology team.

[0065] The following description uses the Googletest testing framework as an example to illustrate the software development kit testing method in this embodiment.

[0066] The specific steps for configuring the Googletest testing framework in an SDK testing project include:

[0067] To use the Googletest testing framework in an SDK test project, add the Googletest testing framework source code to the SDK test project and write a CMakeLists.txt file at the top level of the SDK test project. The CMakeLists.txt file is a project file used to describe relevant information such as the project source code. The test code of the Software Development Kit is independent of the SDK functional code settings and has its own independent CMakeLists.txt file.

[0068] Then, add the subpath corresponding to the Googletest testing framework to the CMakeLists.txt file. This ensures that after executing the cmake and make commands in the SDK test project, the Googletest project will be compiled, generating the corresponding Googletest library files, including but not limited to: libgtest.a (providing unit testing functionality), libgtest_main.a (providing the main entry point for unit testing), libgmock.a (providing database interaction simulation testing functionality), and libgmock_main.a (providing network connection simulation testing functionality). Simultaneously, the path to the Googletest header files needs to be added to the CMakeLists file of the SDK test project, and the header files, including but not limited to gte, need to be added to the test source files within the written CMakeLists file. The CMakeLists file contains header files such as st / gtest.h and gtest / gmock.h. Based on the testing requirements, various namespace functions are declared in the prepared CMakeLists file. These include, but are not limited to, the following Googletest-related namespaces: ::Testing::Test, ::Testing::TestEventListener, ::Testing::UnitTest, and ::Testing::TestWithParam. This allows for the configuration of the Googletest testing framework in the SDK test project. Furthermore, the CMakeLists file links the test target files of the software development kit (SDK) to be tested to the Googletest runtime library, enabling automated testing of the SSDK based on the Googletest testing framework.

[0069] The Googletest testing framework can include a unit testing framework (also known as the gtest framework) and a mock testing framework (also known as the gmock framework). The gtest framework contains various functional unit test macros for implementing unit tests of different functions, while the gmock framework contains various functional mock test macros for implementing mock tests of different functions.

[0070] Among these, the tests in multiple test projects may be dependent on each other or independent of each other, and the test requirements of each test project may be the same or different.

[0071] Optionally, after obtaining multiple test items from the software development kit to be tested, the following operations can be performed on each test item:

[0072] Obtain the dependencies between the current test project and each of the multiple test projects other than the current test project, and obtain the test requirements of the current test project.

[0073] Then, based on the dependencies, retrieve the test macros that represent the inheritance relationship from the unit test macros and mock test macros in the Googletest test framework; and based on the test requirements, retrieve the test macros that represent the corresponding test function requirements from the unit test macros and mock test macros in the Googletest test framework.

[0074] The test macros used to represent inheritance relationships and the corresponding test function requirements are used as target test macros to realize the development of test programs for each test item.

[0075] It should be noted that the number of target test macros can be set according to actual needs.

[0076] Step 203: Based on the test functions in the target test macro, as well as the dependencies and test requirements, generate the test program for each test item;

[0077] The target test macro contains multiple test functions; each test function has a different test function.

[0078] Optionally, once the target test macro corresponding to each test item is obtained, the target test macro can be called to develop the test program for each test item based on the test functions in the target test macro, as well as the dependencies and test requirements.

[0079] In this embodiment, regarding the testing process, the development of test programs for each test item is automatically realized by calling test macros in the testing framework, effectively reducing the large amount of manpower and resources required for manual coding.

[0080] Step 204: Merge the test programs of the multiple test projects to obtain test cases for the SDK to be tested, and test the SDK to be tested based on the test cases.

[0081] Optionally, since the test program for each test project is implemented by sequentially calling the target test macro in the test framework, once the test program for each test project is obtained, the test programs for multiple test projects can be merged by referencing the test program "*.cc" file to obtain the test cases for the SDK to be tested.

[0082] During testing, the test programs for each test item are executed sequentially according to the generation order of the test programs for each test item. This allows for comprehensive testing of the SDK under test across multiple test items. This avoids the problems of operational complexity, poor coding standards, low testing efficiency, and poor testing accuracy associated with manually writing complex test scripts for each test item. Furthermore, relying on the testing framework to automatically generate test cases not only improves the efficiency and standardization of test case generation but also facilitates subsequent modifications and code reuse. It also automatically generates test results, effectively solving the problems of low testing efficiency and inaccurate test results caused by manual observation and comparison methods in existing technologies.

[0083] The software development kit (SDK) testing method in this embodiment obtains the corresponding target test macros from the testing framework based on the dependencies and testing requirements of each test item in the SSD under test, and calls the test functions in the target test macros. It automatically generates test programs for each test item based on its dependencies and configuration requirements, and merges the test programs of multiple test items to achieve automated testing of the SSD. Throughout the testing process, relying on the testing framework, test code is automatically and conveniently generated online based on the testing requirements and dependencies of each test item for comprehensive automated testing of the SSD. This not only improves testing efficiency and standardization but also effectively enhances testing accuracy.

[0084] In some embodiments, generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes:

[0085] Based on the test functions in the target test macro, as well as the dependencies and the first test requirement in the test requirements, an initial test program is generated for each test item;

[0086] Based on the second test requirement in the test requirements, determine the assertion position and assertion type corresponding to each test item;

[0087] Based on the assertion location, an assertion corresponding to the assertion type is added to the initial test program, and a test program for each test item is generated based on the addition result.

[0088] The first test requirement includes various functional test requirements for each test item; the second test requirement includes assertion test requirements for each test item. Based on the assertion test requirements, the assertion location and assertion type required for the test item can be determined. The assertion type includes, but is not limited to, a rich assertion mechanism such as Boolean, string, and floating-point types, which can be determined based on the test output type.

[0089] Optionally, step 203, which generates the test program for each test item, specifically includes:

[0090] The target test macro is invoked to develop the initial test program for each test item based on the test functions in the target test macro, as well as the dependencies and the first test requirements.

[0091] Then, the second test requirement is parsed to obtain the assertion test requirement; based on the assertion test requirement, the assertion position and assertion type corresponding to each test item are determined; based on the assertion position, the position to add the assertion is determined in the initial test program, and the assertion of the corresponding assertion type is added at that position to generate the test program for each test item.

[0092] For example, the TEST test macro in the Googletest testing framework, used for unit testing, can be called. Based on the functional test functions in the TEST test macro, initial test programs can be developed for each test item. Assertions can be added to the initial test program based on the assertion functions in the TEST test macro, such as the EXPECT assertion function which exits the current function directly when an assertion fails, and the ASSERT assertion function which issues a prompt and continues execution when an assertion fails. This allows for the automatic and accurate judgment of the test output and expected test results of the software development kit under test for each test item. The judgment results are described, and sufficient instructions are provided to allow users to obtain test results more conveniently and intuitively. This effectively solves the problem of poor accuracy caused by manually observing test results, thus significantly improving the automation level of testing.

[0093] In some embodiments, testing the SDK under test based on the test cases includes: executing assertions at each assertion position in the test program of each test item in the test cases; if, based on the assertion execution result, it is determined that the actual test output of the SDK under test at any assertion position corresponding to any test item is inconsistent with the expected test output, generating a prompt message and outputting the assertion execution result; the prompt message is used to indicate that the SDK under test failed the test under any test item.

[0094] Optionally, since each test item's test program contains at least one assertion, during testing, the assertions at each assertion location in the test program of each test item in the test case can be executed to compare the actual test output of the SDK under test at that assertion location with the expected test output.

[0095] If the actual test output of the SDK under test at any assertion location in any test project is inconsistent with the expected test output, a prompt message is generated to indicate that the test of the SDK under test at that assertion location in that test project has failed, and the assertion execution result is output so as to promptly prompt the user in the event of test anomalies and provide the user with rich test information, so that the user can make timely decisions and handle abnormal tests based on the rich test information.

[0096] For example, when asserting a test item, the EXPEXT assertion function can be used in the corresponding unit test macro TEST* to set the assertion, so as to compare and judge the expected test output and the actual test output, thereby realizing automated testing of the software development kit to be tested at any assertion position.

[0097] The specific test code is: EXPEXT_EQ(number1,number2)<<”number1not equalnumber2”; where the string “number1 not equal number2” is the description of the assertion exception. If the test results in number1=1 and number2=1, then the test judgment is EXPEXT_EQ(1,2)<<”1 not equal 2”; when the test program is executed, the terminal will display the test failure and print the string “1 not equal 2”.

[0098] In some embodiments, testing the SDK to be tested based on the test cases includes:

[0099] For each test item, perform the following steps:

[0100] Based on the first target test function in the test program of the current test project in the test case, the test program of the current test project is initialized.

[0101] The current test item is tested based on the initialized test program;

[0102] Once it is determined that the current test project has been completed, the test space and test thread occupied by the current test project are released based on the second target test function in the test program of the current test project.

[0103] The first target test function is a function with initialization capabilities, such as the SetUp() function in the unit test macro TEST_F; the second target test function is a function with release capabilities, such as the TearDown() function in TEST_F.

[0104] Optionally, when reusable configuration or initialization code is required, the TEST_F macro can be used to implement resource initialization testing and test environment restoration. Since the TEST macro simply implements automatic registration of test cases in the main test function, they will be automatically called when the test program executes, but the test program itself is still not organized. When encountering initialization functions, basic information class object configurations, etc., that need to be reused by subsequent functional functions, the event mechanism in the Googletest testing framework needs to be used. By overriding the `SetUp()` and `TearDown()` functions derived from the global variable `testing::Environment`, initialization operations across the entire test program can be achieved. The program will run the `SetUp()` function before performing any other operations, executing the initialization code written by the designers within it. The `TearDown()` function will be executed after all test suites have finished running, enabling operations such as releasing memory and threads, restoring the test environment, reducing the execution of other test programs, effectively improving test accuracy, and solving the problems of existing technologies where test code is manually written, lacks a specific framework constraint, requires multiple configurations of the test environment for different test functions, has complex code implementation, poor readability, and is prone to causing memory space to be not properly released, thus affecting subsequent tests.

[0105] In some embodiments, testing the SDK to be tested based on the test cases includes:

[0106] Based on the test requirements of each test item, and if it is determined that there is a dependency between the test results of the SDK under test and the target data, the target data is simulated and generated; the target data is the data output by the target device that the device to which the SDK under test belongs depends.

[0107] The SDK to be tested is tested based on the test cases and simulated target data.

[0108] The target device can be an external device of the device to which the SDK under test belongs, such as a network device or a database. The target data can be third-party data output by the network device or large file data in the database, etc. This embodiment does not specifically limit it.

[0109] Optionally, based on the testing requirements of each test item, it is determined whether the output of the test results of the SDK under test depends on the target data output by the target device on which the device to which the SDK belongs depends. When it is determined that the output of the test results of the SDK under test depends on the target data, the target data needs to be obtained from the target device in order to complete the test smoothly. However, the communication stability and transmission efficiency of the target device can have a significant impact on the test results. Therefore, in order to eliminate the influence of the target device on the test results, the simulation test macro in the simulation test framework gmok framework can be called to simulate and generate target data. Based on the test cases and the simulated target data, the SDK under test can be tested to realize the simulation generation function of test data. This solves the problem that when the underlying test function needs to obtain server data, the response data and latency are highly dependent on the network status, which can easily cause uncertainty and instability in the test results.

[0110] In some embodiments, generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes:

[0111] For each test item, perform the following steps:

[0112] If the current test project is determined to be a multi-parameter test based on the test requirements of the current test project, then the third target test function is selected from the test functions in the target test macro according to the parameter type of the multi-parameter test corresponding to the current test project.

[0113] Based on the third target test function, the multiple parameters are divided into the same test group;

[0114] Based on the test group and the dependencies, a test program for the current test project is generated, and the test program is a test program with multiple parameters.

[0115] Optionally, step 203, which generates the test program for each test item, further includes:

[0116] Based on the testing requirements of the current test project, determine whether the current test project is a multi-parameter test. Multi-parameter testing is used to characterize testing the same type of test using multiple different parameters.

[0117] Optionally, if it is determined whether the current test item is a multi-parameter test, a third target test function that can perform multi-parameter testing, such as the MultiParamTest function, can be selected in the target test macro TEST_P (parameterized test macro).

[0118] Based on the third objective test function, multiple parameters are divided into the same test group, that is, multiple parameters are used as different input parameters of the same test interface;

[0119] Based on the generated test groups and dependencies, multiple test programs with shared parameters are generated to enable the automatic execution of multiple automated tests for different input parameters without the need for manual setting of loop execution, thus effectively improving testing efficiency.

[0120] For example, when implementing positive or negative data determination, a positive / negative data determination function can be executed, specifically `bool Foo_Add(unsigned int a)`, and a multi-parameter test class can be defined, specifically `MultiParamTest:public TestWithParam`.<unsigned int> And write a parameter generator to group multiple parameters into the same test group. The specific code is as follows:

[0121] INSTANTIAET_TEST_CASE_P(testname,MultiParamTest,testing::Values(-1,0,1)).

[0122] The parameter generator can use functions including Range(begin, end, [step]), which generates data in the range begin to end with a step size step; Values(V1,…Vn), which generates enumerated values ​​from V1 to Vn; and ValuesIn(), which retrieves values ​​from C type data, STL (Standard Template Library) containers, or iterators.

[0123] It should be noted that, based on the testing requirements of the current test project, if the current test project is determined to be a multi-type test, that is, to perform the same configuration test on different types of data structures, the above method can also be used to take multiple types as parameters, call the type test macro TYPE_TEST to select the test function that can perform multi-type tests, and realize multiple automated tests of different types based on the selected test function.

[0124] In this embodiment, when testing multiple different types and parameters are involved, the test functions in the corresponding test macros can be directly called. Multiple automated tests with different types and parameters can be achieved with simple code. This effectively solves the problem that in the prior art, when manually writing code, there is no corresponding convenient mechanism to deal with the need to test functional interfaces that require multiple types of input and multiple parameters. Manually writing loop input based on the input parameters leads to cumbersome operation and is prone to errors, thus effectively improving testing efficiency.

[0125] In some embodiments, generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes:

[0126] If, based on the dependency relationship, it is determined that each test item depends on a target test item other than each test item, a fourth target test function is selected from the test functions in the target test macro;

[0127] Based on the fourth target test function, the basic test program for each test item is derived from the test class to which the test program for the target test item belongs.

[0128] Based on the aforementioned testing requirements, the basic testing program is updated.

[0129] Based on the update results, obtain the test program for each test item.

[0130] Optionally, step 203, which generates the test program for each test item, further includes:

[0131] For the current test project, if it is determined that the current test project depends on multiple target test projects other than the current test project based on the dependencies of the current test project, a fourth target test function that can be overridden can be selected in the test function of the target test macro Test, such as the testing::Test class. Based on the fourth target test function and the test requirements, the test program of the current test project can be derived from the test class to which the test program of the target test project belongs.

[0132] It should be noted that by inheriting the testing::Test class, event mechanisms at both the testsuite and testcase levels can be implemented.

[0133] For example, when executing the message addition function `Message_add()` and message retrieval function `Message_get()` in the message queue class, the `MessageQueue` class needs to be instantiated before the specific operations are performed, creating an empty `MessageQueue`. Then, the `Message_add()` and `Message_get()` operations can be performed in the unit test macro `TEST_F` according to the test requirements. Finally, the `MessageQueue` object is released in `TearDown()`. When creating a new test project with dependencies, the derived function `TestQueue:testing::test` can be overridden, inheriting from the relevant test class to derive a new test object. That is, if it is necessary to execute the `Message_get()` test after adding a message, a class `TestQueueGet` derived from the `TestQueue` class can be created. Then, in the `SetUp()` method of the new class, the `SetUp()` function of the base class can be called, and the `Message_add()` operation can be executed to add data, thus conveniently and quickly achieving the sharing of common code and improving testing efficiency.

[0134] In some embodiments, merging the test programs of the multiple test projects to obtain test cases for the SDK to be tested includes:

[0135] The test programs of the multiple test projects are added to the test template of the software development kit to obtain the test cases; the test template of the software development kit includes a main function shared by the test programs of the multiple test projects.

[0136] Optionally, the step of generating test cases for the software development kit to be tested in step 204 includes:

[0137] After generating test programs for multiple test projects, these test programs can be added to the software development kit (SDK) test template. This allows the test programs to be directly linked to the main function library `gtest_main` in the test framework. All test programs in the multiple test projects then implement the shared `main` function through the linked `gtest_main` library, enabling sequential execution of the test programs. This achieves comprehensive testing of the SSD and solves the problem of needing to write multiple `main()` programs for multiple test programs. Developers no longer need to manually register each test case to the `main` function; as long as the test target is specified, the test cases in the test program will be executed sequentially.

[0138] In summary, after generating the test programs for the test project, all test programs can be placed in a single integrated test program by simply using the test template included in the ".cc" file of the software development kit. Finally, simply executing this integrated test program will execute all test cases and generate all test results. This eliminates the need for developers to register each independent test program individually into the main function; one-click testing of the entire SDK project can be achieved through simple source code integration. This effectively solves the problem of cumbersome operations in existing technologies that require writing a main function for each test program and using script programming to continuously test multiple test programs, thus significantly improving testing efficiency.

[0139] like Figure 3 The diagram shown is a second flowchart of the software development kit testing method provided in this embodiment, which specifically includes the following steps:

[0140] Step 301: Add the Googletest testing framework to the SDK test project.

[0141] Step 302, generating the test program, specifically includes calling the resource initialization function in the TEST_F test macro, the multi-parameter test function in the TEST_P test macro, and the assertion functions EXPECT and ASSERT in the TEST test macro, to generate the corresponding test program for each test item.

[0142] Step 303: Create a comprehensive test file; specifically, merge the corresponding test programs of multiple test items to generate a comprehensive test file.

[0143] In summary, when implementing SDK testing, the testing framework is directly applied to develop the relevant test programs. On the one hand, the development of independent test cases based on the test macro *TEST* makes development more convenient. Each test case is written as an independent program block, and the SetUp() and TearDown() functions are provided, which improves the security of the test program and reduces the coupling between it and the SDK project. On the other hand, each independent test case does not need to be registered by the developer into the main function one by one. One-click testing of the entire SDK project can be achieved through simple source code integration. Furthermore, the application of various test macros and assertions can easily implement various interface tests and meet various needs in SDK interface testing.

[0144] The software development kit (SDK) testing system provided in this application is described below. The software development kit testing system described below can be referred to in correspondence with the software development kit testing method described above.

[0145] like Figure 4As shown, this embodiment provides a software development kit (SDK) testing system, which includes a parsing module 401, an acquisition module 402, a generation module 403, and a testing module 404, wherein:

[0146] The parsing module 401 is used to obtain a test request and parse out multiple test items of the software development kit (SDK) to be tested from the test request;

[0147] The acquisition module 402 is used to acquire the target test macro in the test framework for each test item, based on the dependency relationship between each test item and other test items, as well as the test requirements of each test item.

[0148] The generation module 403 is used to generate a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements;

[0149] The testing module 404 is used to merge the test programs of the multiple test items, obtain the test cases of the SDK to be tested, and test the SDK to be tested based on the test cases.

[0150] The software development kit (SDK) testing system in this embodiment obtains the corresponding target test macros from the testing framework based on the dependencies and testing requirements of each test item in the SSD under test. It then calls the test functions within these target test macros and automatically generates test programs for each test item according to their dependencies and configuration requirements. The system also merges the test programs from multiple test items to achieve automated testing of the SSD. Throughout the testing process, relying on the testing framework, test code is automatically and conveniently generated online based on the testing requirements and dependencies of each test item. This comprehensive automated testing of the SSD not only improves testing efficiency and standardization but also effectively enhances testing accuracy.

[0151] In some embodiments, the generation module 403 is specifically used for:

[0152] Based on the test functions in the target test macro, the dependencies, and the first test requirement in the test requirements, an initial test program for each test item is generated; based on the second test requirement in the test requirements, the assertion position and assertion type corresponding to each test item are determined; according to the assertion position, assertions corresponding to the assertion type are added to the initial test program, and the test program for each test item is generated based on the addition result.

[0153] In some embodiments, the test module 404 is specifically used for:

[0154] Execute the assertions at each assertion position in the test program of each test item in the test case; if, based on the assertion execution result, it is determined that the actual test output of the SDK under test at any assertion position corresponding to any test item is inconsistent with the expected test output, generate a prompt message and output the assertion execution result; the prompt message is used to indicate that the SDK under test has failed the test under any test item.

[0155] In some embodiments, the test module 404 is further configured to:

[0156] For each test item, perform the following operations: Initialize the test program of the current test item based on the first target test function in the test program of the current test item in the test case; Test the current test item based on the initialized test program; If the test of the current test item is completed, release the test space and test thread occupied by the current test item based on the second target test function in the test program of the current test item.

[0157] In some embodiments, the test module 404 is further configured to:

[0158] Based on the test requirements of each test item, and if it is determined that the test results of the SDK under test are dependent on the target data, the target data is simulated and generated. The target data is the data output by the target device that the device to which the SDK under test belongs depends. The SDK under test is tested based on the test cases and the simulated target data.

[0159] In some embodiments, the generation module 403 is further configured to:

[0160] For each test item, the following operations are performed: If the current test item is determined to be a multi-parameter test based on the test requirements of the current test item, a third target test function is selected from the test functions in the target test macro according to the parameter types of the multi-parameters corresponding to the current test item; based on the third target test function, the multi-parameters are divided into the same test group; according to the test group and the dependency relationship, a test program for the current test item is generated, and the test program is a test program shared by the multi-parameters.

[0161] In some embodiments, the generation module 403 is further configured to:

[0162] If, based on the dependency relationship, it is determined that each test item depends on a target test item other than each test item, a fourth target test function is selected from the test functions in the target test macro; based on the fourth target test function, a basic test program for each test item is derived from the test class to which the test program of the target test item belongs; based on the test requirements, the basic test program is updated; and based on the update result, the test program for each test item is obtained.

[0163] In some embodiments, the test module 404 is further configured to:

[0164] The test programs of the multiple test projects are added to the test template of the software development kit to obtain the test cases; the test template of the software development kit includes a main function shared by the test programs of the multiple test projects.

[0165] Figure 5 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 5 As shown, the electronic device may include a processor 501, a communications interface 502, a memory 503, and a communication bus 504, wherein the processor 501, communications interface 502, and memory 503 communicate with each other via the communication bus 504. The processor 501 can call logical instructions in the memory 503 to execute a software development kit (SDK) testing method. This method includes: obtaining a test request; parsing multiple test items of the SDK to be tested from the test request; for each test item, obtaining a target test macro in the test framework based on the dependencies between each test item and other test items, and the test requirements of each test item; generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements; merging the test programs of the multiple test items to obtain test cases for the SDK to be tested, and testing the SDK to be tested based on the test cases.

[0166] Furthermore, the logical instructions in the aforementioned memory 503 can be implemented as software functional units and, when sold or used as independent products, 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 a 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, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0167] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the software development kit (SDK) testing method provided by the above methods. The method includes: obtaining a test request; parsing multiple test items of the SDK to be tested from the test request; for each test item, obtaining a target test macro in the test framework based on the dependency relationship between each test item and other test items, and the test requirements of each test item; generating a test program for each test item based on the test functions in the target test macro, the dependency relationship, and the test requirements; merging the test programs of the multiple test items to obtain test cases for the SDK to be tested, and testing the SDK to be tested based on the test cases.

[0168] In another aspect, this application also provides a computer-readable storage medium, the computer-readable storage medium including a stored program, wherein the program executes the software development kit (SDK) testing method provided by the above methods when running, the method comprising: obtaining a test request; parsing multiple test items of the SDK to be tested from the test request; for each test item, obtaining a target test macro in a test framework according to the dependency relationship between each test item and other test items, and the test requirements of each test item; generating a test program for each test item based on the test functions in the target test macro, the dependency relationship and the test requirements; merging the test programs of the multiple test items to obtain test cases for the SDK to be tested, and testing the SDK to be tested based on the test cases.

[0169] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0170] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0171] Finally, it should be noted that the above 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 spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A software development kit testing method, characterized in that, include: Obtain a test request and parse out multiple test items from the test request for the Software Development Kit (SDK) to be tested; For each test item, the target test macro in the test framework is obtained based on the dependency relationship between each test item and other test items, as well as the test requirements of each test item. Based on the test functions in the target test macro, as well as the dependencies and test requirements, a test program for each test item is generated. The test programs of the multiple test items are merged to obtain the test cases of the SDK to be tested, and the SDK to be tested is tested based on the test cases; The testing of the SDK under test based on the test cases includes: Based on the test requirements of each test item, and if it is determined that there is a dependency between the test results of the SDK under test and the target data, the target data is simulated and generated; the target data is the data output by the target device that the device to which the SDK under test belongs depends. The SDK to be tested is tested based on the test cases and simulated target data. The process of generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes: For each test item, perform the following steps: If the current test project is determined to be a multi-parameter test based on the test requirements of the current test project, then the third target test function is selected from the test functions in the target test macro according to the parameter type of the multi-parameter test corresponding to the current test project. Based on the third target test function, the multiple parameters are divided into the same test group; Based on the test group and the dependencies, a test program for the current test project is generated, and the test program is a test program with multiple parameters shared. The step of merging the test programs for the multiple test items to obtain test cases for the SDK to be tested includes: The test programs of the multiple test projects are added to the test template of the software development kit to obtain the test cases; the test template of the software development kit includes a main function shared by the test programs of the multiple test projects.

2. The software development kit testing method according to claim 1, characterized in that, The process of generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes: Based on the test functions in the target test macro, as well as the dependencies and the first test requirement in the test requirements, an initial test program is generated for each test item; Based on the second test requirement in the test requirements, determine the assertion position and assertion type corresponding to each test item; Based on the assertion location, an assertion corresponding to the assertion type is added to the initial test program, and a test program for each test item is generated based on the addition result.

3. The software development kit testing method according to claim 2, characterized in that, The testing of the SDK under test based on the test cases includes: Execute the assertions at each assertion position in the test program for each test item in the test case; If, based on the assertion execution result, it is determined that the actual test output of the SDK under test at any assertion position corresponding to any test item is inconsistent with the expected test output, a prompt message is generated and the assertion execution result is output; the prompt message is used to indicate that the SDK under test failed the test under any test item.

4. The software development kit testing method according to any one of claims 1-3, characterized in that, The testing of the SDK under test based on the test cases includes: For each test item, perform the following steps: Based on the first target test function in the test program of the current test project in the test case, the test program of the current test project is initialized. The current test item is tested based on the initialized test program; Once it is determined that the current test project has been completed, the test space and test thread occupied by the current test project are released based on the second target test function in the test program of the current test project.

5. The software development kit testing method according to any one of claims 1-3, characterized in that, The process of generating a test program for each test item based on the test functions in the target test macro, the dependencies, and the test requirements includes: If, based on the dependency relationship, it is determined that each test item depends on a target test item other than each test item, a fourth target test function is selected from the test functions in the target test macro; Based on the fourth target test function, the basic test program for each test item is derived from the test class to which the test program for the target test item belongs. Based on the aforementioned testing requirements, the basic testing program is updated. Based on the update results, obtain the test program for each test item.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of any one of claims 1 to 5.

7. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method of any one of claims 1 to 5 through the computer program.

Images