API online testing method and device, electronic device and computer storage medium

Abstract

The present disclosure provides an API online testing method, comprising: temporarily publishing a target API on a publishing platform; collecting execution information of the target API based on usage operations during the temporary release period of the target API; determining performance parameters of the target API based on the execution information; switching the release status of the target API on the publishing platform from temporary release to formal release when the performance parameters meet the standards; and removing the target API from the publishing platform when the performance parameters do not meet the standards. Through the above method, automatic debugging of the API during temporary release can be achieved, which can improve the stability of the verified API, reduce the impact on API users during the temporary release period, and save testing resources.

Description

Technical Field

[0001] The present disclosure relates to the field of computers, and in particular, to an API online testing method and device, an electronic device, and a computer storage medium. Background Art

[0002] With the rapid development of cloud-native technologies, more and more users are hosting their developed APIs (Application Programming Interfaces) on cloud platforms. Currently, during the release phase of an API, it's temporarily unavailable, impacting API users. Furthermore, issues that arise during API testing often require on-site resolution by R&D personnel.

[0003] Therefore, a device is needed that can perform automatic testing without affecting user use. Summary of the Invention

[0004] The present disclosure provides an API online testing method and device, an electronic device, and a computer storage medium.

[0005] A first aspect of the present disclosure provides an API online testing method, the method comprising: temporarily publishing the target API on a publishing platform; collecting execution information of the target API based on usage operations during the temporary publishing period of the target API; determining performance parameters of the target API based on the execution information; switching the publishing status of the target API on the publishing platform from temporary release to formal release when the performance parameters meet the standards; and removing the target API from the publishing platform when the performance parameters do not meet the standards.

[0006] Optionally, during the temporary release time of the target API, execution information of the target API based on the usage operation is collected, including: obtaining a pre-check debugging result during the temporary release time of the target API; if the pre-check debugging result indicates that the target API data has passed the verification, executing the target API based on the usage operation in the grayscale period, and collecting the obtained execution information.

[0007] Optionally, the method further includes: obtaining a risk value based on a weighted calculation formula between the number of execution users, execution load, and execution online cycle value of the target API data verified through pre-check debugging; and obtaining the grayscale cycle that is positively correlated with the risk value based on the risk value.

[0008] Optionally, determining the performance parameters of the target API based on the execution information includes: determining that the performance parameters of the target API do not meet the requirements based on an indication from the execution information that the target API test has failed.

[0009] Optionally, determining the performance parameters of the target API based on the execution information includes: determining that the performance parameters of the target API meet the requirements based on an indication from the execution information that the target API test is successful.

[0010] Optionally, when the performance parameters do not meet the standards, after taking the target API offline from the publishing platform, the method further includes: obtaining the exception log of the target API contained in the execution information; and analyzing the reasons why the performance parameters of the target API do not meet the standards based on the exception log.

[0011] Optionally, analyzing the reasons why the performance parameters of the target API do not meet the standards based on the exception log includes: based on the idea of ​​inverse sorting, selecting key fields to compress the exception log, and establishing an index with key fields; uploading the compressed exception log to a search and analysis platform; querying and restoring the compressed exception log; and analyzing the reasons why the performance parameters of the target API do not meet the standards based on the restored exception log.

[0012] A second aspect of the present disclosure provides an API online testing device, which includes: a publishing module for temporarily publishing the target API on a publishing platform; a collection module for collecting execution information of the target API based on usage operations during the temporary publishing time of the target API; a first determination module for determining the performance parameters of the target API based on the execution information; a switching module for switching the publishing status of the target API on the publishing platform from temporary release to formal release when the performance parameters meet the standards; and an offline module for offline the target API from the publishing platform when the performance parameters do not meet the standards.

[0013] A third aspect of the present disclosure provides an electronic device, characterized in that the electronic device includes: a processor; a memory for storing a computer program that can be run on the processor; wherein, when the processor is used to run the computer program, it executes the steps of the API online testing method of the first aspect mentioned above.

[0014] A fourth aspect of the present disclosure provides a computer storage medium, characterized in that the computer storage medium stores computer-executable instructions; the computer-executable instructions are executed by a processor to implement the API online testing method as described in the first aspect above.

[0015] The technical solution provided by the embodiments of the present disclosure may include the following beneficial effects: the API online testing method in the embodiments of the present disclosure temporarily releases the target API on the publishing platform; during the temporary release time of the target API, collects execution information of the target API based on the usage operation; determines the performance parameters of the target API based on the execution information; when the performance parameters meet the standards, switches the release status of the target API on the publishing platform from temporary release to formal release; when the performance parameters do not meet the standards, takes the target API offline from the publishing platform; in this way, compared with the existing technology that requires manual debugging and affects user use, automatic debugging can be achieved when the API is temporarily released, which can improve the stability of the verification API, reduce the impact on API users during the temporary release time, and save testing resources.

[0016] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flowchart of an API online testing method according to an exemplary embodiment.

[0018] Figure 2 This is a flowchart of an API online testing method according to an exemplary embodiment.

[0019] Figure 3 This is a flowchart of an API online testing method according to an exemplary embodiment.

[0020] Figure 4 This is a flowchart of an API online testing method according to an exemplary embodiment.

[0021] Figure 5 This is a flowchart of an API online testing method according to an exemplary embodiment.

[0022] Figure 6 This is a flowchart of an API online testing method according to an exemplary embodiment.

[0023] Figure 7 A flowchart of a method for testing an upgraded API according to a conventional embodiment is shown;

[0024] Figure 8 This is a log processing flow diagram of an API online testing method according to an exemplary embodiment.

[0025] Figure 9 This is a flowchart of an API online testing method according to an exemplary embodiment.

[0026] Figure 10This is a structural diagram of an API online testing device shown in an exemplary embodiment;

[0027] Figure 11 This is a structural diagram of an API online testing device shown in an exemplary embodiment;

[0028] Figure 12 The figure is a structural diagram of an API online testing device according to an exemplary embodiment. DETAILED DESCRIPTION

[0029] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible implementations consistent with the present disclosure. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

[0030] The present disclosure embodiment, combined with Figure 1 As shown, a method for testing an API online is provided, the method comprising:

[0031] Step S101, temporarily publishing the target API on a publishing platform;

[0032] Step S102, collecting execution information of the target API based on the usage operation within the temporary release time of the target API;

[0033] Step S103, determining the performance parameters of the target API according to the execution information;

[0034] Step S104: when the performance parameter meets the standard, switching the target API's release status on the release platform from temporary release to official release;

[0035] Step S105: when the performance parameter does not meet the standard, the target API is taken offline from the publishing platform.

[0036] In the embodiment of the present disclosure, in step S101, the publishing platform is a cloud platform, and the target API is temporarily published on the publishing platform.

[0037] In the disclosed embodiments, temporary release refers to a temporary release based on grayscale measurement. Using the grayscale plug-in module, a grayscale policy is used to specify the API caller user group for diversion, so that some users use the grayscale version while others use the original version. Grayscale policies can be used to divert traffic based on custom request headers, source IP addresses or address segments, specific customer segments, or a combination thereof.

[0038] In the disclosed embodiment, the grayscale plug-in module supports operations such as grayscale release initiation, grayscale removal, grayscale cycle, and grayscale launch success.

[0039] In one embodiment, if the custom request header specified by the grayscale policy is version: V2.5.0, a user carrying this custom request header accesses the grayscale version of the target API.

[0040] In the embodiment of the present disclosure, the target API includes but is not limited to: an upgraded version of the API relative to the API version currently used by the user. When released based on a grayscale strategy, the upgraded version of the API can also be called a grayscale version.

[0041] In the disclosed embodiment, in step S102, the usage operation is also referred to as a test case. For example, a filter is written using the SpringBoot framework (an open source application framework) to implement the usage operation, such as the number of executions, the executing user, and the execution address indicated by the usage operation. Furthermore, the filter executes the target API based on the usage operation within the grayscale period according to the target API risk level assessment.

[0042] In the embodiment of the present disclosure, in step S102, execution information of the target API based on the usage operation is collected during the temporary release time of the target API. The execution information includes but is not limited to execution log information.

[0043] In the embodiment of the present disclosure, in step S103, the performance parameters of the target API are determined based on the execution information, and whether the performance parameters of the target API meet the requirements is determined based on the execution log information.

[0044] In the embodiment of the present disclosure, the performance parameters of the target API include but are not limited to one of the following:

[0045] Request response time;

[0046] Throughput;

[0047] TPS (transactions per second)

[0048] QPS (Queries Per Second)

[0049] Concurrency (the number of requests the system can handle simultaneously).

[0050] In the disclosed embodiment, in step S104, when the performance parameters meet the requirements, the target API's release status on the release platform is switched from provisional release to official release. Here, a portion of users who have already used the target API are allowed to continue using the target API, while another portion of users who have not yet used the target API are officially online and use the target API. Thus, the target API's release status is switched from provisional release to official release.

[0051] In the disclosed embodiment, in step S105, if the performance parameters do not meet the standards, the target API is removed from the publishing platform. This means that some users who were already using the target API no longer use it and instead use the original API version or complain about abnormal usage of the temporary version. Other users who did not use the target API continue to use the original API version. Furthermore, if the performance parameters do not meet the standards, the reasons for the non-compliance need to be analyzed in conjunction with the execution information.

[0052] In this disclosed embodiment, by releasing the target API using a grayscale policy, the impact on API users can be reduced. Furthermore, the target API is executed based on user operations, enabling automated execution and testing without the need for manual testing. This reduces the impact on users while also improving the automation and efficiency of testing, saving manpower.

[0053] In the embodiment of the present disclosure, Figure 2 In step S102, the collecting of execution information of the target API based on the use operation during the temporary release time of the target API includes:

[0054] Step S1021, obtaining pre-check debugging results within the temporary release time of the target API;

[0055] Step S1022: If the pre-check debugging result indicates that the target API data has passed verification, the target API is executed based on the usage operation in the grayscale period, and the obtained execution information is collected.

[0056] In the embodiment of the present disclosure, the target API data includes but is not limited to: the target API name, the target API path, the expected number of users (unit: thousands), the expected load (unit: hundreds / s), and the expected online cycle (days).

[0057] In the embodiment of the present disclosure, before step S1021, the target API data is cached and stored in a redis (Remote Dictionary Server) storage system, so that the target API data can be guaranteed not to be lost during the automated testing process.

[0058] In the disclosed embodiment, in steps S1021 and S1022, pre-check debugging of the target API data is performed during the temporary release period of the target API, and a pre-check debugging result is obtained. The pre-check debugging result indicates that the target API data has passed verification, indicating that there are no obvious abnormalities in the target API data. Therefore, the target API can be executed based on the usage operation within the grayscale period to collect the execution information.

[0059] In the embodiment of the present disclosure, in step S1022, executing the target API based on the usage operation in the grayscale cycle means that, within the grayscale cycle, the target API data is filled into the usage operation, i.e., the test case script, executing the test case, and obtaining the execution information, i.e., the execution log information.

[0060] In the embodiment of the present disclosure, based on the test case consisting of the number of executions, the executing user and the executing address, the use operation and the test case script are executed to obtain the execution information.

[0061] In the embodiment of the present disclosure, before executing the target API based on the use operation, the target API data is pre-checked and debugged, which can reduce subsequent target API execution errors, thereby reducing process losses and reducing waste of computing resources.

[0062] In the disclosed embodiment, during the grayscale cycle, the target API is automatically executed based on the usage operation, thereby improving the degree of automated testing and saving manpower.

[0063] In the embodiment of the present disclosure, Figure 3 , the method further comprises:

[0064] Step S10211, obtaining a risk value based on a weighted calculation formula among the number of executing users, the execution load, and the execution online period value of the target API data verified through pre-check and debugging;

[0065] Step S10212: Obtain the grayscale period that is positively correlated with the risk value according to the risk value.

[0066] In the embodiment of the present disclosure, in step S10211, the risk value riskValue is obtained based on the weighted calculation formula between the execution user number userNumber of the target API data verified through pre-check debugging, the execution load capacity loadCapacity and the execution online period value period.

[0067] In the embodiment of the present disclosure, the weighted calculation formula is a risk assessment formula:

[0068] riskValue=userNumber×M1+loadCapacity×M2+period×M3.

[0069] In the above formula, M1 is the weight coefficient of the execution user quantity userNumber, M2 is the weight coefficient of the execution load quantity loadCapacity, and M3 is the weight coefficient of the online period value period, and the sum of M1, M2, and M3 is 1.

[0070] In the embodiment of the present disclosure, in the above formula, M1>M2>M3, for example, M1 takes a value of 0.5, M2 takes a value of 0.3, and M3 takes a value of 0.2.

[0071] In the embodiments of the present disclosure, the relationship and values ​​of M1, M2, and M3 are not limited to the above embodiments and can be adjusted according to the importance of any data. The values ​​of M1, M2, and M3 that can be adjusted according to the importance of any data are within the scope of implementation of this application.

[0072] In the embodiment of the present disclosure, the target API data may be collected according to the following Table 1:

[0073]

[0074] Table 1

[0075] In the embodiment of the present disclosure, after the risk value riskValue is obtained after executing step S10211, the grayscale period can be obtained according to a function that is positively correlated with the risk value.

[0076] In one embodiment, the positive correlation function may be, but is not limited to, a piecewise increasing function, as shown in Table 2 below:

[0077]

[0078] Table 2

[0079] In one embodiment, the positive correlation function may be, but is not limited to, a direct proportional function, where grayscale cycle value=k*risk value, and k may be a value such as 0.1, 0.2, or the like.

[0080] In the disclosed embodiment, the execution load may be performed at multiple levels, such as 100 times, 500 times, 2000 times, etc., for the target API to verify the load capacity of the service and to determine whether the bottleneck of the load capacity meets expectations.

[0081] In the disclosed embodiment, a risk value is calculated based on the number of executing users, the execution load, and the execution online period. The grayscale period is then calculated based on the risk value to determine the time to execute the target API based on the usage operation. This allows for selecting a reasonable time interval for automated testing. After the target API is temporarily released, automated testing can be performed to reduce the impact on the target API users. The time to execute automated testing can also be automatically calculated, saving manpower and computing resources.

[0082] In the embodiment of the present disclosure, Figure 4 In step S103, determining the performance parameters of the target API according to the execution information includes:

[0083] Step S1031 : determining that the performance parameters of the target API do not meet the requirements based on the execution information indicating that the target API test has failed.

[0084] In the embodiment of the present disclosure, in step S1031, the execution information includes but is not limited to: execution log information and / or execution return result data. If the target API execution return result data is 5xx (500, 502, etc.), it indicates that the target API execution failed and there will be execution exception log information.

[0085] In the embodiment of the present disclosure, based on the execution exception log information and / or the execution return result data, it can be determined that the performance parameters of the target API do not meet the standards.

[0086] In the embodiment of the present disclosure, by indicating that the target API test has failed through execution information and determining the performance parameters of the target API, abnormal log information can be provided to facilitate analysis of the cause of the error.

[0087] In the embodiment of the present disclosure, Figure 4 In step S103, determining the performance parameters of the target API according to the execution information includes:

[0088] Step S1032: Determine whether the performance parameters of the target API meet the requirements based on the execution information indicating that the target API test is successful.

[0089] In the disclosed embodiment, the execution information includes normal execution log information and / or execution return result data. If the target API execution return result data is 2XX (200, etc.), it means that the target API is executed successfully and there is only normal execution log information.

[0090] In the embodiment of the present disclosure, it can be determined whether the performance parameters of the target API meet the requirements based on the normal execution log information and / or the execution return result data.

[0091] In the embodiment of the present disclosure, the execution information indicates that the target API test is successful, which can confirm that the subsequent target API can be officially released and fully launched for all users to use.

[0092] In the embodiment of the present disclosure, Figure 5 When the performance parameter does not meet the standard, after delisting the target API from the publishing platform, the method further includes:

[0093] Step S106, obtaining the exception log of the target API included in the execution information;

[0094] Step S107: analyzing the reasons why the performance parameters of the target API do not meet the standards based on the abnormality log.

[0095] In the disclosed embodiment, in step S106, the normal execution logs in the execution information are filtered to obtain abnormal logs. By analyzing the statistical results of the abnormal logs, a statistical report is generated, and the system describes various performance parameters of the target API, such as the request response time, throughput, TPS, QPS, and concurrency of the target API.

[0096] In the embodiment of the present disclosure, in step S107, the reason why the performance parameter of the target API does not meet the standard is analyzed based on the exception log, that is, the error cause is tracked. Based on the statistical report generated based on the execution exception log in step S106, key error information can be directly obtained from the execution exception log to directly locate the error cause.

[0097] In the embodiment of the present disclosure, the reasons why the performance parameters do not meet the standards can be analyzed through the exception log, which is beneficial for subsequent solutions.

[0098] In the embodiment of the present disclosure, Figure 6 In step S107, analyzing the reasons why the performance parameters of the target API do not meet the standards according to the abnormality log includes:

[0099] Step S1071: Based on the reverse sorting idea, key fields are selected to compress the exception log, and indexes are created based on the key fields.

[0100] Step S1072: uploading the compressed exception log to a search and analysis platform;

[0101] Step S1073: query and restore the compressed exception log;

[0102] Step S1074: Analyze the reasons why the performance parameters of the target API do not meet the standards based on the recovered exception log.

[0103] In the embodiment of the present disclosure, step S1071 selects key fields including but not limited to remote_address and request_method as indexes based on the reverse sorting principle. These key fields are fields involved in a target API call, which can facilitate searching for content corresponding to the key fields.

[0104] In the embodiment of the present disclosure, step S1071 selects key fields to compress the exception log, which can reduce the pressure of log collection, analysis and storage under high concurrency.

[0105] In the embodiment of the present disclosure, in step S1072, the compressed exception log is uploaded to the search and analysis platform ElasticSearch, which can be used to implement search, full-text retrieval, data analysis, etc.

[0106] In the disclosed embodiment, in step S1073, the compressed exception log can be queried and restored based on the key fields. Here, the specific exception log to be obtained can be queried based on the key fields, and the specific compressed exception log can be restored. This eliminates the need to restore all exception logs and does not increase the log collection, analysis, and storage pressure.

[0107] In the embodiment of the present disclosure, in step S1074, the reason why the performance parameters of the target API do not meet the standards can be analyzed based on the restored specified exception log.

[0108] In the disclosed embodiment, since the target API has a large number of online users, a large number of exception logs, and a large amount of corresponding exception log data, compression of the exception logs based on the reverse sorting principle can reduce the pressure of log collection, analysis, and storage under high concurrency. Furthermore, based on the search and analysis platform, search queries and recovery queries for specified compressed exception logs can be implemented, thereby analyzing the reasons why the performance parameters of the target API do not meet the standards.

[0109] Now, in combination with the above embodiments, a method for API online testing is provided.

[0110] Example 1:

[0111] With the rapid development of cloud-native technologies, more and more users are hosting their developed APIs on cloud platforms. Leveraging high-performance, highly available, and secure API hosting service platforms, users can easily build, manage, and deploy APIs of any scale. Currently, API launches are typically completed by testing the API functionality offline, informing API callers of the upcoming launch, and then releasing the API on the API hosting service by taking it offline, editing, republishing it, or directly editing it. Figure 7 The overall process is described using the current API upgrade as an example.

[0112] Step S201: The upgrade begins. The API user informs the API callers that the API is about to be launched and that the API will be temporarily unavailable during the launch period. To minimize the impact on API callers, the upgrade is usually performed at night.

[0113] Step S202: API microservice deployment: API user's R&D personnel deploy the latest API microservice in the production environment.

[0114] Step S203: The API user's tester uses tools such as Postman to test the API functions and load capacity in the production environment. If there are any problems, the R&D personnel will solve them on site.

[0115] Step S204: The upgrade is completed. If the final test fails, the API microservice rolls back, and the API user informs the API caller of the online failure. After the problem is fixed, the API caller goes online again. If the test passes, the upgrade is completed.

[0116] The existing API launch method has the following shortcomings:

[0117] (1) The existing online method is not very friendly to some core API callers. The API service online requires interrupting the original service, and it is necessary to wait for the API online to be completed before it can be used. Moreover, whether the API that has been online can withstand the use of callers for a period of time remains to be studied.

[0118] (2) Unexpected situations may occur during the launch process, such as network policy failure, manual operation errors, etc.; then API users often need to upgrade at night, consuming a lot of energy of R&D personnel.

[0119] (3) API testing requires additional testers to perform a large amount of testing work, which is time-consuming and prone to errors.

[0120] To address the above shortcomings, the present invention proposes a framework and method that combines the concept of phased release with automated testing and online release. This method can solve the following problems:

[0121] (1) API users can go online at any time. Due to the existence of grayscale release, the grayscale version of the API is fully compatible with the existing API, which solves the problem that API callers cannot call the API during the online period in traditional methods. If any problems occur during the online process, they can also roll back, solving the problems of manual errors that may occur in traditional methods and consuming a lot of R&D personnel's energy. It is also very friendly to API callers and R&D personnel.

[0122] (2) Through API online risk assessment, the optimal grayscale cycle is determined. The online personnel perform automated testing on the newly added API on the API hosting service platform. The execution results will be fed back to the platform. After the grayscale cycle is completed, it is confirmed whether the API online is in line with expectations, further ensuring the stability of API operation.

[0123] (3) Unlike existing API services, which are not easy to analyze log information over a period of time, especially in a high-concurrency environment, the stability of the API is difficult to ensure. This invention adds a grayscale log collection module, which is implemented based on ELK and combines the reverse sorting idea to realize the self-service troubleshooting function. During the grayscale period with high concurrency of API calls, abnormal logs are collected and analyzed to realize self-service troubleshooting, ensuring the stable operation of the API in the online environment.

[0124] This proposal is based on the concept of grayscale release and the development of an API automated testing tool for API launch, resulting in an API launch framework and method based on grayscale automated testing. Its main contents include a grayscale plug-in module, an automated testing module, and a log processing module.

[0125] Grayscale plug-in module

[0126] A grayscale policy is provided to specify the user group of API callers. The grayscale policy supports traffic weight ratios, custom request headers, source IP addresses or address segments, specific clients, and other operations. It also supports grayscale release initiation, grayscale removal, grayscale cycle, and grayscale launch success. When the grayscale cycle ends, API users can switch traffic en masse to complete the launch.

[0127] 1. Automated testing module

[0128] Refine and add automated testing processes for the managed API launch. The specific process is as follows: API data cache -> pre-check debugging -> Filter test case writing -> multi-level load execution -> log filtering analysis -> platform result report -> error cause tracking.

[0129] 1.1 API data caching. The present invention implements API data caching and stores the managed API information in redis to ensure that API data will not be lost during the automated testing process.

[0130] 1.2 Pre-check debugging: When users click on pre-check debugging, the hosted API data will be verified to reduce process losses.

[0131] 1.3 Filter test case writing: Use SpringBoot as the architecture to write a filter to implement the test case, including the number of executions, execution users, execution addresses, etc. At the same time, the managed API will evaluate the grayscale cycle based on the API risk level, and the filter will execute the test case in the grayscale cycle.

[0132] Step 1: Upload the hosted API data

[0133] Collect data according to the following table

[0134]

[0135] Step 2: Calculate the API launch risk

[0136] The risk assessment formula is as follows:

[0137] riskValue=userNumber X 0.5+loadCapacity X 0.3+period X 0.2

[0138] Where riskValue is the risk value, userNumber is the expected number of users, loadCapacity is the expected load, and period is the expected online period. After calculation, select the grayscale period according to the following risk value recommended grayscale period table:

[0139]

[0140] Step 3: The filter executes test cases on the managed API with a path such as / ai / create based on the recommended grayscale cycle value.

[0141] 1.4 Multi-level load execution: For managed APIs, multiple levels such as 100 times, 500 times, 2000 times, etc. can be performed to verify the load capacity of the service.

[0142] 1.5 Log filtering analysis: Based on the log processing module proposed in the present invention, log filtering optimization is achieved, making it easier to obtain usable logs.

[0143] 1.6 Platform result statistics: By analyzing the statistical results of the logs and generating reports, the system describes various indicators of the managed API.

[0144] 1.7 Error cause tracking: With the help of the previous process platform result report, the key information of the call can be directly obtained from the error log, and the cause of the error can be directly located to facilitate resolution.

[0145] 2. Log processing module

[0146] This module is based on ELK implementation and collects the results returned by automated testing. The present invention filters normal call logs, optimizes log storage, and compresses abnormal call log information based on the reverse sorting idea, which greatly reduces the pressure of system log collection, analysis and storage. The Filebeat component collects compressed log information and transmits it to ElasticSearch through logstash to achieve self-service troubleshooting, thereby ensuring the effectiveness of the API. The specific implementation process is as follows: Figure 8 :

[0147] Log preprocessing, in the grayscale log collection module, the present invention only collects abnormal log records, selects the fields of interest as key fields column_key based on the inverse sorting idea to compress the log files, thereby reducing the log collection analysis and storage pressure under high concurrency. Column_key includes but is not limited to: remote_address, request_method, response_method, response_message. Create a corresponding name list column_value_list_id for the logs corresponding to these key fields, such as Figure 8 As shown, each name column_value_id stores log information such as column_value column, count column number, position position, etc. Figure 8 shown.

[0148] ELK, based on the ELK module, filebeat collects compressed abnormal log records, which are then transferred to ElasticSearch by logstash to integrate abnormal logs

[0149] View exception logs. This module can query the exception logs integrated by ELK, and can restore files and view details of the exception logs compressed based on the inverse sorting idea.

[0150] The overall process of launching the API based on the above three modules is as follows Figure 9 :

[0151] Step S301: Going online starts.

[0152] Step S302: Compose and execute the grayscale strategy, relying on the grayscale plug-in module, and write a filter to implement the grayscale plug-in to complete the grayscale strategy forwarding.

[0153] Step S303: Click Grayscale Release to officially enter the grayscale testing cycle and verify the API during the cycle.

[0154] Step S304: Click on automated testing. No tester participation is required and the online personnel can operate directly.

[0155] Step S305: Preview the test case and fill the API information into the specific test case script.

[0156] Step S306: Execute the script in batches. During the grayscale period, execute the API multiple times to obtain a large number of return results, which makes it easy to verify the stability of the API.

[0157] Step S307: Return to log processing, rely on the log processing module to reduce server pressure, obtain the required logs for self-service troubleshooting.

[0158] Step S308: Verify the returned result. After the grayscale period ends, verify the returned result. If it fails, roll back the current online operation and delete the grayscale policy. If it succeeds, grayscale switching is performed.

[0159] Step S309: Grayscale release switches traffic to the grayscale version.

[0160] Step S310: End of online process.

[0161] This invention proposes a new way to launch APIs on an API hosting service platform based on the concept of grayscale release and orchestration of automated testing tools, namely, providing an API launch framework and method based on grayscale automated testing. The technical means disclosed in the scheme of the present invention are not limited to the technical means disclosed in the above-mentioned embodiments, but also include technical solutions composed of any combination of the above technical features. Improvements made without departing from the principles of the present invention are also considered to be within the scope of protection of the present invention.

[0162] This involves saving resources consumed by grayscale releases without interrupting existing API microservices and testing. It also combines the grayscale log collection module to implement self-service troubleshooting, conducts risk assessment on the managed API launch, determines the optimal grayscale cycle, and further ensures the successful launch of the managed API.

[0163] (1) Based on the grayscale release concept, users of the API hosting service platform can launch the API at any time without affecting the use of the API by API callers. R&D personnel do not need to launch the API at night to reduce the impact on callers.

[0164] (2) No dedicated testers are required, saving a lot of manpower and reducing the cost of manual errors. The platform automatically compiles API information into test case scripts, which can complete a large number of calls during the grayscale cycle and effectively verify the stability of the API.

[0165] (3) It is difficult to determine the optimal grayscale cycle for grayscale release. This platform selects the optimal grayscale cycle through API online risk assessment to further ensure the stability of the managed API online.

[0166] (4) Add a log processing module to compress exception logs based on the inverse sorting idea, and complete log collection and analysis through the ELK module to achieve self-service troubleshooting, ensuring that the API runs stably in the grayscale cycle in a high-concurrency call environment, and ensuring the successful launch of the API.

[0167] In the embodiment of the present disclosure, Figure 10 As shown, an API online testing device 400 is provided, and the device 400 includes:

[0168] A publishing module 401 is used to temporarily publish the target API on a publishing platform;

[0169] A collecting module 402 is configured to collect execution information of the target API based on a usage operation during the temporary release time of the target API;

[0170] A first determining module 403 is configured to determine the performance parameters of the target API according to the execution information;

[0171] A switching module 404 is configured to switch the target API's release status on the release platform from temporary release to official release when the performance parameter meets the standard;

[0172] The offline module 405 is used to offline the target API from the publishing platform when the performance parameters do not meet the standards.

[0173] In the embodiment of the present disclosure, the collection module 402 is further configured to:

[0174] Used to obtain pre-check debugging results within the temporary release time of the target API;

[0175] If the pre-check debugging result indicates that the target API data has passed verification, the target API is executed based on the usage operation in the grayscale period, and the obtained execution information is collected.

[0176] In the embodiment of the present disclosure, Figure 11 As shown, the apparatus 400 further includes:

[0177] The second determination module 406 is configured to obtain a risk value based on a weighted calculation formula among the number of executing users, the execution load, and the execution online period value of the target API data verified through pre-check debugging;

[0178] The third determining module 407 is configured to obtain, according to the risk value, the grayscale period that is positively correlated with the risk value.

[0179] In the embodiment of the present disclosure, the first determining module 403 is further configured to:

[0180] Used to indicate that the target API test failed according to the execution information, and determine that the performance parameters of the target API did not meet the standards.

[0181] In the embodiment of the present disclosure, the first determining module 403 is further configured to:

[0182] Used to indicate that the target API test is successful based on the execution information, and determine that the performance parameters of the target API meet the standards.

[0183] In the embodiment of the present disclosure, the apparatus 400 further includes:

[0184] The acquisition module 408 and the analysis module 409 are used to remove the target API from the publishing platform when the performance parameters do not meet the standards.

[0185] The acquisition module 408 is used to obtain the exception log of the target API included in the execution information;

[0186] The analysis module 409 is configured to analyze the reasons why the performance parameters of the target API do not meet the standards based on the abnormality log.

[0187] In the embodiment of the present disclosure, Figure 12 As shown, the analysis module 408 is further configured to:

[0188] Based on the inverse sorting idea, key fields are selected to compress the exception logs and index is established based on the key fields;

[0189] Used to upload the compressed exception log to the search and analysis platform;

[0190] Used to query and restore the compressed exception log;

[0191] Used to analyze the reasons why the performance parameters of the target API do not meet the standards based on the restored exception log.

[0192] In an embodiment of the present disclosure, an electronic device is provided, comprising:

[0193] processor;

[0194] a memory for storing processor-executable instructions;

[0195] The processor is used to implement the steps of the above-mentioned API online testing method when running the computer service.

[0196] Those skilled in the art will appreciate that all or part of the steps of the above-mentioned method embodiments may be implemented by hardware associated with program instructions, and the aforementioned program may be stored in a computer-readable storage medium. When the program is executed, the program executes the steps of the above-mentioned method embodiments. The aforementioned storage medium includes various media that can store program codes, such as mobile storage devices, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical disks.

[0197] In an embodiment of the present disclosure, a storage medium is provided, wherein the storage medium contains computer-executable instructions, and the computer-executable instructions are executed by a processor to implement the steps in the above-mentioned API online testing method.

[0198] Alternatively, if the above-mentioned integrated unit of the embodiment of the present invention is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, read-only memories (ROMs), random access memories (RAMs), magnetic disks or optical disks.

[0199] The above description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any modifications or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the application documents.

Claims

1. An API online testing method, characterized in that: The method comprises: Temporarily publish the target API on the publishing platform; Obtaining pre-check debugging results within the temporary release time of the target API; If the pre-check debugging result indicates that the target API data has passed verification, executing the target API based on the usage operation in the grayscale period and collecting the obtained execution information; Determining performance parameters of the target API based on the execution information; When the performance parameters meet the requirements, the target API's release status on the release platform is switched from temporary release to official release; When the performance parameters do not meet the standards, delisting the target API from the publishing platform; The method further comprises: Obtaining a risk value based on a weighted calculation formula among the number of executing users, the execution load, and the execution online cycle value of the target API data verified through pre-check debugging; According to the risk value, the grayscale period positively correlated with the risk value is obtained.

2. The API online testing method according to claim 1, characterized in that: Determining the performance parameters of the target API according to the execution information includes: According to the execution information indicating that the target API test failed, it is determined that the performance parameters of the target API do not meet the standards.

3. The API online testing method according to claim 1, characterized in that: Determining the performance parameters of the target API according to the execution information includes: According to the execution information indicating that the target API test is successful, it is determined that the performance parameters of the target API meet the requirements.

4. The API online testing method according to claim 1 or 2, characterized in that: When the performance parameter does not meet the standard, after delisting the target API from the publishing platform, the method further includes: Obtaining the exception log of the target API included in the execution information; Analyze the reasons why the performance parameters of the target API do not meet the standards based on the abnormal log.

5. The API online testing method according to claim 4, characterized in that: The analyzing, based on the exception log, the reason why the performance parameter of the target API does not meet the standard includes: Based on the inverse sorting idea, key fields are selected to compress the exception logs and indexes are established based on the key fields. Uploading the compressed exception log to a search and analysis platform; Query and restore the compressed exception log; Analyze the reasons why the performance parameters of the target API do not meet the standards based on the recovered exception log.

6. An API online testing device, characterized in that: The device comprises: The publishing module is used to temporarily publish the target API on the publishing platform; A collection module is configured to obtain a pre-check and debugging result within the temporary release time of the target API; if the pre-check and debugging result indicates that the target API data has passed verification, execute the target API based on the usage operation in the grayscale period and collect the execution information obtained; A first determining module, configured to determine performance parameters of the target API based on the execution information; A switching module, configured to switch the target API's release status on the release platform from temporary release to official release when the performance parameter meets the standard; An offline module, configured to offline the target API from the publishing platform when the performance parameters do not meet the standards; A second determination module is configured to obtain a risk value based on a weighted calculation formula among the number of executing users, the execution load, and the execution online cycle value of the target API data verified through pre-check debugging; The third determining module is configured to obtain, according to the risk value, the grayscale period that is positively correlated with the risk value.

7. An electronic device, characterized in that: The electronic device comprises: processor; A memory for storing a computer program that can be run on a processor; wherein, when the processor is used to run the computer program, it executes the steps of the API online testing method described in any one of claims 1 to 5.

8. A computer storage medium, characterized in that The computer storage medium stores computer-executable instructions; the computer-executable instructions are executed by a processor to implement the method for API online testing as described in any one of claims 1 to 5.

Images