Interface testing method and device

Abstract

The invention discloses an interface testing method and device, and relates to the technical field of computers. A specific embodiment of the method comprises the following steps: in response to a received test request of an interface, obtaining a historical execution record of the interface; converting each record in the historical execution record into a standard record in a specified data format, and merging each standard record to obtain a standard total record; and according to the standard total record, generating a test case for interface testing. According to the embodiment, the test case of the interface is automatically generated based on the historical execution record of the interface, the test efficiency is improved, the labor cost is saved, rich test cases can be obtained based on the historical execution record, the test coverage rate is improved, and the test quality is guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for interface testing. Background Art

[0002] During the iteration process of software development, testers need to perform functional testing and regression testing on the interface. Functional testing is mainly performed for iteration needs, while regression testing is mainly performed for the existing functions of the interface to ensure that the existing functions of the interface are not damaged. Currently, regression testing tests the execution status of the interface by executing the written test cases to ensure that the existing functions of the interface are not affected by the iteration requirements.

[0003] In the process of implementing the present invention, the inventors found that the prior art has the following problems:

[0004] The current method of manually writing test cases for regression testing not only requires additional time for designing and writing test cases, but also may have certain technical barriers for complex interface testing projects and requires experienced testers, which is not conducive to the management and control of software projects. On the other hand, because the test cases are manually written, the number of test cases is relatively limited, and the test coverage cannot be well guaranteed, which affects the quality of the test. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a method and device for interface testing, which converts each record in the acquired historical execution record of the interface into a standard record and merges them, and generates test cases according to the merged standard total record to perform interface testing, thereby realizing automatic generation of test cases for the interface based on the historical execution record of the interface. This not only improves testing efficiency and saves labor costs, but also can obtain rich test cases based on historical execution records, thereby improving test coverage and ensuring test quality.

[0006] To achieve the objective, according to one aspect of an embodiment of the present invention, a method for interface testing is provided, comprising:

[0007] In response to receiving a test request for an interface, obtaining a historical execution record of the interface;

[0008] Convert each record in the historical execution record into a standard record in a specified data format, and merge each of the standard records to obtain a standard total record;

[0009] Based on the standard total record, generate test cases for interface testing.

[0010] Optionally, each record in the historical execution record is converted into a standard record in a specified data format, including: converting each record in the historical execution record into a basic record in a data exchange format; performing a standardized description of each basic record according to a dedicated protocol and in combination with preset keywords to obtain a standard record corresponding to each record.

[0011] Optionally, merging the standard records includes: determining a merging rule according to preset keywords; and merging the parameter fields in the standard records, and the values, attributes and types corresponding to the response fields according to the merging rule.

[0012] Optionally, the standard total record includes attributes and types of parameter fields, and attributes and types of response fields; based on the standard total record, a test case is generated, including at least one of the following: based on a set of numerical values ​​corresponding to the parameter fields in the standard total record, and the attributes and types of the response fields, a forward test case for the interface is generated; based on the types of the parameter fields in the standard total record, combined with preset type boundary values, a boundary test case for the interface is generated; based on the attributes of the parameter fields in the standard total record, the necessary parameter fields of the interface are determined, and a reverse test case for the interface is generated by deleting the necessary parameter fields according to preset deletion rules.

[0013] Optionally, the parameter field exists in the form of a set; based on the value set corresponding to the parameter field in the standard total record, and the attributes and type of the response field, a positive test case for the interface is generated, including: determining the order of permutation calculation based on the subfields in the parameter field in the standard total record, and according to the order, fully permuting the values ​​included in the value set corresponding to each subfield to obtain a set of parameter value combinations corresponding to the parameter field of the interface; using each of the parameter value combinations as an input parameter of the test case to be generated, and the attributes and type of the response field in the standard total record as the response of the test case to be generated, to determine the corresponding positive test case.

[0014] Optionally, before using each of the parameter value combinations as an input parameter of a test case to be generated, the method further comprises: processing the set of the parameter value combinations using a pairing algorithm.

[0015] Optionally, the parameter field exists in the form of a set; based on the type of the parameter field in the standard total record and in combination with a preset type boundary value, a boundary test case for the interface is generated, including: based on the type of each subfield in the parameter field and in combination with a preset type boundary value, determining the boundary value corresponding to each subfield, wherein the boundary value has an order; according to the order of the boundary values ​​of each subfield in the parameter field, assigning corresponding boundary values ​​to each subfield in the parameter field until the boundary values ​​of each subfield are assigned; and generating corresponding boundary test cases according to the boundary values ​​assigned to each subfield in the parameter field each time.

[0016] According to a second aspect of an embodiment of the present invention, there is provided an interface testing device, comprising:

[0017] A historical execution record acquisition module, configured to acquire a historical execution record of the interface in response to receiving a test request of the interface;

[0018] A standard total record acquisition module, used to convert each record in the historical execution record into a standard record in a specified data format, and merge each of the standard records to obtain a standard total record;

[0019] The test case generation module is used to generate test cases for interface testing based on the standard total record.

[0020] According to a third aspect of an embodiment of the present invention, there is provided an electronic device for interface testing, comprising:

[0021] one or more processors;

[0022] a storage device for storing one or more programs,

[0023] When the one or more programs are executed by the one or more processors, the one or more processors implement the method provided in the first aspect of the embodiment of the present invention.

[0024] According to a fourth aspect of an embodiment of the present invention, there is provided a computer-readable medium having a computer program stored thereon, wherein when the program is executed by a processor, the method provided by the first aspect of the embodiment of the present invention is implemented.

[0025] An embodiment of the invention has the following advantages or beneficial effects: by responding to a test request received from the interface, the historical execution record of the interface is obtained; each record in the historical execution record is converted into a standard record in a specified data format, and each standard record is merged to obtain a standard total record; based on the standard total record, a technical solution for generating test cases for interface testing is implemented, which realizes the automatic generation of test cases for the interface based on the historical execution records of the interface, which not only improves the testing efficiency and saves labor costs, but also can obtain rich test cases based on the historical execution records, improves the test coverage, and ensures the test quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0027] Figure 1 is a schematic diagram of the main process of the method for interface testing according to an embodiment of the present invention;

[0028] Figure 2 It is a schematic diagram of the principle of generating interface test cases according to an embodiment of the present invention;

[0029] Figure 3 is a schematic diagram of main modules of an interface test device according to an embodiment of the present invention;

[0030] Figure 4 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0031] Figure 5 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0032] It should be noted that the acquisition, storage and application of user personal information involved in the technical solution of the present disclosure are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0033] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0034] The current method of manually writing test cases for regression testing not only requires additional time for designing and writing test cases, but also may have certain technical barriers for complex interface testing projects and requires experienced testers, which is not conducive to the management and control of software projects. On the other hand, because the test cases are manually written, the number of test cases is relatively limited, which cannot guarantee the test coverage well, affects the quality of the test, and cannot meet the actual application well.

[0035] In order to solve the above-mentioned problems existing in the prior art, the present invention proposes a method for interface testing, which converts each record in the acquired historical execution record of the interface into a standard record and merges them, and generates a test case according to the merged standard total record to perform interface testing, thereby realizing automatic generation of test cases for the interface based on the historical execution record of the interface. This not only improves the testing efficiency and saves labor costs, but also can obtain rich test cases based on the historical execution records, thereby improving the test coverage and ensuring the test quality.

[0036] In the introduction to the embodiments of the present invention, the terms and their meanings are as follows:

[0037] JSON Schema: It is a description and specification of the JSON data format. It is a constraint on the JSON format and defines the type and structure of the data more clearly.

[0038] Figure 1 FIG. 1 is a schematic diagram of the main flow of the method for interface testing according to an embodiment of the present invention. Figure 1 As shown, the interface testing method of the embodiment of the present invention includes the following steps S101 to S103.

[0039] Step S101: In response to receiving a test request for an interface, obtaining a historical execution record of the interface.

[0040] Specifically, in the iterative process of software project development, the interface not only performs various types of tests, but also performs formal online business. The embodiment of the present invention uniformly defines the historical test records of the interface and the historical records of online business as historical execution records. The embodiment of the present invention obtains historical execution records with rich input parameter and response data pairs through the interface testing platform and online logs. Considering the large amount of online record data, a specified number of historical execution records can be randomly extracted every day, or historical execution records within a time period can be extracted every day through a scheduled task. The embodiment of the present invention does not specifically limit the method of obtaining historical execution records.

[0041] Step S102: convert each record in the historical execution record into a standard record in a specified data format, and merge each of the standard records to obtain a standard total record.

[0042] Specifically, in order to facilitate the automatic generation of test cases based on historical execution records, it is necessary to perform standardized conversion on each record in the extracted historical execution records, and then merge the records after standardized conversion to obtain an interface standard total record that retains the input parameters and corresponding response data in the historical execution records and has a unified standard.

[0043] According to one embodiment of the present invention, each record in the historical execution record is converted into a standard record in a specified data format, including: converting each record in the historical execution record into a basic record in a data exchange format; performing a standardized description of each basic record according to a dedicated protocol and in combination with preset keywords to obtain a standard record corresponding to each record.

[0044] Specifically, for each record in the extracted historical execution record, the interface parameters (input parameters) and the corresponding response contained in the record are combined and converted into a basic record in the general JSON data exchange format. If there are k records in the historical execution record, then k basic records in JSON format can be obtained. For example, the access record R1 of an interface is: the request header information is: {header1: header1val, header2: header2val}, the query parameters are: {param1: param1val, param2: param2val}, the request body is {"a": "aval", "b": true,"c": 1}, the response is: {"d": [{"d1": "d1val", "d2": 2, "d3": false}], "e": 1680169297769}, we use the request header information, query parameters, and request body as the interface parameters of the interface, and access the request keywords through the interface. (qtSchemaFieldRequest), request header keywords (qtSchemaFieldHeaders), query parameter keywords (qtSchemaFieldQueryParams), request body keywords (qtSchemaFieldBody), and response keywords (qtSchemaFieldResponse) are converted according to the JSON format to obtain the JSON basic record R1-b. It should be noted that in the embodiment of the present invention, the parameter name is defined as a parameter field, and the response name is defined as a response field. For example, header1 and header2 in the above example are parameter fields, and e is a response field.

[0045] Furthermore, considering the need to merge the various records of the interface later, a custom Schema customization keyword is designed based on the standard JSON Schema (a specification / protocol for describing the data format of JSON) to facilitate subsequent merging. In the embodiment of the present invention, the keyword representing the attribute of the parameter / response field (whether it is a required field) is set to qtSchemaFieldRequired, the keyword of the type of the parameter / response field is qtSchemaFieldType, the keyword of the subfield definition of the parameter / response field as the object type is qtSchemaFieldProperties, and the keyword of the possible value of the parameter / response field is qtSchemaFieldContentValue. The data structure of the parameters and responses in the basic records of the interface is standardized and defined through the custom Schema customization keywords. Taking the above interface access record as an example, using the preset keywords, the data structure of each parameter and response in R1-b is described in a standardized manner. For the request header information, it is: {header1: header1val}, where header1 is the parameter field and header1val is the corresponding parameter value. In the standardized description of its data structure, the value of "qtSchemaFieldRequired" is true, indicating that the attribute of the header1 parameter field is required, the value of "qtSchemaFieldType" is "string", indicating that the type of the header1 parameter field is a string type, and the value of "qtSchemaField ContentValue" is "header1val", indicating that the value corresponding to the parameter field header1 is "header1val". Using the above keywords, the data structure of each parameter and response in the JSON basic record is described in a standardized manner, and the standard record corresponding to the JSON basic record is obtained, that is, the interface standard record in the customized JSON Schema format.

[0046] According to another embodiment of the present invention, merging the standard records includes: determining a merging rule based on preset keywords; and merging the parameter fields in the standard records, as well as the values, attributes and types corresponding to the response fields according to the merging rule.

[0047] Specifically, the interface standard record description obtained above defines the data structure of a record in the interface history execution record. There are multiple records in the actual interface history execution record, and the parameter value and response value of each record are not necessarily the same. In addition, different interface access requests may have different parameter fields. Extracting only one record of the interface cannot represent the complete behavior of this interface. Only by merging as many records as possible in the interface history execution record and using rich parameters and responses can the complete behavior of the interface be obtained.

[0048] The present invention is an embodiment that takes the merging of two interface standard records in JSON Schema format into a total JSONSchema as an example, defines specific merging rules, and the merging of multiple interface standard records can be adaptively expanded according to this rule. The merging rules include attribute merging rules, type merging rules and value merging rules. The attribute merging rules: perform a logical "and" operation on the attribute values ​​corresponding to the attribute keywords of the parameter fields to be merged. Specifically: if the parameter / response field exists in both interface standard records, and the keyword qtSchemaFieldRequired is true, it indicates that this field is necessary, and the qtSchemaFieldRequired attribute of this field in the merged total JSON Schema is also true; conversely, if this field only exists in one of the interface standard records or the qtSchemaFieldRequired attribute of one of the interface standard records is false, then the field is optional in the total JSON Schema, and the qtSchemaFieldRequired attribute is false. Type merging rules: The type is based on the higher-level type of the type keyword of the parameter field to be merged, that is, the principle of taking the higher rather than the lower. Specifically: If the keyword qtSchemaFieldType of the same parameter / response field in one interface standard record is int and in another interface standard record is long, then the qtSchemaFieldType after merging is long; if the qtSchemaFieldType of the parameter / response field in any interface standard record is float, then the qtSchemaFieldType of the total JSON Schema after merging is also float. Value merging rules: The qtSchemaFieldContentValue of the same parameter / response field is directly merged. For example, if the qtSchemaFieldContentValue of one interface standard record is ["aa","bb"] and the other is ["cc","dd"], then the qtSchemaFieldContentValue of the total JSON Schema after merging is ["aa","bb","cc","dd"].

[0049] Exemplarily, assume that the above interface also has an access record R2, the request header information is {header1: header1val2}, the query parameter is {param1: param1val2}, the Body is {"a": "aval2", "b": false, "c": 1.1}, and the response is {"d": [{"d1": "d1val2", "d2": 2, "d3": false}], "e": 1680169297800}. In the embodiment of the present invention, all fields except the response field are referred to as parameter fields, that is, the parameter fields of R1 include header1, header2, param1, param2, a, b and c, and the response fields include d and e; the parameter fields of R2 include header1, param1, a, b and c, and the response fields include d and e. According to the above attribute merging rules, type merging rules and value merging rules, the attributes, types and data of the parameter / response fields of the standard record R1-b of the access record R1 and the standard record R2-b of the access record R2 are merged. Since header1 exists in both R1 and R2, and the attribute keyword qtSchemaFieldRequired is true, the qtSchemaFieldRequired of header1 of the merged total JSON Schema is true, while header2 is only in R1-b, so the qtSchemaFieldRequired of header2 of the merged total JSON Schema is false; for the parameter field c, the type keyword qtSchemaFieldType in R1-b is int, and the qtSchemaFieldType of c in R2-b is float, so the qtSchemaFieldType of c in the merged total JSON Schema is float; in addition, for the parameter field c, the value keyword qtSchemaFieldContentValue in R1 is 1, and the qtSchemaFieldContentValue in R2 is 1.1, then the merged total JSON The qtSchemaFieldContentValue of Schema c is a value set [1, 1.1]. It can be understood that according to the above-mentioned attribute merging rule, type merging rule and value merging rule, the attributes, types and values ​​of the parameter fields and response fields in each standard record are merged to obtain a standard total record.

[0050] Step S103: Generate test cases for interface testing based on the standard total record.

[0051] Specifically, the standard total record JSON Schema obtained by the above merger includes the attributes, types and merged value sets of parameter fields and response fields, which provide rich parameter and response data information for test cases to improve the test coverage of subsequently generated test cases.

[0052] According to one embodiment of the present invention, the standard total record includes the attributes and types of parameter fields, and the attributes and types of response fields; based on the standard total record, a test case is generated, including at least one of the following: based on the set of numerical values ​​corresponding to the parameter fields in the standard total record, and the attributes and types of the response fields, a forward test case of the interface is generated; based on the type of the parameter fields in the standard total record, combined with preset type boundary values, a boundary test case of the interface is generated; based on the attributes of the parameter fields in the standard total record, the necessary parameter fields of the interface are determined, and a reverse test case of the interface is generated by deleting the necessary parameter fields according to preset deletion rules.

[0053] Specifically, according to the needs of the actual test business, the embodiment of the present invention supports the selection of generating one or more of the forward test cases, boundary test cases, and reverse test cases. The forward test case is determined based on the value set of the parameter field and the expected response. It should be noted that the embodiment of the present invention is mainly a regression test of the interface. The response of the regression test is different from the response of the general functional test. The expected response of the regression test is determined by checking whether the response field meets the attributes (necessary or not) and type requirements of the response field of the total JSON Schema under the input of the parameter field.

[0054] The boundary test case is based on the type corresponding to the type keyword in the parameter field in the standard total record, combined with the preset type boundary value, to determine the boundary value of the parameter field, and generate a boundary test case based on the boundary test principle (when the value of the parameter field is the boundary value, the interface should not crash). The interface can be determined by checking the http response code of the interface. If the http response code of the interface is 200, it means that the interface has not crashed. Other values ​​indicate that the interface has crashed. Taking the total JSON Schema merged from R1-b and R2-b as an example, the parameter field of the total JSON Schema includes subfields: header1, header2, param1, param2, a, b, and c. The corresponding types are string, string, string, string, string, Boolean, and float. According to the boundary values ​​corresponding to various types in the preset type boundary values: public static String[]boundaryString={"",RandomStringUtils.Random Alphanumeric(1000,1001),null}; public static Boolean[]boundary Boolean={true,false,null}; public static Float[]boundaryFloat={1.0f,0.0f,-1.0f,Float.MAX_VALUE,Float.MIN_VALUE,null}. It can be seen that there are 2 boundary values ​​for string, 3 boundary values ​​for Boolean, and 6 boundary values ​​for float. Therefore, a boundary value of each parameter field corresponds to a test case. Accordingly, the values ​​of other parameter fields are randomly extracted from the qtSchemaFieldContentValue of the corresponding parameter field of the total JSON Schema to generate boundary test cases. As long as the interface does not crash, the test passes.

[0055] The reverse test case is mainly determined based on the properties of the parameter field of the total JSON Schema (whether it is necessary). According to the determined necessary parameter fields, the deletion rules are set. If there is only one necessary parameter field, the necessary parameter field is directly deleted, and the reverse test case is generated based on the reverse test principle (the interface should not crash when the necessary parameter field is deleted); if there are multiple necessary parameter fields, one of the necessary parameter fields is deleted each time, and the reverse test case is generated based on the reverse test principle (the interface should not crash when the necessary parameter field is deleted). Taking the total JSON Schema merged by R1-b and R2-b as an example, the parameter fields header1, param1, a, b, and c are necessary parameter fields (qtSchemaFieldRequired is true), and these five parameter fields are deleted respectively. The values ​​of other parameter fields are randomly extracted from the qtSchemaFieldContentValue of the corresponding parameter fields of the total JSONSchema, and five corresponding reverse test cases are obtained.

[0056] According to another embodiment of the present invention, the parameter field exists in the form of a set; based on the value set corresponding to the parameter field in the standard total record, and the attributes and type of the response field, a positive test case for the interface is generated, including: determining an order of arrangement calculation according to each subfield in the parameter field in the standard total record, and according to the order, fully arranging the values ​​included in the value set corresponding to each subfield to obtain a set of parameter value combinations corresponding to the parameter field of the interface; using each of the parameter value combinations as an input parameter of the test case to be generated, and the attributes and type of the response field in the standard total record as the response of the test case to be generated, to determine the corresponding positive test case.

[0057] Specifically, the subfields included in the parameter field are obtained according to the total JSON Schema, and the order of permutation calculation is determined according to the order of the subfields in the total JSON Schema. Of course, it can also be in a certain agreed order, as long as a fixed order of permutation calculation is used; according to the order of permutation calculation, multiple possible parameter value combinations corresponding to the parameter field can be obtained by performing full permutation calculation on the values ​​included in the value set of each subfield, and these parameter value combinations constitute a set of parameter value combinations; each parameter value combination is used as the input parameter of the positive test case to be generated, and the Schem assertion is generated according to the attributes and types of the response fields of the total JSON Schema, and then the corresponding positive test cases are obtained, that is, the number of parameter value combinations corresponds to the number of positive test cases generated. For example, if the qtSchemaFieldRequired of the response field d2 of the total JSON Schema is true and the qtSchemaFieldType is int, then when each parameter value combination is used as the input parameter, the d2 response of its interface should be a necessary field, that is, the response of the interface must have the existence of d2, and the type of d2 is an integer. If it meets the attributes and types of the response field, it is determined that the positive test passes.

[0058] For example, the parameter fields of the above total JSON Schema include: header1, header2, param1, param2, a, b and c. The parameter fields of the schema are arranged in the order of header1, header2, param1, param2, a, b, and c. Correspondingly, their value sets are ["header1val", "header1val2"], ["header2val"], ["param1val", "param1val2"], ["param2val"], ["aval", "aval2"], [true, false], [1, 1.1]; according to the order of arrangement and calculation, the values ​​in the value set of each subfield are fully arranged, and the values ​​in these value sets are arranged in order into possible value combinations of the parameter field to obtain 32 parameter value combinations corresponding to the parameter field. For specific examples of parameter value combinations, see Table 1 below. The first row is each subfield and the order of arrangement and calculation. Each subsequent row represents a parameter value combination. This table only illustrates 8 of the 32 parameter value combinations.

[0059] Table 1:

[0060] header1 header2 param1 param2 a b c header1val header2val param1val param2val aval true 1 header1val2 header2val param1va1 param2val aval true 1 header1val header2val param1val2 param2val aval true 1 header1va l2 header2val param1va12 param2val aval true 1 header1val header2val param1val param2val Ava2 true 1 header1val2 header2val param1va1 param2val Ava2 true 1 header1val header2val param1val2 param2val Ava2 true 1 header1va l2 header2val param1va12 param2val Ava2 true 1 … … … … … … …

[0061] According to yet another embodiment of the present invention, before using each of the parameter value combinations as an input parameter of the test case to be generated, the method further comprises: processing the set of the parameter value combinations using a pairing algorithm.

[0062] Specifically, considering that some parameter value combinations in the set of parameter value combinations obtained by the above full permutation may not be needed in the actual test business, or there are some duplications and redundancies in the test business, the embodiment of the present invention obtains the set of parameter value combinations corresponding to the parameter field of the interface, and uses the pairwise algorithm to simplify and optimize the number of sets of parameter value combinations before using each of the parameter value combinations as the input parameter of the test case to be generated. Through the optimization of the pairwise algorithm, the number of parameter value combinations in the embodiment of the present invention is reduced from 32 to 7, and 7 positive test cases are generated based on these 7 parameter value combinations, as shown in Table 2 below.

[0063] Table 2

[0064] header1 header2 param1 param2 a b c header1val header2val param1val param2val aval true 1 header1val2 header2val param1val2 param2val aval2 true 1.1 header1val header2val param1val2 param2val aval2 false 1 header1val2 header2val param1val param2val aval false 1.1 header1val header2val param1val2 param2val aval true 1.1 header1val2 header2val param1val param2val aval true 1 header1val header2val param1val param2val aval2 true 1

[0065] According to another embodiment of the present invention, the parameter field exists in the form of a set; according to the type of the parameter field in the standard total record, combined with a preset type boundary value, a boundary test case of the interface is generated, including: according to the type of each subfield in the parameter field, combined with a preset type boundary value, determining the boundary value corresponding to each subfield, and the boundary value has an order; according to the order of the boundary values ​​of each subfield in the parameter field, assigning corresponding boundary values ​​to each subfield in the parameter field until the boundary values ​​of each subfield are assigned; according to the boundary value assigned to each subfield in the parameter field each time, a corresponding boundary test case is generated.

[0066] Specifically, according to the above-mentioned boundary test case generation method in which one boundary value of each subfield corresponds to one test case, it can be seen that the total JSON Schema merged with R1-b and R2-b can generate 2*2*2*2*2*2*3*6=576 test cases. Although this can ensure full coverage of boundary values, too many test cases will not only burden system resources, but also affect test efficiency. Overall, the cost-effectiveness is not high. We adopt an optimized boundary test case generation method that can involve the boundary values ​​of multiple subfields each time. This not only takes into account the boundary value of each subfield, but also reduces the number of test cases.

[0067] Furthermore, according to the type of each subfield in the total JSON Schema parameter field and the preset type boundary value, the boundary value corresponding to each subfield is determined. For example, the subfields header1, header2, param1, param2, a, b and c correspond to types string, string, string, string, string, Boolean and float, according to the preset type boundary value: public static String[]boundaryString={"",RandomStringUtils.RandomAlphanumeric(1000,1001),null};public static Boolean[]boundary Boolean={true,false,null};public static Float[]boundaryFloat={1.0f,0.0f,-1.0f,Float.MAX_VALUE,Float.MIN_VALUE,null}。 It can be seen that the boundary values ​​of string type are RandomStringUtils.Random Alphanumeric(1000,1001) and null, the boundary values ​​of Boolean are true, false, and null, and the boundary values ​​of float are 1.0f, 0.0f, -1.0f, Float.MAX_VALUE, Float.MIN_VALUE, and null.

[0068] Subsequently, in the order of the boundary values ​​of each subfield, each subfield is assigned a corresponding boundary value according to a specified sequence number until the boundary values ​​of each subfield are assigned. For example, the first time, each subfield in the parameter field is assigned its own first boundary value; the second time, each subfield in the parameter field is assigned its own second boundary value. At this time, since there are only two boundary values ​​for subfields header1, header2, param1, and param2, the third boundary value is assigned to subfields b and c in the parameter field for the third time, and the values ​​of other subfields are randomly drawn from their qtSchemaFieldContentValue; similarly, the fourth boundary value is assigned to subfield c in the parameter field for the fourth time, and the values ​​of other subfields are randomly drawn from their qtSchemaFieldContentValue; the fifth time, the fifth boundary value is assigned to subfield c in the parameter field, and the values ​​of other subfields are randomly drawn from their qtSchemaFieldContentValue; the sixth time, the sixth boundary value is assigned to subfield c in the parameter field, and the values ​​of other subfields are randomly drawn from their qtSchemaFieldContentValue. At this time, the boundary values ​​of all subfields have been assigned, that is, 6 boundary value assignments have been performed on the parameter field. According to the boundary values ​​assigned to each subfield in the parameter field each time, 6 boundary test cases can be generated.

[0069] Through the test case generation method of the embodiment of the present invention, different types of test cases (forward, boundary and reverse) can be generated flexibly and diversely as needed. When the number of generated test cases is large, the number of generated test cases can be optimized through a pairwise algorithm or a customized optimization and simplification rule to achieve a balance between test coverage and test efficiency.

[0070] Figure 2It is a schematic diagram of the principle of interface test case generation in an embodiment of the present invention. For a certain interface, record 1, record 2, ..., record k of its historical execution record are obtained; record 1, record 2, ..., record k are converted into basic records JSON1, JSON2, ..., JSONk in JSON data exchange format respectively; then, according to preset keywords, the data structure of each basic record is standardized to obtain interface standard records JSON Schema1, JSONSchema2, ..., JSON Schemak corresponding to each basic record; each standard record JSON Schema1, JSON Schema2, ..., JSONSchemak is merged into an interface standard total record JSON Schema; according to the interface standard total record JSON Schema combined with the test business needs, test case 1, test case 2, test case 3, ..., test case n in JSON data exchange format are automatically generated, and these test cases are at least one test case of forward test cases, boundary test cases, and reverse test cases.

[0071] The interface testing method provided in the embodiment of the present invention automatically generates various types of test cases for the interface based on the historical execution records of the interface, which not only improves the testing efficiency and saves labor costs, but also can flexibly generate rich test cases required by the testing business, thereby improving the test coverage and ensuring the quality of the test.

[0072] Figure 3 FIG. 1 is a schematic diagram of the main modules of the device for interface testing according to an embodiment of the present invention. Figure 3 As shown, the interface testing device 300 mainly includes a historical execution record acquisition module 301 , a standard total record acquisition module 302 and a test case generation module 303 .

[0073] The historical execution record acquisition module 301 is used to obtain the historical execution record of the interface in response to receiving a test request of the interface;

[0074] A standard total record acquisition module 302, configured to convert each record in the historical execution record into a standard record in a specified data format, and merge each of the standard records to obtain a standard total record;

[0075] The test case generation module 303 is used to generate test cases for interface testing according to the standard total record.

[0076] According to one embodiment of the present invention, the standard total record acquisition module 302 is also used to: convert each record in the historical execution record into a basic record in a data exchange format; perform a standardized description of each basic record according to a dedicated protocol and in combination with preset keywords to obtain a standard record corresponding to each record.

[0077] According to another embodiment of the present invention, the standard total record acquisition module 302 is also used to: determine a merging rule based on preset keywords; and merge the parameter fields in each of the standard records, as well as the values, attributes and types corresponding to the response fields according to the merging rules.

[0078] According to another embodiment of the present invention, the standard total record includes attributes and types of parameter fields, and attributes and types of response fields; the test case generation module 303 is also used for at least one of the following: generating a forward test case for the interface based on a set of values ​​corresponding to the parameter fields in the standard total record, and attributes and types of response fields; generating a boundary test case for the interface based on the type of the parameter fields in the standard total record and a preset type boundary value; determining necessary parameter fields of the interface based on the attributes of the parameter fields in the standard total record, and generating a reverse test case for the interface by deleting the necessary parameter fields according to preset deletion rules.

[0079] According to another embodiment of the present invention, the parameter field exists in the form of a set; the test case generation module 303 is also used to: determine the order of arrangement calculation according to each subfield in the parameter field in the standard total record, and arrange all the values ​​included in the value set corresponding to each subfield according to the order to obtain a set of parameter value combinations corresponding to the parameter field of the interface; use each of the parameter value combinations as an input parameter of the test case to be generated, and the attributes and types of the response fields in the standard total record as the response of the test case to be generated, to determine the corresponding positive test case.

[0080] According to another embodiment of the present invention, the interface testing device 300 also includes a set processing module (not shown in the figure), which is used to: use a pairing algorithm to process the set of parameter value combinations before using each parameter value combination as an input parameter for the test case to be generated.

[0081] According to another embodiment of the present invention, the parameter field exists in the form of a set; the test case generation module 303 is further used to: determine the boundary value corresponding to each subfield according to the type of each subfield in the parameter field and in combination with a preset type boundary value, and the boundary value has an order; assign corresponding boundary values ​​to each subfield in the parameter field according to the order of the boundary values ​​of each subfield in the parameter field until the boundary values ​​of each subfield are assigned; and generate corresponding boundary test cases according to the boundary values ​​assigned to each subfield in the parameter field each time.

[0082] Figure 4 is an exemplary system architecture diagram to which embodiments of the present invention can be applied.

[0083] like Figure 4 As shown, system architecture 400 may include terminal devices 401, 402, 403, network 404 and server 405. Network 404 is used to provide a medium for communication links between terminal devices 401, 402, 403 and server 405. Network 404 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0084] Users can use terminal devices 401, 402, 403 to interact with server 405 through network 404 to receive or send messages, etc. Various communication client applications, such as interface test applications, etc., can be installed on terminal devices 401, 402, 403 (only as an example).

[0085] The terminal devices 401 , 402 , and 403 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0086] Server 405 may be a server that provides various services, such as a background management server (only an example) that provides support for interface testing performed by users using terminal devices 401, 402, and 403. In response to receiving a test request for an interface, the background management server may obtain a historical execution record of the interface; convert each record in the historical execution record into a standard record of a specified data format, and merge each of the standard records to obtain a standard total record; generate a test case based on the standard total record to perform interface testing and other processing, and feed back the processing result (such as a test result, etc. - only an example) to the terminal device.

[0087] It should be noted that the interface testing method provided in the embodiment of the present invention is generally executed by the server 405 , and accordingly, the interface testing device is generally set in the server 405 .

[0088] It should be understood that Figure 4 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0089] Reference below Figure 5 , which shows a schematic diagram of the structure of a computer system 500 of a terminal device or a server suitable for implementing an embodiment of the present invention. Figure 5 The terminal device or server shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0090] like Figure 5 As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage part 508 into a random access memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the system 500 are also stored. The CPU 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0091] The following components are connected to the I / O interface 505: an input section 506 including a keyboard, a mouse, etc.; an output section 507 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 510 as needed, so that a computer program read therefrom is installed into the storage section 508 as needed.

[0092] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 509, and / or installed from the removable medium 511. When the computer program is executed by the central processing unit (CPU) 501, the above-mentioned functions defined in the system of the present invention are executed.

[0093] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination thereof.

[0094] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0095] The units involved in the embodiments of the present invention may be implemented by software or hardware. The units described may also be set in a processor, for example, it may be described as: a processor including: a historical execution record acquisition module, a standard total record acquisition module and a test case generation module.

[0096] The names of these modules do not, in some cases, limit the modules themselves. For example, the historical execution record acquisition module can also be described as "a module for acquiring historical execution records of an interface in response to receiving a test request of the interface."

[0097] On the other hand, the present invention also provides a computer-readable medium, which may be included in the device described in the embodiment; or may exist independently without being assembled into the device. The computer-readable medium carries one or more programs, and when the one or more programs are executed by the device, the device includes: in response to receiving a test request of the interface, obtaining the historical execution record of the interface; converting each record in the historical execution record into a standard record of a specified data format, and merging each of the standard records to obtain a standard total record; generating a test case according to the standard total record to perform interface testing.

[0098] The technical solution according to the embodiment of the present invention has the following advantages or beneficial effects: by responding to a test request received from the interface, a historical execution record of the interface is obtained; each record in the historical execution record is converted into a standard record in a specified data format, and each standard record is merged to obtain a standard total record; based on the standard total record, a test case is generated to perform interface testing. The technical solution realizes the automatic generation of interface test cases based on the historical execution records of the interface, which not only improves the testing efficiency and saves labor costs, but also can obtain rich test cases based on the historical execution records, improves the test coverage, and ensures the test quality.

[0099] The specific implementation methods described herein do not constitute limitations on the scope of protection of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention shall be included in the scope of protection of the present invention.

Claims

1. A method for interface testing, characterized in that: include: In response to receiving a test request for an interface, obtaining a historical execution record of the interface; Convert each record in the historical execution record into a standard record in a specified data format, and merge each of the standard records to obtain a standard total record; Based on the standard total record, generate test cases for interface testing.

2. The method according to claim 1, characterized in that Convert each record in the historical execution record into a standard record in a specified data format, including: Convert each record in the historical execution record into a basic record in a data exchange format; According to a dedicated protocol and in combination with preset keywords, each of the basic records is described in a standardized manner to obtain a standard record corresponding to each of the records.

3. The method according to claim 1, characterized in that Merge each of the standard records, including: Determine the merging rules based on the preset keywords; According to the merging rule, the parameter fields in each of the standard records, as well as the values, attributes and types corresponding to the response fields are merged.

4. The method according to claim 1, characterized in that: The standard total record includes the attributes and types of parameter fields and the attributes and types of response fields; Generate a test case based on the standard total record, including at least one of the following: Generate a positive test case for the interface according to the value set corresponding to the parameter field in the standard total record, and the attribute and type of the response field; Generate a boundary test case of the interface according to the type of the parameter field in the standard total record and the preset type boundary value; According to the attributes of the parameter fields in the standard total record, the necessary parameter fields of the interface are determined, and the reverse test case of the interface is generated by deleting the necessary parameter fields according to a preset deletion rule.

5. The method according to claim 4, characterized in that The parameter fields exist in the form of a set; Generate a positive test case for the interface according to the value set corresponding to the parameter field in the standard total record, and the attribute and type of the response field, including: Determine the order of performing arrangement calculation according to each subfield in the parameter field in the standard total record, and perform full arrangement of the values ​​included in the value set corresponding to each subfield according to the order to obtain a set of parameter value combinations corresponding to the parameter field of the interface; Each of the parameter value combinations is used as an input parameter of the test case to be generated, and the attribute and type of the response field in the standard total record is used as the response of the test case to be generated, and the corresponding positive test case is determined.

6. The method according to claim 5, characterized in that Before using each of the parameter value combinations as input parameters for the test case to be generated, the method further includes: The set of parameter value combinations is processed using a pair-wise algorithm.

7. The method according to claim 4, characterized in that The parameter fields exist in the form of a set; According to the type of the parameter field in the standard total record, combined with the preset type boundary value, a boundary test case of the interface is generated, including: According to the type of each subfield in the parameter field, combined with a preset type boundary value, a boundary value corresponding to each subfield is determined, and the boundary value has an order; According to the order of the boundary values ​​of the subfields in the parameter field, corresponding boundary values ​​are allocated to the subfields in the parameter field until the boundary values ​​of the subfields are allocated; According to the boundary values ​​assigned to the subfields in the parameter field each time, a corresponding boundary test case is generated.

8. An interface testing device, characterized in that: include: A historical execution record acquisition module, configured to acquire a historical execution record of the interface in response to receiving a test request of the interface; A standard total record acquisition module, used to convert each record in the historical execution record into a standard record in a specified data format, and merge each of the standard records to obtain a standard total record; The test case generation module is used to generate test cases for interface testing based on the standard total record.

9. A mobile electronic device terminal, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.

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

Images