CN112632056B - Method and device for generating inspection rule - Google Patents

Abstract

The specification discloses a method and a device for generating a check rule, which are used for generating the check rule suitable for a specified service type. Generating a snapshot for the service data when the service data corresponding to the service changes in the service execution process; the method comprises the following steps: acquiring a service data sample set of the specified service type, and acquiring a snapshot set generated aiming at each piece of service data in the set; traversing the service data in the service data sample set, and generating an alternative test rule suitable for each piece of service data based on the snapshot set of each piece of service data; and counting the generated multiple alternative test rules, and determining the alternative test rules meeting the preset counting requirements as formal test rules suitable for the specified service types.

Description

Method and device for generating inspection rule

Technical Field

The embodiment of the specification relates to the technical field of computer application, in particular to a method and a device for generating a check rule.

Background

A service system usually generates a large amount of service data in the process of executing a service, and due to a fault of the service system or illegal execution of the service, a part of wrong service data may be generated, which affects the operation of the service system or causes a loss of a service party. For example, in a commodity transaction service, after an order fails to pay, due to the failure of a service system, a user is allowed to apply for a refund for the order and the refund is successful, so that a loss of a merchant is caused. To avoid or reduce the above-mentioned situation, the service data needs to be checked to find errors therein.

In order to implement the inspection of the service data, one existing method is to inspect the service data by using a predetermined inspection rule. If the business data does not conform to the check rule, it can be determined that the business data has an error. For example, in a commodity transaction business, the pre-established inspection rule may be: if the order payment fails, the user is only allowed to query the order. If the user can still apply for refund after the order payment fails in a piece of business data, the business data can be determined to have errors.

However, the verification rules are usually manually summarized based on experience, and are iterated with continuous update of the business, or in the case of complex business data, the efficiency of manually summarizing the verification rules is low, and it is difficult to effectively help verify errors in the business data.

Disclosure of Invention

In order to solve the above technical problem, the present specification provides a method and an apparatus for generating a verification rule. The technical scheme is as follows.

A generation method of inspection rule is used for generating the inspection rule suitable for the specified service type; generating a snapshot for the service data when the service data corresponding to the service changes in the service execution process; the method comprises the following steps:

acquiring a service data sample set of the specified service type, and acquiring a snapshot set generated aiming at each piece of service data in the set;

traversing the service data in the service data sample set, and generating an alternative test rule suitable for each piece of service data based on the snapshot set of each piece of service data;

and counting the generated multiple alternative test rules, and determining the alternative test rules meeting the preset counting requirements as formal test rules suitable for the specified service types.

The generation device of the inspection rule is used for generating the inspection rule applicable to the specified service type; generating a snapshot for the service data when the service data corresponding to the service changes in the service execution process; the device comprises:

a snapshot set acquisition unit: the snapshot collection is used for acquiring the business data sample collection of the specified business type, and acquiring the snapshot collection generated aiming at each piece of business data in the collection;

an alternative rule generating unit: the snapshot collection is used for traversing the business data in the business data sample collection and generating an alternative test rule suitable for each piece of business data based on the snapshot collection of each piece of business data;

a statistic unit: and the system is used for counting the generated multiple candidate inspection rules and determining the candidate inspection rules meeting the preset counting requirements as formal inspection rules suitable for the specified service types.

According to the technical scheme, the multiple alternative inspection rules are automatically generated through the machine based on the snapshot set of the business data, and the formal inspection rule is further determined from the alternative inspection rules based on statistics, so that the inspection rules are summarized from the business data by utilizing the machine instead of manpower, the efficiency of summarizing the inspection rules is improved, and errors in the business data can be effectively checked.

Drawings

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present specification, and other drawings can be obtained by those skilled in the art according to the drawings.

Fig. 1 is a schematic diagram of a state machine of a commodity transaction service provided in an embodiment of the present specification;

fig. 2 is a schematic flowchart of a method for generating a verification rule according to an embodiment of the present disclosure;

fig. 3 is a schematic structural diagram of an apparatus for generating a verification rule according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram of another verification rule generation apparatus provided in the embodiments of the present specification;

fig. 5 is a schematic structural diagram of an apparatus for configuring a method according to an embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the embodiments of the present specification, the technical solutions in the embodiments of the present specification will be described in detail below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all the embodiments. All other embodiments derived by one of ordinary skill in the art from the embodiments given herein are intended to fall within the scope of the disclosure.

A service system usually generates a large amount of service data in the process of executing a service, and due to a fault of the service system or illegal execution of the service, a part of wrong service data may be generated, which affects the operation of the service system or causes a loss of a service party. For example, in a commodity transaction service, after an order fails to pay, due to the failure of a service system, a user is allowed to apply for a refund for the order and the refund is successful, so that a loss of a merchant is caused. To avoid or reduce the above-mentioned situation, the service data needs to be checked to find errors therein.

In order to implement the inspection of the service data, one existing method is to inspect the service data by using a predetermined inspection rule. If the business data does not conform to the check rule, it can be determined that the business data has an error.

For example, in the commodity transaction service, the payment failure status for the order cannot be converted into the refund application status by performing any operation conventionally, because the user originally failed to pay and did not pay, and cannot apply for the refund. Thus, the pre-established verification rules may include: if the order payment fails, the user is only allowed to query the order. If a piece of business data is verified, and the user can still apply for refund after the order payment fails, the business data can be determined to have errors.

However, the inspection rule is usually manually summarized based on experience, and may be summarized based on a plurality of pieces of business data through analysis of actual business meaning of each field value in the business data, analysis of association relationship between the business data, and the like. With the continuous update and iteration of the service, or in the case of complex service data, the efficiency of manually summarizing the inspection rule is low, and it is difficult to effectively help to inspect errors in the service data.

In order to solve the above problems, the present specification provides a method for generating a verification rule for verification of business data by automatically generating a verification rule from a plurality of pieces of business data by a machine.

Even in the face of update iteration of business or the situation of complex business data, the efficiency of summarizing the inspection rule through a machine is higher than that of manually summarizing, and errors in the business data can be effectively checked.

The inspection rule generation method provided by the specification mainly extracts information contained in business data through a machine, generates corresponding preliminary inspection rules and carries out statistics, and determines the preliminary inspection rules meeting the statistical requirements as formal inspection rules.

The following provides a brief explanation of the business data and the verification rules involved in the verification rule generation method provided in the present specification.

1. And (4) service data.

The service data may be data generated during the execution of the service, and may be data for describing the service execution process and characterizing related information during the service execution process. For example, service type information, service execution time information, service object information, service transaction amount information, etc.

For convenience of understanding, in an alternative embodiment, the service data generated during the service execution process may be stored in a service database, and as the service execution process progresses, the corresponding service data may be updated in the service database according to the update of the service-related information.

For example, in a business of commodity transaction, for a commodity transaction, a piece of business data may be used to represent relevant information of the commodity transaction process. The related information may specifically include a commodity transaction type, commodity information, a commodity identifier, a transaction user identifier, transaction time, a commodity unit price, a transaction commodity quantity, a transaction amount, and whether to pay.

When the commodity starts to trade, a corresponding service data may be created in the service database, which may include the initial value of the related information. With the transaction, the number of the transaction commodities may change, the amount of the deal may also change with the number of the transaction commodities and the actual preferential conditions, and according to the change conditions, the corresponding service data in the service database may be updated in real time.

For convenience of understanding, the initial value of the transaction amount is 5 by taking the transaction amount in the service data as an example; as the user increases the number of traded goods by 10, the value of the deal amount changes from 5 to 50; as the user adds 30 coupons, the value of the deal amount changes from 50 to 20.

After the service data is interpreted, the following is an explanation of information that may be contained in the service data.

1) Service type information.

In an optional embodiment, the service data may include service type information, which is used to characterize a type of a service executed corresponding to the service data. The service type may be an identification of a certain service and is a characteristic that is distinguished from other services.

For example, the service database includes service data of a commodity transaction service, service data of an article rental service, and service data of other services. In order to distinguish different services, the service type information may be used for the distinction. The business data of the commodity transaction business can all contain business type information representing commodity transaction; the business data of the commodity leasing business can contain business type information representing commodity leasing.

In an alternative embodiment, the service type information may be specifically characterized by one or more fields of the service data (as a service type field).

For example, the service type information may be specifically represented by 1 field of the service identification field, and in the case that "commodity transaction" is represented by 101, the value of the service identification field included in the service data of the commodity transaction service may be 101.

Or, the service type information may be represented by using 2 fields, namely, the service large classification field and the service fine classification field. In the major classification "transaction", the minor classification "commodity transaction" and "service transaction" are also included, so the value of the business major classification field included in the business data of the commodity transaction business may be "transaction", the value of the business minor classification field included may be "commodity transaction", and the values of the 2 fields may collectively represent the business type information of "commodity transaction".

2) Traffic status information.

In an alternative embodiment, the service data may include service state information for characterizing the state of the service during execution.

The traffic state may be used to characterize the phases that the traffic may exist in the execution or various conditions that may occur in the execution. The partial traffic state may also transition to other states based on partial operations.

For example, in the business of commodity transaction, there may be a creation phase, a payment phase, a refund phase, and a closing phase along with the course of commodity transaction. There may be a success or failure corresponding to both the payment phase and the refund phase. Thus, there may be states of order creation, deal amount calculation, payment success, payment failure, application for refund, successful refund, failure to refund, order close, and so forth.

Obviously, after the order is created, the transaction amount can be calculated according to the quantity of the commodities in the order, the unit price of the commodities and the preferential condition. And then the payment success status and the payment failure status can be divided according to different payment conditions of the customers. And after the payment fails, the business state is converted into an order closing state to finish the transaction. After the payment is successful, the payment can be converted into an order closing state to finish the transaction, and can also be converted into a refund application state, so that the payment is converted into a refund success state or a refund failure state according to the refund condition, and then the payment is converted into an order closing state to finish the transaction.

In an alternative embodiment, in order to facilitate management of the execution process of the service and to facilitate location of the stage or situation of the current service in the execution process, the stage or situation that may exist in the execution process of the service is generally predefined as a plurality of service states, and a state machine may be constructed according to the transition relationship between the plurality of service states. Transitions between states need to conform to the specifications of the state machine.

Fig. 1 is a schematic diagram of a state machine of a commodity transaction service provided in this specification.

The state nodes comprise 7 states of order creation, payment success, payment failure, refund application, refund success, refund failure and order closing.

The service in the order creation state can be converted into a successful payment state through the event of 'payment of the transaction amount by the client within the preset time length'; the payment can be converted into a payment failure state through the event that the client does not pay the transaction amount within the preset time length.

The service in the payment success state can be converted into a refund application state through the fact that the client applies for refund; the transaction can be ended by converting the event of 'no operation within the preset time length of the customer' into an order closing state.

The service in the payment failure state can be converted into an order closing state to finish the transaction through the fact that no operation is performed within the preset time length of the client.

The service in the refund application state can be converted into a refund success state by judging that the transaction meets the refund standard and the refund is successful, and further can be converted into an order closing state to finish the transaction by judging that the transaction does not operate within the preset time length of the client; the refund failure status may be converted by any event of "determine transaction does not meet refund criteria" or "determine transaction does meet refund criteria but cannot refund".

The service in the refund failure state can be converted into an order closing state through the fact that no operation is performed within the preset time of a client, and then the transaction is finished; the refund application state can also be converted by the event of 'customer re-applying refund'.

Furthermore, it is worth emphasizing that a special state, i.e. an initial state, exists among the traffic states. The service must be in an initial state when it begins execution. For example, for the commodity transaction service described above, the initial state may include an order creation state. A commodity transaction must begin with order creation and if it begins in another state, it is not compliant with the business rules.

And the initial state may be one or more. For example, in a commodity transaction service, the initial state may include an order creation state and a payment success state.

And adding the order with successful payment into the service database to execute the commodity transaction service, namely, the order does not need to be created, and the initial state can be a successful payment state.

In an alternative embodiment, the traffic status information may be specifically characterized by one or more fields of the traffic data (as traffic status fields). In general, traffic state information may be characterized by a single field. The manner of characterizing the traffic status information is not limited. For example, different traffic states may be characterized by labels. "1" characterizes "order creation", "2" characterizes "refund application", etc.

3) A service key field.

In an alternative embodiment, the service data may include one or more key fields, which may be fields used to characterize important information in the service, requiring an emphasis check.

The key field may be specified according to actual requirements of the service, and is not particularly limited.

For example, in the business data of the commodity transaction business, the commodity unit price can be used as a key field, although the transaction amount may vary due to the quantity of commodities and the preference, the commodity unit price should be constant, and if there is a case of modification or variation, it indicates that there is an error in this business data.

4) Other information.

In an optional embodiment, the service data may include identification information of the service execution, which is used to uniquely identify the service execution.

For example, in a commodity transaction service, a commodity transaction may be marked with an order number. When the commodity starts to trade, an order is created, and a unique order number is created, so that the data related to the commodity trade can be conveniently inquired subsequently.

It should be noted that a piece of service data may include any one of the above information, and it is not limited that a piece of service data necessarily includes all the above information.

2. And checking the rule.

The method provided by the specification mainly extracts information contained in the service data and constructs the inspection rule.

In an alternative embodiment, the checking rules may be constructed separately for different traffic types, since traffic under the same traffic type generally follows the same specification, whereas traffic under different traffic types may not follow the same specification.

For example, for the business of commodity transaction, a refund application state exists according to the constructed state machine; for the stock trading business, the state of refund application does not exist, and the state of buying and selling can exist.

Thus, the validation rules may include a determination of the type of traffic. After the type of the service to which the service data to be inspected belongs is determined, a corresponding specification can be determined for inspection.

In an alternative embodiment, a verification rule may include a precondition and a specification.

The precondition in the check rule can be used for judging whether the service type of the service data to be checked is a specified service type. In the case that the service type to which the service data to be inspected belongs is determined to be the specified service type, the inspection can be further performed by using the specification in the inspection rule.

The specific specification may be determined based on the information included in the service data, and various specifications may be summarized according to the information included in the service data, thereby generating various inspection rules. Examples of 3 specifications are given below.

1) And (4) specification of an initial state.

In an alternative embodiment, the precondition may be generated based on the service type information included in the service data, and the state machine may be further generated based on the service state information included in the service data.

Since there is a limit to the initial state in the service, the service must start from the initial state at each execution, and there may be more than one initial state. The specification for the initial state can thus be generated by summarizing the earliest occurring state information as a possible initial state from the traffic state information contained in the traffic data. And determining whether the earliest state of the service data to be detected is the initial state according to the initial state specification aiming at the service data to be detected.

2) And (4) state switching specification.

In an alternative embodiment, the precondition may be generated based on the service type information included in the service data, and the state machine may be further generated based on the service state information included in the service data.

In the state machine, the switching between the service states must be based on a specified event, the states can be switched only when the specified event is monitored, and no switching relation exists between partial service states. Therefore, the switching situation that may occur between the service states can be summarized from the service state information included in the service data, and a specification for state switching can be generated. And determining whether the switching relation between the states in the service data to be detected exists according to the state switching specification aiming at the service data to be detected.

3) The key field specification.

In an alternative embodiment, the precondition may be generated based on the service type information included in the service data, and the specification may be further generated based on a key field included in the service data.

For the key fields, a specification may be generated according to the actual requirements of the service. For example, it may be determined whether the value of the key field is variable; or it may be determined whether the value of the key field should be limited to a range of values. Thereby generating a specification corresponding to the key field.

In a specific example, in the business data of the commodity transaction, the key fields may be commodity unit price and deal amount, and if the specification needs to be generated according to whether the value of the key field is variable, it may be determined that the commodity unit price is unchangeable and the deal amount is variable based on the plurality of pieces of business data. Further, the key field specification can be utilized to determine whether the change occurs or not aiming at the key field (commodity unit price) in the service data to be detected. If the unit price of the commodity changes, the business data to be checked has errors.

A method for generating the verification rule provided in the present specification is explained in detail below with reference to the drawings.

Fig. 2 is a schematic flow chart of a method for generating a verification rule provided in this specification.

Optionally, in the service execution process, when the service data corresponding to the service changes, a snapshot for the service data may be generated. Correspondingly, each time the service data changes, a snapshot for the service data can be generated, so that a plurality of snapshots can be obtained to record all the change processes of the service data in the service execution process.

Therein, it is understood that the earliest snapshot may be generated upon initialization of the traffic data. The snapshots generated may also have a timing relationship between them.

In addition, the process of generating the check rule for the service data of a single specified service type is mainly explained, and it can be understood that the process of generating the check rule for the service data of a plurality of different service types can be obtained through simple reasoning.

The method may comprise at least the following steps.

S101: the method comprises the steps of obtaining a business data sample set of a specified business type, and obtaining a snapshot set generated aiming at each piece of business data in the business data sample set.

Because the flow of the method is based on a plurality of pieces of business data to generate the check rule, the plurality of pieces of business data are selected samples.

Alternatively, the service data sample set may be a plurality of pieces of service data of a specific service type randomly selected from a service database.

Optionally, a plurality of pieces of trusted service data of a specified service type may be added to the service data sample set; the trusted service data can be service data generated by a service trusted execution process based on a specified service type. Because the credible execution process of the business is in accordance with the business specification and has no error, the correct check rule can be conveniently generated.

The snapshot set may include at least one snapshot generated for one piece of business data, and may record multiple changes of one piece of business data.

To facilitate understanding of the snapshot, in an alternative embodiment, the change of the same piece of business data in the business database may be as shown in table 1 below.

And updating the data in the same service data according to the change of the value of the transaction amount in the service progress process. And corresponding to each change, all the information after the change of the service data can be saved as a snapshot. That is, each piece of data in table 1 above is a snapshot of the service data.

The snapshot set may be used in subsequent steps to verify the generation of rules.

In an optional embodiment, the snapshot set generated for each piece of business data may include all snapshots generated for the piece of business data, so that all changes (i.e., information of all changes) of the piece of business data may be included in the snapshot set, and it is further convenient to directly obtain required information according to the snapshot set to generate the check rule.

In another alternative embodiment, at least one snapshot related to the change of the specified information may also be obtained as the snapshot set from all the snapshots generated for one piece of business data according to the specified information required by the subsequently generated check rule. The embodiment can reduce the size of the snapshot set required to be acquired aiming at each piece of service data, and is convenient for accelerating the generation efficiency of the inspection rule subsequently.

Based on the above explanation of the inspection rule, optionally, in order to generate the inspection rule related to the initial state specification, only the snapshot related to the initial state may be obtained, and the first earliest snapshot of the business data, that is, all information included in the business data creation, may be included in the snapshot set.

Alternatively, in order to generate the inspection rule related to the stateful switchover specification, only the snapshot related to the stateful switchover, that is, the snapshot generated when the value of the service state field changes, may be acquired. Therefore, the snapshot set may include all snapshots generated by the service data when the value of the service status field changes.

Alternatively, in order to generate the verification rule related to the key field specification, only the snapshot generated when the value of the key field changes may be obtained. Therefore, the snapshot set may include all snapshots generated when the value of the key field changes in the business data.

S102: and traversing the service data in the service data sample set, and generating an alternative test rule suitable for each piece of service data based on the snapshot set of each piece of service data.

Based on the above explanation of the information contained in the service data, in an alternative embodiment, a piece of service data may include one or more service type fields and a service status field. One or more service type fields can be used for commonly representing the service type of a piece of service data; the service status field can be used to characterize the status of the service to which a piece of service data belongs during execution. In this embodiment, the following 2 alternative checking rules related to the traffic state may be generated conveniently.

1) An alternative checking rule for the initial state of the traffic.

Alternatively, the alternative verification rule may include preconditions and specifications when generating the alternative verification rule, which may be a rule for verifying the initial state of the service.

Therefore, the earliest snapshot in the snapshot set can be determined based on each piece of business data, a precondition is generated according to the values of all the business type fields of the snapshot, and a specification is generated according to the values of the business state fields of the snapshot, so that an alternative test rule suitable for the piece of business data is obtained.

The generated precondition can be used to determine whether the values of all the service type fields included in a piece of service data to be checked are the same as the values of all the service type fields included in the snapshot. That is, the precondition may be used to determine whether the type of the service to which the service data to be checked belongs is the same as the type of the service to which the snapshot belongs.

The generated specification may be used to characterize the value of the traffic state field of the snapshot, and specifically, to help determine whether the value of the traffic state field of a piece of traffic data to be checked is the same as the value of the traffic state field of the snapshot in the initial state.

It should be noted that the alternative check rule generated for a piece of service data to check the initial state of the service only indicates the initial state in one service execution process, and is applicable to the piece of service data, and cannot include all the initial states that may exist in the service.

For ease of understanding, a specific example of an alternative verification rule is given below.

From a set of snapshots of the business data, the earliest snapshot is determined as shown in table 2 below.

Serial number	Type of service	Traffic state	Service identification
				1	Trade of goods	Order creation	011

TABLE 2 earliest snapshot of a piece of business data

Then alternative verification rules may be generated as: if (service type = 'commodity transaction'), then (service initial state = 'order creation').

Of course, the form of the alternative verification rule is not limited, and may be IF (business type = 'commodity transaction') THEN (business initial state = 'order creation'), as long as the preconditions and specifications described above can be characterized.

2) Alternative verification rules for traffic state switching.

Alternatively, when generating the alternative verification rule, the generated alternative verification rule may be a rule for verifying a traffic state switch.

Therefore, based on the snapshot set of each piece of business data, for any one snapshot, a precondition is generated according to the values of all the business type fields of the snapshot, and a specification is generated according to the value of the business state field of the snapshot and the value of the business state field of the previous snapshot of the snapshot, so that an alternative test rule applicable to the piece of business data is obtained.

It should be emphasized that the snapshot before the snapshot refers to, among the snapshots of the business data having a time series relationship, the snapshot immediately before the snapshot in the time series relationship. Specifically, all snapshots in a snapshot set of the service data may be sorted according to the sequence of the time sequence relationship, and then a snapshot immediately before the snapshot in the sorting may be determined.

The switching relation between the service states can be determined by the value of the service state field of the snapshot and the value of the service state field of the previous snapshot of the snapshot, so that the specification of service state switching is generated.

In an alternative embodiment, a plurality of alternative test rules applicable to the piece of business data may be generated for a plurality of snapshots in the snapshot set.

For the explanation of other preconditions, reference is made to the above, which is not described in detail here. It should be noted that the candidate inspection rule generated for inspecting the service state switching for a piece of service data only indicates the state switching situation in one service execution process, and is applicable to the piece of service data, and cannot include all the state switching situations that may exist in the service.

For ease of understanding, a specific example of another alternative verification rule is given below.

The snapshot set for a piece of business data is determined as shown in table 3 below.

Serial number	Type of service	Traffic state	Service time
				1	Trade of goods	S1	11：00
2	Trade of goods	S2	11：01
				3	Trade of goods	S4	11：03

TABLE 3 snapshot set of a piece of business data

Then 2 alternative test rules can be generated, respectively: if (transaction type = 'commodity transaction') (S1 may be switched to S2), and if (transaction type = 'commodity transaction') (S2 may be switched to S4).

Of course, the form of the alternative check rule is not limited, and may be IF (traffic type = 'commodity transaction') THEN (S1 → S2); IF (traffic type = 'commodity transaction') THEN (S2 → S4), as long as the preconditions and specifications described above can be characterized.

3) Alternative verification rules for key fields.

When generating the alternative checking rule related to the key field, because the service state is not needed, based on the above explanation on the information contained in the service data, in an alternative embodiment, a piece of service data may include one or more service type fields and one or more key fields; one or more service type fields are used for commonly representing the service type of one piece of service data.

In this embodiment, it may be convenient to generate alternative verification rules to which the key fields relate.

Optionally, the generated alternative checking rule may be used to check whether the key field is variable, or may be used to check whether the value of the key field is limited to a fixed value range.

For convenience of understanding, in an alternative embodiment, in order to generate an alternative check rule for checking whether a key field is variable, based on a snapshot set of each piece of business data, a precondition may be generated according to values of all business type fields of any one of the snapshots, and a specification is generated according to a value of the key field of the snapshot and a value of the key field of a snapshot before the snapshot, so as to obtain the alternative check rule applicable to the piece of business data.

For the explanation of the previous snapshot, see above, the description is omitted here.

Whether the key field changes between the two snapshots can be determined through the two snapshots which are immediately adjacent in time sequence, and if the key field changes, the key field can be directly determined to be variable; if no change has occurred, it may be determined that there is no change between the two snapshots.

Further, in an alternative embodiment, the key field may be determined to be immutable if it is determined from the snapshot set that no change has occurred to the key field throughout the business execution.

Specifically, the generated alternative check rules can be merged according to the key fields, and for one key field, if all specifications in all the alternative check rules generated based on the snapshot set are invariable, one alternative check rule is generated to represent that the key field is invariable; if there is one of the specifications in all of the alternative validation rules generated based on the snapshot set that is variable, then generating an alternative validation rule characterizes the key field as variable.

It should be noted that the alternative check rule generated for a piece of service data to check whether the key field is variable only indicates whether there is a change in the key field during one service execution, and is applicable to the piece of service data, and does not mean that the key field is not variable during each service execution.

In addition, if an alternative check rule indicates that a certain key field is variable, the value of the key field may or may not be changed in the process of executing the service, and the alternative check rule is not violated.

For ease of understanding, a specific example of another alternative verification rule is given below.

A snapshot set of business data is determined as shown in table 4 below, where the key fields include unit price of the item and amount of the deal.

Serial number	Type of service	Price per unit of goods	Amount of transaction	Transaction time
					1	Trade of goods	5	60	11：00
2	Trade of goods	5	58	11：01
					3	Trade of goods	5	58	11：03

TABLE 4 snapshot set of a piece of business data

Then 2 alternative test rules may be generated, which are: if (transaction type = 'commodity transaction') (commodity unit price is not variable), if (transaction type = 'commodity transaction') (transaction amount is variable), and if (transaction type = 'commodity transaction') (transaction amount is not variable).

Alternatively, after merging according to the key fields, 2 alternative check rules can be obtained, if (transaction type = 'commodity transaction') (commodity unit price is not variable), if (transaction type = 'commodity transaction') (transaction amount is variable).

Of course, the form of the alternative check rule is not limited, and may also be IF (type of service = 'commodity transaction') THEN (commodity unit price); IF (transaction type = 'commodity transaction') THEN (transaction amount: table), as long as the preconditions and specifications described above can be characterized.

Of course, the above description is only for generating the alternative checking rule according to whether the key field is variable, and the alternative checking rules related to other key fields may be derived based on the same logic derivation, and are not described herein again. For example, the value range of the key field may be determined according to the maximum value and the minimum value of the key field in the snapshot set.

After the generation process of the above 3 alternative verification rules is explained, it should be noted that the verification rules in this specification are not limited to the above 3 verification rules, and any verification rules that can be obtained based on the snapshot set are within the scope disclosed in this specification.

While the generation process of other inspection rules can be obtained by simple reasoning based on the generation process of the above-mentioned 3 inspection rules. The check rule may be specifically configured to, when the precondition is used to determine that the type of the service to which the piece of service data to be checked belongs is the same as the type of the service to which the snapshot belongs, determine whether the piece of service data to be checked meets a specification in the check rule.

The following explains the "alternative verification rule".

Because the basis of the alternative inspection rule is only one piece of business data, the possibility that the business data has errors cannot be eliminated; in addition, for the error check of the service data, a complete check rule is required for checking, for example, there may be a plurality of initial states of the service, and only one initial state of the service can be determined by one piece of service data, and the generated check rule is not complete.

Therefore, for the alternative inspection rules, the formal inspection rules are determined through screening.

S103: and counting the generated multiple alternative test rules, and determining the alternative test rules meeting the preset counting requirements as formal test rules suitable for the specified service types.

In an alternative embodiment, since different traffic data may generate the same candidate test rule, the number of the same candidate test rule generated may be counted for each candidate test rule.

Optionally, the preset statistical requirement may include that the number of generated identical rules is greater than a preset number. If the number of the generated same rules is larger than the preset number, the corresponding alternative check rule can be determined as a formal check rule, and the formal check rule can be applicable to the specified service type.

Alternatively, the preset statistical requirement may include that the proportion of the generated same rule in all the generated rules is greater than a preset proportion. If the proportion of the generated same rule in all the generated rules is larger than the preset proportion, the corresponding alternative check rule can be determined as a formal check rule and can be applicable to the specified service type.

Because the wrong service data are usually not much or the proportion is not large, the wrong alternative test rule generated according to the wrong service data can be screened out through the statistical screening process, and the correct alternative test rule is reserved.

In addition, as the same alternative check rule is more, the business data based on the formal check rule is more, and the correctness of the formal check rule can be ensured to a certain extent.

Since the formal verification rule is determined according to the alternative verification rule, in an alternative embodiment, the formal verification rule may include preconditions and specifications; the precondition can be used for determining whether the service data to be checked belongs to a specified service type; the formal proof rules may be used to determine whether the business data to be checked belonging to a specified business type complies with the specifications in the formal proof rules.

In order to ensure that the business data is checked based on the complete check rule when the formal check rule is used for checking the business data, in an alternative embodiment, the formal check rule may be distributed, and in a specific check, all the determined formal check rules may be traversed for checking.

If the business data to be checked does not pass the check of any formal check rule after the traversal, the business data to be checked can be determined to have errors.

And if the business data to be checked passes the check of any formal check rule, the business data to be checked can be determined to be in accordance with the specification in the formal check rule.

It is noted that based on the above analysis, different formal verification rules may be to verify different specifications, such as an initial traffic state specification, a traffic state transition specification, and so on.

At least one formal inspection rule may exist for the same specification, and if the service data to be inspected does not pass the inspection of any formal inspection rule under the specification after traversal, it can be determined that the service data to be inspected has an error on the specification.

In an alternative embodiment, formal verification rules may be combined to facilitate subsequent verification without traversal.

Since all the determined formal verification rules have the same precondition and can be used for determining whether the service data to be verified belong to the specified service type, all the determined formal verification rules can be merged based on the same precondition.

Alternatively, a comprehensive inspection rule applicable to a specific service type may be obtained by integrating all the determined formal inspection rules. Wherein the composite verification rule may include a set of preconditions and specifications. All of the specifications contained in all of the generated formal verification rules may be included in the set of specifications. The association between the specifications may be made using an 'or'.

Optionally, at least one comprehensive inspection rule applicable to a specific service type for inspecting a certain specification may be obtained according to different specifications (specifically, specifications for inspecting different contents) based on all the determined formal inspection rules. Wherein the composite verification rule may include a set of preconditions and specifications. All of the specifications contained in all of the generated formal verification rules may be included in the set of specifications. The association between the specifications may be made using an 'or'.

Obviously, after combination, the number of traversal can be reduced, and the inspection efficiency can be accelerated.

For ease of understanding, a specific example is given below. All official verification rules determined by the above process flow can be seen in table 5 below.

Precondition	Norm of
		Type of service = commodity transaction	Initial state = order creation
Type of service= trade of goods	Initial state = payment success
		Type of service = commodity transaction	Order creation conversion to payment success
Type of service = commodity transaction	Successful conversion of payment into a refund application
		Type of service = commodity transaction	Unit price of commodity: is not changeable
Type of service = commodity transaction	The amount of the deal: variable

TABLE 5 all official examination rules

Optionally, a composite verification rule may be combined, according to the above-mentioned combination possibilities. As follows.

If (transaction type = commodity transaction), then (initial state = order creation, or initial state = payment successful, or order creation converted to payment successful, or payment successful converted to a refund application, or commodity unit price: immutable, or transaction amount: variable).

Alternatively, the contents verified according to the specification may be combined into 3 comprehensive verification rules. As follows.

If (type of service = commodity transaction), then (initial status = order creation or payment success).

If (transaction type = commodity transaction), then (order creation translates to payment success, or payment success translates to a refund application).

If (type of service = commodity transaction), then (commodity unit price: invariable, or amount of transaction: variable).

It is worth emphasizing that for the check rule that the transaction amount is variable, if the transaction amount is not changed in the process of executing the service, the check rule is not violated.

The method automatically generates a plurality of alternative inspection rules based on the snapshot set of the business data through the machine, and further determines the formal inspection rule from the alternative inspection rules based on statistics, so that the inspection rules are summarized from the business data by utilizing the machine instead of manpower, the efficiency of summarizing the inspection rules is improved, and errors in the business data can be effectively checked.

In addition, it should be noted that, when the verification rule generated by the above method flow is used to verify the business data to be verified, at least one generated relevant snapshot needs to be acquired according to the verified content.

Alternatively, when the initial state is checked, an earliest generated snapshot may be obtained for the service data to be checked, the service state information in the snapshot may be obtained, and it may be determined whether the service state information exists in the check rule. Specifically, the value of the service status field in the snapshot may be obtained, and it is determined whether the value exists in the check rule.

For example, for a commodity transaction service, in a snapshot generated earliest for a piece of service data, the value of the service status field is acquired as 'failure to pay', and if (service type = commodity transaction) according to the verification rule (initial status = order creation or payment success), it is obvious that any specification in the verification rule is not met, and it is determined that there is an error in the piece of service data.

Optionally, when the inspection state is switched, a snapshot before the service data to be inspected in the time sequence relationship may be obtained, the service state information in the snapshot may be obtained, the service state information of the snapshot and the service state information of the service data to be inspected may be combined into a set of conversion relationship, and it may be determined whether the conversion relationship exists in the inspection rule. Specifically, the value of the service state field in the snapshot is obtained, and the value of the service state field of the service data to be checked are combined into a group of conversion relationships, so as to determine whether the conversion relationship exists in the check rule.

For example, for a commodity transaction service, in a previous snapshot generated for a piece of service data, the value of the service status field is obtained as 'payment failure', and the value of the service status field of the piece of service data is obtained as 'refund application'. The two values are combined into a set of conversion relationships, specifically 'Payment failure converted into a refund application'. If (business type = commodity transaction) according to the verification rule, then (order creation is converted into payment success, or payment success is converted into a refund application), obviously not meeting any specification in the verification rule, determining that the business data has errors.

Optionally, when checking whether the key field is variable, the value of the key field in the snapshot may be obtained for a previous snapshot in the time series relationship with respect to the service data to be checked, and the value of the key field in the snapshot may be compared with the value of the key field of the service data to be checked, to determine whether the change occurs, and to determine whether the specification of the key field in the check rule is met.

For example, for a commodity transaction service, in a previous snapshot generated for a piece of service data, a value of a key field 'commodity unit price' is acquired as '5', a value of a key field 'transaction amount' is acquired as '9', and a value of a key field 'commodity unit price' of the piece of service data is acquired as '8', and a value of a key field 'transaction amount' is acquired as '9'.

Wherein the unit price of the goods is changed, and the key field is not changed. If (business type = commodity transaction) according to the checking rule, then (commodity unit price: invariable, or transaction amount: variable), the commodity unit price should obviously not be changed, and an error exists; the deal amount may or may not be changed, and no error exists.

The present specification also provides device embodiments corresponding to the above method flows.

Fig. 3 is a schematic structural diagram of a verification rule generating apparatus provided in this specification. The apparatus may be adapted to generate a verification rule applicable to a specified traffic type. Generating a snapshot for the service data when the service data corresponding to the service changes in the service execution process; the apparatus may include at least the following elements.

Snapshot set acquisition unit 201: the method is used for acquiring a business data sample set of a specified business type, and acquiring a snapshot set generated aiming at each piece of business data in the business data sample set.

Alternative rule generating unit 202: the method is used for traversing the business data in the business data sample set, and generating an alternative test rule suitable for each piece of business data based on the snapshot set of each piece of business data.

The statistic unit 203: and the system is used for counting the generated multiple candidate inspection rules and determining the candidate inspection rules meeting the preset counting requirements as formal inspection rules suitable for the specified service types.

Wherein, the formal inspection rule can comprise a precondition and a specification; the precondition can be used for determining whether the service data to be checked belongs to a specified service type; the formal proof rules may be used to determine whether the business data to be checked belonging to a specified business type complies with the specifications contained in the formal proof rules.

Fig. 4 is a schematic structural diagram of another verification rule generating apparatus provided in this specification. In addition to the 3 units described above, a merging unit 204 may also be included.

All formal test rules determined by the statistical unit 203 may have the same preconditions.

The merging unit 204: the comprehensive inspection rule is used for combining all the determined formal inspection rules based on the same precondition to obtain a comprehensive inspection rule suitable for the specified service type; the comprehensive inspection rule may include a set of preconditions and specifications; the set of specifications may include all of the specifications contained in all of the determined formal verification rules.

The method for acquiring the service data sample set of the specified service type may include: adding a plurality of pieces of credible service data of the specified service type to a service data sample set of the specified service type; the credible business data is the business data generated in the credible business execution process.

In addition, a piece of service data may include one or more service type fields, and a service status field; one or more service type fields can be used for commonly representing the service type of a piece of service data; the service status field can be used to characterize the status of the service to which a piece of service data belongs during execution. Alternative verification rules may include preconditions and specifications.

Correspondingly, the alternative rule generating unit 202 may specifically be configured to: determining the earliest snapshot based on the snapshot set of each piece of business data, generating a precondition according to the values of all business type fields of the snapshot, and generating a specification according to the values of the business state fields of the snapshot to obtain an alternative test rule applicable to the piece of business data.

The alternative rule generating unit 202 may specifically be further configured to: based on the snapshot set of each piece of business data, aiming at any one snapshot, generating a precondition according to the values of all business type fields of the snapshot, and generating a specification according to the value of the business state field of the snapshot and the value of the business state field of the previous snapshot of the snapshot to obtain an alternative check rule applicable to the piece of business data.

A piece of service data may include one or more service type fields, and one or more key fields; one or more service type fields are used to jointly characterize the service type to which a piece of service data belongs.

Correspondingly, the alternative rule generating unit 202 may specifically be configured to: based on the snapshot set of each piece of business data, aiming at any key field of any snapshot, generating a precondition according to the values of all business type fields of the snapshot, and generating a specification according to the value of the key field of the snapshot and the value of the key field of the previous snapshot of the snapshot, so as to obtain an alternative test rule applicable to the piece of business data.

For a detailed explanation of the above device embodiments, reference may be made to the above process flow.

Embodiments of the present specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements a method for generating a verification rule when executing the program.

Fig. 5 is a schematic diagram illustrating a more specific hardware structure of a computer device according to an embodiment of the present disclosure, where the device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.

The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.

The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

Bus 1050 includes a path that transfers information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.

It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.

Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, which when executed by a processor implements a method for generating a verification rule.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present disclosure. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The foregoing is only a detailed description of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, many modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as protection for the embodiments of the present disclosure.

Claims (14)

1. A generation method of inspection rule is used for generating the inspection rule suitable for the specified service type; generating a snapshot for the service data when the service data corresponding to the service changes in the service execution process; the method comprises the following steps:

acquiring a service data sample set of the specified service type, and acquiring a snapshot set generated aiming at each piece of service data in the set;

traversing the service data in the service data sample set, and generating an alternative test rule suitable for each piece of service data based on the snapshot set of each piece of service data; the generation method of the alternative verification rule comprises the following steps: generating a precondition for the alternative inspection rule based on the specified service type; the precondition of the alternative inspection rule is used for determining whether the service data to be inspected belongs to the specified service type;

and counting the generated multiple alternative test rules, and determining the alternative test rules meeting the preset counting requirements as formal test rules suitable for the specified service types.

2. The method of claim 1, the formal verification rules comprising preconditions and specifications; the precondition is used for determining whether the service data to be checked belongs to the specified service type; and the formal inspection rule is used for determining whether the service data to be inspected, which belong to the specified service type, conforms to the specification.

3. The method of claim 2, all determined formal verification rules having the same preconditions; the method further comprises the following steps:

based on the same precondition, all the determined formal inspection rules are combined to obtain a comprehensive inspection rule applicable to the specified service type; the comprehensive inspection rule comprises a precondition and a specification set; the set of specifications includes all specifications contained in all of the formal verification rules.

4. The method of claim 1, wherein the method for obtaining the service data sample set of the specific service type comprises:

adding a plurality of pieces of credible business data of the specified business type to a business data sample set of the specified business type; the credible business data is the business data generated in the credible business execution process.

5. The method of claim 1, a piece of service data comprises one or more service type fields, and a service status field; the one or more service type fields are used for commonly representing the service type of a piece of service data; the service state field is used for representing the state of a service to which the service data belongs in the execution process.

6. The method of claim 5, the alternative verification rule comprising a precondition and a specification; the generating of the alternative test rule applicable to each piece of business data based on the snapshot set of each piece of business data includes:

determining the earliest snapshot based on the snapshot set of each piece of business data, generating a precondition according to the values of all business type fields of the snapshot, and generating a specification according to the values of the business state fields of the snapshot to obtain an alternative test rule applicable to the piece of business data.

7. The method of claim 5, the alternative verification rule comprising a precondition and a specification; the generating of the alternative test rule applicable to each piece of business data based on the snapshot set of each piece of business data includes:

based on the snapshot set of each piece of business data, aiming at any one snapshot, generating a precondition according to the values of all business type fields of the snapshot, and generating a specification according to the value of the business state field of the snapshot and the value of the business state field of the previous snapshot of the snapshot to obtain an alternative check rule applicable to the piece of business data.

8. The method of claim 1, a piece of service data comprises one or more service type fields, and one or more key fields; the one or more service type fields are used for commonly representing the service type of a piece of service data.

9. The method of claim 8, the alternative verification rule comprising a precondition and a specification; the generating of the alternative test rule applicable to each piece of business data based on the snapshot set of each piece of business data includes:

based on the snapshot set of each piece of business data, aiming at any key field of any snapshot, generating a precondition according to the values of all business type fields of the snapshot, and generating a specification according to the value of the key field of the snapshot and the value of the key field of the previous snapshot of the snapshot, so as to obtain an alternative test rule applicable to the piece of business data.

10. The generation device of the inspection rule is used for generating the inspection rule applicable to the specified service type; generating a snapshot for the service data when the service data corresponding to the service changes in the service execution process; the device comprises:

a snapshot set acquisition unit: the snapshot collection is used for acquiring the business data sample collection of the specified business type, and acquiring the snapshot collection generated aiming at each piece of business data in the collection;

an alternative rule generating unit: the snapshot collection is used for traversing the business data in the business data sample collection and generating an alternative test rule suitable for each piece of business data based on the snapshot collection of each piece of business data; the generation method of the alternative verification rule comprises the following steps: generating a precondition for the alternative inspection rule based on the specified service type; the precondition of the alternative inspection rule is used for determining whether the service data to be inspected belongs to the specified service type;

a statistic unit: and the system is used for counting the generated multiple candidate inspection rules and determining the candidate inspection rules meeting the preset counting requirements as formal inspection rules suitable for the specified service types.

11. The apparatus of claim 10, the formal verification rules comprising preconditions and specifications; the precondition is used for determining whether the service data to be checked belongs to the specified service type; and the formal inspection rule is used for determining whether the service data to be inspected, which belong to the specified service type, conforms to the specification.

12. The apparatus of claim 11, all determined formal verification rules have the same preconditions; the device further comprises:

a merging unit: the comprehensive inspection rule is used for combining all the determined formal inspection rules based on the same precondition to obtain a comprehensive inspection rule applicable to the specified service type; the comprehensive inspection rule comprises a precondition and a specification set; the set of specifications includes all specifications contained in all of the formal verification rules.

13. The apparatus of claim 10, the method for obtaining the service data sample set of the specified service type includes:

adding a plurality of pieces of credible business data of the specified business type to a business data sample set of the specified business type; the credible business data is the business data generated in the credible business execution process.

14. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 9 when executing the program.

Images