Numbering method, apparatus, device, storage medium and product
Patent Information
- Application Number
- CN202610998550.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-06
- Publication Date
- 2026-10-20
AI Technical Summary
[0003]本申请的主要目的在于提供一种造数方法、装置、设备、存储介质及产品,旨在解决人工在设备端处理并完成相关操作,测试数据准备及执行,导致造数效率低的技术问题
与相关技术中,ATM设备端存取款交易流程长,需要准备的交易场景复杂。常规的造数方法是人工在设备端处理并完成相关操作,测试数据准备及执行,导致造数效率低相比,本申请响应于业务触发指令,获取业务信息,其中,所述业务信息包括业务类型、场景集合和批量笔数;基于所述业务类型,匹配对应的标准交易步骤序列,基于所述业务信息和所述标准交易步骤序列,执行批量造数。即本申请在接收到业务触发指令之后,会自动获取包括业务类型、场景集合和批量笔数的业务信息,并根据业务类型,自动匹配对应的标准交易步骤序列,从而,根据业务信息和标准交易步骤序列,自动执行批量造数,不需要人工在设备端处理并完成相关操作,测试数据准备及执行,提高了造数效率。
Smart Images

Figure FT_1 
Figure FT_2 
Figure FT_3
Abstract
Description
Technical Field
[0001] This application relates to the field of testing technology, and in particular to a method, apparatus, device, storage medium and product for generating numbers. Background Technology
[0002] In related technologies, ATM cash deposit and withdrawal transactions involve lengthy processes and complex transaction scenarios. Conventional data generation methods involve manual processing and execution of related operations on the device, including test data preparation and execution, resulting in low data generation efficiency. Summary of the Invention
[0003] The main objective of this application is to provide a data generation method, apparatus, device, storage medium, and product, which aims to solve the technical problem of low data generation efficiency caused by manual processing and completion of related operations, test data preparation, and execution at the device end.
[0004] To achieve the above objectives, this application proposes a number generation method, which includes: In response to a business trigger command, business information is obtained, wherein the business information includes business type, scenario set, and batch number of transactions; Based on the business type, a corresponding standard transaction step sequence is matched, and based on the business information and the standard transaction step sequence, batch data generation is performed.
[0005] In one embodiment, the step of performing batch data generation based on the business information and the standard transaction step sequence includes: Based on the set of scenarios, the standard transaction step sequence is differentiated and adjusted to obtain the target transaction step sequence; Based on the number of transactions in the batch, the target transaction step sequence is executed sequentially to generate batch numbers.
[0006] In one embodiment, the step of obtaining business information in response to a business triggering instruction, wherein the business information includes business type, scenario set, and batch number of transactions, includes the following steps before: In response to a business type selection instruction, the business type is obtained, and the test scenario corresponding to the business type is determined, wherein the business type includes at least deposit, withdrawal, inquiry, and transfer; The test scenario is returned to the user interface so that the user can select the test scenario.
[0007] In one embodiment, the step of sequentially executing the target transaction step sequence based on the batch number of transactions to generate batch numbers includes: For each transaction in the batch, the target transaction step sequence is encapsulated, and batch data generation is performed based on the encapsulated target transaction step sequence.
[0008] In one embodiment, the step of encapsulating the target transaction step sequence corresponding to each transaction in the batch includes: Obtain the initial field set of the current transaction request, and assemble the initial field set according to the preset message specification to obtain the packet field. The preset message specification includes at least field length alignment, code conversion and field rendering. Encryption operations are performed on sensitive fields in the packet assembly field to obtain encrypted fields, wherein the encryption operations include at least hardware encryption, uplink and downlink packet encryption, and key update; The encrypted field is sent to the host via a network transmission protocol. If a response message is received from the host, the encrypted field in the response message is decrypted and restored to obtain the decrypted field. The decrypted field is parsed based on the preset message specification, and key fields are extracted from the parsed field. The key fields include at least the host serial number, account balance, and account reference number.
[0009] In one embodiment, the step of batch data generation based on the encapsulated target transaction step sequence includes: Upon completion of each transaction, the current transaction count and the aforementioned key fields are sent to the user interface to update the progress bar percentage on the user interface and update the log text.
[0010] Furthermore, to achieve the above objectives, this application also proposes a number generation device, which includes: The acquisition module is used to acquire business information in response to a business trigger command, wherein the business information includes business type, scenario set, and batch number of transactions; The execution module is used to match the corresponding standard transaction step sequence based on the business type, and to perform batch data generation based on the business information and the standard transaction step sequence.
[0011] In addition, to achieve the above objectives, this application also proposes a number generation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the number generation method as described above.
[0012] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the number generation method described above.
[0013] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the number generation method described above.
[0014] One or more technical solutions proposed in this application have at least the following technical effects: In contrast to related technologies, ATM cash deposit and withdrawal transactions involve lengthy processes and complex transaction scenarios. Conventional data generation methods involve manual processing and execution at the device, resulting in low efficiency. This application, however, responds to a business trigger command by acquiring business information, including the business type, scenario set, and batch transaction count. Based on the business type, it matches a corresponding standard transaction step sequence and performs batch data generation based on the business information and the standard transaction step sequence. In other words, upon receiving a business trigger command, this application automatically acquires business information including the business type, scenario set, and batch transaction count, and automatically matches the corresponding standard transaction step sequence based on the business type. Therefore, it automatically performs batch data generation based on the business information and the standard transaction step sequence, eliminating the need for manual processing and execution at the device, thus improving data generation efficiency. Attached Figure Description
[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 This is a flowchart illustrating the method for generating numbers according to Embodiment 1 of this application; Figure 2 This is a flowchart illustrating the encapsulation of the number generation method in this application; Figure 3 This is a flowchart illustrating Embodiment 2 of the number generation method of this application; Figure 4 This is a schematic diagram of the module structure of the number generation device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the number generation method in the embodiments of this application.
[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0019] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.
[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.
[0021] The main solution of this application embodiment is: in response to a business triggering instruction, obtain business information, wherein the business information includes business type, scenario set and batch number of transactions; based on the business type, match the corresponding standard transaction step sequence; and based on the business information and the standard transaction step sequence, perform batch data generation.
[0022] In related technologies, ATM cash deposit and withdrawal transactions involve lengthy processes and complex transaction scenarios. Conventional data generation methods involve manual processing and execution of related operations on the device, including test data preparation and execution, resulting in low data generation efficiency.
[0023] Upon receiving a business trigger instruction, this application automatically acquires business information including business type, scenario set, and batch number of transactions. Based on the business type, it automatically matches the corresponding standard transaction step sequence. Thus, based on the business information and the standard transaction step sequence, it automatically executes batch data generation without requiring manual processing and completion of related operations on the device side, improving data generation efficiency.
[0024] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or data generation device capable of performing the above functions. The following description uses a data generation device as an example to illustrate this embodiment and the subsequent embodiments.
[0025] Based on this, the embodiments of this application provide a method for generating numbers, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the number generation method of this application.
[0026] In this embodiment, the number generation method includes steps S10 to S20: Step S10: In response to the business triggering command, obtain business information, wherein the business information includes business type, scenario set, and batch number of transactions; It should be noted that the execution entity in this embodiment is the data generation device. The business trigger instruction refers to the start signal generated when the user performs a specific operation on the graphical user interface (such as clicking the "Start Generation" button), used to notify the tool to start the data generation task. The business type refers to the specific category of deposit and withdrawal business, including deposit, withdrawal, inquiry, transfer, etc. The scenario set refers to the summary of one or more specific test scenarios selected by the user, such as normal transaction, withdrawal reversal, deposit card cash, incorrect password, duplicate transaction, etc. The batch number of transactions refers to the total number of transaction data entries to be generated in a single data generation task set by the user. After receiving the business trigger instruction from the user, the data generation device immediately starts the data processing flow, reading the parameters pre-selected or input by the user from the corresponding controls in the graphical interface (such as drop-down boxes, checkboxes, and numeric input boxes), specifically obtaining business information including the business type, scenario set, and batch number of transactions. The obtained business information is temporarily stored in memory as input parameters for subsequent message assembly and process execution. This enables the rapid acquisition of data generation task parameters, transforming multiple user interface operations into structured program input data, and providing necessary data support for the subsequent fully automated execution process.
[0027] Step S20: Based on the business type, match the corresponding standard transaction step sequence, and perform batch data generation based on the business information and the standard transaction step sequence.
[0028] Understandably, a standard transaction step sequence refers to a predefined set of fixed-order operation processes for each business type (such as deposits and withdrawals). This sequence arranges the complete interactive process at the ATM device (including card insertion, service selection, password verification, amount input, transaction confirmation, and card retrieval) in the actual execution order, forming a standardized list of steps that can be automatically executed by the software. The data generation device, based on the acquired business type, searches for and matches the standard transaction step sequence corresponding to that business type from its built-in business scenario process engine. For example, the withdrawal business corresponds to a fixed sequence of steps including card insertion, withdrawal selection, password verification, amount input, transaction confirmation, receipt printing, and card retrieval. Subsequently, combining the acquired business information (including the scenario set and batch transaction count) with the standard transaction step sequence, it initiates a batch data generation loop: repeatedly executing the sequence according to the set batch transaction count. Each execution dynamically adjusts the parameters or branch logic in the steps based on the specific scenario in the scenario set (such as normal transaction, withdrawal reversal, etc.), completing the entire process of packet assembly, encryption, request, decryption, and depacketization of messages one by one until the specified number of transaction data is generated.
[0029] In one feasible implementation, step S20 includes: Based on the set of scenarios, the standard transaction step sequence is differentiated and adjusted to obtain the target transaction step sequence; It should be noted that after obtaining the standard transaction step sequence corresponding to the business type, the data generation device further reads the user-selected scenario set and performs differentiated adjustments to the standard transaction step sequence according to the preset logic rules of each scenario in the set. Specifically, if the scenario set includes a "password error" scenario, the password field in the password verification step is adjusted to an error value; if it includes a "withdrawal reversal" scenario, a reversal request step is inserted after the transaction confirmation step, and the subsequent response processing logic is modified; if it includes a "deposit card cash" scenario, the state simulation parameters after the deposit confirmation step are adjusted. By traversing each scenario in the scenario set and modifying the condition judgments, data fields, or subsequent branches of the relevant steps in the standard sequence accordingly, one or more (depending on the scenario combination) target transaction step sequences are finally generated. This allows the step template for the same business type to flexibly adapt to various abnormal or boundary scenarios without needing to write a complete execution flow separately for each scenario.
[0030] Optionally, based on the set of scenarios, the steps to differentiate the standard transaction step sequence to obtain the target transaction step sequence include: Based on each scenario in the scenario set, a corresponding parameter coverage strategy is preset, and a parameter coverage marker is embedded in the target transaction step sequence. The parameter coverage marker is used to trigger dynamic value replacement of a specific field in the initial field set in the subsequent package assembly stage.
[0031] Understandably, the parameter coverage strategy refers to a predefined set of field-value mapping rules for each specific test scenario (such as normal transaction, withdrawal reversal, deposit card cash, password error, etc.). This specifies which fields (such as amount, password, transaction code, reversal flag) in the message should be forcibly replaced with specific values during the packet assembly stage to simulate the typical data characteristics of that scenario. The parameter coverage marker refers to a specific identifier or label inserted into the target transaction step sequence. It is used to indicate to the tool in subsequent packet assembly stages that "the current step requires the application of the parameter coverage strategy," and points to the corresponding strategy number, thereby decoupling the scenario logic from the field assembly action. While performing differentiated adjustments, the data generation device further loads the corresponding parameter coverage strategy from the internal configuration library for each scenario in the scenario set. For example, the "withdrawal reversal" strategy specifies that the transaction amount is fixed at 100.00 yuan and the reversal flag is set to "1"; the "password error" strategy specifies that the PIN field is forcibly replaced with a preset error ciphertext value. Subsequently, the tool binds these strategy numbers to relevant steps in the step sequence (such as "enter amount" and "password verification"), inserts parameter overriding markers at the corresponding positions in the target transaction step sequence, and carries strategy references in the markers. When subsequent package assembly steps encounter this marker, the tool no longer uses the default initial field value, but dynamically overwrites the corresponding field according to the mapping relationship in the strategy. Thus, the expression of scenario differences is further reduced from "modifying step logic" to "modifying field data", making data processing during scenario switching more accurate and easier to expand.
[0032] Furthermore, based on each scenario in the scenario set, a corresponding parameter coverage strategy is preset, a parameter coverage marker is embedded in the target transaction step sequence, and the effective timing of the parameter coverage strategy is determined according to the step position of the parameter coverage marker in the target transaction step sequence. The effective timing includes pre-packet coverage and in-step coverage.
[0033] It should be noted that the effective timing refers to the trigger point of the field replacement operation in the parameter overriding strategy on the transaction execution timeline, which is divided into two modes: "pre-packet overriding" (completing field value replacement before message assembly) and "in-step overriding" (replacing the field values used in a specific marked step in the target transaction step sequence in real time). Pre-packet overriding means that after obtaining the initial field set and before executing the packet assembly operation, the field values in the strategy are written into the corresponding fields of the initial field set all at once. The entire subsequent packet assembly process uses the replaced values, which do not change over time or steps. In-step overriding means that instead of uniform replacement before packet assembly, the field values are replaced with the strategy values only at the moment of execution of a specific step in the target transaction step sequence that carries a parameter overriding mark (such as "enter amount" or "password verification"). The replacement is effective only for that step and does not affect the field values used in other steps. After the data generation device pre-sets the parameter overriding strategy for each scenario in the scenario set during the differentiation adjustment phase, it further analyzes the specific step position to which each parameter overriding mark is attached in the target transaction step sequence. If the flag is attached to a pre-processing step in the sequence (such as "insert card" or "select service") or a starting step strongly related to message packet assembly, the policy's effective timing is set to "pre-packet assembly overwrite." This means that before subsequent packet assembly steps begin, the tool reads the policy's field-value mapping from the configuration and replaces the specified field in the initial field set with the policy value in one go. This replacement value persists through all subsequent sub-steps of the entire transaction. If the flag is attached to a mid-stage step in the sequence with clear business meaning (such as "enter amount," "password verification," or "confirm transaction"), the policy's effective timing is set to "step execution overwrite." This means that when the tool executes this specific step, it dynamically reads the corresponding field value from the policy and temporarily replaces it. This replacement is only used in the logic of that step, and after execution, the field reverts to its initial value or the current value in the context, without affecting subsequent steps. Thus, fine-grained control over parameter coverage strength and timing is achieved, allowing different fields in the same scenario to select the most suitable coverage timing based on their business meaning.
[0034] Based on the number of transactions in the batch, the target transaction step sequence is executed sequentially to generate batch numbers.
[0035] Understandably, the data generation device drives the execution of the target transaction step sequence using a loop control structure based on the user-defined batch number of transactions. In each loop, the tool strictly follows the step order in the target transaction step sequence (e.g., starting from card insertion, proceeding through password verification, amount input, transaction confirmation, etc., until card removal), executing each operation sequentially to complete the message exchange and data recording of a complete transaction. After a single transaction is completed, the tool automatically determines whether the number of generated transactions has reached the batch transaction threshold. If not, it continues to the next loop, repeating the same target transaction step sequence; if the threshold has been reached, the loop terminates, ending the data generation task. Thus, the automated execution capability of a single transaction is extended to a configurable batch continuous production capability, achieving efficient batch generation of test data.
[0036] In one possible implementation, the following steps are included prior to step S10: In response to a business type selection instruction, the business type is obtained, and the test scenario corresponding to the business type is determined, wherein the business type includes at least deposit, withdrawal, inquiry, and transfer; It should be noted that the business type selection instruction refers to the interaction signal generated when a user selects a business option (such as deposit, withdrawal, etc.) in the business type drop-down box (QComboBox) of the graphical interface. This signal triggers the interface to refresh and the scenario matching logic. When a user switches or selects a business type (such as deposit, withdrawal, inquiry, or transfer) in the business type drop-down box of the graphical interface, the data generation device captures the business type selection instruction, immediately obtains the specific business type selected by the user, and then, based on the built-in business-scenario mapping relationship (for example, the withdrawal business corresponds to scenarios such as normal transaction, withdrawal reversal, incorrect password, and duplicate transaction), dynamically determines all available test scenarios associated with the business type, and displays these scenarios in the test scenario area of the interface in the form of checkboxes, while automatically clearing the scenario selection status of other business types that may have remained previously.
[0037] The test scenario is returned to the user interface so that the user can select the test scenario.
[0038] Understandably, the user interface refers to the graphical operation window built on the PyQt5 framework, containing visual controls such as a test scenario selection area for testers to interact with the tool. After determining all available test scenarios based on the business type, the data generation device transmits and renders these test scenarios as a checkbox list to the test scenario selection area of the user interface. Each test scenario corresponds to an independent checkbox, which is either unselected by default or retained based on the previous operation. Users can freely select the scenarios to be executed from the returned scenario list by checking or deselecting them on this interface. The interface also provides select all / deselect all auxiliary functions to improve operational convenience.
[0039] In one feasible implementation, the step of batch data generation, based on the number of transactions in the batch, involves sequentially executing the target transaction step sequence, including: For each transaction in the batch, the target transaction step sequence is encapsulated, and batch data generation is performed based on the encapsulated target transaction step sequence.
[0040] It should be noted that, based on the number of transactions in the batch, the data generation device encapsulates the corresponding target transaction step sequence (including card insertion, password verification, amount input, transaction confirmation, card retrieval, etc.) and transaction-specific parameters (such as card number information loaded from the configuration file, dynamically generated amount value, currently used key version, and differentiated flags determined by the scenario set) for each transaction to be generated, forming independent task objects. Each encapsulated task object has a unified execution interface and internally contains a complete five-stage message processing flow: packet assembly, encryption, request, decryption, and unpacking. Subsequently, the tool sequentially calls the execution interfaces of these encapsulated task objects according to the number of transactions in the batch. Each task independently completes a complete transaction message interaction and independently records its execution result (such as response code, transaction number, balance, etc.). After all tasks are executed, the batch data generation process ends. Thus, by encapsulating, the complex multi-step process is transformed into a unified-granularity task unit, simplifying the batch scheduling logic, while ensuring that the parameters and states of each transaction are isolated from each other, avoiding cross-transaction interference. Figure 2 , Figure 2 A flowchart for the encapsulation process is provided.
[0041] In this implementation, the target step sequence and its unique parameters for each transaction are encapsulated into an independent task unit. Each transaction has its own independent operating environment and data copy, ensuring that multiple transactions do not interfere with each other during execution. This effectively avoids errors caused by shared variables or residual states (such as the balance of the previous transaction affecting the next transaction), improving the accuracy and stability of batch data generation. At the same time, the encapsulated task provides a consistent calling interface. Batch loops only need to repeatedly call the same interface without expanding all step details within the loop body, thereby simplifying the execution control logic, reducing code complexity and maintenance costs, and further improving the reliability and execution efficiency of the tool.
[0042] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 The data generation method further includes steps S01 to S04, which involve encapsulating the target transaction step sequence corresponding to each transaction in the batch of transactions. Step S01: Obtain the initial field set of the current transaction request, and assemble the initial field set based on the preset message specification to obtain the packet field. The preset message specification includes at least field length alignment, code conversion and field rendering. It is understandable that the current transaction request refers to the complete data request corresponding to the transaction task currently being processed in the batch data generation loop, including all business parameters of that transaction. The initial field set refers to the raw field data directly extracted from configuration files, user input, and task parameters before the packet assembly operation begins, such as terminal number, track data, amount, and timestamp. These fields have not yet been formatted and adjusted according to the message specification. The preset message specification refers to a predefined message format standard that specifies the position, length, encoding method, and rendering rules of each field in the message, used to guide the packet assembly operation. It includes at least three processing rules: field length alignment, code conversion, and field rendering. Field length alignment refers to adjusting the actual value of each field according to the fixed length specified by the preset message specification (such as padding with spaces on the left, zeros on the right, or truncation) to ensure that the field length meets the specification requirements. Code conversion refers to converting the field value according to the encoding format required by the specification, such as converting binary data to BASE64 encoding or performing character set conversion. Field rendering refers to replacing templated field placeholders (such as {{amount}}, {{timestamp}}) with the actual business parameter values in the current transaction request to generate the final field content.
[0043] It should be noted that during the execution of each packaged transaction task, the data generation device first obtains all the original data corresponding to the current transaction request. That is, it extracts field values such as terminal number, track data, amount, and timestamp from the configuration file, user input, and task parameters to form an initial field set. Subsequently, the tool performs three processing steps on each field in the set according to the preset message specification (specifically the 8583 message specification): first, it performs field length alignment to ensure that the actual length of each field conforms to the fixed length specified in the specification; then, it performs code conversion to convert the fields that need to be encoded (such as track data) into BASE64 encoding format; finally, it performs field rendering to replace the preset placeholders in the template with the actual parameter values of the transaction (such as the current amount and timestamp), completing the assembly and integration of all fields, and finally obtaining the packaged fields.
[0044] Step S02: Perform encryption operations on the sensitive fields in the packet grouping field to obtain the encrypted field, wherein the encryption operations include at least hardware encryption, uplink and downlink message encryption and key update; It is understandable that sensitive fields refer to fields in transaction messages that contain sensitive user information or security-critical data, such as PIN (Personal Identification Number, i.e., password), MAC (Message Authentication Code, used for message integrity verification), and Track 2 (magnetic track 2 data, containing account information such as card number). These fields need to be encrypted during transmission to prevent leakage. Hardware encryption refers to using hardware-level or fixed algorithm encryption methods (such as the SM4 national cryptographic algorithm) to encrypt sensitive fields, which, unlike software encryption or simple obfuscation, has higher security strength and stability. Uplink and downlink message encryption refers to encrypting sensitive fields in both uplink messages (requests sent from the ATM to the host) and downlink messages (responses returned from the host to the ATM), ensuring that sensitive data in two-way communication is protected. Key updates refer to changing the encryption key according to a preset period (such as daily), using different keys for encryption of transactions at different times to reduce the security risks caused by long-term key use. After assembling the packet fields, the data generation device identifies and extracts sensitive fields such as PIN, MAC, and Track2 from the packet fields, and then performs encryption operations on these sensitive fields. Specifically, the tool uses the SM4 hard encryption algorithm to encrypt the sensitive fields, and performs this encryption process on sensitive fields in both uplink (request) and downlink (response) messages simultaneously to ensure secure two-way communication. During the encryption process, the tool uses the currently valid key, which is automatically rotated according to a daily update strategy to ensure that transactions generated on different dates use different keys. After encryption, the original plaintext sensitive fields are replaced with encrypted ciphertext data, forming encrypted fields.
[0045] Step S03: Send the encrypted field to the host via a network transmission protocol. If a response message is received from the host, decrypt and restore the encrypted field in the response message to obtain the decrypted field. It's important to note that network transmission protocols refer to the protocol standards followed for data communication between a host and a server. For example, the HTTP protocol defines the format of message transmission, interaction methods, and connection management rules, including mechanisms such as timeout retries, long connection reuse, and TLS handshakes. A host refers to the backend server of an ATM transaction system, typically a front-end system or transaction host, responsible for receiving request messages from the ATM, processing them, and returning response messages. A response message is a data packet containing the transaction result, returned by the host to the ATM after receiving and processing the request message. This packet may also contain encrypted sensitive fields (such as the returned balance and transaction number). The data generation device packages the encrypted fields generated in the previous step according to the specifications of network transmission protocols (such as HTTP). By establishing a network connection with the host, it sends the request message to the host. During the sending process, the tool supports mechanisms such as timeout retries and long connection reuse to improve communication reliability. Subsequently, the tool waits for the host's processing result. If it successfully receives the response message returned by the host, it extracts the sensitive fields that are also in an encrypted state from the response message, and performs decryption and restoration operations using the symmetric key and SM4 algorithm agreed upon during encryption to restore the ciphertext data to the original plaintext, thus obtaining the decrypted fields. If no response is received or a timeout occurs, it retransmits the message or marks it as an abnormal transaction according to the retry mechanism.
[0046] Step S04: Parse the decrypted field based on the preset message specification, and extract key fields from the parsed field. The key fields include at least the host serial number, account balance, and account reference number.
[0047] As can be understood, key fields refer to specific fields among all parsed fields that have core value for test data verification, transaction result recording, or subsequent business connections. These include at least the host transaction number, account balance, and account reference number. The host transaction number is a unique sequential number generated by the host for each transaction, used to identify and trace the processing record of that transaction on the host side. The account balance refers to the latest available balance value recorded by the host for that account after the transaction is completed. The account reference number is a reference number generated by the host for this transaction, used for reconciliation and querying. It is usually used in conjunction with the host transaction number to facilitate the association and tracing of detailed transaction information in subsequent processes. After obtaining the decrypted fields (i.e., the plaintext data of sensitive fields in the response message), the data generation device combines them with the plaintext data of non-sensitive fields to form a complete response message plaintext data body. Subsequently, the tool parses the complete response message according to the preset message specification (i.e., the 8583 message specification): based on the offset, length, and data type of each field defined in the specification, the message is split into several independent parsing fields, each field corresponding to a specific data field (such as response code, amount, timestamp, etc.). After parsing, the tool further filters and extracts key fields from the parsed fields, including at least the host serial number, account balance, and account reference number, and stores them as structured data (such as key-value pairs or table rows) for subsequent log output, result display, or test data archiving.
[0048] In one feasible implementation, the step of batch data generation based on the encapsulated target transaction step sequence includes: Upon completion of each transaction, the current transaction count and the aforementioned key fields are sent to the user interface to update the progress bar percentage on the user interface and update the log text.
[0049] It should be noted that the current transaction count refers to the sequence number (e.g., transaction 1, transaction 2) of the transaction that has been completed and generated transaction data during the batch data generation cycle, used to identify the progress position in the batch task. The progress bar refers to a bar control (e.g., QProgressBar) in the user interface used to visually display the overall progress of batch data generation; its fill percentage increases with the number of completed transactions. The log text refers to a text output area (usually a multi-line text box) in the user interface used to display the tool's running status, operation records, and detailed transaction result information in real time, facilitating user tracking of the execution process and troubleshooting. After each packaged transaction task is fully executed (i.e., the entire process from packet assembly, encryption, sending, receiving the response, decryption, and extraction of key fields is completed), the data generation device immediately sends the current number of transactions (i.e., the completed sequence number) and the key fields extracted from the response message (including host serial number, account balance, account reference number, etc.) to the user interface. Upon receiving this data, the user interface calculates the current progress percentage based on the ratio of the current number of transactions to the batch number of transactions and updates the display value of the progress bar control, causing the progress bar to advance by the corresponding increment. On the other hand, it formats the completion information of the current number of transactions and the content of the key fields into readable text and appends it to the log text area to record the result details of the transaction in text.
[0050] In this implementation, upon completion of each transaction, the current number of transactions and key fields are proactively pushed to the user interface. The progress bar percentage and log text are updated accordingly, allowing users to obtain real-time execution progress of batch tasks and core results of each transaction (such as transaction number and balance) in both visual and textual formats. This enables timely detection and intervention of abnormal transactions (such as abnormal response codes or inconsistent balance changes) without waiting for all tasks to finish, significantly reducing the delay in problem discovery and response. Simultaneously, the progress bar provides a macro-level overview of progress, while the log text provides micro-level transaction details. These complementary elements enhance the tool's operability and debugging convenience, effectively improving the user experience for testers and the efficiency of problem localization.
[0051] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the number generation method of this application. Any simple transformations based on this technical concept are all within the protection scope of this application.
[0052] This application also provides a number generation device, please refer to... Figure 4 The data generation device includes: The acquisition module 10 is used to acquire business information in response to a business trigger command, wherein the business information includes business type, scenario set and batch number of transactions; The execution module 20 is used to match the corresponding standard transaction step sequence based on the business type, and to perform batch data generation based on the business information and the standard transaction step sequence.
[0053] Optionally, the execution module includes: The adjustment submodule is used to differentiate the standard transaction step sequence based on the scenario set to obtain the target transaction step sequence; and to execute the target transaction step sequence sequentially based on the batch number of transactions to generate batch numbers.
[0054] Optionally, the acquisition module includes: The return submodule is used to respond to the business type selection instruction, obtain the business type, and determine the test scenario corresponding to the business type, wherein the business type includes at least deposit, withdrawal, inquiry and transfer; and return the test scenario to the user interface so that the user can select the test scenario.
[0055] Optionally, the adjustment submodules include: The encapsulation unit is used to encapsulate the target transaction step sequence corresponding to each transaction in the batch of transactions, and to perform batch data generation based on the encapsulated target transaction step sequence.
[0056] Optionally, the packaging unit includes: The parsing subunit is used to obtain the initial field set of the current transaction request, assemble the initial field set according to a preset message specification to obtain the packet field, wherein the preset message specification includes at least field length alignment, code conversion, and field rendering; perform encryption operations on sensitive fields in the packet field to obtain encrypted fields, wherein the encryption operations include at least hardware encryption, uplink and downlink message encryption, and key update; send the encrypted fields to the host through a network transmission protocol; if a response message is received from the host, decrypt and restore the encrypted fields in the response message to obtain decrypted fields; parse the decrypted fields according to the preset message specification, and extract key fields from the parsed fields, wherein the key fields include at least the host serial number, account balance, and account reference number.
[0057] Optionally, the parsing sub-unit includes: An update component is used to send the current transaction count and the key fields to the user interface each time a transaction is completed, so as to update the progress bar percentage of the user interface and update the log text.
[0058] The number generation device provided in this application, employing the number generation method in the above embodiments, can solve the technical problem of number generation. Compared with the prior art, the beneficial effects of the number generation device provided in this application are the same as those of the number generation method provided in the above embodiments, and other technical features in the number generation device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.
[0059] This application provides a number generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the number generation method in Embodiment 1 above.
[0060] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a data generation device suitable for implementing embodiments of this application. The data generation device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, tablets, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The data generation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0061] like Figure 5As shown, the data generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the data generation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the data generation equipment to communicate wirelessly or wiredly with other devices to exchange data. Although data generation equipment with various systems is shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.
[0062] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.
[0063] The number generation device provided in this application, employing the number generation method described in the above embodiments, can solve the technical problem of number generation. Compared with the prior art, the beneficial effects of the number generation device provided in this application are the same as those of the number generation method provided in the above embodiments, and other technical features of the number generation device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.
[0064] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.
[0065] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0066] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the number generation method in the above embodiments.
[0067] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.
[0068] The aforementioned computer-readable storage medium may be included in the data generation device; or it may exist independently and not assembled into the data generation device.
[0069] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the data generation device, the data generation device: responds to a business trigger instruction, acquires business information, wherein the business information includes a business type, a set of scenarios, and a batch number of transactions; matches a corresponding standard transaction step sequence based on the business type; and performs batch data generation based on the business information and the standard transaction step sequence.
[0070] Computer program code for performing the operations of this application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0071] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0072] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.
[0073] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described number generation method, thereby solving the technical problem of number generation. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the number generation method provided in the above embodiments, and will not be repeated here.
[0074] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the number generation method described above.
[0075] The computer program product provided in this application can solve the technical problem of number generation. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the number generation method provided in the above embodiments, and will not be repeated here.
[0076] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.
Claims
1. A method for generating numbers, characterized in that, The number generation method includes: In response to a business trigger command, business information is obtained, wherein the business information includes business type, scenario set, and batch number of transactions; Based on the business type, a corresponding standard transaction step sequence is matched, and based on the business information and the standard transaction step sequence, batch data generation is performed.
2. The number generation method as described in claim 1, characterized in that, The step of performing batch data generation based on the business information and the standard transaction step sequence includes: Based on the set of scenarios, the standard transaction step sequence is differentiated and adjusted to obtain the target transaction step sequence; Based on the number of transactions in the batch, the target transaction step sequence is executed sequentially to generate batch numbers.
3. The number generation method as described in claim 1, characterized in that, The step of responding to a business trigger command and obtaining business information, wherein the business information includes business type, scenario set, and batch number of transactions, includes the following prior steps: In response to a business type selection instruction, the business type is obtained, and the test scenario corresponding to the business type is determined, wherein the business type includes at least deposit, withdrawal, inquiry, and transfer; The test scenario is returned to the user interface so that the user can select the test scenario.
4. The number generation method as described in claim 2, characterized in that, The step of generating batch numbers by sequentially executing the target transaction step sequence based on the batch number of transactions includes: For each transaction in the batch, the target transaction step sequence is encapsulated, and batch data generation is performed based on the encapsulated target transaction step sequence.
5. The number generation method as described in claim 4, characterized in that, The step of encapsulating the target transaction step sequence corresponding to each transaction in the batch includes: Obtain the initial field set of the current transaction request, and assemble the initial field set according to the preset message specification to obtain the packet field. The preset message specification includes at least field length alignment, code conversion and field rendering. Encryption operations are performed on sensitive fields in the packet assembly field to obtain encrypted fields, wherein the encryption operations include at least hardware encryption, uplink and downlink packet encryption, and key update; The encrypted field is sent to the host via a network transmission protocol. If a response message is received from the host, the encrypted field in the response message is decrypted and restored to obtain the decrypted field. The decrypted field is parsed based on the preset message specification, and key fields are extracted from the parsed field. The key fields include at least the host serial number, account balance, and account reference number.
6. The number generation method as described in claim 5, characterized in that, The steps for batch data generation based on the encapsulated target transaction step sequence include: Upon completion of each transaction, the current transaction count and the aforementioned key fields are sent to the user interface to update the progress bar percentage on the user interface and update the log text.
7. A number generation device, characterized in that, The device includes: The acquisition module is used to acquire business information in response to a business trigger command, wherein the business information includes business type, scenario set, and batch number of transactions; The execution module is used to match the corresponding standard transaction step sequence based on the business type, and to perform batch data generation based on the business information and the standard transaction step sequence.
8. A data generation device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the number generation method as described in any one of claims 1 to 6.
9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the number generation method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the number generation method as described in any one of claims 1 to 6.