Link test method and system relating to multi-system transformation

Abstract

The invention provides a link test method and system related to multi-system renovation, and the method comprises the steps: recognizing a local back-end project source code developed based on a Java or Kotlin language, generating an API document, and synchronizing the API document to a test platform; an annotation is added to a Controller layer of a back-end item of each system; according to the added annotation, interface change information is obtained from the API document synchronized to the test platform; collecting the interface change information according to the interface version number to obtain all interface sets involved in the link test; and testing all the interface sets involved in the obtained link test. According to the method and the device, the problem that a code change influence range and a test range are not clear during multi-system transformation is effectively solved, interface-level change records are acquired in real time, system barriers and team limitations are broken, meanwhile, accurate positioning of the test range is promoted, and cost reduction and efficiency improvement of link updating work are realized.

Description

Technical Field

[0001] This application relates to the technical field of link testing, and specifically relates to a link testing method and system involving multi-system transformation. Background Art

[0002] Test management is a process of managing test activities to ensure that software applications are tested with high quality. This method includes organizing, controlling, and ensuring the traceability and visibility of the test process to provide high-quality software application programs.

[0003] A test plan can be defined as a document that describes the scope, methods, resources, and schedule of test activities. Without a complete test plan, a project may fail. Test plans are particularly important in the development of large software systems. In software testing, the test plan provides detailed test information about the upcoming test work, including test strategies, test objectives, exit / suspension criteria, resource planning, and test deliverables; among which, the test objectives need to provide guiding suggestions and explanations for the test scope and code change scope.

[0004] Currently, the most difficult part in the test process is to determine the test scope, which requires relying on the R & D team to produce accurate interface documents. Currently, since the interface documents are compiled when requirements are newly created or changed, during the development stage, the development will adjust the interfaces or logic according to the actual situation of the project. According to the standardized process, the interface documents need to be updated and reviewed in a timely manner. However, this step is time-consuming and laborious, and it is very difficult to complete the timely update and review of the documents when the project is tense or the resource allocation is uneven. Therefore, in multi-system transformation projects, due to the large number of participating systems, the quality of interface documents is uneven, and the overall update is difficult, resulting in increased difficulty in evaluating function changes and determining the test scope, and it is very difficult to guarantee the accuracy.

[0005] In response to the above technical problems, the main solutions for interface document change management during multi-system transformation are as follows:

[0006] Urge the system side to update the interface documents on a daily basis through project meetings;

[0007] Generate interface documents in real time based on frameworks such as swagger;

[0008] Among them, solution 1 relies entirely on manpower, and it is very difficult to guarantee timeliness and accuracy;

[0009] Among them, solution 2 can reduce the difficulty of writing interface documents, but there is no version perspective, and frameworks such as swagger can only be based on systems, and it is very difficult to summarize the interface documents for cross-system projects.

[0010] Moreover, neither Solution 1 nor Solution 2 can solve the difficulties in interface document change management under multi-system transformation, and there are loopholes with unclear scope in link testing. Summary of the Invention

[0011] This application provides a link testing method and system for multi-system transformation, which can solve the technical problems existing in the prior art, namely, the difficulties in interface document change management under multi-system transformation and the loopholes with unclear scope in link testing.

[0012] In a first aspect, this application provides a link testing method for multi-system transformation, including the following steps:

[0013] Identify the source code of the local backend project developed based on the Java or Kotlin language, generate an API document, and synchronize the API document to the test platform;

[0014] Add annotations to the Controller layer of the backend projects of each system;

[0015] According to the added annotations, obtain the interface change information from the API document synchronized to the test platform;

[0016] Group the interface change information by interface version number to obtain the set of all interfaces involved in link testing;

[0017] Test the set of all interfaces involved in the obtained link testing.

[0018] Combined with the first aspect, in an implementation, the step of identifying the source code of the local backend project developed based on the Java or Kotlin language, generating an API document, and synchronizing the API document to the test platform specifically includes the following steps:

[0019] Identify the source code of the local Java and Kotlin backend projects, and use a tool to automatically generate an API document and synchronize it to the test platform with one click;

[0020] Configure an access token for the API file.

[0021] Combined with the first aspect, in an implementation, the step of adding annotations to the Controller layer of the backend projects of each system specifically includes the following steps:

[0022] Set interface classification information at the outermost layer of the Controller layer;

[0023] Set interface information at the inner layer of the Controller layer;

[0024] Set the interface status at the inner layer of the Controller layer.

[0025] In combination with the first aspect, in one implementation, obtaining interface change information from the API documentation synchronized to the test platform according to the added annotations specifically includes the following steps:

[0026] Interpret the API documentation. When an interface is newly added, modified, or deleted, obtain the interface change information according to the annotations added in the Controller layer.

[0027] In combination with the first aspect, in one implementation, aggregating the interface change information by interface version number to obtain the set of all interfaces involved in the link test specifically includes the following steps:

[0028] Set interface screening conditions;

[0029] According to the set interface screening conditions, obtain the set of all changed interfaces across all systems involved in the link test.

[0030] In combination with the first aspect, in one implementation, testing the set of all interfaces involved in the link test obtained specifically includes the following steps:

[0031] Build a test environment;

[0032] Design test cases, including functional test cases, performance test cases, and security test cases;

[0033] In the built test environment, test the interface set one by one according to the designed test cases to obtain the link test results.

[0034] In combination with the first aspect, in one implementation, the test cases include functional test cases, performance test cases, and security test cases.

[0035] In the second aspect, the present application provides a link test system for multi-system transformation, including:

[0036] An interface change information identification module, which is used to identify the source code of the backend project developed locally based on the Java or Kotlin language, generate an API document, and synchronize the API document to the test platform;

[0037] An annotation adding module, which is used to add annotations to the Controller layer of the backend projects of each system;

[0038] An interface change information obtaining module, which is communicatively connected to the interface change information identification module and the annotation adding module, and is used to obtain interface change information from the API document synchronized to the test platform according to the added annotations;

[0039] A test scope acquisition module, communicatively connected to the interface change information acquisition module, is configured to collect interface change information by interface version numbers and obtain the set of all interfaces involved in link testing;

[0040] A link testing module, communicatively connected to the test scope acquisition module, is configured to test the set of all interfaces involved in the obtained link testing.

[0041] Combined with the second aspect, in an implementation, the interface change information identification module includes:

[0042] An interface change information acquisition unit, configured to identify the source code of local Java and Kotlin backend projects, automatically generate API documents, and synchronize them to the test platform with one key;

[0043] A file access token configuration unit, communicatively connected to the interface change information acquisition unit, is configured to configure an access token for the API file.

[0044] In a third aspect, the present application provides a computer-readable storage medium, characterized in that a link testing program related to multi-system transformation is stored on the computer-readable storage medium, and when the link testing program related to multi-system transformation is executed by a processor, the steps of the link testing method related to multi-system transformation as described above are implemented.

[0045] The beneficial effects brought by the technical solutions provided in the embodiments of the present application at least include:

[0046] The present application completes the unified compilation of interface files by identifying the source code of local backend projects and adding annotations to achieve zero intrusion into the code, reduces the difficulty of overall coordination and update, effectively solves the problem of unclear influence scope and test scope of code changes in the case of multi-system transformation, realizes real-time acquisition of change records at the interface level, thereby breaking system barriers and team limitations, and at the same time promotes the accurate positioning of the test scope, and truly realizes the reduction of costs and improvement of efficiency in link update work. Description of the Drawings

[0047] Figure 1 It is a flowchart of the link testing method related to multi-system transformation of the present application;

[0048] Figure 2 It is a functional module block diagram of the link testing system for multi-system transformation provided by the embodiment of the present application. Detailed Embodiments

[0049] To enable those skilled in the art to better understand the solution of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts belong to the scope of protection of this application.

[0050] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned accompanying drawings are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally further include steps or units not listed, or may optionally further include other steps or units inherent to these processes, methods, products, or devices. The descriptions such as "first", "second", and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit that "first", "second", and "third" are different types.

[0051] In the description of the embodiments of this application, terms such as "exemplary", "for example", or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary", "for example", or "for instance" in the embodiments of this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of terms such as "exemplary", "for example", or "for instance" is intended to present relevant concepts in a specific manner.

[0052] In the description of the embodiments of this application, unless otherwise specified, " / " means "or". For example, A / B may represent A or B; "and / or" in the text is only a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "a plurality of" means two or more than two.

[0053] In some processes described in the embodiments of this application, a plurality of operations or steps appear in a specific order. However, it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of this application or may be executed in parallel. The serial numbers of the operations are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the following will further describe the embodiments of this application in detail with reference to the accompanying drawings.

[0055] In a first aspect, as Figure 1 shown, the embodiments of this application provide a link testing method for multi-system transformation, including the following steps:

[0056] Step S1: Identify the source code of the local backend project developed in Java or Kotlin, generate an API document, and synchronize the API document to the test platform;

[0057] Step S2: Add annotations to the Controller layer of the backend projects of each system;

[0058] Step S3: According to the added annotations, obtain the interface change information from the API document synchronized to the test platform;

[0059] Step S4: Aggregate the interface change information by interface version number to obtain the set of all interfaces involved in the link test;

[0060] Step S5: Test the set of all interfaces involved in the obtained link test.

[0061] This application completes the unified compilation of interface files by identifying the source code of the local backend project and adding annotations to achieve zero intrusion into the code, reduces the difficulty of overall coordination and update, effectively solves the problem of unclear influence scope and test scope of code changes in the case of multi-system transformation, realizes real-time acquisition of change records at the interface level, thereby breaking the system barriers and team limitations, and at the same time promotes the accurate positioning of the test scope, and truly realizes the reduction of costs and increase of efficiency in the link update work.

[0062] In one embodiment, the above-mentioned Step S1: Obtain interface information; identify the source code of the local backend project developed in Java or Kotlin, generate an API document, and synchronize the API document to the test platform, specifically includes the following steps:

[0063] Step S11: Identify the source code of the local Java and Kotlin backend projects, and a tool for automatically generating an API document and synchronizing it to the test platform with one click; specifically, each backend development team of the project introduces a tool in the IDEA environment to identify the source code of the local Java and Kotlin backend projects, and automatically generate an API document and synchronize it to the test platform with one click. Taking Apifox as an example, there is currently Apifox Helper in the plugins of IntelliJ IDEA, and it is installed for each backend development team of the project;

[0064] Step S12: Configure an access token for the API file; specifically, register an APIfox account and generate an API access token, set the API access token on the Upload to APIfox page of the APIfox Helper, and test the token. If the test is successful, the token setting is completed.

[0065] In one embodiment, the step S2: adding annotations to the Controller layer of each system backend project is specifically implemented by using the framework and library provided by the tool to introduce annotations to the Controller layer of each system backend project. More specifically, it includes the following steps:

[0066] Step S2A: Set interface classification information at the outermost layer of the Controller layer to organize interfaces of the same Controller layer and set belonging projects, as shown in the following example:

[0067] / **

[0068] *TestController / / Category name

[0069] *Used to collect test class interfaces / / Classification notes / descriptions

[0070] *

[0071] *@module TestProject / / belonging project

[0072] * /

[0073] @RequestMapping( / Test) / / Set the classification address;

[0074] Step S2B: Set the interface information in the inner layer of the Controller layer, record the API change record, and use the tag annotation to store the API version number. For example:

[0075]

[0076] Step S2C: Setting the interface status in the inner layer of the Controller layer. The interface status is set in the inner layer of the Controller layer. For example:

[0077] @Deprecated / / Indicates that the interface has been deprecated.

[0078] In one embodiment, the step S3: obtaining interface change information from the API document synchronized to the test platform according to the added annotations, specifically includes the following steps:

[0079] Interpret the API document. When an interface is added, modified, or deleted, obtain the interface change information according to the annotations added by the Controller layer. Taking interface modification as an example, obtain the interface change information according to the annotations added by the Controller layer as follows:

[0080] / **

[0081] *API Name

[0082] *api change record: interface change, add a new field tester to verify the legitimacy of the tester, if the tester does not exist, return 500 / / set interface change information

[0083] *@tag(name="V1.2.0") / / Set the change version

[0084] *@param / / parameter description

[0085] *@return / / Response description

[0086] * /

[0087] @ApiOperation("test interface") / / Set the interface name.

[0088] In one embodiment, the step S4: aggregating the interface change information by interface version number to obtain a set of all interfaces involved in the link test, specifically includes the following steps:

[0089] Step S41: Set interface screening conditions; specifically, log in to Apifox, take the Apifox web terminal as an example, perform interface screening in the interface management module, select "Published" in the status, and select "V1.2.0" in the tag;

[0090] Step S42: According to the set interface screening conditions, all changed interface sets are obtained across all systems involved in the link test; specifically, the total of all interfaces under version V1.2.0 can be obtained, and the collection of all changed interfaces can be viewed across systems.

[0091] The test team conducts centralized testing on the interface based on the interface information set obtained in step S4, thereby avoiding the waste of manpower for full regression and eliminating the risk of missed tests within the test scope determined by humans.

[0092] In one embodiment, the step S5: testing all interface sets involved in the acquired link test specifically includes the following steps:

[0093] Set up a test environment;

[0094] Design test cases, including functional test cases, performance test cases and security test cases;

[0095] In the established test environment, each interface in the interface set is tested one by one according to the designed test cases to obtain the link test results.

[0096] In a second aspect, as Figure 2 shown, the present application provides a link test system for multi-system transformation, including:

[0097] An interface change information recognition module, configured to recognize the source code of a local backend project developed based on the Java or Kotlin language, generate an API document, and synchronize the API document to the test platform;

[0098] An annotation adding module, configured to add annotations to the Controller layer of the backend projects of each system;

[0099] An interface change information obtaining module, communicatively connected to the interface change information recognition module and the annotation adding module, configured to obtain interface change information from the API document synchronized to the test platform according to the added annotations;

[0100] A test scope obtaining module, communicatively connected to the interface change information obtaining module, configured to collect interface change information by interface version number to obtain the entire interface set involved in the link test;

[0101] A link test module, communicatively connected to the test scope obtaining module, configured to test the entire interface set involved in the obtained link test.

[0102] In combination with the second aspect, in an implementation manner, the interface change information recognition module includes:

[0103] An interface change information obtaining unit, configured to recognize the source code of a local Java or Kotlin backend project, and a tool for automatically generating an API document and synchronizing it to the test platform with one key;

[0104] A file access token configuration unit, communicatively connected to the interface change information obtaining unit, configured to configure an access token for the API file.

[0105] Among them, the function implementation of each module in the above link test system for multi-system transformation corresponds to each step in the embodiment of the above link test method for multi-system transformation, and its function and implementation process will not be elaborated here one by one.

[0106] In a third aspect, an embodiment of the present application provides a link test device for multi-system transformation. The link test device for multi-system transformation may be a device with data processing functions such as a personal computer (PC), a laptop computer, a server, etc.

[0107] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces, etc., which are used to implement the interconnection of components inside the link test device for multi-system transformation, as well as the interfaces for implementing the interconnection between the link test device for multi-system transformation and other devices (such as other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.; the user device can be a display, a keyboard, etc.

[0108] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical memory, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0109] The processor can be a general-purpose processor, which can call the link test program for multi-system transformation stored in the memory and execute the link test method for multi-system transformation provided by the embodiments of the present application. For example, the general-purpose processor can be a central processing unit (CPU). Among them, the method executed when the link test program for multi-system transformation is called can refer to the various embodiments of the link test method for multi-system transformation in the present application, which will not be elaborated here.

[0110] Fourthly, the embodiments of the present application also provide a readable storage medium.

[0111] The link test program for multi-system transformation is stored on the readable storage medium of the present application. When the link test program for multi-system transformation is executed by the processor, the steps of the link test method for multi-system transformation as described above are implemented.

[0112] Among them, the method implemented when the link test program for multi-system transformation is executed can refer to the various embodiments of the link test method for multi-system transformation in the present application, which will not be elaborated here.

[0113] It should be noted that the serial numbers of the above embodiments of the present application are only for description and do not represent the superiority or inferiority of the embodiments.

[0114] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-described embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium as described above (such as ROM / RAM, magnetic disk, optical disc), and includes several instructions for causing a terminal device to execute the methods described in various embodiments of the present application.

[0115] The above are only the preferred embodiments of the present application, and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present application.

Claims

1. A link testing method involving multi-system transformation, characterized in that It includes the following steps: Identify the source code of the local backend project developed based on the Java or Kotlin language, generate API documents, and synchronize the API documents to the test platform; Add annotations to the Controller layer of each system's backend project; According to the added annotations, obtain interface change information from the API documents synchronized to the test platform; Group the interface change information by interface version number to obtain the set of all interfaces involved in the link test; Test the set of all interfaces involved in the obtained link test.

2. The link test method for multi-system transformation according to claim 1, characterized in that The step of identifying the source code of the local backend project developed based on the Java or Kotlin language, generating API documents, and synchronizing the API documents to the test platform specifically includes the following steps: A tool for identifying the source code of local Java and Kotlin backend projects, automatically generating API documents, and synchronizing them to the test platform with one click; Configure an access token for the API file.

3. The link test method for multi-system transformation according to claim 1, characterized in that, The step of adding annotations to the Controller layer of each system's backend project specifically includes the following steps: Set interface classification information at the outermost layer of the Controller layer; Set interface information at the inner layer of the Controller layer; Set the interface status at the inner layer of the Controller layer.

4. The link test method for multi-system transformation according to claim 1, wherein The step of obtaining interface change information from the API documents synchronized to the test platform according to the added annotations specifically includes the following steps: Interpret the API documents. When an interface is added, modified, or deleted, obtain the interface change information according to the annotations added to the Controller layer.

5. The link test method for multi-system transformation according to claim 1, characterized in that The step of grouping the interface change information by interface version number to obtain the set of all interfaces involved in the link test specifically includes the following steps: Set interface screening conditions; According to the set interface screening conditions, obtain all changed interface sets across all systems involved in the link test.

6. The link test method for multi-system transformation according to claim 1, characterized in that The step of testing the set of all interfaces involved in the obtained link test specifically includes the following steps: Build a test environment; Design test cases, including functional test cases, performance test cases, and security test cases; In the built test environment, test the interface set one by one according to the designed test cases to obtain the link test results.

7. The link test method for multi-system transformation as described in claim 6, characterized in that, The test cases include functional test cases, performance test cases, and security test cases.

8. A link test system involving multi-system transformation, characterized in that, It includes: An interface change information identification module for identifying the source code of the local backend project developed based on the Java or Kotlin language, generating API documents, and synchronizing the API documents to the test platform; An annotation adding module for adding annotations to the Controller layer of each system's backend project; An interface change information obtaining module, communicatively connected to the interface change information identification module and the annotation adding module, for obtaining interface change information from the API documents synchronized to the test platform according to the added annotations; A test scope obtaining module, communicatively connected to the interface change information obtaining module, for grouping the interface change information by interface version number to obtain the set of all interfaces involved in the link test; A link test module, communicatively connected to the test scope acquisition module, for testing all interface sets involved in the acquired link test.

9. The link test system for multi-system transformation according to claim 8, characterized in that, The interface change information recognition module includes: An interface change information acquisition unit, which is used to identify the source code of local Java and Kotlin backend projects, automatically generate API documents and synchronize them to the test platform with one key; A file access token configuration unit, communicatively connected to the interface change information acquisition unit, for configuring an access token for the API file.

10. A computer-readable storage medium, characterized in that, A link test program for multi-system transformation is stored on the computer-readable storage medium. When the link test program for multi-system transformation is executed by a processor, the steps of the link test method for multi-system transformation described in any one of claims 1 to 7 are implemented.

Images