Method, apparatus and system for automated testing of DDK interfaces based on an automated testing tool and a lightweight operating system

Abstract

The present disclosure relates to the technical field of driver development and testing, and particularly relates to a method for implementing automated testing of DDK interfaces of a driver development kit for a lightweight operating system by using an automated testing tool, an automated testing method and device and system based on DDK interfaces of a lightweight operating system. In this method, by referring to the DDK interface test list header file in the set board-level driver file, references to multiple DDK unit test files are realized, and the set board-level driver file and the DDK interface test list header file are saved in the DDK and then compiled to provide a first compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the first compiled DDK file to perform automated testing of DDK interfaces. Without the need for additional tools, the present disclosure can verify all DDK interfaces provided for the lightweight operating system and can modify the test content for DDK interfaces as needed.

Description

Technical Field

[0001] The present disclosure relates to the technical field of driver development and testing, and particularly to a method for automating the testing of the Driver Development Kit (DDK) interface of a Lightweight Operating System (LOS) using an automated testing tool, an automated testing method for the DDK interface based on the lightweight operating system, and a device and a system thereof. Background Art

[0002] A lightweight operating system is an operating system with a simple design, low resource consumption, and relatively limited functions. It is usually applied to scenarios with specific hardware limitations or specific application requirements, such as embedded systems, Internet of Things devices, microcontrollers, etc. The goal of a lightweight operating system is to provide the most basic operating system functions while maintaining low resource consumption and high operating efficiency.

[0003] To simplify the system structure, reduce resource consumption, and improve efficiency, in a lightweight operating system, the kernel and the driver generally adopt a relatively tight integration method. However, in actual use, manufacturers have the need to select components independently, and a lightweight operating system with the kernel and the driver integrated together cannot meet this need, and may also bring problems such as system crashes caused by driver errors, thus triggering security risks. Therefore, a lightweight operating system with the kernel and the driver separated can well avoid the above problems.

[0004] However, in a lightweight operating system with the kernel and the driver separated, in addition to providing a Software Development Kit (SDK) externally, a DDK also needs to be provided. Therefore, before the release of a lightweight operating system with the kernel and the driver separated, in addition to testing the kernel and the SDK, the DDK also needs to be fully verified and tested. Compared with the SDK, the DDK is more closely related to the lightweight operating system, and the requirements for testing are also more stringent.

[0005] There are mainly two deficiencies in the existing testing methods for DDK interfaces: limited testing scope and fixed testing content. That is, the existing testing methods can only test the DDK interfaces using a DDK test APP based on the SDK after the lightweight operating system starts up, resulting in some DDK interfaces not being testable, and only being able to test the preset functions registered by the driver during the operating system startup phase. Summary of the Invention

[0006] To solve the problems in the related art, embodiments of the present disclosure provide a method for implementing automated testing of DDK interfaces of a lightweight operating system using an automated testing tool, an automated testing method and device, and a system based on the DDK interfaces of the lightweight operating system.

[0007] In a first aspect, embodiments of the present disclosure provide a method for implementing automated testing of DDK interfaces of a lightweight operating system using an automated testing tool. The automated testing tool runs on a computer, and the DDK interfaces are provided by the DDK for the lightweight operating system. The method includes using the automated testing tool to perform the following steps:

[0008] Obtain a DDK interface test list according to user input. The DDK interface test list corresponds to multiple DDK unit test files, and the DDK unit test files are used to test corresponding test points among multiple test points set for the DDK interfaces.

[0009] Generate a DDK interface test list header file based on the DDK interface test list, and save the DDK interface test list header file in the DDK. The DDK interface test list header file is used to implement the reference to the multiple DDK unit test files.

[0010] Set a reference instruction in the board-level driver file, and save the set board-level driver file in the DDK. The reference instruction is used to reference the DDK interface test list header file in the set board-level driver file, so that the set board-level driver file can load the multiple DDK unit test files when executed.

[0011] Obtain the set DDK, where the set DDK includes the DDK interface test list header file and the set board-level driver file.

[0012] Compile the set DDK to obtain a first compiled DDK file.

[0013] Provide the first compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the first compiled DDK file to perform automated testing of the DDK interfaces.

[0014] According to an embodiment of the present disclosure, it further includes: obtaining an interface test result from the startup log of the lightweight operating system, where the interface test result is the result obtained by the lightweight operating system performing automated testing of the DDK interfaces.

[0015] According to an embodiment of the present disclosure, it further includes:

[0016] After obtaining the interface test result, delete the DDK interface test list header file and the set board-level driver file in the set DDK, and restore the set DDK to the DDK;

[0017] Compile the DDK to obtain a second compiled DDK file;

[0018] Provide the second compiled DDK file to the lightweight operating system so that the lightweight operating system can use the second compiled DDK file to implement system recovery.

[0019] According to an embodiment of the present disclosure, the DDK interface includes a plurality of application programming API interfaces;

[0020] The multiple test points set for the DDK interface include: one or more test points set for the API interface, or one or more test points set for some of the multiple API interfaces.

[0021] According to an embodiment of the present disclosure, the DDK interface includes API interfaces of necessary drivers and non-necessary drivers provided by the DDK to the lightweight operating system.

[0022] In a second aspect, an automated test method for a DDK interface provided by a DDK based on a lightweight operating system is provided in an embodiment of the present disclosure. The lightweight operating system is applied to a chip, and the kernel and driver of the lightweight operating system are separated. A plurality of test points are set for the DDK interface. The method includes:

[0023] Execute the first compiled DDK file on the lightweight operating system using an upgrade driver command, so that the lightweight operating system automatically restarts. Among them, the first compiled DDK file is obtained by compiling the set DDK. The set DDK includes a set board-level driver file and a DDK test list header file. The DDK test list header file includes a DDK test unit list. The DDK test unit list corresponds to a plurality of DDK unit test files. The DDK unit test files are used to test the test points. The set board-level driver file includes a reference instruction. The reference instruction is used to reference the DDK test list header file in the set board-level driver file. The automatic restart includes:

[0024] The chip is powered on;

[0025] The lightweight operating system enters the boot phase, and an interrupt vector table is built during the boot phase;

[0026] After the interrupt vector table is constructed, the lightweight operating system enters the kernel startup phase;

[0027] In the kernel startup phase, drivers are loaded, and the set board-level driver files are executed. In the set board-level driver files, the DDK test list header file is referenced through the reference instruction, and multiple DDK unit test files are loaded; the hardware initialization function is called to execute the multiple DDK unit test files, and multiple test points set for the DDK interface are tested to obtain the interface test results of the DDK interface. The interface test results are saved in the startup log of the lightweight operating system.

[0028] According to an embodiment of the present disclosure, after obtaining the interface test results of the DDK interface, the second compiled DDK file is executed on the lightweight operating system using the upgrade driver command, so that the lightweight operating system is restarted again to achieve system recovery, where the second compiled DDK file is a file obtained by deleting the set board-level driver file and the DDK test list header file included in the set DDK and then compiling.

[0029] According to an embodiment of the present disclosure, the DDK interface includes multiple API interfaces;

[0030] Multiple test points are set for the DDK interface, including: setting one or more test points for the API interface, or setting one or more test points for some of the multiple API interfaces.

[0031] According to an embodiment of the present disclosure, the test point is a test range set for the registration function and / or non-registration function in the API interface.

[0032] According to an embodiment of the present disclosure, the registration function is a function registered in the driver loaded in the kernel startup phase;

[0033] The non-registration function is a function not registered in the driver loaded in the kernel startup phase.

[0034] According to an embodiment of the present disclosure, the loaded driver is an essential driver, or the loaded driver is an essential driver and a non-essential driver.

[0035] In a third aspect, an automated test tool is provided. The automated test tool is used to implement the automated test of the DDK interface of the lightweight operating system. The automated test tool runs on a computer. The DDK interface is provided by the DDK for the lightweight operating system. The automated test tool includes:

[0036] A first acquisition module, configured to acquire a DDK interface test list according to user input, where the DDK interface test list corresponds to multiple DDK unit test files, and the DDK unit test files are used to test corresponding test points among multiple test points set for the DDK interface;

[0037] A generation module, configured to generate a DDK interface test list header file based on the DDK interface test list and save the DDK interface test list header file in the DDK, where the DDK interface test list header file is used to implement the reference to the multiple DDK unit test files;

[0038] A setting module, configured to set a reference instruction in a board-level driver file and save the set board-level driver file in the DDK, where the reference instruction is used to reference the DDK interface test list header file in the set board-level driver file, so that the set board-level driver file can load the multiple DDK unit test files when executed;

[0039] A second acquisition module, configured to acquire the set DDK, where the set DDK includes the DDK interface test list header file and the set board-level driver file;

[0040] A first compilation module, configured to compile the set DDK to obtain a first compiled DDK file;

[0041] A provision module, configured to provide the first compiled DDK file to the lightweight operating system, so that the lightweight operating system can perform automated testing of the DDK interface by using the first compiled DDK file.

[0042] According to an embodiment of the present disclosure, it further includes: a third acquisition module, configured to acquire an interface test result from the startup log of the lightweight operating system, where the interface test result is the result obtained by the lightweight operating system performing automated testing of the DDK interface.

[0043] According to an embodiment of the present disclosure, it further includes: a second compilation module, configured to:

[0044] After acquiring the interface test result, delete the DDK interface test list header file and the set board-level driver file in the set DDK, and restore the set DDK to the DDK;

[0045] Compile the DDK to obtain a second compiled DDK file;

[0046] Provide the second compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the second compiled DDK file to implement system recovery.

[0047] Fourthly, an automated testing device for DDK interfaces provided for a DDK in a lightweight operating system is provided in an embodiment of the present disclosure. The automated testing device is applied to a lightweight operating system with a separated kernel and driver. The lightweight operating system is applied to a chip. Multiple test points are set for the DDK interfaces. The device includes:

[0048] An automatic restart module, configured to execute a first compiled DDK file on the lightweight operating system using an upgrade driver command, so that the lightweight operating system automatically restarts. Wherein, the first compiled DDK file is obtained by compiling the set DDK. The set DDK includes a set board-level driver file and a DDK test list header file. The DDK test list header file includes a DDK test unit list. The DDK test unit list corresponds to multiple DDK unit test files. The DDK unit test files are used to test the test points. The set board-level driver file includes a reference instruction. The reference instruction is used to reference the DDK test list header file in the set board-level driver file;

[0049] The automatic restart module includes:

[0050] A power-on module, configured to power on the chip;

[0051] A boot module, configured to make the lightweight operating system enter the boot phase, and construct an interrupt vector table in the boot phase;

[0052] A kernel startup module, configured to after the interrupt vector table is constructed, the lightweight operating system enters the kernel startup phase; in the kernel startup phase, load the driver, execute the set board-level driver file, reference the DDK test list header file in the set board-level driver file through the reference instruction, and load the multiple DDK unit test files; call a hardware initialization function to execute the multiple DDK unit test files, test multiple test points set for the DDK interface, and obtain an interface test result of the DDK interface. The interface test result is saved in the startup log of the lightweight operating system.

[0053] According to an embodiment of the present disclosure, it further includes: a system recovery module, configured to:

[0054] After obtaining the interface test result of the DDK interface, execute the second compilation of the DDK file on the lightweight operating system using the upgrade driver command, so that the lightweight operating system is restarted again to achieve system recovery, where the second compilation of the DDK file is a file obtained by deleting the set board-level driver file and the DDK test list header file included in the set DDK and then compiling.

[0055] According to an embodiment of the present disclosure, the DDK interface includes a plurality of API interfaces; the first compilation of the DDK file is a binary file.

[0056] In a fifth aspect, an automated test system for a DDK interface provided by a DDK for a lightweight operating system according to an embodiment of the present disclosure includes: the automated test tool according to any one of the claims in the third aspect and the device according to any one of the claims in the fourth aspect.

[0057] In a sixth aspect, an embodiment of the present disclosure provides a computer-readable storage medium, on which computer instructions are stored, and when the computer instructions are executed by a processor, the method according to any one of the first aspect or the second aspect is implemented.

[0058] In a seventh aspect, an embodiment of the present disclosure provides a computer program product, including computer instructions, and when the computer instructions are executed by a processor, the method according to any one of the first aspect or the second aspect is implemented.

[0059] According to the technical solution provided by the embodiment of the present disclosure, by using a reference instruction to reference the DDK interface test list header file in the set board-level driver file, the reference to a plurality of DDK unit test files is realized, and the set board-level driver file and the DDK interface test list header file are saved and then compiled after the DDK, so as to provide the first compilation of the DDK file to the lightweight operating system, so that the lightweight operating system can perform the automated test of the DDK interface by using the first compilation of the DDK file. Without relying on additional tools, the present disclosure can verify all DDK interfaces provided for the lightweight operating system and all functions of the DDK interface, solve the problems that only part of the DDK interfaces can be tested after the kernel starts and only the functions registered in the DDK interface can be tested, and can modify the test content of the DDK interface as needed to flexibly adapt to the test requirements of developers.

[0060] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. Brief Description of the Drawings

[0061] In conjunction with the accompanying drawings, through the following detailed description of non-limiting embodiments, other features, objectives, and advantages of the present disclosure will become more apparent. In the drawings:

[0062] Figure 1 A flowchart showing a method for testing a DDK interface in the prior art is presented;

[0063] Figure 2 A logic block diagram showing a method for implementing automated testing of a DDK interface of a lightweight operating system using an automated testing tool according to an embodiment of the present disclosure is presented;

[0064] Figure 3 A schematic diagram showing the relationship between the set board-level driver file, the DDK interface test list header file, and the DDK interface test list is presented;

[0065] Figure 4 A logic block diagram showing an automated testing method for a DDK interface provided by a DDK based on a lightweight operating system according to an embodiment of the present disclosure is presented;

[0066] Figure 5 Shown is Figure 4 A flowchart showing the automatic restart of the lightweight operating system in the automated testing method of the shown example;

[0067] Figure 6 A structural block diagram showing an automated testing tool according to an embodiment of the present disclosure is presented;

[0068] Figure 7 A structural block diagram showing an automated testing device for a DDK interface provided by a DDK based on a lightweight operating system according to an embodiment of the present disclosure is presented. Detailed Embodiments

[0069] In the following, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily implement them. In addition, for clarity, parts irrelevant to the description of the exemplary embodiments are omitted in the drawings.

[0070] In the present disclosure, it should be understood that terms such as "including" or "having" are intended to indicate the presence of features, numbers, steps, actions, components, parts, or combinations thereof disclosed in this specification, and are not intended to exclude the possibility of the presence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0071] In addition, it should be noted that, without conflict, the embodiments and features in the embodiments of the present disclosure can be combined with each other. The present disclosure will be described in detail below with reference to the drawings and in combination with the embodiments.

[0072] In the present disclosure, if an operation involves obtaining user information or user data, or presenting user information or user data to others, such operation is an operation authorized, confirmed by the user, or actively selected by the user.

[0073] As mentioned above, in a lightweight operating system, when the driver is coupled with the kernel, it can neither meet the requirements of the manufacturer for independent component selection, nor may it cause the system to crash due to driver errors. To avoid the above problems, a lightweight operating system with the driver separated from the kernel is required.

[0074] In a lightweight operating system with the driver separated from the kernel, during the testing process before the system is released, the DDK needs to be fully verified and tested. Compared with the development of the user-mode SDK, the DDK is more closely related to the system, and the requirements for developers and testers are also more stringent.

[0075] As Figure 1 shown, in the existing testing method for DDK interfaces, first, the lightweight operating system needs to be started. During this startup process: after the system is powered on, it will first enter the boot stage (the boot stage of the operating system). In the boot stage, the interrupt vector table will be constructed, and then it will jump to the kernel. The first step in the kernel startup stage is to load the necessary drivers. After the loading is completed, the system kernel will be started. Among them, when the necessary drivers are loaded, the first function executed is the hardware initialization function in the board-level driver file. In this function, necessary hardware initialization is completed, such as: vector table setting, clock configuration, heap space initialization, etc. For some non-necessary drivers, they can be registered and loaded through an automatic initialization mechanism after the system kernel is started. Finally, after the lightweight operating system is started, a DDK test APP based on the SDK is used to test the DDK interfaces.

[0076] After in-depth research, the inventors found that the existing testing method for DDK interfaces has the following deficiencies:

[0077] 1. Limited testing scope: Since a cross-compiled test APP is used, this test APP can only be downloaded into the system to test the interfaces after the lightweight operating system is started. Therefore, only the corresponding interfaces in the SDK can be called, and the opportunity to call the interfaces in the DDK to implement driver testing has passed, resulting in some interfaces that are only called in the board-level driver file during the system startup process cannot be tested, such as thread communication API interfaces, inter-process communication API interfaces, wait queue API interfaces, timer API interfaces, file access API interfaces, memory management API interfaces, and C library API interfaces, etc.

[0078] 2. The test content is fixed, and only the preset functions registered by the driver during the operating system startup phase can be tested: After the operating system startup is completed, the driver has been registered and cannot be modified. Therefore, only the functions preset during registration can be tested. However, the functions preset during registration are not perfect, and some functions will be turned off or restricted. At the same time, it is also impossible to create a driver for a new device after the operating system startup is completed.

[0079] To solve the above technical problems, the present disclosure provides a method for implementing automated testing of DDK interfaces of a lightweight operating system using an automated testing tool. The automated testing tool runs on a computer, and the DDK interfaces are provided by DDK for the lightweight operating system. The method includes using the automated testing tool to perform the following steps:

[0080] Obtain a DDK interface test list according to user input. The DDK interface test list corresponds to multiple DDK unit test files, and the DDK unit test files are used to test corresponding test points among multiple test points set for the DDK interfaces; generate a DDK interface test list header file based on the DDK interface test list and save the DDK interface test list header file in the DDK. The DDK interface test list header file is used to implement the reference to the multiple DDK unit test files; set a reference instruction in the board-level driver file and save the set board-level driver file in the DDK. The reference instruction is used to reference the DDK interface test list header file in the set board-level driver file, so that the set board-level driver file can load the multiple DDK unit test files when executed; obtain the set DDK, where the set DDK includes the DDK interface test list header file and the set board-level driver file; compile the set DDK to obtain a first compiled DDK file; provide the first compiled DDK file to the lightweight operating system so that the lightweight operating system can use the first compiled DDK file to perform automated testing of the DDK interfaces.

[0081] The present disclosure can verify all DDK interfaces provided for the lightweight operating system and all functions of the DDK interfaces without using additional tools, with a comprehensive test scope, and can modify the test content for the DDK interfaces as needed to flexibly adapt to the test requirements of developers.

[0082] Figure 2 A logic block diagram showing a method for implementing automated testing of DDK interfaces of a lightweight operating system using an automated testing tool according to an embodiment of the present disclosure. As Figure 2 shown, the method includes using the automated testing tool to perform the following steps S201 to S206.

[0083] According to an embodiment of the present disclosure, the automated test tool runs on a computer. For example, it can be an intelligent test platform, intelligent test software, and so on.

[0084] In step S201, a DDK interface test list is obtained according to user input. The DDK interface test list corresponds to multiple DDK unit test files, and the DDK unit test files are used to test corresponding test points among multiple test points set for the DDK interface.

[0085] Among them, the DDK interface is an interface provided by DDK for a lightweight operating system, that is, an interface provided by DDK according to the driver requirements of the lightweight operating system, and the driver requirements are the requirements that can meet the needs of developers to develop or test the driver interface of the lightweight operating system.

[0086] Specifically, the DDK interface includes multiple API interfaces. For example, thread communication API interfaces, inter-process communication API interfaces, wait queue API interfaces, timer API interfaces, file access API interfaces, memory management API interfaces, and C library API interfaces, and so on.

[0087] According to an embodiment of the present disclosure, one or more test points are set for the API interface, or one or more test points are set for some of the multiple API interfaces.

[0088] In the present disclosure, test points are a series of test contents to ensure that aspects such as the function, performance, and security of the interface meet expectations. For example, interface response time test, resource occupancy test, security test, stability test, boundary value test, error handling test, and so on.

[0089] One or more test points can be set for an API interface, and one or more test points can also be set for some of the multiple API interfaces. For example, assume that all the test contents for the first API interface are: test content 1, test content 2, and test content 3, and all the test contents for the second API interface are: test content 4, test content 5, and test content 6. For the test of the first API interface, test content 1 and test content 2 can be set as one test point, test content 3 can be set as another test point, or test content 1, test content 2, and test content 3 can be set as one test point. For the test of the first API interface and the second API interface, test content 1 and test content 4 can be set as one test point, test content 2 and test content 5 can be set as one test point, test content 3 and test content 6 can be set as one test point, or test content 1-6 can be jointly set as one test point. Those skilled in the art should understand that the number and setting method of the test points are determined according to user requirements and are not technical means for limiting the protection scope of the present disclosure.

[0090] According to an embodiment of the present disclosure, the DDK interface includes the API interfaces of the necessary drivers and the API interfaces of the non-necessary drivers provided by the DDK to the lightweight operating system.

[0091] As described above, during the kernel startup process of the lightweight operating system, the necessary drivers (such as storage device drivers, display device drivers, basic input / output (I / O) device drivers) are first loaded, then the kernel is jumped to for kernel startup, and finally the non-necessary drivers (such as network device drivers, audio device drivers, drivers for peripherals such as printers) are loaded. The present disclosure can set test points for the API interfaces of the necessary drivers and the non-necessary drivers for testing, so that not only the API interfaces of the non-necessary drivers after kernel startup can be tested, but also the API interfaces of the necessary drivers before kernel startup can be tested, and the test scope is more comprehensive.

[0092] In step S202, a DDK interface test list header file is generated based on the DDK interface test list, and the DDK interface test list header file is saved in the DDK. The DDK interface test list header file is used to implement the reference to the multiple DDK unit test files.

[0093] Known header files are usually files with the extensions.h or.hpp. These files contain function declarations, macro definitions, etc., but do not contain specific function files. The form of the header file enables it to provide specific function files to other source files without saving the specific function files in the source files, thereby saving the storage space of the source files, reducing the coupling between the source files and the specific implementation function files, and promoting the reuse of the function files.

[0094] As Figure 3 shown, the DDK interface test list is set in the form of a header file. This DDK interface test list header file is used to implement references to multiple DDK unit test files included in the DDK interface test list, so that when the DDK interface test list header file is provided to other files, the multiple DDK unit test files can be referenced.

[0095] In step S203, a reference instruction is set in the board-level driver file, and the set board-level driver file is saved in the DDK. The reference instruction is used to reference the DDK interface test list header file in the set board-level driver file, so that the set board-level driver file can load the multiple DDK unit test files when executed.

[0096] In a specific implementation, a reference instruction is set at the beginning of the board-level driver file, so that when the set board-level driver file is executed, the DDK interface test list header file is referenced through this reference instruction, and then multiple DDK unit test files can be referenced, as Figure 3 shown.

[0097] In step S204, the set DDK is obtained. The set DDK includes the DDK interface test list header file and the set board-level driver file.

[0098] In step S205, the set DDK is compiled to obtain a first compiled DDK file.

[0099] Specifically, the DDK storing the DDK interface test list header file and the set board-level driver file is compiled to obtain a first compiled DDK file in binary form, so that when the first compiled DDK file is provided subsequently, the first compiled DDK file can be recognized by the lightweight operating system.

[0100] In step S206, the first compiled DDK file is provided to the lightweight operating system, so that the lightweight operating system can use the first compiled DDK file to perform automated tests on the DDK interface.

[0101] The present disclosure can not only implement automated testing, greatly improving the testing efficiency, but also verify all DDK interfaces provided for the lightweight operating system and all functions in the DDK interfaces. The testing scope is comprehensive, and the test content for the DDK interfaces can be modified as needed, flexibly adapting to the testing requirements of developers.

[0102] According to an embodiment of the present disclosure, interface test results are obtained from the startup log of the lightweight operating system, and the interface test results are the results obtained from the automated test of the DDK interface performed by the lightweight operating system.

[0103] Among them, the startup log of the operating system is generated during the system startup process, which records various events and status information during the process from the system power-on to the full startup. Since the automated test of the DDK interface performed by the lightweight operating system is executed during the kernel startup process, the interface test results will be recorded in the system startup log, and the automated test tool can directly obtain the interface test results of the DDK interface from this startup log.

[0104] According to an embodiment of the present disclosure, after obtaining the interface test results, the DDK interface test list header file and the set board-level driver file in the set DDK are deleted, and the set DDK is restored to the DDK; the DDK is compiled to obtain a second compiled DDK file; the second compiled DDK file is provided to the lightweight operating system so that the lightweight operating system can use the second compiled DDK file to implement system recovery.

[0105] Specifically, in order to avoid affecting the lightweight operating system after the test is completed during subsequent use, system recovery of the lightweight operating system is required. At this time, the automated test tool needs to delete the DDK interface test list header file and the set board-level driver file in the set DDK to obtain the DDK, then compile the DDK to obtain a second compiled DDK file, and provide this second compiled DDK file to the lightweight operating system to implement system recovery.

[0106] Figure 4 A logic block diagram showing an automated test method for the DDK interface provided for the DDK based on a lightweight operating system according to an embodiment of the present disclosure. The method includes steps S401 to S405:

[0107] According to an embodiment of the present disclosure, the lightweight operating system is applied to a chip, the kernel of the lightweight operating system is separated from the driver, and multiple test points are set for the DDK interface.

[0108] According to an embodiment of the present disclosure, the DDK interface includes multiple API interfaces.

[0109] According to an embodiment of the present disclosure, one or more test points are set for the API interface, or one or more test points are set for some of the multiple API interfaces.

[0110] According to an embodiment of the present disclosure, the test points are test scopes set for the registration function and / or non-registration function in the API interface.

[0111] Among them, the registration function is a function registered in the driver loaded during the kernel startup phase; the non-registration function is a function not registered in the driver loaded during the kernel startup phase.

[0112] In view of the situation that the functions of the loaded driver are incomplete during the registration phase, some functions may be subject to shutdown or function limitation processing. For this reason, the test mechanism of the present disclosure can not only effectively test the functions that have been successfully registered in the driver, but also test the partially closed or function-limited functions. This makes the test process more complete, thus ensuring the overall stability and reliability of the lightweight operating system.

[0113] According to an embodiment of the present disclosure, the loaded driver is an essential driver, or the loaded driver is an essential driver and a non-essential driver.

[0114] In a specific implementation manner, the chip may include a micro-control unit (MCU) in a smart meter, a control chip in an energy controller, a microprocessor in a concentrator, and so on.

[0115] In step S401, execute the first compiled DDK file using the upgrade driver command on the lightweight operating system, so that the lightweight operating system automatically restarts.

[0116] Among them, the first compiled DDK file is obtained by compiling the set DDK. The set DDK includes the set board-level driver file and the DDK test list header file. The DDK test list header file includes a DDK test unit list. The DDK test unit list corresponds to multiple DDK unit test files. The DDK unit test files are used to test the test points. The set board-level driver file includes a reference instruction, and the reference instruction is used to reference the DDK test list header file in the set board-level driver file.

[0117] Figure 5 Show Figure 4 The flowchart of the automatic restart of the lightweight operating system in the automated test method of the shown example is as Figure 5 shown, and the automatic restart includes steps S402 to S405.

[0118] In step S402, the chip is powered on.

[0119] In step S403, the lightweight operating system enters the boot phase, and an interrupt vector table is constructed during the boot phase.

[0120] The known interrupt vector table is a list of addresses used by the operating system to respond to interrupt requests, and each address points to the corresponding interrupt service routine (ISR). Therefore, the interrupt vector table is an essential part of the operating system, which allows the system to effectively respond to and process interrupts.

[0121] In step S404, after the interrupt vector table is built, the lightweight operating system enters the kernel startup phase.

[0122] In step S405, in the kernel startup phase, load the driver, execute the set board-level driver file, reference the DDK test list header file through the reference instruction in the set board-level driver file, and load the multiple DDK unit test files; call the hardware initialization function to execute the multiple DDK unit test files, test multiple test points set for the DDK interface, obtain the interface test result of the DDK interface, and save the interface test result in the startup log of the lightweight operating system.

[0123] Specifically, in the kernel startup phase, load the driver, execute the set board-level driver file, and reference the DDK test list header file through the reference instruction therein, so as to load multiple DDK unit test files in the set board-level driver file, so that when the hardware initialization function is called, the multiple loaded DDK unit test files can be executed to implement the test of multiple test points.

[0124] The present disclosure enables the lightweight operating system to perform automated tests on the DDK interface during the kernel startup phase and until the end of the non-essential driver loading process during the restart process by executing the compiled DDK file including the set board-level driver file in the lightweight operating system. The test range is wide, the test efficiency is high, and the test content is more flexible. At the same time, it can also implement batch testing of a large number of test points, further improving the test efficiency.

[0125] Figure 6 A structural block diagram of an automated test tool according to an embodiment of the present disclosure is shown. The automated test tool is used to implement automated tests on the DDK interface of the lightweight operating system. The automated test tool runs on a computer, and the DDK interface is provided by DDK for the lightweight operating system.

[0126] As Figure 6 shown, the automated test tool 600 includes: a first acquisition module 610, a generation module 620, a setting module 630, a second acquisition module 640, a first compilation module 650, and a providing module 660.

[0127] The first acquisition module 610 is configured to acquire a DDK interface test list according to user input. The DDK interface test list corresponds to multiple DDK unit test files, and the DDK unit test files are used to test corresponding test points among multiple test points set for the DDK interface;

[0128] The generation module 620 is configured to generate a DDK interface test list header file based on the DDK interface test list and save the DDK interface test list header file in the DDK. The DDK interface test list header file is used to implement the reference to the multiple DDK unit test files;

[0129] The setting module 630 is configured to set a reference instruction in the board-level driver file, save the set board-level driver file in the DDK. The reference instruction is used to reference the DDK interface test list header file in the set board-level driver file, so that the set board-level driver file can load the multiple DDK unit test files when executed;

[0130] The second acquisition module 640 is configured to acquire the set DDK. The set DDK includes the DDK interface test list header file and the set board-level driver file;

[0131] The first compilation module 650 is configured to compile the set DDK to obtain a first compiled DDK file;

[0132] The providing module 660 is configured to provide the first compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the first compiled DDK file to perform automated testing of the DDK interface.

[0133] According to an embodiment of the present disclosure, it further includes: a third acquisition module configured to obtain an interface test result from the startup log of the lightweight operating system. The interface test result is the result obtained by the lightweight operating system performing automated testing of the DDK interface.

[0134] According to an embodiment of the present disclosure, it further includes: a second compilation module configured to:

[0135] After obtaining the interface test result, delete the DDK interface test list header file and the set board-level driver file in the set DDK, restore the set DDK to the DDK; compile the DDK to obtain a second compiled DDK file; provide the second compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the second compiled DDK file to implement system recovery.

[0136] Figure 7 The structural block diagram of an automated test device for a DDK interface provided for a DDK based on a lightweight operating system according to an embodiment of the present disclosure is shown. The automated test device is applied to a lightweight operating system with separated kernel and drivers. The lightweight operating system is applied to a chip. Multiple test points are set for the DDK interface. The device 700 includes an automatic restart module 710, and the automatic restart module 710 includes a power-on module 720, a boot module 730, a kernel startup module 740, and a system recovery module 750.

[0137] The automatic restart module 710 is configured to: execute a first compiled DDK file using an upgrade driver command on the lightweight operating system, so that the lightweight operating system automatically restarts. Among them, the first compiled DDK file is obtained by compiling the set DDK. The set DDK includes a set board-level driver file and a DDK test list header file. The DDK test list header file includes a DDK test unit list. The DDK test unit list corresponds to multiple DDK unit test files. The DDK unit test files are used to test the test points. The set board-level driver file includes a reference instruction, and the reference instruction is used to reference the DDK test list header file in the set board-level driver file.

[0138] In the automatic restart module 710:

[0139] The power-on module 720 is configured to power on the chip;

[0140] The boot module 730 is configured to enable the lightweight operating system to enter the boot phase, and construct an interrupt vector table during the boot phase;

[0141] After the interrupt vector table is constructed, the kernel startup module 740 is configured to enable the lightweight operating system to enter the kernel startup phase; during the kernel startup phase, load the driver, execute the set board-level driver file, reference the DDK test list header file in the set board-level driver file through the reference instruction, and load the multiple DDK unit test files; call a hardware initialization function to execute the multiple DDK unit test files, test multiple test points set for the DDK interface, and obtain an interface test result of the DDK interface. The interface test result is saved in the startup log of the lightweight operating system.

[0142] The system recovery module 750 is configured to: after obtaining the interface test result of the DDK interface, execute a second compiled DDK file on the lightweight operating system using an upgrade driver command, so that the lightweight operating system is restarted again to achieve system recovery, where the second compiled DDK file is a file obtained by deleting the set board-level driver file and the DDK test list header file included in the set DDK and then compiling.

[0143] According to an embodiment of the present disclosure, the DDK interface includes a plurality of API interfaces.

[0144] According to an embodiment of the present disclosure, the first compiled DDK file and the second compiled DDK file are binary files.

[0145] The present disclosure also provides an automated test system for a DDK interface provided by a DDK for a lightweight operating system, which is characterized by including: the automated test tool as described above and the automated test device for the DDK interface provided by the DDK based on the lightweight operating system as described above.

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order from that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0147] The units or modules involved in the embodiments described in the present disclosure can be implemented in software or in a programmable hardware manner. The described units or modules can also be provided in a processor, and the names of these units or modules do not constitute a limitation to the units or modules themselves in some cases.

[0148] As another aspect, the present disclosure also provides a computer-readable storage medium, which may be the computer-readable storage medium included in the electronic device or computer system in the above embodiments; or it may exist separately and be a computer-readable storage medium not assembled into the device. The computer-readable storage medium stores one or more programs, and the one or more programs are used by one or more processors to execute the methods described in the present disclosure.

[0149] The above description is only a preferred embodiment of the present disclosure and an explanation of the applied technical principles. Those skilled in the art should understand that the scope of the invention involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above technical features, and should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the inventive concept. For example, the technical solutions formed by mutually replacing the above features with the technical features (but not limited to) having similar functions disclosed in the present disclosure.

Claims

1. A method for realizing automated testing of the DDK interface of a driver development kit for a lightweight operating system by using an automated testing tool, characterized in that The automated test tool runs on a computer, and the DDK interface is provided by the DDK for a lightweight operating system. The method includes using the automated test tool to perform the following steps: Obtain a DDK interface test list according to user input. The DDK interface test list corresponds to multiple DDK unit test files, and the DDK unit test files are used to test corresponding test points among multiple test points set for the DDK interface; Generate a DDK interface test list header file based on the DDK interface test list, and save the DDK interface test list header file in the DDK. The DDK interface test list header file is used to implement the reference to the multiple DDK unit test files; Set a reference instruction in the board-level driver file, and save the set board-level driver file in the DDK. The reference instruction is used to reference the DDK interface test list header file in the set board-level driver file, so that the set board-level driver file can load the multiple DDK unit test files when executed; Obtain the set DDK, where the set DDK includes the DDK interface test list header file and the set board-level driver file; Compile the set DDK to obtain a first compiled DDK file; Provide the first compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the first compiled DDK file to perform the automated test of the DDK interface.

2. The method according to claim 1, characterized in that It further includes: Obtain an interface test result from the startup log of the lightweight operating system. The interface test result is the result obtained by the lightweight operating system performing the automated test of the DDK interface.

3. The method according to claim 2, wherein It further includes: After obtaining the interface test result, delete the DDK interface test list header file and the set board-level driver file in the set DDK, and restore the set DDK to the DDK; Compile the DDK to obtain a second compiled DDK file; Provide the second compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the second compiled DDK file to implement system recovery.

4. The method according to claim 1, wherein: The DDK interface includes multiple application programming API interfaces; The multiple test points set for the DDK interface include: one or more test points set for the API interface, or one or more test points set for some of the multiple API interfaces; 5. The method according to claim 4, characterized in that, The DDK interface includes the API interfaces of the necessary drivers and the API interfaces of the non-necessary drivers provided by the DDK to the lightweight operating system; 6. An automated testing method for the DDK interface provided by the DDK based on a lightweight operating system, characterized in that, The lightweight operating system is applied to a chip, the kernel of the lightweight operating system is separated from the driver, and multiple test points are set for the DDK interface. The method includes: Execute the first compiled DDK file using the upgrade driver command on the lightweight operating system, causing the lightweight operating system to automatically restart. Among them, the first compiled DDK file is obtained by compiling the DDK after setting. The DDK after setting includes the set board-level driver file and the DDK test list header file. The DDK test list header file includes a DDK test unit list. The DDK test unit list corresponds to multiple DDK unit test files. The DDK unit test files are used to test the test points. The set board-level driver file includes a reference instruction. The reference instruction is used to reference the DDK test list header file in the set board-level driver file. The automatic restart includes: Power on the chip; The lightweight operating system enters the boot phase, and an interrupt vector table is constructed during the boot phase; After the construction of the interrupt vector table is completed, the lightweight operating system enters the kernel startup phase; During the kernel startup phase, load the driver, execute the set board-level driver file, reference the DDK test list header file in the set board-level driver file through the reference instruction, and load the multiple DDK unit test files; call the hardware initialization function to execute the multiple DDK unit test files, test multiple test points set for the DDK interface, obtain the interface test result of the DDK interface, and save the interface test result in the startup log of the lightweight operating system.

7. The method according to claim 6, wherein After obtaining the interface test result of the DDK interface, execute the second compiled DDK file using the upgrade driver command on the lightweight operating system, causing the lightweight operating system to restart again to achieve system recovery. Among them, the second compiled DDK file is obtained by deleting the set board-level driver file and the DDK test list header file included in the DDK after setting and then compiling.

8. The method according to claim 6, wherein: The DDK interface includes multiple API interfaces; Multiple test points are set for the DDK interface, including: setting one or more test points for the API interface, or setting one or more test points for some of the multiple API interfaces.

9. The method according to claim 8, wherein The test point is a test range set for the registration function and / or non-registration function in the API interface.

10. The method according to claim 9, wherein: The registration function is a function registered in the driver loaded during the kernel startup phase; The non-registration function is a function not registered in the driver loaded during the kernel startup phase.

11. The method according to claim 10, wherein The loaded driver is an essential driver, or the loaded driver is an essential driver and a non-essential driver.

12. An automated testing tool, which is used to implement automated testing of the DDK interface of a lightweight operating system, and is characterized in that, The automated test tool runs on a computer. The DDK interface is provided by DDK for the lightweight operating system. The automated test tool includes: A first acquisition module, configured to acquire a DDK interface test list according to user input, where the DDK interface test list corresponds to multiple DDK unit test files, and the DDK unit test files are used to test corresponding test points among multiple test points set for the DDK interface; A generation module, configured to generate a DDK interface test list header file based on the DDK interface test list and save the DDK interface test list header file in the DDK. The DDK interface test list header file is used to implement references to the multiple DDK unit test files; A setting module, configured to set a reference instruction in a board-level driver file and save the set board-level driver file in the DDK. The reference instruction is used to reference the DDK interface test list header file in the set board-level driver file, so that the set board-level driver file can load the multiple DDK unit test files when executed; A second acquisition module, configured to acquire the set DDK, where the set DDK includes the DDK interface test list header file and the set board-level driver file; A first compilation module, configured to compile the set DDK to obtain a first compiled DDK file; A provision module, configured to provide the first compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the first compiled DDK file to perform automated tests on the DDK interface.

13. The automated test tool according to claim 12, wherein It further includes: A third acquisition module, configured to acquire an interface test result from the startup log of the lightweight operating system, where the interface test result is the result obtained by the lightweight operating system performing automated tests on the DDK interface.

14. The automated test tool according to claim 13, wherein It further includes: A second compilation module, configured to: After acquiring the interface test result, delete the DDK interface test list header file and the set board-level driver file in the set DDK, and restore the set DDK to the DDK; Compile the DDK to obtain a second compiled DDK file; Provide the second compiled DDK file to the lightweight operating system, so that the lightweight operating system can use the second compiled DDK file to implement system restoration.

15. An automated test device for the DDK interface provided by the DDK based on a lightweight operating system, characterized in that, The automated test device is applied to a lightweight operating system with separated kernel and driver. The lightweight operating system is applied to a chip, and multiple test points are set for the DDK interface. The device includes: An automatic restart module, configured to execute a first compiled DDK file on the lightweight operating system using an upgrade driver command, so that the lightweight operating system automatically restarts, where the first compiled DDK file is obtained by compiling the DDK after setting, the DDK after setting includes a set board-level driver file and a DDK test list header file, the DDK test list header file includes a DDK test unit list, the DDK test unit list corresponds to multiple DDK unit test files, the DDK unit test files are used to test the test points, the set board-level driver file includes a reference instruction, and the reference instruction is used to reference the DDK test list header file in the set board-level driver file; The automatic restart module includes: A power-on module, configured to power on the chip; A boot module, configured to enter the boot phase of the lightweight operating system and build an interrupt vector table during the boot phase; A kernel startup module, configured to enter the kernel startup phase of the lightweight operating system after the interrupt vector table is built; during the kernel startup phase, load the driver, execute the set board-level driver file, reference the DDK test list header file in the set board-level driver file through the reference instruction, and load the multiple DDK unit test files; call the hardware initialization function to execute the multiple DDK unit test files, test multiple test points set for the DDK interface, obtain an interface test result of the DDK interface, and save the interface test result in the startup log of the lightweight operating system.

16. The device according to claim 15, characterized in that, It further includes: A system recovery module, configured to: After obtaining the interface test result of the DDK interface, execute a second compiled DDK file on the lightweight operating system using an upgrade driver command, so that the lightweight operating system restarts again to achieve system recovery, where the second compiled DDK file is a file obtained by deleting the set board-level driver file and the DDK test list header file included in the DDK after setting and then compiling.

17. The device according to claim 15, wherein: The DDK interface includes multiple API interfaces; The first compiled DDK file is a binary file.

18. An automated test system for the DDK interface provided by DDK for lightweight operating systems, characterized in that, It includes: The automated test tool according to any one of claims 12 to 14 and the device according to any one of claims 15 to 17.

19. A computer-readable storage medium having computer instructions stored thereon, characterized in that, When the computer instruction is executed by a processor, it implements the method according to any one of claims 1 to 11.

20. A computer program product, including a computer instruction, which implements the method according to any one of claims 1 to 11 when executed by a processor.

Images