A test control method and device, computer equipment and storage medium
By introducing a synchronous mutex lock mechanism and control code recognition technology into the verification platform, the problems of low testing efficiency and data chaos in traditional verification platforms are solved, and automated testing and improved system stability are achieved.
Patent Information
- Application Number
- CN202511220036.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-29
- Publication Date
- 2025-11-04
- Estimated Expiration
- 2045-08-29
AI Technical Summary
Traditional verification platforms struggle to automate testing, lack multi-channel structured support, struggle to correlate debugging information with hardware status, and exhibit significant differences in output formats across different software environments, resulting in low testing efficiency and chaotic data.
The system employs a synchronous mutex lock mechanism to monitor communication data at preset interfaces, identifies and parses control codes, and achieves software and hardware platform interaction and log file storage through multi-channel output, ensuring system status visualization and stability.
Clear message categorization was achieved, which improved testing efficiency and system readability, enhanced the traceability of debugging information, avoided data races, and ensured system stability.
Smart Images

Figure CN120743795B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of testing, in particular to a test control method and device, computer equipment and a computer readable storage medium. BACKGROUND
[0002] In the development process of SoC verification, FPGA verification and embedded software, the verification test platform is the core tool to ensure the functional correctness and stability of the design. The traditional verification platform directly calls system functions or serial prints and outputs information, which cannot distinguish between ordinary characters and control codes, and is seriously dependent on manual identification, making it difficult to integrate automatic test processes and reducing test efficiency.
[0003] At the same time, due to the delay between hardware state updates and software log outputs, the traditional test method usually uses a single non-blocking output channel, so it lacks multi-channel structured support, and debugging information is difficult to associate with hardware state, which prolongs the time of fault debugging.
[0004] In addition, the output formats of different software environments differ greatly, and there is a lack of a general interface adaptation test scheme, making it difficult for the verification test platform to uniformly manage multi-source data. And in the actual application of multi-channel debugging, it often happens that the same clock edge triggers the message passing task multiple times, causing resource blocking or data confusion. Single use of traditional mutual exclusion locks can only guarantee atomic access to shared resources, and further hardware state synchronization and channel scheduling based on synchronization mutual exclusion locks are needed to realize the test method of coordinating the multi-channel log output and control across software and hardware platforms. SUMMARY
[0005] The present application provides a test control method, device, computer equipment and storage medium to solve the technical problems of low test efficiency and easy data confusion in the prior art.
[0006] The present application provides a test control method, device, computer equipment and storage medium to solve the technical problems of low test efficiency and easy data confusion in the prior art.
[0007] The present application provides a test control method, device, computer equipment and storage medium to solve the technical problems of low test efficiency and easy data confusion in the prior art.
[0008] Identifying a control code in the communication data, comprising: real-time decoding and identifying the control field bits in the data when monitoring the communication data at the preset interface, to distinguish normal characters from special control codes, if identified as a control code, entering a special processing flow, if identified as a normal character, directly outputting; setting decoding classification logic for the fields of the captured communication data in the module at the preset interface to formulate the identification rule of the control code;
[0009] Analyzing the control code to determine the test result, comprising: after identifying the control code, analyzing the meaning corresponding to the control code, and determining the test result according to the meaning of the control code, the meaning corresponding to the control code being pre-set, and the meanings of different control codes being set according to macro definition;
[0010] Outputting the test result through a preset channel to realize the interaction of the software and hardware test platform and / or the storage of the log file.
[0011] In one embodiment, the monitoring of the communication data of the preset interface based on the synchronization mutex mechanism comprises:
[0012] Setting a dedicated port address and / or memory mapping address as the preset interface;
[0013] Generating a synchronization mutex for the preset interface;
[0014] Obtaining the communication data written by the test program at the preset interface.
[0015] In one embodiment, the generating of the synchronization mutex for the preset interface comprises:
[0016] Detecting whether the current process meets a preset condition of writing data to the preset interface;
[0017] Creating a synchronization mutex when the preset condition is met, and delaying the timing of the concurrent processes;
[0018] Releasing the synchronization mutex after the current process completes writing data.
[0019] In one embodiment, the synchronization range of the synchronization mutex comprises:
[0020] When a general preset interface (bus / controller) is input, being associated to the current hardware state;
[0021] When multi-channel output, the control code output of the software and hardware platform interaction being occupied;
[0022] When multi-channel output, the string output for software log generation being occupied.
[0023] In one of the embodiments, the identifying a control code in the communication data comprises:
[0024] acquiring and decoding a control field bit in the communication data field;
[0025] if the value of the control field bit meets a preset condition, judging the communication data as the control code;
[0026] if the value of the control field bit does not meet the preset condition, judging the communication data as a normal string.
[0027] In one of the embodiments, the parsing the control code to determine a test result comprises:
[0028] acquiring a control code macro definition library;
[0029] determining the test result corresponding to the control code according to the control code macro definition library;
[0030] wherein, the test result comprises at least one of test pass, test failure, test interruption, entering a debugging state, and returning a main function.
[0031] In one of the embodiments, the outputting the test result through a preset channel comprises:
[0032] displaying the test result through a console;
[0033] and / or, writing the test result into a log file according to a preset format;
[0034] wherein, the preset format comprises at least one of a timestamp, a module name, and level information.
[0035] In one of the embodiments, after the parsing the control code to determine the test result, the method further comprises:
[0036] controlling the software test platform to interact with the hardware test platform;
[0037] and / or, ending the monitoring of the preset interface.
[0038] Further, the application also provides a test control device, comprising:
[0039] a monitoring module, configured to monitor communication data of a preset interface based on a synchronization mutex mechanism;
[0040] an identifying module, configured to identify a control code in the communication data;
[0041] a parsing module, configured to parse the control code to determine a test result;
[0042] An output module is configured to output the test result through a preset channel to realize interaction between a software test platform and a hardware test platform and / or log file storage.
[0043] Further, the application also provides a computer device including a memory and a processor, the memory stores a computer program, and the processor realizes the steps of the test control method according to any one of the above embodiments when executing the computer program.
[0044] Further, the application also provides a computer readable storage medium, which stores a computer program, and the computer program realizes the steps of the test control method according to any one of the above embodiments when executed by a processor.
[0045] Compared with the prior art, the technical scheme of the embodiment of the application has the following beneficial effects:
[0046] The test control method, device, computer device and storage medium provided by the embodiment of the application can realize clear message classification, improve the readability and controllability of the system, realize an automatic test process and improve test efficiency by setting a universal preset data interface to analyze, classify and respond to test data, and can distinguish between ordinary characters and special control codes. Meanwhile, multi-channel data output can be selected to control the interaction between a software test platform and a hardware test platform, and the log management capability is combined to ensure system state visualization and enhance the traceability of debugging information. A synchronization mutual exclusion lock mechanism is also introduced to prevent possible concurrent conflicts, so that only one process can write an address, output information and control at the same time, thereby avoiding data competition and improving system stability. BRIEF DESCRIPTION OF DRAWINGS
[0047] In order to more clearly illustrate the technical scheme in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are some embodiments of the application, not all embodiments. For those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.
[0048] Figure 1 A flowchart of a test control method provided by the embodiment of the application is shown in the figure;
[0049] Figure 2 A flowchart of step S110 in a test control method provided by the embodiment of the application is shown in the figure;
[0050] Figure 3 A flowchart of step S112 in a test control method provided by the embodiment of the application is shown in the figure;
[0051] Figure 4 A flowchart of step S120 in a test control method provided by an embodiment of the present application is shown in FIG. 12;
[0052] Figure 5 A flowchart of step S130 in a test control method provided by an embodiment of the present application is shown in FIG. 13;
[0053] Figure 6 A flowchart of step S140 in a test control method provided by an embodiment of the present application is shown in FIG. 14;
[0054] Figure 7 A flowchart of a test control method provided by another embodiment of the present application is shown in FIG. 15;
[0055] Figure 8 A module diagram of a test control device provided by an embodiment of the present application is shown in FIG. 16;
[0056] Figure 9 An internal structure diagram of a computer device provided by an embodiment of the present application is shown in FIG. 17. DETAILED DESCRIPTION
[0057] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.
[0058] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the description herein is for describing the specific embodiments only and is not intended to be limiting of the application.
[0059] As used herein, the singular forms "a", "an" and "the" include plural referents unless the context clearly dictates otherwise. It should also be understood that the term "comprising" or "having" etc., specifies the presence of stated features, integers, steps, operations, components, parts, or combinations thereof, but does not preclude the presence or addition of one or more other features, integers, steps, operations, components, parts, or combinations thereof. Also, the term "and / or" used in the description herein includes any and all combinations of the associated listed items.
[0060] The technical solutions of the present application are described in detail below with specific examples. The following specific examples can be combined with each other, and the same or similar concepts or processes can not be described in some examples.
[0061] Based on the problems in the prior art, the embodiments of the present application provide a test control method, a test control device, a computer and equipment, and a computer readable storage medium.
[0062] Figure 1 A flowchart of a test control method provided by an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the embodiment of the present application provides a test control method, which includes the following steps. Figure 1
[0063] Step S110: Monitor the communication data of the preset interface based on a synchronization mutual exclusion mechanism.
[0064] Specifically, a general-purpose preset interface can be first set for communication and monitoring of test data. The preset interface can be a bus monitor (Bus Tracer). For example, the bus monitor can use a preset address and a preset control condition on the AMBA bus, so as to monitor the master control device using the AMBA bus, such as a CPU or a USB, through the bus monitor, and receive communication data containing character streams and control codes.
[0065] For master control devices using non-standard bus interfaces, as an alternative to bus monitoring, the bypass monitoring mechanism of the storage controller can still be used to communicate and monitor the output test data of such master control devices to the storage. Specifically, the preset interface uses a preset address and a preset control condition for writing to the memory controller. The signals of the memory controller used by the preset interface can be completely mapped to the relevant signal categories of the AMBA bus signals, ensuring that the behavior of devices with non-AMBA bus architecture but with memory interfaces is equivalent to the behavior of devices with AMBA standard bus protocols. Thus, the master control devices with standard bus interfaces and non-standard bus interfaces of the AMBA bus architecture can be compatible, and the general compatibility of the full-platform verification environment can be achieved.
[0066] Further, to avoid concurrent access conflicts and prevent multiple modules from competing for the preset interface, a synchronization mutual exclusion mechanism can be introduced to the preset interface to prevent possible concurrent conflicts and ensure that only one process can write to the address, output information and control at the same time, thereby improving the stability of the system.
[0067] Step S120: Identify the control code in the communication data.
[0068] Specifically, when monitoring the communication data of the test program, the control field bits in the data are decoded and recognized in real time to distinguish normal characters from special control codes (such as CPU_PASS, CPU_FAIL, etc.), for example, if recognized as a control code, a special processing flow is entered, and if recognized as a normal character, it is directly output. The identification rule of the control code can be set according to the actual test requirements, for example, the decoding classification logic is set for the captured communication data field in the preset interface module, which is used to judge the special characters of the control code.
[0069] Step S130: Analyzing the control code to determine the test result.
[0070] Specifically, after recognizing the control code, the meaning corresponding to the control code can be parsed, and the test result is determined according to the meaning of the control code. The meaning corresponding to the control code can be preset, and the meanings of different control codes can be set according to macro definition.
[0071] Step S140: Output the test result through a preset channel to realize the interaction of the software and hardware test platform and / or the storage of the log file.
[0072] Specifically, after determining the test result, the test result can be output and printed in various ways, and the test result can also be recorded in a log file and triggered by an event. The log recording function can be selectively enabled or disabled dynamically according to the requirements, and then the test program is processed and responded.
[0073] For example, when the test result is a runtime event passed by the CPU (including interrupt triggering, timestamp recording, intermediate state checking, etc.), the test platform is driven to perform a preset hardware response action (such as interrupt vector jump, register state readback, etc.), and then output and print according to a preset format (such as a timestamp log, a state snapshot, etc.). When the test result is the end of the CPU process, a program termination notification is sent to the test platform, and the termination state information is synchronously transmitted and printed. There is no need to manually check the register state or wait for timeout to determine whether the test is completed.
[0074] In summary, the test control method provided by the embodiment of the application can distinguish between normal characters and special control codes, realize clear message classification, improve the readability and controllability of the system, realize an automatic test process, and improve test efficiency by setting a universal preset data and control interface to analyze, classify, and respond to test data. Meanwhile, multi-channel data output can be selected to control the interaction between a software test platform and a hardware test platform, and the system state can be visualized by combining log management capabilities, thereby enhancing the traceability of debugging information. A synchronization mutex mechanism is also introduced to prevent possible concurrent conflicts and ensure that only one process can write to an address, output information, and control at the same time, thereby avoiding data competition and improving system stability.
[0075] Figure 2 A flowchart of step S110 in the test control method provided by the embodiment of the application is shown in FIG. 1. Figure 2 As shown in FIG. 1, in one embodiment, step S110 can include the following steps.
[0076] Step S111: Set a dedicated port address and / or memory mapping address as a preset interface.
[0077] Step S112: Generate a synchronization mutex for the preset interface.
[0078] Step S113: Obtain communication data written by a test program in the preset interface.
[0079] Specifically, a dedicated I / O port address or memory mapping address is used as the preset interface, and the test program writes data to be output to the register address or memory address. Meanwhile, a synchronization mutex is set for the preset address, and the synchronization mutex can be realized by a semaphore object of System Verilog to ensure atomic access of the test program to the preset address, complete writing of test data to the address, avoid data confusion caused by multiple triggering of message transmission tasks at the same clock edge, and effectively improve system stability.
[0080] Figure 3 A flowchart of step S112 in the test control method provided by the embodiment of the application is shown in FIG. 2. Figure 8 As shown in FIG. 2, in one embodiment, step S112 can include the following steps.
[0081] Step S1121: Detect whether a current process meets a preset condition for writing data to the preset interface.
[0082] Step S1122: When the preset condition is met, create a synchronization mutex and delay capture the timing of concurrent processes.
[0083] Step S1123: release the synchronization mutex after the current process writes data.
[0084] Specifically, due to the existence of asynchronous tasks, the test platform may fall into a multi-module competition bus situation, so it is necessary to generate a synchronization mutex for the preset interface. First, create and use a SystemVerilog semaphore (Semaphore) object, initialize the synchronization mutex, and through the built-in put() and get() functions, perform channel scheduling to ensure that only one process can write to the address, output information and control at the same time, and avoid data competition.
[0085] Further, taking the AHB bus as an example, for the data sending end, the bus signal is detected at the clock rising edge to determine whether the preset write condition is met, for example, it is required that haddr==LED_DRIVER_BASE, htrans==2'b10, hburst==1'b0. If it is determined that the expected condition is met, the string hwdata written in the AHB Single mode is captured. After determining that the preset write condition is met, the concurrent process is started, for example, the concurrent process can be started through the fork...join_none syntax, and a delay of 1 clock cycle is used as a capture delay to ensure that the data is written to the preset interface. Through the delay of the timing, it is ensured that the bus data has been completely written, avoiding the output occupation caused by the timing problem, blocking the next concurrent process. After the write data is completed, the synchronization mutex of the thread on the other end is notified to be released.
[0086] For the data receiving end, the bus signal (such as hready==1) is detected at the clock rising edge to determine whether it is pulled high, and then the try_get() function of the semaphore object is called to non-blockedly try to obtain the synchronization mutex from the preset interface, avoiding the blocking caused by the unready resource. If the data is successfully obtained, the synchronization mutex is released, the decode_msg(hwdata[7:0]) is defined to parse and select the output bus message, and the uvm_event event processing is triggered to include the control code communication data.
[0087] Further, the bus signals can be classified, and the clock signal (such as hclk), the address signal (such as haddr), the master signal (such as htrans, hburst) of the data sending end side device, the data signal (such as hwdata), and the slave signal (such as hready, hresp) of the data receiving end side device control the request signal of the device. When it is monitored that the master device requests to write and the slave device is ready, it is determined that the preset trigger condition for capturing the string is met.
[0088] Similarly, for the master device using a non-standard bus interface, the communication data can be monitored by the memory controller. For example, for a standard SRAM memory controller, the clock signal (e.g., clk), the address signal (e.g., maddr), the master signal (e.g., mwrite, mwstrb), the data signal (e.g., mdata), and the slave signal (e.g., saccept) can be required to meet the preset conditions, respectively.
[0089] The above embodiments specifically list two typical bus and memory controller signal monitoring scenarios, and demonstrate the monitoring conditions of the key signal categories of the clock signal, the address signal, the data signal, the master signal, and the slave signal. It should be noted that the protection scope of the present patent is not limited to the above specific data and control signal examples, but in actual application, it is necessary to ensure that all related signal categories are covered to achieve a complete technical solution.
[0090] Figure 4 A flowchart of step S120 of a test control method provided by an embodiment of the present application is shown in FIG. 2. In one embodiment, step S120 can include the following steps. Figure 4
[0091] Step S121: Obtain and decode the control field bit in the communication data field.
[0092] Step S122: If the value of the control field bit meets the preset condition, determine that the communication data is a control code.
[0093] Step S123: If the value of the control field bit does not meet the preset condition, determine that the communication data is a normal string.
[0094] Specifically, for the control code judgment, when the test program needs to output messages and states, write ASCII code (normal character) messages or predefined control codes to the preset interface. By monitoring the communication data of the preset interface, when an effective message is captured and determined, the data field on the bus is obtained and the control bit is judged, for example, the value of the control field bit at a preset position in the data field is judged, so as to decode and identify whether the communication data is a normal character or a control code.
[0095] Further, in one specific embodiment, the control code is identified by obtaining the low 8-bit data of the bus and judging whether the highest bit is 1. If the highest bit is 1, it is considered as a control code and enters the special processing flow; if the highest bit is 0, it is considered as a normal ASCII code and is directly output, so that the clear classification of control codes and normal characters is realized by the high bit identification method, and the readability and controllability of the system are improved.
[0096] Figure 5 A flowchart of step S130 in the test control method provided by the embodiment of the present application is shown in FIG. 13. In one embodiment, step S130 can include: Figure 5
[0097] Step S131: Obtain a control code macro definition library.
[0098] Step S132: Determine the test result corresponding to the control code according to the control code macro definition library.
[0099] Specifically, the test result can include test pass, test failure, test interruption, entering a debugging state, and returning to a main function, etc. The test result corresponding to the control code can be determined by pre-setting. Specifically, the control code macro definition library can be created by macro definition. The control code definition library includes a plurality of preset control codes and their corresponding test result information. For example, the control code CPU_PASS represents test pass, the control code CPU_FAIL represents test failure, the control code CPU_IRQ_N represents entering an interruption function, the control code CPU_CHECK_POINT represents entering an intermediate debugging state, and the control code CPU_MAIN_RETURN represents returning to a main function. It can be understood that the control code macro definition library is not limited to the above control codes, and more control codes can be defined according to actual test requirements.
[0100] Figure 6 A flowchart of step S140 in the test control method provided by the embodiment of the present application is shown in FIG. 14. In one embodiment, step S140 can include: Figure 6
[0101] Step S141: Display the test result through a console.
[0102] and / or;
[0103] Step S142: Write the test result into a log file according to a preset format.
[0104] Specifically, when the test result is obtained by analyzing the control code, the output printing mode can be selected according to the test requirement, different system functions of different test platforms are called to realize the output of different channels, for example, the output can be realized to the console or written into a log file. When the output is selected to the console, the display and the write of the console can be used to display, when the log file storage ($fwrite) is selected, the log recording function can be enabled by defining the parameter cLogEn, the log is recorded and stored according to the preset format, the preset format can be determined according to the actual test requirement, for example, the context information can include the timestamp, the module name and the level information. The double-channel output mechanism combined with the log management capability provides the structured support for the system and enhances the traceability of the debugging information.
[0105] Figure 7 A flowchart of a test control method provided for another embodiment of the present application is shown in FIG. 6. In one embodiment, after step S140, the test control method can further include: Figure 7
[0106] Step S150: controlling the software test platform to interact with the hardware test platform.
[0107] and / or;
[0108] Step S160: ending the monitoring of the preset interface.
[0109] Specifically, after the test result is determined, in addition to outputting the test result, other operations can be performed according to the requirement, for example, the information and state interaction of the software test platform and the hardware test platform can be performed, or the monitoring of the preset interface is stopped to end the test.
[0110] Further, when the cross-domain interaction of the software test platform (C / C++) and the hardware test platform (SystemVerilog) is required, specifically, in the mainstream hardware test platform under the UVM framework, for example, the uvm_event event of cDbg_ue is defined as a detectable event by using the UVM method, the built-in method wait_trigger() is called to temporarily suspend the further test process until the interaction notification of the system debugging of the upper software test platform is received. On the software test platform side, when the test execution operation is required, the CPU_CHECK_POINT state is output through the preset interface, the built-in method trigger() is called to activate the cDbg_ue event of the hardware test platform side, optionally, the timestamp, the module name and the level information are embedded to notify and trigger the further execution of the hardware test platform, and the trace of the event is realized.
[0111] When the scene of the synchronization mechanism across the domain is needed, specifically, after the CPU completes all hardware initialization configuration (including clock configuration, power management, peripheral enablement, etc.), the subsequent hardware test process can be started, the cEnd_ue defined as a detectable uvm_event event by the UVM method can be called, the built-in method of wait_trigger() is placed in the position of further testing after the CPU completes the system configuration in the hardware test platform. After completing all system tests, the software test platform side needs to return the test end state through the preset interface, such as CPU_PASS / CPU_FAIL / CPU_MAIN_RETURN. On the hardware test platform side, different end states of the upper software test platform are defined, the mapping relationship between the software test state and the hardware response logic is clear, the built-in method of trigger() is called to further trigger the subsequent operation under different response logic of the hardware test platform, and the automatic test is realized.
[0112] The application not only realizes mutual exclusion between threads, but also realizes thread synchronization. The mutual exclusion is realized and acquired by setting the flag object, other threads are actively suspended and wait, and the unexecuted other threads are finally realized, instead of only discarding the failed request, solving the problems of being unable to realize synchronization with other threads, the failed thread may need to be actively retried, and CPU resources are wasted. The application sets to add uvm_event or a callback, and the state code output based on the flag capture can be realized. The various threads can be self-contained by mutual cooperation, the software and hardware interaction is more simple by event combination, the user is more clear about the specific request and implementation state of each thread, the user does not need to be notified by hardware interrupt in the future, and the code complexity is greatly reduced. The mutual exclusion method based on the flag in the application is a first-in-first-out waiting queue in the bottom layer, which ensures that the order of thread execution is strictly consistent with the request order, and can also set the queue length to prevent malicious threads from repeatedly occupying resources, instead of reading the value of the serial number counter and then adding 1, writing the register, and then verifying the count value, solving the problems of being unable to prevent malicious tampering of the serial number counter value and persistent request occupation.
[0113] The application also provides a test control device, Figure 8 A module schematic diagram of a test control device provided by the application is shown in the figure Figure 8 As shown in the figure, the test control device 200 includes a monitoring module 210, a recognition module 220, an analysis module 230, and an output module 240. The monitoring module 210 is used for monitoring the communication data of the preset interface based on the synchronization mutual exclusion mechanism. The recognition module 220 is used for recognizing the control code in the communication data. The analysis module 230 is used for analyzing the control code to determine the test result. The output module 240 is used for outputting the test result through the preset channel, so as to realize the interaction of the software and hardware test platforms and / or the storage of the log file.
[0114] In summary, the test control device provided by the embodiment of the application can distinguish between normal characters and special control codes, realize clear message classification, improve the readability and controllability of the system, realize an automated test process, and improve test efficiency by setting a universal preset data and control interface to analyze, classify, and respond to test data. Meanwhile, multi-channel data output can be selected to control the interaction between a software test platform and a hardware test platform, and the system state can be visualized by combining log management capabilities to enhance the traceability of debugging information. A synchronization mutex mechanism is also introduced to prevent possible concurrent conflicts and ensure that only one process can write to an address, output information, and control the preset interface at the same time, thereby avoiding data competition and improving system stability.
[0115] It can be understood that the test control device of the embodiment can also be used to implement the test control method in any of the above embodiments and has corresponding functional modules.
[0116] Further, the application also provides a computer device, Figure 9 The internal structure of the computer device provided by the embodiment of the application is shown in FIG. 1. As shown in FIG. 1, the computer device comprises at least one processor and a memory in communication connection with the at least one processor, and the memory stores a computer program. Figure 9 The processor executes the computer program to implement the steps of the test control method in any of the above embodiments.
[0117] In an embodiment of the application, the processor executing the computer program can realize the following: monitoring communication data of the preset interface based on a synchronization mutex mechanism; identifying a control code in the communication data; analyzing the control code to determine a test result; and outputting the test result through a preset channel to realize the interaction between the software test platform and the hardware test platform and / or log file storage.
[0118] Further, the application also provides a computer readable storage medium having a computer program stored thereon, and the computer program is executed by a processor to implement the steps of the test control method in any of the above embodiments.
[0119] In an embodiment of the application, the computer program executed by the processor can realize the following: monitoring communication data of the preset interface based on a synchronization mutex mechanism; identifying a control code in the communication data; analyzing the control code to determine a test result; and outputting the test result through a preset channel to realize the interaction between the software test platform and the hardware test platform and / or log file storage.
[0120] The various embodiments in this application are described using a progressive manner. Identical or similar parts among the various embodiments can be mutually referred to. Each embodiment focuses on the difference from other embodiments. In particular, the device and medium embodiments are described simply because they are substantially similar to the method embodiments. The relevant parts can be referred to the description of the method embodiments.
[0121] The specific embodiments of the application have been described. Other embodiments are within the scope of the following claims. In some cases, actions recited in the claims can be performed in a different order and still achieve desirable results. Additionally, the processes depicted in the accompanying figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.
[0122] The device and medium provided by the embodiments of the application are one-to-one corresponding to the method. Therefore, the device and medium also have similar beneficial technical effects as the method. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the device and medium will not be described here.
[0123] Those skilled in the art will appreciate that embodiments of the application can be a method, a system, or a computer program product. Accordingly, the application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer-readable program code.
[0124] The application is described with reference to the flowcharts and / or block diagrams of the method, device (system), and computer program product according to the embodiments of the application. It should be understood that each flow and / or block in the flowcharts 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, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a device that implements the flow Figure 1 The function of one flow or multiple flows and / or blocks Figure 1 The device that implements the function specified in one block or multiple blocks.
[0125] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.
[0126] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.
[0127] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.
[0128] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.
[0129] Computer-readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
[0130] It should also be noted that the terms "comprising," "comprises" or "comprised of" as used herein are synonymous with "including," "includes" or "containing," "contains," and should be affording the broadest scope to the included components as possible. The use of the negative "not" in the claims, such as "does not contain" or "does not include" means that the claims do not include the element that is being negated, but does not exclude the possibility that the element is present. The use of the negative "not" in the claims, such as "does not contain" or "does not include" means that the claims do not include the element that is being negated, but does not exclude the possibility that the element is present.
[0131] The technical features of the above-described embodiments can be combined in any manner, and for the sake of brevity, not all possible combinations are described. However, it should be understood that the scope of the specification encompasses all possible combinations.
[0132] The above-described embodiments are merely illustrative of several embodiments of the present application and do not limit the scope of the present application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present application, and such modifications and improvements should be construed as falling within the scope of the present application. Therefore, the scope of the present application should be determined by the appended claims.
Claims
1. A test control method, characterized in that, include: The communication data of the preset interface is monitored based on the synchronization mutex lock mechanism, including: setting a dedicated port address and / or memory-mapped address as the preset interface; writing the data to be output into the general preset interface through the test program, generating a synchronization mutex lock for the preset interface, creating and using a semaphore object, initializing the synchronization mutex lock, and performing hardware state synchronization and channel scheduling by calling built-in functions. Identifying control codes in the communication data includes: when the communication data is monitored by the preset interface, real-time decoding and identification of control field bits in the data to distinguish between ordinary characters and special control codes; if identified as a control code, it enters a special processing flow; if identified as an ordinary character, it is directly output; the identification rules for control codes are formulated by setting decoding classification logic for the fields of the captured communication data within the module of the preset interface. Parsing the control code to determine the test result includes: after the control code is identified, parsing the meaning of the control code, and determining the test result based on the meaning of the control code. The meaning of the control code is preset, and the meaning of different control codes is set according to macro definitions. The test results are output through a preset channel to enable interaction between the software and hardware testing platform and / or storage of log files.
2. The test control method according to claim 1, characterized in that, The step of generating a synchronous mutex lock for the preset interface includes: Detect whether the current process meets the preset conditions for writing data to the preset interface; A synchronous mutex lock is created when preset conditions are met, and the timing of concurrent processes is delayed. After the current process finishes writing data, the synchronization mutex is released.
3. The test control method according to claim 2, characterized in that, The synchronization range of the synchronous mutex lock includes: When using a common preset interface for input, it is associated with the current hardware state; The control code output for interaction between the hardware and software platforms is occupied during multi-channel output; The string output used for generating software logs during multi-channel output.
4. The test control method according to claim 1, characterized in that, The process of identifying the control code in the communication data includes: Retrieve and decode the control field bits in the communication data field; If the value of the control field bit meets the preset conditions, then the communication data is determined to be the control code; If the value of the control field does not meet the preset conditions, the communication data is determined to be a normal string.
5. The test control method according to claim 1, characterized in that, The process of parsing the control code to determine the test result includes: Obtain the control code macro definition library; The test result corresponding to the control code is determined according to the control code macro definition library; The test results include at least one of the following: test passed, test failed, test interrupted, entering debug state, and returning to the main function.
6. The test control method according to claim 1, characterized in that, The step of outputting the test results through a preset channel includes: The test results are displayed in the console. And / or; write the test results to a log file according to a preset format; The preset format includes at least one of timestamp, module name, and level information.
7. The test control method according to claim 1, characterized in that, After parsing the control code to determine the test result, the method further includes: Control the interaction between the software testing platform and the hardware testing platform; And / or, terminate monitoring of the preset interface.
8. A test control device, characterized in that, include: The monitoring module is used to monitor the communication data of a preset interface based on a synchronization mutex lock mechanism, including: setting a dedicated port address and / or memory-mapped address as the preset interface; writing the data to be output into the general preset interface through a test program, generating a synchronization mutex lock for the preset interface, creating and using a semaphore object, initializing the synchronization mutex lock, and performing hardware state synchronization and channel scheduling by calling built-in functions. The identification module is used to identify control codes in the communication data, including: when monitoring the communication data of the test program, performing real-time decoding and identification of the control field bits in the data to distinguish between ordinary characters and special control codes; if identified as a control code, it enters a special processing flow; if identified as an ordinary character, it is directly output; and formulating the identification rules of control codes by setting decoding classification logic for the fields of the captured communication data in the module of the preset interface. The parsing module is used to parse the control code to determine the test result, including: after the control code is identified, parsing the meaning of the control code, and determining the test result according to the meaning of the control code. The meaning of the control code is preset, and the meaning of different control codes is set according to macro definitions. The output module is used to output the test results through a preset channel to enable interaction between the software and hardware testing platform and / or storage of log files.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the test control method as described in any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the test control method as described in any one of claims 1 to 7.
Citation Information
Patent Citations
System verification using one or more automata
CN101019102A
Cloud-authenticated site resource management devices, apparatuses, methods and systems
CN105981443A