A table use case driven trusted SIS platform automatic test method

Abstract

The present application relates to the technical field of computer software automatic testing and industrial control system security, and particularly relates to a table case driven trusted SIS platform automatic testing method.The method comprises the following steps: obtaining the basic information of the tested trusted management platform and the Excel test case file path, performing field arrangement, Openpyxl reading and function case expansion processing, and generating a structured test instruction list structure; performing page element position field extraction, page element positioning expression generation processing, and generating a trusted management platform interface operation execution record structure; performing terminal side calling and state collection processing, and generating a trusted linkage result set structure; performing piece-by-piece matching through marking, log summarization and HTML test report generation processing, and generating test log and report output structure.The present application realizes full-process automatic testing from interface operation to terminal linkage, improves test efficiency and coverage, reduces manual intervention, and enhances test traceability and accuracy.

Description

Technical Field

[0001] This invention relates to the fields of computer software automated testing and industrial control system security technology, and in particular to a table-based test case-driven automated testing method for a trusted SIS platform. Background Technology

[0002] The domestically developed trusted SIS integrates functions such as trusted boot, static trusted verification, dynamic trusted verification, trusted whitelisting, process protection, and application access control. The trusted management platform provides a GUI interface with a B / S architecture, allowing users to easily set and delete policies for trusted boot, static trusted verification, dynamic trusted verification, trusted whitelisting, process protection, and application access control within the SIS system; and to obtain and display the trusted status and trusted function auditing of the SIS system. The trusted management platform allows for simple and convenient configuration of relevant trusted policies for the SIS system, thereby protecting its security. After deployment, the trusted management platform requires testing. Developed using a B / S architecture, it benefits from mature automated testing frameworks available in mainstream B / S architectures. Test engineers can use languages ​​such as Python and Java to locate test objects and perform automated operations such as input and clicks on them using Selenium page elements. However, testing the stability of the trusted management platform requires test engineers with programming skills to write test programs. Comprehensive testing demands higher programming skills from test engineers, potentially leading to project delays and unplanned costs.

[0003] Furthermore, in the fields of computer software automated testing and industrial control system security technology, existing solutions for automated testing scenarios of trusted management platforms typically rely on test engineers manually writing test cases based on script frameworks, configuring trusted policies item by item on the management platform interface, and collecting terminal status through independent tools. This approach suffers from limitations such as a disconnect between test case descriptions and actual execution actions, separation of terminal linkage verification and management platform interface operations, and fragmented test result data structures. Existing methods often involve manually maintaining tables or configuration files, hard-coding page element location information and operation steps in the test scripts, and manually comparing expected results with terminal feedback after testing. In scenarios where the functions of the trusted management platform under test are constantly expanding, terminal types are diverse, and trusted policy combinations are complex, test scripts become difficult to maintain, regression scenario coverage is incomplete, and it is difficult to ensure the stable implementation of target object functions such as the trusted management platform interface operation execution record structure, terminal request construction and sending, and trusted linkage result set structure. Regarding the joint processing of data device condition links between the structured test instruction list structure, the terminal request construction and sending, and the trusted linkage result set structure, existing technologies generally suffer from common shortcomings such as scattered configurations, fragmented links, and a lack of unified structured expression in the stages of test case description and interface operation mapping, interface operation and terminal linkage triggering, and terminal status collection and result alignment determination. It is difficult to form a continuous and consistent process in the application scenario of trusted management platform automated testing, from test environment input collection, structured test instruction list structure generation, trusted management platform interface operation execution record structure acquisition, trusted linkage result set structure construction to test log and report output structure recording. This results in a large testing workload, difficulty in timely error exposure, and difficulty in traceability and reuse of test processes and results when performing trusted linkage verification with multi-terminal and multi-functional collaboration. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a table-based test case-driven automated testing method for a trusted SIS platform, comprising: Obtain the basic information of the trusted management platform under test and the path of the Excel test case file, organize the fields, read the openpyxl file and perform function-based test case expansion to generate a structured test instruction list. Based on the structured test instruction list structure, page element position fields are extracted, page element location expressions are generated, and operation keywords are mapped to Selenium actions to generate a trusted management platform interface operation execution record structure. Based on the interface operation execution record structure of the trusted management platform, terminal request construction and sending processing are performed, and terminal-side calls and status acquisition processing are executed to generate a trusted linkage result set structure. Obtain the structure of the trusted linkage result set, perform expected result field alignment, match each item, and generate test logs and report output structure through tagging, log aggregation, and HTML test report generation.

[0005] Furthermore, the paths to the basic information of the trusted management platform under test and the Excel test case files include: The basic information of the tested trusted management platform includes the trusted management platform network address field, port number field, login account field, login password field, target system identifier field, and environment identifier field, as well as the proxy server configuration field, timeout threshold field, default waiting time field, and log output directory field; The Excel test case file path field is specified by the test engineer according to the test plan. It points to the path of the spreadsheet file stored in the file system and is represented in the form of an absolute path or a relative path.

[0006] Furthermore, the field organization process also includes: The field processing includes merging the platform address field and port number field into an access endpoint field, encapsulating the login account field and login password field into an authentication credential field, and combining the environment identifier field and target system identifier field into a test target description field. It also performs network address format standardization, port number value range validity checks, log output directory path existence checks, Excel test case file path file existence checks, and access permission checks. The test results are recorded as the environment self-check status field to generate the test environment input set.

[0007] Furthermore, the process of openpyxl reading and functional use case expansion also includes: Based on the test environment input set, Excel test case reading and processing are performed. This includes opening the Excel test case file using the openpyxl library, reading workbook metadata to obtain a list of worksheet names and starting row numbers, traversing the worksheet row by row starting from the starting row number to read cell content, distinguishing between header rows and test case data rows and marking comment rows and incomplete test case rows, and constructing the original row set of the Excel test cases. Functional test case expansion and field decomposition are then performed. Functional test case expansion includes parsing the test case type field to identify functional test case rows and ordinary single-step test case rows, referencing template test cases to generate virtual test case rows through parameter replacement and step rearrangement. Field decomposition includes mapping the original test case row cell values ​​to a logical field set including test case number, step number, page element position, operation keyword, and expected result fields. The page element position field is parsed in segments, the operation keyword field is categorized as click, input text action type, and the expected result field is split into strings and stored in a structured manner.

[0008] Furthermore, the process of extracting page element position fields and generating page element positioning expressions also includes: The page element location field extraction process includes reading the page element location field, environment identifier field, test case number field, and step sequence number field. The page element location expression generation process includes performing segmented parsing to obtain page identifier fields, region identifier fields, control identifier fields, and index identifier fields, consulting the page structure configuration table to determine the page template type, and generating page element location expressions with location method fields and location parameter fields.

[0009] Furthermore, the process of mapping operation keywords to Selenium action processing also includes: The operation keyword mapping Selenium action processing includes finding the action template corresponding to the operation keyword, filling the target element placeholder in the action template, arranging the action sequence and attaching synchronization control fragments and error handling fragments to generate an operation keyword mapping action sequence set; performing browser-driven execution and interface operation result collection and processing. The browser-driven execution processing includes initializing the browser instance, setting proxy server configuration fields and timeout threshold fields, logging into the trusted management platform main interface, scheduling action sequence entries, and executing atomic actions for retrying or skipping; the interface operation result collection and processing includes execution record units, aligning standardized execution event fields to execution result status fields and exception details fields.

[0010] Furthermore, the process of constructing and sending a terminal request also includes: The terminal request construction process includes filtering interface operation steps that have been successfully executed and have terminal linkage significance, identifying terminal action types including trusted startup actions, static trusted verification actions, dynamic trusted verification actions, trusted whitelist distribution actions, process protection configuration actions, and application access control configuration actions, extracting policy identifier fields and terminal range selection fields, and constructing terminal request entries; the entries include action type fields, protocol type fields, target terminal identifier lists, policy identifier fields, and parameter fields; The terminal request sending process includes sending a terminal request entry, recording the sending time field, and the initial response status.

[0011] Furthermore, the process of terminal-side invocation and status acquisition processing also includes: Terminal-side call processing includes executing trusted functions and returning terminal status messages. Specifically, it includes a trusted startup configuration component, a static measurement module, a dynamic behavior monitoring module, a whitelist management module, a process protection module, and an application access control module. The returned terminal status message includes terminal identifier field, action type field, execution result status field, static measurement result field, dynamic behavior event field, whitelist update result field, process protection status field, and application access control status field. The status acquisition and processing includes the execution agent subunit listening for return messages, generating the terminal execution result raw record unit, and recording the terminal result list and log path set.

[0012] Furthermore, the process of aligning expected result fields and matching each record using tags also includes: The expected result field alignment process includes reading trusted linkage result entries, including trusted status field, linkage status summary field, exception type field, execution scope description field, and evidence resource field; reading expected result fields and terminal assertion fields; aligning the rule table to map expected fields and actual fields; and filling in missing or misformatted fields with default values.

[0013] Furthermore, the process of log aggregation and HTML test report generation also includes... Log aggregation processing includes building time-series views and summary log entries, and recording test case start time and test case end time fields; The HTML test report generation process includes building a visual report model, including report header information, use case summary view, assertion-level detail view, and evidence link view, and generating HTML report files and structured log files.

[0014] The key innovations of this invention include: (1) In S100, by obtaining the basic information of the trusted management platform under test and the path of the Excel test case file, the field organization, openpyxl reading and function-based test case expansion are performed. The test case information related to the page element position field, operation keyword and expected result field is uniformly organized into a structured test instruction list structure, so that the basic information of the trusted management platform under test and the path of the Excel test case file form a structured input that can be directly consumed by subsequent steps.

[0015] (2) In S200 and S300, based on the structured test instruction list structure, the page element position field extraction, page element positioning expression generation and operation keyword mapping Selenium action processing are continuously executed to generate a trusted management platform interface operation execution record structure. Furthermore, based on the trusted management platform interface operation execution record structure, the terminal request construction and sending and the terminal side call status collection processing are completed to generate a trusted linkage result set structure, connecting the page side automated operation and the terminal side call status collection in the same link.

[0016] (3) In S400, obtain the trusted linkage result set structure, perform expected result field alignment, match item by item through tags and log summary HTML test report generation process, and organize the actual results and expected result fields from the trusted linkage result set structure into a test log and report output structure. In the same structure, match item by item through tags and HTML test report generation are completed simultaneously.

[0017] The following are its main beneficial effects: (1) To address the problem of the disconnect between test case description and actual execution actions in the background technology, a structured test instruction list is generated directly at the level of the basic information of the trusted management platform under test and the path of the Excel test case file. This makes the field organization, openpyxl reading and function-based test case expansion processing form a fixed process. When maintaining the path of the Excel test case file, test engineers can simultaneously determine the structured expression of the page element position field, operation keyword and expected result field, reducing the dependence on hard-coded scripts and helping to maintain the consistency between test case description and structured execution instructions in the automated testing scenario of the trusted management platform.

[0018] (2) In response to the problems of separation between terminal linkage verification and management platform interface operation and the fragmentation of terminal status collection and result alignment judgment in the background technology, the interface operation execution record structure of the trusted management platform is continuously generated from the structured test instruction list structure and further a trusted linkage result set structure is generated. Within the same link, the extraction of page element position field, generation of page element positioning expression, operation keyword mapping Selenium action processing, terminal request construction and sending and terminal side call status collection processing are completed. This enables the interface operation and terminal side call status collection to run based on a unified data source, forming a continuous data path from interface operation to trusted linkage result set structure in the automated testing process of trusted management platform in multiple terminals and multiple scenarios.

[0019] (3) In view of the problems of scattered test result data structure, difficulty in manually comparing expected results with terminal feedback and test process traceability in the background technology, after obtaining the trusted linkage result set structure, the expected result field alignment and matching are performed one by one through the tagging and log summary HTML test report generation process. The result comparison and report generation are centralized in the test log and report output structure, so that the expected result field and the actual result are recorded in a structured way during the matching and tagging process, and an HTML test report that can be directly viewed is generated simultaneously. This is conducive to the unified recording and reuse of test process and trusted linkage results in the automated test application scenario of trusted management platform. Attached Figure Description

[0020] Figure 1 This application provides an embodiment of an automated testing system, including its architecture and process diagram. Figure 2 This is a flowchart illustrating a table-based test case-driven automated testing method for a trusted SIS platform, as provided in an embodiment of this application. Detailed Implementation

[0021] To achieve the above objectives, this invention employs a Python-based technology stack, integrating the openpyxl library and the Selenium WebDriver component. Openpyxl reads and parses the metadata of Excel test case files, converting test case steps into structured instructions. Selenium WebDriver drives the browser, executing interface operations including but not limited to single-click, double-click, right-click, text input, text clearing, dragging, hovering, and dropdown selection based on the page element location information in the instructions, simulating the front-end interaction of a test engineer with the trusted management platform. The test content comprehensively covers the core trusted functions of the trusted management platform, including: 1) querying and modifying the status of functional modules such as trusted startup, static trusted verification, dynamic trusted verification, trusted whitelist, process protection, and application access control; 2) configuring, issuing, and deleting policies for the above functional modules; 3) performing linked verification on terminals with or without configured relevant policies; and 4) automatically generating HTML test reports containing detailed assertion results and evidence.

[0022] Figure 1The figure shows a schematic diagram of the architecture and process of an automated testing system provided in this application embodiment. The system comprises three core components: a client, a trusted management platform (WEB interface), and a terminal, which work together to complete testing tasks. The client provides an input interface to receive basic information about the trusted management platform under test and the path to the Excel test case file. It is responsible for preparing, parsing, and executing test cases. Preparation includes integrating commonly used functional interface test information, defining operation keywords, specifying page element positions, and defining expected results. The client reads and parses the Excel test cases line by line. Based on the parsed page element positions and operation keywords, it drives the browser to perform simulated operations such as clicking and input on the trusted management platform's WEB interface. The trusted management platform receives trusted function configuration requests from the client, processes them, and forwards them to the specified terminal device. The terminal device receives and executes the configuration request, returns the processing result to the trusted management platform, and the platform feeds back to the WEB interface. The client captures the returned result from the interface, compares it with the expected result, records test logs, and, based on a judgment, executes subsequent test cases in a loop or terminates the test, ultimately generating an HTML format test report. In one specific implementation, the automated testing process of this method is executed according to the following steps: First, the client receives the basic information of the management platform under test and the path of the Excel test case file input by the user; then, the script reads and parses the Excel test cases line by line. The parsing process includes determining whether to use functional test cases and expanding them accordingly, parsing the operation keyword type, obtaining the page element position information and expected result information; next, the client drives the browser to perform corresponding mouse clicks, keyboard inputs, and other operations on the trusted management platform interface based on the parsing results; after receiving the operation request, the management platform processes the business logic and sends the policy issuance instructions to the corresponding terminals; the terminals receive the instructions, execute operations such as setting, deleting, and configuring trusted functions, and return the results to the management platform; the management platform feeds back the terminal execution results to the web interface; the client captures the interface return results and writes them to the log file, and at the same time determines whether to continue executing the next instruction based on the test cases, thus forming a loop execution process starting from step 2; finally, after the entire automated test is completed, an HTML format test report is generated and output.

[0023] In one embodiment, reference is made to Figure 2 This is a flowchart illustrating a table-based test case-driven automated testing method for a trusted SIS platform, provided by an embodiment of the present invention. The process may include at least steps S100-S400: S100: Obtain the basic information of the trusted management platform under test and the path of the Excel test case file, organize the fields, read with openpyxl and process the functional test case expansion, and generate a structured test instruction list structure; S200: Based on the structured test instruction list structure, extract page element position fields, generate page element positioning expressions and map operation keywords to Selenium actions to generate a trusted management platform interface operation execution record structure. S300: Based on the interface operation execution record structure of the trusted management platform, it constructs and sends terminal requests, performs terminal-side calls and status acquisition processing, and generates a trusted linkage result set structure. S400: Obtain the trusted linkage result set structure, perform expected result field alignment, match each item, process through tagging, log aggregation and HTML test report generation, and generate test logs and report output structure.

[0024] Step S100 includes at least steps S110-S130: S110. Obtain the basic information of the trusted management platform under test and the path of the Excel test case file, perform field sorting and merging, and obtain the test environment input set; In this embodiment, the test execution terminal is a workstation with a script execution environment installed, pre-deployed with a client component for accessing the domestically developed Safety Instrumented System (SIS) management platform. Before starting the script, the test engineer inputs basic information about the trusted management platform under test through a configuration file interface or command-line parameters. This basic information includes at least the trusted management platform network address, port number, login account, login password, target system identifier, and environment identifier fields. Preferably, it also includes a proxy server configuration field, timeout threshold field, default wait time field, and log output directory field. The Excel test case file path field is specified by the test engineer according to the test plan and points to the path of the spreadsheet file (Excel) stored in the file system. This path can be represented in absolute or relative path form. When the script starts, the script entry module first collects the above-mentioned inputs and constructs an original set of environment fields by parsing the configuration file content, parsing command-line parameters, and reading environment variables. The original set of environment fields may simultaneously contain fields with the same name, redundant fields, and default fields. The script entry module performs field organization and processing on the original environment field set. It merges the platform address and port number fields into a unified access endpoint field, encapsulates the login account and password fields into authentication credential fields, combines the environment identifier and target system identifier fields into a test target description field, retains the original string value of the Excel test case file path field, and performs overriding and selection among different source fields according to predefined priorities to form a semantically clear subset of environment fields. Specifically, the field organization and processing also includes performing format specification actions on the network address string, performing numerical range validity checks on the port number field, performing path existence checks on the log output directory field, and performing file existence and access permission checks on the Excel test case file path field. The detection results are recorded as the environment self-check status field. When critical fields are missing or detection fails, an environment configuration exception record is written through the exception logging module, and the environment self-check status field is set to a failure status for subsequent steps to determine whether to continue reading the Excel test case file. After the above merging process, the script entry module encapsulates the access endpoint field, authentication credential field, test target description field, Excel test case file path field, environment self-check status field, as well as optional proxy server configuration field, timeout threshold field, default wait time field, and log output directory field into a test environment input set according to the field grouping principle.The test environment input set is represented at the data structure level as a single record or key-value mapping structure with an environment identifier. The access endpoint field and the Excel test case file path field constitute the minimum set of fields driving subsequent Excel test case reading and structured test instruction generation in this invention. The remaining fields are preferred extended fields to enhance script robustness and traceability. In one embodiment, the test execution terminal periodically pulls the latest environment configuration version number from the configuration management system and writes the environment configuration version number field into the test environment input set for version management and backtracking of the subsequent structured test instruction list structure. Through the above process, the test environment input set completes the transformation from distributed configuration to a unified structured environment description. This test environment input set serves as the sole source of the Excel test case file path field in subsequent step S120, and also as the environment context for locating page elements and the Selenium-driven trusted management platform interface operation module in stage S200, used to select the corresponding trusted management platform instance under test when executing test instructions.

[0025] S120. Extract the Excel test case file path field from the test environment input set, perform openpyxl reading and row-by-row traversal processing, and generate the original row set of Excel test cases. After constructing the test environment input set, the Excel test case reading module parses the Excel test case file path field from the input set and hands the corresponding spreadsheet file path to the spreadsheet reading component for processing. The spreadsheet reading component, based on the open-source spreadsheet read / write library openpyxl, opens the corresponding Excel test case file using the spreadsheet file path field. During the initial opening phase, the component prioritizes reading the workbook metadata to obtain a list of worksheet names, frozen row information, and data start row number information, enabling it to distinguish between header rows, comment rows, and test case data rows during subsequent traversal. The Excel test case file is compiled according to a pre-defined format. Each worksheet corresponds to a test function domain or a type of trusted function, such as a trusted startup scenario test worksheet or a static trusted verification scenario test worksheet. The first row or several rows of each worksheet define column headers, which at least include a test case number field, a test case name field, a test case type field, a page element position field, an operation keyword field, and an expected result field. Preferably, they also include a precondition field, a delay configuration field, a screenshot flag field, and a terminal assertion field. The column headings mentioned above form the basis for field mapping in subsequent field decomposition processing.

[0026] During the row-by-row traversal phase, the spreadsheet reading component reads the cell content row by row for each worksheet, starting from the first row number, and constructs an original row object for each Excel test case. The original row object records the current worksheet name, row index, and cell values ​​for each column. Cell values ​​are converted to string or date / time formats using a unified type conversion module to avoid implicit type inconsistencies between different field types. For rows starting with a specific marker, such as when test case engineers add comments to non-test case rows, the spreadsheet reading component marks these rows as comment rows and records them in the comment row list. These rows are not included in the original row set of the Excel test case to ensure that subsequent functional test case expansion and field decomposition only apply to actual test case rows. For rows where test case type fields are empty or some key fields are empty, the spreadsheet reading component marks them as incomplete test case rows, appends an empty field marker to the original row object of the Excel test case, and writes it to the data integrity check log, recording the worksheet name, row number, and missing field names for later revision of the test case file by the test engineer.

[0027] In one embodiment, the spreadsheet reading component further filters the worksheets based on the test target description field, only traversing worksheets that match the current version of the trusted management platform under test. Specifically, the spreadsheet reading component reads the target system identifier field and environment identifier field from the test environment input set, matches them with the pre-set target system identifier cell and environment label cell in each worksheet, and only when a match is successful is the data row in that worksheet included in the original row set of the Excel test case. This environment-based filtering mechanism allows the same Excel test case file to be shared by multiple test environments without needing to maintain multiple path configurations in the script. For abnormal situations such as file opening failure, missing worksheets, and column header mismatches that occur during the reading process, the spreadsheet reading component records the exception type, file path, and stack information through the exception capture module, writes the exception summary to the environment self-check status field associated with the test environment input set, and writes the read failure event to the log file corresponding to the log output directory field for use as a basis for test environment diagnosis.

[0028] Through the above row-by-row traversal process, the Excel test case reading module ultimately generates the original row set of Excel test cases in the script's memory. The original row set of Excel test cases is a collection of original test case rows organized by worksheet name and row number index. Each test case row retains the original cell strings for the test case number, test case name, test case type, page element position, operation keyword, and expected result fields, as well as optional cell strings such as preconditions, delay configuration, screenshot flags, and terminal assertions. Each row in the original row set of Excel test cases also records the test environment identifier and the current environment configuration version number, forming an explicit association between the environment and the test cases. Structurally, the original row set of Excel test cases does not expand the inclusion, reference, or combination relationships between test cases; it only performs a flattening transformation on the Excel test case file structure, providing complete input for the subsequent function-based test case expansion and test case field decomposition processing in step S130. Therefore, the original row set of Excel test cases, as the output field of this step, is directly passed to step S130 in the data flow as the only input set for the functional test case expansion module and field decomposition module. At the same time, it is indirectly passed to stage S200 through the environment identifier field, so that the structured test instruction list structure can be associated with the specific environment configuration when it is constructed.

[0029] S130. Perform function-based test case expansion and test case field decomposition on the original row set of Excel test cases to generate a structured test instruction list structure; After constructing the original row set of Excel test cases, the functional test case expansion module reads the original test case row objects one by one from the original row set. It identifies functional test case rows and ordinary single-step test case rows by parsing the test case type field. In this invention, a functional test case refers to a type of test case row that references template test cases, common step groups, or parameterized step sets by filling in specific markers in the test case type field or other agreed-upon fields, used to reduce repetitive descriptions in the Excel test case file. The functional test case expansion module first reads the template definition area, parsing the original test case rows marked as template test cases into template entries. Each template entry contains a template number, template name, and template step sequence description field. Then, for each functional test case row, the functional test case expansion module searches for a matching template number in the template entry list based on the template reference marker in the test case type field. It combines the template step sequence with the parameter field in the current functional test case row, generating a set of expanded virtual test case rows through parameter replacement and step rearrangement actions. For scenarios involving multi-level template references or nested functionalized tags, the functionalized test case expansion module prevents infinite expansion through depth limits and loop detection strategies. When a self-reference or loop is detected in the reference chain, the test case line is marked as an erroneous test case, and the template link and test case number are written into the error log for test engineers to revise.

[0030] After the functional test case expansion is completed, the test case field decomposition module performs field decomposition processing on both ordinary single-step test case rows and expanded virtual test case rows. The field decomposition processing adopts a column header mapping method, mapping the cell values ​​of each original test case row to a predefined set of logical fields. This set of logical fields includes at least the test case number field, test case name field, step sequence number field, page element position field, operation keyword field, and expected result field. The page element position field and operation keyword field constitute the minimum set of fields driving the Selenium action, and the expected result field constitutes the minimum set of assertions for the subsequent result comparison module. Preferably, the field decomposition processing also parses the precondition field as a description of the environmental state that must be met on the trusted management platform interface or terminal side before executing this structured test instruction; parses the delay configuration field as the length of time to wait before executing certain interface actions; parses the screenshot flag field as a flag indicating whether to capture the management platform interface at the end of this step; and parses the terminal assertion field as the field names and judgment conditions that need to be considered in the terminal's returned data. During the field decomposition process, the use case field decomposition module constructs a globally unique instruction sequence identifier field based on the use case number field and the step sequence number field, ensuring that the page element positioning and action execution can be driven in a predetermined order in the subsequent S200 steps.

[0031] Specifically, when the test case field decomposition module performs field decomposition on an original test case line object, it first checks whether the page element location field is empty. If it is empty, it determines whether the line is a logical step containing only terminal assertions based on the test case type field. If so, it generates only structured test instructions containing terminal assertion fields and marks the page element location field as missing but negligible. If the line requires an operation to be performed on the management platform interface and the page element location field is empty, it marks the line as an unexecutable test case line, writes the error information to the log, and does not generate the corresponding instruction in the structured test instruction list. When the page element location field is not empty, the test case field decomposition module parses the page element location field according to the agreed format, decomposing and storing components such as page identifier, area identifier, control identifier, and index identifier as internal fields, providing a basis for the subsequent page element location expression generation module to construct different location strategies. For the operation keyword field, the test case field decomposition module classifies the keyword content into action types such as single click, double click, right click, input text, clear text, drag, and hover, providing action type labels for the subsequent keyword mapping Selenium action module. For the expected result field and the terminal assertion field, the use case field decomposition module splits and stores the expected text, expected status code, expected terminal return field and judgment condition described therein into strings and in a structured manner, so that the result comparison module can complete the assertion through field-level comparison in subsequent steps.

[0032] Through the concatenation of the functional test case expansion module and the test case field decomposition module, a structured test instruction list structure is ultimately generated in the script's runtime memory. The structured test instruction list structure is a collection ordered by instruction sequence identifiers. Each instruction entry includes the parsed results of the environment identifier field, test case number field, step sequence number field, page element position field, operation keyword field, expected result field, precondition field, delay configuration field, screenshot flag field, and terminal assertion field. The environment identifier field originates from the test environment input set and is used to distinguish the instructions to be executed in different environments when the same Excel test case file is used in multiple environments. The structured test instruction list structure can exist as a memory object within the script or be serialized and written to a local cache file or configuration management system to support subsequent batch regression tests directly loading existing structured test instructions without having to re-parse the original Excel test case row set. In one embodiment, the structured test instruction list structure also includes an instruction version number field and a generation time field. The instruction version number field, together with the environment configuration version number field, constitutes an auditable version management link, facilitating the tracing of the specific test case version and environment configuration used in the current test based on the version number and generation time in case of test result disputes. The structured test instruction list structure, as an output field of this step, is directly input into step S210 in the data flow direction for extracting page element position fields and generating page element location expressions. Simultaneously, the test case number field and expected result field in the structured test instruction list structure are referenced by the result comparison module in stage S400 for constructing the result comparison input set.

[0033] In summary, the technical effects of this step are as follows: Through the continuous processing of S110, S120, and S130, the originally scattered and inconsistent basic information of the trusted management platform under test and the content of the Excel test case files are transformed into a structured test instruction list with environmental context, template expansion results, and field-level semantics. This enables subsequent page element positioning, Selenium-driven trusted management platform interface operations, trusted function terminal linkage execution, and result comparison modules to be directly driven by a unified instruction granularity for automated testing, reducing manual intervention and improving the flexibility of test case maintenance and the traceability of the testing process.

[0034] Step S200 includes at least steps S210-S230: S210. Obtain the structured test instruction list structure, extract the page element position field, and generate the page element positioning expression to obtain the combination set of structured instructions and page element positioning. In this embodiment, the page element location and Selenium-driven trusted management platform interface operation module runs on the page element location subunit on the test execution terminal. The page element location subunit automatically triggers the expansion process when it detects that the structured test instruction list output by the preceding S130 is ready and the environment self-check status is executable. Specifically, the page element location subunit first takes the structured test instruction list as input and sequentially traverses it according to the instruction sequence identifier field through its internal instruction traversal controller. For each structured test instruction, it reads its key fields such as page element position field, environment identifier field, test case number field, and step sequence number field. The page element position field in this invention describes the logical position of the manipulated control on the trusted SIS management platform interface. It typically uses a segmented description method of "page identifier—region identifier—control identifier—index identifier," but can also be extended to include optional fields such as pop-up identifier and tab identifier. The page element positioning sub-unit performs segmented parsing on the page element position field, converting the segmented description into internal structured sub-fields such as page identifier field, region identifier field, control identifier field, and index identifier field. Combined with the version information of the trusted management platform under test recorded in the environment identifier field, it consults the page structure configuration table to determine the page template type where the current control is located, such as login page, policy list page, policy details page, system configuration page, or pop-up confirmation page.

[0035] Furthermore, after parsing the page element position field, the page element positioning subunit searches for the corresponding control positioning strategy in the control positioning rule table according to the page template type. The control positioning strategy pre-maintains positioning priority combinations for different control types, such as prioritizing positioning by unique identifier attributes, followed by positioning by a combination of name attributes and hierarchical paths, and finally positioning by text content and row / column indexes. Based on the above control positioning strategies, the page element positioning subunit extracts raw information that can be used to construct positioning expressions from each subfield of the page element position field and maps this information to a unified page element positioning expression structure. The page element positioning expression structure can be understood to contain two main categories of information: positioning method fields and positioning parameter fields. The positioning method field identifies whether positioning is based on identifier attributes, hierarchical paths, or composite conditions. The positioning parameter field records specific attribute names, attribute value fragments, hierarchical path fragments, and index values. For scenarios where controls need to be located within embedded frames, the page element locator will also add a frame path field or nesting level field based on the page structure configuration table. This will guide the subsequent Selenium WebDriver browser driver component to perform the control search action after entering the corresponding embedded frame.

[0036] When page structures frequently change or there are slight differences between versions, the page element positioning subunit supports multi-version coexistence through version-level control positioning rules. Specifically, when parsing the page element position field, the page element positioning subunit reads the environment configuration version number field from the structured test instruction list structure. It then selects the corresponding version's positioning rule group from the control positioning rule table based on the environment configuration version number field, recording the attribute differences of the same control in different page versions as multiple alternative positioning parameters. When a control is missing during the execution phase of a certain positioning parameter combination, it can switch to an alternative combination for retry without modifying the structured test instruction itself, thus maintaining the continuity of the test process. For instructions with missing page element position fields or parsing failures, the page element positioning subunit generates a corresponding positioning exception record through the exception recording channel, recording the test case number field, step number field, and exception reason field. This instruction is marked as non-executable or terminal assertion-only in the structured instruction and page element positioning combination set, allowing subsequent steps to skip the interface operation part when constructing the action sequence, retaining only the terminal assertion-related information.

[0037] After completing the page element location field extraction and page element location expression generation processes, the page element location subunit combines the original structured test instruction entries with the generated page element location expression structure to form a combined entry containing instruction semantic information and page element location information. Each combined entry retains semantic fields such as test case number, step number, operation keyword, and expected result, while adding a page element location expression field, framework path field, and version adaptation information field. All combined entries are sorted according to the instruction sequence identifier field, forming a structured instruction and page element location combination set. The structured instruction and page element location combination set serves as the output field of this step. It is recorded as a structured instruction and page element location combination set data structure by the page element location and Selenium-driven trusted management platform interface operation module, and directly input into S220 in the data flow direction. The processing unit extracts the operation keyword field from the structured instruction and page element location combination set, which is used to reference the page element location expression in the subsequent keyword mapping Selenium action and action sequence orchestration process. Meanwhile, the page element positioning expression field and version adaptation information field in the structured instructions and page element positioning combination set are also called by the browser driver execution unit in S230 to select the appropriate control positioning method when performing specific actions.

[0038] S220. Extract the operation keyword field from the combination set of structured instructions and page element positioning, perform keyword mapping Selenium actions and action sequence arrangement processing, and generate an operation keyword mapping action sequence set; After the structured instruction and page element location combination set is generated within the page element location and Selenium-driven trusted management platform interface operation module, the action orchestration subunit initiates the keyword mapping processing flow upon detecting the combination set generation event or receiving an external trigger signal. The action orchestration subunit first takes the structured instruction and page element location combination set as input, and then iterates through the internal combination entry controller to obtain information such as the operation keyword field, page element location expression field, precondition field, delay configuration field, screenshot flag field, and terminal assertion field from each combination entry. In this invention, the operation keyword field describes the type of operation to be performed on a specific page element or page area. Typical values ​​include single click, double click, right click, text input, clear text, dropdown selection, checkbox check, checkbox deselection, drag, hover, tab switching, file upload, and triggering a pop-up confirmation. It also allows for differentiation between ordinary clicks and extended presses, and ordinary input and masked input, by extending prefixes or suffixes.

[0039] After reading the operation keyword field, the action orchestration subunit first searches for the corresponding action template in the keyword mapping rule table. This keyword mapping rule table is pre-configured by test tool maintenance personnel during the test tool deployment phase, based on the front-end control system of the Trusted SIS management platform and the basic action set supported by the Selenium WebDriver browser driver component. It records the basic action sequence templates corresponding to each type of operation keyword. For example, the "click" keyword corresponds to "wait for element to become visible—move over element—execute click action," and the "input text" keyword corresponds to "wait for element to become editable—clear existing content—input parameter text—trigger focus event," etc. The action orchestration subunit selects an appropriate action template according to the keyword mapping rules and fills the page element positioning expression field into the target element placeholder in the template, the delay configuration field into the wait time placeholder, and the screenshot flag field into the screenshot action control position. For operation keywords that require input parameters, such as input text, dropdown selection, or file upload, the action orchestration subunit also extracts extended parameter fields or dedicated parameter fields from the structured test instruction entries and binds these parameter fields to the parameter positions in the action template, forming a specific executable action sequence description.

[0040] Understandably, when generating action sequence descriptions, the action orchestration subunit not only simply maps operation keywords to single basic actions, but also adds synchronous control segments and error handling segments to the action sequences based on the asynchronous loading and status prompt characteristics of the trusted SIS management platform interface. For example, for a policy list refresh button that triggers long data loading, the action orchestration subunit adds control steps such as "waiting for the loading prompt to disappear" or "polling for changes in the status of specific page elements" to the action template, and associates the maximum waiting time parameter with the timeout threshold field in the environment configuration, thereby matching different network latency conditions in different test environments. When handling operation keywords that may cause pop-ups, the action orchestration subunit appends an action segment of "detecting and switching to the pop-up context—performing a confirmation or cancellation action—returning to the original window" to the end of the action sequence, combined with the expected description of the pop-up content in the terminal assertion field, to provide a basis for subsequent result collection and assertions.

[0041] In one embodiment, the action orchestration subunit supports action sequence expansion based on scenario-level keywords. For example, a test engineer might mark certain steps in a structured test instruction list as "batch distribution of trusted policies" or "import trusted whitelist configuration." The action orchestration subunit can identify such scenario-level keywords in the keyword mapping rule table, extract a multi-step action sequence from the scenario action template library, break it down into multiple atomic actions, and insert them sequentially into the action sequence of the current test case, while maintaining a continuously increasing step number field. Scenario-level keyword action sequences can include multiple interface operation steps such as menu navigation, list filtering, file selection, and confirmation distribution, allowing test engineers to drive the automated execution of complex business scenarios by simply filling in a scenario keyword in an Excel test case file. After completing keyword mapping and action sequence orchestration for each structured instruction and page element location combination item, the action orchestration subunit generates corresponding action sequence entries. These entries include instruction sequence identifier fields, environment identifier fields, test case number fields, step number fields, page element location expression fields, action sequence description fields, synchronization control parameter fields, exception handling strategy fields, and screenshot control fields.

[0042] After all combined entries have undergone keyword mapping and action sequence orchestration, the action orchestration subunit reorders all action sequence entries according to the instruction sequence identifier field and organizes them into an operation keyword mapping action sequence set. In this invention, the operation keyword mapping action sequence set is the core internal data structure of the page element positioning and Selenium-driven trusted management platform interface operation module, serving as the direct input for driving the browser to perform automated operations. The operation keyword mapping action sequence set is not only used by the browser-driven execution unit in step S230, but its action sequence description field and synchronization control parameter field can also be used in subsequent extended schemes to generate visual execution trajectories, support breakpoint continuation testing, and replay functions. As an output field of this step, the operation keyword mapping action sequence set is explicitly passed to S230, the execution unit that performs browser-driven execution and interface operation result acquisition processing on the operation keyword mapping action sequence set. It is interconnected with the preceding structured instruction and page element positioning combination set, as well as the subsequent trusted management platform interface operation execution record structure, through the instruction sequence identifier field, forming a complete execution chain.

[0043] S230. Perform browser-driven execution and interface operation result collection and processing on the operation keyword mapping action sequence set to generate a trusted management platform interface operation execution record structure. After the action orchestration subunit completes the construction of the operation keyword mapping action sequence set, the browser-driven execution subunit in the page element positioning and Selenium-driven trusted management platform interface operation module begins its work. The browser-driven execution subunit integrates automated access capabilities based on the Selenium WebDriver browser driver component (Selenium WebDriver), enabling control over mainstream browser instances to start, close, switch windows, and perform interactive operations on the test execution terminal. Specifically, upon receiving the operation keyword mapping action sequence set and the access endpoint and authentication credential fields from the test environment input set, the browser-driven execution subunit first initializes the browser instance based on the environment identifier field, sets the proxy server configuration field, timeout threshold field, and default wait time field, and then accesses the login entry page of the trusted management platform under test. Based on the predefined login action sequence, the browser-driven execution subunit reads the page element positioning expression field from the internal login template, executes a set of fixed actions on the username input box, password input box, and login button, writes the login account field and login password field from the test environment input set into the corresponding controls, and triggers the login action. After login is complete, the main interface of the trusted SIS management platform is entered.

[0044] Upon entering the main interface, the browser-driven execution subunit schedules action sequence entries one by one according to the instruction sequence identifier field in the action sequence set mapped by the operation keyword. For each action sequence entry, the browser-driven execution subunit first locates the target control in the current browser context based on the page element location expression field and the frame path field. When it is necessary to switch the context of an embedded frame or pop-up, it first switches to the corresponding level according to the frame path field before executing subsequent actions. After the control is successfully located, the browser-driven execution subunit executes the corresponding operations in the order of atomic actions recorded in the action sequence description field. Atomic actions include waiting for an element to become visible, waiting for an element to become clickable, moving the mouse to an element, single-clicking, double-clicking, right-clicking, entering text, clearing text, selecting from a drop-down list, dragging, hovering, uploading a file, switching tabs, confirming a pop-up, and canceling a pop-up. For action sequences containing synchronization control parameter fields, the browser-driven execution subunit performs a step of waiting for the page state to stabilize after the critical action, such as polling the visibility changes of a specific loading indicator element or checking the row count changes of a table area, and maintaining a waiting state until the synchronization condition or timeout threshold field is reached.

[0045] During the execution of each atomic action, the browser-driven execution subunit monitors for anomalies such as invisible controls, missing controls, click interception, and failed text input through an exception handling mechanism. Upon an anomaly, it immediately determines whether to retry, skip the action, or interrupt the current test case execution based on the exception handling strategy field in the action sequence entry. The exception information, along with the current page screenshot, page element location expression field, and test case number field, is recorded as an exception event in the execution log buffer for use in constructing the subsequent trusted management platform interface operation execution record structure. When a step marked with a screenshot flag in the action sequence entry ends, the browser-driven execution subunit actively invokes the screenshot function, saving the image of the current trusted SIS management platform interface to the location specified in the log output directory field, and writing the screenshot file path field into the execution event record, forming visual evidence of the interface state.

[0046] In one embodiment, for a typical trusted policy distribution scenario in a trusted SIS management platform, the operation keyword mapping action sequence set includes multiple action sequence items such as "open the policy management menu," "filter target policy," "edit policy details," "select terminal range," "distribute policy," and "view distribution result prompts." When processing this scenario, the browser-driven execution subunit first performs multi-level menu expansion and click operations through the menu navigation action sequence items to enter the policy management page; then, according to the filter action sequence items, it enters the policy name in the filter condition area and triggers a query, waiting for the list data to refresh; next, according to the edit action sequence items, it locates the edit button in the row where the target policy is located, performs a click action to enter the details page, and selects the target terminal according to the select terminal range action sequence items on the details page; finally, according to the distribute policy and view distribution result prompts action sequence items, it performs the policy distribution operation and monitors the page prompt information. At the end of each operation, the browser-driven execution subunit integrates information such as whether the execution was successful or not, page state snapshot, current URL, current window handle, use case number field, and step sequence number field into a single execution event and appends it to the trusted management platform interface operation execution record buffer.

[0047] Once all action sequence entries in the action sequence set mapped to the operation keyword have been scheduled and completed by the browser-driven execution subunit or interrupted due to an exception, the browser-driven execution subunit aggregates and standardizes the execution events accumulated in the execution log buffer. Aggregation sorts the execution events according to the use case number field, step number field, and instruction sequence identifier field. Multiple execution events belonging to the same use case are combined into a use case execution record unit. In each use case execution record unit, in addition to storing step-by-step events, use case-level summary fields are generated, such as the use case start time field, use case end time field, and first exception type field. Standardization aligns different types of execution event fields to a unified execution record structure. For example, control positioning failure events, action execution exception events, and page prompt mismatch events are uniformly mapped to the execution result status field and exception details field, while retaining references to the screenshot file path field and the browser console log extract field.

[0048] Through the aforementioned aggregation and standardization processes, the browser-driven execution subunit generates the trusted management platform interface operation execution record structure. This structure is organized into multiple test case execution record units. Each unit expands upon one or more test case number fields in the structured test instruction list, recording the corresponding interface operation execution process and status. As an output field of this step, the trusted management platform interface operation execution record structure is directly input into the terminal request construction and sending processing unit in step S310. This unit extracts operation results related to terminal interaction and generates a trusted functional terminal request set. Simultaneously, the execution result status field and exception details field in the trusted management platform interface operation execution record structure can be referenced by the result comparison and log report generation module in step S400, used to display the interface-side execution status and exception location information in the test log and report output structure.

[0049] In summary, the technical effects of this step are as follows: Through the processing link from S210 to S230, the page element position field and operation keyword field in the structured test instruction list are automatically converted into action sequences adapted to the Selenium WebDriver browser driver component. Batch execution and fine-grained result collection are completed on the real interface of the Trusted SIS Management Platform, forming a structured interface operation execution record structure of the Trusted Management Platform. This enables the testing tool to replay complex business scenarios without having to manually write scripts line by line, and provides complete and traceable interface-side execution evidence for subsequent terminal linkage and result comparison.

[0050] Step S300 includes at least steps S310-S330: S310. Obtain the operation execution record structure of the trusted management platform interface, construct and send terminal requests, and obtain the trusted function terminal request set. In this embodiment, the trusted function terminal linkage execution and result acquisition module is deployed within the test execution terminal or an independent middleware node. After the terminal request construction subunit in this module detects that the page element location and the trusted management platform interface operation execution record structure output by the Selenium-driven trusted management platform interface operation module are ready, it automatically initiates the processing flow according to preset trigger conditions. The trusted management platform interface operation execution record structure consists of multiple test case execution record units. Each test case execution record unit includes fields such as test case number, step number, operation keyword, page element location expression, execution result status, exception details, page screenshot path, current session identifier, and environment identifier. It may also include extended fields such as policy identifier, terminal range selection, trusted function type, and order parameter fields. The terminal request construction subunit first filters out interface operation steps that have been successfully executed and have terminal linkage significance based on the execution result status field, such as "issue trusted policy", "issue static trusted verification task", "issue dynamic trusted monitoring task", "synchronize trusted whitelist", "enable process protection", "update application access control policy", etc. It identifies the operation intent that needs to be issued to the SIS terminal by matching the operation keyword field and trusted function type field.

[0051] Specifically, the terminal request construction subunit takes the selected execution record entries as input and maps different interface operations to standardized terminal action types through a step mapping rule table. The terminal action type field includes at least trusted startup actions, static trusted verification actions, dynamic trusted verification actions, trusted whitelist issuance actions, process protection configuration actions, and application access control configuration actions. For each execution record entry that requires terminal linkage, the terminal request construction subunit extracts the policy identifier field, terminal scope selection field, and order parameter field, and combines them with the environment identifier field and the current session identifier field to construct the terminal request header field. The terminal scope selection field can be generated by checkboxes, multi-select lists, or tree structures on the interface. It has already been recorded in the execution record through screenshots and event sequences. The terminal request construction subunit parses a set of terminal identifier lists based on this field. Each item in the terminal identifier list can be in the form of a terminal IP address, terminal logical number, or a combination of process unit number and terminal number. The policy identifier field is used to mark the trusted policy targeted by this issuance operation, such as trusted startup policy number, static trusted measurement rule number, dynamic behavior monitoring policy number, whitelist version number, protected process set number, and application access control rule set number.

[0052] When constructing terminal request content, the terminal request construction subunit selects the corresponding terminal request template based on different terminal action types. The terminal request template predefines structures such as action type field, protocol type field, target terminal identifier field list, policy identifier field, and parameter field, and also includes control parameters such as timeout parameters, retry limit, and request priority. The terminal request construction subunit fills the policy identifier field and the downlink order parameter field into the parameter field of the terminal request template, fills the target terminal identifier field with the terminal identifier list, and fills the environment identifier field and the current session identifier field into the session context field, thus forming a complete terminal request entry. For the same action executed on multiple terminals within the same use case execution record unit, the terminal request construction subunit can construct batch terminal requests, merging multiple terminal identifiers into the same terminal request entry and setting a batch flag field, or splitting it into several single terminal requests according to the configuration policy, numbering them separately, and recording parent-child relationships.

[0053] After constructing the terminal request entries, the terminal request construction subunit assembles these entries into a Trusted Functional Terminal Request Set. The Trusted Functional Terminal Request Set uses the use case number and step sequence number fields as primary keys to associate each terminal request entry with its corresponding interface operation execution record, forming a mapping link from interface-side operations to terminal-side actions. During the sending phase, the terminal request construction subunit calls the terminal communication adaptation subunit, which is responsible for selecting the appropriate communication channel based on the architecture of the system under test. The terminal communication adaptation subunit can interface with the terminal management interface or message middleware interface within the Trusted SIS management platform, or directly connect to the terminal proxy communication gateway, setting the corresponding transmission destination field and encoding method field in each terminal request entry. Sending actions are scheduled according to the request priority field and time sequence field of the terminal request entry, encoding the request content and writing it into the network sending queue, and recording the sending time, number of target terminals, protocol type, and initial response status for each sending operation.

[0054] In one embodiment, the trusted SIS management platform employs a message queue structure between the central management server and the on-site SIS terminal agent program. The terminal communication adaptation subunit interfaces with this message queue and sends terminal request entries to the corresponding topic or channel using a preset topic name or channel identifier field. During the sending process, if the message queue reports an anomaly, such as connection failure, insufficient permissions, or a full queue, the terminal communication adaptation subunit writes the anomaly information along with the corresponding terminal request entry identifier into the terminal request sending anomaly record and resends it according to the retry limit field. If the limit is exceeded, the terminal request entry is marked as a sending failure and is still stored in the trusted functional terminal request set for subsequent result collection and comparison as a failure criterion. After completing the sending of a batch of terminal requests, the terminal request construction subunit appends a batch number field, a time window field, and a trigger source field to the terminal request entries in that batch, enabling the subsequent raw set of terminal execution results to be collected and analyzed according to batches and time windows. In summary, step S310 identifies the trusted actions to be issued from the operation execution record structure of the trusted management platform interface, constructs and sends a trusted functional terminal request set, which is directly passed to step S320 as the input for terminal-side invocation and status acquisition processing as an output field of this step. At the same time, it is associated and used in subsequent steps S330 and S400 through the session identifier field and batch number field.

[0055] S320. Based on the trusted functional terminal request set, perform terminal-side invocation and status acquisition processing to generate the original set of terminal execution results; During the terminal-side invocation and status acquisition phase, the terminal execution agent subunit in the Trusted Functional Terminal Linkage Execution and Result Acquisition module works in conjunction with the SIS terminal agent program. The terminal execution agent subunit reads terminal request entries from the aforementioned Trusted Functional Terminal request set according to the batch number field and time sequence, and forwards the request content to the corresponding SIS terminal agent program based on the target terminal identifier list in each terminal request entry. The SIS terminal agent program typically resides on the SIS host or an industrial control host with a secure trust relationship with the SIS host, responsible for interfacing with the local trusted computing infrastructure module, policy engine module, and security monitoring module. For trusted startup actions, the SIS terminal agent program calls the local trusted startup configuration component, parses the policy identifier field and parameter field in the terminal request entry, updates the terminal's startup order, boot components, and metric point configuration, or triggers a startup metric task. For static trusted verification actions, the SIS terminal agent program calls the static metric module to perform hash metric or signature verification on the terminal's key files, configuration items, and binary image, and maps the metric results to the local trusted status identifier field. For dynamic trusted verification actions, the SIS terminal agent program calls the behavior monitoring module to match the behavior rule set according to the policy identifier field in the terminal request entry, collects and judges process behavior, system call records and network connections, and generates dynamic event sequences and judgment result fields.

[0056] For trusted whitelist issuance, the SIS terminal agent calls the whitelist management module to write the rule set into the local whitelist storage area based on the whitelist version number and rule content in the terminal request entry, and triggers the whitelist activation action. For process protection configuration, the SIS terminal agent calls the process protection module to load the process list corresponding to the protected process set number in the terminal request entry into the protection rules, and monitors the creation, termination, and injection behavior of critical processes. For application access control configuration, the SIS terminal agent calls the application access control module to load access control rules based on the policy identifier field, and performs permission judgment on the behavior of applications running on the terminal accessing the file system, network resources, and critical interfaces. During execution, the above local modules control the execution rhythm according to the timeout parameter field and retry policy field in the terminal request entry, and return an exception code field and an exception description field when an exception occurs.

[0057] After issuing a terminal request entry to the SIS terminal agent program, the terminal execution agent subunit continuously monitors the execution status messages returned by the terminal through the terminal communication adaptation subunit. Each terminal status message includes fields such as terminal identifier, action type, request identifier, execution result status, static measurement result, dynamic behavior event, whitelist update result, process protection status, application access control status, timestamp, and local log path. The terminal execution agent subunit associates these status messages with the original terminal request entry according to the request identifier and terminal identifier fields. When it detects that all target terminals corresponding to a certain terminal request entry have returned status messages, or the end time specified by the time window field has been reached, the terminal execution agent subunit considers the terminal execution process corresponding to that terminal request entry to have ended and begins to aggregate the relevant status messages. During the aggregation process, the execution result status fields of multiple terminals are organized into a terminal result list, and the static measurement result, dynamic behavior event, whitelist update result, process protection status, and application access control status fields are archived into their respective result subsets. The local log path field associated with each terminal status message is recorded for subsequent tracing.

[0058] The terminal execution agent subunit also undertakes anomaly collection and compensation during the result collection process. For example, if some terminals fail to return status messages or report communication errors for an extended period, the terminal execution agent subunit triggers a certain number of retry actions based on the retry policy field in the terminal request entry. If the retry still fails, the terminal identifier is added to the timeout terminal list, and an execution result record with a timeout status is generated for that terminal. For the log information returned by the terminal, the terminal execution agent subunit can asynchronously pull key segments in the background through the log collection component and record the storage path of the log segment matching the request identifier field in the terminal execution result record. Through the above process, the terminal execution agent subunit forms the terminal execution result raw record unit. Each record unit corresponds to one terminal request entry and stores the terminal request header field, target terminal identifier list, action type field, terminal result list, static measurement result summary field, dynamic behavior event summary field, whitelist update result summary field, process protection status summary field, application access control status summary field, anomaly statistics field, and log path set field, etc.

[0059] In one embodiment, the test engineer designed a static trusted verification regression test for twenty SIS terminals within a factory area using a structured test instruction list. After constructing and sending batch static trusted verification terminal request entries in step S310, the terminal execution agent subunit receives twenty terminal status messages in step S320. The message content includes the static metric summary, metric difference indication, execution time, error code, and local log location of each terminal. The terminal execution agent subunit merges these twenty status messages into a single terminal execution result raw record unit according to the request identifier field. It records the static metric status of each terminal in the terminal result list, records the total number of differences and difference types in the static metric result summary field, records the number of timeout terminals and the number of failed terminals in the anomaly statistics field, and organizes the local log locations of each terminal into the log path set field. All terminal execution result raw record units are combined into a terminal execution result raw set in the order of request generation. The raw set of terminal execution results is used as the output field of step S320. It is directly passed into step S330 in the data flow direction. It is consumed by the management platform's back processing and field standardization sub-unit. At the same time, it is associated with the request set of the preceding trusted function terminal and the operation execution record structure of the trusted management platform interface through the request identifier field and the session identifier field, so as to provide raw terminal-side data for result comparison and log report generation in step S400.

[0060] S330. The original set of execution results from the terminal is processed by the management platform for organization and field standardization to generate a trusted linkage result set structure. During the management platform's feedback processing and field standardization phase, the result collection and standardization subunit in the trusted functional terminal linkage execution and result acquisition module takes the original set of terminal execution results as input. Combining this with the trusted management platform's interface operation execution record structure and the trusted functional terminal request set, it completes the reorganization and standardization of terminal results from the management platform's perspective. The result collection and standardization subunit first queries the corresponding terminal request entries in the trusted functional terminal request set based on the request identifier, use case number, and step sequence number fields in the original set of terminal execution results. From these, it reads the action type, policy identifier, target terminal identifier list, and batch number fields. Simultaneously, the result collection and standardization subunit searches for matching interface operation execution records in the trusted management platform's interface operation execution record structure using the session identifier and use case number fields. It then pairs the interface-side execution result status, page screenshot path, and exception details fields with the original terminal execution result record unit. Through this matching process, the result collection and standardization subunit obtains a three-way related view: the interface-side execution record, the terminal request entries, and the original terminal execution result record.

[0061] After establishing the three-way association view, the result collection and standardization subunit divides different trusted function views according to the action type field, such as trusted startup view, static trusted verification view, dynamic trusted verification view, trusted whitelist view, process protection view, and application access control view. For each view, the result collection and standardization subunit constructs corresponding field standardization mapping rules, mapping the static measurement result summary field, dynamic behavior event summary field, whitelist update result summary field, process protection status summary field, and application access control status summary field in the original record of the terminal execution result to uniformly named trusted status fields and event fields. For example, in the static trusted verification view, the local fields "measurement pass flag," "number of difference files," and "list of difference file paths" returned by the terminal are mapped to uniform static trusted status fields, difference count fields, and difference file list fields; in the dynamic trusted verification view, the event count field, alarm number field, and behavior summary field returned by the terminal are mapped to uniform dynamic alarm count fields, dynamic alarm number list fields, and dynamic behavior summary fields. During the field standardization process, the result collection and standardization subunit also performs unified time zone conversion and format standardization on the timestamp field, generates a unified format event time field, and associates the interface operation time and terminal execution time with the time anchor field of the management platform, providing a basis for subsequent checks on timing consistency and policy effectiveness order.

[0062] Furthermore, when constructing trusted linkage result entries, the result collection and standardization subunit combines the interface-side execution result status field with the terminal-side trusted status field to generate a linkage status summary field; it merges the batch number field, environment identifier field, and target terminal identifier list into an execution scope description field; and it integrates the page screenshot path field and log path set field into an evidence resource field. For records with abnormal situations, such as successful execution on the interface side but a failure status returned on the terminal side, or a timeout returned on the terminal side but no corresponding prompt on the interface side, the result collection and standardization subunit records an exception type field in the trusted linkage result entry. The exception type field is represented by a unified set of enumerated values, such as policy issuance exception, static measurement exception, dynamic behavior exception, whitelist synchronization exception, process protection exception, and application access control exception, etc., and records the triggering conditions and key field summaries that caused the exception in the exception description field. During the field standardization process, if a field is found to be missing or the format is incorrect in the original record of the terminal execution result, the result aggregation and standardization sub-unit will fill it in using the missing field marking and default value filling strategy. At the same time, this situation will be written to the standardization exception log, and the standardization exception log path will be included in the evidence resource field for subsequent manual analysis.

[0063] In one embodiment, for the aforementioned static trusted verification regression test of twenty SIS terminals, the original set of terminal execution results includes a batch execution record unit, which records the static measurement results of the twenty terminals. The result collection and standardization subunit finds the corresponding terminal request entry through the request identifier field and batch number field, and then finds the static verification trigger button click record on the interface through the use case number field and step sequence number field, merging the three-party data. Subsequently, the result collection and standardization subunit converts the measurement results of each terminal into a unified static trusted status field and difference count field according to the field mapping rules of the static trusted verification view, and records the overall pass status and the number of terminals with differences in this batch verification in the linkage status summary field, and records the identifiers of all terminals participating in the verification in the execution scope description field. If some terminals do not return results within the specified time window, the result collection and standardization subunit marks the terminal as timeout in the trusted linkage result entry, marks it as a static trusted verification timeout exception in the exception type field, and records the relevant log location and interface screenshot location in the evidence resource field. After the above processing, all batches of static trusted verification, dynamic trusted verification, policy distribution, whitelist synchronization, process protection, and application access control activities are converted into trusted linkage result entries with unified structure and clear semantics.

[0064] The results aggregation and standardization subunit sorts all trusted linkage result items by time sequence, use case number field, and action type field, forming a trusted linkage result set structure. This trusted linkage result set structure facilitates viewing the entire linkage chain by use case dimension and supports aggregated queries by terminal dimension or action type dimension, providing a comprehensive view across interface operations, terminal requests, and terminal execution results. As an output field of step S330, the trusted linkage result set structure is directly input into step S410. The expected result field alignment and comparison input construction processing unit references the trusted status field, linkage status summary field, and exception type field when constructing the result comparison input set. Simultaneously, through the evidence resource field, step S430 uses it to generate a test log and report output structure containing interface screenshots and log links, thus playing a crucial role in the entire test loop.

[0065] In summary, the technical effects of this step are as follows: Through the combined action of S310, S320, and S330, a set of trusted functional terminal requests is constructed based on the operation execution record structure of the trusted management platform interface. On the terminal side, unified invocation and status collection of actions such as trusted startup, static trusted verification, dynamic trusted verification, trusted whitelist, process protection, and application access control are completed. From the perspective of the management platform, the terminal execution results are organized and the fields are standardized to form a unified and traceable trusted linkage result set structure. This provides a fine-grained and cross-verifiable linkage data foundation for subsequent result comparison and test report generation.

[0066] Step S400 includes at least steps S410-S430: S410. Obtain the structure of the reliable linkage result set, perform expected result field alignment and comparison input construction processing, and obtain the result comparison input set; In this embodiment, the expected result field alignment and comparison input construction subunit runs in the result processing module of the test execution terminal. When it is detected that the trusted linkage result set structure generated in the preceding S330 has been written into the shared data area and the structured test instruction list structure is in a ready state, the scheduling control unit automatically starts the S410 processing flow according to the preset trigger conditions. Specifically, the expected result field alignment and comparison input construction subunit first reads each trusted linkage result entry from the trusted linkage result set structure according to the test case number field, step number field, and action type field. The trusted linkage result entry includes at least the trusted status field, linkage status summary field, exception type field, execution scope description field, evidence resource field, environment identifier field, and batch number field. At the same time, the expected result field alignment and comparison input construction subunit reads the expected result field, terminal assertion field, and optional interface assertion field corresponding to the same test case number field and step number field from the structured test instruction list structure generated in the preceding S130. If necessary, it also reads the precondition field and test case type field associated with the test case. Through the above dual-source reading action, the expected result field alignment and comparison input construction sub-unit internally constructs the expected result side view and the actual result side view. The expected result side view is mainly based on the structured test instruction list structure, while the actual result side view is mainly based on the trusted linkage result set structure. They are associated one-to-one through the test case number field, step number field, action type field, and environment identifier field.

[0067] Furthermore, the expected result field alignment and comparison input construction subunit executes field-level alignment strategies for different types of expected result fields. For interface expected result fields, such as expected page prompts, expected button states, and expected list row numbers, the expected result field alignment and comparison input construction subunit parses the text descriptions or conventionally formatted assertion expressions from the structured test instruction list structure, breaks them down into assertion type subfields, target object identifier subfields, and target value subfields, and then determines the corresponding fields for that type of assertion in the actual results based on the interface screenshot path pointed to by the evidence resource field in the trusted linkage result set structure and the execution result status field in the interface operation execution record. For terminal expected result fields, such as expected static measurement status, expected dynamic alarm quantity, expected whitelist activation flag, expected process protection status, and expected application access control status, the expected result field alignment and comparison input construction subunit extracts the expected value descriptions from the terminal assertion fields in the structured test instruction list structure and maps them to the static trusted status fields, dynamic behavior summary fields, whitelist update result fields, process protection status fields, and application access control status fields in the trusted linkage result set structure. This mapping process is accomplished through a field alignment rule table, which is prepared in advance by test engineers during the test tool deployment phase. The field alignment rule table is used to define the correspondence between "expected field names" and "actual field names", as well as the comparison strategy type used for each correspondence, such as exact equality, inclusion relationship, set equality, ordered or unordered list comparison, and range comparison.

[0068] When performing field alignment, the expected result field alignment and comparison input construction subunit also considers differences in version and environment dimensions. Specifically, using the instruction version number field in the structured test instruction list structure and the environment configuration version number field in the trusted linkage result set structure, the expected result field alignment and comparison input construction subunit selects the corresponding version's mapping rule group in the field alignment rule table, thereby handling differences in field naming and meaning between different management platform versions or policy versions. In scenarios where a field is missing or its meaning changes, the expected result field alignment and comparison input construction subunit will decide whether to ignore the field, use a downgraded comparison method, or generate a field incompatibility flag based on the compatibility flag in the mapping rule, and record the relevant information in the alignment anomaly description field. In this way, the expected result field alignment and comparison input construction subunit can uniformly describe the expected results and actual results under different versions and environments, providing sufficient contextual information for subsequent comparison modules.

[0069] After field alignment is completed, the expected result field alignment and comparison input construction subunit constructs comparison entries based on each successfully matched expected result field and actual result field. Each comparison entry includes at least the following fields: test case number, step number, assertion number, assertion type, expected result, actual result, comparison strategy, tolerance configuration, exception priority, environment identifier, batch number, and evidence reference. The assertion number field marks the order of multiple sub-assertions within the same test case and step; the comparison strategy field records the comparison method to be used; the tolerance configuration field records tolerance settings such as ignoring string case, handling whitespace, numerical deviation range, and time offset range; and the evidence reference field is used to quickly locate screenshots, terminal logs, or other evidence resources in subsequent reports. When constructing comparison entries, the Expected Result Field Alignment and Comparison Input Construction Subunit also sets default comparison strategies based on the test case type field and action type field. For example, for "Static Trusted Verification" test cases, the default comparison method is a complete equality comparison of the static trusted status field; for "Dynamic Behavior Monitoring" test cases, the default comparison method is a comparison method where the number of alarms is not less than the expected number or the alarm content contains the expected keywords; for "Whitelist Issuance" test cases, the default comparison method is a combination of whitelist version number matching and valid entry number matching. When necessary, test engineers can also explicitly specify the comparison strategy and tolerance configuration of certain assertions in the Excel test case file through a dedicated column. The Expected Result Field Alignment and Comparison Input Construction Subunit has high priority for these explicit configurations when constructing comparison entries.

[0070] In one embodiment, for the "batch static trusted verification" use case, the expected result field in the structured test instruction list structure is described as "all target terminals pass static measurement and the difference count is zero," and the terminal assertion field records "static measurement status = passed; difference count = 0." The corresponding static trusted status field in the trusted linkage result set structure records the measurement result for each terminal, and the difference count field records the number of difference files for each terminal. When performing field alignment, the expected result field alignment and comparison input construction subunit splits the expected result field into two assertions: one corresponding to the static trusted status field and the other to the difference count field. Simultaneously, in the comparison strategy field, it sets an aggregation strategy of "all passed" for the static trusted status field and an aggregation strategy of "all zero" for the difference count field. For terminals that time out in the actual results, the expected result field alignment and comparison input construction subunit marks the terminal as "no result returned" in the comparison entry and assigns a corresponding level in the exception priority field. These comparison entries are ultimately stored uniformly in the result comparison input set, forming input data that the S420 can match one by one and generate pass markers. In summary, the output field of step S410 is the result comparison input set. This result comparison input set is directly passed to the line-by-line matching and tag generation processing unit in step S420 as its sole comparison input source. At the same time, it is referenced by the test log and HTML test report generation module in step S430 to display detailed assertion-level comparison information and evidence links in the report.

[0071] S420. Extract the expected result fields and actual result fields from the result comparison input set, perform line-by-line matching and tag generation processing, and generate a test case pass decision list; In this embodiment, the item-by-item matching and tag-based generation subunits are also deployed in the result processing module of the test execution terminal. When the result comparison input set output by S410 is detected as complete and marked as consumable in the metadata, the scheduling control unit calls the comparison engine component to start the S420 processing flow. The item-by-item matching and tag-based generation subunits first take the result comparison input set as input, sort the comparison entries according to the test case number field, step sequence number field, and assertion sequence number field, and gather the comparison entries belonging to the same test case into a test case comparison subset. For each comparison entry, the item-by-item matching and tag-based generation subunits extract the expected result field, actual result field, comparison strategy field, tolerance configuration field, and exception priority field, and perform specific matching operations according to the rules specified in the comparison strategy field. For comparison entries using the string exact equality strategy, the comparison engine performs a character-level comparison between the expected result field and the actual result field. Before the comparison, it performs preprocessing such as case normalization, removal of leading and trailing whitespace, and filtering of specific symbols according to the tolerance configuration field. For comparison entries using the "inclusion relationship" strategy, the comparison engine checks whether the actual result field contains the keyword or pattern fragment given in the expected result field. For comparison entries using the "set comparison" strategy, the comparison engine parses the expected result field and the actual result field into a set or list structure, and compares them according to whether exact consistency or only inclusion relationship is required.

[0072] When processing numerical or count fields, the line-by-line matching and tag-based generation sub-units comprehensively determine whether the comparison is a "numerical range" comparison, a "not less than expected" comparison, or a "deviation within a threshold range" comparison based on the comparison strategy field and the tolerance configuration field. For example, for dynamic alarm count assertions, the comparison strategy field can specify that a match is considered successful if the actual alarm count is greater than or equal to the expected alarm count; for response time or execution time assertions, the comparison strategy field can specify that a match is considered successful if the actual value is less than or equal to the expected upper limit or within a certain preset range, while the tolerance configuration field provides the upper and lower bounds of that range. For timestamp or time interval fields, the comparison engine combines the time zone information in the environment identifier field to perform time conversion on the expected result field and the actual result field, and determines whether a match is achieved within the time offset range specified by the tolerance configuration field. Under any strategy, if the actual result field is missing or marked as "not returned," the line-by-line matching and tag-based generation sub-units will determine whether to mark the assertion as failed, unverified, or ignored based on the exception priority field, and generate the corresponding status field internally for statistical analysis during subsequent use case-level aggregation.

[0073] After the assertion-level matching results are determined, the match-by-match and pass-mark generation subunit generates an assertion-level decision record for each comparison entry. This record includes an assertion result field, an assertion status description field, an assertion-level exception flag field, and inherited information from the evidence reference field. The assertion result field typically uses status values ​​such as pass, fail, or unverified. The assertion status description field describes the specific reasons for the mismatch, such as "actual result is empty," "actual value is not equal to expected value," "actual alarms are fewer than expected alarms," ​​or "terminal did not return results." Then, the match-by-match and pass-mark generation subunit aggregates the assertion-level decision records within the use case comparison subset according to the use case number field, constructing a use case-level decision unit. In addition to all assertion-level decision records, the use case-level decision unit also includes summary information such as the use case-level pass flag field, the number of failed assertions, the number of unverified assertions, the highest exception priority field, the use case start time field, the use case end time field, and the environment identifier field. The generation of test case-level pass / fail fields is based on a set of configurable rules. For example, it can be stipulated that if any assertion-level judgment record is deemed unqualified, the test case-level pass / fail field will be set to fail, or that a certain number of low-priority exceptions will still be considered as a pass for the entire test case. These rules can be configured in the test tool configuration file or Excel test case file. The matching and pass / fail generation sub-unit reads the relevant configuration at runtime and applies it to all test case-level aggregation processes.

[0074] In one embodiment, for the "batch static trusted verification" use case, the result comparison input set contains forty comparison entries, including static metric status assertions and difference count assertions from twenty terminals. The match-by-match and mark generation subunit compares each comparison entry according to the assertion sequence number field and the terminal identifier. For static metric status assertions, an "all passed" aggregation strategy is used, meaning an assertion match is considered successful only if the static trusted status field of all terminals is passed. For difference count assertions, an "all zero" aggregation strategy is used, meaning an assertion match is considered successful only if the difference count field of all terminals is zero. If the static metric status of a terminal fails, the corresponding assertion-level judgment record is marked as failed, and the terminal identifier and reason for failure are recorded in the assertion status description field. During use case-level aggregation, the use case-level pass mark field is set to failed, and the number of failed assertions is recorded as at least 1. The highest exception priority field is filled according to the exception priority field of the failed assertion. In another embodiment, for the "Dynamic Behavior Monitoring" use case, the expected result field specifies that a specific type of alarm must occur at least once. The dynamic behavior summary field records all actual alarm information. The matching and tag generation sub-unit checks whether the expected alarm type exists in the actual alarm list according to the "contains keyword" comparison strategy. If it exists, a passed assertion result field is generated; otherwise, a failed assertion result field is generated.

[0075] After all test case-level decision units are constructed, the matching and tag generation sub-unit sorts these test case-level decision units according to the test case number field, environment identifier field, and batch number field to form a test case pass decision list. Logically, the test case pass decision list is a table recording the execution results of all test cases, including test case-level pass tag fields, assertion-level decision details, anomaly statistics, and evidence citation information. It serves as direct input for the subsequent test log aggregation and HTML test report generation modules to generate summary and detailed views. In the data flow, the test case pass decision list is passed to step S430 as an output field of step S420, and is referenced by the log aggregation and report generation sub-unit when generating the test log and report output structure. Simultaneously, the test case-level pass tag fields in the test case pass decision list can also be used as a decision reference for automated test pipelines in external systems, such as deciding whether to trigger the next round of regression testing or whether to freeze the current trusted policy version.

[0076] S430. Perform log summarization and HTML test report generation for test cases using the decision list, and generate test log and report output structure. In this embodiment, the log aggregation and HTML test report generation subunit runs in the output management module of the test execution terminal. When a test case is generated through the decision list and marked as outputtable, the output management module calls the log aggregation and HTML report engine component to initiate the S430 processing flow. The log aggregation and HTML test report generation subunit first reads all test case-level decision units from the test case decision list, and establishes a correlation between the structured test instruction list structure, the trusted management platform interface operation execution record structure, and the terminal execution result raw set through the test case number field and the environment identifier field, thereby obtaining the multi-source log information generated by each test case during execution. Specifically, the log aggregation and HTML test report generation subunit searches for corresponding interface operation execution records in the trusted management platform's interface operation execution record structure using the use case number field, step sequence number field, and instruction sequence identifier field. This includes the execution result status field, exception details field, and page screenshot path field. Using the request identifier field and batch number field, it searches for corresponding terminal execution result records in the original set of terminal execution results. This includes the static measurement result summary field, dynamic behavior event summary field, whitelist update result summary field, process protection status summary field, and application access control status summary field. Finally, using the evidence resource field and log path set field, it searches for the actually stored interface screenshot files and terminal log files in the file system. This multi-source information is aggregated into an internal log aggregation buffer, serving as the raw material for subsequent report rendering.

[0077] During the log aggregation phase, the log aggregation and HTML test report generation subunit sorts the execution events according to the test case number and step sequence number fields. It combines the interface operation execution records and terminal execution result records into a time-series view. Each row in the time-series view records a key event's timestamp field, event type field, event description field, relevant assertion identifier field, and evidence reference field. For events with exceptions, the log aggregation and HTML test report generation subunit merges the execution result status field and exception details field in the event description field, and simultaneously references the interface screenshot and terminal log path in the evidence reference field for correlation analysis during subsequent report viewing. The log aggregation and HTML test report generation subunit also generates summary log entries at the test case level. These summary log entries record information such as test case level pass / fail fields, number of failed assertions, number of unverified assertions, highest exception priority field, test case start time field, and test case end time field. They also use environment identifier and batch number fields to mark the test environment and execution batch to which the test case belongs. If necessary, the log summary and HTML test report generation subunit can also write the access endpoint field, authentication credential anonymization identifier field, and environment configuration version number field from the test environment input set into the summary log entries, thereby describing the environment state during test execution without exposing sensitive information.

[0078] During the HTML test report generation phase, the log aggregation and HTML test report generation subunit constructs a visual report model based on the aforementioned summary log entries and time-series view. This visual report model typically includes report header information, a use case summary view, an assertion-level detail view, and an evidence link view. The report header information area records fields such as the batch number, execution start and end time, the version information of the trusted management platform under test, and the environment identifier for this test. The use case summary view presents each use case-level decision unit in the use case pass decision list in tabular form, listing fields such as use case number, use case name, use case-level pass flag, number of failed assertions, highest exception priority, and environment identifier, and provides the ability to filter and sort by environment, pass status, and exception priority. The assertion-level detail view displays all assertion-level decision records for a selected use case, including assertion type, expected result, actual result, assertion result, and assertion status description, and uses color indicators or icons to indicate different assertion result statuses. The evidence link view displays screenshots and terminal log links related to the use case, which users can click to view screenshots or download log files in a browser.

[0079] Understandably, when constructing the report content, the HTML test report generation subunit avoids displaying the plaintext values ​​of sensitive fields, such as login passwords, keys, or internal IP addresses, instead employing anonymization or summary display methods. To support retrospective analysis and version management, the HTML test report generation subunit also embeds structured metadata in the report. For example, it writes the environment configuration version number, instruction version number, report generation time, and report number fields into a hidden metadata area. This metadata can be read by scripts when subsequent automated analysis or comparison of test results from different batches is needed. After the report is rendered, the HTML test report generation subunit writes the report content to the specified output directory, generates an HTML report file, and records the report file path field. Simultaneously, the log aggregation and HTML test report generation subunit serializes summary log entries and time-series views into structured log files, such as text logs or structured log formats, and records the log file path field in the test log and report output structure. The test log and report output structure typically includes fields such as HTML report file path, structured log file path, report generation time, report number, environment identifier, and batch number.

[0080] In one embodiment, for a combined test scenario of "batch static trusted verification" and "dynamic behavior monitoring" test cases, the log aggregation and HTML test report generation subunit generates a comprehensive HTML report after a test batch is completed. The report's test case summary view lists the pass status of all static verification and dynamic monitoring test cases. The assertion-level detail view clearly shows which terminals exhibited discrepancies in static metrics, which terminals failed to generate expected alarms in dynamic behavior monitoring, and the corresponding terminal identifiers, discrepancy types, and alarm numbers. The evidence link view provides screenshots of the interface and terminal log links for each abnormal assertion, allowing test engineers to review the interface operation trajectory and terminal behavior trajectory on the same page. In this embodiment, the test log and report output structure records the HTML report storage path and several log file paths, and interfaces with an external test management system through report number and batch number fields, enabling rapid location of the detailed execution status of a specific round of testing based on the report number.

[0081] In summary, the technical effects of this step are as follows: By constructing the result comparison input set in S410, generating test cases through line-by-line matching in S420, and summarizing multi-source logs in S430 to generate HTML test reports and structured log files, this invention connects information scattered in the structured test instruction list structure, the trusted linkage result set structure, and the multi-source execution records into a complete traceable link. This allows testers to obtain unified judgment results at the test case level and assertion level without manually organizing data, and to quickly locate problematic test cases and abnormal assertions through the test log and report output structure.

Claims

1. A table-based test case-driven automated testing method for a trusted SIS platform, characterized in that, include: Obtain the basic information of the trusted management platform under test and the path of the Excel test case file, organize the fields, read the openpyxl file and perform functional test case expansion to generate a structured test instruction list. Based on the structured test instruction list structure, page element position fields are extracted, page element location expressions are generated, and operation keywords are mapped to Selenium actions to generate a trusted management platform interface operation execution record structure. Based on the interface operation execution record structure of the trusted management platform, terminal request construction and sending processing are performed, and terminal-side calls and status acquisition processing are executed to generate a trusted linkage result set structure. Obtain the structure of the trusted linkage result set, perform expected result field alignment, match each item, and generate test logs and report output structure through tagging, log aggregation, and HTML test report generation.

2. The method according to claim 1, characterized in that, The basic information of the trusted management platform under test and the path to the Excel test case file include: The basic information of the tested trusted management platform includes the trusted management platform network address field, port number field, login account field, login password field, target system identifier field, and environment identifier field, as well as the proxy server configuration field, timeout threshold field, default wait time field, and log output directory field; The Excel test case file path field is specified by the test engineer according to the test plan. It points to the path of the spreadsheet file stored in the file system and is represented in the form of an absolute path or a relative path.

3. The method according to claim 1, characterized in that, The process of organizing fields also includes: The field processing includes merging the platform address field and port number field into an access endpoint field, encapsulating the login account field and login password field into an authentication credential field, and combining the environment identifier field and target system identifier field into a test target description field. It also performs network address format standardization, port number value range validity checks, log output directory path existence checks, Excel test case file path file existence checks, and access permission checks. The test results are recorded as the environment self-check status field to generate the test environment input set.

4. The method according to claim 1, characterized in that, openp The process of reading yxl and unfolding functional test cases also includes: Based on the test environment input set, Excel test case reading and processing are performed. This includes opening the Excel test case file using the openpyxl library, reading workbook metadata to obtain a list of worksheet names and starting row numbers, traversing the worksheet row by row starting from the starting row number to read cell content, distinguishing between header rows and test case data rows and marking comment rows and incomplete test case rows, and constructing the original row set of the Excel test cases. Functional test case expansion and field decomposition are then performed. Functional test case expansion includes parsing the test case type field to identify functional test case rows and ordinary single-step test case rows, referencing template test cases to generate virtual test case rows through parameter replacement and step rearrangement. Field decomposition includes mapping the original test case row cell values ​​to a logical field set including test case number, step number, page element position, operation keyword, and expected result fields. The page element position field is parsed in segments, the operation keyword field is categorized as click, input text action type, and the expected result field is split into strings and stored in a structured manner.

5. The method according to claim 1, characterized in that, The process of extracting page element position fields and generating page element positioning expressions also includes: The page element location field extraction process includes reading the page element location field, environment identifier field, test case number field, and step sequence number field. The page element location expression generation process includes performing segmented parsing to obtain page identifier fields, region identifier fields, control identifier fields, and index identifier fields, consulting the page structure configuration table to determine the page template type, and generating page element location expressions with location method fields and location parameter fields.

6. The method according to claim 1, characterized in that, The process of mapping operation keywords to Selenium actions also includes: The operation keyword mapping Selenium action processing includes finding the action template corresponding to the operation keyword, filling the target element placeholder in the action template, arranging the action sequence and attaching synchronization control fragments and error handling fragments to generate an operation keyword mapping action sequence set; performing browser-driven execution and interface operation result collection and processing. The browser-driven execution processing includes initializing the browser instance, setting proxy server configuration fields and timeout threshold fields, logging into the trusted management platform main interface, scheduling action sequence entries, and executing atomic actions for retrying or skipping; the interface operation result collection and processing includes execution record units, aligning standardized execution event fields to execution result status fields and exception details fields.

7. The method according to claim 1, characterized in that, The process of constructing and sending a terminal request also includes: The terminal request construction process includes filtering interface operation steps that have been successfully executed and have terminal linkage significance, identifying terminal action types including trusted startup actions, static trusted verification actions, dynamic trusted verification actions, trusted whitelist distribution actions, process protection configuration actions, and application access control configuration actions, extracting policy identifier fields and terminal range selection fields, and constructing terminal request entries; the entries include action type fields, protocol type fields, target terminal identifier lists, policy identifier fields, and parameter fields; The terminal request sending process includes sending a terminal request entry, recording the sending time field, and the initial response status.

8. The method according to claim 1, characterized in that, The process of terminal-side invocation and status acquisition and processing also includes: Terminal-side call processing includes executing trusted functions and returning terminal status messages. Specifically, it includes a trusted startup configuration component, a static measurement module, a dynamic behavior monitoring module, a whitelist management module, a process protection module, and an application access control module. The returned terminal status message includes terminal identifier field, action type field, execution result status field, static measurement result field, dynamic behavior event field, whitelist update result field, process protection status field, and application access control status field. The status acquisition and processing includes the execution agent subunit listening for return messages, generating the terminal execution result raw record unit, and recording the terminal result list and log path set.

9. The method according to claim 1, characterized in that, The process of aligning expected result fields and matching each record using tags also includes: The expected result field alignment process includes reading trusted linkage result entries, including trusted status field, linkage status summary field, exception type field, execution scope description field, and evidence resource field; reading expected result fields and terminal assertion fields; aligning the rule table to map expected fields and actual fields; and filling in missing or misformatted fields with default values.

10. The method according to claim 1, characterized in that, The process of log aggregation and HTML test report generation also includes Log aggregation processing includes building time-series views and summary log entries, and recording test case start time and test case end time fields; The HTML test report generation process includes building a visual report model, including report header information, use case summary view, assertion-level detail view, and evidence link view, and generating HTML report files and structured log files.

Images