Test management method and device, equipment and storage medium

Abstract

The invention provides a test management method and device, equipment and a storage medium. Relates to the technical field of big data. The method comprises the following steps: receiving a design state document, wherein the design state document comprises a service interface definition of a design state; deploying the software component to a test platform for testing; obtaining a message of the software component in the test process, and obtaining a service interface definition of the software component in a running state in the test environment according to the message; performing consistency comparison on the service interface definition in the running state and the service interface definition in the design state; and if the consistency comparison result indicates that the design state service interface definition and the operation state service interface definition are different, modifying the design state service interface definition or the operation state service interface definition according to a preset rule, so that the design state service interface definition and the operation state service interface definition are the same. According to the method, the difference between the service interface definition and the design state of the software component in the test environment is detected, modification is carried out when the difference occurs, and the consistency of the service interface definition is ensured.

Description

Technical Field

[0001] The present application relates to the field of big data technology, and in particular to a test management method, device, equipment and storage medium. Background Art

[0002] As the scale of IT systems in financial enterprises continues to expand and the information innovation project continues to be implemented, the core systems of large financial industries are gradually moving from host systems to distributed open Java platforms. As the scale of IT applications expands, the number of interfaces is also growing rapidly.

[0003] Software development is usually divided into multiple stages, including requirements analysis, design, coding, testing, deployment, etc. Design state refers to the state of the software system defined according to requirements analysis and functional design in the early stages of software development; running state refers to the actual running state of the software system. There may be inconsistencies in the number and form of interfaces defined in the design state and interfaces in the actual state. Manual comparison is not suitable for a large number of interface situations.

[0004] Therefore, how to ensure the consistency of service interface definitions in the design state and the running state is an urgent problem to be solved. Summary of the invention

[0005] The present application provides a test management method, apparatus, device and storage medium to solve the problem of inconsistent service interface definitions in the design state and the running state during the software development process.

[0006] In a first aspect, the present application provides a test management method, the method comprising:

[0007] Receive a design document uploaded by a research and development integration client and a software component developed according to the design document, wherein the design document includes a design service interface definition, and the design service interface definition includes a definition of the function and calling method of each interface, request parameters, data format, and error handling method;

[0008] In response to a user's publishing operation, the software component is deployed to a test platform for testing;

[0009] Obtaining a message of the software component during the test process, and obtaining a service interface definition of the software component in a running state in a test environment according to the message;

[0010] Perform consistency comparison between the running service interface definition and the stored design service interface definition to obtain a consistency comparison result;

[0011] If the consistency comparison result indicates that there is a difference between the service interface definition in the running state and the service interface definition in the design state, the service interface definition in the design state or the service interface definition in the running state is modified according to the preset rules so that the service interface definition in the design state and the service interface definition in the running state are the same.

[0012] In a possible design, obtaining a message of the software component during the test process, and obtaining a service interface definition of the software component in a running state in the test environment according to the message, includes:

[0013] Obtaining a request message and a response message of each interface of the software component;

[0014] According to the request message of each interface, determine the request parameters, functions and calling methods of each interface;

[0015] Determine the data format of each interface based on the response message of each interface;

[0016] Generate a running service interface definition document based on the request parameters, functions, calling methods and data formats of each interface.

[0017] In a possible design, before determining the request parameters, functions and calling methods of each interface according to the request message of each interface, the method further includes:

[0018] De-duplicate all request messages of each interface;

[0019] De-duplicate all response messages from each interface;

[0020] All request messages after deduplication processing are used as request messages for each interface;

[0021] The response request message after deduplication processing is used as the response message of each interface.

[0022] In a possible design, the deduplication processing of all request messages of each interface includes:

[0023] Compare the URL path, HTTP method, parameter list and parameter list value of all request messages of each interface;

[0024] If the URL path, HTTP method, parameter list, and parameter list value of any two request messages are the same, they are determined to be duplicate request messages and deduplication is performed.

[0025] In a possible design, the deduplication processing of all response messages of each interface includes:

[0026] Compare the status codes, key fields in the response header, and key fields in the response body of all response messages from each interface;

[0027] If the status codes, key fields in the response header, and key fields in the response body of any two request messages are the same, they are determined to be duplicate response messages and deduplication is performed.

[0028] In a possible design, the difference includes a difference in the number of interfaces or a difference in the definition of a service interface.

[0029] In one possible design, the method further includes:

[0030] Publishing the tested software component to the product management platform, and obtaining the application-level service XML file in the tested software component through a scanning tool;

[0031] Read the service interface definition in the service xml file, and obtain the service interface definition of the stored design document;

[0032] Perform an error comparison between the service interface definition in the service xml file and the service interface definition in the stored design state document to obtain an error result;

[0033] If the error result indicates that the service interface definition in the service xml file is different from the service interface definition in the stored design document, a prompt message is issued, which is used to prompt the user to modify the service interface definition in the published software component or modify the service interface definition in the design document.

[0034] In one possible design, the method further includes:

[0035] Receive a demand document proposed by a demander terminal device, and push the demand document to a research and development integration client associated with the project, wherein the demand document includes functional requirements and non-functional requirements of the project;

[0036] According to the design state document uploaded by the R&D integration client, the structured design state document is converted into a service interface definition document in XML format through an XML writing tool;

[0037] The service interface definition document in XML format is sent to the R&D integration client.

[0038] In a second aspect, the present application further provides a test management device, the device comprising:

[0039] A receiving module, used to receive a design document uploaded by a research and development integration client and a software component developed according to the design document, wherein the design document includes a design service interface definition, and the design service interface definition includes a definition of the function and calling method of each interface, request parameters, data format, and error handling method;

[0040] A publishing module, used for responding to a user's publishing operation and deploying the software component to a test platform for testing;

[0041] An acquisition module, used to acquire the message of the software component during the test process, and acquire the service interface definition of the software component in the running state in the test environment according to the message;

[0042] A comparison module, used for performing consistency comparison between the service interface definition in the running state and the service interface definition in the stored design state to obtain a consistency comparison result;

[0043] A modification module is used to modify the service interface definition in the design state or the service interface definition in the running state according to preset rules if the consistency comparison result indicates that there is a difference between the service interface definition in the running state and the service interface definition in the design state, so that the service interface definition in the design state and the service interface definition in the running state are the same.

[0044] In a third aspect, the present application also provides a test management system, the test management system comprising: an online management platform, a research and development integrated client and a test platform;

[0045] The online management platform is respectively connected to the R&D integrated client and the testing platform for communication;

[0046] The test management system is used to execute the method as described in any one of the first aspects.

[0047] In a fourth aspect, the present application further provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0048] The memory stores computer-executable instructions;

[0049] The processor executes the computer-executable instructions stored in the memory to implement the method as described in any one of the first aspects.

[0050] In a fifth aspect, the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the method as described in any one of the first aspects.

[0051] In a sixth aspect, the present application further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the method as described in any one of the first aspects.

[0052] The test management method, device, equipment and storage medium provided by the present application include: receiving a design state document uploaded by a research and development integrated client and a software component developed according to the design state document, wherein the design state document includes a design state service interface definition, and the design state service interface definition includes the definition of the function and calling method of each interface, request parameters, data format and error handling method; in response to the user's publishing operation, deploying the software component to the test platform for testing; obtaining the message of the software component in the test process, and obtaining the service interface definition of the running state of the software component in the test environment according to the message; performing consistency comparison between the running state service interface definition and the stored design state service interface definition to obtain a consistency comparison result; if the consistency comparison result indicates that there is a difference between the running state service interface definition and the design state service interface definition, modifying the design state service interface definition or the running state service interface definition according to the preset rules, so that the design state service interface definition and the running state service interface definition are the same. The method detects the difference between the service interface definition and the design state of the software component in the test environment, and modifies it when there is a difference, so as to ensure the consistency of the service interface definition, and no longer needs to be compared manually. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0054] Figure 1 This is a schematic diagram of the architecture of the test management system embodiment 1 provided by the present application;

[0055] Figure 2 This is a schematic diagram of the architecture of the second embodiment of the test management system provided by this application;

[0056] Figure 3 A flowchart of the first embodiment of the test management method provided by this application;

[0057] Figure 4 A flowchart of the second embodiment of the test management method provided by this application;

[0058] Figure 5 A flowchart of the third embodiment of the test management method provided by this application;

[0059] Figure 6 A flowchart of an example of a test management method provided in this application;

[0060] Figure 7A schematic diagram of the structure of the test management device embodiment 1 provided by the present application;

[0061] Figure 8 A schematic diagram of the structure of the electronic device provided in this application.

[0062] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0063] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0064] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0065] At present, large banks have formulated XML-based interface publishing and message technical specifications. However, as the scale of IT systems in financial enterprises continues to expand, the core systems of large financial industries are shifting from host systems to distributed and open Java platforms. This is a strategy adopted by many financial institutions to improve flexibility and efficiency. However, this shift usually leads to increased complexity of technical architecture and a surge in the number of interfaces.

[0066] With the super-linear growth of the number of interfaces, interface management becomes critical. At different stages of the project, demand analysis, design, coding, testing, deployment, etc. all require unified management of interfaces. The workload of maintaining and managing interfaces only by personnel is becoming increasingly heavy and prone to errors. The number of interfaces defined in the design state may not match the number of interfaces in the actual runtime, or the definitions of the interfaces may be different.

[0067] In view of this, the present application proposes the following technical concept: to design a test management system, which includes an online management platform, an R&D integrated client, a test platform, a product management platform and a production verification platform, and to combine the service interface definition from conceptual design, development design, test verification, and production delivery verification to realize automatic verification of the service interface definition at each stage, thereby ensuring the consistency of the service interface definition at each stage.

[0068] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0069] Figure 1 This is a schematic diagram of the architecture of the test management system embodiment 1 provided in this application. Figure 1 As shown, the test management system includes: online management platform, R&D integrated client and test platform.

[0070] The test platform can be integrated into the online management platform or separated from the online management platform.

[0071] If the test platform is separated from the online management platform, the online management platform establishes a communication connection with the test platform.

[0072] The online management platform establishes a communication connection with the R&D integrated client.

[0073] Users develop software components through the R&D integrated client and test the developed software on the test platform.

[0074] The online management platform is used to ensure that the service interface definition designed by the R&D integration client is the same as the service interface definition in the running state, and also compares the service interface definition in the user development state with the service interface definition in the design state to ensure the synchronization of service definitions. When testing software components in the test platform, the definition of the service interface is determined by obtaining the interface message, and then the subsequent service definition comparison is performed.

[0075] The online management platform is also used to communicate development requirements.

[0076] Through the online management platform, the consistency of service interface definition during development, design, and test operation can be ensured.

[0077] The above-mentioned online management platform and testing platform may be located in the same physical device.

[0078] Figure 2 This is a schematic diagram of the architecture of the test management system embodiment 2 provided in this application, such as Figure 2 As shown, the test management system also includes a product management platform and a production inspection platform.

[0079] After the development process is completed, the production phase begins. Developers package the products and publish them to the product management platform according to the process. The production verification platform uses the production product scanning tool to read the products, decompress the products according to the product specifications, read the application-level service xml file in the product, and read the service interface definition in the file. The service interface definition read is compared with the one stored in the online management platform to ensure the consistency of the service interface definition.

[0080] The test management system can also manage the consistency of service interface definitions during the production process.

[0081] The following is an introduction to service interface management.

[0082] Figure 3 A flow chart of the test management method embodiment 1 provided in this application, such as Figure 3 As shown, the following steps are included:

[0083] S101. Receive the design state document uploaded by the R&D integration client and the software components developed according to the design state document. The design state document includes the design state service interface definition. The design state service interface definition includes the definition of the function and calling method of each interface, request parameters, data format and error handling method.

[0084] In one implementation, developers can write design documents in the R&D integration client according to actual conditions, and send the written design documents to the online management platform.

[0085] In another implementation, the online management platform provides developers with a requirement document, which includes functional requirements and non-functional requirements of the project. The developer generates a design document based on the requirement document and sends it to the online management platform.

[0086] Among them, the design document contains the definition of the service interface, including detailed information such as the function description, calling method, request parameters, data format, and error handling method of each interface.

[0087] Developers can also modify design documents online and synchronize them to the online management platform.

[0088] The user develops the software component according to the design document and uploads the software component.

[0089] S102: In response to the user's publishing operation, the software components are deployed to the test platform for testing.

[0090] In this step, the user develops the software components according to the design documents and uploads the relevant files and configurations of the software components to the test environment to ensure that the software can run normally and execute the relevant service interfaces in the test environment.

[0091] S103: Acquire messages of the software component during the test process, and acquire service interface definitions of the software component in the running state in the test environment according to the messages.

[0092] The test platform monitors and captures the messages and data flows during the test, analyzes the captured data, and records the actual interface implementation, including the format of the request and response data, the error handling mechanism during the processing, and other detailed information. Based on the information obtained from the analysis, the actual runtime service interface definition of the software component in the test environment is obtained. The runtime service interface definition includes the specific implementation of each interface during actual runtime, the format of the request and response data, and the error handling mechanism during the processing.

[0093] The testing process can perform functional and non-functional testing on the interface.

[0094] S104: Perform a consistency comparison between the running service interface definition and the stored design service interface definition to obtain a consistency comparison result.

[0095] After the online management platform receives the operational service interface definition from the test module, it performs a consistency comparison with the previously stored design service interface definition. The comparison process checks whether the functions, request parameters, data format, error handling, etc. of each interface match the design definition.

[0096] S105. If the consistency comparison result indicates that there is a difference between the service interface definition in the running state and the service interface definition in the design state, modify the service interface definition in the design state or the service interface definition in the running state according to the preset rules so that the service interface definition in the design state and the service interface definition in the running state are the same.

[0097] If the consistency comparison results show that there are differences between the design state and the running state, the corresponding treatment measures are executed according to the preset rules. There are two main types of differences: one is the mismatch of the number of interfaces, that is, a non-existent service interface definition appears in the test environment and there is no corresponding design state entry to match it. The other is that the service interface definition already exists in the online management platform, but there is a difference between its running state interface definition and the design state definition.

[0098] Modify the service interface definition in the design state or the service interface definition in the running state according to the preset rules to make the service interface definition in the design state and the service interface definition in the running state the same. There are many ways to do this:

[0099] In one implementation, a prompt message is sent to prompt the developer or person in charge to confirm the interface definition difference and choose to revise the design state or running state interface according to the actual situation, so as to finally keep the two consistent.

[0100] In another implementation, an automation tool or script is used to automatically update the interface definition in the design state according to the service interface definition in the running state.

[0101] This embodiment provides a test management method, an online management platform receives a design state document uploaded by a user from a research and development integrated client, and stores the design state document, the design state document includes a design state service interface definition, and the design state service interface definition includes the definition of the function and calling method of each interface, request parameters, data format and error handling method. In response to the user's publishing operation, the software component developed according to the design state document is deployed to the test module for testing; by capturing the message of the test process, the service interface definition of the running state of the software component in the test environment is obtained; the service interface definition of the running state is compared with the stored service interface definition of the design state to obtain a consistency comparison result; if the consistency comparison result indicates that there is a difference between the service interface definition of the running state and the service interface definition of the design state, the online management platform modifies the service interface definition of the design state or the service interface definition of the running state according to the preset rules, so that the service interface definition of the design state and the service interface definition of the running state are the same. Through this method, the difference between the service interface definition and the design state of the software component in the test environment is detected, and when there is a difference, it is modified to ensure the consistency of the service interface definition at each stage, and no manual comparison is required.

[0102] Figure 4 A flow chart of the second embodiment of the test management method provided in this application, such as Figure 4 As shown, the following steps are included. Based on the above embodiment, in step S103, a message of the software component in the test process is obtained, and a service interface definition of the software component in the running state in the test environment is obtained according to the message, which specifically includes the following steps:

[0103] S1031. The test platform obtains the request message and response message of each interface through the deployed service monitoring device.

[0104] In this step, deploy a suitable service monitoring device in advance on the test platform. The service monitoring device can intercept network traffic and display detailed information of requests and responses. Configure the service monitoring device to ensure that the required interface requests and responses can be captured.

[0105] S1032. Determine the request parameters, functions and calling methods of each interface according to the request message of each interface.

[0106] Based on the captured request data, identify the request parameters of each interface, including path parameters, query parameters, data in the request body, etc. Based on the request data analysis, determine the specific function of each interface. For example, a GET request may be used to obtain data, while a POST request may be used to create or update data.

[0107] Record the calling method of each interface, including HTTP method (GET, POST, etc.), API path, authentication method and other information.

[0108] S1033. Determine the data format of each interface according to the response message of each interface.

[0109] Capture the response data and analyze the data structure and format returned by each interface. Usually the data is in JSON or XML format. Confirm the data fields contained in each interface response, including the field name, type (string, integer, etc.), possible value range, etc.

[0110] S1034. Generate a running service interface definition document based on the request parameters, functions, calling methods and data formats of each interface.

[0111] Combined with the request parameters, functions, calling methods and response data formats analyzed above, a complete interface list is compiled. Using tools and preset formats, a service interface definition document is written, which includes basic information of each interface (path, method), detailed description of request parameters, response data structure, etc.

[0112] Through this embodiment, the service definition interface of the software component in the running state can be obtained in the test environment instead of being directly read from the file.

[0113] In the above-mentioned second embodiment, the request message and response message of each interface are obtained, but there may be repeated or similar requests during the test process, which will generate additional redundant information for generating the service definition document. The following is an example of how to process the request message and response message.

[0114] Figure 5 The flowchart of the third embodiment of the test management method provided by this application is as follows: Figure 5 As shown, the following steps are included:

[0115] S201. De-duplicate all request messages of each interface.

[0116] In this step, each interface will detect multiple request messages during the test, and they need to be compared to remove duplicate messages. Specifically, the URL path, HTTP method, parameter list, and parameter list value of all request messages of each interface are compared; if the URL path, HTTP method, parameter list, and parameter list value of any two request messages are the same, they are determined to be duplicate request messages and deduplication is performed.

[0117] Compare the requested URL path and the HTTP method used (such as GET, POST, etc.); compare the HTTP status code of the response. The same status code usually indicates a similar response; compare the data structure and content returned by the response. If the data structure, fields and types of the response are exactly the same, it can be preliminarily determined to be a similar response; compare the parameter list and its value of the request. The same parameter list and value can point to similar requests, but it should be noted that the order of the parameters does not affect the similarity judgment. If each of the above similarity comparisons indicates that the two requests are similar, then it is confirmed to be a duplicate message.

[0118] Optionally, for large amounts of data comparison, data hashing can be used. For example, the hash values ​​(such as MD5 or SHA-256) of the request and response messages are calculated and compared to see if the hash values ​​are consistent. Hash value consistency can be used as an indicator of request or response similarity.

[0119] Optionally, for text-based requests, a text similarity algorithm (such as edit distance, cosine similarity, etc.) may be used to evaluate the similarity between two requests.

[0120] When comparing the request parameter list and its value, the request parameter list refers to a set of key-value pairs passed in the HTTP request, which is usually used to define the request data and control the request behavior. It may appear in multiple locations, such as the URL path, the request body, the query string, etc. The parameter value is the specific numerical value or string corresponding to the request parameter. Each parameter has one or more values, and the value determines the specific content and behavior of the request.

[0121] For example, suppose there are two GET requests:

[0122] Request 1: / api / v1 / users?name=John&age=30;

[0123] Request 2: / api / v1 / users?age=30&name=John;

[0124] Although the parameter orders are different, they have the same parameter list (name and age) and the same values ​​(name=John and age=30), so the two requests can be considered similar requests.

[0125] S202: De-duplicate all response messages of each interface.

[0126] In this step, each interface will detect multiple response messages during the test, and they need to be compared to remove duplicate messages. Compare the status codes, key fields in the response header, and key fields in the response body of all response messages of each interface; if the status codes, key fields in the response header, and key fields in the response body of any two request messages are the same, they are determined to be duplicate response messages and deduplication is performed.

[0127] When determining whether a response message is duplicated, the following key factors need to be compared:

[0128] Status code: The status code of the HTTP response indicates the processing result of the request. Different status codes usually indicate different response statuses, such as 200 for success, 404 for resource not found, 500 for internal server error, etc.

[0129] Response header: HTTP response contains multiple header fields, which may affect the client's processing of the response or the cache of the response. Key header fields include: fields indicating the data type of the response body; fields indicating the length of the response body; fields indicating the cache control policy of the response; and other custom header fields. Therefore, compare the key fields in the header fields one by one.

[0130] Response body: The response body contains the actual data. For repeated responses, the content of the response body should be consistent. However, the response may be dynamically generated (for example, factors such as timestamps or random numbers may cause the content of some fields to be different each time), so it is necessary to determine whether the non-dynamic key fields are repeated.

[0131] If the response body is in text form or binary data, you can compare the content byte by byte. If the response body is structured data such as JSON or XML, you can first parse it into an object or DOM, and then compare the object attributes or DOM structure.

[0132] If the response body contains dynamically generated data (such as timestamps, random numbers), you can use specific algorithms or filtering methods to exclude dynamic factors and only compare the static content.

[0133] For larger response bodies or complex data, you can calculate a hash value (such as MD5 or SHA-256) and then compare the hash values ​​to see if they are the same. If the hash values ​​are the same, you can indirectly confirm that the response content is the same.

[0134] S203: Use all request messages after deduplication processing as request messages of each interface.

[0135] S204: Use the response request message after deduplication processing as the response message of each interface.

[0136] This embodiment provides a test management method. When obtaining the running service interface definition based on the request message and the response message, all request messages of each interface are deduplicated respectively. This can simplify the message data, improve the generation speed and accuracy of the service interface definition, and prevent the situation where the service interface definition is different due to similar messages.

[0137] The following example uses an example to explain in detail the test management methods in the requirements analysis, design, coding, testing, and deployment stages of software development.

[0138] Figure 6 This is a flow chart of an example of a test management method provided by this application. Figure 6 As shown in the figure, starting from entering the requirements, the test management process from the generation of requirements to production is introduced.

[0139] 1. The demander submits a demand document and breaks it down by demand item and submits it to the online management platform. If necessary, other high-level system design concepts such as business functions and processes should also be associated.

[0140] 2. The project team members receive the requirement document for design, generate a structured form of service design document (design document), submit it to the online management platform, and associate the requirement items. At the same time, the service should also be associated with other concepts such as business functions and processes.

[0141] 3. The online management platform forms a service document in XML format based on the structured service design document (design document) and the service specifications of the enterprise-level IT architecture using XML writing tools.

[0142] 4. Developers, in the R&D integrated client (IDE), download the XML format definition file of the above services and add them to the R&D project.

[0143] This step can be achieved by using the plug-in extension technology of the existing IDE.

[0144] 4.1 Developers can modify the design documents in the development environment according to actual conditions, perform design comparisons, and confirm the modified design documents and synchronize them back to the online management platform.

[0145] 5. Developers publish the development results to the test environment and execute the test.

[0146] 6. The test platform service monitoring device captures the service definition running online and uses it as the test environment verification result. It compares and removes the monitored service results, and then pushes the latest version results to the online management platform.

[0147] 6.1. After receiving the service definition file from the test environment, the online management platform will compare it with the locally stored design document for consistency. If there is a difference, a service definition difference confirmation item will be generated and released to the corresponding responsible personnel for difference processing.

[0148] The above differences mainly include two types: one is that the interface definition does not exist in the test environment. This type of definition appears because there is no design state entry that matches the interface definition obtained by the test. In this case, it will be handed over to the responsible system-level person in charge for further allocation of matters. The other is that the service already exists in the online management platform, but there is a difference between its running state definition and the design state definition. In this case, the design state person in charge of the online management platform will confirm the interface definition difference and choose to revise the design state or running state interface according to the actual situation, so that the two can be unified in the end.

[0149] 7. At the end of the development process, at the production stage, developers package the tested software components to generate products, and publish the products to the product management platform according to the process.

[0150] 7.1 The production verification platform uses the production product scanning tool to read the product, decompress the product according to the product-related specifications, read the application-level service xml file in the software component, and read the service definition in the file.

[0151] In one method, the production verification platform obtains the design state document stored in the online management platform, compares the read service interface definition with the service interface of the design state document stored in the online management platform, and obtains the error result. If there is inconsistency (including the lack of definition in the service online management platform and the inconsistency between the service definition and the design state definition of the online management platform), the production verification platform generates a product verification problem list, prompting the person in charge to handle the problem, modify the service interface definition in the released software component or modify the service interface definition in the design state document.

[0152] In another implementation, the commissioning verification platform sends the read service interface definition to the online management platform, which performs an error comparison and obtains an error result. If the error result indicates that the two are inconsistent, the person in charge is prompted to handle the problem and modify the service interface definition in the released software component or modify the service interface definition in the design document.

[0153] 7.2. The person in charge of the product shall deal with the issues in the product verification list, including discovering design state or operation state errors in the interface service definition, correcting the errors, and uploading the updated product when necessary; and supplementing the missing design state interface definition.

[0154] 7.3. After the person in charge of the work-in-progress completes the relevant revisions, he / she shall submit the revision plan to the person in charge of production for review and final product confirmation.

[0155] This example combines the actual situation of enterprise-level R&D processes and infrastructure, and combines the service from conceptual design, development phase message design, test verification, production delivery verification, and online registration verification to achieve all-round management of service interface definitions, ensuring that the design definition and the operation interface are consistent in terms of quantity and form. From the perspective of IT technology management, this solution proposes a unified service class governance and management method, and proposes a full-process, single-dimensional governance approach for the IT technology architecture governance of large financial IT companies.

[0156] Figure 7 This is a schematic diagram of the structure of the test management device embodiment 1 provided in the present application. The test management device 70 includes:

[0157] Receiving module 701, used to receive the design state document uploaded by the R&D integration client and the software component developed according to the design state document, wherein the design state document includes the design state service interface definition, and the design state service interface definition includes the definition of the function and calling method of each interface, request parameters, data format and error handling method;

[0158] A publishing module 702, for responding to a user's publishing operation, deploying the software component to a test platform for testing;

[0159] The acquisition module 703 is used to acquire the message of the software component during the test process, and acquire the service interface definition of the software component in the running state in the test environment according to the message;

[0160] A comparison module 704 is used to compare the running service interface definition with the stored design service interface definition to obtain a consistency comparison result;

[0161] Modification module 705 is used to modify the service interface definition in the design state or the service interface definition in the running state according to preset rules if the consistency comparison result indicates that there is a difference between the service interface definition in the running state and the service interface definition in the design state, so that the service interface definition in the design state and the service interface definition in the running state are the same.

[0162] In a possible design, the acquisition module 703 is specifically used to:

[0163] Obtaining a request message and a response message of each interface of the software component;

[0164] According to the request message of each interface, determine the request parameters, functions and calling methods of each interface;

[0165] Determine the data format of each interface based on the response message of each interface;

[0166] Generate a running service interface definition document based on the request parameters, functions, calling methods and data formats of each interface.

[0167] In a possible design, the acquisition module 703 is further used to:

[0168] De-duplicate all request messages of each interface;

[0169] De-duplicate all response messages from each interface;

[0170] All request messages after deduplication processing are used as request messages for each interface;

[0171] The response request message after deduplication processing is used as the response message of each interface.

[0172] In a possible design, the acquisition module 703 is further used to:

[0173] Compare the URL path, HTTP method, parameter list and parameter list value of all request messages of each interface;

[0174] If the URL path, HTTP method, parameter list, and parameter list value of any two request messages are the same, they are determined to be duplicate request messages and deduplication is performed.

[0175] In a possible design, the acquisition module 703 is further used to:

[0176] Compare the status codes, key fields in the response header, and key fields in the response body of all response messages from each interface;

[0177] If the status codes, key fields in the response header, and key fields in the response body of any two request messages are the same, they are determined to be duplicate response messages and deduplication is performed.

[0178] In a possible design, the difference includes a difference in the number of interfaces or a difference in the definition of a service interface.

[0179] In a possible design, the publishing module 702 is further used to:

[0180] Publishing the tested software component to the product management platform, and obtaining the application-level service XML file in the tested software component through a scanning tool;

[0181] Read the service interface definition in the service xml file, and obtain the service interface definition of the stored design document;

[0182] Perform an error comparison between the service interface definition in the service xml file and the service interface definition in the stored design state document to obtain an error result;

[0183] If the error result indicates that the service interface definition in the service xml file is different from the service interface definition in the stored design document, a prompt message is issued, which is used to prompt the user to modify the service interface definition in the published software component or modify the service interface definition in the design document.

[0184] In a possible design, the receiving module 701 is further used for:

[0185] Receive a demand document proposed by a demander terminal device, and push the demand document to a research and development integration client associated with the project, wherein the demand document includes functional requirements and non-functional requirements of the project;

[0186] According to the design state document uploaded by the R&D integration client, the structured design state document is converted into a service interface definition document in XML format through an XML writing tool;

[0187] The service interface definition document in XML format is sent to the R&D integration client.

[0188] The test management device provided in this embodiment can implement any of the methods in the above method embodiments, and the principles are similar, which will not be repeated here.

[0189] Figure 8 This is a schematic diagram of the structure of the electronic device provided in this application. The electronic device may be a server of the online management platform, or an electronic device deploying the online management platform, or an electronic device deploying the test platform. Figure 7 As shown, the electronic device 50 provided in this embodiment includes: at least one processor 501 and a memory 502. Optionally, the device 50 also includes a communication component 503. The processor 501, the memory 502 and the communication component 503 are connected via a bus 504.

[0190] In a specific implementation process, at least one processor 501 executes the computer-executable instructions stored in the memory 502, so that at least one processor 501 executes the above method.

[0191] The specific implementation process of the processor 501 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0192] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0193] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0194] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0195] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0196] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0197] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0198] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0199] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

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

[0201] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0202] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0203] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0204] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A test management method, characterized in that: The method comprises: Receive a design document uploaded by a research and development integration client and a software component developed according to the design document, wherein the design document includes a design service interface definition, and the design service interface definition includes a definition of the function and calling method of each interface, request parameters, data format, and error handling method; In response to a user's publishing operation, the software component is deployed to a test platform for testing; Obtaining a message of the software component during the test process, and obtaining a service interface definition of the software component in a running state in a test environment according to the message; Perform consistency comparison between the running service interface definition and the stored design service interface definition to obtain a consistency comparison result; If the consistency comparison result indicates that there is a difference between the service interface definition in the running state and the service interface definition in the design state, the service interface definition in the design state or the service interface definition in the running state is modified according to the preset rules so that the service interface definition in the design state and the service interface definition in the running state are the same.

2. The method according to claim 1, characterized in that: The obtaining of the message of the software component during the test process, and obtaining the service interface definition of the software component in the running state in the test environment according to the message, includes: Obtaining a request message and a response message of each interface of the software component; According to the request message of each interface, determine the request parameters, functions and calling methods of each interface; Determine the data format of each interface based on the response message of each interface; Generate a running service interface definition document based on the request parameters, functions, calling methods and data formats of each interface.

3. The method according to claim 2, characterized in that Before determining the request parameters, functions and calling methods of each interface according to the request message of each interface, the method further includes: De-duplicate all request messages of each interface; De-duplicate all response messages from each interface; All request messages after deduplication processing are used as request messages for each interface; The response request message after deduplication processing is used as the response message of each interface.

4. The method according to claim 3, characterized in that The deduplication processing of all request messages of each interface includes: Compare the URL path, HTTP method, parameter list and parameter list value of all request messages of each interface; If the URL path, HTTP method, parameter list, and parameter list value of any two request messages are the same, they are determined to be duplicate request messages and deduplication is performed.

5. The method according to claim 3, characterized in that: The deduplication processing of all response messages of each interface includes: Compare the status codes, key fields in the response header, and key fields in the response body of all response messages from each interface; If the status codes, key fields in the response header, and key fields in the response body of any two request messages are the same, they are determined to be duplicate response messages and deduplication is performed.

6. The method according to any one of claims 1 to 5, characterized in that: The differences include differences in the number of interfaces or differences in service interface definitions.

7. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Publishing the tested software component to the product management platform, and obtaining the application-level service XML file in the tested software component through a scanning tool; Read the service interface definition in the service xml file, and obtain the service interface definition of the stored design document; Perform an error comparison between the service interface definition in the service xml file and the service interface definition in the stored design state document to obtain an error result; If the error result indicates that the service interface definition in the service xml file is different from the service interface definition in the stored design document, a prompt message is issued, which is used to prompt the user to modify the service interface definition in the published software component or modify the service interface definition in the design document.

8. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Receive a demand document proposed by a demander terminal device, and push the demand document to a research and development integration client associated with the project, wherein the demand document includes functional requirements and non-functional requirements of the project; According to the design state document uploaded by the R&D integration client, the structured design state document is converted into a service interface definition document in XML format through an XML writing tool; The service interface definition document in XML format is sent to the R&D integration client.

9. A test management device, characterized in that: The device comprises: A receiving module, used to receive a design document uploaded by a research and development integration client and a software component developed according to the design document, wherein the design document includes a design service interface definition, and the design service interface definition includes a definition of the function and calling method of each interface, request parameters, data format, and error handling method; A publishing module, used for responding to a user's publishing operation and deploying the software component to a test platform for testing; An acquisition module, used to acquire the message of the software component during the test process, and acquire the service interface definition of the software component in the running state in the test environment according to the message; A comparison module, used for performing consistency comparison between the service interface definition in the running state and the service interface definition in the stored design state to obtain a consistency comparison result; A modification module is used to modify the service interface definition in the design state or the service interface definition in the running state according to preset rules if the consistency comparison result indicates that there is a difference between the service interface definition in the running state and the service interface definition in the design state, so that the service interface definition in the design state and the service interface definition in the running state are the same.

10. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 8 when executed by a processor.

12. A computer program product, characterized in that The invention comprises a computer program for implementing the method according to any one of claims 1 to 8 when the computer program is executed by a processor.

Images