Bill data generation method and device, equipment, medium and product

Abstract

The invention discloses a bill data generation method and device, equipment, a medium and a product. The method comprises the following steps: in response to a bill data generation request, obtaining original bill data generated by interaction between target systems according to business operation interface information of each target system, and determining a market category corresponding to each original bill in the original bill data; based on a domain-driven design strategy, performing sub-domain division on the original bills of different market categories, and constructing a domain model corresponding to the original bill data according to a sub-domain division result; and performing mapping implementation on the domain model through a preset test component, and performing configuration on an image user interface, so as to generate bill test data based on the test component and the image user interface which are realized through mapping. According to the technical scheme, the internal feature association of the bill data can be automatically extracted and analyzed, and effective and accurate test bill data is constructed in combination with the test component, so that the subsequent software test efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method, apparatus, equipment, medium, and product for generating invoice data. Background Technology

[0002] The bill business mainly revolves around the issuance, circulation, financing, and settlement of commercial bills. It is characterized by a rich variety of bill attributes, complex and interdependent business processes, and diverse roles of business participants. On the one hand, obtaining real, effective, and usable bill test data throughout its entire lifecycle through actual business operations requires testers to have sufficient knowledge of bill business and be familiar with the various functional modules of the bill system. On the other hand, bill test data itself is consumable data that cannot be reused, and its preparation involves long and complex business processes, making testing time-consuming and labor-intensive, yet it is an indispensable part of the testing process.

[0003] Therefore, how to automatically extract and analyze the inherent feature relationships of invoice data, and combine it with test components to construct effective and accurate test invoice data, thereby improving the efficiency of subsequent software testing, is an urgent problem to be solved. Summary of the Invention

[0004] This invention provides a method, apparatus, device, medium, and product for generating invoice data, which automatically extracts and analyzes the inherent feature relationships of invoice data, and combines test components to construct effective and accurate test invoice data, thereby improving the efficiency of subsequent software testing.

[0005] According to one aspect of the present invention, a method for generating invoice data is provided, comprising:

[0006] In response to the request to generate invoice data, the system obtains the original invoice data generated by the interaction between the target systems based on the business operation interface information of each target system, and determines the market category corresponding to each original invoice in the original invoice data.

[0007] Based on the domain-driven design strategy, the original invoices of different market categories are divided into subdomains, and the domain model corresponding to the original invoice data is constructed according to the subdomain division results.

[0008] The domain model is mapped and implemented using preset test components, and configured in the graphical user interface to generate ticket test data based on the mapped test components and graphical user interface.

[0009] According to another aspect of the present invention, a bill data generation apparatus is provided, comprising:

[0010] The determination module is used to respond to the bill data generation request, obtain the original bill data generated by the interaction between the target systems based on the business operation interface information of each target system, and determine the market category corresponding to each original bill in the original bill data;

[0011] The module is used to divide the original invoices of different market categories into subdomains based on the domain-driven design strategy, and to build the domain model corresponding to the original invoice data based on the subdomain division results.

[0012] The generation module is used to map the domain model through preset test components and configure it in the graphical user interface to generate ticket test data based on the mapped test components and graphical user interface.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the invoice data generation method according to any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the invoice data generation method according to any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer program product is also provided, the computer program product including a computer program that, when executed by a processor, implements the invoice data generation method of any embodiment of the present invention.

[0019] The technical solution of this invention, in response to a document data generation request, obtains the original document data generated by the interaction between the target systems based on the business operation interface information of each target system, and determines the market category corresponding to each original document in the original document data. Based on a domain-driven design strategy, the original documents for different market categories are divided into subdomains, and a domain model corresponding to the original document data is constructed based on the subdomain division results. The domain model is mapped and implemented using preset test components, and configured in a graphical user interface. Document test data is generated based on the mapped test components and the graphical user interface. By constructing a domain model corresponding to the document data based on a domain-driven design strategy, the inherent feature relationships of the document data can be automatically extracted and analyzed. Combined with test components, effective and accurate test document data can be constructed, thereby improving the efficiency of subsequent software testing.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of a bill data generation method provided in Embodiment 1 of the present invention;

[0023] Figure 2 This is a flowchart of a bill data generation method provided in Embodiment 2 of the present invention;

[0024] Figure 3 This is a structural block diagram of a bill data generation device provided in Embodiment 3 of the present invention;

[0025] Figure 4 This is a schematic diagram of the structure of the electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," "target," "candidate," and "alternative," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices. The acquisition, storage, use, and processing of data in the technical solutions of this application comply with relevant laws and regulations.

[0028] It should be noted that in related technologies, due to the characteristics of the bill industry—long business processes with many sub-processes, rich and diverse information on the bills, and the non-reusable nature of consumable test data—and because database operations or backup / import / restore methods can only be performed on the bill system under test, making the test data unusable, the commonly used method for preparing test data is manual data insertion through real business operations. This method is intuitive and has high data accuracy, but it is inefficient and difficult to handle large-scale data demands. On the one hand, testers need sufficient knowledge of bill business and be familiar with the various functional modules of the bill system; on the other hand, bill test data itself is consumable and non-reusable, and its preparation involves long and complex business processes, making manual data insertion time-consuming and labor-intensive. To address the aforementioned issues, this invention provides a solution for automatically generating test data, supporting complex rules and large-scale scenarios in the bill business domain. Through Domain-Driven Design (DDD) methodology, it clarifies the business rules and states of the bill business domain, performs bounded context analysis, and extracts domain models such as entities, value objects, and domain services. Based on this, it utilizes pre-defined test components, including test fragments and logic controllers, to achieve a solution where testers do not need extensive knowledge of bill business; they only need to focus on the requirements being tested and clarify the business characteristics to obtain the necessary test data. Specific implementation details will be provided in subsequent embodiments.

[0029] Example 1

[0030] Figure 1 This is a flowchart of a document data generation method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where document data is analyzed and a domain model is constructed based on a domain-driven design strategy, and test data corresponding to the document data is generated by combining preset test components. This method can be executed by a document data generation device, which can be implemented in hardware and / or software. The document data generation device can be configured in an electronic device, such as... Figure 1 As shown, the method for generating this invoice data includes:

[0031] S101. In response to the bill data generation request, based on the business operation interface information of each target system, obtain the original bill data generated by the interaction between the target systems, and determine the market category corresponding to each original bill in the original bill data.

[0032] Among them, negotiable instruments, as an electronic medium, carry numerous attributes (such as issuance date, maturity date, face value, circulation status, etc.) and circulate in various negotiable instrument systems and target systems, making them a type of information-rich, consumable test data. A negotiable instrument data generation request refers to the situation where raw negotiable instrument data is analyzed and modeled to generate test negotiable instrument data similar to the raw data using pre-defined test components. Target systems include enterprise systems and financial institution systems; interface information refers to the data content and related descriptions transmitted or exchanged by the target systems during interaction, mainly including input parameters and output results. The purpose of obtaining interface information is to facilitate business function implementation and subsequent functional interactions, constructing a hybrid business scenario implementation device for test data preparation through associated interfaces. Specifically, interface information can be information representing the data transmission interface between target systems. The raw negotiable instrument data may include at least one raw negotiable instrument.

[0033] Optionally, based on the business operation interface information of each target system, the original invoice data generated by the interaction between the target systems can be obtained, including: based on the business operation interface information of each target system, obtaining invoice data generated by the interaction between enterprise systems, invoice data generated by the interaction between enterprise systems and financial institution systems, and invoice data generated by the interaction between financial institution systems, as the original invoice data generated by the interaction between the target systems.

[0034] It should be noted that the bill business mainly revolves around the issuance, circulation, financing, and settlement of commercial bills. In the bill business, the market is usually divided into primary market and secondary market according to the different transaction links and participating entities. Accordingly, bill data generated by the interaction between enterprise systems and bill data generated by the interaction between enterprise systems and financial institution systems can be identified as primary market bill data, while bill data generated by the interaction between financial institution systems can be identified as secondary market bill data.

[0035] Optionally, the market category corresponding to the original bill can be determined, including: determining the transaction stage of the original bill based on the business activities of the original bill; and classifying the original bill into markets based on the transaction stage and the type of target system involved in the original bill, thereby determining the market category corresponding to the original bill.

[0036] The market category can be either a primary market or a secondary market. The primary market is the foundation of the secondary market. Business activities and transaction links can be matched one-to-one; one bill can correspond to at least one business activity. Business activities can include, for example, bill issuance information registration, notification of acceptance application, notification of successful acceptance receipt, notification of bill receipt application, notification of successful receipt receipt, early notification of payment application, or notification of successful payment application response.

[0037] From a transaction perspective, secondary market transactions can be simply understood as those that can only be conducted on discounted bills. Primary market transactions include: bill registration, acceptance presentation, collection presentation, cancellation of bills, guarantee, pledge, release of pledge, transfer endorsement, removal of non-transferable markings, payment presentation, repurchase discounting, and outright discounting. Secondary market transactions include: rediscounting, transfer discounting, and pledged repurchase agreements. In terms of participants, primary market participants are enterprises and financial institutions such as banks, while secondary market participants are also financial institutions such as banks.

[0038] Optionally, the original bills can be market-classified based on the transaction process and the target system type involved, and the corresponding market category can be determined. This includes: if the target system type involved in the original bills includes enterprise systems and the business activities in the transaction process belong to the primary market, then the market category corresponding to the original bills is determined to be the primary market; if the target system type involved in the original bills is financial institution systems and the business activities in the transaction process belong to the secondary market, then the market category corresponding to the original bills is determined to be the secondary market.

[0039] Optionally, the original bills can be aggregated and divided into primary market business contexts or secondary market business contexts based on business capabilities and semantic boundaries. The primary market business context includes primary market business capabilities such as bill issuance information registration and acceptance presentation, which are used for the interaction between bill entities and financial institutions such as enterprises and banks. The secondary market business context includes secondary market businesses such as rediscounting, which are used for the interaction between bill entities and financial institutions such as banks.

[0040] S102. Based on the domain-driven design strategy, the original invoices of different market categories are divided into subdomains, and the domain model corresponding to the original invoice data is constructed according to the subdomain division results.

[0041] Domain-Driven Design (DDD) is a software design methodology that focuses on business domains and uses domain models to solve complex business problems. Its core idea is to closely integrate the design of software systems with the actual needs of the business domain. Original bills for different market categories can be primary market original bills or secondary market original bills. Primary market original bills can be divided into a core subdomain of ordinary electronic bills, a credit approval support subdomain, and a general subdomain of bill products. A domain model includes at least one of the following: domain entities, domain value objects, domain events, and domain services.

[0042] Optionally, based on a domain-driven design strategy, the original invoices for different market categories are divided into subdomains, and a domain model corresponding to the original invoice data is constructed based on the subdomain division results; original invoices in the primary market are identified as primary market original invoices, and primary market original invoices are divided into at least two invoice subdomains, and the circulation entities of each invoice subdomain are determined; based on the static and dynamic attributes of the circulation entities, subdomain value objects and subdomain entities are constructed respectively, and domain events and domain services are constructed based on business behavior and business circulation information; based on subdomain entities, subdomain value objects, domain events, and domain services, a domain model corresponding to the original invoice data is constructed.

[0043] The bill subdomain is divided into core, supporting, and general subdomains based on the bounded context subdomain division principle of the domain-driven design strategy. The criteria for a core subdomain are: directly addressing business pain points, demonstrating product differentiation value, and containing content with complex and frequently changing business logic. The criteria for a supporting subdomain are: providing necessary capabilities to the core subdomain, containing content without differentiated value but indispensable. The criteria for a general subdomain are: highly standardized and reusable content. Therefore, for the primary market context, the core subdomain represents typical business scenarios that realize the entire lifecycle of the bill primary market; the supporting subdomain assists in business processes requiring credit approval, such as bill acceptance and discounting; and the general subdomain integrates and connects business capabilities, representing highly standardized and automated business types.

[0044] Optionally, the circulation entity can be determined by analyzing the business within the subdomain. Each circulation entity has a unique identifier. Taking the core subdomain of a standard electronic bill as an example, the circulation entity in this subdomain is the bill itself. The bill number is unique and includes two categories: static attributes and dynamic attributes. Static attributes include whether the bill is divisible, the acceptor, the drawer, the date of issue, and the maturity date, which constitute the bill value object (i.e., the subdomain value object). Dynamic attributes include the bill range, face value, whether it is transferable, the holder, the bill status, and circulation indicators, which constitute the bill entity (i.e., the subdomain entity). The bill triggers business transactions among different stakeholders. These stakeholders only have static attributes, such as customer number, customer name, contracting bank, and channel type, thus constituting stakeholder value objects (i.e., subdomain value objects). Business transactions constitute domain events, which can link a causal chain. Their attributes include business direction, business type, previous bill status, previous circulation flag, subsequent bill status, and subsequent circulation flag, thus constituting business transaction entities (i.e., subdomain entities). The transaction itself constitutes a domain service, possessing the characteristic of a transaction sequence. This connects the bill entity, stakeholder value objects, and business transaction domain events. Finally, based on the subdomain entities, subdomain value objects, domain events, and domain services, a domain model corresponding to the original bill data is constructed.

[0045] Optionally, for each original bill in the original bill data, at least one business behavior corresponding to the original bill can be determined, and the business scenario, previous bill status, previous circulation flag, subsequent bill status and subsequent circulation flag corresponding to each business behavior can be determined to obtain the business flow information corresponding to the original bill.

[0046] The business flow information can include the pre-transfer status, pre-circulation status, post-transfer status, and post-circulation status of the original bills, corresponding to different business behaviors under different business scenarios. The bill status and circulation status are two different status dimensions in the bill business, reflecting the lifecycle stage and circulation authority of the bill, respectively.

[0047] The status of a negotiable instrument describes its entire lifecycle in the business process, from issuance to settlement. It includes six statuses: issued, accepted, received, due, terminated, and settled, focusing on the progress of the business process. The circulation indicator identifies the circulation rights or restrictions of the negotiable instrument, including nine statuses: pending receipt, tradable, locked, non-transferable, pledged, pending redemption, collection in transit, in pursuit, and completed, focusing on the entity's operational rights. [Previous negotiable instrument status, previous circulation indicator] refers to the composite status of the negotiable instrument entity before a specific business action in a given business scenario. [Post-negotiable instrument status, post-circulation indicator] refers to the composite status of the negotiable instrument entity after a specific business action in a given business scenario has been successfully completed.

[0048] For example, using the pattern of [previous bill status, previous circulation indicator] - {business scenario, business behavior} - [post-bill status, post-circulation indicator], we can illustrate two possible business behaviors for bill A:

[0049] The first method: Issuance – Acceptance – Cancellation;

[0050] [None, None] - {Ticket Information Registration, Ticket Information Registration} - [Tickets Issued, Tickets Awaiting Collection]

[0051] [Ticket issued, ticket pending] - {Please accept, acceptance application requested} - [Ticket issued, ticket locked]

[0052] [Ticket issued, locked] - {Acceptance notification, acceptance successful} - [Accepted, ticket awaiting receipt]

[0053] [Accepted, pending receipt] - {Cancellation, cancellation application} - [Terminated, completed];

[0054] The second method: Issuance of bill – Acceptance – Receipt of bill – Presentation for payment before maturity;

[0055] [None, None] - {Ticket Information Registration, Ticket Information Registration} - [Tickets Issued, Tickets Awaiting Collection]

[0056] [Ticket issued, ticket pending] - {Please accept, acceptance application requested} - [Ticket issued, ticket locked]

[0057] [Ticket issued, locked] - {Acceptance notification, acceptance successful} - [Accepted, ticket awaiting receipt]

[0058] [Accepted, Pending Collection] - {Collection Notice, Collection Request Notice} - [Accepted, Locked]

[0059] [Accepted, Locked] - {Notification of receipt, confirmation of successful receipt} - [Received, Circulating | Non-transferable]

[0060] [Ticket Received, Circulating | Non-Transferable] - {Payment Notice, Advance Payment Request Notice} - [Ticket Received, Locked]

[0061] [Invoice received, locked] - {Payment prompt, payment application response and receipt successful} - [Settled, ended].

[0062] For example, a bill corresponds to at least one business action, and a business action corresponds to a set of previous bill status, previous circulation flag, subsequent bill status, and subsequent circulation flag. The corresponding business flow information can be shown in Table 1 below:

[0063] Table 1: Schematic Table of Business Flow Information

[0064]

[0065] It should be noted that because the bill business is very complex, dividing it can resolve the core contradictions in complex business systems, namely the conflict between the ambiguity of business concepts, the uniformity of models, and the complexity of the system. By dividing the bill business into primary market business context and secondary market business context, context boundaries can be established, which facilitates a unified understanding of business concepts and models among the participants within the context.

[0066] Optionally, the original bills in the primary market are divided into at least two bill subdomains, and the circulation entities of each bill subdomain are determined, including: dividing the original bills in the primary market into a core subdomain of ordinary electronic bills, a credit approval support subdomain, and a general subdomain of bill products; determining that the circulation entity of the core subdomain of ordinary electronic bills is the bill, the circulation entity of the credit approval support subdomain is the approval order, and the circulation entity of the general subdomain of bill products is the bill batch.

[0067] Optionally, considering the primary market context – the core subdomain of ordinary electronic bills, it involves business scenarios such as signing, issuing, accepting, receiving, withdrawing, canceling, endorsing, guaranteeing, pledging, releasing pledges, presenting for payment, recourse, agreeing to settlement, and discounting, covering the entire lifecycle of operations in the primary market for bills. Considering the primary market context – the credit approval support subdomain, it involves online and offline acceptance and investigation, approval, contract signing, and certificate effectiveness, covering credit approval operations for acceptance and discounting businesses. Considering the primary market context – the general subdomain of bill products, it involves bill pools, bill discounting, bill acceptance, and bill financing types, arranging the operations of the core subdomain of ordinary electronic bills and the credit support subdomain according to the business rules of specific business types. Secondary market original bills can be divided using the same method as primary market original bills to construct the domain model, which will not be elaborated here.

[0068] S103. The domain model is mapped and implemented using preset test components, and configured in the graphical user interface to generate ticket test data based on the mapped test components and graphical user interface.

[0069] The preset test components refer to preset performance testing tools, such as the JMeter (Apache JMeter) component. The graphical user interface (GUI) can be used to visualize the process orchestration control variables after setting them according to the business characteristics of the test data.

[0070] Optionally, entities in the domain model can be mapped to JMeter components - Post-Extractor Variables & User-defined Variables (default value), value objects in the domain model can be mapped to JMeter components - User-defined Variables, domain events in the domain model can be mapped to JMeter components - Test Fragments, and finally, domain services in the domain model can be mapped to JMeter components - Logic Controllers (see...). Figure 3 & User-defined variables (i.e., default values ​​for process orchestration control variables) are used to achieve mapping to the domain model.

[0071] It should be noted that this invention uses JMeter components to map the models analyzed by Domain-Driven Design (DDD) one-to-one, and provides an implementation method for mapping domain models to generate test ticket data using JMeter components.

[0072] Optionally, common test data can be configured with variables based on their business characteristics, with each type of test data corresponding to a default value for a process orchestration control variable. The GUI visualization encapsulates common test data business characteristic types through dropdown menus, and allows modification of key elements of the bill information via the GUI. For example, the test data format can be text, and the business characteristics can be bill number, sub-bill range, bill status, circulation indicator, drawer, acceptor, payee, guarantor, or pledgor.

[0073] Optionally, the key elements of the acquired invoice information can be set directly in the configuration file, following the format "|". If the set element does not match, it will be empty; if it matches, it will be the corresponding value. For test data business feature types not in the configured list, a default value for the process orchestration control variable can be manually added, which can then be selected from the drop-down list next time. For invoice attributes not in the GUI interface, they can be modified directly in the user-defined variable component. After the user enters the target number of test data entries and the target file path and clicks the "Data Generation" button, the batch-generated invoice numbers can be obtained from the target file, thus generating the invoice test data.

[0074] The technical solution of this invention, in response to a document data generation request, obtains the original document data generated by the interaction between the target systems based on the business operation interface information of each target system, and determines the market category corresponding to each original document in the original document data. Based on a domain-driven design strategy, the original documents for different market categories are divided into subdomains, and a domain model corresponding to the original document data is constructed based on the subdomain division results. The domain model is mapped and implemented using preset test components, and configured in a graphical user interface. Document test data is generated based on the mapped test components and the graphical user interface. By constructing a domain model corresponding to the document data based on a domain-driven design strategy, the inherent feature relationships of the document data can be automatically extracted and analyzed. Combined with test components, effective and accurate test document data can be constructed, thereby improving the efficiency of subsequent software testing.

[0075] Example 2

[0076] Figure 2 This is a flowchart of a bill data generation method provided in Embodiment 2 of the present invention; based on the above embodiments, this embodiment provides a preferred example of analyzing bill data and constructing a domain model based on a domain-driven design strategy, and generating test data corresponding to the bill data in combination with preset test components. Specifically, as shown... Figure 2 As shown, the method includes the following steps:

[0077] S201. In response to the request to generate bill data, based on the business operation interface information of each target system, obtain the bill data generated by the interaction between enterprise systems and the bill data generated by the interaction between enterprise systems and financial institution systems.

[0078] S202. Combine the bill data generated by the interaction between financial institution systems to determine the original bill data generated by the interaction between target systems.

[0079] S203. Determine the transaction stage of the original bill based on the business activities involved.

[0080] S204. Based on the transaction process and the target system type involved in the original bill, classify the original bill into markets and determine the corresponding market category.

[0081] S205. Determine the original bills as primary market original bills, divide the primary market original bills into at least two bill sub-domains, and determine the circulation entities of each bill sub-domain.

[0082] S206. Based on the static and dynamic attributes of the transfer subject, construct subdomain value objects and subdomain entities respectively, and construct domain events and domain services based on business behavior and business transfer information.

[0083] S207. Construct the domain model corresponding to the original invoice data based on subdomain entities, subdomain value objects, domain events, and domain services.

[0084] S208. The domain model is mapped and implemented using preset test components, and configured in the graphical user interface to generate ticket test data based on the mapped test components and graphical user interface.

[0085] The automated test data generation solution provided by this invention supports complex rules and large-scale scenarios in the bill business domain. Through the domain-driven design methodology, the business rules and business status of the bill business domain can be clearly defined, bounded context analysis can be performed, and domain models such as entities, value objects, and domain services can be extracted. Based on this, by using test fragments, logic controllers and other components of the preset test components, a solution can be implemented that does not require testers to have too much knowledge of bill business. They only need to focus on the requirements being tested and clarify the business characteristics to obtain the required test data.

[0086] Example 3

[0087] Figure 3 This is a structural block diagram of a bill data generation device provided in Embodiment 3 of the present invention. This embodiment is applicable to situations where bill data is analyzed and a domain model is constructed based on a domain-driven design strategy, and test data corresponding to the bill data is generated by combining preset test components. The bill data generation device provided in this embodiment can execute the bill data generation method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method. This bill data generation device can be implemented in hardware and / or software and configured in an electronic device with bill data generation function, such as... Figure 3 As shown, the invoice data generation device may specifically include:

[0088] The determination module 301 is used to respond to the bill data generation request, obtain the original bill data generated by the interaction between the target systems according to the business operation interface information of each target system, and determine the market category corresponding to each original bill in the original bill data.

[0089] Module 302 is used to divide the original invoices of different market categories into subdomains based on the domain-driven design strategy, and to construct the domain model corresponding to the original invoice data based on the subdomain division results.

[0090] The generation module 303 is used to map the domain model through preset test components and configure it in the graphical user interface to generate ticket test data based on the mapped test components and graphical user interface.

[0091] The technical solution of this invention, in response to a document data generation request, obtains the original document data generated by the interaction between the target systems based on the business operation interface information of each target system, and determines the market category corresponding to each original document in the original document data. Based on a domain-driven design strategy, the original documents for different market categories are divided into subdomains, and a domain model corresponding to the original document data is constructed based on the subdomain division results. The domain model is mapped and implemented using preset test components, and configured in a graphical user interface. Document test data is generated based on the mapped test components and the graphical user interface. By constructing a domain model corresponding to the document data based on a domain-driven design strategy, the inherent feature relationships of the document data can be automatically extracted and analyzed. Combined with test components, effective and accurate test document data can be constructed, thereby improving the efficiency of subsequent software testing.

[0092] Furthermore, the target system includes enterprise systems and financial institution systems; the determining module 301 is specifically used for:

[0093] Based on the business operation interface information of each target system, the bill data generated by the interaction between enterprise systems, the bill data generated by the interaction between enterprise systems and financial institution systems, and the bill data generated by the interaction between financial institution systems are obtained respectively, and used as the original bill data generated by the interaction between target systems.

[0094] Furthermore, the determining module 301 may include:

[0095] The stage determination unit is used to determine the transaction stage of the original invoice based on the business activities of the original invoice.

[0096] The category determination unit is used to classify the original bills into markets based on the transaction process and the target system type involved in the original bills, and to determine the market category corresponding to the original bills.

[0097] Furthermore, the category determination unit is specifically used for:

[0098] If the target system type involved in the original invoice includes an enterprise system, and the business activities in the transaction belong to the primary market, then the market category corresponding to the original invoice is determined to be the primary market.

[0099] If the target system type involved in the original bill is a financial institution system, and the business activities in the transaction belong to the secondary market, then the market category corresponding to the original bill is determined to be the secondary market.

[0100] Furthermore, building module 302 may include:

[0101] The division unit is used to determine that the original notes in the primary market are primary market original notes, and to divide the primary market original notes into at least two note sub-domains, and to determine the circulation subject of each note sub-domain;

[0102] Service building units are used to construct subdomain value objects and subdomain entities based on the static and dynamic attributes of the flow subject, and to construct domain events and domain services based on business behavior and business flow information.

[0103] The model building unit is used to construct the domain model corresponding to the original invoice data based on subdomain entities, subdomain value objects, domain events, and domain services.

[0104] Furthermore, the division unit is specifically used for:

[0105] The primary market original bills are divided into the core subdomain of ordinary electronic bills, the credit approval support subdomain, and the general subdomain of bill products.

[0106] The circulation entity of the core subdomain of ordinary electronic bills is determined to be the bill itself; the circulation entity of the credit approval support subdomain is determined to be the approval order; and the circulation entity of the general subdomain of bill products is determined to be the bill batch.

[0107] Example 4

[0108] Figure 4 This is a schematic diagram of the structure of the electronic device provided in Embodiment 4 of the present invention. Figure 4 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0109] like Figure 4As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0110] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0111] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the ticket data generation method.

[0112] In some embodiments, the invoice data generation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the invoice data generation method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the invoice data generation method by any other suitable means (e.g., by means of firmware).

[0113] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0114] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0115] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0116] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0117] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0118] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0119] In one embodiment, the present invention further includes a computer program product, which includes a computer program that, when executed by a processor, implements the invoice data generation method of any embodiment of the present invention.

[0120] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural 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 it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0121] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0122] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for generating invoice data, characterized in that, include: In response to the request to generate invoice data, the system obtains the original invoice data generated by the interaction between the target systems based on the business operation interface information of each target system, and determines the market category corresponding to each original invoice in the original invoice data. Based on the domain-driven design strategy, the original invoices of different market categories are divided into subdomains, and the domain model corresponding to the original invoice data is constructed according to the subdomain division results. The domain model is mapped and implemented using preset test components, and configured in the graphical user interface to generate ticket test data based on the mapped test components and graphical user interface.

2. The method according to claim 1, characterized in that, in, The target systems include enterprise systems and financial institution systems; Accordingly, based on the business operation interface information of each target system, the raw invoice data generated by the interaction between the target systems is obtained, including: Based on the business operation interface information of each target system, the bill data generated by the interaction between enterprise systems, the bill data generated by the interaction between enterprise systems and financial institution systems, and the bill data generated by the interaction between financial institution systems are obtained respectively, and used as the original bill data generated by the interaction between target systems.

3. The method according to claim 1, characterized in that, Determine the market category corresponding to the original notes, including: Based on the business activities involved in the original document, determine the transaction stage in which the original document is located; Based on the transaction process and the target system type involved in the original bill, the original bill is segmented into markets to determine the corresponding market category.

4. The method according to claim 3, characterized in that Based on the transaction process and the type of target system involved in the original bills, the original bills are segmented into market categories to determine their corresponding market classes, including: If the target system type involved in the original invoice includes an enterprise system, and the business activities in the transaction belong to the primary market, then the market category corresponding to the original invoice is determined to be the primary market. If the target system type involved in the original bill is a financial institution system, and the business activities in the transaction belong to the secondary market, then the market category corresponding to the original bill is determined to be the secondary market.

5. The method according to claim 1, characterized in that, Based on the domain-driven design strategy, the original invoices of different market categories are divided into subdomains, and the domain model corresponding to the original invoice data is constructed according to the subdomain division results. The original notes that are identified as being in the primary market are classified as primary market original notes. The primary market original notes are then divided into at least two note sub-domains, and the circulation entities of each note sub-domain are identified. Based on the static and dynamic attributes of the transfer subject, subdomain value objects and subdomain entities are constructed respectively, and domain events and domain services are built based on business behavior and business transfer information. Based on subdomain entities, subdomain value objects, domain events, and domain services, construct the domain model corresponding to the original invoice data.

6. The method according to claim 5, characterized in that, The original bills in the primary market are divided into at least two bill sub-domains, and the circulation entities of each bill sub-domain are identified, including: The primary market original bills are divided into the core subdomain of ordinary electronic bills, the credit approval support subdomain, and the general subdomain of bill products. The circulation entity of the core subdomain of ordinary electronic bills is determined to be the bill itself; the circulation entity of the credit approval support subdomain is determined to be the approval order; and the circulation entity of the general subdomain of bill products is determined to be the bill batch.

7. A bill data generation device, characterized in that, include: The determination module is used to respond to the bill data generation request, obtain the original bill data generated by the interaction between the target systems based on the business operation interface information of each target system, and determine the market category corresponding to each original bill in the original bill data; The module is used to divide the original invoices of different market categories into subdomains based on the domain-driven design strategy, and to build the domain model corresponding to the original invoice data based on the subdomain division results. The generation module is used to map the domain model through preset test components and configure it in the graphical user interface to generate ticket test data based on the mapped test components and graphical user interface.

8. An electronic device, characterized in that, The electronic device includes: at least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that is executed by the at least one processor to enable the at least one processor to perform the invoice data generation method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the invoice data generation method of any one of claims 1-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 invoice data generation method according to any one of claims 1-6.

Images