Test method, device and storage medium based on dynamic command tree
By using a dynamic command tree-based testing method, user interaction and hardware operation are decoupled, solving the problems of high maintenance costs and uncontrollable hardware status in existing testing architectures, and realizing an efficient and controllable testing environment.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN AOWEI LINGXIN TECH CO LTD
- Filing Date
- 2026-03-10
- Publication Date
- 2026-06-09
AI Technical Summary
The existing testing architecture suffers from excessive coupling between the user software interface and hardware operation, resulting in high maintenance costs and uncontrollable hardware status. It lacks flexibility and accuracy, making it difficult to support dynamic combination and agile exploration.
A dynamic command tree-based testing method is adopted. Commands are received through the test interaction system, parsed and separated from user intent and hardware operation. Semantic routing is performed using the dynamic command tree to realize hardware state initialization, parameter setting and monitoring configuration, thus decoupling user interaction and hardware execution.
It achieves controllability of hardware status and flexibility of test logic, reduces maintenance costs, provides a traceable and reproducible R&D environment, and improves the accuracy and efficiency of testing.
Smart Images
Figure CN122173348A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processor testing, and more particularly to a testing method, device, and storage medium based on a dynamic command tree. Background Technology
[0002] In the post-silicon verification and deep optimization phases of network hardware accelerators such as data processors and smart network interface cards (NICs), the industry has made beneficial explorations in the standardization, automation, and virtualization of testing processes. For example, Chinese invention patent CN116860612A focuses on establishing a standardized testing indicator system and scoring model for cloud computing virtualization, mainly addressing the questions of "what to test" and "how to evaluate." Another Chinese invention patent CN120295919A focuses on improving the automation management level of the testing process, achieving full-chain automation from test task scheduling to report generation through technologies such as test case libraries and message queues. Chinese invention patent CN117743043A utilizes virtualization technology to construct a virtual control station, replacing physical peripheral devices with software simulation, aiming to improve the convenience and reliability of test environment setup.
[0003] However, whether executing standardized test projects, running test cases scheduled through automated frameworks, or verifying in a virtual environment, the underlying test logic generation and execution paradigm remains fundamentally unchanged in architecture. Specifically, these solutions are still generally based on execution models that predefine and deeply solidify test logic. This involves writing test sequences as microcode embedded in firmware or relying on script frameworks with limited parameters and fixed processes. This means that no matter how optimized the upper-level management processes are, the system itself still lacks the ability to parse and execute new processes arbitrarily combined from basic functional instructions at runtime. This deep-seated "statically tightly coupled" architecture has become a common bottleneck restricting R&D efficiency and directly leads to the following two fundamental defects: Defect 1: The test architecture is rigid and cannot support dynamic composition and agile exploration. Because the underlying execution engine is fixed, developers cannot quickly build and verify complex combined scenarios based on real-time ideas (e.g., integrating multiple scheduling strategies, integer algorithms, and search mechanisms). Any new test intent must be pre-coded as a separate test program or test case, resulting in a large amount of repetitive and fragmented logic in the test codebase. Any change to basic instructions or hardware behavior requires manual synchronization updates in multiple test code locations, which not only incurs high maintenance costs but also easily introduces inconsistencies and errors, continuously degrading the reliability and sustainability of the test suite itself.
[0004] Defect 2: Uncontrollable hardware state management leads to a lack of precise benchmarks for performance tuning. When tuning scheduler parameters or comparing algorithms, existing methods cannot ensure the consistency of hardware micro-states across tests. Subtle differences in test initialization and implicit perturbations introduced by configuration operations disrupt the continuity and comparability of critical states such as caches, counters, and pipeline contexts. This results in a lack of stable and reproducible benchmarks for performance data, making it difficult to base refined performance analysis and optimization on reliable data.
[0005] These bottlenecks stem from the deep coupling between existing testing architectures and two key dimensions: user interaction and hardware operation execution, as well as hardware basic state configuration and runtime function optimization. This coupling leads to inherent systemic deficiencies in the testing environment regarding agility, accuracy, and the traceability and reproducibility of operational processes, making efficient exploratory development and closed-loop debugging difficult. Therefore, a new technology is needed to address the technical problem of excessive coupling between user software interfaces and hardware operations, resulting in high maintenance costs and uncontrollable hardware states. Summary of the Invention
[0006] The main objective of this invention is to solve the technical problem of excessive coupling between user software interface and hardware operation, which leads to high maintenance costs and uncontrollable hardware status.
[0007] The first aspect of this invention provides a testing method based on a dynamic command tree, the testing method based on a dynamic command tree comprising: a test interaction system and a hardware configuration system, wherein the testing method based on a dynamic command tree includes: The test interaction system receives test commands based on a dynamic command tree; According to the preset matching and verification algorithm, the test command is parsed and processed to obtain command processing data, and the command processing data is sent to the hardware configuration system. The command processing data includes: hardware status settings, hardware parameter settings, and test callback settings. The hardware configuration system receives the command processing data; Based on the hardware state settings, the initialization state of the hardware is constructed to obtain the initialization state hardware; Based on the hardware parameter settings, the register parameters of the initialization state hardware corresponding to the hardware parameter settings are changed to obtain the configuration state hardware; Based on the test callback settings, the configuration state hardware is mapped and associated with a preset monitoring configuration function to obtain the configuration state hardware for test monitoring; After the hardware under test monitoring completes the test process, the test interaction system reads the corresponding register parameters of the hardware under test monitoring and generates test results.
[0008] Optionally, in a first implementation of the first aspect of the present invention, the step of parsing and processing the test command according to a preset matching verification algorithm to obtain command processing data includes: The test command is segmented into words to obtain the test command words; Based on the dynamic command tree, the test command is segmented and matched step by step from the root node to obtain the matching parameters. The matching parameters are subjected to range verification processing to generate verification results; If the verification result is satisfactory, then command processing data is generated based on the matching parameters.
[0009] Optionally, in a second implementation of the first aspect of the present invention, the step of constructing the initialization state of the hardware based on the hardware state settings to obtain the initialization state hardware includes: The hardware is initialized sequentially by calling the preset hw_init() sequence based on the hardware state settings, resulting in the initialized hardware state.
[0010] Optionally, in a third implementation of the first aspect of the present invention, the step of mapping and associating the configuration state hardware with a preset monitoring configuration function according to the test callback setting to obtain the configuration state hardware for test monitoring includes: Based on the test callback settings, start the preset timer and retrieve the callback function pointer from the preset static registry; The callback function pointer is injected into a preset forwarding control function to obtain the callback function, and the callback function is mapped and associated with the configuration state hardware to obtain the configuration state hardware for test monitoring. The preset monitoring configuration function is nested within the forwarding control function.
[0011] Optionally, in a fourth implementation of the first aspect of the present invention, the step of the test interaction system receiving test commands based on a dynamic command tree includes: The test interaction system receives the input string; The string is completed and verified according to a preset intelligent completion algorithm to generate a test command based on a dynamic command tree.
[0012] Optionally, in the fifth implementation of the first aspect of the present invention, the triggering command for the hardware status setting includes functional commands such as config get and config send.
[0013] Optionally, in the sixth implementation of the first aspect of the present invention, the triggering command for setting the hardware parameters includes function commands such as pol, que, rxpsr, port, edit, and mac.
[0014] Optionally, in the seventh implementation of the first aspect of the present invention, the trigger command for the test callback setting includes: the iofwd function command.
[0015] A second aspect of the present invention provides a test device based on a dynamic command tree, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a circuit; the at least one processor invokes the instructions in the memory to cause the test device based on the dynamic command tree to execute the aforementioned test method based on the dynamic command tree.
[0016] A third aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the aforementioned test method based on a dynamic command tree.
[0017] In this embodiment of the invention, a dynamic command tree is used as the semantic routing core to separate the test intent expressed by the user through the command line from the underlying hardware / software operation execution. Users drive testing through high-level semantic commands without needing to be aware of the underlying implementation. Test execution, state observation, and deep diagnostic functions are integrated into the same interactive interface and command context, shortening the problem localization cycle. Through the instruction-driven and software-hardware decoupling architecture, interaction and execution decoupling, and state and function decoupling are achieved at the system architecture level. This systematically overcomes the two core bottlenecks of rigid test logic and lack of state benchmarks. Simultaneously, it provides a traceable and reproducible integrated interactive environment for the R&D process, solving the technical problem of excessive coupling between the user software interface and hardware operation leading to high maintenance costs and uncontrollable hardware state. Attached Figure Description
[0018] Figure 1 This is a schematic diagram of an embodiment of the testing method based on a dynamic command tree in this invention. Figure 2 This is a schematic diagram of the structure of the dynamic command tree in an embodiment of the present invention; Figure 3 This is a schematic diagram of a specific embodiment of the 102 steps of the testing method based on a dynamic command tree in this invention. Figure 4 This is a schematic diagram of a specific embodiment of the 106 steps of the testing method based on dynamic command tree in this invention. Figure 5 This is a schematic diagram of an embodiment of a test device based on a dynamic command tree in this invention. Detailed Implementation
[0019] This invention provides a testing method, device, and storage medium based on a dynamic command tree.
[0020] The embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.
[0021] In the description of the embodiments disclosed in this invention, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.
[0022] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 This invention provides an embodiment of a testing method based on a dynamic command tree, which includes a test interaction system and a hardware configuration system. 101. The test interaction system receives test commands based on a dynamic command tree; In this embodiment, the test interaction system is a software testing system that receives test commands from the user based on a dynamic command tree. Please refer to [link / reference needed]. Figure 2 , Figure 2 This is a schematic diagram of the dynamic command tree structure in an embodiment of the present invention. The syntax structure of the test command is a tree-like hierarchical command, such as the order of (<module><action><object><parameter>). Each tree node is a command information structure, containing the command string, help information, node type (ordinary command / numerical parameter / IP address parameter), parameter range (if it is a numerical parameter), processing function pointer, pointers to sibling nodes, and pointers to child nodes.
[0023] Specifically, step 101 includes the following specific implementation methods: 1011. The test interaction system receives the input string; 1012. Based on the preset intelligent completion algorithm, the string is completed and verified to generate a test command based on a dynamic command tree.
[0024] In steps 1011-1012, as the test interaction system continuously receives input strings, it can complete the strings according to the intelligent completion algorithm and refer to the tree-like hierarchical commands, and perform real-time parameter verification on the input strings. Under the processing of intelligent completion and real-time parameter verification, test commands based on a dynamic command tree are generated.
[0025] 102. According to the preset matching verification algorithm, the test command is parsed and processed to obtain command processing data, and the command processing data is sent to the hardware configuration system, wherein the command processing data includes: hardware status settings, hardware parameter settings, and test callback settings; In this embodiment, the test command statements are parsed from the dynamic command tree, semantically understood, and routed. Parameters are then verified and analyzed to obtain command processing data. This command processing data is then sent to the hardware configuration system so that the hardware configuration system can configure the relevant data on the hardware.
[0026] For details, please refer to Figure 3 , Figure 3 This is one embodiment of step 102 of the testing method based on a dynamic command tree in this invention, which includes the following specific implementation methods: 1021. Perform word segmentation on the test command to obtain the test command word segmentation; 1022. Based on the dynamic command tree, the test command is segmented and matched level by level from the root node to obtain the matching parameters; 1023. Perform range verification on the matching parameters and generate verification results; 1024. When the verification result is qualified, command processing data is generated based on the matching parameters.
[0027] In steps 1021-1024, the test command is "port set mirror 0 5 8". This command is segmented into the words port, set, mirror, 0, 5, and 8. Following the order port, set, mirror, 0, 5, and 8, the dynamic command tree is traversed level by level from the root node CLI to obtain matching parameters. The matching parameters are checked to see if they fall within the corresponding set range. If they do, the processing function of the terminal node is called with the parameters passed in to generate the command processing data.
[0028] More specifically, by calling a unified registration function (such as `rv_cli_cmd_register`), a command string template (e.g., "port set mirror<0~1><0~12><0~12>") and the corresponding processing function are provided. The registration engine automatically parses this template, dividing it into a token sequence separated by spaces, and searches for or creates nodes token by token, starting from the global tree root. Automatic recognition...<min~max> The format is a numerical parameter node. It identifies ABCD, etc., as IP parameter nodes, then performs parameter range verification, and finally attaches the processing function pointer to the end node of the command chain to generate command processing data.
[0029] By leveraging a dynamic command tree mechanism, semantic commands entered by the user in the command line are separated from the underlying hardware / software operations, including register configurations, driver calls, and software callbacks. Users drive testing through high-level semantic commands without needing to be aware of the underlying implementation. Switching is completed only through incremental commands, without triggering a config send. This means that the runtime dynamic state of the hardware platform (such as the DMA engine, internal cache, and counters) remains continuous, while only the test logic (scheduling algorithm and parameters) is precisely reset. This eliminates the random variables introduced by 'hardware cold starts' in traditional methods, ensuring that the observed differences between two tests are solely attributed to the scheduling algorithm itself. This achieves a fair and scientific comparison under identical hardware runtime benchmarks, resulting in more accurate and reliable conclusions.
[0030] 103. The hardware configuration system receives the command processing data; In this embodiment, the hardware configuration system receives command processing data, and the built-in initialization processor, hardware function configuration processor, and test callback diagnostic processor respectively process the data of hardware status settings, hardware parameter settings, and test callback settings.
[0031] 104. Based on the hardware state settings, construct the initialization state of the hardware to obtain the initialization state hardware; In this embodiment, the hardware can be a DPU chip or other types of chips that process the config send command, trigger a one-click reconstruction of the hardware base state, call an internally predefined and fixed-order hardware initialization sequence, quickly reconstruct a consistent and reliable hardware base state, and obtain the initial state hardware.
[0032] Specifically, step 104 includes the following specific implementation methods: 1041. Call the preset hw_init() sequence to perform sequential initialization of the hardware based on the hardware state settings, and obtain the initialized hardware.
[0033] In step 1041, based on the hardware state settings, the hardware enters a known and consistent basic state by following the SerDes initialization, MAC layer initialization, MUX initialization, BM initialization, PORT configuration, QUE initialization, POL initialization, and EDIT initialization sequence in hw_init(), thus obtaining the initialized hardware state.
[0034] Furthermore, the trigger commands for setting the hardware status include functions such as config get and config send.
[0035] In this embodiment, after the user obtains and modifies the configuration template using the `config get` command, they can trigger the `configsend` command. This module calls the internally predefined `hw_init()` sequence, strictly following a fixed order (e.g., SerDes->MUX->MAC->DMA->Parser, etc.) to call the initialization APIs of each hardware module, and submits all configuration parameters at once and completely. This process can reset the hardware to a known, consistent, and stable basic state in an extremely short time (e.g., on the order of microseconds), which is far less than the time required for a complete hardware reset. An example of the environment setup code is as follows: Exploratory environment setup (in seconds) config get # Retrieves the default hardware configuration template `config modify que 0-31 1 1024` # Configure all queues to push mode with a depth of 1024. config send # One-click activation, basic hardware status is ready 105. Based on the hardware parameter settings, change the register parameters of the initialization state hardware corresponding to the hardware parameter settings to obtain the configuration state hardware; In this embodiment, according to the hardware parameter settings, the `pol_set_rate()` function is called to modify the rate limiting policy in real time, the `que_set_sche()` function is called to dynamically change the scheduling algorithm, the `rxpsr_add_rule` function is called to update the parsing rules, and the hardware driver interface is directly called to modify the register parameters of the initialization state hardware to obtain the configuration state hardware. The register parameters of the configuration state hardware can load data, unload data, modify data, etc., and are adjusted based on the specific data set in the hardware parameter settings.
[0036] Furthermore, the trigger commands for setting the hardware parameters include: pol, que, rxpsr, port, edit, mac, and other function commands.
[0037] In this embodiment, based on a stable hardware foundation, users can perform hardware performance tuning using independent semantic commands (such as `polrx scp dscp 0 10 100 64000`, `que tx sche 0 0 1`, and `port set mirror 0 5 10`). This module does not involve hardware reset; instead, it directly routes commands to the corresponding hardware module's independent API (such as the policyr's `pol_set_rate()` and the queue scheduler's `que_set_schedule()`), enabling real-time, precise, and incremental modification of runtime parameters. A code example is shown below: #1. Specify the message receive queue rxpsr rule ipv4 qid 17 0 # [Hardware Function Point Configuration] Set IPv4 UDP packet receive queue to 0 rxpsr rule ipv6 qid 17 1 # [Hardware Function Point Configuration] Configure IPv6 UDP packet receive queue 1 #2. Perform WRR scheduling mode test que tx sche 0 0 1 #
Hardware Function Point Configuration
Hardware Function Point Configuration
[0038] Within the time window controlled by the timer, the hardware receives data packets and generates descriptors; the software, in the loop of processing descriptors, dynamically intervenes based on the registered callback functions to achieve real-time interaction with the hardware.
[0039] The test callback settings include two types: configuration callbacks and monitoring callbacks. Configuration callbacks modify the current packet descriptor fields or generate new descriptors, indirectly controlling the hardware's subsequent processing of packets (such as editing, forwarding, and queue scheduling). This operation does not change the hardware's configuration state; it only affects the processing path of a single packet at runtime. Monitoring callbacks read error statistics from the descriptor and record them in memory or a counter.
[0040] Furthermore, the trigger commands for the test callback settings include functions such as iofwd.
[0041] In this embodiment, the iofwd function command is responsible for establishing the communication path between the DMA shared memory and the CPU: RX direction: Read the RXD (receive descriptor) stored in DMA into the CPU, so that the CPU can obtain the buffer pointer and related information of the message.
[0042] TX direction: Write the TXD (transmit descriptor) generated by the CPU into the DMA, so that the hardware can obtain the message and send it according to the descriptor.
[0043] Hardware registers can be directly read using commands such as `dfx reg read`; statistical information can be easily obtained using commands such as `dfx mac cnt`. The system maintains a software forwarding framework and a registry of callback functions. For example, `l3_forward()` is registered as ID 8. When the command `iofwd … ,8,12` is executed, the system dynamically selects and combines callback functions based on their function IDs, configuring them into the processing chain. This defines the software-level data processing flow, which can be dynamically adjusted independently of the hardware configuration. Code examples are as follows: #1. Real-time interaction optimization (switch to hybrid mode) que tx sche 0 0 1# [Hardware Function Point Configuration] Change queue 0 to WRR mode, weight 1 que tx sche 1 1 1# [Hardware Function Point Configuration] Change queue 1 to SP mode, priority 1 iofwd 255 8 0 30 # [Test logic executed again] Start the third round of testing immediately. `show rule stats all` # Verify the SP scheduling effect and continuously compare it with the WRR results. #2. Problem Diagnosis and Process Retrospection dfx reg read 0x2840000 # Directly read hardware registers for deep debugging history # Fully trace all interactive commands show running-config # View all commands that have been successfully configured For details, please refer to Figure 4 , Figure 4 This is one embodiment of step 106 of the testing method based on a dynamic command tree in this invention. Step 106 includes the following specific implementation methods: 1061. Based on the test callback settings, start the preset timer and retrieve the callback function pointer from the preset static registry; 1062. Inject the callback function pointer into a preset forwarding control function to obtain a callback function, and map the callback function to the configuration state hardware to obtain the configuration state hardware for test monitoring, wherein the preset monitoring configuration function is nested within the forwarding control function.
[0044] In steps 1061-1062, the test process is assembled at the software layer and predefined byte data is set in the RX and TX descriptors to modify and monitor the hardware.
[0045] The monitoring configuration function is nested within the forwarding control function. A callback function pointer is selected using a callback ID, and this pointer is passed as a parameter to the forwarding control function, where it is then invoked. The callback function establishes the software-level association between the monitoring configuration function and the hardware monitoring points, ultimately determining the monitoring settings for the hardware test points.
[0046] The preset timer is started. iofwd relies on a timer to implement fixed-duration forwarding functionality. The forwarding duration parameter (<1~86400>) in the iofwd command is controlled by a timer interrupt at the underlying level to start and stop forwarding. When the iofwd command is executed, the system registers a timer interrupt service function nss_fwd_timer_isr with a period of 1000ms. This function accumulates the timer variable curr_time, incrementing by 1 every second. When curr_time reaches the specified forwarding duration, the system automatically stops the forwarding process.
[0047] A static callback function registry is generated, including monitoring and configuration callback functions. Configuration callback functions modify fields of the TX descriptor, indirectly controlling hardware behavior (checksum, editing, error injection, etc.). Monitoring callback functions read hardware status, counters, and error information without modifying descriptors or configuring the hardware. A timer is enabled to control the total time range of the software-hardware interaction process and control packet forwarding time. Forwarding, callback, and timing functions are integrated into a single command, simplifying the testing interface.
[0048] 107. After the hardware configuration status of the test monitoring completes the test process, the test interaction system reads the corresponding register parameters of the hardware configuration status of the test monitoring and generates test results.
[0049] In this embodiment, the configuration status hardware for test monitoring performs forwarding / editing / statistical actions based on the final modified descriptor through its internal functions. These actions are executed immediately after the packet is actually processed by the hardware, and the registers collect instantaneous data during the processing of that specific packet. After the configuration status hardware for test monitoring completes the test process, the test interaction system reads the corresponding register parameters from the configuration status hardware for test monitoring and generates test results. The test interaction system interface encapsulates all access details to the underlying registers and hardware subsystems. Hardware registers can be directly read using commands such as `dfx reg read`, and statistical information can be easily obtained using commands such as `dfx mac cnt`.
[0050] In this embodiment of the invention, a dynamic command tree is used as the semantic routing core to separate the test intent expressed by the user through the command line from the underlying hardware / software operation execution. Users drive testing through high-level semantic commands without needing to be aware of the underlying implementation. Test execution, state observation, and deep diagnostic functions are integrated into the same interactive interface and command context, shortening the problem localization cycle. Through the instruction-driven and software-hardware decoupling architecture, interaction and execution decoupling, and state and function decoupling are achieved at the system architecture level. This systematically overcomes the two core bottlenecks of rigid test logic and lack of state benchmarks. Simultaneously, it provides a traceable and reproducible integrated interactive environment for the R&D process, solving the technical problem of excessive coupling between the user software interface and hardware operation leading to high maintenance costs and uncontrollable hardware state.
[0051] Figure 5This is a schematic diagram of a test device based on a dynamic command tree according to an embodiment of the present invention. The test device 500 can vary significantly due to different configurations or performance characteristics. It may include one or more central processing units (CPUs) 510 and memory 520, and one or more storage media 530 storing application programs 533 or data 532. The memory 520 and storage media 530 can be temporary or persistent storage. The program stored in the storage media 530 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the test device 500 based on the dynamic command tree. Furthermore, the processor 510 may be configured to communicate with the storage media 530 and execute the series of instruction operations in the storage media 530 on the test device 500 based on the dynamic command tree.
[0052] The test device 500 based on a dynamic command tree may also include one or more power supplies 540, one or more wired or wireless network interfaces 550, one or more input / output interfaces 560, and / or one or more operating systems 531, such as Windows Server, Mac OS X, Unix, Linux, Free BSD, etc. Those skilled in the art will understand that... Figure 5 The illustrated test equipment structure based on dynamic command tree does not constitute a limitation on test equipment based on dynamic command tree. It may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.
[0053] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the test method based on a dynamic command tree.
[0054] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0055] Furthermore, although the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.
[0056] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.
Claims
1. A testing method based on a dynamic command tree, characterized in that, The dynamic command tree-based testing method includes: a test interaction system and a hardware configuration system. The test interaction system receives test commands based on a dynamic command tree; According to the preset matching and verification algorithm, the test command is parsed and processed to obtain command processing data, and the command processing data is sent to the hardware configuration system. The command processing data includes: hardware status settings, hardware parameter settings, and test callback settings. The hardware configuration system receives the command processing data; Based on the hardware state settings, the initialization state of the hardware is constructed to obtain the initialization state hardware; Based on the hardware parameter settings, the register parameters of the initialization state hardware corresponding to the hardware parameter settings are changed to obtain the configuration state hardware; Based on the test callback settings, the configuration state hardware is mapped and associated with a preset monitoring configuration function to obtain the configuration state hardware for test monitoring; After the hardware under test monitoring completes the test process, the test interaction system reads the corresponding register parameters of the hardware under test monitoring and generates test results.
2. The testing method based on a dynamic command tree according to claim 1, characterized in that, The step of parsing and processing the test command according to a preset matching verification algorithm to obtain command processing data includes: The test command is segmented into words to obtain the test command words; Based on the dynamic command tree, the test command is segmented and matched step by step from the root node to obtain the matching parameters. The matching parameters are subjected to range verification processing to generate verification results; If the verification result is satisfactory, then command processing data is generated based on the matching parameters.
3. The testing method based on a dynamic command tree according to claim 1, characterized in that, The step of constructing the initialization state of the hardware based on the hardware state settings to obtain the initialization state hardware includes: The hardware is initialized sequentially by calling the preset hw_init() sequence based on the hardware state settings, resulting in the initialized hardware state.
4. The testing method based on a dynamic command tree according to claim 1, characterized in that, The step of mapping and associating the configuration state hardware with a preset monitoring configuration function according to the test callback settings to obtain the configuration state hardware for test monitoring includes: Based on the test callback settings, start the preset timer and retrieve the callback function pointer from the preset static registry; The callback function pointer is injected into a preset forwarding control function to obtain the callback function, and the callback function is mapped and associated with the configuration state hardware to obtain the configuration state hardware for test monitoring. The preset monitoring configuration function is nested within the forwarding control function.
5. The testing method based on a dynamic command tree according to claim 1, characterized in that, The steps for the test interaction system to receive test commands based on a dynamic command tree include: The test interaction system receives the input string; The string is completed and verified according to a preset intelligent completion algorithm to generate a test command based on a dynamic command tree.
6. The testing method based on a dynamic command tree according to claim 1, characterized in that, The trigger commands for setting the hardware status include functions such as config get and config send.
7. The testing method based on a dynamic command tree according to claim 1, characterized in that, The trigger commands for setting hardware parameters include: pol, que, rxpsr, port, edit, mac, and other function commands.
8. The testing method based on a dynamic command tree according to claim 1, characterized in that, The trigger commands set for the test callback include the iofwd function command.
9. A test device based on a dynamic command tree, characterized in that, The test device based on dynamic command tree includes: a memory and at least one processor, wherein the memory stores instructions and the memory and the at least one processor are interconnected via a line; The at least one processor invokes the instructions in the memory to cause the dynamic command tree-based test device to execute the dynamic command tree-based test method as described in any one of claims 1-8.
10. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the test method based on a dynamic command tree as described in any one of claims 1-8.