Module test case generation method and device, electronic device, and storage medium

Abstract

The application relates to a module test case generation method and device, an electronic device and a storage medium, wherein the module test case generation method comprises the following steps: obtaining an engineering configuration file from an operating system; wherein the engineering configuration file is a configuration information file automatically generated by the operating system after creating an engineering; obtaining parameter information of a to-be-tested module and supported function interfaces of the to-be-tested module from the engineering configuration file; and generating a test case for the to-be-tested module according to the parameter information of the to-be-tested module and the supported function interfaces. Through the application, the problems that a test personnel manually modifies or increases test parameters in a script to generate a corresponding test case in the prior art, modification is tedious, code maintenance is difficult and the like are solved, the effect of automatically generating a test case is achieved, the generation efficiency of the test case is improved, and the work difficulty and workload of the test personnel are reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of Internet of Things operating system testing, in particular to a module test case generation method and device, an electronic device and a storage medium. BACKGROUND

[0002] The module connection kit (MoLink) realizes unified control of different communication modules through architecture design and module adaptation, and provides a unified API interface to the upper layer framework and application, so that the developer can complete the development of network-related applications without having to care about the differences between different modules. At the same time, the MoLink component design is compatible with the OpenCPU development mode of the communication module, greatly improving the portability of the user program, and the wireless networking function of the application program can be seamlessly switched between the AT mode and the OpenCPU mode. The MoLink component will adapt to a large number of wireless communication modules in the later stage, so that users can conveniently select module models according to actual needs and easily configure and switch.

[0003] The module connection kit currently supports more than 20 module models. The supported functions also include module creation and destruction, module and signal information reading, data transmission and reception, network setting, etc., and the test cases have reached more than 100. Different module communication parameters and supported functions are not the same. Therefore, the test of different modules needs to manually modify the test cases in the script. In addition, if you want to modify some parameters of the test or delete some test cases of the module, you also need to manually modify the test script.

[0004] Secondly, as a special mode, the OpenCPU development mode has a different kernel version from the normal version, which leads to the need to design a new set of test cases for OpenCPU. The Molink stability test is different from the normal function test case, and needs to test the test case according to the time and count the success rate, so another set of test cases will be designed. In this way, in addition to the module difference, the test cases need to maintain three sets, which increases the workload of the test personnel in designing and maintaining the test cases.

[0005] Finally, the previous test cases contain the code of all functions, and for different modules and test functions, the code is reduced through conditional compilation (or shielding). In this way, the program code is still retained in the file, which makes the test case redundant and difficult to locate.

[0006] Due to the particularity of the Internet of Things operating system module connection kit adapting to multiple modules, multiple kernels and multiple functions, manual modification of test cases in the script by artificial labor is tedious and difficult to maintain the code, and there is currently no effective solution. SUMMARY

[0007] A module test case generation method and device, an electronic device, and a storage medium are provided in this embodiment to address the problems of tedious modification and difficult code maintenance of manually modifying test cases in scripts in related technologies.

[0008] In a first aspect, a module test case generation method is provided in this embodiment, which includes:

[0009] obtaining an engineering configuration file from an operating system, wherein the engineering configuration file is a configuration information file automatically generated by the operating system after creating an engineering;

[0010] obtaining parameter information of a module to be tested and a supported function interface thereof from the engineering configuration file;

[0011] generating a test case for the module to be tested according to the parameter information of the module to be tested and the supported function interface thereof.

[0012] In some embodiments, the parameter information includes a first communication parameter and a second communication parameter.

[0013] The engineering configuration file includes a first communication keyword.

[0014] The obtaining of the parameter information of the module to be tested and the supported function interface thereof from the engineering configuration file includes:

[0015] parsing the engineering configuration file to obtain the first communication parameter related to the first communication keyword in the module to be tested;

[0016] obtaining a name of the module to be tested from the engineering configuration file, and obtaining a header file of the module to be tested according to the name of the module to be tested;

[0017] parsing the header file of the module to be tested to obtain the second communication parameter of the module to be tested.

[0018] In some embodiments, the engineering configuration file includes a second communication keyword.

[0019] The obtaining of the parameter information of the module to be tested and the supported function interface thereof from the engineering configuration file includes:

[0020] parsing the engineering configuration file to determine a target communication function corresponding to the second communication keyword, wherein the target communication function is a communication function supported by the module to be tested;

[0021] obtaining a name of the module to be tested from the engineering configuration file, and obtaining a source file of the module to be tested according to the name of the module to be tested;

[0022] obtaining a target structure from a source file of the module to be tested according to the target communication function;

[0023] determining a function interface supported by the module to be tested according to the target structure.

[0024] In some embodiments, the generating the test case for the module to be tested according to the parameter information of the module to be tested and the function interface supported by the module to be tested comprises:

[0025] generating test information of a general test and test information of a stability test of the module to be tested respectively according to the parameter information of the module to be tested and the function interface supported by the module to be tested;

[0026] generating the test case for the module to be tested according to the test information of the general test and the test information of the stability test.

[0027] In some embodiments, the generating the test case for the module to be tested according to the test information of the general test and the test information of the stability test comprises:

[0028] generating test code of the general test according to the test information of the general test, and generating test code of the stability test according to the test information of the stability test;

[0029] generating the test case for the module to be tested based on the test code of the general test and the test code of the stability test.

[0030] In some embodiments, the method further comprises:

[0031] determining a current kernel version of the operating system according to the kernel version difference in the engineering configuration file;

[0032] obtaining a test parameter of the stability test input by a user;

[0033] The generating the test code of the general test according to the test information of the general test, and the generating the test code of the stability test according to the test information of the stability test comprises:

[0034] generating the test code of the general test according to the test information of the general test and the current kernel version of the operating system;

[0035] generating the test code of the stability test according to the test information of the stability test and the test parameter of the stability test.

[0036] In some embodiments, the method further comprises:

[0037] visualize the functions supported by the module to be tested;

[0038] determine the function to be tested from the functions supported by the module to be tested in response to a selection instruction input by a user;

[0039] The test case for the module to be tested is generated according to the parameter information of the module to be tested and the function interface supported by the module to be tested.

[0040] The test case for the module to be tested is generated according to the function interface and the parameter information of the function to be tested of the module to be tested.

[0041] In a second aspect, a module test case generation device is provided in the embodiment, and the device comprises:

[0042] A file acquisition module is configured to acquire an engineering configuration file from an operating system, wherein the engineering configuration file is a configuration information file automatically generated by the operating system after an engineering is created.

[0043] An information acquisition module is configured to acquire parameter information of a module to be tested and a function interface supported by the module to be tested from the engineering configuration file.

[0044] A case generation module is configured to generate a test case for the module to be tested according to the parameter information of the module to be tested and the function interface supported by the module to be tested.

[0045] In a third aspect, an electronic device is provided in the embodiment, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the module test case generation method of the first aspect when executing the computer program.

[0046] In a fourth aspect, a storage medium is provided in the embodiment, and the storage medium stores a computer program executable by a processor, and the computer program implements the module test case generation method of the first aspect when executed by the processor.

[0047] Compared with the related art, the module test case generation method provided in the embodiment can automatically parse an engineering configuration file in an operating system by a test device, automatically acquire parameter information of a module to be tested and a function interface supported by the module to be tested from the engineering configuration file, and further quickly and conveniently generate a corresponding test case, thereby solving the problem that a test personnel manually modifies or increases test parameters in a script to generate a corresponding test case in the prior art, and the problems of complicated modification, difficult code maintenance, and the like are solved, the effect of automatically generating a test case is achieved, the generation efficiency of the test case is improved, and the work difficulty and workload of the test personnel are reduced.

[0048] The details of one or more embodiments of the application are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the application will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF DRAWINGS

[0049] The accompanying drawings are included to provide a further understanding of the application, and are incorporated in and constitute a part of this application, illustrate embodiments of the application, and explain them, which do not constitute an inappropriate limitation to the application. In the drawings:

[0050] Figure 1 is a hardware structure block diagram of a terminal of the module test case generation method of the embodiment.

[0051] Figure 2 is a flow chart of the module test case generation method of the embodiment.

[0052] Figure 3 is a flow chart of the module test case generation method of the preferred embodiment.

[0053] Figure 4 is a structure block diagram of the module test case generation device of the embodiment. DETAILED DESCRIPTION

[0054] In order to more clearly understand the objects, technical solutions and advantages of the application, the application is described and explained below in combination with the drawings and embodiments.

[0055] Unless otherwise defined, technical terms or scientific terms used in the present application shall have the same meaning as those commonly understood by a person of ordinary skill in the art to which the present application belongs. The terms "one", "a", "an", "the", "these", and similar terms in the present application do not mean "only one" or "exactly one", but can mean "one or more". The terms "include", "contain", "have", and any variant thereof in the present application are intended to cover the non-exclusive inclusion; for example, a process, method, and system, product or device containing a series of steps or modules (units) are not limited to the listed steps or modules (units), but can include steps or modules (units) not listed, or can include other steps or modules (units) inherent to the process, method, product or device. The terms "connect", "connect", "couple" and the like in the present application are not limited to physical or mechanical connection, but can include electrical connection, whether direct or indirect. The term "multiple" in the present application means two or more. The term "and / or" describes the association between the associated objects, which means that there can be three relationships, for example, "A and / or B" can mean that A exists alone, A and B exist together, and B exists alone. Generally, the character " / " represents the relationship between the objects before and after the connection is "or". The terms "first", "second", "third" and the like in the present application are only used to distinguish similar objects, and do not represent a specific order of the objects.

[0056] The method embodiments provided in the present embodiment can be executed in a terminal, a computer or a similar computing device. For example, the method embodiments are executed on a terminal, Figure 1 is a hardware structure block diagram of the terminal of the module test case generation method of the present embodiment. As shown in Figure 1 , the terminal can include one or more (only one is shown in Figure 1 ) processor 102 and memory 104 for storing data, wherein the processor 102 can include but not limited to processing device such as microprocessor MCU or programmable logic device FPGA. The above terminal can also include transmission device 106 for communication function and input / output device 108. Those skilled in the art can understand that Figure 1 The structure shown is only schematic, which does not limit the structure of the above terminal. For example, the terminal can include more or less components than Figure 1 shown, or have a different configuration from Figure 1 shown.

[0057] The memory 104 can be used to store computer programs, such as software programs of application software and modules, such as the computer program corresponding to the module test case generation method in the embodiment. The processor 102 can execute various functional applications and data processing, i.e., implement the method described above, by running the computer programs stored in the memory 104. The memory 104 can include a high-speed random access memory, and can further include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 104 can further include memories remotely arranged with respect to the processor 102, which can be connected to the terminal through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0058] The transmission device 106 is configured to receive or send data via a network. The network includes a wireless network provided by a communication provider of the terminal. In an example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In an example, the transmission device 106 can be a radio frequency (RF) module, which is configured to communicate with the Internet in a wireless manner.

[0059] In the embodiment, a module test case generation method is provided, Figure 2 A flowchart of the module test case generation method of the embodiment is shown in FIG. 2, which includes the following steps: Figure 2

[0060] In step S210, an engineering configuration file is obtained from an operating system; the engineering configuration file is a configuration information file automatically generated by the operating system after creating an engineering.

[0061] In this step, the test device automatically obtains the engineering configuration file from the operating system. Specifically, the test device finds the configuration header file "oneos_config.h" through the storage relative path of the file, and the configuration header file is the engineering configuration file required in this step, which is a configuration information file automatically generated by OneOS (China Mobile Internet of Things operating system) after creating an engineering. The configuration information file mainly includes kernel, C library, driver, component, and other related configuration information. The related configuration information of the component includes module information, and the module information includes parameter information of the module and supported functions. In this embodiment, the module information of the module to be tested in the engineering configuration file is obtained by analyzing the engineering configuration file.

[0062] ​Step S220, obtaining the parameter information of the module to be tested and the supported function interface from the engineering configuration file.

[0063] In this step, after obtaining the engineering configuration file, the test device obtains the parameter information of the module to be tested and the supported function interface from the engineering configuration file by parsing the engineering configuration file. It needs to be further explained that the parameter information of the module and the supported function interface can be identified and confirmed by the keywords existing in the engineering configuration file. Different modules correspond to different keywords. Therefore, in the process of parsing the engineering configuration file, the parameter information of the module to be tested and the supported function interface can be determined by identifying the keywords related to the module to be tested.

[0064] Step S230, generating the test case for the module to be tested according to the parameter information of the module to be tested and the supported function interface.

[0065] In this step, the test device generates the test case for the module to be tested according to the supported function interface and the parameter information of the module to be tested. It needs to be explained that the key to generating the test case is to obtain the parameter information of the module to be tested and the supported function interface. In this embodiment, the test device automatically parses the engineering configuration file in the operating system, automatically obtains the parameter information of the module to be tested and the supported function interface from the engineering configuration file, and then can quickly and conveniently generate the corresponding test case. It is further explained that in the process of generating the test case, the test case for all functions in the module to be tested can be generated by default; or the test case for the selected functions in the module to be tested can be generated according to the selection of the test personnel. The function interface and the function are corresponding to each other, so the test personnel selects from the functions supported by the module to be tested, and the test device generates the corresponding test case according to the selected function interface and the parameter information.

[0066] Through the above steps, the test device automatically parses the engineering configuration file in the operating system, automatically obtains the parameter information of the module to be tested and the supported function interface from the engineering configuration file, and then can quickly and conveniently generate the corresponding test case. Compared with the prior art in which the test personnel manually modifies or increases the test parameters in the script to generate the corresponding test case, the method in this embodiment is more simple and convenient, the test device automatically obtains the test parameters required by the test case from the engineering configuration file, so as to automatically generate the related test case. The generation efficiency of the test case is greatly improved, and the work efficiency of the test personnel is greatly reduced.

[0067] In some embodiments, the parameter information includes a first communication parameter and a second communication parameter, and the engineering configuration file includes a first communication keyword.

[0068] Step S220, obtaining the parameter information of the to-be-tested module and the supported function interfaces from the engineering configuration file, specifically including:

[0069] Step S221, parsing the engineering configuration file to obtain the first communication parameter related to the first communication keyword in the to-be-tested module;

[0070] Step S222, obtaining the name of the to-be-tested module from the engineering configuration file, and obtaining the header file of the to-be-tested module according to the name of the to-be-tested module;

[0071] Step S223, parsing the header file of the to-be-tested module to obtain the second communication parameter of the to-be-tested module.

[0072] Specifically, in the embodiment, a specific process of obtaining the parameter information of the to-be-tested module from the engineering configuration file is provided. The parameter information of the to-be-tested module is mainly composed of two parts of communication parameters. Among them, the first communication parameter is directly obtained in the engineering configuration file, and the second communication parameter is obtained from the header file of the to-be-tested module. Specifically, the first communication keyword corresponding to the to-be-tested module exists in the engineering configuration file, and the first communication parameter is the parameter set through the first communication keyword. Therefore, the first communication parameter can be obtained by identifying these first communication keywords. Among them, different modules have different first communication keywords, so the test equipment can identify the first communication keyword of the to-be-tested module according to the difference between different modules. As for the second communication parameter, first, the engineering configuration file is parsed to find the module name of the to-be-tested module, and the folder of the corresponding module source code is found in the engineering directory; then the header file (the file with.h as the suffix) corresponding to the to-be-tested module is found under the folder; finally, the second communication parameter is obtained by parsing the header file.

[0073] Exemplarily, the first communication keyword includes the module creation mode (ESP8266_AUTO_CREATE), the module communication parameter (ESP8266_DEVICE_NAME, ESP8266_DEVICE_RATE, ESP8266_RECV_BUFF_LEN), the WiFi access configuration information (optional configuration) (ESP8266_CONNECT_SSID, ESP8266_CONNECT_PASSWORD) and the like. Correspondingly, the header file also has a keyword corresponding to the second communication parameter, for example, the keyword can be ESP8266_NETCONN_NUM.

[0074] In some embodiments, the second communication keyword is included in the engineering configuration file;

[0075] In step S220, the parameter information of the module to be tested and the supported function interfaces are obtained from the engineering configuration file, and specifically include:

[0076] In step S224, the engineering configuration file is parsed to determine the target communication function corresponding to the second communication keyword; the target communication function is the communication function supported by the module to be tested.

[0077] In step S225, the name of the module to be tested is obtained from the engineering configuration file, and the source file of the module to be tested is obtained according to the name of the module to be tested.

[0078] In step S226, the target structure is obtained from the source file of the module to be tested according to the target communication function.

[0079] In step S227, the function interface supported by the module to be tested is determined according to the target structure.

[0080] Specifically, in this embodiment, a specific process for determining the function interface supported by the module to be tested from the engineering configuration file is provided. First, the communication function supported by the module to be tested needs to be determined, and the communication function supported by the module to be tested corresponds to the second communication keyword contained in the engineering configuration file. For example, if the engineering configuration file contains three second communication keywords, then the module to be tested supports three communication functions corresponding to the three second communication keywords. Then the engineering configuration file is parsed to find the module name of the module to be tested, find the folder of the corresponding module source code in the engineering directory, and find the source file (file ending with.c) corresponding to the module to be tested under the folder. Then, from all the structures contained in the source file, the target structure corresponding to the communication function supported by the module to be tested is screened out, wherein the communication function and the structure have a corresponding relationship. Finally, based on the target structure, the specific function interface supported by the module to be tested is obtained.

[0081] Exemplarily, the second communication keyword is mainly an identifier defined by the OneOS system, through which the module functions are classified. For example, Socket function, Wifi function, etc. The defined identifiers include MOLINK_USING_GENERAL_OPS (general operation), MOLINK_USING_PING_OPS (Ping operation), MOLINK_USING_IFCONFIG_OPS (ifconfig operation), MOLINK_USING_SOCKETS_OPS (socket operation), MOLINK_USING_WIFI_OPS (wifi operation), MOLINK_USING_NETCONN_OPS (Netconn connection operation), etc. By judging whether the above-mentioned keyword information is contained in the engineering configuration file, it is determined whether the to-be-tested module supports the corresponding communication function. The structure bodies in the source file include gs_general_op (general operation function structure body), gs_netserv_ops (network operation function structure body), gs_ifconfig_ops (ifconfig operation function structure body), gs_netconn_ops (Netconn connection operation function structure body), gs_wifi_ops (wifi operation function structure body), etc.

[0082] In some embodiments, step S230, according to the parameter information of the to-be-tested module and the supported function interfaces thereof, a test case for the to-be-tested module is generated, specifically including:

[0083] Step S231, according to the parameter information of the to-be-tested module and the supported function interfaces thereof, test information for the regular test and the stability test of the to-be-tested module is respectively generated.

[0084] Step S232, according to the test information of the regular test and the test information of the stability test, a test case for the to-be-tested module is generated.

[0085] Specifically, the test case is composed of two parts, one part is the test information of the regular test, and the other part is the test information of the stability test. Among them, the regular test is a direct test of the communication function supported by the to-be-tested module, and the stability test is a composite test of the communication function supported by the to-be-tested module, that is, a comprehensive communication function formed by combining multiple single communication functions is tested. In the previous steps, the parameter information of the to-be-tested module and the supported function interfaces thereof have been automatically acquired by the test device, and then based on these information, the test information for the regular test and the stability test of the to-be-tested module can be respectively generated.

[0086] In a further embodiment, step S232, generating the test case of the module to be tested according to the test information of the routine test and the test information of the stability test, specifically includes:

[0087] Step S2321, generating the test code of the routine test according to the test information of the routine test, and generating the test code of the stability test according to the test information of the stability test;

[0088] Step S2322, generating the test case of the module to be tested based on the test code of the routine test and the test code of the stability test.

[0089] Specifically, the test case is a piece of test code, so first the test code of the routine test is generated through the test information of the routine test, and the test code of the stability test is generated through the test information of the stability test, and finally the two pieces of code are combined to generate a complete test case.

[0090] In a specific embodiment, the module test case generation method further includes:

[0091] Step S240, determining the current kernel version of the operating system according to the kernel version difference points in the engineering configuration file.

[0092] Step S250, obtaining the test parameters of the stability test input by the user.

[0093] Specifically, in the process of generating the test code of the routine test, the current kernel version of the operating system also needs to be determined, so as to generate test code matching the current kernel version. Therefore, in the method of this embodiment, the current kernel version of the operating system is also determined according to the engineering configuration file. For example, the engineering configuration file has different kernel parameter definition segments for different kernel versions, so the current kernel version can be determined according to the kernel parameter definition segment. Illustratively, the current kernel version can be determined by judging whether there is a macro definition of the time slice parameter "OS_SCHEDULE_TIME_SLICE" in the kernel parameter definition segment, so as to generate test code suitable for different kernels.

[0094] And in the stability test process, the test code of the stability test also needs test parameters input by the test personnel, such as test duration, data size, etc.

[0095] Therefore, step S2321, generating the test code of the routine test according to the test information of the routine test, and generating the test code of the stability test according to the test information of the stability test, specifically includes:

[0096] generating the test code of the routine test according to the test information of the routine test and the current kernel version of the operating system;

[0097] The test code of the stability test is generated according to the test information of the stability test and the test parameter of the stability test.

[0098] Specifically, in the generation of the test code, the test code of the regular test is generated according to the test information of the regular test and the current kernel version, and the test code of the stability test is generated according to the test information of the stability test and the test parameter input by the tester.

[0099] In some of the embodiments, the module test case generation method further includes:

[0100] In step S260, the communication functions supported by the to-be-tested module are visualized.

[0101] In step S270, the to-be-tested function is determined from the communication functions supported by the to-be-tested module in response to the selection instruction input by the user.

[0102] In step S230, the test case for the to-be-tested module is generated according to the parameter information of the to-be-tested module and the function interface supported thereby, specifically including:

[0103] The test case for the to-be-tested module is generated according to the function interface and the parameter information of the to-be-tested function of the to-be-tested module.

[0104] Specifically, in this embodiment, after the test device determines the parameter information of the to-be-tested module and the function interface supported thereby, the test device also visualizes the communication functions supported by the to-be-tested module, so that the tester can select the communication function to be tested therefrom; then the function to be tested is determined in response to the selection instruction input by the tester, and finally the corresponding test case is generated based on the function interface and the parameter information of the function to be tested. It should be noted that the module test includes two types of regular test and stability test. For the regular test, the communication functions supported by the to-be-tested module are directly visualized, while for the stability test, the stability functions formed by the combination of multiple single communication functions are visualized. Exemplarily, the stability function test includes big data test, long time test and multi-thread test, etc.

[0105] It should be noted that the steps shown in the above flow or the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that here. For example, step S270 is to be executed before step S230.

[0106] The technical solutions in the present application will be described below through specific preferred embodiments.

[0107] Figure 3is a flow chart of the module test case generation method of the preferred embodiment. As shown in FIG. 3, the module test case generation method of the preferred embodiment includes the following steps:

[0108] Step S1, obtaining the project configuration file from the operating system.

[0109] Specifically, the configuration header file "oneos_config.h" is found through the relative path, which is the project configuration file. The project configuration file is a configuration information file automatically generated by OneOS after creating a project. It mainly contains kernel, C library, driver, component, and other related configuration information. The technical solution mainly identifies part of the characteristic values in the kernel and component configurations to identify the corresponding software version and module information.

[0110] Step S2, determining the current kernel version of the operating system according to the kernel version difference points in the project configuration file.

[0111] Specifically, the project configuration file in step S1 is parsed, and the current kernel version is determined according to the kernel version difference points (such as whether the macro definition of the time slice parameter "OS_SCHEDULE_TIME_SLICE" exists in the kernel parameter definition section), and the test code suitable for different kernels is selected.

[0112] Step S3, obtaining the first communication parameter of the module to be tested and the supported function interface from the project configuration file.

[0113] Specifically, the project configuration file in step S1 is read to obtain the related parameters of the module and the project (different modules have different variable names), such as:

[0114] A. By parsing whether the configuration file contains keyword information such as MOLINK_USING_GENERAL_OPS, MOLINK_USING_PING_OPS, MOLINK_USING_IFCONFIG_OPS, MOLINK_USING_NETCONN_OPS, MOLINK_USING_SOCKETS_OPS, and MOLINK_USING_WIFI_OPS, it can be known whether the module supports the test of related functions.

[0115] B, by analyzing the configuration file ESP8266_AUTO_CREATE, ESP8266_DEVICE_NAME, ESP8266_DEVICE_RATE, ESP8266_RECV_BUFF_LEN, ESP8266_CONNECT_SSID, ESP8266_CONNECT_PASSWORD and other keywords set parameters (keywords with engineering configuration module is different, the parameters obtained here are the first communication parameters), the module is created and the related information of communication is stored in the structure required for generating test script.

[0116] Step S4, get the module name of the module to be tested from the engineering configuration file.

[0117] Specifically, the engineering configuration file in step S1 is parsed, the module name of the module to be tested is found, and the folder of the corresponding module source code is found in the engineering directory.

[0118] Step S5, according to the name of the module to be tested, get the header file and source file of the module to be tested.

[0119] Specifically, in the source code folder path of step S4, the source file (.c) and header file (.h) corresponding to the module are found.

[0120] Step S6, according to the communication function supported by the module to be tested, get the target structure from the source file, and get the second communication parameter of the module to be tested from the header file.

[0121] Specifically, according to the supported functions parsed in part A of step S3, the structure corresponding to the supported function is found in the source file (.c) queried in step S5. For example: gs_general_op, gs_netserv_ops, gs_ifconfig_ops, gs_netconn_ops, gs_wifi_ops and other structures (the number of structures is different for different modules). Then parse the part of the parameter (the second communication parameter) of the module communication in the header file (.h) queried in step S5, such as ESP8266_NETCONN_NUM.

[0122] Step S7, get the function interface supported by the module to be tested, and visualize the communication function supported by the module to be tested.

[0123] Specifically, the structure selected in step S6 is parsed to obtain the function interface specifically supported by the module. And display the function supported by the module in the test tool.

[0124] Step S8, in response to the selection instruction input by the user, determine the function to be tested from the communication function supported by the module to be tested.

[0125] Specifically, in the support function displayed in step S7, the function required for testing is determined in response to the selection instruction of the tester.

[0126] Step S9, the test information of the general test of the module to be tested is generated according to the parameter information of the module to be tested and the supported function interface.

[0127] Specifically, the test information of the general test of the module is generated according to the parameters obtained in step S3, the parameters obtained in step S6, and the function interface determined in step S8.

[0128] Step S10, the test information of the stability test of the module to be tested is generated according to the parameter information of the module to be tested and the supported function interface.

[0129] Specifically, the same as step S9, the test information related to the stability test of the module is generated based on the parameters and function interfaces obtained in steps S1 to S8, and the stability test function required is determined in response to the selection instruction of the tester.

[0130] Step S11, the test parameters of the stability test input by the user are obtained.

[0131] Specifically, the parameters of the corresponding function of the stability test input by the tester are accepted. Specifically, the tester needs to manually configure the parameters of the corresponding function of the stability test in the test tool, such as test duration, data size, etc.

[0132] Step S12, the test code of the stability test is generated according to the test information of the stability test and the test parameters of the stability test.

[0133] Specifically, the test code related to the stability test of the module is generated according to the results of steps S10 and S11.

[0134] Step S13, the test code of the general test is generated according to the test information of the general test and the current kernel version of the operating system.

[0135] Specifically, the test code related to the general test of the module is generated according to the results of steps S2 and S9.

[0136] Step S14, the test case of the module to be tested is generated based on the test code of the general test and the test code of the stability test.

[0137] Specifically, the complete test case is generated by combining the code contents of steps S12 and S13.

[0138] The following describes a method for using the test tool corresponding to the module test case generation method. The test tool has an instruction input button for reading configuration and generating a test case, and can display supported functions, so the user can select the function to be tested.

[0139] Step a: The tester clicks "read configuration", and if the module information is successfully queried, the module related information is displayed at the position; if the module information is not queried, an error is reported at the position.

[0140] Step b: After reading the module information in step a, the test cases supported by the module are displayed at the position, and the required test function is selected (the default is to select all the regular test functions).

[0141] Step c: Click "generate test case" to generate the test case related to the tested function.

[0142] In this embodiment, a module test case generation device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and will not be described again. The terms "module", "unit", "sub-unit" and the like used below can be a combination of software and / or hardware that can implement a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware can also be implemented and conceived.

[0143] Figure 4 The structure block diagram of the module test case generation device of this embodiment is shown in FIG. 4, which includes: Figure 4

[0144] The file acquisition module 410 is configured to acquire the engineering configuration file from the operating system; wherein the engineering configuration file is a configuration information file automatically generated by the operating system after creating the project;

[0145] The information acquisition module 420 is configured to acquire the parameter information of the module to be tested and the supported function interface from the engineering configuration file;

[0146] The test case generation module 430 is configured to generate the test case for the module to be tested according to the parameter information of the module to be tested and the supported function interface.

[0147] ​Through cooperation between the above modules, the test device can automatically parse the engineering configuration file in the operating system, automatically obtain parameter information of the module to be tested and supported function interfaces from the engineering configuration file, and further quickly and conveniently generate the corresponding test case. Compared with the prior art in which a test personnel manually modifies or increases test parameters in a script to generate a corresponding test case, the method in the embodiment is more simple and convenient, and the test device automatically obtains test parameters required by the test case from the engineering configuration file, thereby automatically generating the related test case. The generation efficiency of the test case is greatly improved, and the work efficiency of the test personnel is greatly reduced.

[0148] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For the modules implemented by hardware, the above modules can be located in the same processor; or the above modules can also be located in different processors in any combination.

[0149] In the embodiment, an electronic device is also provided, including a memory and a processor, the memory stores a computer program, and the processor is configured to execute the computer program to perform the steps in any of the above method embodiments.

[0150] Optionally, the electronic device can further include a transmission device and an input / output device, wherein the transmission device is connected with the processor, and the input / output device is connected with the processor.

[0151] It should be noted that the specific examples in the embodiment can refer to the examples described in the above embodiments and optional implementation manners, which will not be described herein again.

[0152] In addition, in combination with the module test case generation method provided in the above embodiments, a storage medium can also be provided to implement the method in the embodiment. The storage medium stores a computer program; and the computer program is executed by a processor to implement any of the module test case generation methods in the above embodiments.

[0153] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties.

[0154] It should be understood that the specific embodiments described herein are only used to explain the application, but not to limit it. According to the embodiments provided in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor are within the scope of protection of the present application.

[0155] It is apparent that the drawings depicted are only a few example embodiments of the present application and that a person of ordinary skill in the art can further apply the present application to any other analogous situations without paying creative effort, based on these drawings. In addition, it is understood that although the work done in the development process can be complex and long, certain design, manufacture or production changes made according to the technical content disclosed in the present application by a person of ordinary skill in the art are only routine technical means and should not be regarded as insufficient disclosure of the present application.

[0156] The word "embodiment" in the present application means that the specific features, structures or characteristics described in conjunction with the embodiments can be included in at least one embodiment of the present application. The presence of this phrase in various places in the specification does not necessarily mean the same embodiment, nor does it mean independence or alternatives to other embodiments. It is clear or implicitly understood by a person of ordinary skill in the art that the embodiments described in the present application can be combined with other embodiments without conflict.

[0157] The above-described embodiments only express several implementation manners of the present application, which are described in detail and specifically, but should not be understood as a limitation on the scope of patent protection. It should be noted that a person of ordinary skill in the art can make several modifications and improvements without departing from the concept of the present application, which are all within the scope of protection of the present application. Therefore, the scope of protection of the present application should be subject to the appended claims.

Claims

1. A method for generating test cases for a module, the method comprising: The method is applied to an Internet of Things operating system module connection kit, and comprises the following steps: obtaining an engineering configuration file from an operating system, wherein the engineering configuration file is a configuration information file automatically generated by the operating system after creating an engineering; obtaining parameter information of a to-be-tested module and a supported function interface of the to-be-tested module from the engineering configuration file; generating a test case for the to-be-tested module according to the parameter information of the to-be-tested module and the supported function interface of the to-be-tested module; the parameter information comprises first communication parameters and second communication parameters; the engineering configuration file comprises a first communication keyword; the step of obtaining the parameter information of the to-be-tested module and the supported function interface of the to-be-tested module from the engineering configuration file comprises the following steps: parsing the engineering configuration file to obtain the first communication parameters of the to-be-tested module related to the first communication keyword; obtaining the name of the to-be-tested module from the engineering configuration file, and obtaining the header file of the to-be-tested module according to the name of the to-be-tested module; and parsing the header file of the to-be-tested module to obtain the second communication parameters of the to-be-tested module; the engineering configuration file comprises a second communication keyword; the step of obtaining the parameter information of the to-be-tested module and the supported function interface of the to-be-tested module from the engineering configuration file comprises the following steps: parsing the engineering configuration file to determine a target communication function corresponding to the second communication keyword; wherein the target communication function is a communication function supported by the to-be-tested module; obtaining the name of the to-be-tested module from the engineering configuration file, and obtaining the source file of the to-be-tested module according to the name of the to-be-tested module; obtaining a target structure from the source file of the to-be-tested module according to the target communication function; and determining the function interface supported by the to-be-tested module according to the target structure.

2. The module test case generation method of claim 1, wherein, the step of generating the test case for the to-be-tested module according to the parameter information of the to-be-tested module and the supported function interface of the to-be-tested module comprises the following steps: generating test information of a regular test and test information of a stability test of the to-be-tested module respectively according to the parameter information of the to-be-tested module and the supported function interface of the to-be-tested module; generating the test case of the to-be-tested module according to the test information of the regular test and the test information of the stability test.

3. The module test case generation method of claim 2, wherein, the step of generating the test case of the to-be-tested module according to the test information of the regular test and the test information of the stability test comprises the following steps: generating test code of the regular test according to the test information of the regular test, and generating test code of the stability test according to the test information of the stability test; generating the test case of the to-be-tested module based on the test code of the regular test and the test code of the stability test.

4. The method of claim 3, wherein, the method further comprises the following steps: determining a current kernel version of the operating system according to a kernel version difference point in the engineering configuration file; obtaining a test parameter of the stability test input by a user; the step of generating the test code of the regular test according to the test information of the regular test, and generating the test code of the stability test according to the test information of the stability test comprises the following steps: generating test code of the regular test according to test information of the regular test and a current kernel version of the operating system; generating test code of the stability test according to test information of the stability test and test parameters of the stability test.

5. The method of claim 1, wherein, The method further comprises: visualizing communication functions supported by the module to be tested; determining a function to be tested from the communication functions supported by the module to be tested in response to a selection instruction input by a user; The generating of the test case for the module to be tested according to the parameter information of the module to be tested and the function interface supported thereby comprises: generating the test case for the module to be tested according to the function interface and the parameter information of the function to be tested of the module to be tested.

6. A module test case generation apparatus characterized by comprising: The device is applied to a module connection kit of an Internet of Things operating system, and the device comprises: a file acquisition module configured to acquire an engineering configuration file from an operating system, wherein the engineering configuration file is a configuration information file automatically generated by the operating system after an engineering is created; an information acquisition module configured to acquire parameter information of a module to be tested and a function interface supported thereby from the engineering configuration file; a case generation module configured to generate a test case for the module to be tested according to the parameter information of the module to be tested and the function interface supported thereby; The parameter information comprises first communication parameters and second communication parameters, and the engineering configuration file comprises a first communication keyword. The acquiring of the parameter information of the module to be tested and the function interface supported thereby from the engineering configuration file comprises: parsing the engineering configuration file to acquire the first communication parameters in the module to be tested that are related to the first communication keyword; acquiring a name of the module to be tested from the engineering configuration file and acquiring a header file of the module to be tested according to the name of the module to be tested; parsing the header file of the module to be tested to acquire the second communication parameters of the module to be tested; The engineering configuration file comprises a second communication keyword. The acquiring of the parameter information of the module to be tested and the function interface supported thereby from the engineering configuration file comprises: parsing the engineering configuration file to determine a target communication function corresponding to the second communication keyword, wherein the target communication function is a communication function supported by the module to be tested; acquiring a source file of the module to be tested according to the name of the module to be tested from the engineering configuration file; acquiring a target structure from the source file of the module to be tested according to the target communication function; determining the function interface supported by the module to be tested according to the target structure. 7.An electronic device comprising a memory and a processor, the electronic device characterized by, The memory stores a computer program, and the processor is configured to execute the computer program to implement the module test case generation method in any one of claims 1 to 5.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the module test case generation method in any one of claims 1 to 5.

Images