A coffee machine multi-protocol fusion production method and device, a coffee machine and a medium

Abstract

Embodiments of the present application provide a coffee machine multi-protocol fusion production test method and device, a coffee machine and a medium, comprising: after the coffee machine is initialized, receiving to-be-tested item information; classifying the to-be-tested item information to determine a target to-be-tested type; determining at least two target test protocols from a serial port protocol, an ice maker frame protocol, a coffee machine fixed-length frame protocol, a network socket peripheral protocol and an over-the-air download packet protocol based on the target to-be-tested type; converting the to-be-tested item information based on the target test protocol to generate a test instruction; obtaining protocol return data corresponding to the target test protocol, the protocol return data being generated based on executing the test instruction; analyzing the protocol return data to generate a test report; and outputting the test report. Through the embodiments of the present application, the production test efficiency of the coffee machine can be improved.

Description

Technical Field

[0001] This application relates to the field of production testing automation technology, and in particular to a multi-protocol fusion production testing method for a coffee machine, a multi-protocol fusion production testing device for a coffee machine, a coffee machine, and a computer-readable storage medium. Background Technology

[0002] A typical coffee machine comprises multiple sub-devices. During production testing, different sub-devices require different tools or scripts, necessitating frequent switching of software, serial ports, parameters, and test procedures by operators, leading to unstable production line cycles. Furthermore, each type of sub-device often corresponds to a different communication protocol, meaning multiple protocols exist within the coffee machine. This fragmented approach, lacking a unified scheduling layer for test results, hinders unified management and makes it difficult to generate comprehensive machine-wide test results, resulting in low production testing efficiency. Summary of the Invention

[0003] In view of the above problems, embodiments of this application are proposed to provide a coffee machine multi-protocol fusion production test method, a coffee machine multi-protocol fusion production test apparatus, a coffee machine, and a computer-readable storage medium to overcome or at least partially solve the above problems.

[0004] To address the aforementioned problems, in a first aspect of this application, an embodiment discloses a multi-protocol fusion testing method for coffee machines. The multi-protocol includes: a serial port protocol, an ice maker frame protocol, a coffee machine fixed-length frame protocol, a network socket peripheral protocol, and an over-the-air download packet protocol. The method includes: After the coffee machine is initialized, the test item information is received; The information of the items to be tested is classified to determine the target test type; Based on the target test type, at least two of the following are identified as target test protocols: serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air download packet protocol. Based on the target testing protocol, the information of the item to be tested is transformed to generate test instructions; Obtain protocol return data corresponding to the target test protocol, wherein the protocol return data is generated based on the execution of the test instruction; Parse the data returned by the protocol and generate a test report; Output the test report.

[0005] Optionally, it also includes: When the target test type is a manual test type, obtain the test input data; If the test input data corresponds to a qualified type and the protocol return data corresponds to a qualified type, the protocol return data is associated with the test input data to update the protocol return data; If the test input data corresponds to a failure type or the protocol return data corresponds to a failure type, update the protocol return data to the preset failure identifier data.

[0006] Optionally, it also includes: The coffee machine is initialized, and the serial port and camera resource services are released. Optionally, after the step of outputting the test report, the method further includes: Restore the serial port resource usage service and the camera resource usage service.

[0007] Optionally, the step of parsing the protocol return data and generating a test report includes: The returned data from the protocol is verified to determine the verified returned data; The verification return data is parsed based on the target testing protocol to generate a test report.

[0008] Optionally, the step of verifying the protocol-returned data and determining the verified return data includes: The integrity of the protocol-returned data is verified, including frame header detection, packet length detection, packet tail detection, read length detection, refresh time detection, and total timeout time detection. The data returned by the protocol that passes the integrity check will be identified as the verification return data.

[0009] Optionally, the step of parsing the verification return data based on the target testing protocol and generating a test report includes: Based on the target test protocol, the verification return data is parsed to determine the test item completion rate, test item success rate, and test item failure rate. Obtain device serial number and test logs; A test report is generated by combining the test item completion rate, test item success rate, test item failure rate, device serial number, test log, and verification return data.

[0010] Optionally, when the target test protocol includes the ice maker frame protocol, the step of converting the test item information based on the target test protocol and generating test instructions includes: The information to be tested is encoded using big-endian encoding to determine the big-endian byte; Perform an 8-bit addition check on the big-endian byte to determine the check byte; The test instruction is generated by combining the big-endian byte and the check byte.

[0011] Optionally, when the target test protocol includes the coffee machine fixed-length frame protocol, the coffee machine fixed-length frame protocol corresponds to a 26-byte fixed-length frame structure; the step of converting the test item information based on the target test protocol to generate test instructions includes: Based on the 26-byte fixed-length frame structure, the information of the item to be tested is converted to generate test instructions; and / or, The step of obtaining the protocol return data corresponding to the target test protocol includes: Scan the 26-byte frame data of the coffee machine to determine if it is protocol return data; and / or, The steps of parsing the protocol-returned data and generating a test report include: Based on the 26-byte fixed-length frame structure, the protocol return data is parsed to generate a test report.

[0012] Optionally, when the target test protocol includes the network socket peripheral protocol, the step of converting the test item information based on the target test protocol and generating test instructions includes: The test item information is converted based on the network socket peripheral protocol to generate test instructions; and / or, The steps of parsing the protocol-returned data and generating a test report include: Based on the network socket peripheral protocol, the returned data of the protocol is parsed to generate a test report.

[0013] Optionally, when the target testing protocol includes the over-the-air download subpacket protocol, the step of converting the test item information based on the target testing protocol and generating test instructions includes: Based on the aforementioned over-the-air download subpacket protocol, the information of the item to be tested is converted to generate test instructions; and / or, The steps of parsing the protocol-returned data and generating a test report include: Based on the over-the-air download subpacket protocol, the returned data of the protocol is parsed to generate a test report.

[0014] Optionally, the serial port protocol, the ice maker frame protocol, the coffee machine fixed-length frame protocol, the network socket peripheral protocol, and the over-the-air download packet protocol share a unified adapter interface.

[0015] Optionally, the step of outputting the test report includes: Obtain the device serial number; If the preset target test item in the test report has a value, the device serial number is associated with the test report and output. If there are empty values ​​for the preset target test items in the test report, a test prompt message will be output.

[0016] In a second aspect of this application, embodiments of this application disclose a multi-protocol fusion testing device for coffee machines. The multi-protocol includes: a serial port protocol, an ice maker frame protocol, a coffee machine fixed-length frame protocol, a network socket peripheral protocol, and an over-the-air download packet protocol. The device includes: The receiving module is used to receive the test item information after the coffee machine is initialized; The classification module is used to classify the information of the items to be tested and determine the target type of the item to be tested; The filtering module is used to determine at least two of the following as target test protocols based on the target test type: the serial port protocol, the ice maker frame protocol, the coffee machine fixed-length frame protocol, the network socket peripheral protocol, and the over-the-air download packet protocol. The conversion module is used to convert the information of the item to be tested based on the target testing protocol and generate test instructions; The acquisition module is used to acquire protocol return data corresponding to the target test protocol, wherein the protocol return data is generated based on the execution of the test instruction; The parsing module is used to parse the data returned by the protocol and generate a test report; The output module is used to output the test report.

[0017] In a third aspect of this application, embodiments of this application disclose a coffee machine, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the steps of the coffee machine multi-protocol fusion production testing method described above.

[0018] In a fourth aspect of this application, embodiments of this application disclose a computer-readable storage medium, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the coffee machine multi-protocol fusion production testing method as described above.

[0019] The embodiments of this application have the following advantages: This application embodiment involves receiving test item information after the coffee machine is initialized; classifying the test item information to determine the target test type; identifying at least two target test protocols from serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air packet protocol based on the target test type; converting the test item information based on the target test protocol to generate test instructions; obtaining protocol return data corresponding to the target test protocol, the protocol return data being generated based on the execution of the test instructions; parsing the protocol return data to generate a test report; and outputting the test report. By classifying the test item information to determine the target test type, automatically selecting at least two of the serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air packet protocol as target test protocols; and constructing, sending, and obtaining test instructions for the test item information based on the target test protocol to abstract a consistent test item execution result, the protocol return data can be uniformly parsed, a test report generated, and output. There is no need to switch repeatedly between serial port assistants, script tools, peripheral tools and backend systems. The execution of key test items and report upload of the whole machine can be completed in one test, improving production testing efficiency. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the steps of an embodiment of a multi-protocol fusion testing method for coffee machines according to this application; Figure 2 This is a flowchart illustrating the steps of another embodiment of the multi-protocol fusion production testing method for coffee machines in this application; Figure 3 This is a schematic diagram of the coffee machine architecture, illustrating an example of a multi-protocol fusion testing method for coffee machines according to this application. Figure 4 This is a flowchart illustrating the steps of a multi-protocol fusion testing method for coffee machines according to this application; Figure 5 This is a structural block diagram of an embodiment of a coffee machine multi-protocol fusion testing device according to this application; Figure 6 This is a structural block diagram of a coffee machine provided in an embodiment of this application; Figure 7 This is a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation

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

[0022] Coffee machine testing involves technologies such as multi-device communication protocol adaptation, test task scheduling, equipment status analysis, manual confirmation of closed-loop processes, system service collaborative control, and automatic upload of test reports. A typical coffee machine consists of a central control motherboard, MCU control board, coffee machine subsystem, ice maker subsystem, barcode scanner, ticket machine, camera, door motor, pump, LED strip, fan, and sensors for temperature, water level, photoelectric sensors, and weighing. The production line needs to perform functional verification, status query, anomaly identification, manual confirmation of phenomena, log retention, and server report upload for these components within a short cycle time.

[0023] Existing technical solutions typically employ multiple independent debugging tools to complete testing. For example, operators use a serial port assistant to send hexadecimal commands to the MCU (Microcontroller Unit) control board, another dedicated tool to check the communication status of the coffee machine, a script or command line to check the ice maker, and a browser or separate host computer program to test peripherals such as barcode scanners and ticket machines. The working principle of this approach is that each tool is responsible for only one communication interface or one sub-device, and the test results are manually observed and recorded, then summarized in a table or backend system.

[0024] The existing technical solution two uses a semi-automated production test script. This type of script can issue some serial port commands in a fixed order and save the returned raw data as a log. However, it usually only covers MCU layer control commands and lacks unified handling for WebSocket peripherals, ice maker custom frame protocols, coffee machine fixed-length status frame protocols, manual confirmation results, and Linux (system name) system service usage issues.

[0025] Existing technical solution three employs a separation of manual confirmation and background upload. After the equipment returns successfully, production personnel verbally or in writing confirm phenomena such as lights, doors, fans, printing, and recording, and finally, the test results are uploaded manually or by another system. This solution cannot combine machine response, manual confirmation, sub-device SN (Serial Number) binding information, and original logs into a traceable overall machine report.

[0026] However, the above solutions have the following problems: Different sub-devices require different tools or scripts, necessitating frequent switching between software, serial ports, parameters, and test procedures by operators, resulting in high training costs and unstable production line pace. This indicates fragmented tools and low production testing efficiency. The lack of a unified scheduling layer among MCU serial port protocols, ice maker custom frame protocols, coffee machine fixed-length frame protocols, WebSocket network socket peripheral protocols, and OTA (Over-The-Air) packet protocols leads to protocol fragmentation, making it impossible to manage test results uniformly and form a complete machine test status table. Traditional serial port tools can only display hexadecimal data, requiring manual judgment of fields such as packet header, packet length, checksum, status bits, temperature value, serial number, and version number, which is prone to misjudgment or omission and difficult to automatically parse, resulting in low production testing efficiency. Phenomena such as LED strip color, door movement, fan operation, printing effects, audio playback, and camera images cannot be judged solely based on device return packets. Existing solutions struggle to bind manual confirmation results and machine responses to the same test result, resulting in a disconnect between manual confirmation and machine response, making it difficult to integrate manually input retest results. In a Linux system environment, serial ports or cameras may be occupied by background services. If resources are not released before testing, it can lead to serial port opening failure, camera preview failure, or system services not recovering after the test. System resource occupation can cause occasional failures, while production testing failures can lead to test failures. Manual spreadsheets or single-point logs cannot uniformly record test pass rates, untested items, sub-device SN binding, original responses, manual confirmations, and server-uploaded results, which is not conducive to quality traceability and after-sales analysis, and the report traceability capability is insufficient.

[0027] In order to at least partially solve the above-mentioned technical problems, embodiments of this application are proposed.

[0028] Reference Figure 1This document illustrates a flowchart of an embodiment of a multi-protocol fusion production testing method for a coffee machine according to this application. The multiple protocols include: a serial port protocol, an ice maker frame protocol, a coffee machine fixed-length frame protocol, a network socket peripheral protocol, and an over-the-air (OTA) packet download protocol. The serial port protocol can be an MCU serial port protocol, enabling serial communication between the MCU and peripherals / other MCUs based on the UART interface. The serial port protocol includes byte information such as a fixed frame header, version number, serial number, command word, data length, valid data, and checksum. The ice maker frame protocol is a UART communication protocol customized for the specific business scenarios of ice makers, adapting to dedicated control logic such as ice making, ice removal, and fault reporting. The information in the ice maker frame protocol consists of a start identifier, data length, function type ID (identifier), ice maker status data, and a 6-checksum. The coffee machine fixed-length frame protocol is a fixed-length serial communication protocol designed for coffee machine control scenarios, simplifying parsing logic and improving response speed. The network socket peripheral protocol is a full-duplex communication protocol based on TCP, enabling bidirectional real-time data interaction between web pages / cloud and intelligent peripherals. Over-the-air (OTA) packet download protocol is a transmission protocol for remote firmware upgrades of embedded devices.

[0029] The coffee machine multi-protocol fusion production testing method may specifically include the following steps: Step 101: After the coffee machine is initialized, receive the information of the item to be tested; After the coffee machine is initialized, the operator can manually select the test items to be tested or directly input a preset test item list to determine the test item information. The system receives the test item information to begin the overall production testing process for the coffee machine. The test item information includes multiple test items. Each test item corresponds to one test content.

[0030] Step 102: Classify the information of the items to be tested and determine the target type of the item to be tested; Each test item in the test item information can be categorized to determine the corresponding test type for each item. For example, the test type can be determined by categorizing the test items according to their corresponding test sub-device type or service type. The test type corresponding to each test item is then identified as its target test type. The target test type represents the test type of each test item, and each test type has a corresponding test protocol. These test protocols are one of the following: serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air download packet protocol.

[0031] Step 103: Based on the target test type, determine at least two of the following as target test protocols: serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air download packet protocol; For each target test type, matching protocols from serial port protocols, ice maker frame protocols, coffee machine fixed-length frame protocols, network socket peripheral protocols, and over-the-air packet download protocols are selected as candidate test protocols. Matching is performed for each target test type separately, identifying at least two matching protocols from each of the following categories as candidate test protocols. These candidate protocols are then used as the target test protocols.

[0032] Step 104: Based on the target testing protocol, the information of the item to be tested is converted to generate test instructions; The test item information is transformed according to the data structure of the target test protocol to generate test instructions. These instructions can then be deployed to the corresponding sub-devices or services for execution. This allows for the unified conversion of multiple different test protocols and the generation of test instructions without the need to switch between different production testing tools.

[0033] Step 105: Obtain protocol return data corresponding to the target test protocol, wherein the protocol return data is generated based on the execution of the test instruction; After a sub-device or service executes a test command, the output data or status it achieves can be used as protocol return data. Protocol return data corresponding to the target test protocol can be obtained from the sub-device or service. This allows for unified sending and receiving of protocol return data for each target test protocol.

[0034] Step 106: Parse the protocol return data and generate a test report; The returned data from the protocol can be parsed according to the target test protocol to generate a test report. This allows for unified parsing of the returned data for each target test protocol, unifying all data and generating a test report.

[0035] Step 107: Output the test report.

[0036] Output a test report. Operators can use the test report to determine the actual operating status of the coffee machine and thus implement corresponding maintenance strategies.

[0037] This application embodiment involves receiving test item information after the coffee machine is initialized; classifying the test item information to determine the target test type; identifying at least two target test protocols from serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air packet protocol based on the target test type; converting the test item information based on the target test protocol to generate test instructions; obtaining protocol return data corresponding to the target test protocol, the protocol return data being generated based on the execution of the test instructions; parsing the protocol return data to generate a test report; and outputting the test report. By classifying the test item information to determine the target test type, automatically selecting at least two of the serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air packet protocol as target test protocols; and constructing, sending, and obtaining test instructions for the test item information based on the target test protocol to abstract a consistent test item execution result, the protocol return data can be uniformly parsed, a test report generated, and output. There is no need to switch repeatedly between serial port assistants, script tools, peripheral tools and backend systems. The execution of key test items and report upload of the whole machine can be completed in one test, improving production testing efficiency.

[0038] Reference Figure 2 This document illustrates a flowchart of another embodiment of the multi-protocol fusion production testing method for coffee machines according to this application. The multi-protocol includes: a serial port protocol, an ice maker frame protocol, a coffee machine fixed-length frame protocol, a network socket peripheral protocol, and an over-the-air packet download protocol. The serial port protocol, the ice maker frame protocol, the coffee machine fixed-length frame protocol, the network socket peripheral protocol, and the over-the-air packet download protocol share a unified adapter interface. All protocols share a unified transmit / receive / parsing output adapter interface, meaning each protocol adapter provides a unified "send command—receive response—return raw data and error information" interface. Different protocol adapters share the same test item execution result data structure. The multi-protocol fusion production testing method for coffee machines may specifically include the following steps: Step 201: Initialize the coffee machine and release the serial port resource service and the camera resource service. The implementation of this application embodiment can be encapsulated in a production testing tool. This production testing tool can be deployed in the coffee machine of the test system. The user can start the production testing tool. The system enters a graphical production testing interface, initializing the test item buttons, log display area, raw response display area, manual confirmation window, and report upload entry. The coffee machine system can be initialized, for example, loading the machine's serial number (SN) from the machine's hardware configuration file, reading serial port port, baud rate, timeout, and other configurations, initializing the log directory, and logging into the server to obtain an access token. Furthermore, when running on a Linux system, it simultaneously checks serial port permissions, serial port pass-through status, and system services that may occupy serial port or camera resources; it also releases serial port resource-consuming services and camera resource-consuming services.

[0039] Step 202: After the coffee machine is initialized, receive the information of the item to be tested; After the coffee machine is initialized, testing can begin. Operators can manually select individual test items or determine the test item information according to a preset test item list and execute the entire machine production testing process. The start time of each test item can be recorded.

[0040] Step 203: Classify the information of the items to be tested and determine the target type of the item to be tested; The test items in the test item information can be categorized to determine the target test type for each item. For example, the information can be categorized according to the data type of the applicable serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air download packet protocol to determine the corresponding target test type.

[0041] Step 204: Based on the target test type, determine at least two of the following as target test protocols: serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air download packet protocol; Based on the target test type, at least two protocols can be identified as target test protocols from serial port protocols, ice maker frame protocols, coffee machine fixed-length frame protocols, network socket peripheral protocols, and over-the-air (OTA) packet protocols. For example, each test item can be pre-labeled with its corresponding protocol category in a configuration table, serving as the target test type. By reading this target test type, the corresponding protocols from the serial port protocols, ice maker frame protocols, coffee machine fixed-length frame protocols, network socket peripheral protocols, and OTA packet protocols can be matched as the target test protocols. This allows the identification of the adapter instance corresponding to the target test protocol, and the invocation of its command construction, sending, receiving, verification, and parsing methods to complete the test item. This enables unified construction, sending, receiving, verification, and parsing of multiple protocols within a single production testing tool. For example, if the test item pertains to the detection of the status of a door, pump, light strip, sensor, or MCU, then the serial port protocol of the MCU 5E serial port protocol is selected as the target test protocol; if the test item pertains to the ice maker version or ice dispensing setting / reading, then the ice maker frame protocol of FF55+5555 frames is selected and ADD8 verification is performed; if the test item pertains to the coffee machine status query, then the coffee machine fixed-length frame protocol of 26 bytes 0x7E is selected; if the test item pertains to the scanning barcode scanner, ticket machine, or sub-device version reading, then the WebSocket ask / res protocol or other network socket peripheral protocols are selected; if the test item pertains to firmware upgrade, then the over-the-air download packet protocol is selected and CRC verification is performed.

[0042] Step 205: Based on the target testing protocol, the information of the item to be tested is converted to generate test instructions; The test item information can be transformed according to the data structure characteristics of the target test protocol to generate test instructions. Instruction frames or JSON messages are constructed based on the corresponding protocol adapter of the target test protocol and sent to the target device or local service via a background thread.

[0043] Step 206: Obtain protocol return data corresponding to the target test protocol, wherein the protocol return data is generated based on the execution of the test instruction; Within the specified timeout period for sending test commands, response data from the target device or local service can be received as the protocol return data corresponding to the target test protocol. Furthermore, the UI main thread can synchronously display the sending command, receiving progress, and raw response, avoiding UI blocking.

[0044] Step 207: When the target test type is a manual test type, obtain the test input data; After receiving the protocol return data, the system can determine whether the machine's response is sufficient to complete the judgment based on the target test type of the test item. For test items that can be directly judged from communication data, when the target test type is a manual test type, the operator needs to confirm whether the on-site phenomenon meets expectations and input the corresponding test input data. The test input data can be obtained. The test input data is data manually entered by the operator based on the test phenomenon. For example, for test items that require on-site observation, such as light strips, ambient lights, door movements, fans, pumps, printers, recordings, and camera images, the target test type can be determined to be a manual test type. A confirmation window matching the test item type pops up, prompting the operator to confirm whether the on-site phenomenon meets expectations, and the operator enters the test input data. The system obtains the test input data.

[0045] Step 208: If the test input data corresponds to a qualified type and the protocol return data corresponds to a qualified type, associate the protocol return data with the test input data to update the protocol return data; The test input data corresponding to the manual confirmation result can be verified with the protocol return data corresponding to the machine response. When a manual test type exists, the status type corresponding to the test input data will be input, which can include pass and fail types. Similarly, when a manual test type exists, the protocol return data will also carry the corresponding status type, also including pass and fail types. When both the test input data and the protocol return data correspond to the pass type, it means that the current test item is in a pass state. The protocol return data can be associated and bound with the test input data to form the final status of the test item, thereby updating the protocol return data. The machine response and manual confirmation are bound to the same test item result. For test items such as light strips, ambient lights, door movements, fans, pumps, printers, recordings, and cameras, the system generates different confirmation texts according to the test item type, requiring operators to confirm whether the actual phenomenon meets expectations. That is, only when both the communication response and manual confirmation meet the requirements is the test item recorded as pass.

[0046] For example, for peripheral functions such as barcode scanners, ticket machines, and sub-device version reading, which are proxied by the screen or local service, a local connection is established via WebSocket, using an ask / res request / response model. Each request includes a command word, sequence number, target group, source identifier, and timestamp. After receiving the response, the system parses the code, errmsg, and data fields and writes the results to a unified test item status. For instance, after receiving a successful print_test response, the ticket machine test will also pop up a manual confirmation window, requiring the operator to confirm whether the test ticket has actually been printed; the barcode scanner test executes the complete process of opening the barcode scanner, waiting for the scanning result, and closing the barcode scanner.

[0047] Step 209: If the test input data corresponds to a failure type or the protocol return data corresponds to a failure type, update the protocol return data to a preset failure identifier data; When the test input data or the protocol return data corresponds to a failure type, it means that one of the machine response or manually determined structures is identified as a non-compliant test item. The protocol return data can be updated to the preset failure flag data, which is used to characterize the non-compliant test item.

[0048] Step 210: Parse the protocol return data and generate a test report; It can perform unified integrity checks on the data returned by these protocols, parse the meaning of fields, generate readable status, write machine responses, parsing results, manual confirmation results, original response frames and error messages into a unified test result table, and update button colors, log display areas and original data display areas, etc., to generate test reports.

[0049] In an optional embodiment of the present invention, the step of parsing the protocol return data and generating a test report includes: Sub-step S2101: Verify the protocol return data and determine the verification return data; A unified integrity check is performed on data returned by different protocols to verify the returned data. Data that passes the verification is identified as the verified return data. The verified return data represents the protocol return data that has passed the integrity check.

[0050] Specifically, the step of verifying the protocol return data and determining the verification return data includes: performing integrity verification on the protocol return data, wherein the integrity verification includes frame header detection, packet length detection, packet tail detection, read length detection, refresh time detection, and total timeout time detection; and determining the protocol return data that passes the integrity verification as the verification return data.

[0051] The verification of protocol-returned data is an integrity check, which includes frame header detection, packet length detection, packet trailer detection, read length detection, refresh time detection, and total timeout detection. Specifically, it checks the packet header, packet trailer, packet length, CRC checksum, ADD8 checksum, response timeout, and the absence of continuous new data. If all requirements are met, the protocol-returned data is deemed to have passed the integrity check. Protocol-returned data that passes the integrity check is designated as the definitive verification return data.

[0052] Sub-step S2102: Based on the target test protocol, parse the verification return data and generate a test report.

[0053] Based on the target test protocol, the meaning of fields in the returned verification data is analyzed, such as door status, pump status, light strip status, temperature value, coffee machine status, ice maker version number, ice dispensing amount, MCU version number or SN number, etc. A test report is then generated by summarizing this data.

[0054] Specifically, the step of parsing the verification return data based on the target test protocol and generating a test report includes: parsing the verification return data based on the target test protocol to determine the test item completion rate, test item success rate, and test item failure rate; obtaining the device serial number and test log; and combining the test item completion rate, the test item success rate, the test item failure rate, the device serial number, the test log, and the verification return data to generate a test report.

[0055] Based on the data frame format of the target test protocol, the meaning of the fields in the verification return data can be parsed to read the fields corresponding to the test item completion rate, test item success rate, and test item failure rate; thus obtaining the test item completion rate, test item success rate, and test item failure rate. Then, the serial number of the device being tested and the test logs from the test process are obtained. The test item completion rate, the test item success rate, the test item failure rate, the device serial number, the test logs, and the verification return data are combined to generate a test report.

[0056] For example, for MCU control boards, a unified serial port transmission and reception method can be adopted based on the serial port protocol. Before sending, the input / output buffer is cleared, hexadecimal instructions are written, and the output buffer is immediately refreshed. During reception, the system no longer simply relies on "receiving a certain byte" to determine the end; instead, it comprehensively judges the completeness of the response based on the frame header, packet length, packet tail, maximum read length, continuous no new data time, and total timeout. This method can reduce misjudgments caused by incomplete packets, packet fragmentation, and delayed response packets in the serial port. Different parsers are called according to the name of the measured item. Examples include door status parsing, pump status parsing, photoelectric detection parsing, cabinet temperature parsing, water level detection parsing, door motor status parsing, MCU version number parsing, and MCU SN parsing. The parsing results are displayed in a human-readable format such as "Door open / closed," "Pump running / stopped," "Temperature value," "Version number," and "SN number."

[0057] Step 211: Output the test report; Upload the complete device test report. The test report summarizes all test items, including those tested, passed, failed, untested, success rate, failure rate, sub-device SN binding information, test logs, and original response summaries, and is uploaded via the server's test report interface. After upload, the system displays the reason for success or failure.

[0058] In an optional embodiment of this application, the step of outputting the test report includes: Obtain the device serial number; if the preset target test item in the test report has a value, associate the device serial number with the test report and output it; if the preset target test item in the test report has a null value, output test prompt information.

[0059] The preset target test items are the mandatory test items in the test report. If a preset target test item has a value, it means the mandatory test item has been completed; if it has a blank value, it means the mandatory test item has not been completed. The device serial number can be obtained. When the preset target test items in the test report have values, all mandatory tests have been completed. The device serial number can be associated with the test report and output, allowing for traceability to the corresponding device, enhancing traceability capabilities. When the preset target test items in the test report have blank values, the test report output can be prevented, and a test prompt message can be output. This test prompt message reminds the user to test the mandatory test items, i.e., the preset target test items.

[0060] In practical applications, a unified list of test items and a test result table can be maintained. When uploading a test report, the system can calculate the total number of test items, number of tested items, pass / fail items, number of untested items, success rate, and failure rate, and submit the system's serial number (SN), device model, test module, start time, end time, pass / fail result, test logs, sub-device SN binding information, user information, and enterprise identifier to the server. For formal production testing, if any mandatory test items are not completed, the system can block the upload and list the untested items; for debug mode, partial uploads can be allowed and marked in the logs.

[0061] Step 212: Restore the serial port resource usage service and the camera resource usage service.

[0062] Upon outputting the test report and completing the test, the serial port resource usage service and the camera resource usage service can be exited and resumed. This allows the production testing tool to not only control external devices but also coordinate the resources of the entire operating system, reducing occasional test failures. Specifically, in a Linux environment, some background services may occupy serial port or camera resources. By checking the status of relevant services using systemctl before starting or executing a specific test item, and stopping the service to release resources if necessary, the service is resumed based on the logs when the program exits. This mechanism allows the production testing tool to not only control external devices but also coordinate the resources of the entire operating system, reducing occasional test failures.

[0063] In an optional embodiment of this application, when the target test protocol includes the ice maker frame protocol, the step of converting the test item information based on the target test protocol and generating test instructions includes: performing big-endian encoding on the test item information to determine the big-endian byte; performing an 8-bit addition check on the big-endian byte to determine the check byte; and combining the big-endian byte and the check byte to generate test instructions.

[0064] For testing ice makers, instructions can be constructed based on the ice maker frame protocol. The FF55+5555 frame format can be used. The frame structure includes a synchronization header, packet length, data area, and an ADD8 (8-bit checksum) byte. The ADD8 checksum is calculated by adding the lower 8 bits from the first byte of the frame to the last byte of the data area. By listening to the frames sent by the master controller and parsing the version number, the frame sent from the screen to the master controller can also be assembled to set and read the ice dispensing amount. First, the information to be tested is encoded in big-endian byte order, i.e., the information to be tested is encoded and converted to big-endian bytes. Then, an 8-bit checksum is performed on the big-endian byte, adding the lower 8 bits from the first byte of the frame to the last byte of the data area; the resulting data is used as the content of the checksum byte. Combining the big-endian byte and the checksum byte, test instructions are generated. For example, when setting the ice quantity, a pop-up window can be used to obtain the user's input ice quantity and verify whether it is within the allowed range. Then, the ice quantity is encoded into big-endian bytes and written into the data area, and after calculating the ADD8 checksum, it is sent. After sending, the system continues to listen for response frames, parses the returned ice quantity in grams from the specified bytes, and displays the original frame and the parsing result on the interface.

[0065] In an optional embodiment of this application, when the target test protocol includes the coffee machine fixed-length frame protocol, the coffee machine fixed-length frame protocol corresponds to a 26-byte fixed-length frame structure; the step of converting the test item information based on the target test protocol to generate test instructions includes: converting the test item information based on the 26-byte fixed-length frame structure to generate test instructions.

[0066] When the target test protocol includes a coffee machine fixed-length frame protocol, a 26-byte fixed-length frame structure can be used as the data structure for this protocol. This 26-byte fixed-length frame structure is used for instruction construction, scanning, verification, and status summary display. The 26-byte fixed-length frame structure includes a header (0x7E), packet length (0x1A), warning field, fault field, coffee machine status field, communication instruction field, application status field, beverage number field, application number field, checksum byte, and packet trailer (0x7E). The information to be tested can be converted according to the bytes of the 26-byte fixed-length frame structure to generate test instructions.

[0067] In an optional embodiment of this application, when the target test protocol includes the coffee machine fixed-length frame protocol, the step of obtaining the protocol return data corresponding to the target test protocol includes: scanning the 26-byte frame data of the coffee machine and determining it as protocol return data; During scanning, bytes using a fixed-length 26-byte frame structure can also be scanned. After the test command, the first valid 26-byte frame can be scanned in the receive buffer, and this 26-byte frame data from the coffee machine is identified as the protocol return data.

[0068] In an optional embodiment of this application, when the target test protocol includes the coffee machine fixed-length frame protocol, the step of parsing the protocol return data and generating a test report includes: parsing the protocol return data based on the 26-byte fixed-length frame structure and generating a test report.

[0069] By analyzing the meaning of bytes in the 26-byte fixed-length frame structure, the protocol-returned data is parsed to extract fields such as coffee machine status, communication commands, and application status, generating a test report. To reduce the probability of production line misreading complex messages, only a summary status can be displayed in the confirmation window, such as "Coffee Machine Status: Standby / Idle / Running / Warning / Fault," while the complete original frame and detailed fields are kept in the log area.

[0070] In an optional embodiment of this application, when the target test protocol includes the network socket peripheral protocol, the step of converting the test item information based on the target test protocol and generating test instructions includes: converting the test item information based on the network socket peripheral protocol and generating test instructions.

[0071] The information of the item to be tested can be converted according to the socket address data structure corresponding to the network socket peripheral protocol to generate test instructions.

[0072] In an optional embodiment of this application, when the target test protocol includes the network socket peripheral protocol, the step of parsing the protocol return data and generating a test report includes: parsing the protocol return data based on the network socket peripheral protocol and generating a test report.

[0073] Test results data corresponding to the test items can be generated by converting the protocol return data according to the socket address data structure, and test reports can be generated by combining the test results data.

[0074] In an optional embodiment of this application, when the target test protocol includes the over-the-air (OTA) subpacket protocol, the step of converting the test item information based on the target test protocol and generating test instructions includes: converting the test item information based on the OTA subpacket protocol and generating test instructions.

[0075] The information of the item to be tested can be converted according to the data structure corresponding to the over-the-air download sub-packet protocol to generate test instructions.

[0076] In an optional embodiment of this application, when the target test protocol includes the over-the-air (OTA) subpacket protocol, the step of parsing the protocol return data and generating a test report includes: parsing the protocol return data based on the OTA subpacket protocol and generating a test report.

[0077] The test results data corresponding to the test items can be generated by converting the data returned by the protocol according to the data structure corresponding to the over-the-air download subpacket protocol, and the test results data can be combined to generate a test report.

[0078] This application embodiment unifies the scheduling of test item information from multiple protocols, enabling instruction construction, transmission, and parsing. Operators no longer need to repeatedly switch between serial port assistants, script tools, peripheral tools, and the backend system. Key test item execution and report uploading for the entire machine can be completed on a single interface, improving production testing efficiency. It automatically performs response integrity checks, verification, field parsing, and untested item statistics, avoiding misjudgments caused by manually reading hexadecimal data and reducing misjudgments and missed tests. For test items that cannot be fully verified by the machine, the system introduces manual confirmation and binds it to the test item results, ensuring the report reflects both communication status and on-site phenomena, enhancing test credibility. It automatically handles serial port and camera-related service usage issues, releasing and restoring resources as needed, reducing occasional failures caused by device resource conflicts and improving stability. The test report includes the entire machine's serial number (SN), sub-device SN bindings, test item statistics, raw logs, parsing results, and upload results, facilitating quality analysis, after-sales location, and production traceability, enhancing traceability capabilities. When adding a new sub-device or a new test item, you only need to add a protocol adapter, test item configuration, and parsing rules to connect to the unified scheduling and reporting system, thus improving scalability.

[0079] To enable those skilled in the art to clearly understand the embodiments of this application, an example is used below for illustration: For the production testing system architecture of coffee machines, please refer to... Figure 3 It can include the following modules: (1) Production Test UI (User Interface) Module: Used to display serial port configuration, test item buttons, logs, raw responses, confirmation pop-ups, and upload results. Operators can execute a single test item or a list of preset test items through a unified interface.

[0080] (2) Test Item Scheduling Module: Maintains a preset test item list and test item status table, and automatically selects the corresponding protocol channel according to the test item name or test item category. For example, the status of gate control, pump control, light strip, and sensor belongs to the MCU serial port protocol; the ice maker version and ice dispensing amount belong to the ice maker frame protocol; the coffee machine status belongs to the coffee machine fixed-length frame protocol; the barcode scanner, ticket machine, and sub-device version belong to the WebSocket protocol; and the firmware upgrade belongs to the OTA sub-packet protocol.

[0081] (3) Multi-protocol communication layer: including MCU 5E frame serial communication, ice maker FF55 frame communication, coffee machine 26-byte 0x7E frame communication, WebSocket ask / res communication, and OTA packet transmission communication. Each protocol adapter provides a unified interface for "sending instructions - receiving responses - returning raw data and error information".

[0082] (4) Status parsing module: Parses the raw data returned by different protocols, including packet header and footer checks, packet length judgment, CRC (Cyclic Redundancy Check) or ADD8 (8-bit cumulative check), field extraction and human-readable status conversion.

[0083] (5) Manual Confirmation Module: For test items that cannot be fully verified by machine response, a confirmation window will pop up, and the manual judgment result will be included in the test item pass / fail status. For example, whether the door is actually opened, whether the light strip color is pure, whether the fan is running, whether the receipt is printed, whether the recording is played normally, etc.

[0084] (6) System service coordination module: In the Linux running environment, detect system services that may occupy serial port or camera resources, stop the service before the test item is executed if necessary, and restore the service when exiting the program, thereby reducing occasional failures caused by resource occupation.

[0085] (7) Log and report module: Records the test item name, start time, end time, sent command, original response, parsing result, manual confirmation result, sub-device SN binding information, and uploads the whole machine test report through the server interface.

[0086] For the testing process of coffee machines, please refer to [reference needed]. Figure 4 : Step S1: Start the production testing tool. The system enters the graphical production testing interface, initializes the test item buttons, log display area, raw response display area, manual confirmation window, and report upload entry.

[0087] Step S2: Initialize the runtime environment.

[0088] Step S3: Select the receiving test item.

[0089] Step S4: Enter the multi-protocol scheduling node. The system pre-establishes a test item configuration table, which includes at least the test item name, protocol type, instruction construction rules, response parsing rules, whether manual confirmation is required, and report field mapping. When an operator selects a test item, the test item scheduling module reads the test item configuration and selects the corresponding execution channel from multiple protocol adapters according to the protocol type. The protocol adapters include an MCU serial port protocol adapter, an ice maker frame protocol adapter, a coffee machine fixed-length frame protocol adapter, a WebSocket peripheral protocol adapter, and an OTA packet splitting protocol adapter. Each protocol adapter provides a unified execution interface to the upper layer, enabling test items with different underlying protocols to enter the same set of verification, parsing, manual confirmation, and report upload processes.

[0090] Step S5: Perform protocol routing. If the test item pertains to door, pump, light strip, sensor, or MCU status detection, select the MCU 5E serial port protocol; if the test item pertains to ice maker version or ice dispensing quantity setting / reading, select the ice maker FF55+5555 frame protocol and perform ADD8 verification; if the test item pertains to coffee machine status query, select the 26-byte 0x7E fixed-length frame protocol; if the test item pertains to barcode scanner, ticket machine, or sub-device version reading, select the WebSocket ask / res protocol; if the test item pertains to firmware upgrade, select the OTA packet transmission protocol and perform CRC verification.

[0091] Step S6: Execute command sending and receiving. The corresponding protocol adapter constructs a command frame or JSON message, sends it to the target device or local service via a background thread, and receives response data within a specified timeout period. The UI main thread synchronously displays the sent command, receiving progress, and raw response to avoid UI blocking.

[0092] Step S7: Perform unified verification and status parsing. The status parsing module performs unified integrity checks on data returned by different protocols, including packet header, packet trailer, packet length, CRC check, ADD8 check, response timeout, and judgment of continuous lack of new data. After the verification passes, the system further parses the meaning of the fields and generates readable statuses, such as door status, pump status, light strip status, temperature value, coffee machine status, ice maker version number, ice dispensing amount, MCU version number or SN number.

[0093] Step S8: Determine if manual confirmation is required. The system determines whether the machine response is sufficient to complete the judgment based on the type of the test item. For test items that can be directly judged by communication data, proceed to step S110; for test items that require on-site observation, such as light strips, ambient lights, door movements, fans, pumps, printers, audio recordings, and camera footage, proceed to step S9.

[0094] Step S9: Perform manual confirmation. The system will pop up a confirmation window matching the test item type, prompting the operator to confirm whether the on-site phenomenon meets expectations, and bind the manual confirmation result with the machine response result to form the final pass or fail status of the test item.

[0095] Step S10: Update the test item status and logs. The system writes the machine response, parsing results, manual confirmation results, original response frames, and error messages into the unified test item result table, and simultaneously updates the button colors, log display area, and original data display area.

[0096] Step S11: Determine whether the test items are completed. If there are still unexecuted mandatory test items or the operator continues to select new test items, the process returns to step S3; if all mandatory test items for the entire machine have been completed, proceed to step S12.

[0097] Step S12: Generate and upload the complete system test report. The report module summarizes the total test items, tested, passed, failed, untested, success rate, failure rate, sub-device SN binding information, test logs, and original response summaries, and uploads the report by calling the server's test report interface. After the upload is complete, the system displays the reason for success or failure; when the program exits, it restores the temporarily stopped system services and ends the current production testing process.

[0098] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0099] Reference Figure 5 This diagram illustrates a structural block diagram of an embodiment of a coffee machine multi-protocol fusion testing device according to this application. The multi-protocol includes: a serial port protocol, an ice maker frame protocol, a coffee machine fixed-length frame protocol, a network socket peripheral protocol, and an over-the-air download packet protocol. The coffee machine multi-protocol fusion testing device may specifically include the following modules: The receiving module 501 is used to receive the test item information after the coffee machine is initialized; The classification module 502 is used to classify the information of the items to be tested and determine the target type of the items to be tested; The filtering module 503 is used to determine at least two of the following as target test protocols based on the target test type: the serial port protocol, the ice maker frame protocol, the coffee machine fixed-length frame protocol, the network socket peripheral protocol, and the over-the-air download packet protocol. The conversion module 504 is used to convert the information of the item to be tested based on the target test protocol and generate test instructions; The acquisition module 505 is used to acquire protocol return data corresponding to the target test protocol, wherein the protocol return data is generated based on the execution of the test instruction; Parsing module 506 is used to parse the protocol return data and generate a test report; Output module 507 is used to output the test report.

[0100] In an optional embodiment of this application, the apparatus further includes: The input module is used to acquire test input data when the target test type is a manual test type; The association module is used to associate the protocol return data with the test input data when both the test input data and the protocol return data correspond to a qualified type, so as to update the protocol return data. The failure module is used to update the protocol return data to a preset failure identifier data when the test input data corresponds to a failure type or the protocol return data corresponds to a failure type.

[0101] In an optional embodiment of this application, the apparatus further includes: The initialization module is used to initialize the coffee machine and release the serial port and camera resource usage services. In an optional embodiment of this application, the apparatus further includes: The recovery module is used to restore the serial port resource usage service and the camera resource usage service.

[0102] In an optional embodiment of this application, the parsing module 506 includes: The verification submodule is used to verify the data returned by the protocol and determine the verification data. The parsing submodule is used to parse the verification return data based on the target test protocol and generate a test report.

[0103] In an optional embodiment of this application, the verification submodule includes: The integrity verification unit is used to perform integrity verification on the protocol returned data. The integrity verification includes frame header detection, packet length detection, packet tail detection, read length detection, refresh time detection, and total timeout time detection. The determination unit is used to determine the protocol return data that has passed the integrity check as the determination check return data.

[0104] In an optional embodiment of this application, the parsing submodule includes: The parsing unit is used to parse the verification return data based on the target test protocol to determine the test item completion rate, test item success rate, and test item failure rate. The acquisition unit is used to acquire device serial numbers and test logs; The combination unit is used to combine the test item completion rate, the test item success rate, the test item failure rate, the device serial number, the test log, and the verification return data to generate a test report.

[0105] In an optional embodiment of this application, when the target test protocol includes the ice maker frame protocol, the conversion module 504 includes: The encoding submodule is used to perform big-endian encoding on the information to be tested to determine the big-endian byte. The addition submodule is used to perform an 8-bit addition check on the big-endian byte to determine the check byte; The combined submodule is used to combine the big-endian byte and the check byte to generate test instructions.

[0106] In an optional embodiment of this application, when the target test protocol includes the coffee machine fixed-length frame protocol, the coffee machine fixed-length frame protocol corresponds to a 26-byte fixed-length frame structure; the conversion module 504 includes: The long frame conversion submodule is used to convert the test item information based on the 26-byte fixed-length frame structure and generate test instructions; and / or, The acquisition module 505 includes: The scanning submodule is used to scan the 26-byte frame data of the coffee machine to determine if it is protocol return data; and / or, The parsing module 506 includes: The long frame parsing submodule is used to parse the protocol return data based on the 26-byte fixed-length frame structure and generate a test report.

[0107] In an optional embodiment of this application, when the target test protocol includes the network socket peripheral protocol, the conversion module 504 includes: The first conversion submodule is used to convert the information of the item under test based on the network socket peripheral protocol, and generate test instructions; and / or, The parsing module 506 includes: The first parsing submodule is used to parse the protocol return data based on the network socket peripheral protocol and generate a test report.

[0108] In an optional embodiment of this application, when the target test protocol includes the over-the-air download subpacket, the conversion module 504 includes: The second conversion submodule is used to convert the information of the item to be tested based on the over-the-air download subpacket protocol, and generate test instructions; and / or, The parsing module 506 includes: The second parsing submodule is used to parse the protocol return data based on the over-the-air download subpacket protocol and generate a test report.

[0109] In an optional embodiment of this application, the serial port protocol, the ice maker frame protocol, the coffee machine fixed-length frame protocol, the network socket peripheral protocol, and the over-the-air download packet protocol share a unified adapter interface.

[0110] In an optional embodiment of this application, the output module 507 includes: The sequence recognition submodule is used to obtain the device serial number; The output submodule is used to associate the device serial number with the test report and output it when the preset target test item in the test report has a value; The question description submodule is used to output test prompt information when there are empty values ​​in the preset target test items in the test report.

[0111] This application embodiment involves receiving test item information after the coffee machine is initialized; classifying the test item information to determine the target test type; identifying at least two target test protocols from serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air packet protocol based on the target test type; converting the test item information based on the target test protocol to generate test instructions; obtaining protocol return data corresponding to the target test protocol, the protocol return data being generated based on the execution of the test instructions; parsing the protocol return data to generate a test report; and outputting the test report. By classifying the test item information to determine the target test type, automatically selecting at least two of the serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air packet protocol as target test protocols; and constructing, sending, and obtaining test instructions for the test item information based on the target test protocol to abstract a consistent test item execution result, the protocol return data can be uniformly parsed, a test report generated, and output. There is no need to switch repeatedly between serial port assistants, script tools, peripheral tools and backend systems. The execution of key test items and report upload of the whole machine can be completed in one test, improving production testing efficiency.

[0112] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0113] Reference Figure 6This application also provides a coffee machine, including: a processor 601, a memory 602, and a program or instructions stored in the memory 602 and executable on the processor 601. When the program or instructions are executed by the processor 601, they implement the steps of the coffee machine multi-protocol fusion production testing method as described above.

[0114] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0115] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0116] Reference Figure 7 This application also provides a computer-readable storage medium 701, on which a computer program or instructions are stored. When the program or instructions are executed by a processor, the processor performs the steps of the coffee machine multi-protocol fusion production testing method as described in any one of the embodiments of this application.

[0117] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0118] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0119] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0120] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0121] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0122] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0123] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0124] The foregoing has provided a detailed description of a coffee machine multi-protocol fusion production testing method, a coffee machine multi-protocol fusion production testing device, a coffee machine, and a computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and its core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A multi-protocol fusion production testing method for coffee machines, characterized in that, The multiple protocols include: serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air download packet sub-protocol. The method includes: After the coffee machine is initialized, the test item information is received; The information of the items to be tested is classified to determine the target test type; Based on the target test type, at least two of the following are identified as target test protocols: serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air download packet protocol. Based on the target testing protocol, the information of the item to be tested is transformed to generate test instructions; Obtain protocol return data corresponding to the target test protocol, wherein the protocol return data is generated based on the execution of the test instruction; Parse the data returned by the protocol and generate a test report; Output the test report.

2. The method according to claim 1, characterized in that, Also includes: When the target test type is a manual test type, obtain the test input data; If the test input data corresponds to a qualified type and the protocol return data corresponds to a qualified type, the protocol return data is associated with the test input data to update the protocol return data; If the test input data corresponds to a failure type or the protocol return data corresponds to a failure type, update the protocol return data to the preset failure identifier data.

3. The method according to claim 1, characterized in that, Also includes: The coffee machine is initialized, and the serial port and camera resource services are released.

4. The method according to claim 3, characterized in that, Following the step of outputting the test report, the following is also included: Restore the serial port resource usage service and the camera resource usage service.

5. The method according to claim 1, characterized in that, The steps of parsing the protocol-returned data and generating a test report include: The returned data from the protocol is verified to determine the verified returned data; The verification return data is parsed based on the target testing protocol to generate a test report.

6. The method according to claim 5, characterized in that, The step of verifying the protocol-returned data and determining the verified return data includes: The integrity of the protocol-returned data is verified, including frame header detection, packet length detection, packet tail detection, read length detection, refresh time detection, and total timeout time detection. The data returned by the protocol that passes the integrity check will be identified as the verification return data.

7. The method according to claim 5, characterized in that, The step of parsing the verification return data based on the target testing protocol and generating a test report includes: Based on the target test protocol, the verification return data is parsed to determine the test item completion rate, test item success rate, and test item failure rate. Obtain device serial number and test logs; A test report is generated by combining the test item completion rate, test item success rate, test item failure rate, device serial number, test log, and verification return data.

8. The method according to claim 1, characterized in that, When the target test protocol includes the ice maker frame protocol, the step of converting the test item information based on the target test protocol and generating test instructions includes: The information to be tested is encoded using big-endian encoding to determine the big-endian byte; Perform an 8-bit addition check on the big-endian byte to determine the check byte; The test instruction is generated by combining the big-endian byte and the check byte.

9. The method according to claim 1, characterized in that, When the target test protocol includes the coffee machine fixed-length frame protocol, the coffee machine fixed-length frame protocol corresponds to a 26-byte fixed-length frame structure; the step of converting the test item information based on the target test protocol to generate test instructions includes: Based on the 26-byte fixed-length frame structure, the information of the item to be tested is converted to generate test instructions; and / or, The step of obtaining the protocol return data corresponding to the target test protocol includes: Scan the 26-byte frame data of the coffee machine to determine if it is protocol return data; and / or, The steps of parsing the protocol-returned data and generating a test report include: Based on the 26-byte fixed-length frame structure, the protocol return data is parsed to generate a test report.

10. The method according to claim 1, characterized in that, When the target test protocol includes the network socket peripheral protocol, the step of converting the test item information based on the target test protocol and generating test instructions includes: The test item information is converted based on the network socket peripheral protocol to generate test instructions; and / or, The steps of parsing the protocol-returned data and generating a test report include: Based on the network socket peripheral protocol, the returned data of the protocol is parsed to generate a test report.

11. The method according to claim 1, characterized in that, When the target testing protocol includes the over-the-air download packet protocol, the step of converting the information of the item to be tested based on the target testing protocol and generating test instructions includes: Based on the aforementioned over-the-air download subpacket protocol, the information of the item to be tested is converted to generate test instructions; and / or, The steps of parsing the protocol-returned data and generating a test report include: Based on the over-the-air download subpacket protocol, the returned data of the protocol is parsed to generate a test report.

12. The method according to claim 1, characterized in that, The serial port protocol, the ice maker frame protocol, the coffee machine fixed-length frame protocol, the network socket peripheral protocol, and the over-the-air download packet protocol all share a unified adapter interface.

13. The method according to claim 1, characterized in that, The steps for outputting the test report include: Obtain the device serial number; If the preset target test item in the test report has a value, the device serial number is associated with the test report and output. If there are empty values ​​for the preset target test items in the test report, a test prompt message will be output.

14. A multi-protocol fusion testing device for coffee machines, characterized in that, The multiple protocols include: serial port protocol, ice maker frame protocol, coffee machine fixed-length frame protocol, network socket peripheral protocol, and over-the-air download packet protocol. The device includes: The receiving module is used to receive the test item information after the coffee machine is initialized; The classification module is used to classify the information of the items to be tested and determine the target type of the item to be tested; The filtering module is used to determine at least two of the following as target test protocols based on the target test type: the serial port protocol, the ice maker frame protocol, the coffee machine fixed-length frame protocol, the network socket peripheral protocol, and the over-the-air download packet protocol. The conversion module is used to convert the information of the item to be tested based on the target testing protocol and generate test instructions; The acquisition module is used to acquire protocol return data corresponding to the target test protocol, wherein the protocol return data is generated based on the execution of the test instruction; The parsing module is used to parse the data returned by the protocol and generate a test report; The output module is used to output the test report.

15. A coffee machine, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the coffee machine multi-protocol fusion production testing method as described in any one of claims 1-13.

16. A computer-readable storage medium, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the coffee machine multi-protocol fusion production testing method as described in any one of claims 1-13.

Images