SDK (Software Development Kit) white box test method

Abstract

The invention provides an SDK white-box testing method, which comprises the following steps that: a shell project and a target SDK are created, the shell project comprises a running environment of an operating system, and the target SDK is a to-be-tested object; and providing the to-be-tested case code writing template for the user to obtain a target test case which is written by the user based on codes of the to-be-tested case code writing template and is used for carrying out white-box testing on the target SDK. And importing the target test case into the shell project to obtain a test APP suitable for operation of an operating system. And running the test APP in the operating system to perform white-box test on the target SDK. According to the method and the device, the white-box test aiming at the SDK can be realized under the condition of not depending on professional code programming capability of a user.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an SDK white box testing method. Background Art

[0002] In the process of developing Android APP, specific functions can be implemented by introducing a software development kit (SDK), and the SDK also needs to be tested.

[0003] Existing SDK testing methods can be divided into white-box testing and black-box testing. White-box testing is based on the tester's in-depth understanding of the internal structure and code logic of the software. It verifies whether the functions are executed as expected by writing test code, which requires the tester to have professional code programming capabilities. Black-box testing designs test cases based on the software specifications, user needs, and functional requirements to verify whether the output meets expectations by inputting different data. Compared with white-box testing, black-box testing does not require testers to write code, so testers are not required to understand the internal structure and code logic of the software.

[0004] The testing effect of white box testing is better than that of black box testing, but white box testing has a certain threshold. How to implement white box testing for SDK without relying on the user's professional code programming ability is the technical problem to be solved by this application. Summary of the invention

[0005] The purpose of this application is to provide an SDK white box testing method that can implement white box testing for the SDK without relying on the user's professional code programming ability.

[0006] In order to achieve the above purpose, the embodiment of the present application is implemented as follows:

[0007] In a first aspect, a SDK white box testing method is provided, comprising:

[0008] Create a shell project and a target SDK, wherein the shell project includes an operating environment of an operating system, and the target SDK is an object to be tested;

[0009] Providing a test case code writing template to the user, so as to obtain a target test case written by the user based on the test case code writing template for white-box testing of the target SDK;

[0010] Importing the target test case into the shell project to obtain a test APP suitable for running the operating system;

[0011] The test APP is run in the operating system to perform white box testing on the target SDK.

[0012] In an embodiment of the present application, when it is necessary to perform white-box testing on the target SDK, a shell project can be created and a test case code writing template can be provided to the user. Correspondingly, the user can write a target test case for white-box testing of the target SDK by inputting some variable parameters under the guidance of the test case code writing template. Then, the target test case is imported into the shell project to obtain a test APP suitable for operating system operation. Finally, the test APP is run in the operating system to implement white-box testing of the target SDK. Based on the solution of the embodiment of the present application, users who do not have professional code writing capabilities can also independently complete white-box testing for the SDK, thereby lowering the threshold requirements for white-box testing. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] Figure 1 This is a schematic diagram of the first flow chart of the SDK white box testing method according to an embodiment of the present application.

[0015] Figure 2 A schematic diagram of the framework of the SDK white box testing method of an embodiment of the present application.

[0016] Figure 3 This is a class diagram of the white box test SDK of an embodiment of the present application.

[0017] Figure 4 This is a logical flow chart of the white box testing SDK of an embodiment of the present application.

[0018] Figure 5 This is a logic flow chart of the auxiliary script module of an embodiment of the present application.

[0019] Figure 6 This is a second flow chart of the SDK white box testing method according to an embodiment of the present application.

[0020] Figure 7 This is a schematic diagram of the structure of the SDK white box testing device according to an embodiment of the present application.

[0021] Figure 8 A schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0023] Based on the above, the existing SDK testing methods can be divided into white-box testing and black-box testing. White-box testing is based on the tester's in-depth understanding of the internal structure and code logic of the software. It verifies whether the function is executed as expected by writing test code, which requires the tester to have professional code programming ability. Black-box testing does not require the tester to understand the internal structure and code logic of the software, nor does it require writing code for testing. The tester will design test cases based on the software specifications, user needs and functional requirements, and then verify whether the output meets expectations by inputting different data.

[0024] It can be seen that the testing effect of white box testing is better than that of black box testing, but white box testing has a higher threshold. To this end, this application aims to propose an SDK white box testing solution that can implement white box testing for SDK without relying on the user's professional code programming ability.

[0025] Specifically, an embodiment of the present application proposes an SDK white box testing method. Figure 1 This is a flowchart of the SDK white box test, which includes the following steps:

[0026] S102, creating a shell project and a target SDK, wherein the shell project includes a running environment of an operating system, and the target SDK is an object to be tested.

[0027] In this embodiment, the target SDK can be but is not limited to one, such as an integrated multiple SDKs. Shell project refers to an empty shell project, which does not contain actual code and only provides a code running environment. The code running environment described here includes an operating system, an interpreter of a programming language, a compiler, necessary libraries and tools, etc., which are indispensable parts for code running.

[0028] S104, providing a test case code writing template to the user, so as to obtain a target test case that is coded by the user based on the test case code writing template and is used for white-box testing of the target SDK.

[0029] In this embodiment, the test case code writing template includes a test case code writing framework, and the user can generate the test code of the test case by filling in some personalized variable parameters, such as the test object, the number of test rounds, and the test method. Therefore, even if the user does not have professional code programming ability, he can also create a white box test case.

[0030] In extreme cases, if the user is not very familiar with the variable parameters, after generating the target test case, the test code of the target test case can be input into the deep learning model for code error detection to obtain the code error detection result corresponding to the test code; then, the code error detection result is displayed to the user for modification to ensure that the target test case can run.

[0031] Among them, the deep learning model is trained based on the sample test code and the label corresponding to the sample test code. The label corresponding to the sample test code is used to indicate the code error type (true value) of the sample test code. The training principle is that after the sample test code is input into the deep learning model, the deep learning model attempts to identify the code error type (training result) existing in the sample test code, and then calculates the error loss between the code error type of the training result and the code error type indicated by the label, and adjusts the model parameters of the deep learning model with the goal of reducing the error loss. Through multiple rounds of iteration of the model parameters, the code error type identified by the deep learning model for the sample test code can be consistent with the true value indicated by the label to achieve the training purpose. After the training is completed, the code error detection result identified by the deep learning model for the target test case also includes the code error type. The user can modify the variable parameter that was previously entered incorrectly according to the code error type to rewrite the correct target test case. For example, if the code error type indicates that the current value of a target variable parameter is 200, which exceeds the value interval [0,100], the user can modify the value of the target variable parameter to the range of 0 to 100.

[0032] It should be noted that this embodiment does not limit the specific form of the deep learning model, but any classification model that supports test code as input can be applied to the prediction of code error types.

[0033] In addition, in actual applications, the test case code writing template is not limited to one. As an exemplary introduction, each type of test case can correspond to a test case code writing template, and the user can select the test case code writing template according to the type of test case to be performed.

[0034] It should be understood that traditional black box testing is equivalent to inputting different data to verify whether the SDK output meets expectations from the perspective of user use according to the software specifications, user needs and functions, which is a kind of usage test. Based on the test case code writing template of this embodiment, a test case written by professional test code can be generated, which is equivalent to a test for a specified purpose from the perspective of a system engineer. Therefore, compared with traditional black box testing, the purpose of the method of this embodiment is clearer, and once a problem occurs, the root cause can be located more quickly.

[0035] In practical applications, the code writing templates of this embodiment can be stored in a template library to achieve unified management, such as modifying or deleting the original code writing templates in the template library, adding new code writing templates to the template library, etc.

[0036] In addition, in order to facilitate users to understand the purpose of code writing templates, a description information list of the code writing template can also be configured to mark the description information of each code writing template in the template library. The description information may include code version number, code function, code variable source and other descriptions for user reference.

[0037] Even in extreme cases, if the user still cannot understand how to use the code writing template through the description information of the code writing template, the description information of the code writing template and the test requirement information of the user can be submitted as prompt words to the large language model, and the large language model can recognize the semantics of the description information of the code writing template and the user's test requirements based on the natural language understanding ability, and combine the semantics of the two to write test cases for the user. That is, the method of this embodiment can provide the user with an access port to the large language model, and the user can decide whether to use the large language model to generate the target test case.

[0038] S106, import the target test case into the shell project to obtain a test APP suitable for running the operating system.

[0039] This embodiment requires that the target test case be run on the device in the form of an APP. To this end, the target test case can be first configured into a dex file executable by the operating system (containing test code and test resources), and then the dex file can be imported into the shell project to generate a test APP for testing the target SDK.

[0040] On the basis of the above, users can further customize the test result feedback method. For example, provide users with implementation classes of multiple test result feedback methods supported by the operating system, so that users can select the implementation class of the specified test result feedback method; then, import the target test case and the implementation class of the specified test result feedback method into the shell project to build a test APP. Among them, the test result feedback method can include: at least one of pop-up feedback, voice playback feedback, and motor vibration feedback, which is not specifically limited in this article.

[0041] In actual applications, different users and different white-box tests correspond to different dex files, and dex files need to reflect differentiated configurations to distinguish them. To this end, the target test cases and the implementation classes of the specified test result feedback method can be packaged into class files; then, according to the differentiated configuration information, such as: the path of the class file, the package name of the class file, the package name of the shell project, and at least one of the paths of the pre-generated dex files, the class files are converted into dex files.

[0042] In addition, this embodiment can also save the test cases written by the user through the test case code writing template. Correspondingly, during this white box test, if the user needs to use historical test cases, the historical test cases can be retrieved to be imported into the shell project together with the target test cases.

[0043] S108, running the test APP in the operating system to perform white box testing on the target SDK.

[0044] Specifically, in this step, based on the dynamic loading technology of dex files in the operating system, the target test cases of the dex files and the implementation class of the specified test result feedback method are identified and loaded, so that the white box test can be automatically performed and the corresponding test results can be output according to the specified test result feedback method.

[0045] In summary, based on the method of this embodiment, when it is necessary to perform white box testing on the target SDK, a shell project can be created and a test case code writing template can be provided to the user. Correspondingly, the user can write a target test case for white box testing of the target SDK by inputting some variable parameters under the guidance of the test case code writing template. Then, the target test case is imported into the shell project to obtain a test APP suitable for operating system operation. Finally, the test APP is run in the operating system to implement white box testing of the target SDK. It can be seen that the method of this embodiment enables users who do not have professional code writing capabilities to independently complete white box testing for the SDK, thereby reducing the threshold requirements for white box testing.

[0046] The method of this embodiment is introduced below in conjunction with the application scenario of the Android operating system.

[0047] Figure 2 It is a schematic diagram of the architecture of the method of this embodiment, including: a test APP shell engineering module, a test case module and an auxiliary script module.

[0048] 1. Test the APP shell engineering module

[0049] The test APP shell engineering module is responsible for the specific operation of white box testing, including the following three sub-parts:

[0050] 1) Shell project: provides the code running environment of the Android system, but does not contain the actual code;

[0051] 2) Target SDK: as the test object in this application scenario;

[0052] 3) White box testing SDK: It consists of functional entities related to white box testing. Figure 3 The functional entities of the white box test SDK module and the corresponding class diagram are illustrated, including:

[0053] ①Interface extension function entity: used for custom interface classes, such as IBaseApplication interface class and ITestContext interface class. Among them, IBaseApplication interface class provides a framework for writing test cases using the run() function of the Android system. ITestContext interface class is responsible for calling the Android system's proprietary capabilities to implement test result feedback, such as pop-up feedback, voice playback feedback, motor vibration feedback, etc.

[0054] Here we take the implementation of Toast pop-up feedback as an example. The ITestContext interface class can provide a code writing template for the Toast pop-up window, which is as follows:

[0055]

[0056] }

[0057] Among them, users can query the code that specifically implements the Toast function from the code library through the ITestContext interface class, and import it into the above code writing template to implement Toast pop-up feedback.

[0058] ② Dynamic loading functional entity: It is configured with Android dex file dynamic loading technology, which is specifically used to dynamically load and use dex files when the Android APP is running. The loading objects mainly include instances of the above-mentioned IBaseApplication interface class and ITestContext interface class, so as to ultimately realize the generation of test cases.

[0059] ③ Human-computer interaction functional entity: It is configured with the SDKTesterActivity class, which provides a human-computer interaction interface, displays the progress of the automated test process in real time, and displays the final test results or error information during the test process.

[0060] ④ Database functional entity: Configured with TesterGreenDao class, which is responsible for recording the user's test cases and corresponding test results to facilitate subsequent queries by users.

[0061] Correspondingly, the main execution logic of the above white box test SDK is as follows Figure 4 As shown, including:

[0062] A1, dynamically load dex files.

[0063] A2, according to the class name in the dex file, load the target interface class, such as the instances of the IBaseApplication interface class and ITestContext interface class mentioned above.

[0064] A3, create a test instance of the target class. A4, execute the test code of the test case and record the test case and test results based on the TesterGreenDao class.

[0065] A5, display the test results based on the SDKTesterActivity class.

[0066] 2. Test case module

[0067] In the test case module, users can choose a mainstream integrated development environment to write test case code.

[0068] Among them, the test case module includes the following three functional entities:

[0069] 1) Test case code functional entity: Provide users with the description document of the SDK to be tested (target SDK) interface to facilitate users to write test case code;

[0070] 2) SDK functional entity to be tested: used to map the SDK to be tested to the integrated development environment tool, so that users can write test case codes. The integrated development environment tool can automatically complete the code according to the content of the SDK to be tested;

[0071] 3) White-box testing SDK extended functional entity: Integrate the interface extension functional entity in the white-box testing SDK so that the code written by the user for the test case needs to comply with the framework provided by the interface extension functional entity.

[0072] 3. Auxiliary script module

[0073] The auxiliary script module is responsible for completing the differentiated configuration of dex files and triggering the Android APP to dynamically load and compile dex files for white box testing.

[0074] The auxiliary script module includes the following two functional entities:

[0075] 1) Start the script function entity: implement some related operations through the script. The main functions are:

[0076] ① Read the differential information configuration script: In order to achieve universality, some differential information (main test class package name and target dex file name) is recorded in the configuration script;

[0077] ② Determine the current system type and compile the dex file: Determine the current system type by reading the system properties, and use the dex file compilation tool that matches the current system type to compile and generate the target dex file;

[0078] ③ Push the dex file to the target Android device: Use ADB commands to push the currently compiled dex file to the private external data storage space of the test shell project on the target Android device according to the package name of the shell project in the configuration script;

[0079] ④ Pull up the test interface and trigger automated testing: Use AM instructions to pull up the human-computer interaction function entity in the white-box test SDK, and pass in the main test class package name and target dex file name in the configuration script to trigger the white-box test SDK to start automated white-box testing.

[0080] 2) Differentiated configuration script functional entity: some differentiated information is recorded in the above configuration script to generate the following configuration items:

[0081] ① Compile and generate the dex file name: compile and generate the target dex file with the specified name to the target Android device, and trigger the white box test SDK to start dynamically loading the target dex file with the specified name;

[0082] ② The directory and package name of the class file compiled and generated on the integrated development environment tool: The dex file compilation tool needs to pass in the directory and package name of the class file to be compiled;

[0083] ③ Package name of the shell project: Only after the shell project is configured with a specific package name, can the compiled dex file be pushed to the private external storage space of the target Android device, and the human-computer interaction function entity in the white box test SDK in the shell project be pulled up through AM instructions.

[0084] Correspondingly, the main execution logic of the auxiliary script module is as follows Figure 5 As shown, including:

[0085] B1, read the differential configuration information, such as the main test class package name and the name of the target dex file.

[0086] B2, determine the current system type, such as: Mac system, Windows system and Linux system, etc.

[0087] B3, use the dex file compilation tool of the current system type to compile the class file into the target dex file according to the differentiated configuration information.

[0088] B4, use ADB command to push the target dex file to the target Android device.

[0089] Among them, the ADB command is a C / S architecture command line tool provided by Android. Through the ADB command, operation commands can be issued to the target Android device.

[0090] B5, use AM instructions to trigger the shell project to dynamically load the dex file and start automated white box testing.

[0091] Among them, the AM command is also a command line tool provided by Android, which allows interaction with the ActivityManager Service of the Android system. Various system operations can be performed through the AM command.

[0092] based on Figure 2 The overall process of SDK white box testing in this application scenario is as follows: Figure 6 As shown, including:

[0093] C1, the test case of the startup script function entity in the auxiliary script module receiving the class file input by the user;

[0094] Among them, users use mainstream integrated development environment tools to implement the code writing of test cases for class files under the framework provided by the interface expansion function entity of the white box test SDK. Class files are files that can be recognized on Android devices.

[0095] C2, the differential configuration function entity compiles the test cases of the class file into test cases of the dex file according to the differential information, and pushes the compiled target dex file to the shell project.

[0096] It should be understood that the bytecode running on the Android device is based on the dex format, so it is necessary to convert the test cases of the compiled class file into test cases of the dex file.

[0097] Specifically, this step can use the dx tool that comes with the Android development kit to generate the target dex file according to the following differential information configuration:

[0098] 1) The name of the pre-generated target dex file;

[0099] 2) The path of the generated class file;

[0100] 3) The package name of the class file;

[0101] 4) The package name of the shell project.

[0102] For example:

[0103] #Compile and generate the custom name of the target dex file: dexName = test.dex;

[0104] #The directory where the class files compiled and generated by the integrated development environment tool are located: classFilePath = / Users / Projects / tester / out / production / tester / ;

[0105] #Package name corresponding to the class file: classFilePackageName=com.example.Main;

[0106] #Package name of the shell project: targetApkPackageName=com.example.demo.

[0107] C3, the shell project receives the target dex file, and in response to the triggering of the start script function entity in the auxiliary script module, dynamically loads the test case corresponding to the target dex file to complete the white box test.

[0108] Specifically, the white-box test SDK in the shell project responds to the triggering of the test startup script module and uses Android dynamic loading technology to load the target dex file pushed in the previous step. During the loading process, the white-box test SDK traverses and finds all IBaseApplication interface classes, and automatically runs its internal run() function to complete the white-box test. During the running process, the run() function can also pass in an instance of the ITestContext interface class to select a specified test result feedback method.

[0109] C4, the human-computer interaction function entity in the white-box testing SDK displays the test results to the user.

[0110] Next, the target Android device will automatically perform the test according to the code in the run() function. If successful, the screen will display success. If failed, the screen will prompt the reason for the error, and finally save the test results in the database function entity.

[0111] In summary, the method of this embodiment has the following characteristics:

[0112] 1) Implement white-box testing of the Android SDK without relying on Android engineers. Compared with black-box testing, it is less likely to ignore some boundary conditions and abnormal situations, thereby improving test coverage.

[0113] 2) Combined with Android's unique capabilities, different test result feedback methods are provided for users to choose from, such as dialogue pop-up windows, prompt pop-up window feedback, voice broadcast feedback, motor vibration feedback, SMS sending feedback, email sending feedback, etc. In addition, it can also support the expansion of derivative functions such as log printing, screen display of results, and result recording in the database.

[0114] 3) Initiating white-box testing based on test code is more purposeful. Once a problem is found during testing, the root cause can be located more quickly, thus achieving higher testing efficiency.

[0115] Corresponds to Figure 1 The method shown, another embodiment of the present application provides an SDK white box testing device. Figure 7 : is a schematic diagram of the structure of the SDK white box test device 700, including:

[0116] A creation unit 710 creates a shell project and a target SDK, wherein the shell project includes an operating environment of an operating system, and the target SDK is an object to be tested;

[0117] The writing unit 720 provides a test case code writing template to the user, so as to obtain a target test case written by the user based on the test case code writing template for white-box testing of the target SDK;

[0118] An importing unit 730 imports the target test case into the shell project to obtain a test APP suitable for running the operating system;

[0119] The testing unit 740 runs the test APP in the operating system to perform white box testing on the target SDK.

[0120] Based on the device of this embodiment, when it is necessary to perform white-box testing on the target SDK, a shell project can be created and a test case code writing template can be provided to the user. Correspondingly, the user can write a target test case for white-box testing of the target SDK by inputting some variable parameters under the guidance of the test case code writing template. Then, the target test case is imported into the shell project to obtain a test APP suitable for operating system operation. Finally, the test APP is run in the operating system to implement white-box testing of the target SDK. It can be seen that the device of this embodiment enables users who do not have professional code writing capabilities to independently complete white-box testing for the SDK, thereby lowering the threshold requirements for white-box testing.

[0121] Optionally, the import unit 730 imports the target test case into the shell project to obtain a test APP suitable for running the operating system, including: providing the user with implementation classes of multiple test result feedback methods supported by the operating system to obtain the implementation class of the specified test result feedback method selected by the user; importing the target test case and the implementation class of the specified test result feedback method into the shell project to obtain a test APP suitable for running the operating system; wherein, after the operating system completes running the test APP, it feeds back the test results of the target SDK in accordance with the specified test result feedback method.

[0122] Optionally, the import unit 730 imports the target test case and the implementation class of the specified test result feedback method into the shell project to obtain a test APP suitable for running the operating system, including: configuring the target test case and the implementation class of the specified test result feedback method into a dex file; importing the dex file into the shell project to generate a test APP for testing the target SDK.

[0123] Optionally, the import unit 710 configures the target test case and the implementation class of the specified test result feedback method into a dex file, including: packaging the target test case and the implementation class of the specified test result feedback method into a class file; converting the class file into a dex file according to the differentiated configuration information; wherein the differentiated configuration information includes: the path of the class file, the package name of the class file, the package name of the shell project and at least one of the path of the pre-generated dex file.

[0124] Optionally, the testing unit 740 runs the test APP in the operating system, including: in the operating system, based on the dex file dynamic loading technology, identifying and loading the target test case of the dex file and the implementation class of the specified test result feedback method.

[0125] Optionally, the multiple test result feedback methods include: at least one of: pop-up window feedback, voice playback feedback, and motor vibration feedback.

[0126] Optionally, before the import unit 730 imports the target test case into the shell project to obtain a test APP suitable for running the operating system, it also executes: inputting the test code of the target test case into the deep learning model for code error detection, and obtaining a code error detection result corresponding to the test code; wherein the deep learning model is trained based on sample test code and the label corresponding to the sample test code, and the label corresponding to the sample test code is used to indicate the code error type of the sample test code; and, displaying the code error detection result to the user.

[0127] Optionally, the import unit 730 imports the target test case into the shell project to obtain a test APP suitable for running the operating system, including: obtaining historical test cases provided by the user, and importing the historical test cases and the target test cases into the shell project to obtain a test APP suitable for running the operating system; wherein the historical test cases are compiled by the user using a template for writing the code of the test case to be tested.

[0128] Optionally, the device of this embodiment further includes:

[0129] The recording unit is configured to record the test result of the target SDK after the testing unit 740 performs the white box test on the target SDK.

[0130] Optionally, the operating system is an Android system, and the test code includes a run() function.

[0131] It should be noted that the SDK white box test device of this embodiment can be used as Figure 1 The execution subject of the method shown can thus realize Figure 1 The steps and functions in the method shown will not be repeated in this article.

[0132] Figure 8 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Figure 8 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0133] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0134] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0135] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming the above SDK white box test device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0136] Create a shell project and a target SDK, wherein the shell project includes the operating environment of the operating system, and the target SDK is the object to be tested.

[0137] A test case code writing template is provided to the user to obtain a target test case that is coded by the user based on the test case code writing template and is used for white-box testing of the target SDK.

[0138] Import the target test case into the shell project to obtain a test APP suitable for running on the operating system.

[0139] The test APP is run in the operating system to perform white box testing on the target SDK.

[0140] Based on the electronic device of the present embodiment, when it is necessary to perform white box testing on the target SDK, a shell project can be created and a test case code writing template can be provided to the user. Correspondingly, the user can write a target test case for white box testing of the target SDK by inputting some variable parameters under the guidance of the test case code writing template. Then, the target test case is imported into the shell project to obtain a test APP suitable for operating system operation. Finally, the test APP is run in the operating system to implement white box testing of the target SDK. Based on the solution of the embodiment of the present application, users who do not have professional code writing capabilities can also independently complete white box testing for the SDK, thereby lowering the threshold requirements for white box testing.

[0141] The above application Figure 1 The method disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in the form of software. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in one or more embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in conjunction with one or more embodiments of the present application can be directly embodied as a hardware decoding processor for execution, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0142] Of course, in addition to software implementation, the electronic device of the present application does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0143] The present application also provides a computer program product, which includes a computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform the following operations:

[0144] Create a shell project and a target SDK, wherein the shell project includes the operating environment of the operating system, and the target SDK is the object to be tested.

[0145] A test case code writing template is provided to the user to obtain a target test case that is coded by the user based on the test case code writing template and is used for white-box testing of the target SDK.

[0146] Import the target test case into the shell project to obtain a test APP suitable for running on the operating system.

[0147] The test APP is run in the operating system to perform white box testing on the target SDK.

[0148] In short, the above description is only a preferred embodiment of the present application and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present application shall be included in the protection scope of one or more embodiments of the present application.

[0149] The systems, devices, and modules described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0150] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0151] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0152] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

Claims

1. A SDK white box testing method, characterized in that: include: Create a shell project and a target SDK, wherein the shell project includes an operating environment of an operating system, and the target SDK is an object to be tested; Providing a test case code writing template to the user, so as to obtain a target test case written by the user based on the test case code writing template for white-box testing of the target SDK; Importing the target test case into the shell project to obtain a test APP suitable for running the operating system; The test APP is run in the operating system to perform white box testing on the target SDK.

2. The method according to claim 1, characterized in that Importing the target test case into the shell project to obtain a test APP suitable for running the operating system includes: Providing the user with implementation classes of multiple test result feedback methods supported by the operating system to obtain the implementation class of the specified test result feedback method selected by the user; Importing the target test case and the implementation class of the specified test result feedback method into the shell project to obtain a test APP suitable for running the operating system; After the operating system has completed running the test APP, the test result of the target SDK is fed back in accordance with the specified test result feedback method.

3. The method according to claim 2, characterized in that Importing the target test case and the implementation class of the specified test result feedback method into the shell project to obtain a test APP suitable for running the operating system, including: Configure the target test case and the implementation class of the specified test result feedback method into a dex file; Import the dex file into the shell project to generate a test APP for testing the target SDK.

4. The method according to claim 3, characterized in that: Configure the target test case and the implementation class of the specified test result feedback method into a dex file, including: Package the target test case and the implementation class of the specified test result feedback method into a class file; According to the differentiated configuration information, convert the class file into a dex file; The differential configuration information includes: at least one of the path of the class file, the package name of the class file, the package name of the shell project, and the path of the pre-generated dex file.

5. The method according to claim 3, characterized in that: Running the test APP in the operating system includes: In the operating system, the target test case of the dex file and the implementation class of the specified test result feedback method are identified and loaded based on the dex file dynamic loading technology.

6. The method according to claim 2, characterized in that The multiple test result feedback methods include: at least one of: pop-up window feedback, voice playback feedback, and motor vibration feedback.

7. The method according to claim 2, characterized in that Before importing the target test case into the shell project to obtain a test APP suitable for running the operating system, the method includes: Input the test code of the target test case into the deep learning model for code error detection, and obtain the code error detection result corresponding to the test code; wherein the deep learning model is trained based on the sample test code and the label corresponding to the sample test code, and the label corresponding to the sample test code is used to indicate the code error type of the sample test code; The code error detection result is displayed to the user.

8. The method according to claim 1, characterized in that Importing the target test case into the shell project to obtain a test APP suitable for running the operating system includes: Obtain the historical test cases provided by the user, and import the historical test cases and target test cases into the shell project to obtain a test APP suitable for running the operating system; wherein the historical test cases are compiled by the template for writing the code of the user's test case.

9. The method according to any one of claims 1 to 8, characterized in that: After running the test APP in the operating system to perform white box testing on the target SDK, the method further includes: The test results of the target SDK are recorded.

10. The method according to any one of claims 1 to 8, characterized in that: The operating system is an Android system, and the test code includes a run() function.

Images