Inventory data consistency test method and system of intelligent retail terminal

Abstract

The application discloses a kind of inventory data consistency test method and system of intelligent retail terminal.This application configures test scene parameter, determines test terminal, time length, inventory change parameter and message tampering strategy;Based on Poisson distribution sales rate, replenishment threshold, replacement probability simulation sales, replenishment, paired replacement event, generate as comparison gold standard's benchmark inventory data;Through the data simulation gateway between terminal and background interception report message, complete five kinds of abnormal injection of delay, discard, tamper, repeat, out of order;Automated comparison engine collects background inventory snapshot regularly, aligns and verifies according to terminal, SKU, time stamp, when difference exceeds threshold, record the inconsistent event of binding tampering strategy label, test output test report, can also automatically associate abnormal positioning background inventory processing defects.This application can systematize reproduce all kinds of network transmission abnormalities, full-process automation is executed, fully expose background inventory logic loophole before going online, widen test coverage, do not need professional hardware, effectively reduce test cost.

Description

Technical Field

[0001] This invention relates to the field of computer software testing technology, and specifically to a method and system for testing the consistency of inventory data in a smart retail terminal. Background Technology

[0002] Smart retail terminals, encompassing vending machines and smart lockers, are widely deployed in shopping malls and communities. These devices continuously report inventory changes to a cloud-based backend via wireless networks. However, the actual operating network environment is complex and variable, often resulting in transmission anomalies such as delayed delivery, random loss, duplicate pushes, out-of-order transmission, and field content tampering. If the cloud-based backend's handling logic for these anomalies is insufficiently robust, it can directly lead to discrepancies between the backend's recorded inventory and the terminal's actual physical inventory, triggering multiple business risks: the backend may misjudge sufficient inventory and fail to generate replenishment orders, resulting in empty shelves and lost sales revenue; the discrepancy between recorded and actual inventory can also distort financial accounting data and interfere with inventory management.

[0003] Current industry testing methods for end-user inventory consistency have significant shortcomings: First, network anomalies rely on manual simulation, often using crude methods such as plugging and unplugging network cables and manually limiting bandwidth, resulting in low testing efficiency, limited reproducible anomaly scenarios, and an inability to simulate complex network fluctuations caused by multiple overlapping transmission anomalies. Second, there is a lack of automated continuous comparison mechanisms, allowing only manual spot checks of inventory data and making it impossible to monitor inventory consistency trends in real time over long testing periods. Third, there is a lack of standardized message tampering injection capabilities, preventing the batch configuration of fine-grained anomaly parameters such as latency intervals, packet loss probability, SKU / quantity tampering rates, and duplicate transmission counts. Fourth, when inventory data discrepancies are detected, it is impossible to trace the corresponding network anomaly type, making it difficult to quickly locate defects in the backend inventory processing logic.

[0004] Existing testing methods are insufficient to fully expose inventory processing vulnerabilities in the backend system under unreliable data transmission scenarios before software goes live. Therefore, the industry urgently needs a smart retail terminal inventory data consistency testing method that can systematically construct various message transmission anomalies, automatically complete inventory data comparison, and accurately correlate anomalies with discrepancies between accounts and actual inventory. Summary of the Invention

[0005] To address these issues, this invention provides a method and system for testing the consistency of inventory data in smart retail terminals. This solves the problems of existing tests that rely on manual simulation of network anomalies, have limited coverage of scenarios, lack automated continuous comparison capabilities, cannot efficiently reproduce transmission anomalies such as message delays, packet loss, and out-of-order delivery, and are difficult to fully expose defects in the backend inventory processing logic before going live.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for testing the consistency of inventory data in a smart retail terminal, comprising:

[0007] S1. Configure test scenario parameters, determine the smart retail terminals participating in the test, test duration, physical inventory change scenario parameters, and inventory reporting message tampering strategy parameters;

[0008] S2. Based on the physical inventory change scenario parameters, generate a physical inventory change event sequence and record each inventory change event as baseline inventory data.

[0009] S3. During the test execution, the data simulation gateway intercepts the original inventory reporting message sent by the smart retail terminal to the backend system, performs the corresponding tampering operation on the original inventory reporting message according to the tampering strategy parameters, and forwards the tampered / untampered message to the backend system.

[0010] S4. Obtain the inventory snapshot data of each terminal corresponding to the product recorded in the background system, and align and compare the inventory snapshot data with the benchmark inventory data according to the time series.

[0011] S5. When the difference between the inventory snapshot data and the baseline inventory data exceeds the preset tolerance threshold, a data inconsistency event is determined to have occurred, and the associated information of the inconsistency event is recorded. After the test is completed, all inconsistency events are summarized and a data consistency test report is generated.

[0012] As a preferred method for testing the consistency of inventory data in smart retail terminals, in S1, the test scenario parameters include a list of terminal IDs participating in the test, test duration, initial inventory of each product SKU, sales rate probability distribution function, replenishment trigger threshold, replenishment strategy, replenishment delay duration, probability of exchange event trigger, and tampering strategy; the tampering strategy is configured to allow single or multiple tampering operations to be applied simultaneously.

[0013] As a preferred method for testing the consistency of inventory data in smart retail terminals, the sales rate probability distribution function is a Poisson distribution, and the probability mass function formula is:

[0014]

[0015] In the formula, The number of goods sold and shipped within a unit of test duration; The actual number of items sold per unit of time. ; The mean of the Poisson distribution represents the average number of goods sold per unit of time. It is a natural constant.

[0016] As a preferred method for testing the consistency of inventory data in smart retail terminals, in S2, the process of generating the sequence of physical inventory change events includes: randomly generating a sequence of product sales and outbound events on the time axis based on a preset sales rate probability distribution function.

[0017] Based on a preset replenishment trigger threshold, when the simulated inventory is lower than the replenishment trigger threshold, a replenishment inbound event sequence for the corresponding product is generated and the replenishment delay time is included.

[0018] Based on the preset probability of the exchange event, a pair of event sequences for exchange outbound and exchange inbound are generated.

[0019] As a preferred method for testing the consistency of inventory data in smart retail terminals, in S2, the benchmark inventory data includes the timestamp, terminal ID, product SKU, change type, change quantity, and post-change inventory quantity for each inventory change event.

[0020] As a preferred method for testing the consistency of inventory data in smart retail terminals, in S3, the tampering operation includes:

[0021] Delayed transmission: The original inventory reporting message is temporarily stored in a buffer and forwarded to the backend system after a preset delay period;

[0022] Discard messages: Randomly discard a portion of the original inventory reporting messages according to a preset discard probability, and do not forward them to the backend system;

[0023] The content of the tampering is as follows: the inventory quantity field / product SKU field in the original inventory reporting message is modified to a preset tampering value before being forwarded to the backend system;

[0024] Repeated transmission: Copy the same original inventory reporting message multiple times and forward it to the backend system at preset intervals;

[0025] Out-of-order sending: The sending order of multiple original inventory reporting messages is shuffled before being forwarded to the backend system.

[0026] As a preferred method for testing the consistency of inventory data in smart retail terminals, in S4, the alignment comparison includes:

[0027] According to the preset time interval, retrieve the real-time inventory snapshot data of each product SKU under each test terminal from the background system;

[0028] Using terminal ID, product SKU, and timestamp as alignment dimensions, the inventory snapshot data is matched with the corresponding time-based inventory value in the baseline inventory data;

[0029] Calculate the absolute value of the difference between the inventory snapshot data and the benchmark inventory data under the same dimension, and compare the absolute value of the difference with a preset tolerance threshold.

[0030] As a preferred method for testing the consistency of inventory data in smart retail terminals, in S5, the associated information of the inconsistency event includes: event occurrence timestamp, terminal ID, product SKU, inventory value recorded by the back-end system, baseline inventory value, absolute value of the difference, direction of the difference, and currently effective tampering policy label.

[0031] As a preferred method for testing the consistency of inventory data in smart retail terminals, it also includes, based on the data consistency test report, performing correlation analysis between the inconsistency events and the corresponding tampering strategies to identify the defect types of the inventory processing logic in the back-end system.

[0032] The defect types include: inventory update lag caused by message delay, inventory shortage caused by message loss, inventory accumulation caused by message duplication, inventory status disorder caused by message out-of-order, and inventory deviation caused by message content error.

[0033] This invention also provides an inventory data consistency testing system for smart retail terminals, employing the aforementioned inventory data consistency testing method for smart retail terminals, comprising:

[0034] Parameter configuration unit: used to configure test scenario parameters, determine the smart retail terminals participating in the test, test duration, physical inventory change scenario parameters, and inventory reporting message tampering strategy parameters;

[0035] Benchmark data generation unit: used to generate a sequence of physical inventory change events based on the physical inventory change scenario parameters, and record each inventory change event as benchmark inventory data;

[0036] Message hijacking and tampering unit: During test execution, the data simulation gateway intercepts the original inventory reporting message sent by the smart retail terminal to the back-end system, performs the corresponding tampering operation on the original inventory reporting message according to the tampering strategy parameters, and forwards the tampered / untampered message to the back-end system;

[0037] Inventory data comparison unit: used to obtain the inventory snapshot data of each terminal corresponding to the product recorded by the back-end system, and to align and compare the inventory snapshot data with the benchmark inventory data according to the time series;

[0038] Abnormal Data and Report Output Unit: When the difference between the inventory snapshot data and the baseline inventory data exceeds a preset tolerance threshold, it determines that a data inconsistency event has occurred, records the associated information of the inconsistency event, and after the test is completed, it summarizes all inconsistency events and generates a data consistency test report.

[0039] The present invention has the following advantages:

[0040] First, it supports five types of transmission anomalies: message delay, message dropping, message content tampering, message duplication, and message out-of-order delivery. It also allows for the free combination of multiple anomaly strategies, fully recreating real and complex network fluctuation scenarios and significantly expanding the coverage of inventory consistency testing.

[0041] Secondly, everything from test scenario configuration, baseline inventory data simulation, abnormal message injection, backend inventory snapshot comparison to test report output can be automated. It can be integrated into continuous integration pipelines, reducing manual operations and improving the efficiency of long-term regression testing.

[0042] Third, each inventory inconsistency event is bound to a corresponding effective tampering policy identifier, which can directly establish a causal relationship between network transmission anomalies and backend inventory processing defects, making it easier for R&D personnel to quickly locate the root cause of the problem.

[0043] Fourth, the entire process is implemented using a pure software architecture, eliminating the need to purchase expensive professional network impairment instruments or a large number of physical smart retail terminals. The entire testing process can be completed using ordinary test servers, reducing the investment in test hardware.

[0044] Fifth, it can automatically match the anomaly type based on the test report and identify five types of backend logic defects: delayed updates, missing inventory, duplicate accumulation, disordered inventory, and inventory deviation, saving the workload of manually checking the differences one by one. Attached Figure Description

[0045] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0046] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0047] Figure 1 This is a schematic diagram of the inventory data consistency testing method for an intelligent retail terminal provided in Embodiment 1 of the present invention;

[0048] Figure 2 This is a technical roadmap for a smart retail terminal inventory data consistency testing method provided in Embodiment 1 of the present invention;

[0049] Figure 3 This is an overall implementation architecture diagram of an inventory data consistency testing method for a smart retail terminal provided in Embodiment 1 of the present invention;

[0050] Figure 4 This is a schematic diagram of the benchmark data generation logic for an inventory data consistency testing method for a smart retail terminal provided in Embodiment 1 of the present invention;

[0051] Figure 5 This is a flowchart of the data simulation gateway workflow for an inventory data consistency testing method for a smart retail terminal provided in Embodiment 1 of the present invention.

[0052] Figure 6 This is an internal flowchart of the automated comparison engine for an inventory data consistency testing method for a smart retail terminal provided in Embodiment 1 of the present invention.

[0053] Figure 7 This is a timing diagram illustrating the execution of an inventory data consistency testing method for a smart retail terminal provided in Embodiment 1 of the present invention.

[0054] Figure 8 This is a schematic diagram of the inventory data consistency testing system architecture for an intelligent retail terminal provided in Embodiment 1 of the present invention. Detailed Implementation

[0055] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] Example 1

[0057] See Figure 1 and Figure 2 This invention provides a method for testing the consistency of inventory data in a smart retail terminal, comprising:

[0058] S1. Configure test scenario parameters, determine the smart retail terminals participating in the test, test duration, physical inventory change scenario parameters, and inventory reporting message tampering strategy parameters;

[0059] S2. Based on the physical inventory change scenario parameters, generate a physical inventory change event sequence and record each inventory change event as baseline inventory data.

[0060] S3. During the test execution, the data simulation gateway intercepts the original inventory reporting message sent by the smart retail terminal to the backend system, performs the corresponding tampering operation on the original inventory reporting message according to the tampering strategy parameters, and forwards the tampered / untampered message to the backend system.

[0061] S4. Obtain the inventory snapshot data of each terminal corresponding to the product recorded in the background system, and align and compare the inventory snapshot data with the benchmark inventory data according to the time series.

[0062] S5. When the difference between the inventory snapshot data and the baseline inventory data exceeds the preset tolerance threshold, a data inconsistency event is determined to have occurred, and the associated information of the inconsistency event is recorded. After the test is completed, all inconsistency events are summarized and a data consistency test report is generated.

[0063] Specifically, firstly, by simulating inventory changes under real business logic, absolutely accurate baseline inventory data is generated, serving as the sole standard for judging the correctness of backend inventory. Secondly, through a data simulation gateway deployed in the terminal and backend transmission link, various transmission anomalies are injected into inventory reporting messages in a controllable and reproducible manner, accurately reproducing the complex real network environment. Thirdly, through a multi-dimensional time series alignment and comparison mechanism, the consistency between backend inventory and baseline inventory is continuously verified, capturing inventory deviations between intermediate and final states. Finally, by structurally recording difference information and outputting test reports, traceability and localization of inventory processing defects are achieved. This replaces the traditional testing mode of manually plugging and unplugging network cables and manually checking inventory, solving the pain points of limited coverage of manual testing scenarios, low execution efficiency, and inability to continuously monitor for extended periods.

[0064] In one possible embodiment, in S1, the test scenario parameters include a list of terminal IDs participating in the test, test duration, initial inventory of each product SKU, sales rate probability distribution function, replenishment trigger threshold, replenishment strategy, replenishment delay duration, exchange event trigger probability, and tampering strategy; the tampering strategy is configured to allow single or multiple tampering operations to be applied simultaneously.

[0065] Specifically, the terminal ID list supports parallel testing across multiple terminals, simulating distributed deployment scenarios of terminals at different locations; the test duration controls the test cycle, adapting to both short-term regression testing and long-term stability testing needs; the initial inventory provides the starting value for inventory simulation, serving as the initial condition for baseline inventory calculation; the sales rate probability distribution function fits the sales patterns of real retail scenarios, ensuring that the simulated sales rhythm conforms to actual business characteristics; the replenishment trigger threshold, replenishment strategy, and replenishment delay correspond to processes such as low inventory triggering replenishment and replenishment logistics time consumption in real operations, making the inventory change logic conform to offline operational rules; the exchange event trigger probability simulates non-sales inventory change scenarios such as offline exchanges and near-expiry product exchanges, covering more business boundaries; the tampering strategy supports single / multiple overlays because multiple anomalies such as latency and packet loss often exist simultaneously in real network environments, and overlay configurations can improve the realism of test scenarios, avoiding the disconnect between single anomaly testing and the actual environment.

[0066] In one possible embodiment, the sales rate probability distribution function is a Poisson distribution, and the probability mass function formula is:

[0067]

[0068] In the formula, The number of goods sold and shipped within a unit of test duration; The actual number of items sold per unit of time. ; The mean of the Poisson distribution represents the average number of goods sold per unit of time. It is a natural constant.

[0069] Specifically, the sales behavior of a single product at a smart retail terminal meets the three applicable conditions of a Poisson process: first, stationarity, meaning the average sales rate is stable per unit time and unaffected by the starting point of the time frame; second, independent increment, meaning sales behavior within any two time periods is independent, with a previous order not affecting the occurrence of a subsequent order; and third, generality, meaning that multiple transactions are almost never completed simultaneously within a very short period. The probability mass function of the Poisson distribution can be used to calculate the number of transactions sold per unit time. By calculating the probability of a single item and combining it with the inverse transformation method, outbound event time points that conform to the actual sales rhythm can be generated on the timeline. This avoids simulation distortion caused by manually setting fixed sales intervals, ensures the business rationality of the baseline inventory data, and enhances the persuasiveness of the test results. Among the parameters... This is a configurable option that can be adjusted based on the actual daily sales volume of different products, adapting to product scenarios with different sales rates, such as beverages and snacks.

[0070] In one possible embodiment, in S2, the process of generating the sequence of physical inventory change events includes: randomly generating a sequence of goods sales and outbound events on the time axis based on a preset sales rate probability distribution function;

[0071] Based on a preset replenishment trigger threshold, when the simulated inventory is lower than the replenishment trigger threshold, a replenishment inbound event sequence for the corresponding product is generated and the replenishment delay time is included.

[0072] Based on the preset probability of the exchange event, a pair of event sequences for exchange outbound and exchange inbound are generated.

[0073] Specifically, sales outbound events are generated as discrete sales events on a continuous time axis using probability distributions, simulating random user purchases in real-world scenarios and serving as the primary trigger for inventory reduction. Replenishment inbound events employ a threshold trigger mechanism, corresponding to the business rule in real-world operations where replenishment is initiated when inventory falls below a safety threshold. The replenishment delay simulates the entire process of order placement, delivery, and terminal shelving, ensuring that the timing of inventory recovery aligns with actual operational rhythms and avoiding logical distortions caused by unwarranted inventory increases. Exchange matching events address the essence of exchange business, where goods are both outbound and inbound. While the total inventory or SKU structure may change, the business logic must be maintained. Therefore, a matching generation mechanism is used to ensure a one-to-one correspondence between outbound and inbound transactions, avoiding logical contradictions in the baseline inventory itself, ensuring the accuracy of the margin standard, and covering edge testing scenarios for non-sales inventory changes.

[0074] In one possible embodiment, in S2, the baseline inventory data includes the timestamp, terminal ID, product SKU, change type, change quantity, and post-change inventory quantity for each inventory change event.

[0075] Specifically, the timestamp is the main dimension for time series comparison, used to accurately match the baseline inventory with the backend inventory snapshot at a specific point in time; the terminal ID and product SKU are entity-level identifiers used to distinguish inventory data from different terminals and products, ensuring that the inventory value being compared is that of the same entity, avoiding misjudgments caused by cross-terminal or cross-SKU comparisons; the change type is used to distinguish the business reasons for inventory changes (sales / replenishment / exchange), facilitating subsequent identification of the business process where defects occurred; the change quantity and the inventory quantity after the change are the main numerical fields, where the inventory quantity after the change is the real-time inventory value after the current event is completed, serving as the benchmark at that point in time, and can be directly used to calculate the difference with the backend snapshot value without additional cumulative calculation, improving comparison efficiency and accuracy.

[0076] In one possible embodiment, in S3, the tampering operation includes:

[0077] Delayed transmission: The original inventory reporting message is temporarily stored in a buffer and forwarded to the backend system after a preset delay period;

[0078] Discard messages: Randomly discard a portion of the original inventory reporting messages according to a preset discard probability, and do not forward them to the backend system;

[0079] The content of the tampering is as follows: the inventory quantity field / product SKU field in the original inventory reporting message is modified to a preset tampering value before being forwarded to the backend system;

[0080] Repeated transmission: Copy the same original inventory reporting message multiple times and forward it to the backend system at preset intervals;

[0081] Out-of-order sending: The sending order of multiple original inventory reporting messages is shuffled before being forwarded to the backend system.

[0082] Specifically, delayed sending corresponds to message transmission delays caused by network congestion, weak terminal signals, and long transmission links, simulating scenarios where messages arrive late in a weak network environment. This is used to test the backend system's processing logic for non-real-time messages and whether a timing calibration mechanism exists. Discarded messages correspond to message loss caused by network packet loss, signal interruption, and link failure, simulating unstable network scenarios. This is used to test whether the backend system has reconciliation and compensation calibration mechanisms after message loss. Content tampering corresponds to scenarios such as data bit errors, interface parsing anomalies, and data tampering during transmission, used to test the backend system's data validity verification and anomaly interception capabilities. Repeated sending corresponds to the same message arriving at the backend multiple times due to network retransmission mechanisms and terminal abnormal retries, used to test the backend system's idempotent processing capabilities and verify whether inventory is repeatedly deducted / increased. Out-of-order sending corresponds to scenarios where the message arrival order is inconsistent with the generation order due to different network routes, used to test the backend system's timing processing logic and verify whether inventory is updated according to message generation time rather than arrival time.

[0083] In one possible embodiment, in S4, the alignment comparison includes:

[0084] According to the preset time interval, retrieve the real-time inventory snapshot data of each product SKU under each test terminal from the background system;

[0085] Using terminal ID, product SKU, and timestamp as alignment dimensions, the inventory snapshot data is matched with the corresponding time-based inventory value in the baseline inventory data;

[0086] Calculate the absolute value of the difference between the inventory snapshot data and the benchmark inventory data under the same dimension, and compare the absolute value of the difference with a preset tolerance threshold.

[0087] Specifically, the backend inventory is a dynamic value that is continuously updated as message processing progresses. Fixed-interval sampling enables continuous monitoring throughout the entire lifecycle, capturing inconsistencies in intermediate states caused by message delays and verifying eventual consistency, avoiding omissions of intermediate defects caused by testing only the final result. A multi-dimensional matching mechanism using terminal ID, product SKU, and timestamp ensures that the comparison is between two inventory values ​​from the same terminal, the same product, and the same point in time, fundamentally avoiding false positives caused by dimensional mismatches, such as comparing the inventory of terminal A with that of terminal B, or comparing values ​​from different time points. Setting a tolerance threshold is to filter out normal system precision errors, such as minor numerical deviations caused by data rounding and differences in statistical precision, avoiding the judgment of reasonable errors as data inconsistencies and improving the accuracy of test results. The tolerance threshold can be flexibly configured according to the business's requirements for inventory precision, adapting to business scenarios with different precision needs.

[0088] In one possible embodiment, in S5, the associated information of the inconsistency event includes: event occurrence timestamp, terminal ID, product SKU, backend system recorded inventory value, baseline inventory value, absolute value of difference, direction of difference, and currently effective tampering policy label.

[0089] Specifically, timestamps can accurately pinpoint the time point when a defect occurs, facilitating the investigation of the system status and message chain at that time; terminal IDs and product SKUs can locate specific test objects, investigating whether there are defects in the processing logic of specific terminals or products, quickly narrowing down the investigation scope; the backend system records the difference between the inventory value and the benchmark inventory value, displaying the numerical results on both sides; the absolute value of the difference is used to measure the severity of the inconsistency, distinguishing between minor deviations and serious errors; the direction of the difference (backend value higher / lower) can help determine the defect type, for example, message loss usually leads to a higher backend inventory; the currently effective tampering policy label is the main traceability field, which can be directly associated with the currently injected anomaly type, quickly establishing the causal relationship between anomaly input and defect output, eliminating the need for manual investigation of the anomaly cause, and significantly improving the efficiency of defect localization.

[0090] In one possible embodiment, the method further includes performing correlation analysis between the inconsistency events and corresponding tampering strategies based on the data consistency test report to identify the defect type of the back-end system's inventory processing logic.

[0091] The defect types include: inventory update lag caused by message delay, inventory shortage caused by message loss, inventory accumulation caused by message duplication, inventory status disorder caused by message out-of-order, and inventory deviation caused by message content error.

[0092] Specifically, because the tampering strategy is controllable and traceable during testing, each type of inconsistency event corresponds to a clear abnormal input. When a specific pattern of inventory inconsistency continuously occurs under a certain tampering strategy, it can be determined that there is a defect in the corresponding backend processing logic, without the need for manual analysis of each item: If only the delay strategy is enabled, and the inventory difference exists at an intermediate time but disappears at the final time, it can be determined as an inventory update lag defect, indicating that the backend only updates according to the message arrival time and has no time sequence calibration mechanism; If the inventory difference persists and does not self-heal after enabling the packet loss strategy, it can be determined as an inventory missing defect, indicating that the backend has no message loss perception and reconciliation compensation mechanism; If the inventory difference is proportional to the number of repetitions after enabling the duplicate sending strategy, it can be determined as an inventory duplicate accumulation defect, indicating that the backend has no idempotent verification mechanism; If the inventory status does not match the baseline logic after enabling the out-of-order strategy, it can be determined as an inventory status disorder defect, indicating that the backend does not process according to the message generation time sequence; If the abnormal value is directly updated to the backend inventory after enabling the content tampering strategy, it can be determined as an inventory deviation defect, indicating that the backend has no data validity verification logic.

[0093] See Figure 3This diagram presents the overall implementation architecture for inventory data consistency testing of smart retail terminals. The right side of the diagram represents the message transmission and anomaly injection link. The smart retail terminal, acting as the generator of inventory messages, sends inventory reporting messages to the backend system. During transmission, these messages are intercepted by a data simulation gateway deployed between the terminal and the backend. The gateway performs various anomaly handling operations on the original messages according to a preset tampering policy, including delaying, discarding, content tampering, duplicate sending, and out-of-order sending. It then forwards the tampered or untampered messages to the backend system. Upon receiving the messages, the backend system updates its own inventory records and can provide snapshot inventory data for query and verification. The left side represents the baseline data generation link. The test scenario configuration module is the parameter entry point for the entire system, responsible for receiving and distributing all configuration parameters required for testing. After the parameters are input to the baseline data generation module, the module simulates and generates a sequence of inventory change events that conform to real business patterns based on configured physical inventory change parameters such as sales rate, replenishment rules, and exchange probability. Finally, it outputs baseline inventory data as a standard for judging inventory correctness. The output data from both links are jointly fed into the automated comparison engine. The engine simultaneously acquires baseline inventory data from the baseline data generation module and a real-time inventory snapshot retrieved from the backend system. After data matching is completed using terminal identifier, product SKU, and timestamp as alignment dimensions, the engine executes discrepancy detection logic. It calculates the difference between the two inventory levels and compares it with the tolerance threshold to determine if any data inconsistency events exist. The detected discrepancy results are transmitted to the discrepancy recording module. This module fully retains the associated information for each inconsistency event, including event time, terminal and product information, inventory values ​​on both sides, the magnitude and direction of the difference, and the corresponding effective tampering policy tags. Finally, the discrepancy recording module summarizes all inconsistency events throughout the entire testing cycle, generates a complete data consistency test report, completes the corresponding automated defect analysis, and outputs the defect location conclusions for the backend system's inventory processing logic.

[0094] See Figure 4This diagram illustrates the benchmark data generation logic for inventory data consistency testing in smart retail terminals. The overall process uses test scenario parameters as input, simulates various inventory change events based on real business rules, and ultimately outputs benchmark inventory data as the gold standard for comparison. After the process starts, it first generates product sales and outbound events on the timeline based on the configured Poisson distribution sales rate. This simulates random user purchasing behavior in a real scenario, serving as the primary trigger for inventory reduction. After generating the sales event, the process is divided into two parallel business judgment branches: the left branch performs replenishment logic judgment, checking whether the current simulated inventory level is lower than or equal to the preset replenishment threshold. If the judgment result is negative, the replenishment step is skipped, and no replenishment-related events are generated; if the judgment result is positive, a replenishment inbound event for the corresponding product is generated, and the replenishment delay time is included, replicating the entire process time of replenishment ordering, delivery, and shelving in real operations. The right side handles the exchange logic, randomly determining the event based on a preset probability. If the exchange condition is not triggered, the exchange process is skipped. If the condition is triggered, a matching event is generated for each exchange item leaving and entering the warehouse, ensuring the inventory logic of the exchange business and preventing logical inconsistencies in the baseline data. After processing both branches, all generated inventory change events are uniformly imported into the recording stage, retaining information such as the timestamp, terminal identifier, product SKU, and inventory change quantity for each event. After completing a single round of event recording, the process loops back to the sales event generation step, continuously generating inventory change events for the next stage until the full test duration is covered. Finally, the data is aggregated to form complete baseline inventory data, providing an accurate basis for subsequent inventory consistency comparisons.

[0095] See Figure 5This diagram illustrates the workflow of a data simulation gateway for testing inventory data consistency in smart retail terminals. The process begins with the smart retail terminal sending an inventory reporting message to the backend. The data simulation gateway, deployed between the terminal and the backend transmission link, intercepts all original reporting messages to ensure all messages undergo unified processing. After interception, the gateway reads pre-configured tampering policy parameters to determine the exception types and corresponding parameters used in this test, serving as the basis for subsequent message processing. The tampering operation then proceeds to the branch execution phase. The gateway selects the corresponding message processing method based on the configured policy, covering five typical transmission exception scenarios: The first is delayed transmission, where the original inventory reporting message is temporarily stored in a buffer and forwarded only after a preset delay duration, simulating message transmission delays under network congestion and weak network signals; the second is message discarding, where a portion of the original message is randomly discarded according to a preset discard probability without forwarding to the backend system, simulating message loss scenarios caused by network packet loss and temporary link interruptions; the third is content tampering, directly modifying the inventory information in the original message. The first type of alteration involves replacing the quantity field or the product SKU field with a preset altered value before forwarding. This simulates abnormal situations such as data transmission bit errors or message content tampering. The second type involves duplicate transmission, where the same original reported message is copied multiple times and forwarded to the backend system at preset time intervals. This simulates scenarios where a single message arrives multiple times due to network retransmission mechanisms or terminal retries. The third type involves out-of-order transmission, where multiple original reported messages are collected, their original sending order is shuffled, and then forwarded sequentially. This simulates scenarios where the message arrival order differs from the generation order due to differences in network routing. Regardless of which type of alteration is performed, or whether messages that do not require alteration are directly passed through, all processed messages are ultimately forwarded to the backend system. The backend updates its own inventory records based on the received messages to verify whether there are any defects in the backend's inventory processing logic under various abnormal message inputs.

[0096] See Figure 6This diagram illustrates the internal process of an automated comparison engine for testing inventory data consistency in smart retail terminals. The entire process is periodically triggered by scheduled data collection tasks, ensuring uninterrupted monitoring throughout the testing cycle. Upon triggering a task, two data streams are simultaneously acquired: one is real-time inventory snapshot data retrieved from the backend system, and the other is pre-generated benchmark inventory data. Both streams then enter the data alignment stage, using terminal ID, product SKU, and timestamp as matching criteria. This ensures that the comparison involves two sets of inventory values ​​from the same terminal, for the same product, and at the same time, fundamentally avoiding misjudgments caused by misaligned dimensions and guaranteeing the accuracy of the verification results. After data alignment, the process proceeds to the inventory difference calculation step, quantifying the absolute value of the difference between the backend inventory value and the benchmark inventory value in the corresponding matching item, thus clarifying the degree of deviation between the two sides. The process then proceeds to the discrepancy determination stage, comparing the calculated discrepancy value with a preset tolerance threshold. If the discrepancy value exceeds the tolerance threshold, a data inconsistency event is identified, and the event is recorded. The event's timestamp, terminal information, product information, inventory values ​​on both sides, the magnitude of the discrepancy, and the corresponding tampering policies are all recorded, providing a basis for subsequent defect tracing. If the discrepancy value does not exceed the tolerance threshold, the inventory status is considered normal, no anomaly is recorded, and the process proceeds directly to the next monitoring cycle, awaiting the next scheduled data collection task. At the end of the entire testing cycle, all recorded inconsistency event information is summarized, compiled, and a complete data consistency test report is generated, outputting the final test results. This provides data support for defect analysis and optimization of the backend inventory processing logic.

[0097] See Figure 7This diagram illustrates the execution sequence of the inventory data consistency test method for smart retail terminals. In the initial test phase, the terminal initializes its product inventory, setting an initial inventory of 20 units for SKUA and 15 units for SKUB, serving as the starting inventory state for the test. After the test runs, the terminal generates a sales transaction and sends a sales report message to the gateway. Upon receiving the message, the data simulation gateway processes it according to a preset tampering strategy, either by incurring a random delay of 3 to 8 seconds or by randomly discarding parts of the message based on probability. After completing the tampering processing, the gateway forwards the processed message to the backend system. Upon receiving the report message, the backend system updates its own inventory records accordingly. Throughout the test, the comparison engine runs continuously at a fixed 5-second cycle, periodically pulling current inventory snapshot data from the backend system and comparing the snapshot data with pre-generated baseline inventory data, repeatedly performing monitoring actions. As sales events continue, when the simulated inventory at the terminal drops to a threshold of 5 units or less, a replenishment mechanism is triggered. The terminal generates a replenishment event and sends a replenishment report message to the gateway. Upon receiving the message, the gateway forwards it to the backend system. The backend then completes the replenishment and warehousing operation for the corresponding product and updates the inventory value. During the continuous comparison and monitoring throughout the entire lifecycle, the comparison engine detected a total of 3 data inconsistency events. After the entire test process is completed, the comparison engine summarizes all abnormal records and generates a final inventory data consistency test report, completing the entire test process.

[0098] The application scenarios of this invention are as follows:

[0099] Commercial vending machine full-domain operation scenario: Applicable to chain vending machine brands and offline equipment operation and maintenance service providers, covering all business processes such as multi-city distribution, real-time sales reporting, intelligent replenishment scheduling, and monthly inventory financial accounting. Vending machines in cross-regional areas experience frequent mobile network fluctuations. Manually plugging and unplugging network cables to simulate network anomalies is inefficient and has limited scenario coverage. Long-term operation makes it difficult to continuously monitor discrepancies between book and actual inventory. Message packet loss and out-of-order delivery can easily lead to misjudgments in back-end replenishment and empty shelves. This solution automatically injects five types of transmission anomalies through a data simulation gateway, generates a benchmark inventory that fits the actual sales pattern, and continuously compares snapshots. It automatically associates anomaly strategies to locate various inventory processing defects and improves the back-end reconciliation and compensation logic before going live to reduce losses from out-of-stock sales.

[0100] Community Smart Fresh Produce Locker Management Scenario: Applicable to community fresh produce operators and unmanned self-pickup locker management platforms in residential areas, covering fresh produce sales, user returns and exchanges, scheduled replenishment, and daily loss inventory management. The high frequency of fresh produce exchanges and returns, coupled with the large concurrency of terminal inventory reporting messages, makes network latency and duplicate reporting prone to causing repeated inventory deductions or accumulations. Traditional manual testing cannot reproduce complex scenarios with multiple anomalies. This solution simulates multi-terminal sales, replenishment, and pairing exchange events in parallel, and batch-overlays multiple message tampering strategies to accurately identify idempotent failures and timing errors in the backend system, reducing product losses and accounting losses caused by discrepancies between inventory records and actual stock.

[0101] Operation and maintenance scenario for self-service retail terminals in large supermarkets: Applicable to chain supermarkets and offline integrated stores operation teams, covering in-store beverage and snack self-service cabinets, weighing and self-service equipment, and near-expiry product exchange business; the WiFi signal interference in supermarkets is severe, inventory reporting messages are out of order, and transmission bit tampering occurs occasionally. Manual testing can only simulate network outages and cannot carry out long-term stability testing. This solution implements fault injection through pure software architecture, periodically captures backend inventory snapshots and performs multi-dimensional alignment and verification with benchmark data, fully retains inconsistent events and corresponding abnormal tags, and supplements the backend SKU and inventory value legality verification logic before going live to avoid monthly inventory and financial accounting deviations.

[0102] Management and control scenarios for unmanned retail devices on university campuses: Applicable to university logistics service providers and unmanned retail operators on campuses, covering time-sharing sales, nighttime bulk replenishment, and student return and exchange services for vending machines in teaching buildings and dormitories. During morning and evening commutes and breaks between classes, the number of concurrent messages reported by terminals surges, leading to network congestion, message delays, and packet loss issues. Traditional testing methods struggle to reproduce high-traffic, network-anomaly-related scenarios. This solution simulates time-sharing differentiated sales traffic based on Poisson distribution, supports testing with multiple tampering strategies, automatically categorizes and identifies defects in backend time-series processing and message loss compensation, optimizes the inventory message queuing and update logic during peak hours, and avoids distortion of inventory statistics during campus periods.

[0103] Subway / Office Building Smart Vending Terminal Operation Scenarios: Suitable for rail transit operators and unmanned retail service providers in commercial buildings, covering high-frequency vending during commuting peak hours, fixed-point replenishment, and product exchange due to equipment failure. In commuting areas, mobile signal strength fluctuates dynamically, and random message delays and packet loss are common occurrences. Long-term manual stability testing is costly. This solution automates the entire process of generating baseline inventory, injecting abnormal messages, detecting discrepancies, and outputting test reports. It eliminates the need to purchase specialized network impairment hardware, enabling low-cost long-term stability testing and proactively fixing vulnerabilities in the automatic inventory calibration mechanism, reducing stockouts of popular items during peak commuting hours.

[0104] It should be noted that the method of this embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this embodiment, and these multiple devices will interact with each other to complete the inventory data consistency testing method for the smart retail terminal.

[0105] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0106] Example 2

[0107] See Figure 8 Embodiment 2 of the present invention also provides an inventory data consistency testing system for smart retail terminals, which adopts the above-described inventory data consistency testing method for smart retail terminals, including:

[0108] Parameter configuration unit 100: Used to configure test scenario parameters, determine the smart retail terminals participating in the test, test duration, physical inventory change scenario parameters, and inventory reporting message tampering strategy parameters;

[0109] Benchmark data generation unit 200: used to generate a sequence of physical inventory change events based on the physical inventory change scenario parameters, and record each inventory change event as benchmark inventory data;

[0110] Message hijacking and tampering unit 300: During test execution, the data simulation gateway intercepts the original inventory reporting message sent by the smart retail terminal to the back-end system, performs the corresponding tampering operation on the original inventory reporting message according to the tampering strategy parameters, and forwards the tampered / untampered message to the back-end system;

[0111] Inventory data comparison unit 400: used to obtain the inventory snapshot data of each terminal corresponding to the product recorded by the background system, and to align and compare the inventory snapshot data with the benchmark inventory data according to the time series;

[0112] Abnormal Data and Report Output Unit 500: When the difference between the inventory snapshot data and the baseline inventory data exceeds a preset tolerance threshold, it determines that a data inconsistency event has occurred, records the associated information of the inconsistency event, and after the test is completed, it summarizes all inconsistency events and generates a data consistency test report.

[0113] It should be noted that the information interaction and execution process between the modules of the above-mentioned device are based on the same concept as the method embodiment in Embodiment 1 of this application, and the resulting technical effects are the same as those in the method embodiment of this application. For details, please refer to the description in the method embodiment shown above in this application, and it will not be repeated here.

[0114] Example 3

[0115] Embodiment 3 of the present invention provides a non-transitory computer-readable storage medium, wherein the computer-readable storage medium stores program code for a method of testing the consistency of inventory data of a smart retail terminal, the program code including instructions for executing the method of testing the consistency of inventory data of a smart retail terminal according to Embodiment 1 or any possible implementation thereof.

[0116] Computer-readable storage media can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0117] Example 4

[0118] Embodiment 4 of the present invention provides an electronic device, including: a memory and a processor;

[0119] The processor and the memory communicate with each other via a bus; the memory stores program instructions that can be executed by the processor, and the processor can execute the inventory data consistency test method of the smart retail terminal in Embodiment 1 or any possible implementation thereof by calling the program instructions.

[0120] Specifically, a processor can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. This memory can be integrated into the processor or located outside the processor and exist independently.

[0121] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0122] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0123] Although the present invention has been described in detail above with general descriptions and specific embodiments, modifications or improvements can be made to it, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present invention fall within the scope of protection claimed by the present invention.

Claims

1. A method for testing the consistency of inventory data in a smart retail terminal, characterized in that, include: S1. Configure test scenario parameters, determine the smart retail terminals participating in the test, test duration, physical inventory change scenario parameters, and inventory reporting message tampering strategy parameters; S2. Based on the physical inventory change scenario parameters, generate a physical inventory change event sequence and record each inventory change event as baseline inventory data. S3. During the test execution, the data simulation gateway intercepts the original inventory reporting message sent by the smart retail terminal to the back-end system, performs the corresponding tampering operation on the original inventory reporting message according to the tampering strategy parameters, and forwards the tampered / untampered message to the back-end system. S4. Obtain the inventory snapshot data of each terminal corresponding to the product recorded in the background system, and align and compare the inventory snapshot data with the benchmark inventory data according to the time series. S5. When the difference between the inventory snapshot data and the baseline inventory data exceeds a preset tolerance threshold, a data inconsistency event is determined to have occurred, and the associated information of the inconsistency event is recorded. After the test is completed, all inconsistencies are summarized and a data consistency test report is generated.

2. The method for testing the consistency of inventory data in a smart retail terminal according to claim 1, characterized in that, In S1, the test scenario parameters include a list of terminal IDs participating in the test, test duration, initial inventory of each product SKU, sales rate probability distribution function, replenishment trigger threshold, replenishment strategy, replenishment delay duration, probability of exchange event trigger, and tampering strategy; the tampering strategy is configured to allow single or multiple tampering operations to be applied simultaneously.

3. The method for testing the consistency of inventory data in a smart retail terminal according to claim 2, characterized in that, The probability distribution function of the sales rate is a Poisson distribution, and the probability mass function formula is: In the formula, The number of goods sold and shipped within a unit of test duration; The actual number of items sold per unit of time. ; The mean of the Poisson distribution represents the average number of goods sold per unit of time. It is a natural constant.

4. The method for testing the consistency of inventory data in a smart retail terminal according to claim 1, characterized in that, In S2, the process of generating the physical inventory change event sequence includes: randomly generating a product sales and outbound event sequence on the time axis based on a preset sales rate probability distribution function; Based on a preset replenishment trigger threshold, when the simulated inventory is lower than the replenishment trigger threshold, a replenishment inbound event sequence for the corresponding product is generated and the replenishment delay time is included. Based on the preset probability of the exchange event, a pair of event sequences for exchange outbound and exchange inbound are generated.

5. The method for testing the consistency of inventory data in a smart retail terminal according to claim 4, characterized in that, In S2, the baseline inventory data includes the timestamp, terminal ID, product SKU, change type, change quantity, and post-change inventory quantity for each inventory change event.

6. The method for testing the consistency of inventory data in a smart retail terminal according to claim 1, characterized in that, In S3, the tampering operation includes: Delayed transmission: The original inventory reporting message is temporarily stored in a buffer and forwarded to the backend system after a preset delay period; Discard messages: Randomly discard a portion of the original inventory reporting messages according to a preset discard probability, and do not forward them to the backend system; The content of the tampering is as follows: the inventory quantity field / product SKU field in the original inventory reporting message is modified to a preset tampering value before being forwarded to the backend system; Repeated transmission: Copy the same original inventory reporting message multiple times and forward it to the backend system at preset intervals; Out-of-order sending: The sending order of multiple original inventory reporting messages is shuffled before being forwarded to the backend system.

7. The method for testing the consistency of inventory data in a smart retail terminal according to claim 1, characterized in that, In S4, the alignment comparison includes: According to the preset time interval, retrieve the real-time inventory snapshot data of each product SKU under each test terminal from the background system; Using terminal ID, product SKU, and timestamp as alignment dimensions, the inventory snapshot data is matched with the corresponding time-based inventory value in the baseline inventory data; Calculate the absolute value of the difference between the inventory snapshot data and the benchmark inventory data under the same dimension, and compare the absolute value of the difference with a preset tolerance threshold.

8. The method for testing the consistency of inventory data in a smart retail terminal according to claim 1, characterized in that, In S5, the associated information of the inconsistency event includes: event occurrence timestamp, terminal ID, product SKU, backend system recorded inventory value, baseline inventory value, absolute value of difference, direction of difference, and currently effective tampering policy label.

9. The method for testing the consistency of inventory data in a smart retail terminal according to claim 1, characterized in that, It also includes, based on the data consistency test report, performing correlation analysis between the inconsistency events and the corresponding tampering strategies to identify the defect types in the back-end system's inventory processing logic; The defect types include: inventory update lag caused by message delay, inventory shortage caused by message loss, inventory accumulation caused by message duplication, inventory status disorder caused by message out-of-order, and inventory deviation caused by message content error.

10. A system for testing the consistency of inventory data in a smart retail terminal, employing the method for testing the consistency of inventory data in a smart retail terminal as described in any one of claims 1-9, characterized in that, include: Parameter configuration unit: used to configure test scenario parameters, determine the smart retail terminals participating in the test, test duration, physical inventory change scenario parameters, and inventory reporting message tampering strategy parameters; Benchmark data generation unit: used to generate a sequence of physical inventory change events based on the physical inventory change scenario parameters, and record each inventory change event as benchmark inventory data; Message hijacking and tampering unit: During test execution, the data simulation gateway intercepts the original inventory reporting message sent by the smart retail terminal to the back-end system, performs the corresponding tampering operation on the original inventory reporting message according to the tampering strategy parameters, and forwards the tampered / untampered message to the back-end system; Inventory data comparison unit: used to obtain the inventory snapshot data of each terminal corresponding to the product recorded by the back-end system, and to align and compare the inventory snapshot data with the benchmark inventory data according to the time series; Abnormal Data and Report Output Unit: When the difference between the inventory snapshot data and the baseline inventory data exceeds a preset tolerance threshold, it determines that a data inconsistency event has occurred and records the associated information of the inconsistency event; After the test is completed, all inconsistencies are summarized and a data consistency test report is generated.

Images