API test system and method for communication module
By designing a communication module API testing system, the problems of testing complexity and poor reusability in existing technologies have been solved, achieving efficient and automated API testing, simplifying the testing process and improving testing efficiency and accuracy.
Patent Information
- Application Number
- CN202511316912.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-16
- Publication Date
- 2026-01-09
AI Technical Summary
In existing technologies, API testing of communication modules requires writing C language demo programs, which has a high technical threshold, poor reusability, difficulty in covering boundary, exception and multi-module concurrent scenarios, and low testing efficiency.
Design an API testing system, including a communication interface module, a protocol parsing module, a parameter mapping module, and a result encapsulation module. Communicate with a PC via a serial port to achieve an automated and standardized API testing process. Use Python scripts to automate and modularize the test logic.
It improves testing efficiency and accuracy, simplifies the testing process, reduces the programming skills required of testers, and can cover complex testing scenarios, including boundary, exception, and multi-module concurrent scenarios.
Smart Images
Figure CN121309433A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of API testing technology, specifically to an API testing system and method for communication modules. Background Technology
[0002] During the development of communication modules, it is necessary to provide API interfaces for customers to perform secondary development. To ensure the reliability and stability of the API, comprehensive testing is required. Traditional testing methods include white-box testing, black-box testing, and manual testing. White-box testing requires testers to have a deep understanding of the API's internal implementation, which has a high technical threshold. Black-box testing relies on pre-written demo programs, but demos usually call APIs in a fixed order, making it difficult to cover all input combinations. Manual testing is inefficient and cannot adapt to complex multi-module interaction scenarios.
[0003] In existing technologies, testers need to write C language demo programs to call APIs. This requires testers to have high programming skills, and the demo code has poor reusability and high maintenance costs. Each test case or test scenario usually requires writing a specific demo program. Testing different API combinations, different parameter inputs, and different state transition paths often means writing almost all the code from scratch. Since the test logic, API call sequence, parameter construction, and result verification are all tightly coupled in a single demo program, it is difficult to abstract common test steps, such as initialization, network connection, and data transmission, into reusable modules, resulting in a large amount of duplicate code. Therefore, this does not meet the existing requirements. To address this, we propose an API testing system and method for communication modules. Summary of the Invention
[0004] This invention provides an API testing system and method for communication modules, which has the beneficial effects of expanding testing scenarios, improving stability, increasing testing efficiency, and accelerating deployment. It solves the problems mentioned in the background technology, such as testers having to write C language demos, high technical threshold, poor reusability, and demo programs usually calling interfaces in a predetermined order, making it difficult to cover boundary, exception, and multi-module concurrent scenarios.
[0005] This invention provides the following technical solution: an API testing system and method for communication modules, wherein the API testing system for communication modules includes:
[0006] The communication interface module establishes a full-duplex link with the PC via a serial port and receives raw data streams of text commands from the PC.
[0007] The protocol parsing module extracts the API_NAME from the full string of the original text instruction data stream through exact matching to obtain the corresponding callback function pointer cb;
[0008] The parameter mapping module parses and converts text instructions into memory data structures required for C language function calls;
[0009] The execution module passes the corresponding callback function pointer cb to the mapping parameter, thereby executing the API in the real-time environment;
[0010] The result encapsulation module executes the API to obtain the execution result, and the result encapsulation module sends it back to the PC according to the unified frame format communication interface module.
[0011] This invention also provides a testing method for an API testing system for communication modules, comprising the following steps:
[0012] On the PC side, a text command in a specific format is constructed and sent to the communication interface module via a serial port;
[0013] The communication interface module receives raw data streams of text commands.
[0014] The protocol parsing module is used to extract API_NAME from the raw text instruction data stream and perform keyword matching to determine the corresponding static array;
[0015] Perform a full string exact match element by element in the static array, obtain the callback function pointer cb, pass in the mapping parameters, and obtain the parameter list;
[0016] The parameter mapping module converts the textual parameter list into C language variables or structure instances that conform to the signature of the target API function;
[0017] The result encapsulation module outputs a text string based on the API function execution result and sends it back to the PC through the communication interface module.
[0018] As an optional solution for the testing method of the API testing system for communication modules described in this invention, wherein: when the API function is executed, the unified UCR reporting interface is actively called for non-requested or asynchronous events;
[0019] Formatting UCR;
[0020] The formatted UCR is actively sent to the PC via serial port;
[0021] The PC continuously monitors the serial port to capture asynchronous messages and verify asynchronous behavior.
[0022] As an optional solution to the testing method of the API testing system for communication modules described in this invention, the method of continuously monitoring the serial port on the PC side includes:
[0023] S1, Send command;
[0024] S2. Wait for and read the response;
[0025] S3. Parse the response and determine whether it is a synchronous Result or an asynchronous URC;
[0026] For the Result, check if the value is 0 and verify if the value matches the expectation;
[0027] For URC, check whether the reported event type and content match the expectations of the test cases;
[0028] S4. Record the test cases, commands, expectations, actual responses, and pass / fail status;
[0029] S5, repeat S1-S4 in a loop.
[0030] As an optional solution to the testing method of the API testing system for communication modules described in this invention, it further includes designing test cases according to testing requirements;
[0031] Define the text protocol format to convert test cases into one or more executable text instructions.
[0032] As an optional solution for the test method of the API test system for communication modules described in this invention, the serial port includes UART or USB;
[0033] The communication interface module continuously listens to the UART or USB interface. When the PC sends a command, the communication interface module stores the received raw byte stream into a receive buffer.
[0034] A background task is set up, which activates the protocol parsing module when it detects a complete instruction frame.
[0035] As an optional solution to the test method of the API test system for communication modules described in this invention, wherein: when performing full string exact matching element by element in the static array;
[0036] If a perfect match is found, its cb field is retrieved, which is the callback pointer to the actual API function, and the parameter mapping stage is entered.
[0037] No match found. This indicates that the API was not found, and an error code will be returned.
[0038] As an optional solution of the test method of the API test system for communication modules described in this invention, the result encapsulation module organizes the execution result into a text string according to a predefined Result frame format;
[0039] The execution results include success results and failure results;
[0040] Both successful and unsuccessful results include a type;
[0041] The failure result contains detailed error information.
[0042] The present invention has the following beneficial effects:
[0043] 1. This API testing system and method for communication modules, through the coordination of module composition, text protocol design format, input parameter data format, result response format and URC asynchronous response format, in conjunction with Python scripts, completes the automated and standardized API testing process, thereby improving testing efficiency and accuracy.
[0044] 2. The API testing system and method for communication modules optimizes the API testing process through text protocol design format, ensuring efficient and stable protocol parsing and data interaction.
[0045] 3. The API testing system and method for communication modules cover the automated processing of protocol parsing, data flow and response mechanisms through a text protocol design format, thus optimizing the protocol adaptation and response management process in API testing. Attached Figure Description
[0046] Figure 1 This is a schematic diagram of the module structure of the test system of the present invention.
[0047] Figure 2 This is a schematic diagram of the overall process of the testing system of the present invention.
[0048] Figure 3 This is a flowchart illustrating the detailed functional modules of the present invention.
[0049] Figure 4 This is a schematic diagram of the data processing flow of the present invention. Detailed Implementation
[0050] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0051] Example 1
[0052] Please see Figures 1-4 Furthermore, an API testing system for communication modules is disclosed, comprising:
[0053] The communication interface module establishes a full-duplex link with the PC via a serial port and receives raw data streams of text commands from the PC.
[0054] The protocol parsing module extracts the API_NAME from the raw text instruction data stream through exact matching of the entire string, in order to obtain the corresponding callback function pointer cb;
[0055] The parameter mapping module parses and converts text instructions into the memory data structures required for C language function calls;
[0056] The execution module passes the corresponding callback function pointer cb to the mapping parameters, thereby executing the API in the real-time environment;
[0057] The result encapsulation module executes the API to obtain the execution result and sends it back to the PC in a unified frame format via the communication interface module.
[0058] This invention also provides a testing method for an API testing system for communication modules, comprising the following steps:
[0059] This also includes designing test cases based on testing requirements, such as designing test cases for testing Socket connections, ADC sampling, UART configuration, etc.
[0060] Define the text protocol format to convert test cases into one or more executable text instructions;
[0061] The format of the text instruction format is set as follows:
[0062] API_NAME(param1,param2,{param3,param4},…,paramN);
[0063] The semantic convention is as follows:
[0064] API_NAME is case-sensitive and must be exactly the same as the name of the publicly released interface.
[0065] The parameter list is comma-separated and supports the following atom types:
[0066] Number: Decimal integer, without quotation marks;
[0067] String: UTF-8 encoded, enclosed in double quotes, inner quotes, commas, and curly braces must be escaped with backslashes;
[0068] Structure: Represented by a pair of curly braces, members are arranged in order, and there are no key names;
[0069] Structures / arrays can be nested at multiple levels;
[0070] Note: Only the input parameters need to appear; the output parameters are carried by the module in the return frame, and the test end does not need to occupy space.
[0071] If the interface has no input parameters, the parentheses should be empty, i.e., API_NAME().
[0072] For example, Example 1:
[0073] Test the voltage of ADC channel 1 and generate the instruction adc_liot_adc_get_volt(1).
[0074] Example 2:
[0075] Initialize a TCPSocket and generate commands.
[0076] lwip_socket_init(1,"TCP","121.89.205.240",41000).
[0077] Example 3:
[0078] Configure UART parameters and generate instructions.
[0079] liot_uart_set_dcbconfig(1,{115200,8,0,1,0,1}).
[0080] On the PC side, text commands in a specific format are constructed and sent to the communication interface module via serial port.
[0081] The communication interface module receives raw data streams of text commands;
[0082] The API_NAME is extracted from the raw data stream of the text instruction using the protocol parsing module, and keyword matching is performed to determine the corresponding static array;
[0083] Serial ports include UART or USB;
[0084] The communication interface module continuously listens to the UART or USB interface;
[0085] Specifically, the PC-side automation script (such as a Python script) opens the serial port (such as COM3) connected to the communication module through a serial port library (such as pyserial), and sends out the generated text instruction string (usually with a newline character \n added at the end as the terminator) through the write() method;
[0086] When the PC sends a command, the communication interface module stores the received raw byte stream into a receive buffer.
[0087] Set up a background task; when the background task detects a complete instruction frame, it will activate the protocol parsing module.
[0088] Specifically, the communication interface module on the module side (usually a serial port receive interrupt service routine or DMA receive) continuously listens to the UART or USB interface. When the PC sends a command, this module stores the received raw byte stream (such as 'a', 'd', 'c', '_', 'l', ...) into a receive buffer (such as a circular buffer);
[0089] A background task or main loop periodically checks the receive buffer. When a complete instruction frame (ending with a newline character \n) is detected, the protocol parsing module is activated;
[0090] The parsing module first extracts the API name (API_NAME) from the received complete string, from the beginning to the first left parenthesis (). For example, it extracts adc_liot_adc_get_volt from adc_liot_adc_get_volt(1);
[0091] The system iterates through the predefined global MainMenuMapping[] array. This array has registered all testable modules (such as dev, adc, uart, socket, etc.) and their corresponding function pointer array TestFunction_X[] when the module starts.
[0092] The system uses the strstr() function to check whether the extracted API_NAME contains a module keyword from MainMenuMapping[]. For example,
[0093] The adc_liot_adc_get_volt contains the keyword adc, so the system determines that this API belongs to the adc module;
[0094] Perform a full string match element by element in the static array, obtain the callback function pointer cb, pass in the mapping parameters, and obtain the parameter list;
[0095] The parameter mapping module converts the textual parameter list into C language variables or struct instances that conform to the signature of the target API function;
[0096] The result encapsulation module outputs a text string based on the API function execution result and sends it back to the PC through the communication interface module.
[0097] Once a module (such as adc) is identified through keyword matching, the system narrows the search to the static array TestFunction_X[] corresponding to that module;
[0098] The system performs an exact match of the entire string element by element in the TestFunction_X[] array (strcmp()).
[0099] Each element in TestFunction_X[] is a structure {const char *name; module_func_cb cb;}, where name is the fully qualified name of the API and cb is the corresponding C language function pointer;
[0100] The system will compare the extracted API_NAME (adc_liot_adc_get_volt) with the name field of each element in the array;
[0101] When performing an exact match of the entire string element by element in a static array;
[0102] If a perfect match is found, its cb field is retrieved, which is the callback pointer to the actual API function (such as the adc_liot_adc_get_volt function), and the parameter mapping stage is entered.
[0103] No match found. If no match is found after traversing the entire TestFunction_X[] array, it is determined as "API not found" and an error code 0xF001 (corresponding to Result:1) is prepared to be returned.
[0104] The system locates the content between the left and right parentheses, i.e., the parameter list. Then, it parses the parameters one by one according to the semantic conventions defined in the protocol.
[0105] For numbers (such as 1), directly call atoi() or a similar function to convert to an integer; for strings (such as "TCP"), remove the double quotes and handle the internal escape characters (such as \").
[0106] For structures (such as {115200,8,0,1,0,1}), the system needs to recognize the curly braces {} and parse the comma-separated values inside in sequence, filling them into a predefined C language structure variable.
[0107] For multi-level nested structures (such as {1,2,{"1",5},{"2",6}}), the parser needs to have recursive or stack-based parsing capabilities to ensure that the nested data structure in memory is correctly constructed.
[0108] The ultimate goal of the parameter mapping module is to convert a textual list of parameters into a set of C language variables or struct instances that conform to the signature of the target API function. This data forms a "parameter package" in memory required to call the API.
[0109] The execution module uses the callback pointer cb obtained in the previous step and passes in the mapped parameter package to directly call the C language API function inside the module. This call occurs in the module's real-time operating system (RTOS) or main loop environment, which is completely consistent with the actual operating environment of the product.
[0110] After the API function finishes execution, it will return a status code (usually of type int) and may return specific data (such as version number, status information, voltage value read, etc.) through output parameters.
[0111] The result encapsulation module organizes the execution result into a text string according to the predefined Result frame format;
[0112] The result encapsulation module organizes the execution results into a text string according to the predefined Result frame format;
[0113] The execution results include success results and failure results;
[0114] Both successful and unsuccessful results include a type;
[0115] The failure result contains detailed error information.
[0116] Specifically, the result is given, for example: \r\nResult:0;Value:<actual return value>\r\n. The format of <actual return value> depends on the type: numbers are output directly, strings are enclosed in double quotes, and structures are enclosed in {} and separated by commas.
[0117] The failure result returns a corresponding value based on the error type (e.g., number 1 indicates API not found, number 3 indicates incorrect parameters), and may carry more detailed error information in the data.
[0118] The encapsulated Result frame is sent back to the PC via the serial port of the communication interface module.
[0119] When the API function is executed, it actively calls the unified UCR reporting interface for non-requested or asynchronous events.
[0120] Formatting UCR;
[0121] The formatted UCR is actively sent to the PC via serial port;
[0122] The PC continuously monitors the serial port to capture asynchronous messages and verify asynchronous behavior.
[0123] Specifically, after an API is executed or during module operation, some non-requested, asynchronous events may occur. For example:
[0124] The socket received data sent from the other end.
[0125] The network connection status has changed (disconnected, reconnected).
[0126] The UART port receives data from external devices.
[0127] When these events occur, the relevant modules within the module (such as the Socket module and UART module) will proactively call a unified URC reporting interface. The system will then report the URC_ <module> ： <message>The format organizes event information into text, for example:
[0128] The socket received 10 bytes of data: URC_Socket: recv: 1, 10, "aaaaaaaaaa";
[0129] Socket connection closed: URC_Socket: closed: 1;
[0130] The formatted URC frames are sent to the PC proactively via serial port by the module without requiring a request from the PC. The script on the PC needs to continuously listen to the serial port to capture these asynchronous messages and use them to verify the asynchronous behavior.
[0131] The asynchronous URC returns:
[0132] Formatting instructions: \r\nURC_ <module> ： <message>\r\n;
[0133] Field description:
[0134] module: refers to a specific module, such as Socket, Uart, Http, Mqtt, Ftp, Lbs, Gnss, etc.
[0135] message: The format is comma-separated; the format needs to be specified.
[0136] Example as follows:
[0137] ;
[0138] A PC-based script (using Python as an example) dynamically generates instructions and asserts return frames using a serial port object:
[0139] importserial,concurrent.futures;
[0140] ser=serial.Serial('COM3',115200,timeout=2);
[0141] cmds=[b'adc_liot_adc_get_volt(1)\n',
[0142] b'lwip_socket_init(1,"TCP","121.89.205.240",41000)\n'];
[0143] defrun(c);
[0144] ser.write(c);
[0145] returner.readline();
[0146] withconcurrent.futures.ThreadPoolExecutor(3)ase;
[0147] forrine.map(run,cmds);
[0148] assert b'Result: 0'in r;
[0149] Out-of-order calls can cover boundary conditions, exceptions, and multi-module concurrent scenarios, without requiring testers to have C language development skills.
[0150] Methods for continuous monitoring of the serial port on a PC include:
[0151] S1, Send command;
[0152] S2. Wait for and read the response;
[0153] S3. Parse the response and determine whether it is a synchronous Result or an asynchronous URC;
[0154] For the Result, check if the value is 0 and verify if the value matches the expectation;
[0155] For URC, check whether the reported event type and content match the expectations of the test cases;
[0156] S4. Record the test cases, commands, expectations, actual responses, and pass / fail status;
[0157] S5, repeat S1-S4 in a loop.
[0158] Furthermore, automation features:
[0159] Test cases are stored in an Excel file (test_cases.xlsx), and a Python script reads the commands, executes them, and compares the actual response with the expected response. It integrates with CI / CD pipelines to automate testing across multiple devices and environments.
[0160] Scalability:
[0161] The framework can be extended to support additional functional modules (such as I2C and SPI) with minimal effort, ensuring compatibility with various hardware platforms and operating systems.
[0162] In summary, this application encapsulates complex C API calls using a simple text format, enabling non-C developers to easily write test scripts. It clearly divides responsibilities such as "instruction parsing," "API lookup," "parameter mapping," and "result encapsulation" into different modules, making the framework itself easy to maintain and extend. By building an "interpreter" on the module side, it decouples test logic from firmware, freeing testers from needing to concern themselves with the internal C code of the module. They only need to "tell" the module "what to do" via PC scripts, and the module can "execute" and "report the results," improving testing efficiency and accuracy.
[0163] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.
[0164] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / message> < / module> < / message> < / module>
Claims
1. An API testing system for communication modules, characterized in that, include: The communication interface module establishes a full-duplex link with the PC via a serial port and receives raw data streams of text commands from the PC. The protocol parsing module extracts the API_NAME from the full string of the original text instruction data stream through exact matching to obtain the corresponding callback function pointer cb; The parameter mapping module parses and converts text instructions into memory data structures required for C language function calls; The execution module passes the corresponding callback function pointer cb to the mapping parameter, thereby executing the API in the real-time environment; The result encapsulation module executes the API to obtain the execution result, and the result encapsulation module sends the result back to the PC according to the unified frame format communication interface module.
2. The test method for the API testing system for communication modules according to claim 1, characterized in that, Includes the following steps: On the PC side, a text command in a specific format is constructed and sent to the communication interface module via a serial port; The communication interface module receives raw data streams of text commands. The protocol parsing module is used to extract API_NAME from the raw data stream of the text instruction and perform keyword matching to determine the corresponding static array; Perform a full string exact match element by element in the static array, obtain the callback function pointer cb, pass in the mapping parameters, and obtain the parameter list; The parameter mapping module converts the textual parameter list into C language variables or structure instances that conform to the signature of the target API function; The result encapsulation module outputs a text string based on the API function execution result and sends it back to the PC through the communication interface module.
3. The test method for the API test system for communication modules according to claim 2, characterized in that: When the API function is executed, it actively calls the unified UCR reporting interface for non-requested or asynchronous events. Formatting UCR; The formatted UCR is actively sent to the PC via serial port; The PC continuously monitors the serial port to capture asynchronous messages and verify asynchronous behavior.
4. The test method for the API test system for communication modules according to claim 2, characterized in that, The method for continuous monitoring of the serial port on the PC includes: S1, Send command; S2. Wait for and read the response; S3. Parse the response and determine whether it is a synchronous Result or an asynchronous URC; For the Result, check if the value is 0 and verify if the value matches the expectation; For URC, check whether the reported event type and content match the expectations of the test cases; S4. Record the test cases, commands, expectations, actual responses, and pass / fail status; S5, repeat S1-S4 in a loop.
5. The test method for the API test system for communication modules according to claim 2, characterized in that: This also includes designing test cases based on testing requirements; Define the text protocol format to convert test cases into one or more executable text instructions.
6. The test method for the API test system for communication modules according to claim 2, characterized in that: The serial port includes UART or USB; The communication interface module continuously listens to the UART or USB interface. When the PC sends a command, the communication interface module stores the received raw byte stream into a receive buffer. A background task is set up, which activates the protocol parsing module when it detects a complete instruction frame.
7. The test method for the API test system for communication modules according to claim 4, characterized in that: When performing an exact full string match element by element in the static array; If a perfect match is found, its cb field is retrieved, which is the callback pointer to the actual API function, and the parameter mapping stage is entered. No match found. This indicates that the API was not found, and an error code will be returned.
8. The test method for the API test system for communication modules according to claim 7, characterized in that: The result encapsulation module organizes the execution result into a text string according to the predefined Result frame format; The execution results include success results and failure results; Both successful and unsuccessful results include a type; The failure result contains detailed error information.