CN117472782A

CN117472782A - Transaction testing method and device, storage medium and electronic equipment

Info

Publication number: CN117472782A
Application number: CN202311694541.4A
Authority: CN
Inventors: 范莉英; 朱俊豪; 李小琳; 杨如耀
Original assignee: Chongqing Ant Consumer Finance Co ltd
Current assignee: Chongqing Ant Consumer Finance Co ltd
Priority date: 2023-12-11
Filing date: 2023-12-11
Publication date: 2024-01-30

Abstract

The specification discloses a transaction testing method, a device, a storage medium and an electronic device, wherein the method comprises the following steps: the method comprises the steps of obtaining historical transaction data, performing feature extraction processing on the historical transaction data to generate transaction scene data, then performing case data construction on the transaction scene data through the historical transaction data to obtain transaction test cases corresponding to the transaction scene data, and finally testing a transaction platform by adopting the transaction test cases to obtain a test result.

Description

Transaction testing method and device, storage medium and electronic equipment

Technical Field

The present disclosure relates to the field of internet applications, and in particular, to a transaction testing method, a transaction testing device, a storage medium, and an electronic device.

Background

In recent years, with the continuous development of internet technology, various transactions are started to be changed from off-line to on-line. Under the data transaction scene, the transaction process of the transaction platform on various transactions often involves the circulation of funds, so that once the transaction platform fails, the risk of funds loss is caused.

Disclosure of Invention

The specification provides a transaction testing method, a transaction testing device, a storage medium and electronic equipment, wherein the technical scheme is as follows:

In a first aspect, the present specification provides a transaction testing method, the method comprising:

acquiring historical transaction data, performing feature extraction processing on the historical transaction data, and generating transaction scene data;

performing case data construction on the transaction scene data based on the historical transaction data to obtain a transaction test case corresponding to the transaction scene data;

the transaction test case is adopted to test the transaction platform, and a test result is obtained

In a second aspect, the present specification provides a transaction testing device, the device comprising:

the acquisition module is suitable for acquiring historical transaction data, performing feature extraction processing on the historical transaction data and generating transaction scene data;

the construction module is suitable for carrying out case data construction on the transaction scene data based on the historical transaction data to obtain a transaction test case corresponding to the transaction scene data;

and the test module is suitable for testing the transaction platform by adopting the transaction test case to obtain a test result.

In a third aspect, the present description provides a computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the above-described method steps.

In a fourth aspect, the present description provides an electronic device, which may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the above-mentioned method steps.

In a fifth aspect, the present description provides a computer program product storing at least one instruction for loading by a processor and performing the method steps of any one of the above

The technical scheme provided by some embodiments of the present specification has the following beneficial effects: the transaction test cases are generated by carrying out case data construction regeneration on historical transaction data based on each transaction scene data, and because the generation of the transaction test cases depends on real data, the transaction test cases can simulate the real data, and meanwhile, the transaction platform can be fully covered by testing the transaction based on the transaction test cases, so that the transaction platform can be tested more fully and effectively based on the transaction test cases, and the risk of problems of the transaction platform can be effectively reduced.

Drawings

In order to more clearly illustrate the technical solutions of the present specification or the prior art, the following description will briefly introduce the drawings that are required to be used in the embodiments or the prior art descriptions, it is obvious that the drawings in the following description are only some embodiments of the present specification, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a transaction testing system provided herein;

FIG. 2 is a schematic flow chart of a transaction testing method provided in the present specification;

FIG. 3 is a schematic flow chart of generating transaction scenario data provided in the present specification;

FIG. 4 is a schematic flow chart of determining a transaction test case provided in the present specification;

FIG. 5 is a schematic diagram of a combination of determining transaction test cases provided in the present specification;

FIG. 6 is a schematic flow chart of determining coverage information of a test case provided in the present specification;

FIG. 7 is a schematic diagram of an architecture for determining test case coverage information provided in the present specification;

FIG. 8 is a schematic flow chart of an update transaction test case provided in the present specification;

FIG. 9 is a schematic diagram of a transaction testing method provided in the present disclosure;

FIG. 10 is a schematic diagram of a transaction testing device according to the present disclosure;

fig. 11 is a schematic structural diagram of an electronic device provided in the present specification;

FIG. 12 is a schematic diagram of the architecture of the operating system and user space provided herein;

FIG. 13 is an architecture diagram of the android operating system of FIG. 12;

FIG. 14 is an architecture diagram of the IOS operating system of FIG. 12.

Detailed Description

The following description of the embodiments of the present invention will be made apparent from, and elucidated with reference to, the drawings of the present specification, in which embodiments described are only some, but not all, embodiments of the present specification. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

In the description of the present specification, it should be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. In the description of the present specification, it should be noted that, unless expressly specified and limited otherwise, "comprise" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus. The specific meaning of the terms in this specification will be understood by those of ordinary skill in the art in the light of the specific circumstances. In addition, in the description of the present specification, unless otherwise indicated, "a plurality" means two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship.

The present specification is described in detail below with reference to specific examples.

Referring to fig. 1, a schematic view of a scenario of a transaction testing system provided in the present specification is provided. As shown in fig. 1, the transaction testing system may include at least a client cluster and a service platform 100.

The client cluster may include at least one client, as shown in fig. 1, specifically including a client 1 corresponding to a user 1, a client 2 corresponding to a user 2, …, and a client n corresponding to a user n, where n is an integer greater than 0.

Each client in the client cluster may be a communication-enabled electronic device including, but not limited to: wearable devices, handheld devices, personal computers, tablet computers, vehicle-mounted devices, smart phones, computing devices, or other processing devices connected to a wireless modem, etc. Electronic devices in different networks may be called different names, for example: a user equipment, an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote terminal, a mobile device, a user terminal, a wireless communication device, a user agent or user equipment, a cellular telephone, a cordless telephone, a personal digital assistant (personal digital assistant, PDA), an electronic device in a 5G network or future evolution network, and the like.

The service platform 100 may be a separate server device, such as: rack-mounted, blade, tower-type or cabinet-type server equipment or hardware equipment with stronger computing capacity such as workstations, mainframe computers and the like is adopted; the server cluster may also be a server cluster formed by a plurality of servers, and each server in the server cluster may be formed in a symmetrical manner, wherein each server is functionally equivalent and functionally equivalent in a transaction link, and each server may independently provide services to the outside, and the independent provision of services may be understood as no assistance of another server is needed.

In one or more embodiments of the present description, the service platform 100 may establish a communication connection with at least one client in the client cluster, and complete data interaction during a transaction test process based on the communication connection, such as online transaction data interaction, for example, the service platform 100 may test the transaction platform based on a transaction test case obtained by the transaction test method of the present description.

It should be noted that, the service platform 100 establishes a communication connection with at least one client in the client cluster through a network for interactive communication, where the network may be a wireless network, or may be a wired network, where the wireless network includes, but is not limited to, a cellular network, a wireless local area network, an infrared network, or a bluetooth network, and the wired network includes, but is not limited to, an ethernet network, a universal serial bus (universal serial bus, USB), or a controller area network. In one or more embodiments of the specification, techniques and/or formats including HyperText Mark-up Language (HTML), extensible markup Language (Extensible Markup Language, XML), and the like are used to represent data exchanged over a network (e.g., target compression packages). All or some of the links may also be encrypted using conventional encryption techniques such as secure socket layer (Secure Socket Layer, SSL), transport layer security (Transport Layer Security, TLS), virtual private network (Virtual Private Network, VPN), internet protocol security (Internet Protocol Security, IPsec), and the like. In other embodiments, custom and/or dedicated data communication techniques may also be used in place of or in addition to the data communication techniques described above.

The embodiments of the transaction testing system provided in the present specification and the transaction testing method in one or more embodiments belong to the same concept, and an execution subject corresponding to the transaction testing method in one or more embodiments in the present specification may be the service platform 100 described above; the execution subject corresponding to the transaction testing method in one or more embodiments of the specification may also be an electronic device corresponding to the client, which is specifically determined based on an actual application environment. The implementation process of the transaction test system embodiment may be described in detail in the following method embodiment, which is not described herein.

Based on the schematic view of the scenario shown in fig. 1, a transaction testing method provided in one or more embodiments of the present disclosure is described in detail below.

Referring to fig. 2, fig. 2 is a flow chart of a transaction testing method provided in the present specification, which may be implemented by a computer program and may be executed on a transaction testing device based on von neumann system. The computer program may be integrated in the application or may run as a stand-alone tool class application. The transaction testing device may be a service platform.

Specifically, the transaction testing method comprises the following steps:

S202: and acquiring historical transaction data, and performing feature extraction processing on the historical transaction data to generate transaction scene data.

The historical transaction data may be data generated in a transaction pushing process within a preset historical period. Specifically, the data generated in the transaction pushing process may include protocol information corresponding to the transaction, where the protocol information may include protocol rules, protocol scenarios, protocol expense, and the like. Typically, the agreement charge may include technical service charge, tariff charge, staged charge, etc.

After the historical transaction data is obtained, the transaction scenario of each transaction corresponding to the historical transaction data needs to be analyzed so as to prepare for the generation of the subsequent use cases. Thus, feature extraction processing can be performed on historical transaction data, and since the same transaction scenario can correspond to a large number of transactions, each transaction has corresponding transaction data. Thus, the history transaction data can be subjected to the feature extraction processing, and the transaction scene data can be generated by the target transaction scene feature obtained by the feature extraction processing.

Alternatively, the process of the feature extraction process may include: acquiring transaction scene feature definition information; extracting features from the historical transaction data based on the transaction scenario feature definition information; discretizing the extracted features to obtain discretized features; and screening the discretization characteristics to obtain target transaction scene characteristics corresponding to the historical transaction data.

The transaction scene feature definition information can be obtained based on expert experience or common feature information, discretization processing is performed on the extracted features, the complexity of the whole features is mainly reduced, the interpretability of the features is improved, and the process of screening the discretization features is mainly used for screening and deleting unusual features and abnormal features. Here, expert experience, that is, a field-related expert, accumulates business experience in a daily business process. Such as quality engineers combing scenes, use cases, risks, etc. that need test verification according to their own expert experience.

Alternatively, the historical transaction data may be input into a transaction scenario data generation model, which performs feature extraction processing on the historical transaction data to output the transaction scenario data.

The transaction scenario data generation model can be trained based on sample transaction data and sample transaction scenario data corresponding to the sample transaction data, so that the transaction scenario data generation model can perform feature extraction processing to output the transaction scenario data.

S204: and constructing case data for the transaction scene data based on the historical transaction data to obtain the transaction test case corresponding to the transaction scene data.

Each transaction scenario data in the historical transaction data has corresponding transaction data, however, the historical transaction data are generally called by the transaction platform to execute various transaction tasks, and even if the transaction scenario data are called again, the transaction platform is difficult to test directly through the historical transaction data.

Therefore, the transaction scenario data can be subjected to case data construction through the historical transaction data, so that corresponding transaction test cases can be constructed for each transaction scenario data through the real data. The coverage of the transaction test case obtained through construction is wider than that of the historical transaction data, because the transaction test case obtained through construction is to randomly combine each transaction scene data in the historical transaction data with other corresponding transaction data again, and because the generation of the transaction test case depends on the real data, the transaction test case can realize the simulation of the real data. Here, the transaction test case may be used to test various functions of the transaction platform to determine whether the transaction platform may operate properly when different transaction data is invoked to perform a transaction task.

Optionally, performing case data construction on the transaction scenario data based on the historical transaction data to obtain a transaction test case corresponding to the transaction scenario data, including:

And inputting the historical transaction data and the transaction scene data into a case data construction model, and constructing the case data for the transaction scene data based on the historical transaction data through the case data construction model to obtain the transaction test case corresponding to the transaction scene data.

The case data construction model can be trained based on sample transaction data and sample transaction scene data corresponding to the sample transaction data, so that the case data construction model can construct case data of the transaction scene data based on historical transaction data to obtain transaction test cases corresponding to the transaction scene data.

and acquiring case expert experience information, generating an expert experience portraiture model based on the case expert experience information, and constructing case data for the transaction scene data based on historical transaction data through the expert experience portraiture model to obtain a transaction test case corresponding to the transaction scene data.

The automation degree of manually generating the test case based on expert experience is low and the cost is high. Therefore, the expert experience information of the case can be learned by means of the model to describe the expert experience portraits, and then the characteristic conversion process of generating the case based on the expert experience information of the case can be learned, so that finally the case data construction can be carried out on the transaction scene data based on the historical transaction data through the expert experience portraits model, and the transaction test case corresponding to the transaction scene data is obtained.

S206: and testing the transaction platform by adopting the transaction test case to obtain a test result.

After the transaction test case is obtained, the transaction platform is tested through the transaction test case so as to test the risk of problems in specific transactions of the transaction platform. Here, the transaction corresponding to the transaction test case may be a transaction occurring in the historical transaction data, or may be a new transaction generated based on the historical transaction data. Therefore, the transaction platform is tested based on the transaction test case, so that the full coverage of each transaction under each transaction scene data can be realized, and the non-occurring transaction is also foreseeable, so that the test of the transaction platform is more fully and effectively realized, and the risk of the occurrence of problems of the transaction platform is effectively reduced.

Optionally, testing the transaction platform by using the transaction test case to obtain a test result, including:

obtaining a result verification scheme corresponding to the transaction test case; testing the transaction platform by adopting a transaction test case to obtain a test operation result; and verifying the test operation result based on the result verification scheme to obtain a test result.

The result verification scheme corresponding to the transaction test case can be obtained through table lookup, or is obtained through manual scheme design, or is obtained through automatic generation of a model corresponding to the transaction test case input. After a result verification scheme corresponding to the transaction test case is obtained, testing the transaction platform by adopting the transaction test case to obtain a test operation result corresponding to the test, and verifying the test operation result by adopting the result verification scheme to judge whether the transaction platform fails when the transaction test case is called, and repairing the transaction platform based on failure information when the transaction platform fails when the transaction test case is called so as to avoid the follow-up occurrence of the same failure when the transaction platform calls transaction data similar to the transaction test case.

In the specification, the historical transaction data is subjected to feature extraction processing by acquiring the historical transaction data, so that transaction scene data is generated; performing case data construction on the transaction scene data based on the historical transaction data to obtain a transaction test case corresponding to the transaction scene data; and testing the transaction platform by adopting the transaction test case to obtain a test result. In the embodiment of the specification, the transaction test case is generated by carrying out case data construction regeneration on historical transaction data based on each transaction scene data, and because the generation of the transaction test case depends on real data, the transaction test case can simulate the real data, and meanwhile, the transaction platform can be fully covered by testing the transaction based on the transaction test case, so that the transaction platform can be tested more fully and effectively based on the transaction test case, and the risk of problems of the transaction platform can be effectively reduced.

Referring to fig. 3, fig. 3 is a schematic flow chart of generating transaction scenario data provided in the present specification. Specific: in S202, feature extraction processing is performed on the historical transaction data, so as to generate transaction scene data, which includes:

S302: and carrying out transaction association processing on the historical transaction data to obtain association historical transaction data.

The historical transaction data comprises transaction data corresponding to a plurality of transactions, so that the transaction data corresponding to the same transaction are required to be associated to obtain complete transaction data corresponding to the same transaction. Generally, transaction data corresponding to the same transaction have the same transaction identifier, so that transaction association processing can be performed on historical transaction data through the transaction identifier to obtain associated historical transaction data.

Illustratively, performing transaction association processing on the historical transaction data to obtain associated historical transaction data, including:

and determining at least one transaction table data corresponding to the historical transaction from the historical transaction data, and carrying out transaction table association processing on all the transaction table data of the same historical transaction to obtain associated historical transaction data corresponding to the historical transaction.

In order to facilitate storage and analysis, the historical transaction data is generally stored in a table form, so that at least one transaction table data corresponding to the historical transaction can be obtained from the historical transaction data through a transaction identifier corresponding to the historical transaction, and after the at least one transaction table data corresponding to the historical transaction is obtained, the at least one transaction table data corresponding to the same historical transaction is associated, so that complete associated historical transaction data corresponding to the historical transaction is obtained.

S304: and extracting transaction scene features of each associated historical transaction data to obtain candidate transaction scene features, and performing feature screening processing on the candidate transaction scene features to obtain target transaction scene features.

Each transaction corresponds to one associated historical transaction data, so that the transaction scene feature extraction of each associated historical transaction data is actually to extract the transaction scene feature corresponding to each transaction, and the candidate transaction scene feature is obtained. After the candidate transaction scenario features are obtained, the validity of each candidate transaction scenario feature needs to be confirmed, so that feature screening processing needs to be carried out on the candidate transaction scenario features to obtain target transaction scenario features.

When the feature screening processing is performed on the candidate transaction scene features, the feature screening processing can be performed based on expert experience, validity matching can also be performed on the candidate transaction scene features, the unmatched candidate transaction scene features are deleted or recorded, and the recorded unmatched candidate transaction scene features can be further judged whether to be added into the target transaction scene features as features which do not appear or appear less before. The matched candidate transaction scenario features are used as target transaction scenario features, and the matched candidate transaction scenario features are features which occur frequently, namely features which occur frequently.

Exemplary, performing transaction scenario feature extraction on each associated historical transaction data to obtain candidate transaction scenario features, and performing feature screening processing on the candidate transaction scenario features to obtain target transaction scenario features, including:

carrying out transaction commonality extraction on each associated historical transaction data to obtain candidate transaction commonality data;

performing transaction scene aggregation on the candidate transaction commonality data to obtain candidate transaction scene characteristics;

and acquiring at least one reference transaction scene type tag, and filtering scene characteristics of the candidate transaction scene characteristics based on the reference transaction scene type tag to obtain target transaction scene characteristics.

Each history transaction corresponds to one associated history transaction data, so that the same characteristic data of each history transaction, namely candidate transaction commonality data, is obtained by carrying out transaction commonality extraction on each associated history transaction data. The same feature data may be of one or more kinds, and not all candidate transaction commonality data may be targeted transaction scenario features. Therefore, transaction context aggregation can be performed on the candidate transaction common data through the transaction context so as to extract candidate transaction context features corresponding to the transaction context from the candidate transaction common data.

After the candidate transaction scenario features are obtained, the validity of the candidate transaction scenario features needs to be determined, and the candidate transaction scenario features can be screened and filtered based on the reference transaction scenario tags. Specifically, the candidate transaction scenario features may be input into a transaction scenario label generation model, where the transaction scenario label generation model extracts label information of the candidate transaction scenario features to obtain transaction scenario labels of the candidate transaction scenario features. And then matching the transaction scene label of the candidate transaction scene feature with at least one reference transaction scene label, wherein the matched candidate transaction scene feature is used as a target transaction scene feature, and the matched candidate transaction scene feature is a feature which appears frequently, namely a feature which appears frequently.

S306: and carrying out scene processing on the target transaction scene characteristics to obtain transaction scene data under at least one transaction scene type label.

Wherein, after the target transaction scene feature is obtained, the transaction scene data is generated by the obtained target transaction scene feature. Here, there is a random combination of target transaction scenario features in the process of generating the transaction scenario data.

Exemplary, the scenerising process is performed on the target transaction scene feature to obtain transaction scene data under at least one transaction scene type label, including:

Performing feature scene conversion processing on the target transaction scene features to obtain initial transaction scene data corresponding to the target transaction scene features, and determining initial scene types of the initial transaction scene data;

the transaction scene type tag is obtained, the initial transaction scene data is screened based on the transaction scene type tag and the initial scene type to obtain at least one associated historical scene transaction data under the transaction scene type tag, and all the associated historical scene transaction data under the same transaction scene type tag are combined to obtain the transaction scene data.

Firstly, performing feature scene conversion processing on each target transaction scene feature to obtain initial transaction scene data corresponding to each target transaction scene feature, and obtaining an initial scene type of the initial transaction scene data after obtaining the initial transaction scene data. And then, acquiring a preset transaction scene type label, wherein the transaction scene type label is used for screening the initial scene type. Specifically, the initial scene type may be input into a tag generation model, and the tag generation model extracts tag information of the initial scene type to obtain a scene type tag of the initial scene type. Then, the scene type label of the initial scene type is matched with the transaction scene type label, and the scene type label which is not matched indicates that the initial scene type corresponding to the label is not the scene type frequently appearing in the actual scene, so that the scene type label can be removed; the matched scene type tag indicates that the initial scene type corresponding to the tag is a scene type frequently appearing in an actual scene, and therefore can be reserved.

And screening the initial transaction scene data based on the transaction scene type tag and the initial scene type to obtain at least one associated historical scene transaction data under the transaction scene type tag, wherein the associated historical scene transaction data corresponds to the target transaction scene characteristics. It should be noted that the transaction scenario type tag may include a main body, a transaction type, a funding mode, a major class identifier, a tertiary product code, a data transfer product code, and the like. Where data transfers include, but are not limited to, funds transfers, resource data transfers, and the like. Each transaction scenario type tag may correspond to one or more associated historical scenario transaction data. Therefore, the complete transaction scenario data can be obtained by combining all the associated historical scenario transaction data under the same transaction scenario type label.

Of course, in other embodiments, the filtering of the initial transaction scenario data may also rely on expert experience to perform filtering, or perform activity sorting according to the occurrence frequency of the initial transaction scenario data, reject the initial transaction scenario data with low activity, or may perform table lookup to obtain the priority of each initial transaction scenario data, sort according to the priority, and reject the initial transaction scenario data with low priority.

In the embodiment provided by the specification, transaction association processing is performed on historical transaction data to obtain complete associated historical transaction data corresponding to the same historical transaction, candidate transaction scene features are extracted from each associated historical transaction data, the candidate transaction scene features are screened to remove features which do not accord with an actual scene, so that target transaction scene features are obtained, and finally the target transaction scene features are subjected to scene processing to generate transaction scene data which accord with the actual scene, namely transaction scene data under at least one transaction scene type label.

Referring to fig. 4, fig. 4 is a schematic flow chart of determining a transaction test case provided in the present specification. Specific: s204, constructing case data of the transaction scene data based on the historical transaction data to obtain a transaction test case corresponding to the transaction scene data, wherein the method comprises the following steps:

s402: a transaction context library is generated based on the transaction context data.

Different transaction scene type labels correspond to different transaction scene data, and transaction scene data corresponding to all the transaction scene type labels are put into the same scene library to obtain a transaction scene library. In particular, the transaction context library may include a body, a transaction type, a payback pattern, a large class identification, a tertiary product code, a data transfer product code, and the like.

S404: and extracting transaction characteristics from the historical transaction data to obtain transaction characteristic features, and generating an initial use case library based on the transaction characteristic features.

The method comprises the steps of carrying out transaction association processing on historical transaction data to obtain associated historical transaction data, carrying out transaction characteristic extraction on each associated historical transaction data to determine characteristics of parameters different from each other in each associated historical transaction data, further obtaining transaction characteristic characteristics, and then placing the transaction characteristic characteristics into the same user library to obtain an initial user library.

Specifically, the transaction characteristic feature obtained by extracting the transaction characteristic of the historical transaction data may include: charging scope, charging scenario, no-charging scenario, charging rule, contract rule, exception scenario, etc.

S406: and carrying out scene data combination processing based on the transaction scene library and the initial case library to obtain transaction test cases corresponding to the transaction scene data.

After the transaction scene library and the initial case library are obtained, a transaction test case can be generated. Namely, each element in the transaction scene library is randomly combined with each element in the initial case library, so that a transaction test case corresponding to the transaction scene data is generated.

Exemplary, scene data combination processing is performed based on a transaction scene library and an initial case library to obtain a transaction test case corresponding to the transaction scene data, including:

acquiring at least one transaction characteristic feature in an initial use case library and at least one scene data combination in a transaction scene library, wherein the scene data combination comprises transaction scene data corresponding to at least two transaction scene type tags;

and randomly combining the transaction characteristic features and the scene data combination to obtain the transaction test case corresponding to the transaction scene data.

And randomly combining the transaction scene data corresponding to all the transaction scene type tags to obtain at least one scene data combination in the transaction scene library. Thus, the scene data combination includes transaction scene data corresponding to at least two transaction scene type tags.

After the transaction characteristic feature and scene data combination is obtained, the transaction characteristic feature and scene data combination is randomly combined, so that more transaction test cases are generated.

Specifically, referring to fig. 5, fig. 5 is a schematic combination diagram of determining a transaction test case provided in the present specification.

The number of elements in the initial case library is N, the number of elements corresponding to the scene data combination in the transaction scene library is M, and the transaction test cases corresponding to the transaction scene data are obtained by carrying out random combination based on the transaction characteristic features and the scene data combination, wherein the number of the transaction test cases can be N x M.

Specifically, in the billing scenario, that is, the institution developing transaction process cooperates with a plurality of external institutions and main bodies and signs corresponding agreements, and pays/charges corresponding various fees according to the agreements: such as technical service fees, charging service fees, staged charge fees, etc. When charging, a user (such as a refund overdue scene, refund including principal, fee, and technical service fee for refund fee) often needs to cover different transaction scene data, such as main body (e.g. main body a and main body B), transaction type (e.g. XX flower, XX borrowing), and fund mode (e.g. direct throw, joint). Thus, 6 transaction context data parameters are extracted, the values of which may be individually defined by specific context data combinations. The use case templates include reusable scene parameters. When a use case template is added into a certain scene data combination, the scene parameters are instantiated, so that the quick multiplexing of the use case template is realized quickly. Meanwhile, in the whole testing process, the test is possibly required to be performed in a plurality of environments such as a development environment, a continuous integration environment, a simulation environment, a production environment and the like, so that the use cases of different environments can be automatically multiplexed and generated through checking the environments, and the execution efficiency is improved.

Further, assume that there are 5 use cases, but the coverage scene is actually needed in a large class: body = mechanism body a, mechanism body B; transaction type = XX flower bar, XX bar; the fund mode=direct projection, affiliated, etc., if 20 scene major categories are combined based on the cartesian products of the transaction scene library, the actual number of cases is 5×20=100. And the test needs to be verified in the development environment, the continuous integration environment and the production environment, and then the number of finally executed cases is 5×20×3=300.

The platform can cover the 300 use cases by actually inputting 5 transaction characteristic features, establishing 20 scene data combinations and checking 3 environments, so that the manual maintenance cost of the use cases is greatly reduced, the daily automatic operation and the statistical coverage rate are supported, and the result verification can be realized through a custom script and rules.

Referring to fig. 6, fig. 6 is a schematic flow chart of determining coverage information of a test case provided in the present specification. Specifically, the step of determining the test case coverage information includes:

s602: and acquiring a transaction task corresponding to the transaction platform, and calling a transaction test case to execute the transaction task based on the transaction platform.

The transaction platform needs to execute various transaction tasks during running, and in order to determine the coverage condition of the generated transaction test cases, the transaction test cases corresponding to the transaction tasks are called when the transaction platform executes the transaction tasks.

S604: and acquiring an un-called reference transaction test case, and calculating test case coverage information based on the reference transaction test case and the transaction test case.

The reference transaction test case which is not called indicates that the reference transaction test case is not covered by the transaction task, and the validity of the generated transaction test case can be represented based on the test case coverage information obtained by calculating the reference transaction test case and the transaction test case.

Specifically, referring to fig. 7, fig. 7 is a schematic diagram of an architecture for determining coverage information of a test case provided in the present specification.

The environment switching can comprise switching of 4 running environments, such as a development environment, a continuous integration environment, a simulation environment and a production environment. The instance instantiation can substitute specific parameters into the transaction test instance, the specific parameters can be generated based on the parameters of the transaction scene library, then the instance script corresponding to the instance is generated for the transaction platform to call, and meanwhile, the instance instantiation can be subjected to dynamic date partitioning so as to distinguish the instance instances generated in different dates. It should be noted that, when the transaction platform calls the transaction test case, the corresponding case script is actually called.

After the application case script corresponding to the transaction test case is executed, the coverage condition of each transaction test case is produced, and the execution of the application case script corresponding to the transaction test case indicates that the transaction test case is covered; the case script corresponding to the transaction test case is not executed, which indicates that the transaction test case is not covered.

In order to more accurately know the coverage information of the test cases, coverage configuration can be set, for example, in a time interval of the coverage configuration, the starting time and the deadline can be adjusted to obtain the coverage condition of each transaction test case in the time interval; in the measurement type of coverage rate configuration, the coverage rate of all transaction test cases in the same day and the accumulated coverage rate of all transaction test cases in a certain period can be obtained by having selectable daily coverage rate and cycle accumulated coverage rate; in the measurement dimension and measurement value of coverage rate configuration, scene data combination, cost item and all scene data combination can be specified for type screening; subscription periods, subscribed scene data combinations, and subscription groups/subscribers may be managed in a subscription configuration of the coverage configuration.

Finally, the coverage rate of the case coverage details and the single scene data combination can be output in the coverage metric and problem positioning, and meanwhile, the coverage rate can be notified, a case manual feedback entry and an autonomous positioning can be provided, and a case re-running function can be provided, so that the test case coverage information can be regenerated by one key after the transaction test case is updated. In the coverage measurement report, the current day coverage report and the accumulated coverage report within the set period can be input, and meanwhile, the coverage measurement report can be calculated in real time and refreshed in real time according to the configuration.

The application scene of the coverage rate of the current day and the period accumulation coverage rate in the coverage metric type is as follows: because most of offline tasks run once a day, under a drainage scene, part of use cases may not be data in a certain day, and a period of time needs to be accumulated to accurately evaluate the coverage condition of the use cases, so that the coverage rate of the use cases needs to be accumulated in a use period. If the statistical algorithm is intended to produce flow in batches or to sense the coverage of the flow of a certain day, the coverage of the current day can be used. In general, offline tasks depend on offline data, which generally refers to data of date of T-1, such as date of today t=2023-08-04, and then transaction data on which offline tasks depend is generally data of 2023-08-03 of the previous day (yesterday data).

In addition, after the case scripts are multiplexed to different scene libraries, the case scripts of different environments are instantiated according to scene parameters of the scene libraries, and the timed task automatically schedules and executes each day to obtain the coverage condition of each case. And calculating the current day coverage rate or the period accumulated coverage rate of the specified time interval and the specified dimension according to the front end configuration of the coverage rate. And support configuration software to notify active perceived coverage changes. Meanwhile, the front end can provide coverage details and execution logs of each use case so as to facilitate automatic positioning and use case feedback.

Referring to fig. 8, fig. 8 is a schematic flow chart of an update transaction test case provided in the present specification. As shown in fig. 8, in S206, the transaction platform is tested by using the transaction test case, and before obtaining a test result, the method includes:

s802: reference transaction data is acquired.

Wherein the reference transaction data is currently generated transaction data, and therefore, the reference transaction data is not in the historical transaction data.

S804: it is determined whether the reference transaction data is data-anomalous.

Whether the reference transaction data is abnormal or not can be judged based on expert experience, or feature matching is carried out on the reference transaction data based on the reference early warning features of the historical transaction data so as to judge whether the reference transaction data is abnormal or not.

Illustratively, determining whether the reference transaction data is data-anomalous includes:

extracting historical reference early warning features from historical transaction data, and extracting reference early warning features from the reference transaction data;

and performing feature matching on the historical reference early warning features and the reference early warning features, and when the historical reference early warning features are not matched with the reference early warning features, the reference transaction data is of a data anomaly type.

The method comprises the steps of extracting historical reference early warning features of historical transaction data and reference early warning features of the reference transaction data, and performing feature matching on the reference early warning features of the reference transaction data based on the historical reference early warning features corresponding to historical experience, so that the reference transaction data is judged to be of a data abnormal type or a data normal type. Specifically, the historical reference early warning features may include a characterized charging range, a contract rule, a charging rule, a non-charging range, and the like.

Illustratively, feature matching the historical reference early warning feature with the reference early warning feature includes:

determining a reference feature value distribution range of the historical reference early warning feature, and determining a feature value of the reference early warning feature;

judging whether the characteristic value of the reference early warning characteristic falls into the reference characteristic value distribution range, and if the characteristic value of the reference early warning characteristic does not fall into the reference characteristic value distribution range, mismatching the historical reference early warning characteristic with the reference early warning characteristic.

After the historical reference early warning features are extracted through the historical transaction data, determining reference feature values of the historical reference early warning features, determining a reference feature value distribution range based on the feature values of the historical reference early warning features, and then judging whether the feature values of the reference early warning features fall into the reference feature value distribution range, wherein when the feature values of the reference early warning features fall into the reference feature value distribution range, the historical reference early warning features are matched with the reference early warning features; when the characteristic value of the reference early warning characteristic does not fall into the distribution range of the reference characteristic value, the historical reference early warning characteristic is not matched with the reference early warning characteristic.

When the historical reference early warning characteristic is matched with the reference early warning characteristic, indicating that the reference transaction data is of a data normal type; and when the historical reference early warning characteristic is not matched with the reference early warning characteristic, indicating that the reference transaction data is of a data anomaly type.

S806, if the reference transaction data is of a data exception type, constructing case data of the reference transaction data to obtain a new transaction test case corresponding to the reference transaction data.

Wherein when the reference transaction data is of a data exception type, it is indicated that the reference transaction data may be data generated in a new scenario. Therefore, the case data construction can be carried out on the reference transaction data to obtain the newly-added transaction test case corresponding to the reference transaction data, so that the timely update of the transaction test case is realized. In particular, when the reference transaction data is of a data exception type, the possibility of generating exception by the reference transaction data exists, so that after the reference transaction data is diagnosed to be abnormal, the possibility of generating exception by the reference transaction data is eliminated, and then the case data construction is performed on the reference transaction data to obtain a new transaction test case corresponding to the reference transaction data.

S808: and updating the transaction test case based on the newly added transaction test case.

After the new transaction test case is obtained, the new transaction test case is added into the transaction test case to complete the real-time update of the transaction test case, so that the transaction test case can timely cover a new scene.

S810: and if the reference transaction data is of the data normal type, executing the step of testing the transaction platform by adopting the transaction test case to obtain a test result.

When the historical reference early warning feature matches the reference early warning feature, it indicates that the reference transaction data is of a normal type, step S206 is performed at this time, and specific content can refer to the relevant description of S206, which is not described herein.

Referring to fig. 9, fig. 9 is a schematic diagram of a transaction testing method according to one or more embodiments of the present disclosure. As shown in fig. 9, in the offline charging scenario, first, a transaction test case without specific data is generated based on expert experience and algorithm mining, and then specific data can be automatically generated through manual entry or algorithm to be added into the transaction test case without specific data. When specific data is automatically generated based on an algorithm, the algorithm may include a data construction component for use in case label generation, case environment addition, case parameter addition, case set description generation, case set parameter addition, and case-case set association generation, and a result verification component. The case set can be generated based on historical transaction data, specifically, the transaction test case can be generated after abnormal data is eliminated from the historical transaction data, and the case set is generated based on the transaction test case.

In expert experience, charging scenarios may be divided into charging characteristics and charging commonalities, the charging characteristics including charging range, non-charging range, charging scenario, charging rule, contract rule, and abnormal scenario; billing commonalities may include fees, principals, types of matters, funding patterns, tertiary product codes, and product categories. Algorithm mining may include semantic conversion, feature definition, feature discretization, feature mining, feature filtering, unmatched feature recommendation, and so forth. The semantic conversion is used for extracting features, and feature definition, feature discretization, feature mining, feature filtering, and unmatched feature recommendation are all mentioned in the above embodiments, and are not described herein.

In the service layer, the service layer comprises links of scene inquiry, scene marking, scene association, scene identification, scene filtering, scene matching, expert experience auxiliary deviation correction, scene liveness and scene map. The scene is screened by inquiring, associating, identifying and matching the obtained scenes, the scene marking is performed manually, the expert experience is assisted to correct the deviation, the screening is performed based on the expert experience, the scene liveness is recorded, the occurrence frequency of each scene is recorded, and the scene graph is manufactured based on the scene liveness.

In the test data construction, the method comprises the steps of drainage of a production environment and automatic counting of an algorithm, namely, a transaction test case is adopted to test a transaction platform in the production environment, specific data in the transaction test case is automatically generated based on the algorithm, and a low-frequency scene, an abnormal scene and a no-flow scene are generated, namely, the scene coverage condition in the process of testing the transaction platform by adopting the transaction test case in the production environment, wherein the low-frequency scene indicates that the scene is less in application, the abnormal scene indicates that the scene does not accord with the actual condition, and the no-flow scene indicates that the scene is temporarily not applied.

The use case generation and execution comprises automatic generation of algorithm use cases, automatic scheduling of use cases, precipitation of expert experience use cases, manual triggering of use cases and change analysis. The method comprises the steps of automatically generating an algorithm case, namely adding specific data in transaction scene data based on the algorithm, automatically scheduling the case based on a preset transaction task, precipitating expert experience cases, namely adding new transaction test cases based on expert experience, manually triggering the cases, namely manually scheduling the cases, and rescheduling and analyzing after changing and analyzing the transaction test cases.

In the result verification & test measurement, the double running comparison, the automatic verification and the check rule are included, and because the test environments of the transaction test cases can be multiple, the consistency of data obtained by migration in each environment needs to be confirmed, and therefore, the double running comparison, the automatic verification and the check rule are carried out through the running results of the data in different test environments to confirm the consistency of the data obtained by migration in each environment. The parameters for comparison can include a transaction coverage rate measurement parameter in double running, and can also provide self-help positioning of the double running problem.

In the scene early warning & active discovery, the new scene is perceived through the charging factor distribution and the factor fluctuation detection, and the specific reference may be made to step S806, which is not repeated here. The scheme mainly prevents resource loss through off-line full scene coverage and production flow early warning, improves efficiency through expert experience use case multiplexing and algorithm use case automatic generation, and achieves test scene coverage visualization through coverage metrics.

The transaction testing device provided in this specification will be described in detail with reference to fig. 10. It should be noted that fig. 10 is a schematic structural diagram of a transaction testing device provided in the present specification, which is used to execute the method of the embodiment shown in fig. 1 to 9 in the present specification, and for convenience of explanation, only a portion relevant to the present specification is shown, and specific technical details are not disclosed, and please refer to the embodiment shown in fig. 1 to 9 in the present specification.

Referring to fig. 10, a schematic structural diagram of a transaction testing device according to the present specification is shown. The transaction testing device 1 may be implemented as all or part of a terminal by software, hardware or a combination of both. According to some embodiments, the transaction testing device 1 comprises an acquisition module 11, a construction module 12 and a testing module 13, in particular for:

The acquisition module 11 is suitable for acquiring historical transaction data, performing feature extraction processing on the historical transaction data, and generating transaction scene data;

the construction module 12 is adapted to perform case data construction on the transaction scene data based on the historical transaction data to obtain a transaction test case corresponding to the transaction scene data;

and the test module 13 is suitable for testing the transaction platform by adopting the transaction test case to obtain a test result.

Optionally, the acquisition module 11 includes:

the association history transaction data determining unit is suitable for carrying out transaction association processing on the history transaction data to obtain association history transaction data;

the feature extraction unit is suitable for carrying out transaction scene feature extraction on each associated historical transaction data to obtain candidate transaction scene features, and carrying out feature screening processing on the candidate transaction scene features to obtain target transaction scene features;

the scenery unit is suitable for scenery processing the target transaction scene characteristics to obtain transaction scene data under at least one transaction scene type label.

Optionally, the association history transaction data determining unit is adapted to determine at least one transaction table data corresponding to the history transaction from the history transaction data, and perform transaction table association processing on all the transaction table data of the same history transaction to obtain association history transaction data corresponding to the history transaction.

Optionally, the feature extraction unit includes:

the commonality extraction subunit is suitable for carrying out transaction commonality extraction on each associated historical transaction data to obtain candidate transaction commonality data;

the transaction scene aggregation subunit is suitable for carrying out transaction scene aggregation on the candidate transaction commonality data to obtain candidate transaction scene characteristics;

the first acquisition subunit is suitable for acquiring at least one reference transaction scene type tag, and performing scene feature filtering on candidate transaction scene features based on the reference transaction scene tag to obtain target transaction scene features.

Optionally, the scenerising unit includes:

the feature scene conversion processing subunit is suitable for carrying out feature scene conversion processing on the target transaction scene features to obtain initial transaction scene data corresponding to the target transaction scene features, and determining the initial scene type of the initial transaction scene data;

the transaction scene type tag acquisition subunit is suitable for acquiring the transaction scene type tag, screening the initial transaction scene data based on the transaction scene type tag and the initial scene type to obtain at least one associated historical scene transaction data under the transaction scene type tag, and combining all the associated historical scene transaction data under the same transaction scene type tag to obtain the transaction scene data.

Optionally, the construction module comprises:

a transaction scenario library generation unit adapted to generate a transaction scenario library based on the transaction scenario data;

the initial use case library generating unit is suitable for extracting transaction characteristics of historical transaction data to obtain transaction characteristic features and generating an initial use case library based on the transaction characteristic features;

the combination unit is suitable for carrying out scene data combination processing based on the transaction scene library and the initial case library to obtain transaction test cases corresponding to the transaction scene data.

Optionally, the combining unit includes:

the second acquisition subunit is suitable for acquiring at least one transaction characteristic feature in the initial use case library and at least one scene data combination in the transaction scene library, wherein the scene data combination comprises transaction scene data corresponding to at least two transaction scene type tags;

and the random combination subunit is suitable for carrying out random combination on the transaction characteristic features and scene data combination to obtain transaction test cases corresponding to the transaction scene data.

Optionally, the transaction test device 1 further includes:

the execution module is suitable for acquiring a transaction task corresponding to the transaction platform, and calling a transaction test case to execute the transaction task based on the transaction platform;

the computing module is suitable for acquiring the reference transaction test case which is not called and computing the test case coverage information based on the reference transaction test case and the transaction test case.

Optionally, the transaction test device 1 further includes:

the reference transaction data acquisition module is suitable for acquiring reference transaction data;

the judging module is suitable for judging whether the reference transaction data is abnormal;

the data exception type module is suitable for constructing case data of the reference transaction data if the reference transaction data is of a data exception type, and obtaining a newly-added transaction test case corresponding to the reference transaction data;

and the updating module is suitable for updating the transaction test case based on the newly added transaction test case.

Optionally, the judging module includes:

the early warning feature extraction unit is suitable for extracting historical reference early warning features from historical transaction data and extracting reference early warning features from the reference transaction data;

the feature matching unit is suitable for carrying out feature matching on the historical reference early warning feature and the reference early warning feature, and when the historical reference early warning feature is not matched with the reference early warning feature, the reference transaction data is of a data anomaly type.

Optionally, the feature matching unit includes:

the determining subunit is suitable for determining a reference feature value distribution range of the historical reference early warning feature and determining a feature value of the reference early warning feature;

the judging subunit is suitable for judging whether the characteristic value of the reference early-warning characteristic falls into the reference characteristic value distribution range, and if the characteristic value of the reference early-warning characteristic does not fall into the reference characteristic value distribution range, the historical reference early-warning characteristic is not matched with the reference early-warning characteristic.

Optionally, the test module 13 includes:

the result verification scheme acquisition unit is suitable for acquiring a result verification scheme corresponding to the transaction test case;

the test operation result acquisition unit is suitable for testing the transaction platform by adopting the transaction test case to obtain a test operation result;

and the test result determining unit is suitable for verifying the test running result based on the result verification scheme to obtain the test result.

It should be noted that, when executing the transaction testing method, the transaction testing device provided in the foregoing embodiment only uses the division of the functional modules to illustrate, in practical application, the functional allocation may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the transaction testing device and the transaction testing method provided in the foregoing embodiments belong to the same concept, which embody detailed implementation procedures in the method embodiments, and are not described herein again.

The present disclosure further provides a computer storage medium, where the computer storage medium may store a plurality of instructions, where the instructions are adapted to be loaded by a processor and execute the transaction testing method according to the embodiments shown in fig. 1 to 9, and the specific execution process may refer to the specific description of the embodiments shown in fig. 1 to 9, which is not repeated herein.

The present disclosure further provides a computer program product, where at least one instruction is stored, where the at least one instruction is loaded by the processor and executed by the processor to perform the transaction testing method according to the embodiment shown in fig. 1 to fig. 9, and the specific execution process may refer to the specific description of the embodiment shown in fig. 1 to fig. 9, which is not repeated herein.

Referring to fig. 11, fig. 11 is a schematic structural diagram of an electronic device provided in the present disclosure. A block diagram of an electronic device according to an exemplary embodiment of the present specification is shown. The electronic device in this specification may include one or more of the following: processor 110, memory 120, input device 130, output device 140, and bus 150. The processor 110, the memory 120, the input device 130, and the output device 140 may be connected by a bus 150.

Processor 110 may include one or more processing cores. The processor 110 employs various interfaces and lines to connect various portions of the overall electronic device, perform various functions of the electronic device 100 and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and invoking data stored in the memory 120. Alternatively, the processor 110 may be implemented in at least one hardware form of digital signal processing (digital signal processing, DSP), field-programmable gate array (field-programmable gate array, FPGA), programmable logic array (programmable logic Array, PLA). The processor 110 may integrate one or a combination of several of a central processor (central processing unit, CPU), an image processor (graphics processing unit, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for being responsible for rendering and drawing of display content; the modem is used to handle wireless communications. It will be appreciated that the modem may not be integrated into the processor 110 and may be implemented solely by a single communication chip.

The memory 120 may include a random access memory (random Access Memory, RAM) or a read-only memory (ROM). Optionally, the memory 120 includes a non-transitory computer readable medium (non-transitory computer-readable storage medium). Memory 120 may be used to store instructions, programs, code, sets of codes, or sets of instructions. The memory 120 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, which may be an Android (Android) system, including an Android system-based deep development system, an IOS system developed by apple corporation, including an IOS system-based deep development system, or other systems, instructions for implementing at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing various method embodiments described below, and the like. The storage data area may also store data created by the electronic device in use, such as phonebooks, audiovisual data, chat log data, and the like.

Referring to fig. 12, fig. 12 is a schematic diagram of an operating system and a user space provided in the present specification, where the memory 120 may be divided into an operating system space and a user space, and an operating system may be run in the operating system space, and a native and a third party application may be run in the user space. In order to ensure that different third party application programs can achieve better operation effects, the operating system allocates corresponding system resources for the different third party application programs. However, the requirements of different application scenarios in the same third party application program on system resources are different, for example, under the local resource loading scenario, the third party application program has higher requirement on the disk reading speed; in the animation rendering scene, the third party application program has higher requirements on the GPU performance. The operating system and the third party application program are mutually independent, and the operating system often cannot timely sense the current application scene of the third party application program, so that the operating system cannot perform targeted system resource adaptation according to the specific application scene of the third party application program.

In order to enable the operating system to distinguish specific application scenes of the third-party application program, data communication between the third-party application program and the operating system needs to be communicated, so that the operating system can acquire current scene information of the third-party application program at any time, and targeted system resource adaptation is performed based on the current scene.

Taking an Android system as an example, the program and data stored in the memory 120 are shown in fig. 13, fig. 13 is a schematic diagram of the Android operating system in fig. 12, and the Linux kernel layer 320, the system runtime library layer 340, the application framework layer 360 and the application layer 380 may be stored in the memory 120, where the Linux kernel layer 320, the system runtime library layer 340 and the application framework layer 360 belong to an operating system space, and the application layer 380 belongs to a user space. The Linux kernel layer 320 provides the underlying drivers for various hardware of the electronic device, such as display drivers, audio drivers, camera drivers, bluetooth drivers, wi-Fi drivers, power management, and the like. The system runtime layer 340 provides the main feature support for the Android system through some C/c++ libraries. For example, the SQLite library provides support for databases, the OpenGL/ES library provides support for 3D graphics, the Webkit library provides support for browser kernels, and the like. Also provided in the system runtime library layer 340 is a An Zhuoyun runtime library (Android run) which provides mainly some core libraries that can allow developers to write Android applications using the Java language. The application framework layer 360 provides various APIs that may be used in building applications, which developers can also build their own applications by using, for example, campaign management, window management, view management, notification management, content provider, package management, call management, resource management, location management. At least one application program is running in the application layer 380, and these application programs may be native application programs of the operating system, such as a contact program, a short message program, a clock program, a camera application, etc.; and may also be a third party application developed by a third party developer, such as a game-like application, instant messaging program, photo beautification program, etc.

Taking the IOS system as an example, the program and data stored in the memory 120 are shown in fig. 14, fig. 14 is an architecture diagram of the IOS operating system in fig. 12, where the IOS system includes: core operating system layer 420 (Core OS layer), core service layer 440 (Core Services layer), media layer 460 (Media layer), and touchable layer 480 (Cocoa Touch Layer). The core operating system layer 420 includes an operating system kernel, drivers, and underlying program frameworks that provide more hardware-like functionality for use by the program frameworks at the core services layer 440. The core services layer 440 provides system services and/or program frameworks required by the application, such as a Foundation (Foundation) framework, an account framework, an advertisement framework, a data storage framework, a network connection framework, a geographic location framework, a sports framework, and the like. The media layer 460 provides an interface for applications related to audiovisual aspects, such as a graphics-image related interface, an audio technology related interface, a video technology related interface, an audio video transmission technology wireless play (AirPlay) interface, and so forth. The touchable layer 480 provides various commonly used interface-related frameworks for application development, with the touchable layer 480 being responsible for user touch interactions on the electronic device. Such as a local notification service, a remote push service, an advertisement framework, a game tool framework, a message User Interface (UI) framework, a User Interface UIKit framework, a map framework, and so forth.

Among the frameworks shown in fig. 14, frameworks related to most applications include, but are not limited to: the infrastructure in core services layer 440 and the UIKit framework in touchable layer 480. The infrastructure provides many basic object classes and data types, providing the most basic system services for all applications, independent of the UI. While the class provided by the UIKit framework is a basic UI class library for creating touch-based user interfaces, iOS applications can provide UIs based on the UIKit framework, so it provides the infrastructure for applications to build user interfaces, draw, process and user interaction events, respond to gestures, and so on.

The manner and principle of implementing data communication between the third party application program and the operating system in the IOS system may refer to the Android system, and this description is not repeated here.

The input device 130 is configured to receive input instructions or data, and the input device 130 includes, but is not limited to, a keyboard, a mouse, a camera, a microphone, or a touch device. The output device 140 is used to output instructions or data, and the output device 140 includes, but is not limited to, a display device, a speaker, and the like. In one example, the input device 130 and the output device 140 may be combined, and the input device 130 and the output device 140 are a touch display screen for receiving a touch operation thereon or thereabout by a user using a finger, a touch pen, or any other suitable object, and displaying a user interface of each application program. Touch display screens are typically provided on the front panel of an electronic device. The touch display screen may be designed as a full screen, a curved screen, or a contoured screen. The touch display screen can also be designed to be a combination of a full screen and a curved screen, and a combination of a special-shaped screen and a curved screen is not limited in this specification.

In addition, those skilled in the art will appreciate that the configuration of the electronic device shown in the above-described figures does not constitute a limitation of the electronic device, and the electronic device may include more or less components than illustrated, or may combine certain components, or may have a different arrangement of components. For example, the electronic device further includes components such as a radio frequency circuit, an input unit, a sensor, an audio circuit, a wireless fidelity (wireless fidelity, wiFi) module, a power supply, and a bluetooth module, which are not described herein.

In this specification, the execution subject of each step may be the electronic device described above. Optionally, the execution subject of each step is an operating system of the electronic device. The operating system may be an android system, an IOS system, or other operating systems, which is not limited in this specification.

The electronic device of the present specification may further have a display device mounted thereon, and the display device may be various devices capable of realizing a display function, for example: cathode ray tube displays (cathode ray tubedisplay, CR), light-emitting diode displays (light-emitting diode display, LED), electronic ink screens, liquid crystal displays (liquid crystal display, LCD), plasma display panels (plasma display panel, PDP), and the like. A user may employ a display device on electronic device 101 to view displayed text, images, video, etc. The electronic device may be a smart phone, a tablet computer, a gaming device, an AR (Augmented Reality ) device, an automobile, a data storage device, an audio playing device, a video playing device, a notebook, a desktop computing device, a wearable device such as an electronic watch, electronic glasses, an electronic helmet, an electronic bracelet, an electronic necklace, an electronic article of clothing, etc.

In the electronic device shown in fig. 11, where the electronic device may be a terminal, the processor 110 may be configured to invoke the transaction test program stored in the memory 120 and specifically perform the following operations:

and testing the transaction platform by adopting the transaction test case to obtain a test result.

In one embodiment, the processor 110 performs the following operations when performing feature extraction processing on historical transaction data to generate transaction scenario data:

carrying out transaction association processing on the historical transaction data to obtain association historical transaction data;

extracting transaction scene features of each associated historical transaction data to obtain candidate transaction scene features, and performing feature screening processing on the candidate transaction scene features to obtain target transaction scene features;

and carrying out scene processing on the target transaction scene characteristics to obtain transaction scene data under at least one transaction scene type label.

In one embodiment, the processor 110 performs the following operations when performing a transaction association process on the historical transaction data to obtain the associated historical transaction data:

In one embodiment, the processor 110 performs the following operations when performing the transaction scenario feature extraction on each associated historical transaction data to obtain candidate transaction scenario features, and performing feature screening processing on the candidate transaction scenario features to obtain target transaction scenario features:

and acquiring at least one reference transaction scene type tag, and filtering scene features of the candidate transaction scene features based on the reference transaction scene tag to obtain target transaction scene features.

In one embodiment, when performing the scenerising process on the target transaction scene feature to obtain the transaction scene data under the at least one transaction scene type tag, the processor 110 specifically performs the following operations:

In one embodiment, when executing the case data construction on the transaction scenario data based on the historical transaction data to obtain the transaction test case corresponding to the transaction scenario data, the processor 110 specifically performs the following operations:

generating a transaction context library based on the transaction context data;

extracting transaction characteristics from the historical transaction data to obtain transaction characteristic features, and generating an initial use case library based on the transaction characteristic features;

and carrying out scene data combination processing based on the transaction scene library and the initial case library to obtain transaction test cases corresponding to the transaction scene data.

In one embodiment, when executing the scene data combination processing based on the transaction scene library and the initial case library to obtain the transaction test case corresponding to the transaction scene data, the processor 110 specifically executes the following operations:

In one embodiment, the processor 110 is further adapted to execute a transaction task corresponding to the acquired transaction platform, and invoke a transaction test case based on the transaction platform to execute the transaction task;

and acquiring an un-called reference transaction test case, and calculating test case coverage information based on the reference transaction test case and the transaction test case.

In one embodiment, before executing the test on the transaction platform using the transaction test case, the processor 110 specifically performs the following operations:

acquiring reference transaction data;

judging whether the reference transaction data is abnormal;

if the reference transaction data is of a data exception type, carrying out case data construction on the reference transaction data to obtain a newly-added transaction test case corresponding to the reference transaction data;

and updating the transaction test case based on the newly added transaction test case.

In one embodiment, the processor 110, when executing the determination of whether the reference transaction data is data-anomalous, specifically performs the following operations:

In one embodiment, the processor 110, when performing feature matching of the historical reference warning feature with the reference warning feature, specifically performs the following operations:

In one embodiment, when the processor 110 performs the test on the transaction platform using the transaction test case to obtain the test result, the following operations are specifically performed:

Obtaining a result verification scheme corresponding to the transaction test case;

testing the transaction platform by adopting a transaction test case to obtain a test operation result;

and verifying the test operation result based on the result verification scheme to obtain a test result.

Those skilled in the art will appreciate that implementing all or part of the above-described methods in accordance with the embodiments may be accomplished by way of a computer program stored on a computer readable storage medium, which when executed may comprise the steps of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a read-only memory, a random access memory, or the like.

It should be noted that, information (including but not limited to user equipment information, user personal information, etc.), data (including but not limited to data for analysis, stored data, presented data, etc.), and signals according to the embodiments of the present disclosure are all authorized by the user or are fully authorized by the parties, and the collection, use, and processing of relevant data is required to comply with relevant laws and regulations and standards of relevant countries and regions. For example, object features, interactive behavior features, user information, and the like referred to in this specification are all acquired with sufficient authorization.

The foregoing disclosure is only illustrative of the preferred embodiments of the present invention and is not to be construed as limiting the scope of the claims, which follow the meaning of the claims of the present invention.

Claims

1. A transaction testing method, the method comprising:

2. The method of claim 1, the performing feature extraction processing on the historical transaction data to generate transaction context data, comprising:

carrying out transaction association processing on the historical transaction data to obtain associated historical transaction data;

3. The method of claim 2, wherein performing transaction association processing on the historical transaction data to obtain associated historical transaction data comprises:

and determining at least one transaction table data corresponding to the historical transaction from the historical transaction data, and performing transaction table association processing on all transaction table data of the same historical transaction to obtain association historical transaction data corresponding to the historical transaction.

4. The method of claim 2, wherein the performing transaction scenario feature extraction on each associated historical transaction data to obtain candidate transaction scenario features, and performing feature screening processing on the candidate transaction scenario features to obtain target transaction scenario features, includes:

and acquiring at least one reference transaction scene type tag, and filtering scene characteristics of the candidate transaction scene characteristics based on the reference transaction scene tag to obtain target transaction scene characteristics.

5. The method of claim 2, wherein the performing the scenerising of the target transaction scene feature to obtain transaction scene data under at least one transaction scene type tag comprises:

and acquiring a transaction scene type tag, screening the initial transaction scene data based on the transaction scene type tag and the initial scene type to obtain at least one associated historical scene transaction data under the transaction scene type tag, and combining all the associated historical scene transaction data under the same transaction scene type tag to obtain the transaction scene data.

6. The method of claim 1, wherein the constructing the case data for the transaction scenario data based on the historical transaction data to obtain the transaction test case corresponding to the transaction scenario data comprises:

generating a transaction context library based on the transaction context data;

7. The method of claim 6, wherein the performing scene data combination processing based on the transaction scene library and the initial case library to obtain the transaction test case corresponding to the transaction scene data, comprises:

acquiring at least one transaction characteristic feature in the initial use case library and at least one scene data combination in the transaction scene library, wherein the scene data combination comprises transaction scene data corresponding to at least two transaction scene type tags;

and randomly combining the transaction characteristic features and the scene data combination to obtain a transaction test case corresponding to the transaction scene data.

8. The method of claim 1, the method further comprising:

acquiring a transaction task corresponding to the transaction platform, and calling the transaction test case to execute the transaction task based on the transaction platform;

9. The method of claim 1, wherein the testing the transaction platform using the transaction test case, before obtaining the test result, comprises:

Acquiring reference transaction data;

judging whether the reference transaction data is abnormal;

10. The method of claim 9, the determining whether the reference transaction data is data-anomalous comprising:

extracting historical reference early warning features from the historical transaction data, and extracting reference early warning features from the reference transaction data;

and performing feature matching on the historical reference early warning feature and the reference early warning feature, wherein when the historical reference early warning feature is not matched with the reference early warning feature, the reference transaction data is of a data abnormality type.

11. The method of claim 10, the feature matching the historical reference warning feature with the reference warning feature, comprising:

judging whether the characteristic value of the reference early warning characteristic falls into the reference characteristic value distribution range, and if the characteristic value of the reference early warning characteristic does not fall into the reference characteristic value distribution range, the historical reference early warning characteristic is not matched with the reference early warning characteristic.

12. The method of claim 1, wherein the testing the transaction platform with the transaction test case to obtain the test result comprises:

testing the transaction platform by adopting the transaction test case to obtain a test operation result;

13. A transaction testing device, the device comprising:

14. A computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the method steps of any one of claims 1 to 12.

15. A computer program product storing at least one instruction for loading by a processor and performing the method steps of any one of claims 1 to 12.

16. An electronic device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the method steps of any of claims 1-12.