Smart card test instruction data processing method, apparatus, equipment and storage medium

Abstract

This application discloses a method, apparatus, device, and storage medium for processing smart card test instruction data. The method includes: acquiring heterogeneous test logs from multiple test platforms and extracting structured instruction data; acquiring technical specification documents and test specification documents, extracting knowledge information, and constructing a knowledge graph; extracting field features and context features from the structured instruction data, extracting knowledge features from the knowledge graph, and fusing the field features, context features, and knowledge features to generate a comprehensive feature vector; classifying the comprehensive feature vector using a trained classifier to obtain instruction semantic categories; and generating an instruction library based on the structured instruction data, knowledge graph, and instruction semantic categories. This instruction library is used to assist in generating executable test instructions. This unified management of instruction information scattered across different test platforms and tools reduces the workload of script format conversion and interface adaptation, thereby lowering the integration cost of multi-platform testing.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence, and in particular relates to a method, apparatus, device and storage medium for processing smart card test instruction data. Background Technology

[0002] As security-sensitive devices, smart cards play a crucial role in finance, telecommunications, and other fields, making rigorous testing of their performance and security essential. Currently, companies commonly use third-party testing kits developed by specialized manufacturers to verify the quality of smart cards.

[0003] However, test suites from different vendors vary in terms of tool platforms, script formats, and execution interfaces, requiring enterprises to deal with multiple testing tools and scripting languages ​​simultaneously. Consequently, in practical applications, it is often necessary to develop a separate integration solution for each tool, resulting in a large integration workload, high maintenance costs, and a significant impact on testing efficiency. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for processing smart card test instruction data, which effectively reduces the integration difficulty of smart card testing and improves testing efficiency.

[0005] In a first aspect, embodiments of this application provide a smart card test instruction data processing method, the method comprising: Obtain heterogeneous test logs from multiple test platforms, and extract structured instruction data from the heterogeneous test logs; Obtain technical specification documents and test specification documents, extract and associate knowledge information from the technical specification documents and test specification documents, and construct a knowledge graph; Extract field features and context features from structured instruction data, extract knowledge features from knowledge graphs, and generate a comprehensive feature vector by fusing field features, context features, and knowledge features. The trained classifier is used to classify the comprehensive feature vector to obtain the semantic category of the instruction; Based on structured instruction data, knowledge graphs, and instruction semantic categories, an instruction library is generated to assist in the generation of executable test instructions.

[0006] Secondly, embodiments of this application provide a smart card test instruction data processing apparatus, the apparatus comprising: The log parsing module is used to obtain heterogeneous test logs from multiple test platforms and extract structured instruction data from the heterogeneous test logs. The knowledge graph construction module is used to acquire technical specification documents and test specification documents, extract and associate knowledge information in the technical specification documents and test specification documents, and construct a knowledge graph. The feature extraction module is used to extract field features and context features from structured instruction data, extract knowledge features from knowledge graphs, and generate a comprehensive feature vector by fusing field features, context features, and knowledge features. The classification module is used to classify the comprehensive feature vector using the trained classifier to obtain the semantic category of the instruction; The instruction library module is used to generate an instruction library based on structured instruction data, knowledge graphs, and instruction semantic categories. This instruction library is used to assist in generating executable test instructions.

[0007] Thirdly, embodiments of this application provide a computer device, the device including: a processor, and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the method of any one of the first aspects above.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the method of any one of the first aspects described above.

[0009] Fifthly, embodiments of this application provide a computer program product comprising a computer program that, when executed by a processor, implements the method of any one of the first aspects described above.

[0010] The technical solutions provided by the embodiments of this application have at least the following beneficial effects: The smart card test instruction data processing method provided in this application extracts structured instruction data from heterogeneous test logs and constructs a knowledge graph by combining technical specification documents and test specification documents, thereby comprehensively acquiring the semantics, rules, and execution logic of test instructions. Subsequently, a comprehensive feature vector is generated by fusing field features, context features, and knowledge features, and a trained classifier is used to identify the semantic categories of instructions, achieving accurate understanding of diverse test scenarios. Finally, an instruction library is generated based on instruction semantics and knowledge associations. This allows for unified management of instruction information scattered across different test platforms and tools, fundamentally reducing the workload of interface adaptation and script conversion between different test tools, significantly reducing the integration cost of subsequent tests, and improving the automation level and cross-platform consistency of the test process. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below.

[0012] Figure 1 This is a flowchart illustrating a smart card test instruction data processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a test log parsing process provided in an embodiment of this application; Figure 3 This is a schematic diagram of a process for constructing a knowledge graph provided in an embodiment of this application; Figure 4 This is a schematic diagram of a process control model provided in an embodiment of this application; Figure 5 This is a flowchart illustrating an anomaly annotation method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a knowledge fusion engine provided in an embodiment of this application; Figure 7 This is a schematic diagram of a knowledge graph output structure provided in an embodiment of this application; Figure 8 This is a schematic diagram of a feature extraction and fusion process provided in an embodiment of this application; Figure 9 This is a schematic diagram of an instruction generation, execution, and verification process provided in an embodiment of this application; Figure 10 This is a model diagram of a state machine provided in an embodiment of this application; Figure 11 This is a multi-dimensional analysis strategy diagram provided in an embodiment of this application; Figure 12 This is a flowchart illustrating a smart card test instruction data processing device provided in an embodiment of this application; Figure 13 This is a schematic diagram of the structure of a smart card test instruction data processing system provided in an embodiment of this application; Figure 14 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0014] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples consistent with some aspects of this application as detailed in the appended claims.

[0015] As described in the background section, existing methods for testing smart cards using third-party smart card test kits suffer from low testing efficiency, high error rates, and difficulties in integrating heterogeneous kits. To address these issues, this application provides a smart card test instruction data processing method, apparatus, device, and computer storage medium.

[0016] The smart card test instruction data processing method provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] Figure 1 A flowchart illustrating a smart card test instruction data processing method according to an embodiment of this application is shown.

[0018] like Figure 1 As shown, the method may include the following steps.

[0019] S110. Obtain heterogeneous test logs from multiple test platforms and extract structured instruction data from the heterogeneous test logs.

[0020] It should be noted that, in order to broaden the coverage of data sources, this application supports obtaining heterogeneous historical log files from multiple different testing platforms.

[0021] For example, the file type of the heterogeneous test log may include HTML, XML, etc.

[0022] In one possible implementation, different parsing and data extraction methods are used for test logs of different formats. After extracting the instruction data, it is uniformly formatted to generate structured instruction data that can be used for subsequent analysis.

[0023] S120. Obtain technical specification documents and test specification documents, extract and associate knowledge information from the technical specification documents and test specification documents, and construct a knowledge graph.

[0024] Technical specification documents are standard documents that define and constrain the architecture of smart cards.

[0025] Test specification documents are test guidance documents that describe test cases, execution processes, and expected results.

[0026] In one implementation, step S120 may include the following steps.

[0027] S121. Extract abstract definition knowledge from technical specification documents; S122. Extract specific operational knowledge from the test specification document; S123. Based on the knowledge fusion engine, abstract definition knowledge and specific operational knowledge are fused to construct a knowledge graph.

[0028] Abstract knowledge may include, but is not limited to, technical elements, instruction set definitions, and security protocol parameters. Specific operational knowledge may include, but is not limited to, instruction sequences, operational procedures, execution conditions, and expected outputs.

[0029] In implementation, the association between the two types of knowledge can be established through entity alignment and relation mapping, and then structured integration can be completed based on knowledge fusion algorithms to obtain a unified knowledge graph.

[0030] Through the above process, this implementation automatically extracts, associates, and integrates multi-source heterogeneous knowledge from different specification documents, so that the resulting unified knowledge graph not only retains the abstract and systematic knowledge structure in the technical specification documents, but also supplements the operational details in the test specification documents that are closely related to actual verification, providing semantic support for subsequent automated instruction generation.

[0031] S130. Extract field features and context features from structured instruction data, extract knowledge features from knowledge graph, and generate a comprehensive feature vector by fusing field features, context features, and knowledge features.

[0032] In this step, a comprehensive modeling of instruction semantics is achieved through multi-source feature fusion, so that each instruction has both structured semantic description and contextual behavioral features and knowledge association features.

[0033] In one implementation, regular expressions or fixed-byte parsing are used to extract instruction fields from structured instruction data to form field features. For some complex fields (such as Data fields), further feature engineering processing can be performed, such as analyzing features like data type, byte length, content entropy, or format consistency.

[0034] For example, field features may include fields such as CLA, INS, P1, P2, Lc, Data, Le, SW1, and SW2.

[0035] In one implementation, context information fields are extracted from structured instruction data. An instruction cache structure or instruction sequence queue is designed to store information on the most recently executed instructions, and the current security state is inferred based on the logical dependencies between instructions. Furthermore, by calculating the difference between the current instruction timestamp and the base time or the timestamp of the preceding instruction, time interval characteristics can be obtained to reflect the execution rhythm and temporal behavior characteristics.

[0036] For example, contextual features may include test phase markers, preceding instructions, security states, and time features.

[0037] In one implementation, the knowledge features corresponding to the instruction are queried from the knowledge graph. Based on the instruction's CLA and INS fields, a hash index is used to quickly locate the corresponding technical definition node in the knowledge graph, obtaining semantic information related to the instruction, such as instruction type definition, target object identifier, and expected response pattern. The knowledge features can originate from structured knowledge definitions in technical specifications or from empirical patterns learned from historical test data, enhancing the interpretability and consistency of the instruction's semantics.

[0038] For example, knowledge characteristics may include instruction type definition, object identifier, and expected response pattern.

[0039] Finally, the extracted field features, context features, and knowledge features are fused into a comprehensive feature vector. For example, the comprehensive feature vector describes the structural information of the instruction, the execution environment, and its knowledge associations in a hierarchical structure.

[0040] S140. Using the trained classifier, classify the comprehensive feature vector to obtain the instruction semantic category.

[0041] In this application, the classifier is pre-trained based on a training dataset. The training dataset includes historical instruction data and corresponding semantic labels. The semantic labels can be generated manually or by a semi-automatic annotation system. Through supervised learning on the training dataset, the classifier can establish a mapping relationship between the comprehensive feature vector and the semantic category of the instruction.

[0042] In practical applications, the trained classifier is used to classify and infer the comprehensive feature vector, outputting the corresponding instruction semantic category and its confidence score. For example, when the confidence score of the classification result is higher than the dynamically set confidence threshold, the current instruction is determined as the target semantic category; when the confidence score is lower than the threshold, the instruction is marked as "awaiting manual review" or "unclassifiable".

[0043] The classifier output is, for example, the instruction category label "Apply delete instruction" and the confidence score "0.92".

[0044] This classification process enables automatic semantic recognition of instructions from different sources and in different formats in test logs, effectively improving the accuracy and efficiency of instruction classification in smart card testing scenarios.

[0045] S150. Generate an instruction library based on structured instruction data, knowledge graph, and instruction semantic categories.

[0046] For example, structured instructions with similar semantics and related functions are summarized and organized to form reusable instruction templates, which constitute an instruction library. That is, the instruction library includes multiple instruction templates.

[0047] It should be understood that this instruction library can be used to assist in generating executable test instructions.

[0048] It should also be understood that the application of this instruction library is not limited to test instruction generation, but can also be used in other scenarios such as test script auto-completion and instruction consistency verification.

[0049] The smart card test instruction data processing method provided in this application extracts structured instruction data from heterogeneous test logs and constructs a knowledge graph by combining technical specification documents and test specification documents, thereby comprehensively acquiring the semantics, rules, and execution logic of test instructions. Subsequently, a comprehensive feature vector is generated by fusing field features, context features, and knowledge features, and a trained classifier is used to identify the semantic categories of instructions, achieving accurate understanding of diverse test scenarios. Finally, an instruction library is generated based on instruction semantics and knowledge associations. This allows for unified management of instruction information scattered across different test platforms and tools, fundamentally reducing the workload of interface adaptation and script conversion between different test tools, significantly reducing the integration cost of subsequent tests, and improving the automation level and cross-platform consistency of the test process.

[0050] In some embodiments, Figure 1 The embodiments may also include the following steps.

[0051] S160. Obtain the target test requirements.

[0052] The target test requirements describe the target object, operation type, and test parameters to be tested, and serve as the input basis for generating target test instructions.

[0053] S170. Generate executable target test instructions based on the target test requirements and instruction library.

[0054] This command generation method avoids the tedious process of manually writing commands one by one, reducing human error. At the same time, different testing requirements can be met through a unified command generation logic, improving the consistency and efficiency of test configurations and reducing the complexity of test preparation.

[0055] In one implementation, instruction templates are selected from the instruction library based on the operation type of the target test requirement; the instruction templates are populated based on the test parameters included in the target test requirement to generate the target test instruction and the corresponding execution script.

[0056] For example, to ensure the accuracy of the generated instructions, the test parameters can be prioritized: the parameters specified in the target test requirements have the highest priority, followed by the high-frequency parameter values ​​in historical tests, and finally the template default values.

[0057] Through the above implementation method, appropriate instruction templates can be automatically matched and parameters can be filled in according to test requirements, thereby realizing the intelligent and customized generation of test instructions. This not only avoids the tedious process of manually writing scripts, but also ensures that the generated test instructions correspond precisely to the target test requirements in terms of semantics and parameters, significantly improving the accuracy of instruction generation and execution efficiency, and realizing the automation and standardization of the test process.

[0058] Figure 2 This illustration shows a flowchart of a test log parsing process provided in an embodiment of this application. It should be understood that... Figure 2 The illustrated embodiment can be considered as an example of step S110. For example... Figure 2 As shown, the method may include the following steps.

[0059] S111 Determine the file type of the heterogeneous test log.

[0060] S112. When the heterogeneous test logs are HTML logs, the following steps can be performed: The document object model tree of the HTML log is built based on the document object model (DOM) parser; Locate key nodes in the document object model tree using the XML Path Language (XPath) query mechanism; Further filter key nodes related to directives based on compound CSS selector strategies; The first instruction data is extracted by matching the instruction content using regular expressions and performing semantic analysis on the text content of key nodes based on the context association algorithm.

[0061] Among them, key nodes can be paragraph nodes that contain instruction content.

[0062] S113. When the heterogeneous test log is an XML log, the following steps can be performed: The file structure of XML logs is validated based on an XMLSchema-based validation and parsing mechanism. XML logs are parsed based on the SAX (Simple API for XML) event-driven mechanism. Extract instruction data from XML logs.

[0063] S114. Perform normalization and multi-level verification on instruction data extracted from different types of logs.

[0064] For example, the verification may include, but is not limited to, hexadecimal character format verification, instruction length verification, and field logical consistency checks. The verification rules can be implemented using predefined regular expressions and verification functions.

[0065] S115. Determine whether the instruction data needs to be repaired.

[0066] If yes, then execute S116 and S117; otherwise, execute S118. S116, Perform intelligent repair.

[0067] For example, incomplete or abnormal instruction data can be intelligently completed and corrected based on pre-trained models or rule templates.

[0068] S117. Reconstruct timing based on instruction type.

[0069] By analyzing instruction dependencies and timestamp information, the execution order of instructions can be reconstructed, ensuring the integrity and traceability of the instruction sequence.

[0070] S118. Perform structured processing on the instruction data to obtain standardized structured instruction data.

[0071] For example, instruction data can be structured into JSON format. Each instruction object can contain: the original hexadecimal string, the decomposed field data (such as CLA / INS / P1 / P2 / LC / Data / LE / SW1 / SW2, etc.), and context information (such as test phase, operation type, timestamp, instruction sequence number, previous instruction status word, etc.).

[0072] Through the above process, this embodiment can perform unified parsing and structured conversion of heterogeneous test logs from multiple platforms, enabling high-quality extraction, verification, and standardized output of instruction data, and providing efficient and reliable data support for automated testing of smart cards.

[0073] Figure 3 This illustration shows a flowchart of a knowledge graph construction process provided in an embodiment of this application. It should be understood that... Figure 3 The illustrated embodiment can be considered as an example of step S120. For example... Figure 3 As shown, the steps may include the following.

[0074] S310. Determine the document type of the specification document.

[0075] S320. In the case of a technical specification document, perform the following operations: Technical elements are extracted by converting technical specification text into coordinate-based text data and extracting technical elements from the coordinate-based text data based on text features, layout features, and position features. Identify instruction set definitions, that is, extract structured instruction set definitions from technical specification texts; Security protocol parameter extraction involves constructing a hierarchical state machine model from physical security to lifecycle management, and then parsing the security protocol structure hierarchically based on the state machine model to extract security protocol parameters.

[0076] For example, during the technical element extraction stage, Tesseract OCR can be used to recognize the text content in technical specification documents and convert it into structured text data with text coordinates.

[0077] Textual features refer to the keyword or phrase features in technical specification documents that are related to test instructions, such as "APDU", "Management", "Secure" and other information.

[0078] Layout features refer to the characteristic information of the test instructions in terms of layout style, structural hierarchy and presentation of poetry, such as being located on the first page of a chapter and having a title font size that is more than 20% larger than the body text.

[0079] Location characteristics refer to the chapter position, page number distribution, and relative area information of the test instruction-related content in the overall structure, such as appearing between chapters 5 and 11 of the document.

[0080] By jointly analyzing the above three types of features, key areas containing instruction set definitions, parameter rules, or security protocol information can be automatically identified and located, enabling semantic structured parsing of technical specification documents.

[0081] Furthermore, the OpenCV algorithm is used to identify cross-page layout areas and accurately extract content such as instruction encoding tables and parameter definition tables from them.

[0082] The output examples are shown in Table 1 below: During the instruction set definition identification phase, the instruction set definition is transformed into a structured expression through a semantic parsing algorithm. Specifically, numerical range descriptions (such as "P1's value range is 0x00 to 0xFF") are transformed into interval expressions; enumerated values ​​(such as "INS code 0xE4 indicates a deletion operation") are transformed into key-value pairs; and conditional constraints (such as "MAC verification is required when CLA=0x84") are transformed into IF-THEN logical rules.

[0083] A conflict detection mechanism is implemented during the parsing process. When the same instruction code (e.g., INS=0xA4) is assigned different meanings in different documents, the system records the conflict location and context information, and automatically selects or prompts for manual confirmation to establish constraint relationships based on document priority (e.g., newer specifications take precedence). During the security protocol parameter extraction stage, elements including electrical parameter ranges, security channel protocol requirements, security state constraints, error handling strategies, and state transition rules are extracted from each security layer.

[0084] In summary, this step, through a combination of OCR, visual recognition, and semantic parsing, achieves automated extraction and structured modeling of technical elements, instruction set definitions, and security protocol parameters from technical specification documents. This ensures both the accuracy and completeness of information extraction and provides a high-quality data foundation for subsequent knowledge fusion and automated test generation.

[0085] S330. In the case of a test specification document, perform the following operations: parse test cases, identify test step numbers, extract expected instruction sequences, and annotate exceptions.

[0086] During the test case parsing phase, the document is segmented based on its layout features, and elements are classified according to the keyword matching table.

[0087] For example, the system can identify information such as test ID, test target, preconditions, and step description according to a preset keyword matching table, and store it in a unified data structure.

[0088] Table 2 is an example of a keyword matching table: In the test step number identification stage, regular expressions are used to identify the test step numbers, and the multi-level numbering in the test document is parsed hierarchically to establish a corresponding tree structure to reflect the parent-child relationship and execution order between test steps.

[0089] During the extraction of the expected instruction sequence, the test steps are decomposed into standard triples: <action, operation object, parameter> through action word recognition and semantic analysis. For conditional branches (if / else) or loops (for / while) structures appearing in the test cases, corresponding flow control models are established to maintain the integrity of the test logic. Figure 4 shows a schematic diagram of the flow control model, where linear steps can flow to branch nodes. Different conditions (such as condition 1 and condition 2) correspond to paths A and B, respectively. Paths A and B merge again at the merge node to form a complete test execution path.

[0090] During the specification parsing process, abnormal scenarios involved in the test specification document are marked, distinguishing between expected and unexpected anomalies, and extracting corresponding recovery strategies. Figure 5 shows a flowchart of the anomaly marking process. Expected anomalies are usually described by explicit error codes, such as SW=6985 or SW=6A80; unexpected anomalies can be identified by symptomatic descriptions, such as "card unresponsive," "communication interrupted," "reset and reconnect," etc.

[0091] This step automatically parses the test logic and expected behavior from the test specification document, extracts executable instruction sequences and exception annotation information, thereby achieving structured modeling of the test specification and providing behavioral and constraint layer data support for subsequent knowledge graph fusion and automatic instruction generation.

[0092] S340: Based on the knowledge fusion engine, the extracted knowledge content is fused to construct a knowledge graph.

[0093] In this application, the knowledge fusion engine adopts a three-layer progressive processing architecture to realize the full-link knowledge integration process from semantic alignment to logical verification and then to intelligent reasoning.

[0094] Figure 6 A schematic diagram of the knowledge fusion engine is shown below. (The following section will combine...) Figure 6 This section introduces the process of knowledge fusion by the knowledge fusion engine.

[0095] The first layer is the basic alignment layer, used to achieve conceptual unification and element mapping between test specifications and technical specifications. In this stage, hash tables are used to map specific operational knowledge in the test specifications to abstract definitions in the technical specifications. Simultaneously, compliance checks are performed based on a built-in rule set, validating the legality of various instruction parameters. Example rules are shown in Table 3.

[0096] Table 3 shows examples of rules for compliance checks.

[0097] For example, as shown in Table 3, the CLA value range can be verified through binary mask operations, and the INS code can be verified by querying the technical specification whitelist. When a test parameter is detected to be outside the range defined by the technical specification (e.g., an undefined INS code or parameter anomaly), the engine will automatically mark the item as "pending confirmation" and generate a difference report containing the location of the anomaly, the triggering condition, and the reason for the difference.

[0098] The second layer is the logic verification layer, which is used to align basic knowledge at the semantic consistency level.

[0099] This layer constructs a five-dimensional verification matrix, which performs in-depth comparisons between the execution logic of the test specification and the constraint logic of the technical specification from five dimensions: instruction sequence compliance, security state matching degree, parameter boundary coverage, anomaly handling completeness, and performance constraint satisfaction. Specifically, instruction sequence compliance is verified by the rule engine; security state matching degree is verified based on the aforementioned layered state machine model; parameter boundary coverage is compared using a parameter range model; and anomaly handling and performance constraints are comprehensively evaluated using a performance and recovery model.

[0100] The logic verification layer can identify potential logical omissions, state mismatches, or boundary coverage issues in test cases, providing semantic support for subsequent reasoning completion.

[0101] The third layer is the intelligent completion layer, which is used to expand knowledge and correct consistency when knowledge gaps or conflicts occur.

[0102] This layer employs a hybrid reasoning model that combines rule-based reasoning with case-based reasoning. When undefined boundary conditions or conflicting definitions are detected in the normative knowledge, the engine automatically triggers three completion mechanisms: Historical pattern reuse refers to automatically migrating solutions with similar patterns based on historical processing records; Standardized logical deduction, that is, deduce missing parameters or conditions based on existing technical specification rule sets; The conflict resolution mechanism establishes priority constraints on differing definitions and automatically generates knowledge consistency rules.

[0103] Ultimately, the fusion engine outputs a multi-dimensional knowledge graph. Figure 7 A schematic diagram of the knowledge graph output structure is shown. For example... Figure 7 As can be seen, the KnowledgeGraph serves as the top-level structure in the knowledge graph, storing information entities through InstructionNodes and establishing relationships between entities through Relations. The KnowledgeGraph itself represents the entire knowledge graph and contains a list of instructions (List). <instruction>instructions, test case node list <testcasenode>testCases, Relationship Diagram List <relation>Components such as relationsGraph. InstructionNode is the instruction node, containing a unique identifier (String id), a name (String name), a description (String description), and a list of parameter rules for the node. <paramrule>The `params` parameter contains information such as `relation`. `relation` refers to the connection between nodes in the knowledge graph, including the source node ID (`source`), the target node ID (`target`), and the list of parameter rules. <paramrule>params, the type of the relationship (String type), etc.

[0104] Figure 8 A schematic diagram illustrating the feature extraction and fusion process provided in an embodiment of this application is shown. It should be understood that... Figure 8 The illustrated embodiment can be considered as an example of step S130. For example... Figure 3 As shown, the process may include the following steps.

[0105] S131. Extract features from structured instructions and knowledge graphs to obtain field features, context features, and knowledge features.

[0106] S132. Calculate the dynamic weight corresponding to each feature.

[0107] During the initialization phase, a base weight is preset based on the importance of each feature, and this preset base weight can be stored in a configuration file (e.g., a JSON file).

[0108] At runtime, the preset base weights of each feature are dynamically adjusted based on the weight adjustment matrix or rule base, according to the test environment and instruction type.

[0109] For example, a feature weight adjustment strategy can be learned through a machine learning model (such as an attention mechanism model), and the weight adjustment rules can be continuously optimized based on historical classification results and feature performance, thereby achieving dynamic weight adaptation.

[0110] S133. Perform multimodal fusion of field features, context features, and knowledge features to generate a comprehensive feature vector.

[0111] In one implementation, the dynamic weights are used to perform weighted fusion of field features, context features, and knowledge features.

[0112] In one implementation, features are mapped to the same vector space, and deep semantic fusion is achieved using an attention mechanism to capture high-order relationships between fields, context, and knowledge features.

[0113] By extracting field features and context features from structured instruction data and combining them with knowledge features extracted from knowledge graphs, we can comprehensively characterize the multidimensional information of instructions at the syntactic, temporal, and semantic levels. Through dynamic weight calculation and multimodal fusion mechanisms, the contribution of features from different sources can be adaptively adjusted according to the test scenario and instruction type, thereby achieving accurate expression and discrimination of instruction semantics.

[0114] Figure 9 This illustration shows a flowchart illustrating the instruction generation, execution, and verification process provided in an embodiment of this application. It should be understood that... Figure 9 The illustrated embodiment can be considered as an example of step S170. For example... Figure 9 As shown, the process includes the following steps.

[0115] S171, Generation Instruction.

[0116] After obtaining the target test requirements, the corresponding target test instructions are generated by matching them with instruction templates in the instruction library. To improve correctness and executability, three levels of verification are performed after the instructions are generated: Field-level validation is used to check the value range and format validity of each field in the instruction, such as CLA / INS value range check and Lc field length validation; Logical verification is used to determine whether the combination of parameters conforms to the smart card protocol logic, such as the compliance of the P1-P2 parameter combination; Context validation is used to verify whether the generated instructions match the current test phase, preventing instructions from being executed in an incorrect test context.

[0117] Through the above three-level verification, field errors, parameter conflicts, and context mismatches can be detected in advance during the generation stage, significantly improving the accuracy and execution stability of test commands.

[0118] S172, Simulated execution.

[0119] After verification, simulated transmission is performed through the virtual smart card interface. The virtual smart card interface fully simulates the communication protocol stack of a real smart card, including character-level timing simulation under the T=0 protocol and block retransmission mechanism under the T=1 protocol. It can be implemented by a software simulator or hardware emulator and maintains a complete virtual card state machine (including the five working states of the smart card standard) to ensure that each instruction is executed in the correct and secure state.

[0120] Figure 10 This is a model diagram of the state machine. Figure 10 This document defines the main security states a smart card may be in during its lifecycle and their transition relationships, including the OP_READY, INITIALIZED, SECURED, CARD_LOCKED, and TERMINATED states. Solid lines represent state transition paths between security domains, while dashed lines represent restricted access paths at the application layer. This state machine is used to regulate the execution scope of instructions in different security states, ensuring the security and compliance of instructions during testing or simulation.

[0121] S173, Verification Analysis.

[0122] Figure 11 A diagram illustrating multi-dimensional analysis strategies is shown. For example... Figure 11 As shown, after executing the target test command, the response data is obtained, and basic verification, business verification, and security verification are performed based on the response data.

[0123] The basic verification layer checks whether the response code meets expectations; for example, SW=63CX indicates that the PIN verification failed.

[0124] The business verification layer parses the response data content through the TLV recursive parser to verify whether the FCI returned by the SELECT command conforms to the specification format. The security verification layer uses hardware cryptographic modules to accelerate computation and verify the legitimacy of security metadata (such as ciphertext checksums and MAC tags) in the response.

[0125] The verification rigor can be dynamically adjusted according to different testing scenarios. For example, full verification (including all security checks and boundary tests) can be enabled in regression testing, while only checks on key fields (such as SW code and basic TLV structure) are retained in exploratory testing. Through layered verification and dynamic adjustment mechanisms, both flexibility and security are achieved in the verification process, ensuring the credibility and reproducibility of test results.

[0126] The foregoing mainly describes a smart card test instruction data processing method according to an embodiment of this application with reference to the accompanying drawings. It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially, these steps are not necessarily executed in the order shown in the figures. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of steps or stages in other steps. The following describes a smart card test instruction data processing apparatus according to an embodiment of this application with reference to the accompanying drawings. For brevity, appropriate omissions will be made in the following description of the apparatus; relevant content can be referred to in the relevant descriptions of the method above, and will not be repeated.

[0127] Corresponding to the method described in the above embodiments, Figure 12 This diagram illustrates the structure of a smart card test instruction data processing apparatus 1000 according to an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0128] like Figure 12 As shown, the device 1000 may include: The log parsing module 1001 is used to obtain heterogeneous test logs from multiple test platforms and extract structured instruction data from the heterogeneous test logs. The knowledge graph construction module 1002 is used to acquire technical specification documents and test specification documents, extract and associate knowledge information in the technical specification documents and test specification documents, and construct a knowledge graph. The feature extraction module 1003 is used to extract field features and context features from structured instruction data, extract knowledge features from knowledge graphs, and generate a comprehensive feature vector by fusing field features, context features, and knowledge features. The classification module 1004 is used to classify the comprehensive feature vector using the trained classifier to obtain the instruction semantic category; The instruction library module 1005 is used to generate an instruction library based on structured instruction data, knowledge graphs, and instruction semantic categories. This instruction library is used to assist in generating executable test instructions.

[0129] In some embodiments, the device 1000 may further include the following modules.

[0130] Module 1006, which is used to obtain target test requirements; The instruction generation module 1007 is used to generate executable target test instructions based on the target test requirements and the instruction library.

[0131] Figure 13 A schematic diagram of the structure of a smart card test instruction data processing system provided in an embodiment of this application is shown. Figure 13 As shown, the system 2000 may include a log parsing module 2001, a semantic understanding module 2002, an intelligent classification module 2003, and an instruction generation and verification module 2004.

[0132] Based on the Smart Card Test Instruction Data Processing System 2000, the system analyzes and processes the test logs, technical specifications, test standards, and test requirements from the input sources, thereby automatically outputting APDU instruction sequences and test scripts, realizing the fully automated generation of test instructions from logs to execution scripts.

[0133] The log parsing module 2001 is used to parse raw test logs from multiple test platforms, converting unstructured logs into structured instruction data to extract key field information and execution context.

[0134] The semantic understanding module 2002 is used to perform semantic analysis on technical specification documents and test specification documents. Combined with the structured instruction data, it extracts text features, layout features and position features, constructs a knowledge graph, and generates a comprehensive feature vector representing the semantics of the instructions.

[0135] The intelligent classification module 2003 is used to classify the comprehensive feature vector, determine the corresponding instruction semantic category, and generate an instruction library containing multiple semantic labels and weights to support the rapid generation of subsequent test instructions.

[0136] The instruction generation and verification module 2004 is used to automatically generate executable APDU instruction sequences and test scripts according to the target test requirements and the instruction library, and to perform three-level verification of the generated results at the field level, logic level and context level to ensure the correctness and executability of the instructions.

[0137] Through the synergistic effect of the above modules, this system can automatically generate standardized and verifiable smart card test instructions from log data and specification documents without requiring manual script writing, significantly improving testing efficiency and consistency. For example, the log parsing module 2001 is used to execute... Figure 2 The steps of the illustrated embodiment.

[0138] For example, the semantic understanding module 2002 is used to perform Figure 3 The steps of the illustrated embodiment.

[0139] For example, the intelligent classification module 2003 is used to perform Figure 8 The steps of the illustrated embodiment.

[0140] For example, the instruction generation and verification module 2004 is used to execute Figure 9 The steps of the illustrated embodiment.

[0141] Figure 14 A schematic diagram of the hardware structure of a computer device provided in an embodiment of this application is shown.

[0142] The computer device may include a processor 7001 and a memory 7002 storing computer program instructions.

[0143] Specifically, the processor 7001 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0144] Memory 7002 may include mass storage for data or instructions. For example, and not limitingly, memory 7002 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 7002 may include removable or non-removable (or fixed) media, or memory 7002 may be non-volatile solid-state memory. Memory 7002 may be internal or external to the integrated gateway disaster recovery device.

[0145] In one instance, the memory 7002 may be a read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0146] The memory 7002 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, a memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0147] The processor 7001 reads and executes computer program instructions stored in memory 7002 to achieve... Figure 1 The smart card test instruction data processing method in the illustrated embodiment.

[0148] In one example, the computer device may also include a communication interface 7003 and a bus 7004. Wherein, as... Figure 14 As shown, the processor 7001, memory 7002, and communication interface 7003 are connected through bus 7004 and complete communication with each other.

[0149] The communication interface 7003 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0150] Bus 7004 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 7004 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0151] Furthermore, in conjunction with the smart card test instruction data processing method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the smart card test instruction data processing methods in the above embodiments.

[0152] This application also provides a computer program product, including a computer program, which, when executed, implements any of the smart card test instruction data processing methods described in the above embodiments.

[0153] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0154] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0155] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0156] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.< / paramrule> < / paramrule> < / relation> < / testcasenode> < / instruction>

Claims

1. A method for processing smart card test instruction data, characterized in that, include: Obtain heterogeneous test logs from multiple test platforms, and extract structured instruction data from the heterogeneous test logs; Obtain technical specification documents and test specification documents, extract and associate knowledge information from the technical specification documents and test specification documents, and construct a knowledge graph; Field features and context features are extracted from the structured instruction data, and knowledge features are extracted from the knowledge graph. A comprehensive feature vector is generated by fusing the field features, context features, and knowledge features. The knowledge features include instruction type definition, target object identifier, and expected response pattern. The comprehensive feature vector describes the structural information, execution environment, and knowledge associations of the instruction data in a hierarchical structure. The comprehensive feature vector is classified using a trained classifier to obtain the instruction semantic category; wherein, the trained classifier is pre-trained based on a training dataset, which includes historical instruction data and corresponding semantic labels, and the trained classifier is used to establish a mapping relationship between the comprehensive feature vector and the instruction semantic category. An instruction library is generated based on the structured instruction data, the knowledge graph, and the instruction semantic categories. This instruction library is used to assist in generating executable test instructions.

2. The method according to claim 1, characterized in that, The extraction of structured instruction data from the heterogeneous test logs includes: Determine the file type of the heterogeneous test logs; When the heterogeneous test log is an HTML log, a document object model tree of the HTML log is constructed based on the document object model parser. Key nodes are located in the document object model tree through the XML path language query mechanism. The text content of the key nodes is semantically analyzed based on the context association algorithm to extract instruction data. In the case that the heterogeneous test log is an XML log, instruction data is extracted from the XML log based on the XMLSchema verification and parsing mechanism; The instruction data is processed into a structured form to obtain the structured instruction data.

3. The method according to claim 1, characterized in that, The step of extracting and associating test knowledge from the technical specification document and the test specification document to construct a knowledge graph includes: Extract abstract definition knowledge from the technical specification document; Extract specific operational knowledge from the aforementioned test specification document; Based on the knowledge fusion engine, the abstract definition knowledge and the specific operation knowledge are fused to construct the knowledge graph.

4. The method according to claim 3, characterized in that, The abstract definition knowledge includes technical elements, instruction set definitions, and security protocol parameters. Extracting the abstract definition knowledge from the technical specification document includes: The technical specification document is converted into text data with coordinates, and the technical elements are extracted from the text data with coordinates based on text features, layout features, and position features. Extract the structured instruction set definition from the technical specification document; A hierarchical state machine model is constructed, encompassing physical security and lifecycle management. Based on this state machine model, the security protocol structure is parsed hierarchically, and the security protocol parameters are extracted.

5. The method according to claim 3, characterized in that, The extraction of specific operational knowledge from the test specification document includes: The test cases in the test specification document are parsed to identify test steps and extract expected instruction sequences.

6. The method according to any one of claims 1 to 5, characterized in that, The step of fusing the field features, the context features, and the knowledge features to generate a comprehensive feature vector includes: Based on the weight adjustment matrix, the preset base weights of each feature are adjusted according to the test environment and instruction type to obtain dynamic weights; The dynamic weights are used to weight and fuse the field features, context features, and knowledge features to generate the comprehensive feature vector.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the target testing requirements; Based on the target test requirements and the instruction library, generate executable target test instructions.

8. The method according to claim 7, characterized in that, The step of generating executable target test instructions based on the target test requirements and the instruction library includes: Based on the operation type of the target test requirement, filter instruction templates from the instruction library; Based on the test parameters included in the target test requirements, the instruction template is filled in to generate the target test instructions and the corresponding execution scripts.

9. The method according to claim 7, characterized in that, After generating the target test instruction, the method further includes: The target test instruction is subjected to multi-level verification, which includes field-level verification, logical verification, and context verification.

10. A smart card test instruction data processing device, characterized in that, include: The log parsing module is used to obtain heterogeneous test logs from multiple test platforms and extract structured instruction data from the heterogeneous test logs. The knowledge graph construction module is used to acquire technical specification documents and test specification documents, extract and associate knowledge information in the technical specification documents and test specification documents, and construct a knowledge graph. The feature extraction module is used to extract field features and context features from the structured instruction data, extract knowledge features from the knowledge graph, and generate a comprehensive feature vector by fusing the field features, context features, and knowledge features. The knowledge features include instruction type definition, target object identifier, and expected response pattern. The comprehensive feature vector describes the structural information, execution environment, and knowledge associations of the instruction data in a hierarchical structure. The classification module is used to classify the comprehensive feature vector using a trained classifier to obtain the instruction semantic category; wherein, the trained classifier is pre-trained based on a training dataset, the training dataset including historical instruction data and corresponding semantic labels, and the trained classifier is used to establish a mapping relationship between the comprehensive feature vector and the instruction semantic category. The instruction library module is used to generate an instruction library based on the structured instruction data, the knowledge graph, and the instruction semantic categories. The instruction library is used to assist in generating executable test instructions.

11. A computer device, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the method as claimed in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the computer device, the computer device causes the computer device to perform the method as described in any one of claims 1 to 9.

Images