Method, electronic device and computer readable medium for testing a payment system

Abstract

The application discloses a method for testing a payment system, an electronic device and a computer readable medium, generating a plurality of vertices corresponding to fund processing nodes in a business process one by one, adding cross-node directed edges between the vertices according to the calling relationship between the nodes, obtaining a business graph model corresponding to the business process; adding business line labels and UUIDs to each vertex and each cross-node directed edge; adding cross-business directed edges between each business graph model according to the calling relationship between a plurality of business processes and arranging fund links, obtaining a fund link graph model corresponding to the payment system; adding combined business line labels and UUIDs to each cross-business directed edge; based on the fund link graph model, calling stored test data to test the updated business graph model, obtaining a global test result; the test data carries the business line label and the UUID; the global test result is visually displayed to determine the abnormal fund processing node and the affected fund link.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cross-border payment, in particular to a method for testing a payment system, an electronic device and a computer readable medium. BACKGROUND

[0002] In the field of cross-border payment, the fund link is usually distributed in different regions and different business lines. Due to data isolation and multi-subject reasons, the fund processing logic between different business lines has great differences. The actual receipt amount of foreign trade funds is easily affected by exchange rate and channel commission because the fund link is relatively long, the risk coefficient of the fund link is high, and in order to meet the development needs of the business, the frequency of changes of new requirements of backend code is high. The traditional cross-border payment test method has many problems such as non-uniform risk definition, scattered test case management, insufficient compatibility evaluation, and weak fund link control. SUMMARY

[0003] The present application aims to solve one of the technical problems in the related art to some extent. To this end, the present application provides a method for testing a payment system, an electronic device and a computer readable medium.

[0004] As a first aspect of the present application, a method for testing a payment system is provided, the payment system comprising a plurality of business processes, wherein the method comprises:

[0005] For any of the business processes, a plurality of vertices corresponding one-to-one to a plurality of fund processing nodes in the business process are generated, and cross-node directed edges are added between the vertices according to the calling relationship between the plurality of fund processing nodes, to obtain a business graph model corresponding to the business process;

[0006] A business line label and a universally unique identifier (UUID) are added to each of the vertices and the cross-node directed edges, wherein the business line label is used to identify the business line to which it belongs, and different business line labels are associated with different user viewing permissions, and the UUID is used to associate pre-set test data;

[0007] According to the calling relationship between the plurality of business processes, cross-business directed edges are added between the plurality of business graph models, and the plurality of business graph models are arranged in a fund link, to obtain a fund link graph model corresponding to the payment system;

[0008] A combined business line label and a universally unique identifier (UUID) are added to each of the cross-business directed edges;

[0009] Based on the fund link graph model, the stored test data is called to test the updated business graph model, to obtain a global test result; wherein the test data carries a business line label and a universally unique identifier (UUID).

[0010] visualizing the global test result to determine the abnormal fund processing node and the fund link affected thereby.

[0011] Optionally, the adding of the cross-business directed edges between the business graph models and the arrangement of the fund link among the business graph models according to the calling relationship among the plurality of business processes to obtain the fund link graph model corresponding to the payment system comprises:

[0012] According to the calling relationship among the plurality of business processes, cross-business directed edges are added to the cross-business vertex pairs corresponding to the cross-business process node pairs in the plurality of business graph models, and a weight parameter is configured for the cross-business directed edges according to the calling frequency to form a global basic calling graph.

[0013] By modifying the weight parameters of the cross-business directed edges in the global basic calling graph according to the preset optimization data, a global performance graph, a global reliability graph, a global test complexity graph and a global change sensitivity graph are obtained.

[0014] According to the global basic calling graph, the global performance graph, the global reliability graph, the global test complexity graph and the global change sensitivity graph, a global composite graph is constructed.

[0015] Based on the global composite graph, an optimal execution order between vertices in the global basic calling graph is solved by a preset convex optimization model to obtain the fund link graph model corresponding to the payment system.

[0016] Optionally, the preset convex optimization model comprises an objective function and a constraint condition, the constraint condition comprises a dependency relationship constraint condition, a resource constraint condition and a time constraint condition, and the objective function is represented by the following formula:

[0017] Min f(path) = (test cost) + (uncovered risk) - (value benefit);

[0018] Min f(path) represents the minimized total execution time or resource consumption, 、 、 respectively represent the weights corresponding to the test cost, the uncovered risk and the value benefit, the test cost is determined according to the global basic calling graph and the global test complexity graph, the uncovered risk is determined according to the global reliability graph and the global change sensitivity graph, and the value benefit is determined according to the global basic calling graph and the global performance graph. ​​​

[0019] Optionally, the optimal execution order between vertices in the global base call graph is solved by a preset convex optimization model based on the global composite graph, and the fund link graph model corresponding to the payment system is obtained, including:

[0020] The cross-business vertices and cross-business directed edges in the global composite graph are preprocessed according to the unstructured original data corresponding to the global composite graph; wherein the preprocessing includes correction processing and / or completion processing;

[0021] The preprocessed global composite graph is converted into an undirected graph;

[0022] The undirected graph is colored by using the four-color theorem and a preset algorithm, so that all adjacent vertices in the undirected graph have different colors and each color corresponds to a group of vertices that can be executed in parallel;

[0023] According to the constraint condition of the convex optimization model, the parallel execution grouping result obtained by coloring is used as a resource allocation basis to determine the optimal execution order between vertices in the global base call graph corresponding to the minimum value of the objective function, and the fund link graph model corresponding to the payment system is obtained.

[0024] Optionally, based on the fund link graph model, the stored test data is called to test the updated business graph model, and a global test result is obtained, including:

[0025] The stored test data is obtained according to the universal unique identifier UUID of the target; wherein the universal unique identifier UUID of the target includes the universal unique identifier UUID carried by the vertices and directed edges in the updated business graph model, the test data has a high priority or a low priority, the test data with a high priority is stored in a database through a remote dictionary service redis cache, and the test data with a low priority is stored in the redis cache;

[0026] The obtained test data is input into the corresponding vertices in the fund link graph model according to the business line label and the universal unique identifier UUID, so as to execute the corresponding processing algorithm, and a global test result is obtained.

[0027] Optionally, the global test result includes: the fund link formed by the vertices and directed edges carrying the universal unique identifier UUID of the target, and the attribute information of the vertices and directed edges carrying the universal unique identifier UUID of the target;

[0028] The attribute information of the vertex includes a type of a corresponding fund processing node, an amount, a currency, a timestamp, a processing state, and a transaction state, the type of the fund processing node includes at least one of a payment node, a clearing node, and a settlement node, the processing state includes a processed state or a to-be-processed state, and the transaction state includes a transaction success state or a transaction failure state.

[0029] Optionally, after the combined business line label and the universal unique identifier (UUID) are added to each of the cross-business directed edges, the method further includes:

[0030] Identifying a high-risk fund link in the fund link graph model;

[0031] Setting a corresponding risk data model for each vertex and each directed edge in the high-risk fund link, wherein the risk data model includes a trigger condition;

[0032] In a case where the trigger condition is met, determining a business graph model corresponding to the high-risk fund link as an updated business graph model.

[0033] Optionally, the risk data model further includes an access condition, an exit condition, and a risk rule verification script, and the method further includes:

[0034] For any vertex or any directed edge in the high-risk fund link, by executing the risk rule verification script, matching corresponding attribute information with the access condition and the exit condition corresponding to the vertex or the directed edge, to obtain a corresponding risk verification result;

[0035] Generating a risk verification report according to the risk verification results of the vertices and the directed edges in the high-risk fund link.

[0036] As a second aspect of the present application, an electronic device is provided, wherein the electronic device includes:

[0037] One or more processors;

[0038] A memory having one or more computer programs stored thereon, when the one or more computer programs are executed by the one or more processors, the one or more processors implement the method for testing a payment system according to the first aspect of the present application.

[0039] As a third aspect of the present application, a computer readable medium having a computer program stored thereon is provided, wherein the computer program is executed by a processor to implement the method for testing a payment system according to the first aspect of the present application.

[0040] The method for testing the payment system provided in the application adds a business line label and a UUID to each fund processing node (vertex) and calling relationship (directed edge), wherein the UUID is used as a full-link unique identifier and can be used throughout the full process of fund transaction from initiation to completion, ensuring that the risk nodes of each transaction can be uniquely tracked, and the business line label is used to explicitly classify fund links of different business lines and regions. This standardized identification method can uniformly classify and model risk points of fund links scattered in different business lines and different countries, avoid risk definition confusion caused by business line differences, and realize centralized analysis and unified management of high-risk links in all business lines.

[0041] By constructing a unified business graph model and a fund link graph model, test data of each business process is stored in association through the UUID, and the test data is managed in partitions through the business line label. Meanwhile, the combined label design of the cross-business directed edge enables the middle platform to uniformly manage the models and test data of each business line from a global perspective, avoids the isolated state of test cases scattered in each business line, and improves the reusability and management efficiency of test resources.

[0042] When the business graph model is updated, the influence of the updated model on other associated business processes is automatically identified based on the association relationship (cross-business directed edge) of the fund link graph model. Since each node and link forms a clear dependency relationship through the UUID and the business line label, the affected fund processing nodes and associated links can be quickly located when the business changes, and the specific influence on other business lines can be accurately informed, solving the compatibility evaluation missing problem caused by business line isolation in the traditional method and reducing the risk of cross-business line changes.

[0043] By constructing the fund link graph model and visually displaying the global test results, the state of the fund at each processing node (for example, the fund processing node with an abnormality and the fund link affected thereby) can be directly presented. In combination with the association of the test data by the UUID, the fund node, path and state can be tracked in real time, the control over long fund links is enhanced, and transparent monitoring of the full process of fund circulation is realized. BRIEF DESCRIPTION OF DRAWINGS

[0044] The application will be further described below with reference to the accompanying drawings:

[0045] Figure 1 is a flowchart of one embodiment of the method for testing the payment system provided in the embodiment of the application;

[0046] Figure 2 is a flowchart of another embodiment of the method for testing the payment system provided in the embodiment of the application;

[0047] Figure 3is a flowchart of still another embodiment of the method for testing a payment system provided by the embodiments of the present application;

[0048] Figure 4 is a flowchart of still another embodiment of the method for testing a payment system provided by the embodiments of the present application;

[0049] Figure 5 is a flowchart of still another embodiment of the method for testing a payment system provided by the embodiments of the present application;

[0050] Figure 6 is a flowchart of still another embodiment of the method for testing a payment system provided by the embodiments of the present application;

[0051] Figure 7 is a module diagram of an embodiment of the electronic device provided by the embodiments of the present application;

[0052] Figure 8 is a schematic diagram of the computer readable medium provided by the embodiments of the present application;

[0053] Explanation of reference signs

[0054] 101: processor; 102: memory; 103: I / O interface; 104: bus. DETAILED DESCRIPTION

[0055] Embodiments of the present application are described in detail below with reference to the accompanying drawings. Examples of the embodiments are shown in the drawings, in which the same or similar reference signs represent the same or similar elements or elements having the same or similar functions throughout. Based on the embodiments in the embodiments, it is intended to explain the present application, and cannot be understood as a limitation of the present application.

[0056] In this specification, "one embodiment" or "an example" or "an example" means that a particular feature, structure, or characteristic described in connection with the embodiment itself can be included in at least one embodiment of the present disclosure. The appearance of the phrase "in one embodiment" at various places in the specification does not necessarily refer to the same embodiment.

[0057] In the field of cross-border payment, the fund link is usually distributed in different regions and different business lines. Due to data isolation and multi-subjects, there are great differences in fund processing logic between different business lines. The actual amount of foreign trade funds is easily affected by exchange rate and channel handling fee due to the long fund link, and the risk coefficient of the fund link is high. In order to meet the development needs of the business, the frequency of changes in new requirements for back-end code is high. The traditional cross-border payment test method has the following problems:

[0058] 1. Risk definition is not uniform: due to different characteristics of different regions, the actual fund transaction passes through different links, so the definition of high-risk links will be different, resulting in the omission of risk problems;

[0059] 2. Test case management is scattered: there is a lack of unified test case management between different business lines, and the test scenarios and test tools corresponding to high-risk fund business are scattered;

[0060] 3. Insufficient compatibility evaluation: business development is fast, and it is difficult to conduct comprehensive compatibility evaluation of requirements and changes, which may easily lead to changes in one business line affecting other business lines;

[0061] 4. Weak control of fund link: the fund link is long, and the control of the fund on the whole link is insufficient, which cannot quickly reflect the current state of the fund.

[0062] Therefore, the applicant of the present application proposes a method for testing a payment system, the payment system comprising a plurality of business processes, as shown in Figure 1 The method comprises:

[0063] Step S110, for any of the business processes, a plurality of vertices corresponding one-to-one to a plurality of fund processing nodes in the business process are generated, and cross-node directed edges are added between the vertices according to the calling relationship between the plurality of fund processing nodes, to obtain a business graph model corresponding to the business process;

[0064] Step S120, business line labels and universally unique identifiers (UUIDs) are added to each of the vertices and each of the cross-node directed edges, wherein the business line labels are used to identify the business line to which they belong and different business line labels are associated with different user viewing permissions, and the UUIDs are used to associate pre-set test data;

[0065] Step S130, according to the calling relationship between the plurality of business processes, cross-business directed edges are added between the business graph models, and the plurality of business graph models are arranged in a fund link, to obtain a fund link graph model corresponding to the payment system;

[0066] Step S140, combined business line labels and universally unique identifiers (UUIDs) are added to each of the cross-business directed edges;

[0067] Step S150, based on the fund link graph model, stored test data is called to test the updated business graph model, to obtain a global test result; wherein the test data carries a business line label and a universally unique identifier (UUID);

[0068] Step S160, the global test result is visualized to determine the abnormal fund processing node and its affected fund link.

[0069] The business flow refers to the fund processing flow of different business lines (e.g., different countries) in the payment system, including the complete fund transfer link from initiation to completion. It can be understood that due to differences in regions, compliance, etc., the business flow between different business lines may differ.

[0070] The cross-node directed edge is used to represent the call or dependency relationship between different fund processing nodes. For example, if node A depends on node B, there is a directed edge from B to A. The cross-node directed edge can reflect the business logic order between nodes and is an important element in building a business graph model.

[0071] The business graph model refers to the abstract modeling of a single business flow, which is composed of the fund processing nodes (vertices) corresponding to the business flow and the call relationship between nodes (cross-node directed edges), and is used to represent the fund transfer logic of the business flow.

[0072] The business line label is used to identify the region or type of the business line, such as the label CN for China business, the label AP for Asia-Pacific business, the label AF for Africa business, and the label AM for American business. Different labels are associated with different viewing permissions of operation personnel. Operation personnel in each region can add, delete, modify, and query test cases in the corresponding region according to reason information.

[0073] The universally unique identifier (UUID) is a unique identifier throughout the fund transaction chain, ensuring that each fund transaction can be uniquely tracked from initiation to completion. Test data carries the UUID, which is used to associate data and achieve full-process traceability, avoiding confusion between different transaction data (i.e., avoiding cross-table).

[0074] The cross-business directed edge is used to represent the call relationship between different business flows and is a directed edge added between business graph models, which is used to arrange fund links between multiple business graph models and build the global fund link relationship of the payment system.

[0075] The combined business line label is a label carried by the cross-business directed edge, which is composed of the business line labels of multiple business flows connected by the cross-business directed edge, and is used to identify the multiple business lines to which the cross-business call relationship belongs.

[0076] The fund link graph model refers to the global model formed by arranging fund links between multiple business graph models through cross-business directed edges. It integrates the fund transfer relationship of multiple business flows in the payment system and can reflect the fund link logic of the entire system.

[0077] The global test result refers to a result obtained after testing based on the fund link diagram model, the specific path of the fund, the node and the state of the fund can be determined by reading the model instance where the UUID is located, and the fund processing node and the fund link affected by the fund processing node can be visually displayed on the front-end page to determine the abnormal fund processing node and the fund link affected by the fund processing node.

[0078] The method for testing the payment system provided by the embodiment of the application adds a business line label and a UUID to each fund processing node (vertex) and a calling relationship (directed edge), the UUID is used as a unique identifier of the whole link, can be throughout the whole process of the fund transaction from initiation to termination, and ensures that the risk node of each transaction can be uniquely tracked, and the business line label is used for classifying the fund links of different business lines and regions. The standardized identification method can classify and model the risk points of the fund links scattered in different business lines and different countries, avoid the confusion of risk definition caused by the difference between business lines, and realize the centralized analysis and unified management of the high-risk links of the whole business line.

[0079] The test data of each business process is stored through the UUID, and the test data is managed by the business line label. Meanwhile, the combined label design of the cross-business directed edge enables the middle platform to uniformly manage the model and the test data of each business line from a global perspective, avoids the isolated state of the test cases scattered in each business line, and improves the reusability and management efficiency of the test resources.

[0080] When the business graph model is updated, the influence of the updated model on other associated business processes is automatically identified based on the associated relationship (cross-business directed edge) of the fund link diagram model. Since each node and link forms a clear dependency relationship through the UUID and the business line label, the affected fund processing node and associated link can be quickly located when the business is changed, and the specific influence on other business lines is accurately informed, thereby solving the compatibility evaluation missing problem caused by the isolation of business lines in the traditional method and reducing the risk of cross-business line change.

[0081] The fund link diagram model is constructed, and the global test result is visually displayed, so that the state of the fund at each processing node (for example, the fund processing node with an abnormal state and the fund link affected by the fund processing node) can be intuitively presented. In combination with the association of the test data by the UUID, the node, path and state of the fund can be tracked in real time, the control of the long fund link is enhanced, and the transparent monitoring of the whole process of the fund circulation is realized.

[0082] In addition, the embodiments of the present application do not make special limitations on the specific organizational structure used to implement the provided method. For example, a client and server dual-site deployment architecture can be used to provide a near-end package for the servers of the business line, the server is responsible for the core model data storage (such as the fund link diagram model and test data storage) and business logic processing (such as the full link tracking associated with the UUID), the client is responsible for user interaction (such as test operation and front-end visual display), and the near-end package (Software Development Kit (SDK) or Application Programming Interface (API) library) can simplify the access process of each business line server, and ensure that the business graph model of different business lines can be effectively constructed and accessed to the unified system. In addition, a unified platform can be built from the perspective of the middle platform, and the established business graph model, fund link diagram model and test data are managed and unified in the database from the perspective of the middle platform, ensuring that the addition of cross-business directed edges and the link arrangement of multi-business processes can be realized based on unified model and data standards, and the visual display of the global test results of the unified front-end site provides a carrier, so that each business line test can be realized through the front-end abnormal node and impact link results.

[0083] In some embodiments, the cross-business directed edges are added between the business graph models according to the calling relationship between the plurality of business processes, and the fund link arrangement of the plurality of business graph models is performed to obtain the fund link diagram model corresponding to the payment system (i.e. involved in step S130), as shown in Figure 2

[0084] Step S210, according to the calling relationship between the plurality of business processes, adding cross-business directed edges between the plurality of business graph models for the cross-business vertex pair corresponding to the cross-business process node pair, and configuring a weight parameter for the cross-business directed edge according to the calling frequency, to form a global basic calling graph;

[0085] Step S220, by modifying the weight parameter of each cross-business directed edge in the global basic calling graph according to the preset optimization data, obtaining a global performance graph, a global reliability graph, a global test complexity graph and a global change sensitivity graph;

[0086] Step S230, constructing a global composite graph according to the global basic calling graph, the global performance graph, the global reliability graph, the global test complexity graph and the global change sensitivity graph;

[0087] ​Step S240, based on the global composite graph, solving the optimal execution order between each vertex in the global base call graph through a preset convex optimization model, and obtaining the fund link graph model corresponding to the payment system.

[0088] Wherein, the preset optimization data includes: runtime monitoring data, test history data, and related information in the version control system. The global base call graph (hereinafter referred to as ) is constructed by analyzing static code, the global performance graph (hereinafter referred to as ) and the global reliability graph (hereinafter referred to as ) are constructed by runtime monitoring data, the global test complexity graph (hereinafter referred to as ) is constructed by test history data, and the global change sensitivity graph (hereinafter referred to as ) is constructed by related information in the version control system.

[0089] Wherein, it can be understood that a directed graph (Directed Graph) is composed of a vertex set V and a directed edge set E, denoted as G=(V,E). The directed edge has a clear direction, represented as an ordered pair (u,v), where u is the starting point and v is the terminal point. This corresponds to the calling relationship in the payment system, and the caller points to the callee. The weighted graph (Weighted Graph) means that each edge in the graph is associated with a weight value, and these weights can represent quantitative indicators such as call frequency, response time, and dependency strength. The path (Path) is a series of consecutive edges from vertex u to vertex v. In payment system calls, the path represents a complete call chain from the entry point to the final processing component. Connectivity (Connectivity) means that if there is a path from any vertex in the graph to another vertex, the graph is called connected, which reflects the reachability between services in the payment system.

[0090] Wherein, =(V,E,W), V is the set of all fund processing nodes, E is the set of directed edges between fund processing nodes, and W is the edge weight function (i.e. the weight parameter of the edge) representing the call frequency, is the most basic mapping, capturing all possible static call relationships in the system, providing a basis for other specialized graphs. =(V,E,W_perf), W_perf is the edge weight function representing the average response time or delay, focuses on system performance characteristics, and is used to identify performance bottlenecks and performance concerns in optimization testing. =(V,E,W_rel), W_rel is the edge weight function representing the call failure rate or error probability, is used for reliability analysis to identify vulnerable points and error propagation paths in the system. =(V, E, W_test), W_test is an edge weight function representing test complexity or test cost, to help evaluate the test difficulty of different invocation paths and optimize test resource allocation. =(V, E, W_change), W_change is an edge weight function representing code change frequency or recent modification time, to reflect the dynamic evolution characteristics of the system and guide the incremental testing strategy.

[0091] Static code refers to the source code and code structure information of the payment system in a non-running state, including code text of modules corresponding to each business process, static call relationship definition between modules, and other non-runtime code-related data. Runtime monitoring data refers to real-time recorded data related to module invocation during the running of the payment system, including average response time, processing delay, and number of invocation failures, error occurrence probability, and other real-time monitoring information. Test history data refers to historical record data accumulated during past testing of the payment system, including test difficulty evaluation results of each invocation path, and resource (such as time, manpower) consumption statistics during testing, and other information related to historical testing activities. Related information in the version control system refers to code change-related record information stored in the version control system, including the number of code modifications, the timestamp of each modification, and the code change content between different versions, and other information reflecting code update frequency and time.

[0092] The present application analyzes the payment system from the perspective of graph theory, which can convert complex invocation relationships into structured mathematical models, so as to apply mature graph algorithms to solve problems such as test path planning, performance optimization, and architecture evaluation. This method not only provides a global view of the payment system structure, but also reveals problems that traditional analysis methods cannot find.

[0093] In some embodiments, the preset convex optimization model includes an objective function and constraint conditions, the constraint conditions include dependency relationship constraint conditions, resource constraint conditions, and time constraint conditions, and the objective function is represented by the following formula:

[0094] Min f(path)= (test cost) + (uncovered risk) - (value benefit);

[0095] wherein Min f(path) represents the minimized total execution time or resource consumption, 、 、 respectively represent a test cost, the uncovered risk, and a weight corresponding to the value benefit, the test cost is determined according to the global basic call graph and the global test complexity graph, the uncovered risk is determined according to the global reliability graph and the global change sensitivity graph, and the value benefit is determined according to the global basic call graph and the global performance graph.

[0096] In the embodiments of the present application, the dependency constraints, the resource constraints, and the time constraints are not specifically limited. For example, the dependency constraints can be made according to the dependency relationship between nodes and the dependency relationship between business processes, for example, business process A must be executed after the business process B on which it depends; the resource constraints can be made according to the central processing unit (CPU) limit, the memory limit, and the like; and the time constraints can be made according to the latest completion time requirement of certain business processes.

[0097] In addition, it can be understood that in the embodiments of the present application, new data can also be collected during test execution, the graph model weight is continuously updated, the graph model accuracy is continuously improved, and the allocation of the remaining test resources is continuously optimized.

[0098] In some embodiments, based on the global composite graph, an optimal execution order between vertices in the global basic call graph is solved by a preset convex optimization model, and a fund link graph model corresponding to the payment system (i.e., involved in step S240) is obtained, as shown in Figure 3 may include:

[0099] In step S310, the cross-business vertices and the cross-business directed edges in the global composite graph are preprocessed according to the unstructured original data corresponding to the global composite graph; wherein the preprocessing includes correction processing and / or completion processing.

[0100] In step S320, the preprocessed global composite graph is converted into an undirected graph.

[0101] In step S330, the four-color law and a preset algorithm are used to color the undirected graph, so that all adjacent vertices in the undirected graph have different colors and each color corresponds to a vertex group that can be executed in parallel.

[0102] In step S340, according to the constraint condition of the convex optimization model, the parallel execution grouping result obtained by coloring is taken as a resource allocation basis, the optimal execution order between vertices in the global basic call graph corresponding to the minimum value of the objective function is determined, and a fund link graph model corresponding to the payment system is obtained.

[0103] Among them, the embodiments of the present application do not make specific limitations on the unstructured original data corresponding to the global composite graph, but at least include preset optimization data (i.e. static code, runtime monitoring data, test history data, and related information in the version control system).

[0104] Among them, the embodiments of the present application do not make specific limitations on the correction processing, for example, it can be an outlier detection, which uses the local structural features on the graph to identify abnormal data points. The embodiments of the present application do not make specific limitations on the completion processing, for example, it can be a missing value processing, which completes data based on the topological structure of the graph and the similarity of nodes.

[0105] Among them, the embodiments of the present application do not make specific limitations on the preset algorithm, for example, it can be a greedy algorithm or a backtracking algorithm.

[0106] In some embodiments, the stored test data is called to test the updated business graph model to obtain a global test result (i.e. involved in step S150), as shown in Figure 4 , which can include:

[0107] Step S410, obtaining stored test data according to the universal unique identifier UUID of the target; wherein the universal unique identifier UUID of the target includes the universal unique identifier UUID carried by the vertex and directed edge in the updated business graph model, and the test data has a high priority or a low priority, the test data with a high priority is stored in a database through a remote dictionary service (Remote Dictionary Server, Redis) cache, and the test data with a low priority is stored in a redis cache;

[0108] Step S420, inputting the obtained test data according to the business line label and the universal unique identifier UUID to the corresponding vertex in the fund link graph model to execute the corresponding processing algorithm to obtain a global test result.

[0109] Among them, the test data with a high priority means that it has a higher importance, and the test data with a low priority means that it has a lower importance. The embodiments of the present application are not limited to using redis as a distributed cache middleware, but also can use a memory cache daemon (Memory Cache Daemon, Memcached) as a distributed cache middleware. By deploying a distributed cache middleware, data access speed can be provided, and UUID can be recorded in each process of fund transaction to realize full-process traceability and cache key transaction data, reduce database pressure and improve response speed.

[0110] In addition, the test data stored in the distributed cache middleware and the database can also be time-tagged to realize the playback function, solving the problem of non-recording in the traditional way.

[0111] In some embodiments, the global test result includes: a fund link formed by a vertex carrying a universal unique identifier (UUID) of the target and a directed edge, and attribute information of the vertex and the directed edge each carrying the universal unique identifier (UUID) of the target;

[0112] The attribute information of the vertex includes a type of a corresponding fund processing node, an amount, a currency, a timestamp, a processing state, and a transaction state, the type of the fund processing node includes at least one of a payment node, a clearing node, and a settlement node, the processing state includes a processed state or a to-be-processed state, and the transaction state includes a transaction success state or a transaction failure state.

[0113] By recording the attribute information of the vertex (including fund element information, etc.), when finally visualizing the global test result, the fund state such as the fund link, the card number, the amount, the currency, etc. can be displayed in real time through graphical rendering.

[0114] In some embodiments, after the combination business line label and the universal unique identifier (UUID) are added to each cross-business directed edge (i.e., involved in step S140), as shown in Figure 5 The method can further include:

[0115] Step S510: identifying a high-risk fund link in the fund link graph model;

[0116] Step S520: setting a corresponding risk data model for each vertex and each directed edge in the high-risk fund link; wherein the risk data model includes a trigger condition.

[0117] Step S530: determining a business graph model corresponding to the high-risk fund link as an updated business graph model when the trigger condition is met.

[0118] In the embodiments of the present application, when the trigger condition of the identified high-risk fund link is met, the corresponding business graph model can be determined as an updated business graph model, so as to test it.

[0119] In some embodiments, the risk data model further includes an access condition, an exit condition, and a risk rule verification script; as shown in Figure 6 The method can further include:

[0120] Step S610: For any vertex or directed edge in the high-risk capital link, the risk rule verification script is executed to match the corresponding attribute information with the corresponding entry and exit conditions to obtain the corresponding risk verification result;

[0121] Step S620: Generate a risk verification report based on the risk verification results of each vertex and each directed edge in the high-risk capital link.

[0122] The embodiment of the present application does not specifically limit the type of the risk rule verification script. For example, it can be a Groovy script.

[0123] By setting trigger conditions to trigger risk rule verification, the corresponding risk rule verification script runs, retrieves the risk data model data table, and maps the risk points that trigger the risk rules to different business lines, thereby generating a risk verification report. For each business line, by querying the database in the table, you can obtain the specific risks and countermeasures for the corresponding business line.

[0124] As a second aspect of the embodiment of the present application, an electronic device is provided, wherein, Figure 7 As shown, the electronic device includes:

[0125] One or more processors 101;

[0126] The memory 102 stores one or more computer programs. When the one or more computer programs are executed by the one or more processors 101, the one or more processors 101 implement the method for testing the payment system provided in the first aspect of the embodiment of the present application.

[0127] The electronic device may further include one or more I / O interfaces 103 connected between the processor 101 and the memory 102 and configured to implement information exchange between the processor 101 and the memory 102 .

[0128] Among them, the processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, and can realize information exchange between the processor and the memory, including but not limited to a data bus (Bus), etc.

[0129] In some embodiments, the processor 101, the memory 102 and the I / O interface 103 are connected with each other through the bus 104, and further connected with other components of the computing device.

[0130] As a third aspect of the embodiments of the present application, as shown in Figure 8 A computer readable medium having stored thereon a computer program is provided, wherein the computer program, when executed by a processor, implements the method for testing a payment system according to the first aspect of the embodiments of the present application.

[0131] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by a computer program instructing related hardware. Accordingly, the computer program can be stored in a non-volatile computer readable storage medium, and when executed, the computer program can implement the method of any one of the embodiments. In the embodiments provided by the present application, any reference to the memory, storage, database or other medium can include non-volatile and / or volatile memory. The non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. The volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM) and memory bus dynamic RAM (RDRAM), etc.

[0132] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Those skilled in the art should understand that the present application includes but is not limited to the contents described in the above specific embodiments and the accompanying drawings. Any modification that does not deviate from the functional and structural principles of the present application will be included in the scope of the claims.

Claims

1. A method for testing a payment system, wherein the payment system includes multiple business processes, characterized in that: The method comprises: For any of the business processes, generate multiple vertices corresponding one-to-one to multiple fund processing nodes in the business process, and add cross-node directed edges between the vertices based on the call relationships between the multiple fund processing nodes to obtain a business graph model corresponding to the business process; Add a business line label and a universally unique identifier (UUID) to each vertex and each cross-node directed edge, wherein the business line label is used to identify the business line to which it belongs and different business line labels are associated with viewing permissions of different users, and the UUID is used to associate with preset test data; According to the calling relationship between the multiple business processes, cross-business directed edges are added between the business graph models and the capital chain is orchestrated for the multiple business graph models to obtain a capital chain graph model corresponding to the payment system; Adding a combined business line label and a universally unique identifier (UUID) to each of the cross-business directed edges; Based on the capital link graph model, the stored test data is called to test the updated business graph model to obtain a global test result; wherein the test data carries the business line label and the universal unique identifier UUID; The global test results are visualized to determine the abnormal fund processing nodes and the fund links affected by them.

2. The method according to claim 1, characterized in that The method of adding cross-business directed edges between the business graph models based on the calling relationships between the multiple business processes and performing capital chain orchestration on the multiple business graph models to obtain a capital chain graph model corresponding to the payment system includes: According to the calling relationships between the plurality of business processes, in the plurality of business graph models, cross-business directed edges are added for cross-business vertex pairs corresponding to fund processing node pairs across the business processes, and weight parameters are configured for the cross-business directed edges according to the calling frequencies, so as to form a global basic call graph; By modifying the weight parameters of each cross-business directed edge in the global basic call graph according to preset optimization data, a global performance graph, a global reliability graph, a global test complexity graph, and a global change sensitivity graph are obtained; Constructing a global composite graph according to the global base call graph, the global performance graph, the global reliability graph, the global test complexity graph, and the global change sensitivity graph; Based on the global composite graph, the optimal execution order between the vertices in the global basic call graph is solved by a preset convex optimization model to obtain a capital link graph model corresponding to the payment system.

3. The method according to claim 2, characterized in that The preset convex optimization model includes an objective function and constraints, wherein the constraints include dependency constraints, resource constraints, and time constraints. The objective function is expressed by the following formula: Min f(path)= (Testing cost)+ (Uncovered Risk)- (value gain); Among them, Min f(path) represents the minimized total execution time or resource consumption, 、 、 They respectively represent the weights corresponding to the test cost, the uncovered risk, and the value benefit, the test cost is determined according to the global basic call graph and the global test complexity graph, the uncovered risk is determined according to the global reliability graph and the global change sensitivity graph, and the value benefit is determined according to the global basic call graph and the global performance graph.

4. The method according to claim 3, characterized in that The method of solving the optimal execution order between vertices in the global basic call graph based on the global composite graph by a preset convex optimization model to obtain a capital chain graph model corresponding to the payment system includes: Preprocessing the cross-business vertices and cross-business directed edges in the global composite graph according to the unstructured raw data corresponding to the global composite graph; wherein the preprocessing includes correction processing and / or completion processing; Convert the preprocessed global composite graph into an undirected graph; Coloring the undirected graph using the four-color rule and a preset algorithm so that all adjacent vertices in the undirected graph have different colors and each color corresponds to a vertex group that can be executed in parallel; According to the constraints of the convex optimization model, the parallel execution grouping results obtained by coloring are used as the basis for resource allocation, and the optimal execution order between the vertices in the global basic call graph corresponding to the minimum value of the objective function is determined to obtain the capital chain graph model corresponding to the payment system.

5. The method according to claim 1, wherein The method of testing the updated business graph model based on the capital link graph model by calling the stored test data to obtain a global test result includes: According to the target's universally unique identifier (UUID), stored test data is obtained; wherein the target's universally unique identifier (UUID) includes the universally unique identifier (UUID) carried by the vertices and directed edges in the updated business graph model, and the test data has a high priority or a low priority. The test data with a high priority is stored in the database via the remote dictionary service Redis cache, and the test data with a low priority is stored in the Redis cache. The acquired test data is input into the corresponding vertices in the capital chain graph model according to the business line label and the universal unique identifier UUID to execute the corresponding processing algorithm and obtain the global test results.

6. The method according to claim 5, characterized in that The global test result includes: the capital link formed by the vertices and directed edges carrying the universal unique identifier (UUID) of the target, and the attribute information of the vertices and directed edges carrying the universal unique identifier (UUID) of the target; The attribute information of the vertex includes the type, amount, currency, timestamp, processing status and transaction status of the corresponding funds processing node. The type of the funds processing node includes at least one of a payment node, a clearing node and a settlement node. The processing status includes a processed status or a pending status. The transaction status includes a successful transaction status or a failed transaction status.

7. The method according to any one of claims 1 to 6, characterized in that After adding a combined business line label and a universally unique identifier (UUID) to each of the cross-business directed edges, the method further includes: Identifying high-risk funding links in the funding link graph model; Setting a corresponding risk data model for each vertex and each directed edge in the high-risk capital link; wherein the risk data model includes a trigger condition; When the trigger condition is met, the business graph model corresponding to the high-risk capital link is determined as the updated business graph model.

8. The method according to claim 7, characterized in that The risk data model also includes entry conditions, exit conditions, and a risk rule verification script; the method further includes: For any vertex or directed edge in the high-risk capital link, by executing the risk rule verification script, the corresponding attribute information is matched with the corresponding entry and exit conditions to obtain the corresponding risk verification result; A risk verification report is generated based on the risk verification results of each vertex and each directed edge in the high-risk capital link.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; A memory having one or more computer programs stored thereon, wherein when the one or more computer programs are executed by the one or more processors, the one or more processors implement the method for testing a payment system according to any one of claims 1-8.

10. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for testing a payment system according to any one of claims 1 to 8 is implemented.

Images