A method and apparatus for automated testing of trusted SIS trusted function interfaces

Abstract

The application relates to the technical field of software testing, and discloses an automatic testing method for a trusted SIS trusted function interface, which comprises the following steps: reading test cases from a CSV file line by line, wherein the test cases contain a case ID, an interface name, input parameters and expected output; searching for a corresponding measured interface function from a pre-established interface mapping table according to the interface name, and parsing a string of the input parameters into a required parameter format of the measured interface function; calling the measured interface function, capturing actual output; verifying the actual output with the expected output to determine the pass state of the test case; and generating a test report in a CSV format, wherein the test report contains the case ID, the actual output, the pass state and execution time.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, specifically to an automated testing method and apparatus for trusted functional interfaces of trusted SIS (Software-Defined System). Background Technology

[0002] In software engineering, interface testing is a crucial step in verifying the correctness of interactions between modules, playing an irreplaceable role in ensuring software quality. Traditional C language interface testing methods typically rely on test engineers manually writing test cases, embedding test parameters into the test program's source code through hard coding, then compiling, executing, and manually verifying the output results. This testing model has the following inherent drawbacks: First, test data and test code are highly coupled. When test requirements change or test parameters need to be adjusted, test engineers must modify the source code and recompile and link the test program. This is not only time-consuming and labor-intensive, but also prone to introducing new code errors, reducing the reliability and maintainability of testing activities.

[0003] Second, there is a lack of a unified data management format. Different testing projects often use their own defined test data formats, making it difficult to reuse test cases across projects and severely restricting the accumulation and transfer of testing experience.

[0004] Third, test result verification relies on manual inspection. After the test is completed, test engineers need to compare the actual output with the expected output line by line. This manual verification method is not only inefficient, but also prone to omissions due to human error, making it difficult to meet the needs of large-scale regression testing.

[0005] Fourth, it is difficult to integrate into continuous integration (CI) processes. Existing testing solutions lack standardized report output formats and automated result notification mechanisms, and cannot seamlessly interface with mainstream CI tools such as Jenkins, which restricts the promotion and application of DevOps practices in the field of trusted SIS R&D.

[0006] In summary, there is an urgent need in this field for a C language interface automated testing solution that can separate test data from code, support full-process automated execution, seamlessly integrate with CI tools such as Jenkins, and generate structured test reports, in order to meet the actual needs of trusted SIS trusted functional interface testing. Summary of the Invention

[0007] The purpose of this invention is to provide an automated testing method and apparatus for trusted functional interfaces of trusted SIS, so as to solve the problems mentioned in the background art.

[0008] To achieve the above objectives, the present invention provides the following technical solution: An automated testing method for trusted functional interfaces of trusted SIS (Secured System-on-a-Service), characterized by comprising the following steps: Read test cases line by line from the CSV file. Each test case contains a test case ID, interface name, input parameters, and expected output. The corresponding interface function under test is found from the pre-established interface mapping table according to the interface name, and the string of the input parameter is parsed into the parameter format required by the interface function under test. Call the function of the interface under test and capture the actual output; The actual output is compared with the expected output to determine the pass / fail status of the test case; Generate a test report in CSV format, which includes the test case ID, the actual output, the pass status, and the execution time.

[0009] Preferably, the CSV file contains a header row and data rows. The header row defines a test case ID field, an interface name field, an input parameter field, an expected output field, an error tolerance field, and a timeout field. Each row of the data rows corresponds to one test case.

[0010] Preferably, the libcsv library is used to read the CSV file line by line and parse the fields, with commas used as delimiters for the field parsing.

[0011] Preferably, the step of searching for the corresponding interface function under test from a pre-established interface mapping table based on the interface name includes: The function pointer of the interface under test is dynamically loaded from the dynamic link library using the dlsym function, and the function pointer is registered in the interface mapping table to establish the correspondence between the interface name and the function pointer.

[0012] Preferred options also include: The automated testing method is executed through a Jenkins pipeline, which includes a build phase, a test phase, and a post-processing phase. The build phase compiles the test program, the test phase performs line-by-line reading and result verification, and the post-processing phase sends the test report.

[0013] An automated testing device for a trusted SIS trusted function interface includes: The test data management module is used to read test cases line by line from a CSV file. Each test case contains a test case ID, interface name, input parameters, and expected output. The interface calling module is used to find the corresponding interface function under test from the pre-established interface mapping table according to the interface name, parse the string of the input parameter into the parameter format required by the interface function under test, and call the interface function under test to capture the actual output. The result verification module is used to verify the actual output against the expected output and determine the pass status of the test case. The report generation module is used to generate a test report in CSV format, which includes the test case ID, the actual output, the pass status, and the execution time.

[0014] Preferably, the test data management module uses the libcsv library to read and parse the fields of the CSV file line by line. The CSV file contains a header row and data rows. The header row defines the test case ID field, interface name field, input parameter field, expected output field, error tolerance field, and timeout field.

[0015] Preferably, it also includes an interface adaptation module, used to parse the string of the input parameter into the parameter format required by the interface function under test, the parsing including identifying delimiters, type conversion and memory allocation.

[0016] Preferably, the result verification module supports an exact value matching strategy, a numerical range verification strategy, and a regular expression matching strategy. The numerical range verification strategy determines the pass status of the test case based on the error tolerance field.

[0017] Preferably, it also includes a Jenkins integration module for executing automated tests through the Jenkins pipeline. The Jenkins integration module includes a build phase unit, a test phase unit, and a post-processing phase unit. The post-processing phase unit sends the test report through the Email Extension plugin.

[0018] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention uses CSV files to store test cases. Each test case exists as an independent row, containing fields such as test case ID, interface name, input parameters, and expected output. Test data is stored in plain text format, and modifications to test cases do not require recompiling the test program; only editing the CSV file takes effect. This data-driven testing model significantly improves the efficiency of test case maintenance, allowing test engineers to focus more on test scenario design rather than test code writing. Furthermore, the CSV format has excellent cross-platform compatibility, allowing direct editing using text editors or spreadsheet software on operating systems such as Windows, Linux, and macOS, lowering the barrier to test data management.

[0019] 2. The main test program of this invention is written in C language and can automatically parse test data in CSV files. Based on the interface name, it searches for the corresponding interface function under test from a pre-established interface mapping table, parses the input parameter string into the parameter format required by the interface function under test, calls the interface function under test and captures the actual output, and then automatically compares the actual output with the expected output to determine the pass / fail status of the test case. The entire testing process requires no manual intervention and supports unattended scheduled execution or code submission-triggered execution, significantly improving testing efficiency and reducing labor costs. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the system architecture of the present invention; Figure 2 This is a schematic diagram of the automated testing method of the present invention. Detailed Implementation

[0021] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0022] Example 1 like Figure 1 and Figure 2 As shown, this embodiment provides an automated testing method for trusted functional interfaces of trusted SIS. This method stores test cases in CSV files, and uses a test main program written in C language to realize automatic parsing of test cases, dynamic calling of interface functions, automatic verification of test results, and generation of CSV format test reports. The test process can be fully automated through the Jenkins pipeline.

[0023] like Figure 1 As shown, the overall process of the automated testing method described in this embodiment includes the following steps: Step S101: Read the test cases line by line from the CSV file.

[0024] The CSV file is the core storage medium for test data. It uses plain text format, separating different test cases with newlines and different fields of the same test case with commas. CSV files have good cross-platform compatibility and can be edited and viewed directly on operating systems such as Windows, Linux, and macOS using text editors or spreadsheet software.

[0025] In this embodiment, the CSV file consists of two parts: a header row and data rows. The header row, located in the first line of the CSV file, defines the names and data types of each field, including the test case ID field, interface name field, input parameter field, expected output field, error tolerance field, and timeout field. The data rows begin from the second line of the CSV file, with each row corresponding to an independent test case, and the values ​​of each field corresponding one-to-one with the field order defined in the header row.

[0026] The Test Case ID field uniquely identifies a test case, and its value is typically in numeric or string format, such as TC001, TC002, etc. The Test Case ID is referenced in the test report, allowing test engineers to quickly locate and track the execution results of specific test cases.

[0027] The interface name field specifies the name of the interface function under test, and its value should be exactly the same as the function name exported from the dynamic link library under test. The main test program looks up the corresponding interface function under test from the pre-established interface mapping table based on the interface name.

[0028] The input parameter field is used to store the input parameters required to call the function of the interface under test. Multiple parameters are separated by a predetermined delimiter (such as a semicolon, a vertical bar, etc.). Since the CSV file itself uses commas as field delimiters, in order to avoid conflicts with the commas inside the input parameters, this embodiment recommends using semicolons or vertical bars as internal parameter delimiters.

[0029] The expected output field is used to store the expected result value after the interface function under test is executed. The main test program compares the actual output with the expected output to determine the pass status of the test case.

[0030] The error tolerance field defines the allowable error range for verifying numerical results, and its value is usually expressed in the form of absolute error or relative error. For the verification of floating-point operation results, due to the precision limitations of computer floating-point numbers, directly comparing whether two floating-point numbers are equal is often unreliable. After introducing error tolerance, as long as the difference between the actual output and the expected output is within the tolerance range, the test can be judged as passed.

[0031] The timeout field defines the maximum allowed execution time for a test case, in milliseconds or seconds. If the execution time of the interface function under test exceeds the timeout, the main test program will forcibly terminate the execution of the test case and determine it as a failure, to prevent the entire test process from being blocked due to deadlock or infinite loop of the interface function under test.

[0032] In this embodiment, the libcsv library is used to read and parse the fields of a CSV file line by line. libcsv is an open-source, pure C language CSV parsing library with advantages such as small size, high speed, and no external dependencies, making it particularly suitable for embedded testing environments. The libcsv library uses a callback function mechanism to handle each field and row of data encountered during the parsing process. Users only need to implement custom callback functions to complete the parsing of CSV files of a specific format.

[0033] The libcsv library uses commas as the default delimiter for field parsing, but also supports user-defined delimiters. During parsing, libcsv automatically handles cases where field values ​​are enclosed in double quotes, and supports complex scenarios where field values ​​contain commas and newlines. For the test case CSV file described in this embodiment, since the field values ​​typically do not contain special characters, the default configuration can be used directly for parsing.

[0034] Step S102: Based on the interface name, find the corresponding interface function under test from the pre-established interface mapping table, and parse the string of input parameters into the parameter format required by the interface function under test.

[0035] The interface mapping table is the core data structure for implementing dynamic interface invocation in this embodiment. It establishes a mapping relationship between interface names and the addresses of the functions of the interface under test. The interface mapping table is built during the initialization phase of the main test program and supports dynamically adding, deleting, or modifying mapping entries at runtime.

[0036] In this embodiment, the process of constructing the interface mapping table includes the following sub-steps: Sub-step S102-1: Dynamically load the function pointer of the interface function under test from the dynamic link library using the dlsym function.

[0037] The `dlsym` function is a POSIX standard-defined dynamic linking interface function used to find the address of a symbol (function or variable) with a specified name from a loaded dynamic link library at runtime. In the Linux operating system, the `dlsym` function is declared in the header file `dlfcn.h`, and its function prototype is: `void *dlsym(void *handle, const char *symbol);` where the `handle` parameter is the handle of the dynamic link library returned by the `dlopen` function, and the `symbol` parameter is the name of the symbol to be searched for. If the search is successful, the `dlsym` function returns the address of the symbol; if the search fails, it returns NULL.

[0038] In this embodiment, the main test program first calls the `dlopen` function to load the dynamic link library under test and obtains the library handle. Then, for each interface function to be tested, the `dlsym` function is called with the interface name as the symbol parameter to obtain the entry address of that interface function. The obtained function pointer needs to be forcibly cast to the actual type of the interface function to ensure correct subsequent calls.

[0039] Sub-step S102-2: Register the function pointer to the interface mapping table and establish the correspondence between the interface name and the function pointer.

[0040] In this embodiment, the interface mapping table is implemented using a hash table data structure, with the hash value of the interface name as the key and the function pointer as the value. The hash table supports fast lookup with an average time complexity of O(1), which can meet the high-efficiency execution requirements of large-scale test cases.

[0041] The hash function of the hash table uses either the classic DJB2 algorithm or the FNV-1a algorithm. Both algorithms have good distribution characteristics and computational efficiency in the field of string hashing. The hash table uses the separate chaining method to resolve collisions. That is, when multiple interface names are mapped to the same hash bucket, these entries are stored in the bucket as a linked list.

[0042] When registering a mapping entry, the hash value of the interface name is first calculated to determine the corresponding hash bucket index. Then, the entry containing the interface name and function pointer is inserted into the linked list of that bucket. To avoid duplicate registrations, the linked list is traversed before insertion to check if an entry with the same interface name already exists. If it does, its function pointer is updated; otherwise, a new entry is created and inserted at the head of the linked list.

[0043] Sub-step S102-3: Parse the string of input parameters into the parameter format required by the interface function under test.

[0044] Since the input parameters stored in the CSV file are represented as strings, and the interface function under test usually requires parameters of specific types (such as integers, floating-point numbers, structure pointers, etc.), parameter type parsing and conversion are necessary. This embodiment completes this parsing process through an interface adaptation module.

[0045] The parsing process of the interface adaptation module includes three key steps: identifying separators, type conversion, and memory allocation.

[0046] In the separator identification stage: the interface adaptation module first divides the input parameter string into multiple substrings based on a predefined separator (such as a semicolon, vertical bar, etc.), with each substring corresponding to an independent parameter value. The choice of separator should be determined during the test data design phase and maintained consistently throughout the entire test project.

[0047] Type conversion stage: For each substring, the interface adaptation module converts it to the corresponding C language data type according to the parameter type definition of the interface function under test. Common type conversions include: (1) Integer conversion: Use standard library functions such as atoi, atol, and atol to convert decimal strings to integers such as int, long, and long long; use functions such as strtol and strtoll to support conversion of multiple base formats such as binary, octal, and hexadecimal. (2) Floating-point conversion: Use standard library functions such as atof and strtod to convert strings to double type; use the strtof function to convert to float type. For high-precision floating-point operation scenarios, the strtold function can be used to convert to long double type. (3) Boolean conversion: Identify strings true, 1, yes, etc. as true values, and false, 0, no, etc. as false values, and convert them to the bool type of C language. (4) String conversion: Directly use the substring as a character array (char array) of C language, and pay attention to the handling of string boundaries and memory allocation. (5) Array type conversion: For scenarios that require passing array parameters, it is agreed to use a specific delimiter (such as a comma) to separate array elements. After the interface adaptation module recognizes the delimiter, it further divides the substring into array elements and performs type conversion one by one.

[0048] Memory allocation phase: For parameters that require dynamic memory allocation (such as strings, structure pointers, arrays, etc.), the interface adaptation module is responsible for calling memory allocation functions such as malloc and calloc to request sufficient memory space, and calling the free function to release memory after the test case is executed to prevent memory leaks.

[0049] Step S103: Call the function of the interface under test and capture the actual output.

[0050] After completing parameter parsing and type conversion, the test main program calls the interface function under test through function pointers. The specific form of the function call depends on the parameter list and return value type of the interface function under test. For common return value types, the processing methods are as follows: (1) Integer return value: directly obtain the return value and compare it with the expected output as an integer. (2) Floating-point return value: after obtaining the return value, calculate the absolute value of the difference with the expected output, compare it with the error tolerance, and determine whether it is within the allowable range. (3) Pointer return value: for interface functions that return pointers, it is necessary to check whether the return value is NULL (indicating execution failure). If it is not NULL, it may be necessary to further dereference the pointer to obtain the actual data. (4) Output parameters: some interface functions return the execution result through output parameters (passed in the form of pointers). The test main program needs to allocate memory space for the output parameters before the call, and read the memory content pointed to by the output parameters as the actual output after the call.

[0051] While calling the interface function under test, the main test program records the start and end times of the call and calculates the execution time for performance analysis and timeout determination.

[0052] Step S104: Verify the actual output against the expected output to determine the pass / fail status of the test case.

[0053] Result verification is the core step in determining whether test case execution was successful in this embodiment. The result verification module in this embodiment supports multiple verification strategies to adapt to the testing requirements of different types of interface functions.

[0054] Exact value matching strategy: Suitable for scenarios where the return value type is integer, boolean, or fixed-precision string. The verification logic directly compares whether the actual output is exactly equal to the expected output. If they are equal, the test is considered passed; otherwise, the test is considered failed.

[0055] Numerical range verification strategy: Applicable to scenarios where the return value type is floating-point or where numerical errors exist. The verification logic is to calculate the absolute value of the difference between the actual output and the expected output, denoted as error. If error is less than or equal to the error tolerance, the test is considered passed; otherwise, the test is considered failed. The error tolerance can be read from the error tolerance field of a CSV file or a preset default value can be used.

[0056] Let the expected output be 'expected', the actual output be 'actual', and the error tolerance be 'tolerance'. Then the judgment logic for the numerical range verification can be represented by the following mathematical expression: pass = |actual - expected|<=tolerance; where pass is a Boolean value indicating whether the test passes or fails; |x| represents the absolute value operation.

[0057] For relative error scenarios, the error tolerance can be expressed as a percentage of relative error. In this case, the judgment logic is: pass = |actual - expected| / |expected| <= tolerance.

[0058] Regular expression matching strategy: Suitable for scenarios where the return value format is complex but conforms to a certain pattern, such as log output, version number strings, etc. The verification logic uses a regular expression engine (such as the POSIX regex library or PCRE library) to perform pattern matching on the actual output. If the match is successful, the test is considered passed; otherwise, the test is considered failed.

[0059] Step S105: Generate a test report in CSV format.

[0060] The test report is a summary output of the test execution results. In this embodiment, the test report is stored in CSV format to facilitate subsequent data analysis and visualization.

[0061] The test report includes the following fields: (1) Test Case ID field: Identifier of the test case, consistent with the test case ID in the input CSV file. (2) Interface Name field: Records the name of the interface function under test. (3) Actual Output field: Records the actual return value or output parameter content after the interface function under test is executed. (4) Expected Output field: Copies the expected output value in the input CSV file for easy comparison and viewing. (5) Pass Status field: Records the judgment result of the test case, usually PASS for pass, FAIL for failure, TIMEOUT for timeout, and ERROR for exceptions during execution. (6) Execution Time field: Records the execution time of the test case, in milliseconds or seconds, for performance analysis and trend tracking. (7) Error Information field: Optional field, records detailed error description information when the test case fails or an exception occurs, for easy problem location and debugging.

[0062] Test reports are written to disk as CSV files. The filename may include a timestamp for version control, such as test_report_20240329_143052.csv. Once generated, the test report can be sent to relevant personnel via email or uploaded to the test management system for unified management and analysis.

[0063] Step S106: Execute automated tests via the Jenkins pipeline.

[0064] Jenkins is an open-source automation server widely used in continuous integration and continuous delivery (CI / CD) scenarios. This example demonstrates how to automate the entire testing process using a Jenkins pipeline.

[0065] Jenkins pipelines can be defined using either declarative or script-based syntax; this embodiment uses declarative syntax. The build phase is responsible for compiling the test program. In this phase, Jenkins pulls the source code of the main test program from a code repository (such as a Git repository), calls the gcc compiler to compile and link it, and generates an executable file. Example compilation command: `gcc -otester tester.c -lcsv -ldl`; where `-o tester` specifies the output file name as `tester`, `tester.c` is the source file of the main test program, `-lcsv` links to the libcsv library, and `-ldl` links to the dynamic link library support library.

[0066] The testing phase is responsible for executing the main test program and generating a test report. In this phase, Jenkins calls the executable file generated during the build phase, passing the path to the test data CSV file and the report output path as command-line arguments. Example execution command: `. / tester test_data.csv report.csv`; after the main test program completes execution, it will generate a CSV format test report file named `report.csv`. Jenkins can be configured to archive this report file for later viewing and download.

[0067] The post-processing stage is responsible for sending the test report. In this stage, Jenkins sends the test report as an email attachment to relevant personnel via the Email Extension plugin. Email configuration allows specifying the recipient list, email subject, email body template, etc. If any test cases fail during test execution, it can be configured to send an email only in such cases, or to send different levels of notification (e.g., send to developers on failures, and to the test manager on successes).

[0068] Through the Jenkins pipeline configuration described above, this embodiment achieves full automation from code submission to test report sending. After developers submit code, Jenkins automatically triggers pipeline execution, compiles the latest test programs, runs full regression tests, and promptly feeds back the test results to relevant personnel, greatly shortening the defect discovery and fixing cycle and improving the efficiency and quality of software development.

[0069] Example 2 This embodiment provides an automated testing device for trusted functional interfaces of trusted SIS. This device corresponds to the method described in Embodiment 1 and adopts a modular architecture design, including a test data management module, an interface call module, a result verification module, a report generation module, an interface adaptation module, and a Jenkins integration module.

[0070] The test data management module is used to read test cases line by line from a CSV file. This module uses the libcsv library to implement CSV file parsing, supporting functions such as header row recognition, field extraction, and data type conversion. During initialization, the test data management module opens the specified CSV file, reads the test case data line by line, parses each line into a structured test case object, and stores it in a test case queue in memory for subsequent sequential or concurrent processing by other modules.

[0071] The data structure definition of the test case object is as follows: typedef struct { char case_id

[32] ;char interface_name

[64] ; char input_params

[256] ; char expected_output

[128] ;double tolerance; int timeout_ms;} TestCase; where each field corresponds to the test case ID, interface name, input parameters, expected output, error tolerance, and timeout in the CSV file.

[0072] The interface invocation module is used to find the corresponding interface function under test from a pre-established interface mapping table based on the interface name, invoke the interface function under test, and capture the actual output. This module maintains a global interface mapping table, which supports dynamic registration and querying of interface function pointers at runtime.

[0073] The data structure definition of the interface mapping table entry is as follows: typedef struct InterfaceEntry { charname

[64] ; void *func_ptr; struct InterfaceEntry *next;} InterfaceEntry; where the name field stores the interface name, the func_ptr field stores the function pointer, and the next field is used as a linked list pointer to resolve hash collisions.

[0074] The interface mapping table is implemented using a hash table. The size of the hash bucket array is configured according to the expected number of interfaces, typically 1.5 to 2 times the expected number, to balance memory usage and collision probability. The hash function uses the FNV-1a algorithm, and its calculation process is as follows: hash = 2166136261; hash = hash XOR byte[i]; hash = hash * 16777619; where byte[i] represents the i-th byte of the interface name string, and XOR represents the bitwise XOR operation. The FNV-1a algorithm has the characteristics of fast calculation speed and uniform hash distribution, making it particularly suitable for string hashing scenarios.

[0075] When the API call module searches for an API function, it first calculates the hash value of the API name to locate the corresponding hash bucket. Then, it traverses the linked list of that bucket, comparing the name field of each linked list entry with the target API name. If a matching entry is found, its func_ptr field is returned. If no matching entry is found after traversing the linked list, NULL is returned to indicate that the search failed.

[0076] The result verification module is used to verify the actual output against the expected output and determine the pass / fail status of the test case. This module implements three verification methods: exact value matching, numerical range verification, and regular expression matching, automatically selecting the appropriate verification strategy based on the test case configuration.

[0077] The numerical range verification strategy is the focus of this embodiment, and its judgment logic is based on the error tolerance field. Let the actual output be actual, the expected output be expected, and the error tolerance be tolerance, then the judgment formula is: error = |actual - expected|; pass = (error<= tolerance) ? true : false.

[0078] When comparing floating-point data, directly comparing whether two floating-point numbers are equal (i.e., using the == operator) is often unreliable due to the precision limitations of computer floating-point representation. For example, due to rounding errors, two floating-point numbers that should theoretically be equal may have slight differences after actual calculation. Therefore, introducing an error tolerance for range verification is a more robust approach.

[0079] The value of the error tolerance needs to be determined based on the characteristics of the interface function under test and the application scenario. For high-precision calculation scenarios, tolerance can be set to a smaller value, such as 1e-6 or 1e-9; for scenarios that allow for a certain degree of error, tolerance can be set to a larger value, such as 0.01 or 0.1. In the CSV file, the error tolerance field is stored as a floating-point number string, and the result verification module uses the atof function to convert it to a double-type value.

[0080] The report generation module is used to generate test reports in CSV format. During test execution, this module collects the execution results of each test case, including the test case ID, actual output, pass / fail status, and execution time, and writes all results to a CSV file after the test is completed.

[0081] The format of the test report CSV file is similar to that of the input test data CSV file, containing a header row and data rows. The header row defines the names of each field, and each data row records the execution result of one test case. The report generation module supports append mode, meaning new test results can be appended to an existing report file, facilitating the summarization of results from multiple test executions. The report generation module also provides result statistics functions, calculating metrics such as the total number of test cases, the number of passes, the number of failures, and the pass rate, and outputting a statistical summary at the end of the report file or in a separate file.

[0082] The interface adaptation module is used to parse the input parameter string into the parameter format required by the interface function under test. This module is the bridge connecting the CSV test data and the C language interface function, and is responsible for handling low-level details such as type conversion, memory allocation, and parameter passing.

[0083] The core function of the interface adaptation module is the parameter parsing function, which parses the input parameter string into the corresponding C language data according to the parameter type definition of the interface function under test. The parameter type definition adopts the form of descriptor string, for example: i, f, s represent three parameters, with types of integer (int), floating-point (float), and string (string) respectively; i

[10] represents one parameter, with type being an array containing 10 integer elements; p{ii} represents one parameter, with type being a pointer to a structure, which contains two integer members.

[0084] The interface adaptation module parses the above descriptor strings, identifies the type and structure of each parameter, and then segments and converts the input parameter strings according to the identification results. For integer parameters, the strtol function is used for conversion, supporting multiple base formats such as decimal, hexadecimal (starting with 0x), and octal (starting with 0). For floating-point parameters, the strtod function is used for conversion, supporting scientific notation. For string parameters, the parameter string content is directly copied to the allocated memory space, paying attention to string length and memory boundaries. For array parameters, the number and type of array elements are first parsed, then memory is allocated for the array, and finally array elements are parsed one by one and filled into the array. For structure pointer parameters, the type and order of structure members are first parsed, then memory is allocated for the structure, and finally member values ​​are parsed one by one according to the member order and filled into the structure.

[0085] The Jenkins integration module is used to execute automated tests through the Jenkins pipeline. This module includes a build phase unit, a test phase unit, and a post-processing phase unit, corresponding to the three phases of the Jenkins pipeline. The build phase unit is responsible for compiling the test program, including pulling source code from the code repository, configuring the compilation environment, calling the compiler, and checking the compilation results. The test phase unit is responsible for executing the main test program, including preparing the test environment, calling the test program, monitoring the execution process, and checking the results. The post-processing phase unit is responsible for sending test reports, sending them as email attachments to relevant personnel via the EmailExtension plugin.

[0086] Example 3 This embodiment provides a specific test scenario application example, taking the whitelist query interface test of trusted SIS as an example, to illustrate the specific implementation details of the method and device described in this invention.

[0087] The interface function under test is defined as follows: `int get_whitelist_policy(const char *filename, int policy_id, PolicyInfo *info)`. This interface function is used to query policy information for a specified ID from a specified whitelist policy file. The query result is returned through the `info` parameter. The function return value indicates the execution status: 0 indicates success, and a non-zero value indicates failure (such as file not existing, policy ID not existing, etc.).

[0088] The PolicyInfo structure is defined as follows: typedef struct { int id; char name

[64] ; inttype; unsigned long hash;} PolicyInfo; This structure contains four member fields: policy ID, policy name, policy type, and policy hash value.

[0089] The test data CSV file content is shown below: The header row defines fields such as case_id, interface_name, input_params, expected_return, expected_output, tolerance, and timeout; the data rows contain three test cases: TC001, TC002, and TC003. Test case TC001 verifies a normal query scenario. Input parameters include the policy file path / etc / whitelist.conf, policy ID of 1, output parameter placeholder of 0, expected return value of 0 (success), expected output of a policy information string, and a timeout of 1000 milliseconds. Test case TC002 verifies a scenario where the policy ID does not exist. The policy ID is set to 999 (assuming the ID does not exist). The expected return value is 1 (indicating the policy does not exist), and the expected output is empty. Test case TC003 verifies a scenario where the policy file does not exist. The file path is set to / nonexistent.conf (assuming the file does not exist). The expected return value is -1 (indicating a file error), and the expected output is empty.

[0090] The interface adaptation module defines the parameter type descriptors s, i, p for the get_whitelist_policy function, indicating that the three parameters are of type string, integer, and pointer, respectively. The parsing process is as follows: The input parameter strings are separated by semicolons, resulting in three substrings: / etc / whitelist.conf, 1, and 0. The first parameter is a string, and the substring / etc / whitelist.conf is directly used as the parameter value. The second parameter is an integer, and the atoi function is used to convert the substring 1 to the integer 1. The third parameter is a pointer, and the substring 0 represents the initial value of the output parameter (here, a placeholder). The interface adaptation module calls the malloc function to allocate memory space the size of the PolicyInfo structure, and uses the allocated memory address as the parameter value.

[0091] The test execution process is as follows: The main test program reads the TC001 test case from the CSV file; it looks up the function pointer in the interface mapping table based on the interface name get_whitelist_policy; it calls the interface adaptation module to parse the input parameters, obtaining the string / etc / whitelist.conf pointed to by filename, policy_id equal to 1, and the allocated PolicyInfo structure memory pointed to by info; it calls the interface under test function get_whitelist_policy(filename, policy_id, info); it captures the return value ret and the structure content pointed to by the output parameter info; the result verification module compares ret with expected_return (0 and 0), and the comparison is successful; it formats the info structure content into a string and compares it with expected_output, and the comparison is successful; the TC001 test case is determined to pass; the above process is repeated to execute the TC002 and TC003 test cases.

[0092] The test report example is as follows: Test cases with test case IDs TC001, TC002, and TC003 all passed, with execution times of 15 milliseconds, 8 milliseconds, and 5 milliseconds, respectively. The test report is stored in CSV format and can be directly opened and viewed using Excel, facilitating analysis and archiving by test engineers.

[0093] Example 4 This embodiment provides another test scenario application example, taking the dynamic trust measurement interface test of a trusted SIS as an example, to illustrate the specific implementation details involving floating-point result verification.

[0094] The interface function under test is defined as follows: double calculate_trust_score(const char *measurements[], int count, double weights[]); This interface function is used to calculate a comprehensive trust score based on a set of measures and weights, and returns a score result of type double (range 0.0 to 1.0).

[0095] The following is an example of the contents of the test data CSV file: The TC101 test case contains three metrics m1, m2, and m3, with corresponding weights of 0.3, 0.4, and 0.3. The expected calculation result is 0.725, the error tolerance is 0.001 (i.e., an error of ±0.001 is allowed), and the timeout is 500 milliseconds.

[0096] The result verification module employs a numerical range verification strategy for floating-point results. The judgment logic is as follows: Assume the actual return value is `actual`, the expected output `expected_output` is 0.725, and the error tolerance is 0.001. Calculate the error: `error = |actual - 0.725|`. Judgment condition: `pass = (error <= 0.001)`. If `actual` is 0.7255, then `error` equals 0.0005, satisfying the judgment condition, and the test passes. If `actual` is 0.7230, then `error` equals 0.0020, failing the judgment condition, and the test fails.

[0097] The introduction of error tolerance solves the precision problem of floating-point arithmetic. Because computers use binary floating-point numbers to represent real numbers, some decimal fractions cannot be represented precisely (e.g., 0.1 is an infinite repeating decimal in binary), leading to slight rounding errors in floating-point arithmetic results. By setting a reasonable error tolerance, the pass / fail status of test cases can be correctly determined while acknowledging this inherent error.

[0098] Example 5 This embodiment provides a detailed example of Jenkins pipeline configuration, illustrating the specific implementation of the present invention integrated with Jenkins.

[0099] The Jenkinsfile defines three main phases: the build phase, the test phase, and the post-processing phase. The build phase calls the gcc compiler to compile the main test program and its dependent modules, generating an executable file. The test phase executes the generated executable file, passing in the paths to the test data files and the report output files. The post-processing phase calls the emailext step to send a test report email. The email subject includes the build number, the email body contains basic build information, and the test report file is sent as an attachment.

[0100] Through the Jenkins pipeline configuration described above, this invention achieves full automation of the testing process. After developers submit code changes, Jenkins automatically triggers pipeline execution, completing all operations such as compilation, testing, and report sending without manual intervention, greatly improving testing efficiency and response speed.

[0101] In summary, the automated testing method and apparatus for trusted functional interfaces of trusted SIS provided by this invention effectively solves the technical problems existing in the prior art, such as coupling of test data and code, insufficient automation, poor integration, and low report readability, through innovative technical solution design, achieving significant technical effects and practical value. The implementation of this invention can not only improve the quality of trusted SIS software, reduce testing costs, and accelerate product launch, but also provide a lightweight, efficient, and easily integrated general solution for automated testing of C language interfaces, with broad prospects for promotion and application.

[0102] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. An automated testing method for trusted functional interfaces of a trusted SIS, characterized in that, Includes the following steps: Read test cases line by line from the CSV file. Each test case contains a test case ID, interface name, input parameters, and expected output. The corresponding interface function under test is found from the pre-established interface mapping table according to the interface name, and the string of the input parameter is parsed into the parameter format required by the interface function under test. Call the function of the interface under test and capture the actual output; The actual output is compared with the expected output to determine the pass / fail status of the test case; Generate a test report in CSV format, which includes the test case ID, the actual output, the pass status, and the execution time.

2. The method according to claim 1, characterized in that, The CSV file contains a header row and data rows. The header row defines the test case ID field, interface name field, input parameter field, expected output field, error tolerance field, and timeout field. Each data row corresponds to one test case.

3. The method according to claim 1, characterized in that, The libcsv library is used to read the CSV file line by line and parse the fields, with commas as the delimiter for the field parsing.

4. The method according to claim 1, characterized in that, The step of searching for the corresponding interface function under test from the pre-established interface mapping table based on the interface name includes: The function pointer of the interface under test is dynamically loaded from the dynamic link library using the dlsym function, and the function pointer is registered in the interface mapping table to establish the correspondence between the interface name and the function pointer.

5. The method according to claim 1, characterized in that, Also includes: The automated testing method is executed through a Jenkins pipeline, which includes a build phase, a test phase, and a post-processing phase. The build phase compiles the test program, the test phase performs line-by-line reading and result verification, and the post-processing phase sends the test report.

6. An automated testing device for a trusted functional interface of a trusted SIS, characterized in that, include: The test data management module is used to read test cases line by line from a CSV file. Each test case contains a test case ID, interface name, input parameters, and expected output. The interface calling module is used to find the corresponding interface function under test from the pre-established interface mapping table according to the interface name, parse the string of the input parameter into the parameter format required by the interface function under test, and call the interface function under test to capture the actual output. The result verification module is used to verify the actual output against the expected output and determine the pass status of the test case. The report generation module is used to generate a test report in CSV format, which includes the test case ID, the actual output, the pass status, and the execution time.

7. The apparatus according to claim 6, characterized in that, The test data management module uses the libcsv library to read and parse the fields of the CSV file line by line. The CSV file contains a header row and data rows. The header row defines the test case ID field, interface name field, input parameter field, expected output field, error tolerance field, and timeout field.

8. The apparatus according to claim 6, characterized in that, It also includes an interface adaptation module, which is used to parse the string of the input parameter into the parameter format required by the interface function under test. The parsing includes identifying delimiters, type conversion, and memory allocation.

9. The apparatus according to claim 6, characterized in that, The result verification module supports exact value matching strategy, numerical range verification strategy and regular expression matching strategy. The numerical range verification strategy determines the pass status of the test case based on the error tolerance field.

10. The apparatus according to claim 6, characterized in that, It also includes a Jenkins integration module for executing automated tests through the Jenkins pipeline. The Jenkins integration module includes a build phase unit, a test phase unit, and a post-processing phase unit. The post-processing phase unit sends the test report through the Email Extension plugin.

Images