Data generation method and device, storage medium and electronic equipment

Abstract

The invention discloses a data generation method and device, a storage medium and electronic equipment. The method comprises the steps that an interface constraint condition of a service interface of a first program end is obtained, the interface constraint condition is used for constraining message formats of a request message and a response message of the service interface, and the first program end is used for achieving service logic of an application program; debugging data conforming to the interface constraint condition is generated for a second program end through the interface constraint condition, the second program end is used for achieving program interface logic of the application program, and the debugging data is used for conducting simulation joint debugging on the second program end and the first program end under the condition that the service interface is not completely created. The technical problem of inaccurate data is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the computer field, in particular to a data generation method and device, a storage medium and an electronic device. BACKGROUND

[0002] Application debugging is an indispensable part of the application development life cycle, which aims to verify the correctness of program functions, the efficiency of performance and the fluency of user experience, and to ensure that the software can run stably in the actual environment. In the case where the server-side interface is not developed, the current generation of debugging data for the client of the application usually adopts a manual generation method based on the client.

[0003] However, the above generation method of debugging data has the technical problem that the manually generated data may not be completely consistent with the actual requirements or data structure of the backend interface, resulting in inaccurate generated data.

[0004] At present, there is no effective solution to the above problems. SUMMARY

[0005] The embodiments of the present application provide a data generation method and device, a storage medium and an electronic device to at least solve the technical problem of inaccurate generated data.

[0006] According to an aspect of the embodiments of the present application, a data generation method is provided, comprising:

[0007] obtaining an interface constraint condition of a service interface of a first program side, wherein the interface constraint condition is used to constrain the message format of the request message and the response message of the service interface, and the first program side is used to implement the business logic of the application; and generating debugging data that conforms to the interface constraint condition for a second program side by using the interface constraint condition, wherein the second program side is used to implement the program interface logic of the application, and the debugging data is used to simulate joint debugging of the second program side and the first program side in the case where the service interface is not completed.

[0008] According to another aspect of the embodiments of the present application, a data generation device is also provided, comprising: an obtaining unit, configured to obtain an interface constraint condition of a service interface of a first program side, wherein the interface constraint condition is used to constrain the message format of the request message and the response message of the service interface, and the first program side is used to implement the business logic of the application; and a generating unit, configured to generate debugging data that conforms to the interface constraint condition for a second program side by using the interface constraint condition, wherein the second program side is used to implement the program interface logic of the application, and the debugging data is used to simulate joint debugging of the second program side and the first program side in the case where the service interface is not completed.

[0009] According to a further aspect of the embodiments of the present application, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program. The computer program is configured to perform the data generation method when executed.

[0010] According to a further aspect of the embodiments of the present application, a computer program product or computer program is provided, and the computer program product or computer program comprises 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 the processor executes the computer instructions, so that the computer device performs the data generation method.

[0011] According to a further aspect of the embodiments of the present application, an electronic device is provided, and the electronic device comprises a memory and a processor. The memory stores a computer program, and the processor is configured to perform the data generation method by using the computer program.

[0012] In the embodiments of the present application, the interface constraint condition of the service interface of the first program end is acquired, wherein the interface constraint condition is used to constrain the message format of the request message and the response message of the service interface, and the first program end is used to implement the business logic of the application program. The debugging data conforming to the interface constraint condition is generated for the second program end by using the interface constraint condition, wherein the second program end is used to implement the program interface logic of the application program, and the debugging data is used to perform the simulated joint debugging on the second program end and the first program end in the case that the service interface is not completed. In other words, by using the embodiments of the present application, the technical problem of inaccurate data in the related art is solved, and the accuracy of the debugging data is improved. BRIEF DESCRIPTION OF DRAWINGS

[0013] The accompanying drawings, which are included to provide a further understanding of the present application, constitute a part of the present application, and illustrate the embodiments of the present application and the description thereof, and do not constitute improper limitations to the present application. In the drawings:

[0014] Figure 1 is a flow chart of an optional data generation method according to the embodiments of the present application;

[0015] Figure 2 is a schematic diagram of an optional data generation method according to the embodiments of the present application;

[0016] Figure 3 is a schematic diagram of another optional data generation method according to the embodiments of the present application;

[0017] Figure 4 is a schematic diagram of a further optional data generation method according to the embodiments of the present application;

[0018] Figure 5 is a schematic diagram of still another optional data generation method according to an embodiment of the application;

[0019] Figure 6 is a schematic diagram of still another optional data generation method according to an embodiment of the application;

[0020] Figure 7 is a schematic diagram of still another optional data generation method according to an embodiment of the application;

[0021] Figure 8 is a schematic diagram of still another optional data generation method according to an embodiment of the application;

[0022] Figure 9 is a flowchart of an optional data generation method according to an embodiment of the application;

[0023] Figure 10 is a schematic diagram of still another optional data generation method according to an embodiment of the application;

[0024] Figure 11 is a schematic diagram of still another optional data generation method according to an embodiment of the application;

[0025] Figure 12 is a structural schematic diagram of an optional data generation apparatus according to an embodiment of the application;

[0026] Figure 13 is a structural schematic diagram of an optional electronic device according to an embodiment of the application. DETAILED DESCRIPTION

[0027] In order to enable persons skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative labor should fall within the protection scope of the present application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and in the above drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0029] As an optional solution, as shown in Figure 1 The above data generation method includes:

[0030] S102, obtaining the interface constraint condition of the service interface of the first program end, wherein the interface constraint condition is used to constrain the message format of the request message and the response message of the service interface, and the first program end is used to implement the business logic of the application program.

[0031] It should be noted that the above data generation method can be but is not limited to applied in a front-end and back-end separation development scenario. Specifically, in a front-end and back-end separation architecture, the front-end and the back-end can be developed independently, but when debugging, the consistency of the interface and the correctness of the data format need to be ensured. The debugging data can be generated by an automatic tool interface agreement condition, so that the front-end can be simulated for debugging when the back-end service has not been completed, ensuring the correctness of the front-end logic, and avoiding multiple modifications due to changes in the back-end interface.

[0032] Optionally, the above first program end can be but is not limited to used to represent a back-end service, which is a part of the application program responsible for processing business logic and data operation. In a front-end and back-end separation architecture, the back-end is usually responsible for data storage, processing and implementation of business rules.

[0033] It should be noted that the above service interface can be but is not limited to including an application programming interface (API) provided by the back-end to the front-end call, which is used to define how the front-end communicates with the back-end, including request method, request path, request parameter and response format, etc.

[0034] Further, the interface constraint condition can be, but is not limited to, an interface specification predefined by the back end using a specific language protocol, which describes the data format of the service interface in detail, including the specific fields, types, whether required or not, and field descriptions of the request and response messages, to ensure the consistency and standardization of the data exchange between the front end and the back end. The language protocol corresponding to the interface constraint condition can be, but is not limited to, Protocol Buffers (Protobuf) or other description languages, which are not limited in the embodiment. Specifically, Protobuf is a language-neutral and platform-neutral structured data serialization mechanism for efficiently defining and evolving interface protocols. For example, taking the Protobuf protocol with the above interface constraint condition as an example, a code snippet in the Protobuf protocol can be as shown in the following table. Figure 2 It should be noted that, Figure 2 The above is only an optional example provided by the Protobuf protocol for ease of explanation, and the content of the Protobuf protocol can be related to the needs of the actual application program, which is not limited in the embodiment.

[0035] Further, it should be noted that when generating the Protobuf protocol, annotation information can be added in the protocol to facilitate the generation of the subsequent interface description document.

[0036] Optionally, the request message can be, but is not limited to, a request sent by the front end to the back end, such as a Hypertext Transfer Protocol (HTTP) request, which contains the data and parameters required to complete an operation and is organized according to the format defined in the interface constraint condition.

[0037] It should be noted that the response message can be, but is not limited to, a response of the back end to the front end request, which usually contains the result data, status code and possible error information of the request, and also follows the message format specified in the interface constraint condition.

[0038] In S104, the interface constraint condition is used to generate debugging data conforming to the interface constraint condition for a second program end, wherein the second program end is used to implement the program interface logic of the application program, and the debugging data is used to simulate the joint debugging of the second program end and the first program end in the case where the service interface is not completed.

[0039] Further, the second program end can be, but is not limited to, the front end application, which is responsible for the user interface and user experience in the application program, implements the program interface logic, and interacts with the back end by calling the service interface.

[0040] Optionally, the above debugging data can include but is not limited to at least: configuration mock object (Mock) data, used to simulate the response behavior of the backend when the backend service interface is not completed or unavailable, so that the front-end development can be carried out independently in the "no backend" environment; interface description document, which describes in detail the usage of the service interface, including request and response formats, parameter descriptions, etc., for reference by developers to ensure consistency and accuracy of front-end and back-end development.

[0041] It should be noted that the above simulation joint debugging can refer to, but is not limited to, the process of front-end simulating the response of the backend service by using the debugging data (mock data and interface document) when the backend interface is not ready, so as to independently develop and test the function. This helps to speed up the development process and reduce the waiting time and cost of front-end and back-end joint debugging.

[0042] In the embodiment of the present application, the interface constraint condition of the service interface of the first program end is obtained, wherein the interface constraint condition is used to constrain the message format of the request message and the response message of the service interface, and the first program end is used to implement the business logic of the application program. The debugging data conforming to the interface constraint condition is generated for the second program end by using the interface constraint condition, wherein the second program end is used to implement the program interface logic of the application program, and the debugging data is used to simulate the joint debugging of the second program end and the first program end when the service interface is not completed. By obtaining the interface constraint condition from the first program end responsible for the business logic (usually referred to as the backend service) in the embodiment of the present application, the structure of the request and response messages of the service interface is described in detail, which ensures that the generated debugging data strictly follows the actual service interface definition, and avoids the common problems of field omission and type mismatch when manually generating data. Further, according to the above obtained interface constraint condition, the debugging data is automatically generated for the second program end (such as the front end) responsible for the program interface logic. Here, the debugging data is used to simulate the case where the front-end layer can still be effectively developed and tested in the absence of real service interface response. In other words, by automatically generating debugging data conforming to the interface constraint in the embodiment of the present application, the development and testing work can continue when the backend interface is missing or not completed, which is not limited by the progress of the backend, ensures that the generated debugging data is consistent with the actual interface logic, solves the technical problem of low accuracy of the generated data, and achieves the technical effect of improving the accuracy of the debugging data.

[0043] As an optional solution, generating debugging data conforming to the interface constraint condition for the second program end by using the interface constraint condition includes:

[0044] The simulation response data is generated according to the interface constraint condition, and the interface description document is generated according to the interface constraint condition, wherein the simulation response data is used to simulate the response data returned by the service interface to the second program end after the service interface obtains the calling request sent by the second program end, and the interface description document is used to describe the service interface.

[0045] It should be noted that the simulation response data generated according to the interface constraint condition can be but is not limited to that an automatic tool parses the service interface definition in the protobuf file (i.e., the interface constraint condition), including the structure and metadata of all response messages, and then generates a series of preset or random example response data, which is completely consistent with the format and field of the real response, but the specific content is for testing purposes rather than real business data.

[0046] Optionally, such simulation response data can be but is not limited to mock data used by front-end developers when performing UI and logic testing. It allows the front end to simulate a complete calling link without the backend service, so as to evaluate whether the front-end implementation can correctly handle data in different situations. Specifically, the simulation response data described above can be but is not limited to a series of data instances with the same structure as the real response, but the values of these data instances are usually preset or randomly generated by an automatic tool, for simulating the behavior of the backend interface without an actual backend service, so that the front end can be independently developed and tested.

[0047] Further, the interface description document generated according to the interface constraint condition can be but is not limited to that an automatic tool extracts all necessary metadata from the protobuf definition, including the service name, method, structure of request and response messages, comments and descriptions, and then automatically generates a complete and easy-to-understand interface document in the Markdown format. This document contains all the information of the service interface, which can be used as a reference for development and testing from the perspective of the front end.

[0048] Optionally, the generation of such interface description document can be but is not limited to that an automatic tool converts all service interface information contained in the protobuf into a human-readable document form, which not only covers the basic information of the interface, but also includes detailed request parameters, response fields and corresponding type descriptions, and even example requests and responses, so as to facilitate front-end developers to quickly understand and use the interface.

[0049] It should be noted that in some embodiments, when generating the interface description document, anchor links and back-to-top indexes can be but are not limited to added in the interface description document. For example, the structure of the interface description document described above can be but is not limited to as follows: Figure 3As shown, the left side may display navigation information including, but is not limited to, different interface categories and names for the application, while the right side displays detailed descriptions related to the interfaces. The documentation page may include a "back to top" button and an anchor index for services and methods; these can be used to automatically jump to the corresponding location in the documentation via clickable titles. Furthermore, when generating the interface description documentation, anchor links for jumping to the actual interface code page can be added, thus enabling clickable navigation from the documentation to the code (or online documentation). It should be noted that... Figure 3 This is merely an optional example provided to facilitate the explanation of the above content; there are no limitations on the specific implementation of the above data generation method.

[0050] In this embodiment, simulated response data and an interface description document are generated according to interface constraints. The simulated response data simulates the response data returned by the service interface to the second program after receiving a call request from the second program. The interface description document describes the service interface. Using this embodiment, simulated response data is automatically generated using interface constraints obtained from the first program. The structure and type of this data strictly follow the interface definition, allowing the second program (frontend) to use simulated data for development and testing even when the service interface is not fully implemented. This ensures that the frontend logic can handle the backend interface response as expected. Specifically, it eliminates the bottleneck of frontend development stalling due to incomplete backend interfaces, improves frontend development efficiency, and provides a stable test data foundation for the testing team, enhancing the effectiveness and coverage of testing. The interface description document, automatically generated using interface constraints, details the request and response message formats, parameter types, and data structures of the service interface, ensuring the accuracy and timeliness of the document content and eliminating the need for backend developers to spend extra time manually writing or maintaining it. This not only improves the quality of documentation but also reduces communication costs between the front-end and back-end, as front-end developers can directly obtain specific information about the API from the documentation, reducing the need for inquiries and interpretations. Furthermore, the automated generation of documentation helps the team adhere to the principle of "documentation first," improving project management and collaboration efficiency.

[0051] As an optional approach, simulated response data is generated according to interface constraints, including:

[0052] Obtain the response message structure of the service interface indicated in the interface constraints. The response message structure includes the identifier of the response field, the type of the response field, the field description of the response field, and the field constraints of the response field.

[0053] Simulated response data is generated based on the response message structure.

[0054] It should be noted that the response message structure of the service interface can include but is not limited to the identification (i.e. field name) of each field in the response message, the field type, the field description (if any) and the field constraints (such as mandatory, default value, range, etc.).

[0055] Further, the above-mentioned response message structure can be but not limited to refer to the definition in protobuf, an automated tool builds a structured model, which describes in detail which fields the response message returned by the service interface should contain, the type of each field, and the description and constraints of the field, providing a basis for generating mock data.

[0056] Optionally, the identification of the above-mentioned response field can be but not limited to used to represent the unique name or identifier of each field in the response message, which is used to reference and set the field value in the generated mock data.

[0057] It should be noted that the type of the above-mentioned response field can include but is not limited to the field data type described in protobuf definition, such as string, int32, bool, enum or complex message type, etc., which does not make any limitation in this embodiment, and these type information determines the format of the corresponding field value in the mock data.

[0058] Further, the field description of the above-mentioned response field can be but not limited to refer to the annotation or description beside the field definition in the protobuf file, which provides the business meaning of the field, and facilitates the generated mock data to be closer to the actual business scenario.

[0059] Optionally, the field constraints of the above-mentioned response field can be but not limited to used to represent whether the field is mandatory, default value, value range and other limit conditions, which determines the compliance of the field value when generating mock data.

[0060] It should be noted that the above-mentioned generation of simulated response data based on the response message structure can include but is not limited to generating a series of preset or random field values according to the parsed response message structure, combining them into mock data consistent with the return format of the backend interface, so as to be used by the front end (second program end) in the development and test stage.

[0061] In the embodiments of the present application, a response message structure of a response message of a service interface indicated in the interface constraint condition is acquired, wherein the response message structure includes identification of a response field in the response message, type of the response field, field description of the response field, and field constraint of the response field; and simulation response data is generated based on the response message structure. By using the embodiments of the present application, in the development process, the front end can acquire simulation response data conforming to the interface definition in real time, thereby quickly verifying the function implementation, without waiting for the development and deployment of the back end service, accelerating the development feedback cycle and promoting rapid iteration.

[0062] As an optional solution, before the interface description information is generated according to the interface constraint condition, the following steps are further included:

[0063] The request message structure and the response message structure indicated in the interface constraint condition are acquired, wherein the request message structure includes identification of a request field in a request message, type of the request field, field description of the request field, and field constraint of the request field, and the response message structure includes identification of a response field in a response message, type of the response field, field description of the response field, and field constraint of the response field.

[0064] Based on the request message structure and the response message structure, an interface call file of the service interface is generated, wherein the interface call file includes a first sub-file for triggering the request message and sending the request message to the service interface, and a second sub-file for constraining the field type of the request field carried in the request message and the field type of the response field carried in the response message in the first program.

[0065] Optionally, the request message structure can be, but is not limited to, used to represent specific constitution of the request message in the interface constraint condition, covering detailed information such as identification, type, field description, and field constraint of the request field, providing necessary input for generating the first sub-file (interface definition) and the second sub-file (type definition) in the interface call file, and ensuring that the front end can accurately construct the request message when calling the interface.

[0066] Optionally, the above response message structure can be used to represent the specific composition of the response message in the interface constraint condition, including the identification, type, field description, field constraint, and other detailed information of the response field, which is not only used to generate mock data for independent development and integration testing of the front end when the backend interface is not ready, but also provides key content for generating interface description documents to help the front end understand and use the data returned by the interface. The above type definition can be used to indicate the TypeScript type definition file (TS type definition for short). The above TS type definition can be used to indicate the specific definition of the field type of the request field and the response field generated based on the request message structure and the response message structure in the interface calling file. It provides strict type constraints for front-end development, ensuring that the correct data type is used when writing code, thereby improving the maintainability and stability of the code. At the same time, the type definition also provides code hints and automatic completion functions for development tools, further improving development efficiency. In addition, the type definition also serves as a bridge for the interaction between the front end and the back end, ensuring consistency in field types between the front end and the back end, and avoiding runtime errors caused by type mismatches.

[0067] Optionally, the above interface calling file can be used to represent a file set generated based on the request message structure and the response message structure, which includes a first sub-file (interface definition) for triggering the request message and sending the request message to the service interface, and a second sub-file (type definition) for constraining the field type of the request field carried in the request message and the field type of the response field carried in the response message in the first program (backend), providing clear interface calling specifications and type constraints for the front end, and helping to improve development efficiency and code quality.

[0068] Optionally, the above first sub-file can be used to represent the specific content of the interface calling file responsible for defining the interface, including the name of the interface, the request method, the request path, the request parameter, and other information, which provides a clear interface calling entry and method for the front end, enabling the front end to accurately trigger the request message and send the request message to the service interface according to the definition, and is an important basis for the interaction between the front end and the back end.

[0069] Optionally, the above second sub-file can be used to represent the TS type definition file included in the interface calling file, which defines the type constraints of the request field and the response field according to the request message structure and the response message structure, providing strict type checking and code hints for the front end, helping front-end developers avoid type errors when writing code, improving the maintainability and stability of the code, and also helping the front end and the back end to maintain consistency in interface field types.

[0070] It should be noted that the generated mock data and response message structure can be but not limited to located in the same code file, for example, Figure 4 The code snippet shown in the above code file includes the generated mock data, type definition, and interface definition. It should be noted that, Figure 4 The generated mock data, type definition, and interface definition are only optional examples provided for the convenience of explanation, and are related to the actual application program, which is not limited in the embodiment.

[0071] In the embodiment of the present application, the request message structure and the response message structure indicated in the interface constraint condition are obtained, wherein the request message structure includes the identification of the request field in the request message, the type of the request field, the field description of the request field, and the field constraint of the request field, and the response message structure includes the identification of the response field in the response message, the type of the response field, the field description of the response field, and the field constraint of the response field; based on the request message structure and the response message structure, the interface calling file of the service interface is generated, wherein the interface calling file includes a first sub-file for triggering the request message and sending the request message to the service interface, and a second sub-file for constraining the field type of the request field carried in the request message and the field type of the response field carried in the response message in the first program. By using the embodiment of the present application, the interface calling file is generated by obtaining and utilizing the request and response message structure, thereby ensuring the specification of the interface calling, improving the development efficiency, reducing the communication and maintenance cost, improving the code quality, promoting the team cooperation, and enhancing the compatibility and flexibility of the system.

[0072] As an optional solution, generating the interface description document according to the interface constraint condition includes:

[0073] The interface calling file and the condition description information in the interface constraint condition are parsed to generate the interface description document, wherein the condition description information is used to describe the request message structure and the response message structure according to the first format.

[0074] It should be noted that the above interface description document can but not limited to include a detailed document generated according to the interface constraint condition defined by the backend through protobuf, which describes the request and response message structure of the interface. It usually contains the name of the interface, the request method, the request path, the request parameter, the response parameter, and the type, description, and constraint of each parameter, and other detailed information, which is not limited in the embodiment. The interface description document is crucial for the front-end developer to understand and use the back-end interface, which helps to improve the efficiency and accuracy of the front-end and back-end cooperation.

[0075] Optionally, the condition description information can be, but is not limited to, used to represent the annotations and comments contained in the protobuf protocol definition, which describe the request message structure and response message structure of the interface. The condition description information provides the necessary metadata for generating the interface description document, so that the document can accurately reflect the expected behavior and data format of the interface.

[0076] Further, the first format described above can be, but is not limited to, natural language, which refers to the description method adopted when generating the interface description document. Using natural language can make the document easier to understand, because it is close to the way people communicate in their daily lives. In the technical disclosure, it means that the interface description document will use natural language to explain in detail the functions of the interface, the data structure of the request and response, and how to use these interfaces.

[0077] It should be noted that the above analysis can include, but is not limited to, the analysis and processing of interface call files (such as interface definitions and TS type definitions) and condition description information by automated tools to generate interface description documents. The parsing process involves extracting and converting data in these files and information to clearly express various aspects of the interface in natural language.

[0078] Optionally, as an optional example, the front end can be, but is not limited to, calling the schema data generation service by referring to Figure 5 , specifically, the front end can call the schema data generation service by referring to the TypeScript code example shown in Figure 5 , which includes importing the UserData and GetAllBusinessInfo interface definitions, which are automatically generated according to the protobuf file of the backend; the asynchronous function part, i.e. the userRequest part, is used to demonstrate how to call these interfaces; the part of calling the UserData interface; the part of calling the GetAllBusinessInfo interface; the part of printing the data returned by the interface; the part of exporting the userRequest function. It should be noted that Figure 5 is only an optional example provided to facilitate the explanation of the specific implementation of the above data generation method, and does not have any limitation on the specific implementation of the above data generation method.

[0079] Further, it should be noted that during the generation of the interface description document, the process of generation can be, but is not limited to, displayed in the execution interface of the automated tool, for example, as shown in Figure 6 , in the integrated development environment (Integrated Development Environment, IDE for short) corresponding to the automated tool, the progress information of data generation is displayed. It should be noted that,Figure 6 It should be noted that the above-mentioned optional example provided for the purpose of facilitating the explanation of the specific implementation of the data generation method does not have any limitation.

[0080] In the embodiment of the present application, the condition description information in the interface calling file and the interface constraint condition is parsed to generate an interface description document, wherein the condition description information is used to describe the request message structure and the response message structure in a first format. By using the embodiment of the present application, the interface description document is updated synchronously with the interface definition file, which ensures the consistency of the interface implementation and the document description, and reduces the integration and testing problems caused by interface changes.

[0081] As an optional solution, after generating the interface description document according to the interface constraint condition, the method further includes:

[0082] The interface description document is sent to a target document library for storing the description document of the application program, so as to add the interface description document to the description document.

[0083] Optionally, the above-mentioned sending the interface description document to the target document library for storing the description document of the application program can be but is not limited to representing the process of transmitting the generated interface description document to the target document library. This process ensures the centralized storage and management of the interface document, and facilitates the access and reference of team members.

[0084] Further, the above-mentioned target document library can be but is not limited to a knowledge base associated with the application program. The target document library is used to store and manage the description document of the application program, and provides version control, permission management and retrieval functions of the document, so as to ensure the security and availability of the document.

[0085] It should be noted that the above-mentioned adding to the description document can be but is not limited to including the process of integrating the interface description document into the existing document set in the target document library. In this process, the classification, indexing and association of the document are also involved, so that the user can conveniently find and use these documents.

[0086] It should be noted that in some embodiments, the front end can also instruct the local generation path of the interface description document. For example, as shown in Figure 7 the output path of the document can be configured in the automation tool, and then after the automation tool generates the interface description document, the document can be saved in the above- configured output path. In addition, the stage task flow (parsing→generating→document→pushing) and statistical information of the document generation are also displayed in the console of the automation tool. It should be noted that, Figure 7 It should be noted that the above-mentioned optional example provided for the purpose of facilitating the explanation of the specific implementation of the data generation method does not have any limitation.

[0087] In the embodiments of the present application, the interface description document is sent to a target document library for storing the description document of the application program, so as to add the interface description document to the description document. By using the embodiments of the present application, the efficiency of document management is significantly improved through automatic document sending and merging, errors introduced by manual operation are avoided, the accuracy and real-time performance of the document are improved, communication and cooperation between teams are promoted, maintenance costs are reduced, agile development processes are supported, and finally the development efficiency and quality of the project are improved.

[0088] As an optional solution, after generating the debugging data conforming to the interface constraint condition for the second program end by using the interface constraint condition, the method further includes:

[0089] Based on the simulation response data and the interface description document, a test case corresponding to the second program end is generated.

[0090] The second program end is tested based on the test case.

[0091] It should be noted that the above generation of test cases can but is not limited to representing the process of creating test cases for verifying the behavior of the front-end application based on simulation response data and interface description documents. These test cases aim to ensure that the front-end application can correctly handle various expected back-end responses.

[0092] Further, the above test cases can but are not limited to a series of explicit test steps and expected results for verifying whether the functions of the front-end application meet the design requirements. Test cases usually include tests on various normal and abnormal scenarios to ensure the robustness of the application.

[0093] Optionally, the above testing of the second program end can but is not limited to representing the process of using the generated test cases to verify whether the behavior of the front-end application meets the expectations. This includes executing the test cases, observing the results, and comparing them with the expected results to identify and fix potential problems.

[0094] It should be noted that when the front-end calls the back-end interface, the mock data can be enabled or disabled by modifying the parameters in the mock data function, for example, as shown in Figure 8 , the mock data example is included in Figure 8 , the mock data can be enabled by calling the UserData interface and passing true as a parameter.

[0095] It should be further noted that in some embodiments, a calling function of the network model can be added in the automation tool, and the network model is used to generate mock data that is closer to the actual scenario of the application program.

[0096] In the embodiments of the present application, based on the simulation response data and the interface description document, the test case corresponding to the second program end is generated; and the second program end is tested based on the test case. By using the embodiments of the present application, on the one hand, the front end can perform independent functional testing by using the automatically generated test case before the back end service is developed, without waiting for the back end API to be ready, which significantly accelerates the speed and efficiency of front end development and testing. On the other hand, the generation of the test case is based on the interface constraint condition, which ensures that the front end code is consistent with the definition of the back end API, and avoids compatibility problems caused by the asynchronization of the front end and the back end when the interface changes.

[0097] As an optional solution, after the interface constraint condition is used to generate the debugging data conforming to the interface constraint condition for the second program end, the following steps are further included:

[0098] In the case that the service interface of the first program end is updated to obtain an updated service interface, the updated interface constraint condition matched with the updated service interface is obtained.

[0099] The updated interface constraint condition is used to generate the debugging data conforming to the updated interface constraint condition for the second program end.

[0100] It should be noted that the above-mentioned updated service interface can be but is not limited to indicating the modification or enhancement of the first program end (back end) to the existing service interface. These updates can include adding new functions, modifying parameters, changing response structures, etc., to meet the changing business needs or technical requirements.

[0101] Further, the above-mentioned updated interface constraint condition can be but is not limited to being redefined according to the updated service interface, which is a rule and a limit for guiding how to interact with the updated back end service, to reflect the latest state of the back end service.

[0102] Optionally, the above-mentioned debugging data can be but is not limited to indicating the simulation response data (mock data) generated for the second program end (front end) according to the updated interface constraint condition. These data enable the front end developer to continue development and testing after the back end service is updated, without waiting for the back end service to be fully ready.

[0103] It should be noted that the above-mentioned generation of debugging data can be but is not limited to indicating the process of automatically generating debugging data conforming to the new interface specification by using the updated interface constraint condition. This process ensures that the front end application can adapt to the update of the back end service, and maintains the consistency and compatibility of the front end and the back end.

[0104] In the embodiment of the present application, in the case that the first program end updates the service interface to obtain an updated service interface, the updated interface constraint condition matched with the updated service interface is acquired, and the debugging data conforming to the updated interface constraint condition is generated for the second program end by using the updated interface constraint condition. By adopting the embodiment of the present application, after the interface is changed, the debugging data and the interface description document are automatically updated, the manual adjustment and the number of joint debugging required by the front end are reduced, and the development resources consumed due to the interface change are reduced.

[0105] Optionally, as an optional example, the above-mentioned data generation method can be exemplarily and wholly explained as follows: Figure 9

[0106] In step S902, the back end writes a protobuf protocol, specifically, the back end developer defines the interface protocol by using Protocol Buffers (protobuf). This is the writing stage of the interface constraint condition, which is used to specify the data structure and the communication mode of the interface.

[0107] In step S904, the back end develops the interface, specifically, the back end develops the actual interface service according to the written protobuf protocol.

[0108] In step S906, the back end publishes the test interface, specifically, the back end publishes the developed interface as a test interface for the front end to perform joint debugging and testing.

[0109] In step S908, the front end calls the protobuf tool, specifically, the front end developer uses the protobuf tool to generate the interface definition and the type definition.

[0110] In step S910, the front end determines whether to generate mock data, specifically, it is judged whether the simulation data (mock data) needs to be generated. If yes, it proceeds to step S912 of generating the mock data; if no, it is skipped.

[0111] In step S912, the front end generates the mock data, specifically, the front end generates the simulation data according to the protobuf definition, which is used for independent development and testing of the front end when the back end service is not ready.

[0112] In step S914, the front end generates the type definition, specifically, the protobuf tool is used to automatically generate the TypeScript type definition required by the front end from the protobuf protocol.

[0113] In step S916, the front end generates the interface definition, specifically, the interface definition is generated according to the protobuf protocol, including the request method, the path, the parameter and the like.

[0114] ​Step S918, the front end generates an interface document. Specifically, a document of the interface is automatically generated using the type definition and the interface definition, including a service, a method, an input / output parameter structure table, and an example.

[0115] Step S920, interface debugging. Specifically, the front end and the back end perform interface debugging to ensure the correctness and stability of the interface.

[0116] Step S922, determining whether the interface needs to be modified. Specifically, it is determined whether the interface needs to be modified during debugging. If yes, the step S902 of modifying the protobuf protocol is returned; if no, the step S924 is executed.

[0117] Step S924, publishing a formal interface. Specifically, after confirming that the interface is correct, the back end publishes a formal interface for the front end to use.

[0118] Optionally, as another optional example, the above data generation method can be applied to the structure as shown in Figure 10 .

[0119] As shown in Figure 10 , the architecture mainly includes: a configuration management module 1002 responsible for reading and managing unified configuration information of a project. These configurations can include output paths, document pushing strategies, task grouping, package name matching rules, document output formats, and base URLs, etc. This module supports processing multiple protocols and multiple branches of input, and can use wildcards to match package names to facilitate flexible management and operation of different source configurations.

[0120] A protocol acquisition and preparation module 1004 supports pulling.proto files from a local file system or a remote code repository (such as Git), which contain interface protocol definitions. This module can handle concurrent execution of multiple tasks and create temporary file isolation environments for each task to ensure the stability and reliability of the protocol parsing process.

[0121] A protocol parsing module 1006 is responsible for parsing various data structures defined in.proto files, such as services (service), methods (method), messages (message), enumerations (enum), and maps (map). In addition, this module also handles special types of maps and ignore strategies, such as the handling of types defined in protobuf packages.

[0122] Type and service generation module 1008: generates strict TypeScript type definitions and service-split API methods based on the parsed protocol. This module automatically exports the required type definitions for requests and responses, and supports Tree-Shaking optimization to reduce the final package size while maintaining compatibility with older aggregation export methods. The Tree-Shaking optimization is used to indicate the on-demand import of API methods and Mock structures, avoiding unnecessary code packaging and reducing the product size.

[0123] Mock generation module 1010: automatically generates mock data templates based on response structures and provides local mock service methods. To avoid misuse of mock data in production environments, this module adds a "deprecated" label to mock methods. In addition, it supports generating or disabling mock data as needed.

[0124] Annotation / comment metadata injection module 1012: extracts annotations and comments from.proto files based on configuration, such as description, summary, tags, header information, router, method, deprecated, alias, and complete comments, and injects them into the runtime environment or documentation to enhance type hints, document generation, and runtime behavior.

[0125] Plugin and hook module 1014: provides extension points at key stages such as preparation, generation, writing, documentation, and pushing, allowing third parties or internal teams to customize and extend to meet specific business needs. The plugin and hook are used to indicate that extension points are opened at the "preparation, generation, writing, documentation, pushing" stages, supporting customization and ecological capability evolution.

[0126] In addition, the structure can also include:

[0127] Document generation module: generates Markdown-formatted interface documentation based on the parsed data structure and extracted metadata. The document content includes data structure tables, example code, anchor links, and a back-to-top index, supporting the concatenation of multiple task documents. The anchor link is added to the generated document or API code to support quick positioning between the document and the code.

[0128] Document pushing module: pushes the generated document to the knowledge base according to the configuration, handles permission issues, failure retry logic, and error information prompts, ensuring that the document can be correctly stored and accessed.

[0129] Runtime encapsulation module: provides a unified request entry, supports Mock data switching, optional AI-generated Mock data path, and error handling extension points, to facilitate use and extension in the runtime environment.

[0130] Parallel acceleration and stabilization module: through stage-based fine-grained control of concurrency, combined with error grading, context state output and cleaning mechanisms, to ensure execution efficiency and stability when processing large projects. Among them, parallel acceleration is used to indicate parallel control of protocol parsing, code generation, document building and other processes to improve large project generation performance.

[0131] Optionally, as another optional example, the above data generation method is applied to Figure 11 As an example of the indicated structure, the overall flow of the execution of the above data generation method can be, but not limited to, explained and described as follows:

[0132] Step S1 is executed, user 1102 executes a unified entry command, specifically, the user or the continuous integration system triggers the start of the entire process, and executes a unified entry command.

[0133] Then step S2 is executed, the configuration management module 1104 performs initialization operation, specifically, the configuration management module takes the unified configuration file, including output path, pushing strategy, task group, package matching rule, document output format and baseUrl, etc., and then verifies the compliance of the task.

[0134] Then step S3 is executed, the configuration management module 1104 creates output directory and context environment.

[0135] Then, step S4 is executed, the protocol preparation and acquisition module 1106 pulls the protocol file, specifically, it pulls the.proto file from the local file system or remote code repository (such as Git) in parallel, and caches it, and then generates a set of temporary and resolvable protocol files, to prepare for subsequent parsing work.

[0136] Then, step S5 is executed, the protocol preparation and acquisition module 1106 caches the protocol file to the temporary directory.

[0137] Then, step S6 is executed, the protocol parsing and generation engine 1108 parses the protocol file, specifically, it parses the service definition (service), method definition (method), message definition (message), enumeration definition (enum) and mapping (map) structures, establishes type index and dependency relationship, and handles special type mapping and circular reference.

[0138] Step S7 is performed, and the protocol parsing and generation engine 1108 generates code, specifically, strict TypeScript type definitions and service-split API methods for each service.

[0139] Step S8 is performed, and the protocol parsing and generation engine 1108 generates mock methods and deprecation hints, specifically, if the Mock function is enabled, the corresponding Mock service is generated, and a deprecation hint is added for Mock export.

[0140] Next, step S9 is performed, and the protocol parsing and generation engine 1108 builds an aggregated entry and a service entry, specifically, the aggregated entry is built to be compatible with the old way, and service-level imports are supported, which helps Tree-Shaking optimization.

[0141] Next, step S10 is performed, and the protocol parsing and generation engine 1108 generates documentation, specifically, Markdown-formatted interface documentation is generated according to the parsing results and metadata.

[0142] Next, step S11 is performed, and the protocol parsing and generation engine 1108 injects metadata, specifically, service and method lists, input / output parameter structure tables, example code, and anchor links are included, and if a baseUrl is configured, the title in the document is converted into a clickable link to realize cross-document jumping of service anchors and method anchors.

[0143] Next, step S12 is performed, and the document pushing module 1110 aggregates multi-task documents by page ID, specifically, the generated documents are grouped and combined by page ID.

[0144] Next, step S13 is performed, and the document pushing module 1110 code product is landed, specifically, the code is landed to the specified output directory.

[0145] Next, step S14 is performed, and the file system 1112 removes aggregated products, specifically, expired products such as old versions of aggregated files are removed.

[0146] Next, step S15 is performed, and the document pushing module 1110 pushes the document, specifically, the code document is pushed to the knowledge base.

[0147] Next, step S16 is performed, and the document pushing module 1110 provides a push success or failure prompt.

[0148] Next, step S17 is performed, and the file system 1112 performs document landing locally.

[0149] Then, the configuration management module 1104 outputs a summary report by outputting success statistics and error information, and instructs the user to handle possible encountered permission or network problems.

[0150] It should be noted that in the present embodiment, wildcard support is provided for package name: wildcard (such as yka.* or trpc.*) is supported to match multiple service lines, and unified generation is implemented. Annotation extraction rules can be configured: Boolean is supported to be turned on, and fine-grained key filtering or conversion function is supported, and the annotation can be selected to be completely retained or simplified after de-annotation. Anchor naming convention: service anchors are prefixed with service_, and method anchors are prefixed with method_+service full name+method name, to ensure stable jumping across documents. Mock strategy: by default, Mock structure is not injected into runtime to avoid production volume expansion; Mock methods are output in a separate directory, and are explicitly selected when called.

[0151] It should be noted that for each of the foregoing method embodiments, in order to simply describe, each is described as a combination of a series of actions, but those skilled in the art should know that the present application is not limited to the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0152] According to another aspect of the embodiments of the present application, a data generation apparatus for implementing the data generation method described above is also provided. As shown in the Figure 12 apparatus includes:

[0153] The acquisition unit 1202 is configured to acquire an interface constraint condition of a service interface of a first program end, wherein the interface constraint condition is used to constrain the message format of a request message and a response message of the service interface, and the first program end is used to implement the business logic of an application program.

[0154] The generation unit 1204 is configured to generate, by using the interface constraint condition, debugging data conforming to the interface constraint condition for a second program end, wherein the second program end is used to implement the program interface logic of the application program, and the debugging data is used to perform simulated joint debugging on the second program end and the first program end in a case where the service interface is not completed.

[0155] Optionally, in the present embodiment, the generation unit includes a generation module configured to generate simulated response data according to the interface constraint condition, and generate an interface description document according to the interface constraint condition, wherein the simulated response data is used to simulate the response data returned by the service interface to the second program end after the service interface acquires the calling request sent by the second program end, and the interface description document is used to describe the service interface.

[0156] Optionally, in the embodiment, the generating module is further configured to: obtain a response message structure of a response message of the service interface indicated in the interface constraint condition, wherein the response message structure comprises an identification of a response field in the response message, a type of the response field, a field description of the response field, and a field constraint of the response field; and generate the simulation response data based on the response message structure.

[0157] Optionally, in the embodiment, the generating module is further configured to: obtain a request message structure and a response message structure indicated in the interface constraint condition, wherein the request message structure comprises an identification of a request field in the request message, a type of the request field, a field description of the request field, and a field constraint of the request field, and the response message structure comprises an identification of a response field in the response message, a type of the response field, a field description of the response field, and a field constraint of the response field; and generate an interface calling file of the service interface based on the request message structure and the response message structure, wherein the interface calling file comprises a first sub-file for triggering the request message and sending the request message to the service interface, and a second sub-file for constraining the type of the request field carried in the request message and the type of the response field carried in the response message in the first program.

[0158] Optionally, in the embodiment, the generating module is further configured to: parse the interface calling file and condition description information in the interface constraint condition to generate an interface description document, wherein the condition description information is used to describe the request message structure and the response message structure in the first format.

[0159] Optionally, in the embodiment, the apparatus further comprises a sending unit configured to send the interface description document to a target document library for storing a description document of the application program, so as to add the interface description document to the description document.

[0160] Optionally, in the embodiment, the apparatus further comprises a first generating unit configured to generate a test case corresponding to the second program based on the simulation response data and the interface description document; and a testing unit configured to test the second program based on the test case.

[0161] Optionally, in the embodiment, the apparatus further comprises a second obtaining unit configured to, in a case that the service interface of the first program is updated to obtain an updated service interface, obtain an updated interface constraint condition matched with the updated service interface; and a first generating unit configured to generate debugging data conforming to the updated interface constraint condition for the second program based on the updated interface constraint condition.

[0162] The specific embodiments can refer to the examples shown in the above data generation method, and the embodiments will not be described here.

[0163] According to still another aspect of the embodiments of the present application, an electronic device for implementing the above data generation method is also provided, which can be a terminal device or a server. The present embodiment takes the electronic device as a server as an example for illustration. As shown in Figure 13 The electronic device includes a memory 1302 in which a computer program is stored and a processor 1304 configured to execute the steps in any of the above method embodiments through the computer program.

[0164] Optionally, in the present embodiment, the above electronic device can be located in at least one of a plurality of network devices in a computer network.

[0165] Optionally, in the present embodiment, the above processor can be configured to execute the following steps through the computer program:

[0166] S1, obtaining an interface constraint condition of a service interface of a first program end, wherein the interface constraint condition is used to constrain the message format of a request message and a response message of the service interface, and the first program end is used to implement the business logic of an application program;

[0167] S2, generating debugging data conforming to the interface constraint condition for a second program end by using the interface constraint condition, wherein the second program end is used to implement the program interface logic of the application program, and the debugging data is used to perform simulated joint debugging on the second program end and the first program end in the case where the service interface is not completed.

[0168] Optionally, those skilled in the art can understand that Figure 13 The structure shown in FIG. 13 is only schematic, and the electronic device can also be a terminal device such as a smart phone (e.g., an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, a Mobile Internet Device (MID), a PAD, etc. Figure 13 It does not limit the structure of the above electronic device. For example, the electronic device can further include more or less components (e.g., a network interface, etc.) than those shown in FIG. 13, or have a different configuration from that shown in FIG. 13. Figure 13 Figure 13

[0169] ​​The memory 1302 can be used to store software programs and modules, such as program instructions / modules corresponding to the data generation method and device in the embodiments of the present application. The processor 1304 executes various functions and data processing by running the software programs and modules stored in the memory 1302, that is, implements the data generation method described above. The memory 1302 can include a high-speed random access memory, and can also include a non-volatile memory such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 1302 can further include a memory remotely arranged with respect to the processor 1304, which can be connected to the terminal through a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof. As an example, as shown in Figure 13 The memory 1302 can include but is not limited to the acquisition unit 1202 and the generation unit 1204 in the data generation device described above. In addition, other module units in the data generation device described above can also be included, but not limited to, which will not be described in detail in this example.

[0170] Optionally, the transmission device 1306 described above is used to receive or send data via a network. Specific examples of the above-mentioned network can include wired networks and wireless networks. In one example, the transmission device 1306 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers through a network cable to communicate with the Internet or a local area network. In one example, the transmission device 1306 is a radio frequency (Radio Frequency, RF) module, which is used to communicate with the Internet in a wireless manner.

[0171] In addition, the electronic device described above further includes a display 1308 and a connection bus 1310 for connecting various module components in the electronic device.

[0172] In other embodiments, the terminal device or server described above can be a node in a distributed system, where the distributed system can be a blockchain system, which can be a distributed system formed by the multiple nodes communicating through a network. Wherein, the nodes can form a point-to-point network, and any form of computing device, such as a server, a terminal, and other electronic devices, can become a node in the blockchain system by joining the point-to-point network.

[0173] It should be noted that the data collection and processing in the present application should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of authorization of laws and regulations and the personal information subject.

[0174] According to an aspect of the present application, there is provided a computer program product comprising computer programs / instructions containing program codes for executing the above method. In such an embodiment, the computer program can be downloaded and installed from a network by a communication part, and / or installed from a detachable medium. When the computer program is executed by a central processing unit, various functions provided by the embodiments of the present application are executed.

[0175] According to an aspect of the present application, there is also provided another computer program product comprising a non-volatile computer readable storage medium storing a computer program which, when executed by a processor, implements the steps of the method in the various embodiments of the present application.

[0176] According to an aspect of the present application, there is provided a computer readable storage medium, from which a processor of a computer device reads computer instructions, and the processor executes the computer instructions so that the computer device executes the above method.

[0177] Optionally, in the present embodiment, the above computer readable storage medium can be configured to store a computer program for executing the following steps:

[0178] S1, obtaining an interface constraint condition of a service interface of a first program end, wherein the interface constraint condition is used to constrain the message format of a request message and a response message of the service interface, and the first program end is used to implement the business logic of an application program;

[0179] S2, generating debugging data conforming to the interface constraint condition for a second program end by using the interface constraint condition, wherein the second program end is used to implement the program interface logic of the application program, and the debugging data is used to perform simulated joint debugging on the second program end and the first program end in the case that the service interface is not completed.

[0180] Optionally, in the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that contains the function of the module or unit.

[0181] Optionally, in the embodiment, all or part of the steps in the various methods of the above embodiments can be understood by those of ordinary skill in the art that the program can instruct the terminal device related hardware to complete, and the program can be stored in a computer readable storage medium, and the storage medium can include a flash disk, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk or an optical disk, etc.

[0182] The integrated units in the above embodiments, if realized in the form of software function units and sold or used as independent products, can be stored in the above computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts that make contributions to the prior art or the whole or part of the technical solutions can be embodied in the form of software products. The computer software product is stored in a storage medium and includes a plurality of instructions for causing one or more computer devices (which can be personal computers, servers or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0183] In the above embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0184] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented by other means. Among them, the above-described device embodiments are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed mutual units can be indirect coupling or communication connection through some interfaces, units or modules, which can be electrical or other forms.

[0185] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or they can be distributed on multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0186] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware or software function unit.

[0187] The above merely preferred embodiments of the present application, it should be noted that for those of ordinary skill in the art, without departing from the principles of the present application, can also make a number of improvements and refinements, these improvements and refinements should also be considered as the scope of protection of the present application.

Claims

1. A method of generating data, characterized by, The method comprises: obtaining an interface constraint condition of a service interface of a first program end, wherein the interface constraint condition is used to constrain message formats of a request message and a response message of the service interface, and the first program end is used to implement business logic of an application program; generating, by using the interface constraint condition, debugging data conforming to the interface constraint condition for a second program end, wherein the second program end is used to implement program interface logic of the application program, and the debugging data is used to perform simulated joint debugging on the second program end and the first program end in a case where the service interface is not completed.

2. The method of claim 1, wherein, The generating, by using the interface constraint condition, of the debugging data conforming to the interface constraint condition for the second program end comprises: generating simulated response data according to the interface constraint condition, and generating an interface description document according to the interface constraint condition, wherein the simulated response data is used to simulate response data returned by the service interface to the second program end after the service interface obtains a calling request sent by the second program end, and the interface description document is used to describe the service interface.

3. The method of claim 2, wherein, The generating of the simulated response data according to the interface constraint condition comprises: obtaining a response message structure of a response message of the service interface indicated in the interface constraint condition, wherein the response message structure comprises an identifier of a response field in the response message, a type of the response field, a field description of the response field, and a field constraint of the response field; generating the simulated response data based on the response message structure.

4. The method of claim 2, wherein, Before the generating of the interface description information according to the interface constraint condition, the method further comprises: obtaining a request message structure and a response message structure indicated in the interface constraint condition, wherein the request message structure comprises an identifier of a request field in the request message, a type of the request field, a field description of the request field, and a field constraint of the request field, and the response message structure comprises an identifier of a response field in the response message, a type of the response field, a field description of the response field, and a field constraint of the response field; generating an interface calling file of the service interface based on the request message structure and the response message structure, wherein the interface calling file comprises a first sub-file used to trigger the request message and send the request message to the service interface, and a second sub-file used to constrain field types of the request field carried in the request message and field types of the response field carried in the response message in the first program end.

5. The method of claim 4, wherein, The generating of the interface description document according to the interface constraint condition comprises: parsing condition description information in the interface calling file and the interface constraint condition to generate the interface description document, wherein the condition description information is used to describe the request message structure and the response message structure in a first format.

6. The method of claim 2, wherein, After the generating of the interface description document according to the interface constraint condition, the method further comprises: sending the interface description document to a target document library used to store description documents of the application program, so as to add the interface description document to the description documents.

7. The method of claim 2, wherein, After the generating of the debugging data conforming to the interface constraint condition for the second program end by using the interface constraint condition, the method further comprises: generating a test case corresponding to the second program end based on the simulation response data and the interface description document; testing the second program end based on the test case.

8. The method according to any one of claims 1 to 7, characterized in that, After the generating of the debugging data conforming to the interface constraint condition for the second program end by using the interface constraint condition, the method further comprises: in the case that the first program end updates the service interface to obtain an updated service interface, obtaining an updated interface constraint condition matched with the updated service interface; generating debugging data conforming to the updated interface constraint condition for the second program end by using the updated interface constraint condition.

9. A data generating apparatus characterized by comprising: comprise: an obtaining unit, configured to obtain an interface constraint condition of a service interface of a first program end, wherein the interface constraint condition is used to constrain message formats of request messages and response messages of the service interface, and the first program end is used to implement business logic of an application program; a generating unit, configured to generate debugging data conforming to the interface constraint condition for a second program end by using the interface constraint condition, wherein the second program end is used to implement program interface logic of the application program, and the debugging data is used to perform simulation joint debugging on the second program end and the first program end in the case that the service interface is not completed.

10. A computer readable storage medium, characterized in that, The computer readable storage medium comprises a stored program, wherein the program is executed by a processor to perform the method in any one of claims 1 to 8.

11. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instruction is executed by the processor to implement the steps of the method in any one of claims 1 to 8.

12. An electronic device comprising a memory and a processor, characterized in that The memory stores a computer program, and the processor is configured to execute the method in any one of claims 1 to 8 by using the computer program.

Images