Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer and more complete, the technical solutions in the embodiments of the present invention will be described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention, and based on the embodiments of the present invention, all other embodiments obtained by a person of ordinary skill in the art without creative efforts belong to the scope of the present invention.
As shown in fig. 1, an embodiment of the present invention provides a service request checking method, which may include the following steps:
step 101: determining a field to be checked according to a plurality of service requests;
step 102: determining a check rule corresponding to a field to be checked according to a corresponding relation between a preset field and the check rule, wherein the check rule comprises a field-level check rule and a request-level check rule;
step 103: determining a field-level verification result of the field to be verified according to a field-level verification rule corresponding to the field to be verified;
step 104: and determining whether the plurality of service requests pass the verification according to the field-level verification result and the request-level verification rule corresponding to the field to be verified.
Wherein a service request is a piece of data. The field to be checked may be the same field of different service requests, or may be multiple fields of different service requests. For example, the field to be verified is a password field of 10 login requests, or the field to be verified is a password field and a login name field of 10 login requests.
The method can determine whether the field to be checked has problems, and can also determine whether a plurality of service requests have problems according to the field-level checking result of the field to be checked. The method can verify the overall situation of a plurality of service requests, and improve the quality of the service requests passing the verification.
As shown in fig. 2, an embodiment of the present invention provides a service request checking method, which may include the following steps:
step 201: several service requests are determined.
In the embodiment of the invention, a plurality of or a large number of service requests are required to be used as a check basis.
Step 202: and determining a field to be checked corresponding to the service request type in the field of the service request according to the preset corresponding relation between the service request type and the field.
The service request type may include a transaction request, a registration request, a login request, and the like. The service request type may be carried as a field in the service request.
Taking a login request as an example, as shown in table 1, the service request type in the login request is a1, the account number, nickname and password are fields in the login request, and a2, A3 and a4 are values of the corresponding fields. Wherein the service request type is present in the service request in the form of a field.
TABLE 1
Service request type
|
Account number
|
Nickname
|
Cipher code
|
A1
|
A2
|
A3
|
A4 |
TABLE 2
Service request type
|
Field(s)
|
Registration request
|
Mobile phone number
|
Request for loginTo find
|
Account number
|
Transaction request
|
Transaction amount, total transaction amount |
In an actual application scenario, the service request types are different, and the corresponding fields to be checked may differ.
As shown in table 2, the correspondence between the service request type and the field is described. Taking the service request type as an example of a login request, fields in the login request comprise an account number, a nickname and a password, and the field to be verified of the login request is determined as the account number according to table 2.
TABLE 3
Field(s)
|
Checking rules
|
Mobile phone number
|
B1
|
Account number
|
B1、B2
|
Transaction amount, total transaction amount
|
B3 |
Step 203: and determining a check rule corresponding to the field to be checked according to the corresponding relation between the preset field and the check rule, wherein the check rule comprises a field-level check rule and a request-level check rule.
As shown in table 3, the correspondence between the field and the check rule is described. As can be seen from table 3, one field may correspond to one or more check rules, and different fields may correspond to the same check rule. Wherein, each of B1, B2, and B3 includes field-level check rules and request-level check rules.
It should be noted that the check rule is used to check the fields to be checked of several service requests, and what is analyzed is the value of the fields to be checked in different service requests.
Step 204: determining a field-level verification result of the field to be verified according to a field-level verification rule corresponding to the field to be verified; and determining whether the plurality of service requests pass the verification according to the field-level verification result and the request-level verification rule corresponding to the field to be verified.
The method determines the field to be checked contained in each service request in the service requests according to the current service request type carried in the service requests, does not need to match all the fields in each service request one by one, and can more efficiently determine the field to be checked.
It should be noted that, the embodiments of the present invention concern whether there is a problem in the entirety of a plurality of service requests, and if there is a problem in the entirety, the service requests cannot pass the verification.
In an embodiment of the present invention, the value of the field to be checked of several service requests is checked, and there are at least the following two cases:
case 1: determining a field-level verification result of the field to be verified according to a field-level verification rule corresponding to the field to be verified; and determining whether the plurality of service requests pass the verification according to the field-level verification result and the request-level verification rule corresponding to the field to be verified. .
And determining whether the values of the fields to be checked of all the service requests meet the current checking rule. That is, the service requests are not distinguished, and the verification object is all the service requests.
For example, there are 20 login requests, and it is determined whether the 20 login requests pass the verification according to the distribution of the values of the accounts of the 20 login requests and the verification rules corresponding to the accounts.
Case 2: step 204 specifically includes: determining a field level check result of a field to be checked of the service request of the target service request type according to a field level check rule corresponding to the field to be checked of the service request of the target service request type; and determining whether the service request of the target service request type passes the verification or not according to the field-level verification result of the field to be verified of the service request of the target service request type and the request-level verification rule corresponding to the field to be verified of the service request of the target service request type.
And classifying the service requests according to the service request types, and checking according to different service request types.
For example, there are 20 service requests, 10 login requests and 10 registration requests. And determining whether the 10 login requests pass the verification according to the value distribution of the accounts of the 10 login requests and the verification rules corresponding to the accounts. And determining whether the 10 registration requests pass the verification according to the value distribution of the accounts of the 10 registration requests and the verification rules corresponding to the accounts.
In one embodiment of the present invention, at least the following verification modes exist, that is, steps 103 and 104 include the following implementation forms:
verification mode 1: determining a service request of which the value of the field to be verified is within a preset first threshold value range according to a field-level verification rule corresponding to the field to be verified; determining a first proportion of service requests with the value of the field to be checked within a preset first threshold range in a plurality of service requests; and determining whether the first ratio is within a preset first ratio range or not according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
The checking mode 1 is suitable for the value of the field to be checked, and is text type, numerical value type or Boolean type.
The verification mode 1 verifies whether the distribution of the values of the fields to be verified of different service requests meets requirements or not according to the size of the values of the fields to be verified, and the mode can find out the problem of the values of the fields to be verified in value logic.
For example, the service request to be verified is 10 transaction requests, the first percentage of the transaction requests with the total transaction amount value less than 1 is 100%, and the first percentage range is "less than 80%", so that if the first percentage is not within the first percentage range, it is determined that the 10 transaction requests are not verified.
In addition, whether the service requests are not verified can be determined according to whether the number of the service requests of which the value of the field to be verified is within the preset first threshold range is smaller than the preset number range.
For example, the total number of the service requests is 10, the number of the service requests of which the value of the field to be checked is within a preset first threshold range is 7, and in a preset number range "greater than 6", it is determined that a number of the service requests pass the check. Similarly, the following check patterns 3, 4, 5, and 6 may also be checked by determining the number of service requests, and will not be described in detail below.
Verification mode 2: determining a sequencing result of sequencing the values of the fields to be verified of the plurality of service requests from small to large according to field-level verification rules corresponding to the fields to be verified; determining the value of a field to be checked corresponding to a preset target quantile according to the sequencing result; and determining whether the value of the field to be verified corresponding to the target sub-bit is within a preset second threshold range according to a request-level verification rule corresponding to the field to be verified, if so, determining that the plurality of service requests pass the verification, and otherwise, determining that the plurality of service requests do not pass the verification.
The verification mode 2 is suitable for the value of the field to be verified to be a numerical value.
The checking mode 2 is to check whether the values of the fields to be checked of the plurality of service requests have a distribution problem according to the quantile distribution of the values of the fields to be checked.
The quantile distribution includes a median distribution, a quartile distribution, a percentile distribution, and the like, and the verification mode 2 will now be described in detail by taking the quartile distribution as an example.
In the existing 8 service requests, the values of the fields to be checked are respectively "1, 2, 5, 8, 9, 11, 17, 28" in descending order, wherein the target quantile is a third quartile, and the value 11 of the corresponding field to be checked is the third quartile. In other words, among the values of the fields to be checked of the 8 service requests, 75% (i.e., 6) of the values of the fields to be checked of the service requests are not greater than 11, and 25% (i.e., 2) of the values of the fields to be checked of the service requests are greater than 11. If the second threshold range is 'greater than 10', the value of the field to be checked corresponding to the target sub-bit is in the second threshold range, and it is determined that 8 service requests pass the check.
It should be noted that there may be a plurality of target quantiles, for example, a first percentile, a second percentile, and a third percentile. Accordingly, there is a second threshold range corresponding to the first percentile, a second threshold range corresponding to the second percentile, and a second threshold range corresponding to the third percentile. In an actual application scenario, whether the service requests pass the verification or not can be determined according to the relationship between the number of the target quantiles meeting the corresponding second threshold range and the preset number threshold.
Verification mode 3: determining a service request which comprises at least two fields to be verified and meets the preset mapping relation by the values of the at least two fields to be verified according to field-level verification rules corresponding to the fields to be verified; determining a second proportion of the service requests which comprise at least two fields to be checked and have values meeting a preset mapping relation in the service requests; and determining whether the second ratio is within a preset second ratio range according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
The verification mode 3 is suitable for the text type and the numerical type of the value of the field to be verified.
The check mode 3 may be used to check a mapping relationship between a plurality of fields to be checked.
As shown in table 4, there are 5 transaction requests, and the transaction request includes three fields of unit price, transaction amount and total transaction amount. The values of the three fields may be checked based on the relationship between the three fields.
TABLE 4
Transaction request
|
Univalent (Yuan/jin)
|
Trade volume (jin)
|
Transaction total (Yuan)
|
1
|
3
|
50
|
140
|
2
|
4
|
40
|
110
|
3
|
5
|
40
|
200
|
4
|
6
|
30
|
180
|
5
|
7
|
10
|
70 |
For example, the preset mapping relationship is that the product of the unit price and the transaction amount is equal to the total transaction amount. And checking 5 transaction requests in the table 4 based on the mapping relation, determining that the second proportion of the service requests meeting the mapping relation is 60%, and if the preset second proportion range is greater than 80%, determining that the 5 transaction requests are not checked.
It should be noted that the mapping relationship may be a mapping relationship between different fields of the same service request, or a mapping relationship between different fields of different service requests.
Verification mode 4: determining a service request which comprises at least two fields to be verified and meets the preset mapping relation by the values of the at least two fields to be verified according to field-level verification rules corresponding to the fields to be verified; determining a second proportion of the service requests which comprise at least two fields to be checked and have the same value in the at least two fields to be checked in the plurality of service requests; determining whether the second ratio is within a preset second ratio range according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, otherwise, determining that the plurality of service requests do not pass the check
The verification mode 4 is suitable for the text type and the numerical type of the value of the field to be verified.
Verification mode 4 is essentially a special case of verification mode 3. For example, the value of the current check field a is equal to the value of the current check field B.
TABLE 5
Transaction request
|
Mobile phone number for receiving goods
|
Registering mobile phone number
|
6
|
a1
|
a1
|
7
|
a2
|
a2
|
8
|
a3
|
a3
|
9
|
a4
|
a4
|
10
|
a5
|
a5 |
As shown in table 5, the second percentage of the transaction request with the same receiving mobile phone number as the registered mobile phone number is 100%, and if the second percentage range is "less than 60%", it is determined that the transaction request 6-10 fails to be verified.
Verification mode 5: determining that the value of the field to be verified meets a preset service request in a text format according to a field-level verification rule corresponding to the field to be verified; determining a third ratio of the value of the field to be verified to meet the preset service request in the text format in the plurality of service requests; and determining whether the third ratio is within a preset third ratio range according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
The verification mode 5 is suitable for the value of the field to be verified to be a text type, a numerical value type, a date type or a Boolean type.
The check mode 5 is mainly used for checking the format of the value of the field to be checked. For example, the text format corresponding to the mobile phone number field is "11 digits", and if letters appear in the current mobile phone number, it is determined that the current mobile phone number does not satisfy the preset text format.
For example, the currency field corresponds to a text format of any one of "euro, dollar, pound, japanese and rmb", and if korean appears in the current currency, it is determined that the preset text format is satisfied.
In an actual application scenario, the verification mode considers the case of the entirety of a plurality of service requests, for example, when a third percentage of the service requests, of which the mobile phone numbers do not satisfy the preset text format, is 60% and is greater than a preset third percentage range, "less than 10%", in 10 service requests, it is determined that the 10 service requests fail to be verified.
Verification mode 6: determining that the length of the value of the field to be verified meets a service request in a preset length range according to a field-level verification rule corresponding to the field to be verified; determining a fourth proportion of the service requests of which the length of the value of the field to be checked meets a preset length range in the plurality of service requests; and determining whether the fourth ratio is within a preset fourth ratio range according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
The verification mode 6 is applicable to the text type and the numerical type of the value of the field to be verified.
For example, if there are 10 registration requests, the length range is "equal to 11", the fourth percentage of the registration requests with the length of 11 for the mobile phone number is 90%, and if the preset fourth percentage range is "greater than 8%", it is determined that 10 registration requests pass verification.
The check mode 6 may also be used for checking that the value of the field to be checked is empty. For example, there are 10 login requests, the length range is "equal to 0", the fourth percentage is 60%, and if the preset fourth percentage range is "less than 10%", it is determined that 10 login requests fail to be checked.
It should be noted that the above-mentioned several verification modes can be applied to the above-mentioned case 1 and case 2, respectively. Different verification modes can also be used in combination, namely different verification modes are used for verifying the same field.
For example, the values of the fields to be checked are checked by using the check modes 6, 5 and 1 in sequence; and in the case that the previous verification mode passes verification, the next verification mode can be used for verification. For example, the field to be checked is checked by using the check mode 6, when the check is passed, the field to be checked is checked by using the check mode 5, and when the check is passed, the field to be checked is checked by using the check mode 1.
The verification modes 1-4 can realize the verification of the values of the fields to be verified of different service requests on a semantic level, achieve the verification quality of manual verification, and improve the verification efficiency. For example, the check mode 1 and the check mode 2 can determine whether there is a problem in the distribution of the values of the field to be checked, and whether the size of the value of the field to be checked is logical. The verification modes 3 and 4 can utilize the association relationship of the values of different fields to be verified to verify one or more fields to be verified.
In summary, compared with the method for checking each field of each service request, the method checks the value of the field in each service request as an entry, has no training cost, and has strong universality.
The embodiment of the invention provides a service request checking method, which comprises the following steps:
s1: determining a field to be checked according to a plurality of service requests;
s2: determining a first check rule, a second check rule, a third check rule, a fourth check rule and a fifth check rule corresponding to a field to be checked according to a corresponding relation between a preset field and the check rules, wherein the first check rule comprises a first field-level check rule and a first request-level check rule, the second check rule comprises a second field-level check rule and a second request-level check rule, the third check rule comprises a third field-level check rule and a third request-level check rule, the fourth check rule comprises a fourth field-level check rule and a fourth request-level check rule, and the fifth check rule comprises a fifth field-level check rule and a fifth request-level check rule;
s3: determining that the length of the value of the field to be verified meets a service request in a preset length range according to a first field-level verification rule corresponding to the field to be verified; determining a fifth proportion of the service requests of which the length of the value of the field to be checked meets a preset length range in the plurality of service requests; determining whether the fifth proportion is within a preset fifth proportion range according to a first request level verification rule corresponding to the field to be verified, and if so, executing S4;
s4: determining that the value of the field to be verified meets a service request in a preset text format according to a second field-level verification rule corresponding to the field to be verified; determining a sixth proportion of the service requests of which the values of the fields to be verified meet the preset text format in the plurality of service requests; determining whether the sixth proportion is in a preset sixth proportion range according to a second request level verification rule corresponding to the field to be verified, and if so, executing S5;
s5: determining a service request of which the value of the field to be verified is within a preset third threshold range according to a third field level verification rule corresponding to the field to be verified; determining a seventh proportion of the service requests of which the values of the fields to be checked are within a preset third threshold range in the plurality of service requests; determining whether the seventh proportion is in a preset seventh proportion range according to a third request level check rule corresponding to the field to be checked, and if so, executing S6;
s6: determining a sequencing result of sequencing the values of the fields to be verified of the plurality of service requests from small to large according to a fourth field-level verification rule corresponding to the fields to be verified; determining the value of a field to be checked corresponding to a preset target quantile according to the sequencing result; determining whether the value of the field to be verified corresponding to the target quantile is within a preset fourth threshold range according to a fourth request-level verification rule corresponding to the field to be verified, and if so, executing S7;
s7: determining a service request which comprises at least two fields to be verified and meets the preset mapping relation by the values of the at least two fields to be verified according to a fifth field level verification rule corresponding to the fields to be verified; determining an eighth ratio of the service requests which comprise at least two fields to be verified and have values meeting a preset mapping relation in the service requests; determining whether the eighth ratio is within a preset eighth ratio range according to a fifth request level check rule corresponding to the field to be checked, if so, executing S8, otherwise, executing S9;
s8: determining that the service requests pass verification;
s9: it is determined that the number of service requests has not been verified.
The embodiment of the invention verifies the field to be verified through different verification rules, can verify whether the field to be verified has problems in different levels, and further screens out the high-quality service request.
As shown in fig. 3, the embodiment of the present invention takes all current service request types as transaction requests as an example to describe in detail a service request verification method, which includes the following steps:
step 301: 5 service requests are determined.
The 5 service requests obtained are shown in table 6, and the fields include unit price, transaction amount, and total transaction amount.
TABLE 6
Service request
|
Service request type
|
Univalent (Yuan/jin)
|
Trade volume (jin)
|
Transaction total (Yuan)
|
11
|
Transaction request
|
3
|
50
|
140
|
12
|
Transaction request
|
4
|
40
|
110
|
13
|
Transaction request
|
5
|
40
|
200
|
14
|
Transaction request
|
6
|
30
|
180
|
15
|
Transaction request
|
7
|
10
|
70 |
Step 302: and determining a field to be verified corresponding to the service request type in the field of the service request according to the preset corresponding relation between the service request type and the field, wherein the field to be verified comprises unit price, transaction amount and total transaction amount.
TABLE 7
Service request type
|
Field(s)
|
Registration request
|
Mobile phone number
|
Login request
|
Account number
|
Transaction request
|
Unit price, transaction amount, total amount of transaction |
The correspondence between the type of the service request and the field is shown in table 7, and the field to be verified is determined to be unit price, transaction amount, and total transaction amount according to table 7.
Step 303: and determining a check rule corresponding to the field to be checked according to the corresponding relation between the preset field and the check rule, wherein the unit price and the total transaction amount correspond to the check rule C5, and the transaction amount corresponds to the check rules C1, C2, C3, C4 and C5.
It should be noted that each of the check rules in C1-C5 includes field-level check rules and request-level check rules.
According to the table 8, the trade rule corresponding to the unit price and the total trade amount is determined to be C5, and the trade rule corresponding to the trade amount is determined to be C1, C2, C3, C4 and C5.
TABLE 8
Field(s)
|
Checking rules
|
Mobile phone number
|
C1
|
Account number
|
C1、C2
|
Unit price, total amount of transaction
|
C5
|
Amount of transaction
|
C1、C2、C3、C4、C5 |
Step 304: determining that the length of the value of the field to be verified meets a service request in a preset length range according to a field-level verification rule in C1 corresponding to the field to be verified; determining a fifth proportion of the service requests of which the length of the value of the field to be checked meets a preset length range in the plurality of service requests; and determining whether the fifth ratio is within a preset fifth ratio range according to the request-level checking rule in the C1 corresponding to the field to be checked, and executing step 305 when the fifth ratio is within the preset fifth ratio range.
Step 305: determining that the value of the field to be verified meets a preset service request in a text format according to a field-level verification rule in C2 corresponding to the field to be verified; determining a sixth proportion of the service requests of which the values of the fields to be verified meet the preset text format in the plurality of service requests; and determining whether the sixth proportion is within a preset sixth proportion range according to the request-level verification rule in the C2 corresponding to the field to be verified, and executing the step 306 when the sixth proportion is within the preset sixth proportion range.
Step 306: determining a service request of which the value of the field to be verified is within a preset first threshold range according to a field-level verification rule in C3 corresponding to the field to be verified; determining a seventh proportion of the service requests of which the values of the fields to be checked are within a preset first threshold range in the service requests; and determining whether the seventh percentage is within a preset seventh percentage range according to the request-level check rule in the C3 corresponding to the field to be checked, and executing step 307 when the seventh percentage is within the preset seventh percentage range.
Step 307: determining a sequencing result of sequencing the values of the fields to be verified of the plurality of service requests from small to large according to a field-level verification rule in C4 corresponding to the fields to be verified; determining the value of a field to be checked corresponding to a preset target quantile according to the sequencing result; and determining whether the value of the field to be checked corresponding to the target quantile is within a preset second threshold range according to the request-level checking rule in C4 corresponding to the field to be checked, and executing step 308 when the value of the transaction amount corresponding to the target quantile is within a preset fourth threshold range.
Step 308: determining a service request which comprises at least two fields to be verified and has values meeting a preset mapping relation according to a field-level verification rule in C5 corresponding to the fields to be verified; determining an eighth ratio of the service requests which comprise at least two fields to be verified and have values meeting a preset mapping relation in the service requests; and determining whether the eighth ratio is within a preset eighth ratio range according to a request level check rule in C5 corresponding to the field to be checked, determining that 5 service requests pass the check when the eighth ratio is within the preset eighth ratio range, and otherwise, determining that 5 service requests do not pass the check.
The embodiment of the invention realizes deep and multi-angle verification of the value of the field to be verified by sequentially using different verification modes from shallow to deep.
As shown in fig. 4, an embodiment of the present invention provides a service request checking apparatus, including:
a first determining unit 401, configured to determine, according to the service requests, a field to be checked;
a second determining unit 402, configured to determine, according to a corresponding relationship between a preset field and a check rule, a check rule corresponding to a field to be checked, where the check rule includes a field-level check rule and a request-level check rule;
a first checking unit 403, configured to determine a field-level checking result of a field to be checked according to a field-level checking rule corresponding to the field to be checked; and determining whether the plurality of service requests pass the verification according to the field-level verification result and the request-level verification rule corresponding to the field to be verified.
In an embodiment of the present invention, the first determining unit 401 is configured to determine, according to a preset correspondence between a service request type and a field, a field to be checked corresponding to the service request type in the field of the service request.
In an embodiment of the present invention, the first checking unit 403 is configured to determine a field-level checking result of a field to be checked of a service request of a target service request type according to a field-level checking rule corresponding to the field to be checked of the service request of the target service request type; and determining whether the service request of the target service request type passes the verification or not according to the field-level verification result of the field to be verified of the service request of the target service request type and the request-level verification rule corresponding to the field to be verified of the service request of the target service request type.
In an embodiment of the present invention, the first checking unit 403 is configured to determine, according to a field-level checking rule corresponding to a field to be checked, a service request whose value of the field to be checked is within a preset first threshold range; determining a first proportion of service requests with the value of the field to be checked within a preset first threshold range in a plurality of service requests; and determining whether the first ratio is within a preset first ratio range or not according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
In an embodiment of the present invention, the first checking unit 403 is configured to determine, according to a field-level checking rule corresponding to a field to be checked, a sorting result obtained by sorting values of the field to be checked of the service requests from small to large; determining the value of a field to be checked corresponding to a preset target quantile according to the sequencing result; and determining whether the value of the field to be verified corresponding to the target sub-bit is within a preset second threshold range according to a request-level verification rule corresponding to the field to be verified, if so, determining that the plurality of service requests pass the verification, and otherwise, determining that the plurality of service requests do not pass the verification.
In an embodiment of the present invention, the first checking unit 403 is configured to determine, according to a field-level checking rule corresponding to a field to be checked, a service request that includes at least two fields to be checked and satisfies a preset mapping relationship with values of the at least two fields to be checked; determining a second proportion of the service requests which comprise at least two fields to be checked and have values meeting a preset mapping relation in the service requests; and determining whether the second ratio is within a preset second ratio range according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
In an embodiment of the present invention, the values of at least two fields to be checked satisfy a preset mapping relationship, including: the values of at least two fields to be checked are the same.
In an embodiment of the present invention, the first checking unit 403 is configured to determine, according to a field-level checking rule corresponding to a field to be checked, that a value of the field to be checked meets a service request in a preset text format; determining a third ratio of the value of the field to be verified to meet the preset service request in the text format in the plurality of service requests; and determining whether the third ratio is within a preset third ratio range according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
In an embodiment of the present invention, the first checking unit 403 is configured to determine, according to a field-level checking rule corresponding to a field to be checked, that a length of a value of the field to be checked satisfies a service request in a preset length range; determining a fourth proportion of the service requests of which the length of the value of the field to be checked meets a preset length range in the plurality of service requests; and determining whether the fourth ratio is within a preset fourth ratio range according to a request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
As shown in fig. 5, an embodiment of the present invention provides a service request checking apparatus, including:
a third determining unit 501, configured to determine a field to be checked according to the service requests;
a fourth determining unit 502, configured to determine, according to a corresponding relationship between a preset field and a check rule, a first check rule, a second check rule, a third check rule, a fourth check rule, and a fifth check rule corresponding to the field to be checked, where the first check rule includes a first field-level check rule and a first request-level check rule, the second check rule includes a second field-level check rule and a second request-level check rule, the third check rule includes a third field-level check rule and a third request-level check rule, the fourth check rule includes a fourth field-level check rule and a fourth request-level check rule, and the fifth check rule includes a fifth field-level check rule and a fifth request-level check rule;
the second checking unit 503 is configured to determine, according to the first field-level checking rule corresponding to the field to be checked, that the length of the value of the field to be checked satisfies the service request in the preset length range; determining a fifth proportion of the service requests of which the length of the value of the field to be checked meets a preset length range in the plurality of service requests; determining whether the fifth ratio is within a preset fifth ratio range according to a first request level check rule corresponding to the field to be checked,
if the fifth occupation ratio is within the preset fifth occupation ratio range, determining that the value of the field to be verified meets the service request in the preset text format according to a second field-level verification rule corresponding to the field to be verified; determining a sixth proportion of the service requests of which the values of the fields to be verified meet the preset text format in the plurality of service requests; determining whether the sixth ratio is within a preset sixth ratio range according to a second request level check rule corresponding to the field to be checked,
if the sixth occupation ratio is within the preset sixth occupation ratio range, determining the service request of the field to be verified, of which the value is within the preset third threshold value range, according to a third field level verification rule corresponding to the field to be verified; determining a seventh proportion of the service requests of which the values of the fields to be checked are within a preset third threshold range in the plurality of service requests; determining whether the seventh proportion is in a preset seventh proportion range according to a third request level check rule corresponding to the field to be checked,
if the seventh ratio is within the preset seventh ratio range, determining a sequencing result of sequencing the values of the fields to be verified of the plurality of service requests from small to large according to a fourth field-level verification rule corresponding to the fields to be verified; determining the value of a field to be checked corresponding to a preset target quantile according to the sequencing result; determining whether the value of the field to be verified corresponding to the target sub-bit is within a preset fourth threshold value range according to a fourth request level verification rule corresponding to the field to be verified,
if the value of the field to be verified corresponding to the target quantile is within the preset fourth threshold range, determining a service request which comprises at least two fields to be verified and meets the preset mapping relation by the value of the at least two fields to be verified according to a fifth field level verification rule corresponding to the field to be verified; determining an eighth ratio of the service requests which comprise at least two fields to be verified and have values meeting a preset mapping relation in the service requests; and determining whether the eighth ratio is within a preset eighth ratio range according to a fifth request level check rule corresponding to the field to be checked, if so, determining that the plurality of service requests pass the check, and otherwise, determining that the plurality of service requests do not pass the check.
An embodiment of the present invention provides a data quality verification apparatus, including: a processor and a memory;
the memory is used for storing execution instructions, and the processor is used for executing the execution instructions stored by the memory to realize the method of any one of the above embodiments.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
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. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
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 tape 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.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. The use of the phrase "including a" does not exclude the presence of other, identical elements in the process, method, article, or apparatus that comprises the same element, whether or not the same element is present in all of the same element.
The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage 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 system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.