Interface attribute consistency checking method and device, electronic equipment and storage medium

Abstract

The application relates to the computer technical field, in particular to an interface attribute consistency checking method and device, electronic equipment and a storage medium, to improve the interface attribute consistency checking efficiency. The method comprises the following steps: analyzing interface documents of a plurality of to-be-tested interfaces to obtain attribute information of the same interface field defined in different to-be-tested interfaces; comparing the attribute information to obtain target interface fields with consistent attribute information definition in different to-be-tested interfaces; analyzing library table information of databases associated with each to-be-tested interface to obtain database fields obtained by mapping the target interface fields in each database; and checking the consistency of field length and field type between each target interface field and the mapped database field to obtain the consistency checking result of each target interface field. The application checks the database definition and the interface parameter definition in the same dimension, realizes automatic interface attribute checking, and improves the checking efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for verifying the consistency of interface attributes. Background Technology

[0002] With the development of internet technology, the development of interfaces is a common part of business system development. Given the complexity of current product logic, deep interface design chains, and inconsistencies in interface attribute definitions, current testing methods for interface attributes typically examine input parameters from a single interface perspective, separating interface parameter definitions from database (DB) definitions. This manual verification of interface attribute consistency requires significant manpower and is inefficient. Therefore, achieving adaptive interface attribute consistency verification to improve testing efficiency has become a pressing technical problem. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and storage medium for verifying the consistency of interface attributes, in order to improve the efficiency of verifying the consistency of interface attributes.

[0004] This application provides a method for verifying the consistency of interface attributes, comprising:

[0005] By parsing the interface documents of multiple interfaces to be tested, the attribute information of the same interface fields defined in different interfaces to be tested can be obtained.

[0006] Compare the attribute information of the same interface field defined in different interfaces under test to obtain the target interface field whose attribute information is consistent in different interfaces under test. The attribute information includes field length and field type.

[0007] By analyzing the database table information associated with each interface to be tested, the database fields mapped to the target interface fields in each database are obtained.

[0008] Verify the consistency of field length and field type between each target interface field and the database field mapped to each target interface field;

[0009] For any target interface field, if the target interface field and the database field mapped to the target interface field have the same field length and the same field type, then the verification shows that the target interface field and the database field have the same attributes, and the consistency verification result for the target interface field is successful.

[0010] This application provides an interface attribute consistency verification device, comprising:

[0011] The parsing unit is used to parse the interface documents of multiple interfaces to be tested to obtain the attribute information of the same interface fields defined in different interfaces to be tested.

[0012] The comparison unit is used to compare the attribute information of the same interface field defined in different interfaces under test, and to obtain the target interface field whose attribute information is consistent in different interfaces under test, wherein the attribute information includes field length and field type.

[0013] The acquisition unit is used to analyze the database table information of the database associated with each interface to be tested, and obtain the database fields mapped by the target interface fields in each database.

[0014] The verification unit is used to verify the consistency of field length and field type between each target interface field and the database field mapped to each target interface field. For any target interface field, if the field length and field type of the target interface field and the database field mapped to the target interface field are consistent, then the verification shows that the attributes of the target interface field and the database field are the same, and the consistency verification result of the target interface field is successful.

[0015] Optionally, the acquisition unit is specifically used for:

[0016] Based on the database table information, the database sharding and table partitioning of each database are classified and deduplicated, and the parameters in the remaining data tables after deduplication are formatted.

[0017] By comparing the attribute information of the same database fields defined in the formatted data tables, the target database fields with consistent attribute information definitions in different data tables can be obtained.

[0018] Establish a mapping relationship between the target interface field and the target database field, and obtain the database fields mapped by the target interface field in each database based on the mapping relationship.

[0019] Optionally, the acquisition unit is specifically used for:

[0020] For target interface fields whose field names are the same as those in the target database, a mapping relationship between the target database field and the target interface field is directly established.

[0021] For target interface fields that do not have the same field name as the target database field, a mapping relationship between the target database field and the target interface field is established based on the log information of each data table.

[0022] Optionally, the acquisition unit is specifically used for:

[0023] Based on the log information of each data table, query the interface service corresponding to each data table;

[0024] Establish the mapping relationship between each data table and the interface to be tested corresponding to the interface service;

[0025] Based on the mapping relationship between each data table and the interface to be tested, a mapping relationship is established between the target database fields in each data table and the target interface fields in the corresponding interface to be tested.

[0026] Optionally, the parsing unit is further configured to:

[0027] Compare the attribute information of the same interface field defined in different interfaces under test to obtain one or more of the interface fields whose attribute information is inconsistent in different interfaces under test, and the interface fields whose attribute information is not defined.

[0028] Mark the obtained interface fields as errors and display them.

[0029] Optionally, the acquisition unit is further configured to:

[0030] By comparing the attribute information of the same database fields defined in the formatted data tables, one or more database fields with inconsistent attribute information definitions in different data tables and database fields with no defined attribute information are identified.

[0031] The retrieved database fields are marked as errors and then displayed.

[0032] An electronic device provided in this application includes a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor performs the steps of any of the above-mentioned interface attribute consistency verification methods.

[0033] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the interface attribute consistency verification methods described above.

[0034] This application provides a computer-readable storage medium including program code. When the program product is run on an electronic device, the program code is used to cause the electronic device to perform the steps of any of the above-described interface attribute consistency verification methods.

[0035] The beneficial effects of this application are as follows:

[0036] This application provides a method, apparatus, electronic device, and storage medium for verifying the consistency of interface attributes. In this application, by identifying the interface documentation of the interface to be tested and analyzing the database table information, target interface fields with consistent attribute definitions in the same interface fields defined in different interfaces to be tested, as well as database fields mapped to the target interface fields, are selected. A system adaptive approach is adopted to verify the database definition and interface parameter definition on the same dimension, preventing database storage content truncation and abnormal program exit due to inconsistent definitions. This application can complete the full-link parameter verification at the interface level in minutes and the consistency verification between the interface and the database in hours without human intervention, greatly reducing manpower input and effectively improving the verification efficiency of interface attribute consistency verification.

[0037] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0038] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0039] Figure 1 This is an optional schematic diagram of an application scenario in an embodiment of this application;

[0040] Figure 2 This is a flowchart illustrating a consistency verification method for interface attributes in an embodiment of this application.

[0041] Figure 3 This is a flowchart illustrating a method for obtaining database fields according to an embodiment of this application;

[0042] Figure 4 This is a schematic diagram illustrating the mapping relationship between an interface and database fields in one embodiment of this application;

[0043] Figure 5This is a system architecture diagram from an embodiment of this application;

[0044] Figure 6 This is a flowchart illustrating a complete method for verifying interface attribute consistency in an embodiment of this application.

[0045] Figure 7 This is a schematic diagram of the composition structure of an interface attribute consistency verification device according to an embodiment of this application;

[0046] Figure 8 This is a schematic diagram of the hardware structure of an electronic device using an embodiment of this application. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this application. Obviously, the described embodiments are only some embodiments of the technical solutions of this application, and not all embodiments. Based on the embodiments recorded in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the technical solutions of this application.

[0048] The following describes some of the concepts involved in the embodiments of this application.

[0049] Interface idempotency: This means that a single or multiple requests made by a user for the same operation will yield consistent results, without any side effects from multiple clicks. Take a payment scenario as an example: a user purchases a product and pays successfully. However, if a network error occurs when the result is returned, the money has already been deducted. If the user clicks the button again, a second deduction will occur, returning a successful result. The user then checks their balance and finds that they were overcharged, and the transaction record has become two entries… This demonstrates a failure to guarantee the idempotency of the interface.

[0050] Interface testing is a type of testing that examines the interfaces between system components. It primarily detects interaction points between external systems and the system itself, as well as between internal subsystems. The focus of this testing is to examine data exchange, transmission, and control management processes, as well as the logical dependencies between systems.

[0051] Interface documentation: This refers to the documentation written by the developers or relevant technical personnel, which specifies the interface's address, parameter types, methods, inputs, outputs, and other information. The two main elements of interface documentation are a functional description and interface parameter specifications. The functional description concisely and clearly describes the interface's function, such as: what information the interface does not retrieve. The interface parameter specifications require that each parameter be identical to the one used in the actual call, including capitalization; the meaning of each parameter is concisely explained, including its format (string, int, long, etc.); the specification section explains where the parameter values ​​need to be provided and details how the parameters are generated, such as the timestamp, the time period it represents, whether the parameter is required, and whether some parameters are mandatory and others optional. In this embodiment, the attribute information of each interface field is mainly obtained based on the interface documentation analysis, specifically including field length, field type, etc.

[0052] Key value: This is a concept in the Windows Registry (an operating system). Located at the end of the registry structure chain, similar to a file in a file system, a key value contains the actual configuration information and data used by the computer and applications during execution. Key values ​​include several field types to adapt to different usage requirements. In the registry, various information is managed through keys and subkeys. All information in the registry is stored as key value entries in various formats. The right window of the Registry Editor displays various key value entries. A key value entry consists of three parts: a key name, a field type, and a key value, with the format: "key name:field type:key value". In this embodiment, fields can be used as key values ​​to classify database shards, interfaces, etc.

[0053] A database is a repository for organizing, storing, and managing data according to a data structure. Broadly speaking, a database is something that stores data; more narrowly, it's a structured table stored in a computer. It's a long-term, organized, shared, and uniformly managed collection of data stored on a computer. A database is a collection of data stored together in a certain way, shared by multiple users, with minimal redundancy, and independent of application programs. It can be viewed as an electronic filing cabinet, a place to store electronic files, but reading and writing data in a file is relatively slow. Users can perform operations such as adding, querying, updating, and deleting data in the file. The purpose of a database is to record information, and its significance is for analysis.

[0054] Data Table: A table is a matrix of data. It is a grid-like virtual table that temporarily stores data (representing a table of data in memory). It can be easily bound to the database without code. A data table consists of three parts: the table name, the fields in the table, and the records in the table. In this embodiment, a database can have multiple data tables.

[0055] A field is a member that represents a variable associated with an object or class. Each row in a table is called a "record," and each record contains all the information in that row, much like all the information about a person in a contact database. However, records in a database don't have specific record names; they are often identified by their row number. A field is a smaller unit than a record. A collection of fields makes up a record. Each field describes a specific characteristic of the document, i.e., a data item, and has a unique field identifier for computer recognition. Variables and constants defined in a class or structure are generally called fields.

[0056] The design concept of the embodiments of this application is briefly introduced below:

[0057] With the development of internet technology, the development of business systems typically involves the development of interfaces, each of which requires parameter configuration. Only after the parameters are configured can the interface be used to transfer data. More complex business systems may require configuring multiple interfaces, each with different parameters. These interface parameters define one or more interface fields.

[0058] In a front-end / back-end separated web (World Wide Web) development model, developers typically need to define interface documentation to standardize the interface format, such as interface address, parameters, types, and meanings. Given the current complexity of product logic, deep interface design chains, inconsistencies in field length limits before and after interface calls, inconsistencies in the definition of the same field across multiple data tables, and inconsistencies between interface definitions and database definitions, this approach faces challenges.

[0059] Currently, interface length validation is generally performed through interface testing, and interface length limits are usually based on design documents provided by the developer. This can lead to insufficient comparison between interfaces and inaccurate reference materials. Therefore, it is essential to perform global length validation using a system-adaptive approach. Furthermore, current testing methods typically examine interface input parameters from a single interface perspective, and interface parameter definitions and database definitions are judged separately. When validating interface field lengths, manual verification of field length consistency requires significant manpower; neglecting this can result in field truncation, process termination, and interfaces that do not support idempotency.

[0060] In view of this, embodiments of this application propose a method, apparatus, electronic device, and storage medium for interface attribute consistency verification. In these embodiments, by identifying the interface documentation of the interface to be tested and analyzing the database table information, target interface fields with consistent attribute definitions in the same interface fields defined in different interfaces to be tested, as well as database fields mapped to the target interface fields, are selected. A system adaptive approach is adopted to verify database definitions and interface parameter definitions on the same dimension, preventing database storage content truncation and abnormal program exit due to inconsistent definitions. These embodiments can complete interface-level end-to-end parameter verification in minutes and interface-database consistency verification in hours without human intervention, significantly reducing manpower and effectively improving the verification efficiency of interface attribute consistency verification.

[0061] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0062] like Figure 1 The diagram illustrates an application scenario according to an embodiment of this application. The application scenario diagram includes two terminal devices 110 and one server 120. The terminal devices 110 and the server 120 can communicate via a communication network.

[0063] In one alternative implementation, the communication network is either a wired network or a wireless network. The terminal device 110 and the server 120 can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this.

[0064] In this embodiment, the terminal device 110 is an electronic device used by a user. This electronic device can be a personal computer, mobile phone, tablet computer, laptop, e-book reader, smart home device, or other computer device with a certain computing power that runs instant messaging software and websites or social networking software and websites. Each terminal device 110 connects to the server 120 via a wireless network. The server 120 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0065] With the continuous development of internet technology, various applications such as e-commerce, enterprise office, social communication, shopping, and financial management have emerged. These applications primarily rely on databases to provide content support. Currently, there are various types of databases, and large-scale applications may require multiple databases of different types to provide diverse content support.

[0066] In this embodiment of the application, each terminal device 110 may have one or more of the above-mentioned applications installed. The applications involved in this embodiment of the application may be software, or web pages, mini programs, etc. The server is the application server corresponding to the software, web pages, mini programs, etc., and there is no restriction on the specific type of client.

[0067] In one alternative implementation, the database comprises multiple physical machines, each with the database bound to it to provide database services. Those skilled in the art will also understand that the aforementioned physical machines can also exist as virtual machines, with the database also bound to these virtual machines to provide database services. Access to data in the database is achieved through an interface.

[0068] The consistency verification methods for interface attributes listed in the embodiments of this application will be described in detail below:

[0069] See Figure 2 The diagram shown is an implementation flowchart of an interface attribute consistency verification method provided in this application embodiment. The specific implementation process of this method is as follows:

[0070] S21: By parsing the interface documents of multiple interfaces to be tested, the attribute information of the same interface fields defined in different interfaces to be tested can be obtained;

[0071] S22: Compare the attribute information of the same interface field defined in different interfaces under test to obtain the target interface field whose attribute information is consistent in different interfaces under test. The attribute information includes field length and field type.

[0072] In this embodiment, the interface to be tested refers to multiple interfaces involved in the development of the business system to be tested. This interface is mainly used to access the database of the business system. Specifically, the interface is defined primarily based on the interface documentation. The interface documentation specifies information such as the interface's address, parameter types, methods, inputs, and outputs.

[0073] The main elements in the API documentation include: API parameter descriptions, specifically ensuring that each parameter is identical to the one used in the actual API call, including capitalization; a concise explanation of the parameter's meaning and format (e.g., string, int, long); and a description section explaining where the parameter value needs to be provided and how it is generated, such as timestamps, indicating the time period, whether a parameter is required, and whether some parameters are mandatory while others are optional.

[0074] The interface parameters may contain one or more interface fields. In this embodiment, the interface and the interface field have a 1:N ratio, where N is a positive integer.

[0075] Optionally, the attribute information of the interface field includes the field length and field type. In this embodiment, a field generally defines a range of field lengths, such as 11-18 bits, where 18 is the upper limit of the field length (also simply called the length limit or upper limit), representing the maximum length that this field can store. Additionally, the field type refers to the data type, such as int (integer), tinyint (integer), string (string), char (character variable), varchar (variable-length string), bit (bit data type, length 1 bit), etc.

[0076] Among them, tinyint(M), where M defaults to 4, is a very small integer. The signed range is -128 to 127. The unsigned range is 0 to 255. int(M), where M defaults to 11, is a normal-sized integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.

[0077] For multiple interfaces to be tested, an interface will certainly not define the same interface fields, but different interfaces can define the same interface fields (with the same field name). If the attribute information of the same interface field is defined differently in different interfaces, it is easy to cause problems such as field truncation, process termination, and interface not supporting idempotency.

[0078] Therefore, in this embodiment, the interface parameters defined in each interface to be tested are analyzed in detail by identifying the interface documentation of each interface to be tested, in order to obtain the attribute information of each interface field in the interface parameters. Then, the interface fields are classified and analyzed using the interface fields as keys, grouping the same interface fields into the same category. Through summary analysis, the interface fields are divided into the following three categories:

[0079] Category 1: Target interface fields with consistent attribute information across different interfaces to be tested;

[0080] The second category: Interface fields with inconsistent attribute information definitions in different interfaces to be tested;

[0081] The third category: Interface fields where there is no defined attribute information in different interfaces to be tested.

[0082] In this embodiment, both the second and third type of interface fields are error messages. That is, when attribute information is inconsistent or undefined, issues such as field truncation, process termination, and lack of idempotency support in the interface can easily occur. Therefore, it is necessary to mark the obtained second and third type of interface fields as errors and display them to the user. The first type of interface field is mainly used for comparison with fields in the database layer to verify consistency.

[0083] Among these, undefined attribute information can be a case where the upper limit of field length is not defined, as shown below:

[0084]

[0085]

[0086] The above describes one method for displaying interface fields with no defined upper limit on field length to the user, as illustrated in the embodiments of this application. Two fields are listed: "mobile" and "application_id," neither of which has a set upper limit on length.

[0087] In this embodiment, based on the analysis of the interface documentation, the rationality of the entire link parameter definition can be verified from a global perspective. Instead of using manually maintained interface definitions as a reference, a system adaptive approach is adopted to determine whether parameter overflow exists in the link. Parameter overflow refers to the situation where, when interface A calls interface B, the call is truncated because interface B has narrower restrictions on a certain parameter definition field. Without manual intervention, interface-level end-to-end parameter verification can be completed in minutes, effectively improving verification efficiency.

[0088] S23: By analyzing the database table information associated with each interface to be tested, the database fields mapped to the target interface fields in each database are obtained;

[0089] In this embodiment, the database of the business system can be accessed by calling the interface service. Similarly, database parameters that map to the interface parameters defined in the interface are also defined in the database, and these database parameters may contain one or more database fields.

[0090] The database table information can include the table names and related field information. Therefore, based on the table information, analysis is performed to obtain the database fields that map to the target interface fields selected in S21. After this step, a consistency check can be performed between the interface fields and the database fields.

[0091] S24: Verify the consistency of field length and field type between each target interface field and the database field mapped to each target interface field;

[0092] S25: For any target interface field, if the field length of the target interface field and the field of the database field mapped to the target interface field are the same and the field type is the same, then the verification shows that the attributes of the target interface field and the database field are the same, and the consistency verification result of the target interface field is successful.

[0093] In other words, in this embodiment of the application, when performing consistency verification between the target interface field and each database field, the consistency verification between each target interface field and the corresponding database field is mainly performed based on the mapping relationship between the target interface field and the target database field.

[0094] The attribute information can include field length and field type. Therefore, when performing consistency verification on a target interface field and its mapped database field, it is necessary to verify the consistency of field length and field type between each target interface field and the database field mapped to each target interface field.

[0095] For any given target interface field, if the target interface field and its mapped database field have the same field length and data type (e.g., both have a maximum field length of 18 and are of type int), it indicates that the attribute information of the mapped database field is identical to that of the target interface field. Therefore, it can be determined that the target interface field and its mapped database field have the same attributes, and the verification result is successful. Otherwise, the verification fails.

[0096] In this embodiment of the application, after marking the target interface field that failed the verification and the corresponding database field as errors, they can also be displayed to the user.

[0097] In the embodiments of this application, during execution Figure 2 In step S23 as shown, an optional implementation process is as follows: Figure 3 As shown, where Figure 2 Step S23 shown can be specifically divided into steps S33 to S35:

[0098] S31: By parsing the interface documents of multiple interfaces to be tested, the attribute information of the same interface fields defined in different interfaces to be tested can be obtained;

[0099] S32: Compare the attribute information of the same interface field defined in different interfaces under test to obtain the target interface field whose attribute information is consistent in different interfaces under test. The attribute information includes field length and field type.

[0100] S33: Based on the database table information, classify and deduplicate the database shards and tables of each database, and format the parameters in the remaining data tables after deduplication.

[0101] S34: By comparing the attribute information of the same database fields defined in the formatted data tables, the target database field with consistent attribute information in different data tables is obtained;

[0102] S35: Establish a mapping relationship between the target interface fields and the target database fields, and obtain the database fields mapped to the target interface fields in each database based on the mapping relationship;

[0103] S36: Verify the consistency of field length and field type between each target interface field and the database field mapped to each target interface field;

[0104] S37: For any target interface field, if the target interface field and the database field mapped to the target interface field have the same field length and the same field type, then the verification shows that the attributes of the target interface field and the database field are the same, and the consistency verification result for the target interface field is successful.

[0105] In this embodiment of the application, a database may have multiple shards and tables, and in the same type of shard and table, the attribute information of the same database field is defined in the same way.

[0106] When categorizing and deduplicating database shards and tables, sharding is typically done by year, month, and day, or by a specific key value. For these two types of tables, the table interfaces are identical. To deduplicate these tables, only one table structure should be retained for each type of shard for subsequent evaluation. The returned table structure undergoes initial validation and parameter formatting.

[0107] The preliminary verification specifically refers to classifying and analyzing the acquired database fields, and dividing them according to the consistency of the attribute information definitions. Specifically, it can be divided into database fields with inconsistent attribute information definitions in different databases (or different data tables), database fields with no defined attribute information, and database fields with consistent attribute information definitions.

[0108] For database fields with consistent attribute information definitions, specifically referred to as target database fields in this embodiment, they are used for comparative analysis with target interface fields whose attribute information definitions are consistent with those obtained in step S21. For database fields with inconsistent attribute information definitions or no defined attribute information, the same error marking is applied as with interface fields, and the error is displayed to the user.

[0109] The following uses a specific database field as an example to illustrate the field length definition in different data tables:

[0110] 'max':

[0111] {'max': 4,}

[0112] 'table': 'db_1'}

[0113] 'max': 11,

[0114] 'table': 'db_2'}

[0115] {'max': 4,}

[0116] 'table': 'db_3'}

[0117] {'max': 64,}

[0118] 'table': 'db_4'}

[0119] The above content indicates that: in Table 1 (db_1), the maximum length of this field is 4; in Table 2 (db_2), the maximum length of this field is 11; in Table 3 (db_3), the maximum length of this field is 4; and in Table 4 (db_4), the maximum length of this field is 64.

[0120] 'Type':

[0121] {'table': 'db_1',

[0122] 'Type': 'tinyint(4)'}

[0123] {'table': 'db_2',

[0124] 'Type': 'int(11)'}

[0125] {'table': 'db_3',

[0126] 'Type': 'tinyint(4)'}

[0127] {'table': 'db_4',

[0128] 'Type': 'varchar(64)'}

[0129] The above indicates that the data type of this field is tinyint in Table 1 (db_1), inint in Table 2 (db_2), tinyint in Table 3 (db_3), and varchar in Table 4 (db_4). Specifically, when establishing the mapping relationship, there are two possible scenarios:

[0130] Scenario 1: For target interface fields with the same field names as target database fields, directly establish a mapping relationship between the target database field and the target interface field;

[0131] For example, in a target interface field Field1 defined in a test interface, the field name is "state", which represents the state. Similarly, a target database field Field1 is also named "state", also representing the state. Therefore, a mapping relationship between the target interface field Field1 and the target database field Field1 can be directly established.

[0132] Scenario 2: For target interface fields that do not have the same field name as the target database field, a mapping relationship between the target database field and the target interface field is established based on the log information of each data table.

[0133] For example, in a test interface, a target interface field Field1 might be named "state," representing the state. However, the target database field Field1 might be named "status," not "state." In reality, both the target interface field Field1 and the target database field Field1 represent the state. At this point, log information from each table can be retrieved. Based on the analysis of this log information, it can be determined whether their field values ​​are consistent. If they are consistent, a mapping relationship can be established.

[0134] Specifically, the process of establishing the mapping relationship between target database fields and target interface fields based on the log information of each data table is as follows:

[0135] Based on the log information of each data table, query the interface service corresponding to each data table; establish the mapping relationship between each data table and the interface to be tested corresponding to the interface service; based on the mapping relationship between each data table and the interface to be tested, establish the mapping relationship between the target database fields in each data table and the target interface fields in the corresponding interface to be tested.

[0136] In the business systems listed in the embodiments of this application for testing, database read-write separation is generally implemented. Therefore, by scanning the log information of the service writing to the database, a mapping relationship can be established between the interface fields in the interface input parameters (interface parameters) and the database fields written to the database. However, it is first necessary to establish a mapping relationship between the data tables and the interface, that is, to match the logs of each data table. For any data table, the relevant interface service for the write operation is found through the log information, and a mapping relationship is established between the data table and the interface service. Based on this, by judging whether the field values ​​are consistent, a mapping relationship is established between the target interface field in the interface and the target database field in the data table. That is, the input parameters of the service corresponding to the write operation are found, and the interface field content in the input parameters is matched with the database field content of the write operation. When they are consistent, a mapping relationship is established between the interface field and the database field. Then, based on this mapping relationship, the field types and field lengths defined in the interface layer and the database layer can be verified to be consistent.

[0137] See Figure 4 As shown, it is a schematic diagram of the mapping relationship between an interface and database fields in an embodiment of this application.

[0138] Taking the `service` interface as an example, this interface corresponds to a test interface, through which data can be written to the `Database.table` table. Here, `Field1` connected to `service` refers to interface field 1, `Field2` to interface field 2, `Field3` to interface field 3, ..., `FieldN` to interface field N. All N interface fields belong to the target interface fields.

[0139] Database.table is a data table that has a mapping relationship with the service interface. Field1, Field2, Field3, ..., FieldN are all database fields connected to Database.table.

[0140] Through analysis of log information, it can be finally determined that there is a mapping relationship between interface field 1 and database field 1, interface field 2 and database field 2, interface field 3 and database field 3, ..., interface field N and database field N.

[0141] Therefore, during consistency verification, the main process involves comparing the attribute information of interface field 1 with the attribute information of database field 1, including comparing field lengths and field types. Similarly, the attribute information of interface field 2 is compared with the attribute information of database field 2, the attribute information of interface field 3 is compared with the attribute information of database field 3, and so on. Finally, the verification result for each target interface field is determined based on the comparison results, indicating whether the verification was successful or failed.

[0142] For validation failures, errors can be marked. For example, if the length of field 1 in the interface is inconsistent with the length of field 1 in the database, the field length can be marked as inconsistent and displayed to the user; if the field type of field 2 in the interface is inconsistent with the field type of field 2 in the database, the field type can be marked as inconsistent and displayed to the user so that the user can make further modifications and avoid situations such as truncation of DB storage content and abnormal program exit due to inconsistent definitions.

[0143] The following is combined Figure 5 The consistency verification method in the embodiments of this application will be described in detail.

[0144] See Figure 5 As shown, it is a system architecture diagram of an embodiment of this application. The architecture diagram mainly includes four parts, from left to right: DB layer, service layer, verification model and interface layer.

[0145] The interface layer is primarily used to analyze the interface definitions of various interfaces under test in the business system being tested. This mainly involves identifying the interface definitions in the interface documentation and obtaining the attribute information of each interface field. Then, using these interface fields as keys, it performs classification analysis. Here, the consistency of attribute information is primarily used as the classification criterion.

[0146] For example Figure 5 As shown, by determining whether the attribute information of the same field in multiple interfaces is consistent, it can be divided into the following main categories:

[0147] 1) When there is no attribute information set, the data in that field is output to the error queue for fields without attribute information. Errors can then be flagged, and a corresponding report can be generated and displayed to the user. This means the report is sent to project stakeholders, also known as project stakeholders, who are individuals or organizations actively involved in the project or whose interests are affected by the project's execution or completion. In this embodiment, it mainly refers to the project stakeholders of the business system under test, which can be individuals or organizations.

[0148] 2) When there are inconsistencies in the definition of attribute information, the data of that field is output to the error queue for inconsistent definitions; then the error can be marked, a corresponding report can be generated, and the report can be sent to project stakeholders.

[0149] 3) If the attribute information is consistent, return to the tool's intelligent verification layer and wait for consistency verification with the DB layer.

[0150] It should be noted that, in this embodiment, the steps of generating a report and contacting project stakeholders for the error-marked field data can be output when developers submit code, thus exposing risks in advance and improving testing efficiency. End-to-end parameter validation at the interface level, including field length and field type validation, is completed within minutes.

[0151] The DB layer, or database management layer, stores information about each database (table) and the source data within it. It can output this database information to the validation model. The validation model primarily consists of a collector, formatting, intelligent tool validation, error messages, report generation, and outreach to project stakeholders.

[0152] Specifically, the collector retrieves database table information and source data from the database management end of the DB layer. The source data contains various database fields. After obtaining the database table information and source data, it categorizes them by type and performs deduplication (i.e., each type of database sharding retains only one table structure for subsequent judgment). The returned table structure undergoes preliminary validation and parameter formatting. First, based on fields as keys, it performs categorization analysis. For the same database field defined in different data tables, if there are cases where attribute information is not set, the relevant data for that database field is output to the error queue for fields without attribute information; if there are cases where attribute information definitions are inconsistent, the relevant data for that database field is output to the error queue for inconsistent definitions. Second, based on tables, it returns to the tool's intelligent validation layer, waiting for the generation of the mapping relationship between database fields and interface fields before performing consistency validation between the DB and the interface. The first part above (the categorization analysis of database fields) can be validated during the development environment configuration submission, facilitating left-shift testing.

[0153] The mapping relationship between the database (DB) and the interface is primarily established based on the service layer. The service layer provides log information for each database (data table), and the mapping relationship described in this embodiment is established based on this log information. Then, the intelligent verification tool checks whether the data type and length of the target interface fields and target database fields are consistent. The specific verification process can be found in the above embodiment; repeated details will not be elaborated further. Finally, a report is generated based on the verification results and communicated to project stakeholders.

[0154] It should be noted that the embodiments of this application are applicable to all business systems with well-defined interfaces.

[0155] See Figure 6 The diagram shown is a complete flowchart of an interface attribute consistency verification method according to an embodiment of this application. The specific implementation process of this method is as follows:

[0156] Step S61: By parsing the interface documents of multiple interfaces to be tested, the attribute information of the same interface fields defined in different interfaces to be tested is obtained;

[0157] The interface to be tested is mainly used to access the database. The interface document can be in JSON (JavaScript Object Notation) format, or other formats, which are not specifically limited here. The interface document in this embodiment contains a description of the interface parameters. Based on this information, the attribute information of each interface field defined in the interface document can be analyzed, and the attribute information of the same interface field defined in different interfaces to be tested can be filtered out.

[0158] Step S62: Compare the attribute information of the same interface field defined in different interfaces under test to obtain the target interface field whose attribute information is consistent in different interfaces under test;

[0159] Step S63: For interface fields with inconsistent attribute information definitions or no attribute information defined in different interfaces to be tested, mark the errors and display them;

[0160] When demonstrating, the code sections listed in the above embodiments can be used to intuitively show users which interface fields have inconsistent attribute information definitions or no attribute information in different interfaces to be tested. Among them, undefined attribute information generally refers to the undefined upper limit of field length, while inconsistent attribute information definitions are divided into: inconsistent field length definitions and inconsistent field type definitions.

[0161] Step S64: Based on the database table information associated with each interface to be tested, classify and deduplicate the database shards and tables of each database, and format the parameters in the remaining data tables after deduplication.

[0162] When categorizing and deduplicating database shards and tables, sharding is typically done by year, month, and day, or by a specific key value. For these two types of tables, the table interfaces are identical. To deduplicatize these tables, only one table structure should be retained for each type of sharding for subsequent evaluation. The returned table structure undergoes initial validation and parameter formatting.

[0163] Step S65: By comparing the attribute information of the same database fields defined in the formatted data tables, the target database fields with consistent attribute information definitions in different data tables are obtained;

[0164] Step S66: Mark and display errors for database fields whose attribute information is inconsistent or undefined in different databases;

[0165] Similarly, when demonstrating, the code sections listed in the above embodiments can be used to intuitively show users which database fields have inconsistent attribute information definitions or no attribute information in different database tables; where, undefined attribute information generally refers to the undefined upper limit of field length, and inconsistent attribute information definitions are divided into: inconsistent field length definitions and inconsistent field type definitions.

[0166] Step S67: For target interface fields whose field names are the same as those in the target database, directly establish the mapping relationship between the target database field and the target interface field;

[0167] Specifically, by comparing the field names of the target interface fields with those of the target database fields, a mapping relationship is established between the target interface fields and the target database fields with the same field names;

[0168] Step S68: For target interface fields whose field names are the same as those in the target database, establish a mapping relationship between the target database fields and the target interface fields based on the log information of each data table;

[0169] Specifically, firstly, based on the log information of each data table, it is necessary to query the interface service corresponding to each data table; then, establish the mapping relationship between each data table and the interface to be tested corresponding to the interface service; finally, based on the mapping relationship between each data table and the interface to be tested, establish the mapping relationship between the target database fields in each data table and the target interface fields in the corresponding interface to be tested.

[0170] Step S69: Determine whether the attribute information of the target interface field and the mapped database field are the same, and obtain the consistency verification result for each target interface field;

[0171] Specifically, when determining whether the attribute information of a target interface field and its mapped database field are the same, the process mainly relies on the mapping relationship between the target interface field and the target database field. Consistency checks are performed on the field length and field type of each target interface field and its mapped database field. For any given target interface field, if both the target interface field and its mapped database field have the same field length and field type, it can be determined that the attribute information of this target interface field and its mapped database field are the same, and the check result for this target interface field is successful. If at least one of the field length or field type differs, it can be determined that the attribute information of this target interface field and its mapped database field are different, and the check result for this target interface field is unsuccessful.

[0172] Step S610: Mark and display errors for target interface fields and database fields with different attributes.

[0173] like Figure 7 As shown, this is a structural schematic diagram of an interface attribute consistency verification device 700 according to an embodiment of this application, which may include:

[0174] The parsing unit 701 is used to parse the interface documents of multiple interfaces to be tested to obtain the attribute information of the same interface fields defined in different interfaces to be tested.

[0175] The comparison unit 702 is used to compare the attribute information of the same interface field defined in different interfaces under test, and to obtain the target interface field whose attribute information is consistent in different interfaces under test, wherein the attribute information includes field length and field type.

[0176] The acquisition unit 703 is used to obtain the database fields mapped to each database by analyzing the database table information associated with each interface to be tested.

[0177] Verification unit 704 is used to verify the consistency of field length and field type between each target interface field and the database field mapped to each target interface field. For any target interface field, if the field length and field type of the target interface field and the database field mapped to the target interface field are consistent, then the verification shows that the attributes of the target interface field and the database field are the same, and the consistency verification result of the target interface field is successful.

[0178] Optionally, the acquisition unit 703 is specifically used for:

[0179] Based on the database table information, the database sharding and table partitioning of each database are classified and deduplicated, and the parameters in the remaining data tables after deduplication are formatted.

[0180] By comparing the attribute information of the same database fields defined in the formatted data tables, the target database fields with consistent attribute information definitions in different data tables can be obtained.

[0181] Establish a mapping relationship between target interface fields and target database fields, and obtain the database fields mapped to the target interface fields in each database based on the mapping relationship.

[0182] Optionally, the acquisition unit 703 is specifically used for:

[0183] For target interface fields whose field names are the same as those in the target database, a mapping relationship between the target database field and the target interface field is directly established.

[0184] For target interface fields that do not have the same field name as the target database field, a mapping relationship between the target database field and the target interface field is established based on the log information of each data table.

[0185] Optionally, the acquisition unit 703 is specifically used for:

[0186] Based on the log information of each data table, query the interface service corresponding to each data table;

[0187] Establish the mapping relationship between each data table and the corresponding interface to be tested;

[0188] Based on the mapping relationship between each data table and the interface to be tested, establish the mapping relationship between the target database fields in each data table and the target interface fields in the corresponding interface to be tested.

[0189] Optionally, the parsing unit 701 is also used for:

[0190] Compare the attribute information of the same interface field defined in different interfaces under test to obtain one or more of the interface fields whose attribute information is inconsistent in different interfaces under test, and the interface fields whose attribute information is not defined.

[0191] Mark the obtained interface fields as errors and display them.

[0192] Optionally, the acquisition unit 703 is also used for:

[0193] By comparing the attribute information of the same database fields defined in the formatted data tables, one or more database fields with inconsistent attribute information definitions in different data tables and database fields with no defined attribute information are identified.

[0194] The retrieved database fields are marked as errors and then displayed.

[0195] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0196] Having introduced the interface attribute consistency verification method and apparatus according to exemplary embodiments of this application, we will now introduce an electronic device according to another exemplary embodiment of this application.

[0197] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0198] Based on the same inventive concept as the above-described method embodiments, this application also provides an electronic device. This electronic device can be used for consistency detection of interface attributes. In one embodiment, the electronic device can be a server, such as... Figure 1 The server 120 shown could also be other electronic devices, such as... Figure 1 The terminal device 110 is shown. In this embodiment, the electronic device can be structured as follows: Figure 8 As shown, it includes a memory 801, a communication module 803, and one or more processors 802.

[0199] The memory 801 is used to store computer programs executed by the processor 802. The memory 801 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0200] Memory 801 may be volatile memory, such as random-access memory (RAM); memory 801 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 801 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 801 may be a combination of the above-described memories.

[0201] Processor 802 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 802 is used to implement the consistency verification method of the above-mentioned interface attributes when calling computer programs stored in memory 801.

[0202] The communication module 803 is used to communicate with terminal devices and other servers.

[0203] This application does not limit the specific connection medium between the memory 801, the communication module 803, and the processor 802 described above. This disclosure embodiment... Figure 8 The memory 801 and the processor 802 are connected via a bus 804, and the bus 804 is in Figure 8 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The 804 bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0204] The memory 801 stores a computer storage medium containing computer-executable instructions for implementing the interface attribute consistency verification method of this application embodiment. The processor 802 executes the aforementioned interface attribute consistency verification method.

[0205] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0206] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0207] In some possible implementations, various aspects of the interface attribute consistency verification method provided in this application can also be implemented as a program product, which includes program code. When the program product is run on a computer device, the program code is used to cause the computer device to perform the steps in the interface attribute consistency verification method according to the various exemplary embodiments of this application described above. For example, the computer device can perform actions such as... Figure 2 The steps are shown in the figure.

[0208] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0209] The program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a computing device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0210] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0211] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0212] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0213] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for checking consistency of interface attributes, characterized in that, The method comprises: obtaining attribute information of the same interface field defined in different to-be-tested interfaces by parsing interface documents of a plurality of to-be-tested interfaces; each to-be-tested interface refers to an interface involved in development of a to-be-tested business system, and is used for accessing a database of the business system; comparing the attribute information of the same interface field defined in different to-be-tested interfaces, and obtaining a target interface field with consistent attribute information defined in different to-be-tested interfaces after confirming that the field length and the field type are consistent; based on library table information, classifying and deduplicating the databases, comparing attribute information of the same database field defined in each of the remaining data tables, and obtaining a target database field with consistent attribute information defined in different data tables; and establishing a mapping relationship between the target interface field and the target database field; based on the mapping relationship, obtaining database fields mapped from the target interface field in each database; and respectively verifying the consistency of the field length and the field type between each target interface field and the database field mapped from the target interface field; for any target interface field, if the field length and the field type of the target interface field and the database field mapped from the target interface field are consistent, it is verified that the attribute of the target interface field is the same as that of the database field, and the consistency verification result of the target interface field is verified to be successful.

2. The method of claim 1, wherein, Before comparing the attribute information of the same database field defined in each of the remaining data tables, the method further comprises: formatting parameters in each of the remaining data tables; comparing the attribute information of the same database field defined in each of the remaining data tables, and obtaining a target database field with consistent attribute information defined in different data tables, comprises: comparing the attribute information of the same database field defined in each of the formatted data tables, and obtaining a target database field with consistent attribute information defined in different data tables.

3. The method of claim 1, wherein, The method further comprises: for a target interface field with the same field name as the target database field, a mapping relationship is directly established between the target database field and the target interface field; for a target interface field without the same field name as the target database field, a mapping relationship is established between the target database field and the target interface field based on log information of each data table.

4. The method of claim 3, wherein, The method further comprises: based on the log information of each data table, querying an interface service corresponding to each data table; establishing a mapping relationship between each data table and a to-be-tested interface corresponding to the interface service; based on the mapping relationship between each data table and the to-be-tested interface, respectively establishing a mapping relationship between a target database field in each data table and a target interface field in a corresponding to-be-tested interface.

5. The method of claim 1, wherein, The comparing of the attribute information of the same interface field defined in different to-be-tested interfaces further includes: comparing the attribute information of the same interface field defined in different to-be-tested interfaces, obtaining one or more of the interface fields with inconsistent attribute information definition in different to-be-tested interfaces and the interface fields without defined attribute information; error marking the obtained interface fields and displaying them.

6. The method of claim 2, wherein, The comparing of the attribute information of the same database field defined in the formatted various data tables further includes: comparing the attribute information of the same database field defined in the formatted various data tables, obtaining one or more of the database fields with inconsistent attribute information definition in different data tables and the database fields without defined attribute information; error marking the obtained database fields and displaying them.

7. An apparatus for checking consistency of interface attributes, characterized by It includes: a parsing unit configured to obtain attribute information of the same interface field defined in different to-be-tested interfaces by parsing interface documents of the to-be-tested interfaces; each to-be-tested interface refers to an interface involved in the development of a to-be-tested business system and is used to access a database of the business system; a comparison unit configured to compare the attribute information of the same interface field defined in different to-be-tested interfaces, and obtain target interface fields with consistent attribute information definition in different to-be-tested interfaces after confirming that the field length and the field type are consistent, wherein the attribute information includes the field length and the field type; an obtaining unit configured to compare attribute information of the same database field defined in the remaining various data tables after classifying and deduplicating the database sharding of each database based on library table information, and obtain target database fields with consistent attribute information definition in different data tables; and establish a mapping relationship between the target interface fields and the target database fields; obtain database fields mapped from the target interface fields in each database based on the mapping relationship; a checking unit configured to check the consistency of the field length and the field type between each target interface field and the database field mapped therefrom respectively; for any target interface field, if the field length and the field type of the target interface field and the database field mapped therefrom are consistent, it is checked that the attribute of the target interface field is the same as that of the database field, and the consistency checking result for the target interface field is checking success.

8. The apparatus of claim 7, wherein, Before comparing the attribute information of the same database field defined in the remaining various data tables, the obtaining unit is further configured to: format the parameters in the remaining various data tables; the obtaining unit is specifically configured to: compare the attribute information of the same database field defined in the formatted various data tables, and obtain target database fields with consistent attribute information definition in different data tables.

9. An electronic device, comprising: A computer program product, comprising a computer readable storage medium having program code stored therein, the program code configured such that, upon execution by a processor, the processor is caused to perform the steps of any of the methods of claims 1-6.

10. A computer-readable storage medium, characterized in that, A computer program product, comprising a computer readable storage medium having program code stored therein, the program code configured such that, upon execution by a processor, the processor is caused to perform the steps of any of the methods of claims 1-6.

Images