Interface risk assessment method and device based on online news traffic

Abstract

The invention discloses an interface risk assessment method and device based on online news traffic, and the method comprises the steps: monitoring a code warehouse called by a new media interface, then capturing an affected interface through an automatic means, and carrying out the risk assessment of the affected interface in combination with a network request log; therefore, a tester can be assisted to accurately identify an interface influenced by code change, and the risk brought to the interface due to the code change can be more accurately evaluated according to the network request log; on the basis, the intelligent analysis technology is innovatively introduced, an interface risk test system is constructed, the requirement for the ability of test personnel is lowered, high dependence on personal experience is reduced, and the efficiency and accuracy of the whole test process are remarkably improved; therefore, the method is very suitable for large-scale application and popularization.

Description

Technical Field

[0001] The present invention belongs to the technical field of software testing, and in particular relates to an interface risk assessment method and device based on online news traffic. Background Art

[0002] In the current new media software testing industry practice, evaluating the risks that may be introduced by the development team's code modifications has become a particularly daunting challenge. When the code base changes, it may inadvertently affect other components of the system, such as the interfaces called by new media. Therefore, when evaluating interface risks, testers not only need to be proficient in various testing techniques, but also have a solid programming foundation. Only in this way can they deeply understand the code logic and the business logic it carries, so as to accurately trace and predict the potential risks of the changes.

[0003] In order to meet this challenge, testers usually use static and dynamic code analysis tools to assist in code review. However, these tools are not perfect in actual applications, and false positives and missed positives occur from time to time. This requires testers to not only be proficient in the use of these tools, but also have the ability to comprehensively consider tool characteristics, project requirements, and development process characteristics to ensure that potential problems in the code can be fully and accurately identified and resolved, thereby accurately completing interface risk assessment; based on this, the aforementioned existing technologies not only have high requirements on the ability of testers, but are also highly dependent on personal experience, which reduces the accuracy of the test. At the same time, the use of manual assessment of interface risks also reduces the efficiency of the test; therefore, how to provide an interface risk assessment method with high accuracy and efficiency has become an urgent problem to be solved. Summary of the invention

[0004] The purpose of the present invention is to provide an interface risk assessment method and device based on online news traffic, so as to solve the problem that the existing technology uses manual assessment of interface risks, which requires high ability of testers and is highly dependent on personal experience, resulting in low accuracy and efficiency.

[0005] In order to achieve the above object, the present invention adopts the following technical solutions:

[0006] In the first aspect, a method for assessing interface risk based on online news traffic is provided, including:

[0007] Get network request logs and code repositories for new media API calls;

[0008] Based on the code repository, a plurality of target interfaces are determined, wherein the plurality of target interfaces are used to represent interfaces that are affected by changes in the code in the code repository among all interfaces called by the new media;

[0009] Parsing the network request log to obtain interface call information;

[0010] According to the target interface and the interface calling information, risk assessment processing is performed on the several target interfaces to screen out risky interfaces from the several target interfaces, so as to complete the risk assessment of the new media calling interface after obtaining the risky interfaces.

[0011] Based on the above disclosed content, the present invention first obtains the code repository of the new media interface call and the network request log generated by the interface call; then, based on the code in the code repository, from all the interfaces called by the new media, the interfaces affected by the code changes are screened out, thereby obtaining several target interfaces; then, by parsing the network request log, the interface call information is obtained; finally, the aforementioned target interfaces can be risk assessed based on the interface call information, thereby screening out risky interfaces from several target interfaces, and thus the risk assessment of the interface can be completed.

[0012] Through the above design, the present invention monitors the code repository called by the new media interface, and then captures the affected interface through automated means, and combines the network request log to perform risk assessment of the affected interface; in this way, it can not only help testers accurately identify the interfaces affected by code changes, but also more accurately assess the risks brought to the interfaces by code changes based on the network request log; based on this, the present invention innovatively introduces intelligent analysis technology and constructs an interface risk testing system, which reduces the ability requirements for testers, reduces the high dependence on personal experience, and significantly improves the efficiency and accuracy of the entire testing process; therefore, the present invention is very suitable for large-scale application and promotion.

[0013] In a possible design, several target interfaces are identified based on the code repository, including:

[0014] Parsing all codes in the code repository to obtain parsing results corresponding to each code, wherein the parsing result of any code includes a method corresponding to the code;

[0015] According to the parsing results corresponding to each code, determine the calling method corresponding to each method;

[0016] A call graph is constructed using the methods corresponding to each code and the calling methods corresponding to each method, wherein the call graph contains a number of nodes, each node represents a code method, and the nodes corresponding to two code methods with a calling relationship are connected by edges, and a code method is a method or a calling method;

[0017] Filtering out target codes from the code repository, and parsing to obtain methods corresponding to the target codes as methods to be retrieved, wherein the target codes are codes that have changed in the code repository;

[0018] Determine, from the call graph, a node having an edge connection relationship with the method to be retrieved, so as to obtain a call relationship corresponding to the target code based on the node having an edge connection relationship with the method to be retrieved;

[0019] The plurality of target interfaces are determined according to the calling relationship.

[0020] In a possible design, the network request log includes log information of all interfaces called by the new media during the publishing phase, and the interface call information includes interface request data and interface response data of all interfaces called by the new media during the publishing phase;

[0021] Among them, performing risk assessment processing on the plurality of target interfaces according to the target interface and the interface call information to screen out risky interfaces from the plurality of target interfaces includes:

[0022] According to the interface request data and several target interfaces, the number of interface accesses of each target interface during the release phase is counted;

[0023] Using the interface response data, the call success rate of each target interface during the release phase is calculated;

[0024] Based on the interface request data, determining the request parameters and request frequency of each target interface during the publishing phase;

[0025] According to the number of interface accesses corresponding to each target interface, the call success rate corresponding to each target interface, and the request parameters and request frequencies corresponding to each target interface, risky interfaces are screened out from the plurality of target interfaces.

[0026] In a possible design, risk interfaces are screened out from the target interfaces according to the number of interface accesses corresponding to each target interface, the call success rate corresponding to each target interface, and the request parameters and request frequencies corresponding to each target interface, including:

[0027] According to the number of interface accesses of each target interface in the release phase, target interfaces whose number of interface accesses is less than the minimum access frequency are removed from the plurality of target interfaces to obtain a plurality of first interfaces to be evaluated;

[0028] Determining the risk level of each first interface to be evaluated according to the number of interface accesses of each first interface to be evaluated, wherein the higher the risk level, the greater the number of interface accesses;

[0029] Based on the risk level of each first interface to be evaluated, screening out a test risk interface from the plurality of first interfaces to be evaluated;

[0030] According to the call success rate of each target interface during the release phase, the target interface with a call success rate lower than the success rate threshold is selected from a number of target interfaces to serve as the release risk interface;

[0031] Using the request parameters and request frequencies of each target interface during the release phase, interface risk assessment is performed on each target interface to screen out pre-release risk interfaces from a number of target interfaces;

[0032] The risk interface is composed of the test risk interface, the pre-release risk interface and the release risk interface.

[0033] In a possible design, the request parameters and request frequencies of each target interface in the release phase are used to perform interface risk assessment on each target interface, so as to screen out pre-release risk interfaces from a number of target interfaces, including:

[0034] Based on the request frequencies of the target interfaces, target interfaces whose request frequencies are lower than a frequency threshold are removed from the target interfaces to obtain a plurality of second interfaces to be evaluated;

[0035] Obtain the pre-release environment and official release environment for interface deployment;

[0036] Generate a first call request for each second interface to be evaluated according to the pre-release environment and the request parameters of each second interface to be evaluated, and generate a second call request for each second interface to be evaluated according to the formal release environment and the request parameters of each second interface to be evaluated;

[0037] Using the first call request and the second call request of each second interface to be evaluated, calling each second interface to be evaluated, so as to obtain a first call response result of each second interface to be evaluated in the pre-release environment and a second call response result in the formal release environment;

[0038] The pre-release risk interface is screened out from the plurality of second interfaces to be evaluated according to the first call response results and the second call response results corresponding to the respective second interfaces to be evaluated.

[0039] In a possible design, the pre-release risk interface is screened out from a plurality of second interfaces to be evaluated according to the first call response result and the second call response result corresponding to each second interface to be evaluated, including:

[0040] Comparing the first call response result and the second call response result of each second interface to be evaluated, to obtain a comparison result of each second interface to be evaluated, wherein the comparison result of any second interface to be evaluated is that the call content is consistent or the call content is inconsistent;

[0041] Based on the comparison results of the second interfaces to be evaluated, the second interfaces to be evaluated whose comparison results show inconsistent call contents are selected from the plurality of second interfaces to be evaluated to serve as the pre-release risk interface.

[0042] In a possible design, the network request log is parsed to obtain interface call information, including:

[0043] Use regular expressions to parse the network request log to obtain interface request data and interface response data;

[0044] The interface call information is generated using the interface request data and the interface response data.

[0045] In a second aspect, an interface risk assessment device based on online news traffic is provided, comprising:

[0046] An acquisition unit, used to acquire network request logs and a code repository for calling new media interfaces;

[0047] An interface selection unit, configured to determine a plurality of target interfaces based on the code repository, wherein the plurality of target interfaces are used to represent interfaces that are affected by changes in the code in the code repository among all interfaces called by the new media;

[0048] A parsing unit, used for parsing the network request log to obtain interface call information;

[0049] The risk assessment unit is used to perform risk assessment processing on the multiple target interfaces according to the target interface and the interface calling information, so as to screen out risk interfaces from the multiple target interfaces, and complete the risk assessment of the new media calling interface after obtaining the risk interface.

[0050] In a third aspect, another interface risk assessment device based on online news traffic is provided. Taking the device as an electronic device as an example, the device includes a memory, a processor and a transceiver which are communicatively connected in sequence, wherein the memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer program to execute the interface risk assessment method based on online news traffic as in the first aspect or any possible design in the first aspect.

[0051] In a fourth aspect, a storage medium is provided, on which instructions are stored. When the instructions are executed on a computer, the interface risk assessment method based on online news traffic as in the first aspect or any possible design of the first aspect is executed.

[0052] In a fifth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, causes the computer to execute the interface risk assessment method based on online news traffic as described in the first aspect or any possible design of the first aspect.

[0053] Beneficial effects:

[0054] (1) The present invention monitors the code repository called by the new media interface, then captures the affected interface through automated means, and combines the network request log to perform risk assessment on the affected interface; in this way, it can not only help testers accurately identify the interfaces affected by code changes, but also more accurately assess the risks brought to the interfaces by code changes based on the network request log; based on this, the present invention innovatively introduces intelligent analysis technology and constructs an interface risk testing system, which reduces the ability requirements for testers, reduces the high dependence on personal experience, and significantly improves the efficiency and accuracy of the entire testing process; therefore, the present invention is very suitable for large-scale application and promotion.

[0055] (2) The present invention performs interface risk detection by acquiring network request logs. Therefore, interface risk monitoring can cover the testing, pre-release and formal release stages, that is, by automatically capturing interface information affected by code changes and combining the number of visits to the online interface to perform risk assessment, the risk interface in the testing stage can be obtained (i.e., focusing on testing interfaces with more visits). In this way, the present invention can intelligently guide testers to design more targeted test cases, thereby ensuring the accuracy and efficiency of the testing work.

[0056] At the same time, request parameters and frequency play an important role in the pre-release stage. Therefore, the present invention uses request parameters and request frequency to drive the interface to make access requests in the pre-release environment and the online formal environment respectively, and compares the response results of the two environments to obtain the risk interface of the pre-release stage. In this way, this step is crucial for predicting the risks of problems that may be introduced by the new version, and helps the team to discover and fix potential problems in time before the official release.

[0057] Finally, during the release phase, the present invention continuously monitors and collects access success rate data of the affected interfaces, and uses this as an important indicator for monitoring online operation status, so as to derive risk interfaces during the release phase. This measure ensures that the team can quickly respond to possible anomalies that may occur online, thereby ensuring the stable operation of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 A schematic diagram of the steps of the interface risk assessment method based on online news traffic provided by an embodiment of the present invention;

[0059] Figure 2 A flowchart for determining a target interface based on a code repository provided by an embodiment of the present invention;

[0060] Figure 3 A flow chart of interface risk assessment provided by an embodiment of the present invention;

[0061] Figure 4 A schematic diagram of the structure of an interface risk assessment device based on online news traffic provided by an embodiment of the present invention;

[0062] Figure 5 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0063] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in combination with the drawings and the description of the embodiments or the prior art. Obviously, the following description of the structure of the drawings is only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. It should be noted that the description of these embodiments is used to help understand the present invention, but does not constitute a limitation of the present invention.

[0064] It should be understood that although the terms first, second, etc. may be used herein to describe various units, these units should not be limited by these terms. These terms are only used to distinguish one unit from another unit. For example, a first unit can be referred to as a second unit, and similarly, a second unit can be referred to as a first unit without departing from the scope of the exemplary embodiments of the present invention.

[0065] It should be understood that the term "and / or" that may appear in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can represent three situations: A exists alone, B exists alone, and A and B exist at the same time. The term " / and" that may appear in this article describes another type of association object relationship, indicating that two relationships may exist. For example, A / and B can represent two situations: A exists alone, and A and B exist alone. In addition, the character " / " that may appear in this article generally indicates that the previous and next associated objects are in an "or" relationship.

[0066] Example:

[0067] See also Figure 1 As shown, the interface risk assessment method based on online news traffic provided by this embodiment monitors the code repository called by the new media interface, then captures the affected interface by automated means, and combines the network request log to perform risk assessment of the affected interface; in this way, it can not only help testers accurately identify the interfaces affected by code changes, but also more accurately assess the risks brought to the interface by code changes based on the network request log; based on this, the method reduces the ability requirements for testers, reduces the high dependence on personal experience, and significantly improves the efficiency and accuracy of the entire testing process; therefore, it is very suitable for large-scale application and promotion; among them, for example, the method can be but not limited to running on the interface risk assessment end side, optionally, the interface risk assessment end can be but not limited to a personal computer (PC), a tablet computer or a smart phone, it can be understood that the aforementioned execution subject does not constitute a limitation on the embodiments of the present application, and accordingly, the operation steps of the method can be but not limited to the following steps S1 to S4.

[0068] S1. Obtain network request logs and code repositories for new media interface calls; in specific implementation, most companies have deployed online environment log collection systems. The log data collected by these systems can be effectively applied to interface testing and system monitoring after analysis. Therefore, this embodiment can provide an accurate data basis for subsequent interface risk analysis by collecting network request logs; wherein, the network request log described in the example contains log information of all interfaces called by new media in the release stage, based on this, all risk interfaces in the testing, pre-release and formal release stages can be obtained based on the log information.

[0069] At the same time, the code warehouse used for calling the new media interface mentioned above is the code warehouse used for the interface call, and the acquired code warehouse contains the code corresponding to the latest software version; thus, this embodiment automatically captures the interfaces affected by code changes by monitoring the code warehouse, and then combines the network request log of the interface to implement risk assessment of the affected interfaces.

[0070] The process of capturing the interface affected by the code change may be, but is not limited to, as shown in the following step S2.

[0071] S2. Based on the code repository, several target interfaces are determined, wherein the target interfaces are used to characterize all interfaces called by the new media, and the interfaces affected by the changes in the code in the code repository; in specific applications, see Figure 2As shown, this embodiment combines Java bytecode technology to parse each code in the code repository, thereby obtaining the class and method of each code, and determining other methods called by each method; then, using the results of the aforementioned analysis to establish a call graph; finally, based on the call graph, determine the interface affected by the code change.

[0072] Optionally, the aforementioned interface capture process may be but is not limited to the following steps S21 to S26.

[0073] S21. parse all the codes in the code repository to obtain the parsing results corresponding to each code, wherein the parsing result of any code includes the method corresponding to any code; in this embodiment, see Figure 2 As shown, the bytecode structure of the Java class of the parsed code is used to obtain the classes and methods corresponding to each code; in the specific implementation, the class (Class) in the code is the blueprint for creating an object, and the method (Method) is the function defined in the class, which is used to perform specific operations; therefore, by parsing the code, its calling relationship can be obtained, that is, the method corresponding to each code and other methods called by its method.

[0074] Specifically, the process of determining other methods called by each method may be, but is not limited to, as shown in the following step S22.

[0075] S22. According to the analysis results corresponding to each code, determine the calling method corresponding to each method; in specific applications, parse the internal implementation of each method to accurately locate other methods called by it; wherein, the implementation in the method refers to the specific code inside the method, which defines the operations performed by the method and usually includes variable declarations, logical operations, control flow statements (such as if-else, for, while, etc.), calls to other methods or functions, and return results, etc.; therefore, based on the method of each code, it is possible to capture other methods called by it; then, based on this, a call graph can be constructed, and the process can be but is not limited to as shown in the following step S23.

[0076] S23. Using the methods corresponding to each code and the calling methods corresponding to each method, a call graph is constructed, wherein the call graph contains a number of nodes, each node represents a code method, and the nodes corresponding to two code methods with a calling relationship are connected by edges, and the code method is a method or a calling method; in this embodiment, see Figure 2As shown, the method corresponding to each code and the calling method corresponding to each method are taken as nodes, and the methods with calling relationships are connected by edges (for example, if there is a calling relationship between method A and calling method A1, they are connected by edges); in this way, these connecting edges are essentially potential call chains, which clearly depict the calling order and logical flow between methods.

[0077] Based on this, after constructing the call graph, when the code in the code repository changes, the interface affected by the code change can be determined based on the call graph; wherein the capture process of the target interface can be but is not limited to as shown in the following steps S24 to S26.

[0078] S24. Filter out target codes from the code repository, and parse to obtain methods corresponding to the target codes as methods to be retrieved, wherein the target codes are codes that have changed in the code repository.

[0079] After obtaining the changed code (i.e. Figure 2 After the modified code in the code block is found and its corresponding method is parsed, node matching can be performed in the call graph to obtain its corresponding call relationship, that is, the changed code part is tracked in the call graph to extract the call chain associated with the changed code. The specific determination process is shown in the following step S25.

[0080] S25. From the call graph, determine the nodes that have an edge connection relationship with the method to be retrieved, so as to obtain the calling relationship corresponding to the target code based on the nodes that have an edge connection relationship with the method to be retrieved; in the specific implementation, the method to be retrieved is actually a node, therefore, the node that has an edge connection relationship with it is determined in the call graph, and then it is used as the method that has a calling relationship with the method to be retrieved; in this way, according to obtaining the original code of the method that has a calling relationship with the method to be retrieved, the affected interface can be determined; of course, it is also possible to first determine the node corresponding to the original method of the target code (that is, the method corresponding to the code before the change); then, based on the node that has an edge connection relationship with the node corresponding to the original method, determine the calling relationship; in this way, the calling relationships determined by the above two methods are both calling relationships corresponding to the target code.

[0081] After obtaining the call relationship corresponding to the target code, the interface affected by the code change can be determined based on it. The process can be but not limited to the following step S26.

[0082] According to the calling relationship, the several target interfaces are determined; in this embodiment, the calling interface corresponding to the target code and the calling interface corresponding to the code that has a calling relationship with the target code are essentially determined according to the calling relationship; then, the aforementioned determined calling interface is used as the interface affected by the code change.

[0083] Therefore, through the aforementioned steps S21 to S26, this embodiment can pull the latest code from the code repository through an automated program and accurately identify the modified code fragments; then, this embodiment deeply locates the member methods involved in these modifications and comprehensively searches for the calling conditions of these methods. Finally, based on this, all affected interfaces can be automatically traced and identified.

[0084] After capturing the interface affected by the code change, the aforementioned network request log can be parsed to obtain the interface call information, so as to subsequently perform a risk assessment of the affected interface based on the interface call information; wherein, the log parsing process can be but is not limited to as shown in the following step S3.

[0085] S3. Parse and process the network request log to obtain interface call information; in specific implementation, this embodiment uses regular expression technology to accurately match and record the interface call information in the log, that is, uses regular expressions to parse and process the network request log to obtain interface request data and interface response data; then, use the interface request data and the interface response data to generate the interface call information; at the same time, it has been explained above that the network request log covers the formal release stage, so the interface call information includes the interface request data and interface response data of all interfaces called by the new media during the release stage.

[0086] Furthermore, the following is an example of parsing a network request log:

[0087] Assume that the online interface request log is:

[0088] 2024-11-26 09:54:23.158 INFO[http-nio-8080-exec-9]ccserver.interceptor.AppCheckHandlerInterceptor line59- / getList input parameters={"deviceid":"XX","illegalDeviceid":false,"ip":"14.108.212.29","message":"verify Certificate passed","params":{"vno":["10.1.1"],"account":["XXD"],"client":["iOS"],"data":["{\"list_style\": 1,\"interact_poId\":-1,\"ad_id\":0,\"channel_type\":1,\"size\":\"1179*2556\",\"channel_id\": 9,\"page_size\":10,\"news_id\":11540101,\"operation_type\":1,\"lastUpdateTime\":\"2024-11-26 09:53:37\",\"main_channel_style\":true}"],"deviceid":["XXX"],"sign":["XXXX"],"switch_suggest":["1"]," teen_mode":["0"],"timestamp":["1732586063052"],"token":[""]},"url":"http: / / api.thecover.cn / getList"}.

[0089] The online interface response log is:

[0090] 2024-11-26 09:54:23.635 INFO[http-nio-8080-exec-9]ccserver.interceptor.AppCheckHandlerInterceptor line132- / getList response=200.

[0091] Then, the regular expression is:

[0092] pattern_param=r'^(\d{4}-\d{2}-\d{2}\d{2}:\d{2}:\d{2}.\d{3}).*( / \w+)Input parameter=(.*)'

[0093] pattern_response=r'^(\d{4}-\d{2}-\d{2}\d{2}:\d{2}:\d{2}.\d{3}).*( / \w+) response=(\d{3})'.

[0094] Of course, the above examples are only for illustration, and the use of regular expressions to perform log processing is a common technology for log parsing, and its principle will not be elaborated here.

[0095] In this way, after obtaining the interface request data and interface response data of all interfaces called by the new media in the release stage, the risk interfaces of the testing, pre-release and release stages can be derived based on the above data, wherein the evaluation process of the risk interface can be but is not limited to as shown in the following step S4.

[0096] S4. Perform risk assessment on the target interfaces and the interface call information to screen out risky interfaces from the target interfaces, and complete the risk assessment of the new media call interface after obtaining the risky interface. In the specific implementation, it is mainly to count the number of interface calls during the publishing stage, the request parameters and frequency during the publishing stage, and the call success rate during the publishing stage, so as to conduct risk assessment of the interface at different stages based on the aforementioned statistical data. The specific risk assessment process may be, but is not limited to, as shown in the following steps S41 to S44.

[0097] S41. According to the interface request data and several target interfaces, statistics of the number of interface accesses to each target interface during the release phase; in this embodiment, see Figure 3 As shown, the number of interface accesses of each target interface can be counted in the interface request data according to the name of each target interface, so as to complete the risk assessment of each target interface in the testing phase based on this later; similarly, the risk assessment of each target interface in the publishing phase can also be performed according to the interface response data, and the process can be but is not limited to as shown in the following step S42.

[0098] S42. Using the interface response data, the call success rate of each target interface during the release phase is calculated; in specific applications, see Figure 3 As shown, the return status of each target interface is determined based on the name of each target interface and then from the interface response data, wherein the return status indicates whether the call is successful or unsuccessful. Based on this, the return status of each target interface at each call during the formal release phase can be counted to calculate the call success rate of each target interface.

[0099] After completing the statistics of the call success rate of each target interface in the release stage, the request parameters and frequency of each target interface in the release stage can be obtained, so as to perform risk assessment in the pre-release stage based on the request parameters and frequency (request parameters and frequency play an important role in pre-release, therefore, interface risk detection in the pre-release stage can be performed based on request parameters and frequency); wherein, the process of obtaining request parameters and frequency can be but is not limited to as shown in the following step S43.

[0100] S43. Based on the interface request data, the request parameters and request frequency of each target interface in the publishing stage are determined; in the specific implementation, the request parameters and frequency corresponding to each target interface are determined in the interface request data according to the name of each target interface; wherein the request parameters are the data content to be pulled by each target interface, such as web page content, etc.; in this way, after obtaining the request parameters and request frequency of each target interface in the publishing stage, the risk assessment of the target interface at different stages can be carried out in combination with the aforementioned interface access times and call success rate, and the process is shown in the following step S44.

[0101] S44. According to the number of interface accesses corresponding to each target interface, the call success rate corresponding to each target interface, and the request parameters and request frequency corresponding to each target interface, the risk interface is screened out from the target interfaces; in specific applications, the risk assessment of the interface is carried out from the three stages of testing, pre-release and release based on the aforementioned data. The process can be seen in Figure 3 As shown; at the same time, this embodiment provides a specific evaluation method, which can be but not limited to the following steps S44a~S44f.

[0102] S44a. According to the number of interface accesses of each target interface during the release phase, the target interfaces whose interface accesses are less than the minimum access frequency are removed from a number of target interfaces to obtain a plurality of first interfaces to be evaluated; in specific implementation, the minimum access frequency can be specifically set according to actual use, wherein the present embodiment is preferably set to 0 or 1.

[0103] After removing the target interfaces whose interface access times are lower than the minimum access frequency, the interface risk classification can be performed according to the interface access times, and the process is shown in the following step S44b.

[0104] S44b. Determine the risk level of each first interface to be evaluated according to the number of interface accesses of each first interface to be evaluated, wherein the higher the risk level, the more interface accesses there are; in specific implementation, the interface access number intervals corresponding to different risk levels can be pre-set; then, according to the number of interface accesses of each first interface to be evaluated, the intervals are matched to obtain the corresponding risk level; wherein, this embodiment divides the interfaces into high-risk interfaces, medium-risk interfaces and low-risk interfaces; in this way, the target interfaces with risks in the test phase can be screened out according to the risk level of each first interface to be evaluated, and the process is shown in the following step S44c.

[0105] S44c. Based on the risk level of each first interface to be evaluated, screen out the test risk interface from multiple first interfaces to be evaluated; in specific implementation, high-risk interfaces and medium-risk interfaces can be used as test risk interfaces, that is, in the test phase, the interfaces with more interface access times should be focused on.

[0106] After completing the interface risk assessment in the testing phase, the risk assessment in the pre-release phase may be performed, and the process is shown in the following step S44d.

[0107] S44d. Using the request parameters and request frequency of each target interface during the release phase, perform interface risk assessment on each target interface to screen out pre-release risk interfaces from a number of target interfaces; in specific implementation, refer to Figure 3 As shown, this embodiment first removes target interfaces whose request frequencies are lower than a frequency threshold from each target interface based on the request frequencies of each target interface, so as to obtain a plurality of second interfaces to be evaluated; then, the pre-release environment and the formal release environment of the interface deployment are obtained; then, according to the pre-release environment and the request parameters of each second interface to be evaluated, a first call request of each second interface to be evaluated is generated, and according to the formal release environment and the request parameters of each second interface to be evaluated, a second call request of each second interface to be evaluated is generated; then, the first call request and the second call request of each second interface to be evaluated can be used to call each second interface to be evaluated, so as to obtain a first call response result of each second interface to be evaluated in the pre-release environment and a second call response result in the formal release environment; finally, according to the first call response result and the second call response result corresponding to each second interface to be evaluated, the pre-release risk interface can be screened out from the plurality of second interfaces to be evaluated.

[0108] In this embodiment, the publishing environment can be regarded as a publishing carrier, such as publishing on a web page or on an app, while the pre-releasing environment is to build an environment as similar as possible to the publishing environment for final testing before the code is deployed to the production environment. The hardware configuration, network configuration, database and other services of the pre-releasing environment should be consistent with the production environment; in this way, risk assessment can be performed based on the response results in the two environments.

[0109] Specifically, the first call response result of any of the aforementioned second interfaces to be evaluated is the result of pulling the request parameters in the pre-release environment, that is, whether the content specified in the request parameters is pulled; similarly, the corresponding second call response result is the result of pulling the request parameters in the formal release environment; based on this, the first call response result and the second call response result of each second interface to be evaluated can be compared to obtain the comparison results of each second interface to be evaluated, and then, based on the comparison results, the pre-release risk interface can be determined from multiple second interfaces to be evaluated.

[0110] Optionally, for example, the comparison result of any second interface to be evaluated is that the call content is consistent or the call content is inconsistent (that is, whether the content pulled in the pre-release environment and the release environment is exactly the same). In this way, based on the comparison results of each second interface to be evaluated, the second interface to be evaluated whose comparison result is inconsistent call content can be screened out from multiple second interfaces to be evaluated to serve as the release risk interface.

[0111] After completing the interface risk assessment in the pre-release phase, the risk assessment in the release phase may be performed, and the process is shown in the following step S44e.

[0112] S44e. According to the call success rate of each target interface during the release phase, the target interface with a call success rate lower than the success rate threshold is selected from a number of target interfaces as the release risk interface; in this embodiment, if the call success rate is lower than the success rate threshold, the interface failure rate exceeds the threshold; at this time, in the formal release phase, the target interface with an interface failure rate exceeding the threshold can be used as the release risk interface; at the same time, for example, in the formal release phase, an alarm can also be issued for the release risk interface to promptly prompt the operation and maintenance personnel, and the process can be referred to Figure 3 shown.

[0113] After completing the interface risk assessment of the testing phase, pre-release phase and release phase through the aforementioned steps, a summarized risk interface can be obtained, and the process is shown in the following step S44f.

[0114] S44f. The risk interface is composed of the test risk interface, the pre-release risk interface and the release risk interface. In this embodiment, the test risk interface, the pre-release risk interface and the release risk interface can be used to generate a risk interface table, so as to intuitively display the risks of the interfaces affected by code changes at different stages. In this way, it is convenient for testers to understand the risk status of the affected interfaces and take corresponding maintenance measures in time.

[0115] Through the aforementioned steps S41 to S44 and their sub-steps, the present invention performs risk assessment on the affected interfaces by counting the number of interface accesses, which reveals the potential risks of interface changes, so that testers can clearly understand the actual online access conditions of these interfaces; in this way, the test strategy can be optimized on this basis, that is, for interfaces with wireless access records, relevant tests can be exempted, and for interfaces with low access volume, only basic functions need to be covered; finally, for interfaces with high access volume, it is necessary to deeply analyze the online interface request parameters and their frequency to gain insight into business usage, and formulate a detailed test plan accordingly.

[0116] At the same time, when the service enters the pre-release environment, testers can submit test applications. The system will then automatically build interface test cases based on the affected interfaces and high-frequency request parameters, and simultaneously access the pre-release environment and the formal environment. By comparing the response data of the two environments, the system generates detailed comparison results and summarizes the comparison of all interfaces to form a comprehensive test report. In this way, testers can comprehensively review the request performance of all affected interfaces in the two environments, and conduct in-depth troubleshooting for interfaces with differences.

[0117] When the service is officially launched, testers can use the access success rate data provided by the system to perform real-time and effective monitoring of the interface operation status while performing functional regression testing on the interface. This measure ensures the high stability and excellent performance of the service, and provides a solid guarantee for the continuous and stable operation of the system.

[0118] Therefore, through the interface risk assessment method based on online news traffic described in detail in the aforementioned steps S1 to S4, the present invention obtains the affected interfaces through automated means, so that testers can fully understand the scope of all affected interfaces; at the same time, risk assessment is performed in combination with the access volume data of the online interface, wherein this information can not only help testers accurately identify and exclude those abandoned or rarely used interfaces, thereby optimizing the allocation of test resources, but also enable them to more accurately assess the risks that may be brought about by interface changes, and then formulate more accurate and efficient test plans based on this.

[0119] Furthermore, the request parameters obtained by the present invention play a vital role in the pre-release stage. They are used to automatically construct requests and perform comparisons between environments, so that testers can instantly understand the actual performance and impact of the new version interface after the modification. This instant feedback mechanism greatly shortens the cycle of problem discovery and resolution, and improves testing efficiency and quality; in addition, by counting the interface access success rate, the present invention can continuously monitor the actual operating status of the interface after online release. This data provides an intuitive quantitative indicator for the stability and performance of the interface, ensuring that the service can continuously and stably provide users with high-quality service experience after going online; thus, the present invention innovatively introduces intelligent analysis technology and constructs an interface risk testing system, which reduces the ability requirements for testers, reduces the high dependence on personal experience, and significantly improves the efficiency and accuracy of the entire testing process; therefore, the present invention is very suitable for large-scale application and promotion.

[0120] like Figure 4 As shown, the second aspect of this embodiment provides a hardware device for implementing the interface risk assessment method based on online news traffic described in the first aspect of the embodiment, including:

[0121] The acquisition unit is used to obtain network request logs and code repositories for calling new media interfaces.

[0122] The interface selection unit is used to determine a plurality of target interfaces based on the code repository, wherein the plurality of target interfaces are used to represent interfaces that are affected by changes in the code in the code repository among all interfaces called by the new media.

[0123] The parsing unit is used to parse the network request log to obtain interface call information.

[0124] The risk assessment unit is used to perform risk assessment processing on the multiple target interfaces according to the target interface and the interface calling information, so as to screen out risk interfaces from the multiple target interfaces, and complete the risk assessment of the new media calling interface after obtaining the risk interface.

[0125] The working process, working details and technical effects of the device provided in this embodiment can be found in the first aspect of the embodiment and will not be described in detail here.

[0126] like Figure 5As shown, the third aspect of this embodiment provides another interface risk assessment device based on online news traffic. Taking the device as an electronic device as an example, it includes: a memory, a processor and a transceiver that are communicatively connected in sequence, wherein the memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer program to execute the interface risk assessment method based on online news traffic as described in the first aspect of the embodiment.

[0127] For example, the memory may include, but is not limited to, random access memory (RAM), read only memory (ROM), flash memory, first input first output (FIFO) and / or first in last out (FILO), etc. Specifically, the processor may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). At the same time, the processor may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state.

[0128] In some embodiments, the processor may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. For example, the processor may not be limited to a microprocessor of the STM32F105 series, a reduced instruction set computer (RISC) microprocessor, an X86 architecture processor, or a processor with an integrated embedded neural network processing unit (NPU); the transceiver may be, but is not limited to, a wireless fidelity (WIFI) wireless transceiver, a Bluetooth wireless transceiver, a general packet radio service technology (General Packet Radio Service, GPRS) wireless transceiver, a ZigBee protocol (a low-power local area network protocol based on the IEEE802.15.4 standard, ZigBee) wireless transceiver, a 3G transceiver, a 4G transceiver and / or a 5G transceiver, etc. In addition, the device may also include, but is not limited to, a power module, a display screen, and other necessary components.

[0129] The working process, working details and technical effects of the electronic device provided in this embodiment can be found in the first aspect of the embodiment and will not be described in detail here.

[0130] The fourth aspect of this embodiment provides a storage medium storing instructions for the interface risk assessment method based on online news traffic as described in the first aspect of the embodiment, that is, the storage medium stores instructions, and when the instructions are executed on a computer, the interface risk assessment method based on online news traffic as described in the first aspect of the embodiment is executed.

[0131] The storage medium refers to a carrier for storing data, which may include but is not limited to a floppy disk, a CD, a hard disk, a flash memory, a USB flash drive and / or a memory stick, and the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0132] The working process, working details and technical effects of the storage medium provided in this embodiment can be found in the first aspect of the embodiment and will not be described in detail here.

[0133] A fifth aspect of this embodiment provides a computer program product comprising instructions, which, when executed on a computer, causes the computer to execute the interface risk assessment method based on online news traffic as described in the first aspect of the embodiment, wherein the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0134] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. An interface risk assessment method based on online news traffic, characterized in that: include: Get network request logs and code repositories for new media API calls; Based on the code repository, a plurality of target interfaces are determined, wherein the plurality of target interfaces are used to represent interfaces that are affected by changes in the code in the code repository among all interfaces called by the new media; Parsing the network request log to obtain interface call information; According to the target interface and the interface calling information, risk assessment processing is performed on the several target interfaces to screen out risky interfaces from the several target interfaces, so as to complete the risk assessment of the new media calling interface after obtaining the risky interfaces.

2. According to claim 1, a method for assessing interface risk based on online news traffic is characterized in that: Based on the code repository, several target interfaces are identified, including: Parsing all codes in the code repository to obtain parsing results corresponding to each code, wherein the parsing result of any code includes a method corresponding to the code; According to the parsing results corresponding to each code, determine the calling method corresponding to each method; A call graph is constructed using the methods corresponding to each code and the calling methods corresponding to each method, wherein the call graph contains a number of nodes, each node represents a code method, and the nodes corresponding to two code methods with a calling relationship are connected by edges, and a code method is a method or a calling method; Filtering out target codes from the code repository, and parsing to obtain methods corresponding to the target codes as methods to be retrieved, wherein the target codes are codes that have changed in the code repository; Determine, from the call graph, a node having an edge connection relationship with the method to be retrieved, so as to obtain a call relationship corresponding to the target code based on the node having an edge connection relationship with the method to be retrieved; According to the calling relationship, the plurality of target interfaces are determined.

3. According to claim 1, a method for assessing interface risk based on online news traffic is characterized in that: The network request log includes log information of all interfaces called by the new media during the publishing phase, and the interface call information includes interface request data and interface response data of all interfaces called by the new media during the publishing phase; Among them, performing risk assessment processing on the plurality of target interfaces according to the target interface and the interface call information to screen out risky interfaces from the plurality of target interfaces includes: According to the interface request data and several target interfaces, the number of interface accesses of each target interface during the release phase is counted; Using the interface response data, the call success rate of each target interface during the release phase is calculated; Based on the interface request data, determining the request parameters and request frequency of each target interface during the publishing phase; According to the number of interface accesses corresponding to each target interface, the call success rate corresponding to each target interface, and the request parameters and request frequencies corresponding to each target interface, risky interfaces are screened out from the plurality of target interfaces.

4. According to claim 3, the interface risk assessment method based on online news traffic is characterized in that: According to the number of interface accesses corresponding to each target interface, the call success rate corresponding to each target interface, and the request parameters and request frequency corresponding to each target interface, a risk interface is screened out from the plurality of target interfaces, including: According to the number of interface accesses of each target interface in the release phase, target interfaces whose number of interface accesses is less than the minimum access frequency are removed from the plurality of target interfaces to obtain a plurality of first interfaces to be evaluated; Determining the risk level of each first interface to be evaluated according to the number of interface accesses of each first interface to be evaluated, wherein the higher the risk level, the greater the number of interface accesses; Based on the risk level of each first interface to be evaluated, screening out a test risk interface from the plurality of first interfaces to be evaluated; According to the call success rate of each target interface during the release phase, the target interface with a call success rate lower than the success rate threshold is selected from a number of target interfaces to serve as the release risk interface; Using the request parameters and request frequencies of each target interface during the release phase, interface risk assessment is performed on each target interface to screen out pre-release risk interfaces from a number of target interfaces; The risk interface is composed of the test risk interface, the pre-release risk interface and the release risk interface.

5. According to claim 4, a method for assessing interface risk based on online news traffic is characterized in that: Using the request parameters and request frequency of each target interface during the release phase, interface risk assessment is performed on each target interface to screen out pre-release risk interfaces from a number of target interfaces, including: Based on the request frequencies of the target interfaces, target interfaces whose request frequencies are lower than a frequency threshold are removed from the target interfaces to obtain a plurality of second interfaces to be evaluated; Obtain the pre-release environment and official release environment for interface deployment; Generate a first call request for each second interface to be evaluated according to the pre-release environment and the request parameters of each second interface to be evaluated, and generate a second call request for each second interface to be evaluated according to the formal release environment and the request parameters of each second interface to be evaluated; Using the first call request and the second call request of each second interface to be evaluated, calling each second interface to be evaluated, so as to obtain a first call response result of each second interface to be evaluated in the pre-release environment and a second call response result in the formal release environment; The pre-release risk interface is screened out from the plurality of second interfaces to be evaluated according to the first call response results and the second call response results corresponding to the respective second interfaces to be evaluated.

6. The interface risk assessment method based on online news traffic according to claim 5 is characterized in that: Screening out the pre-release risk interface from the plurality of second interfaces to be evaluated according to the first call response results and the second call response results corresponding to the respective second interfaces to be evaluated includes: Comparing the first call response result and the second call response result of each second interface to be evaluated, to obtain a comparison result of each second interface to be evaluated, wherein the comparison result of any second interface to be evaluated is that the call content is consistent or the call content is inconsistent; Based on the comparison results of the second interfaces to be evaluated, the second interfaces to be evaluated whose comparison results show inconsistent call contents are selected from the plurality of second interfaces to be evaluated to serve as the pre-release risk interface.

7. The interface risk assessment method based on online news traffic according to claim 1 is characterized in that: The network request log is parsed to obtain interface call information, including: Use regular expressions to parse the network request log to obtain interface request data and interface response data; The interface call information is generated using the interface request data and the interface response data.

8. An interface risk assessment device based on online news traffic, characterized in that: include: An acquisition unit, used to obtain network request logs and a code repository for calling new media interfaces; An interface selection unit, configured to determine a plurality of target interfaces based on the code repository, wherein the plurality of target interfaces are used to represent interfaces that are affected by changes in the code in the code repository among all interfaces called by the new media; A parsing unit, used for parsing the network request log to obtain interface call information; The risk assessment unit is used to perform risk assessment processing on the multiple target interfaces according to the target interface and the interface calling information, so as to screen out risk interfaces from the multiple target interfaces, and complete the risk assessment of the new media calling interface after obtaining the risk interface.

9. An electronic device, characterized in that: include: A memory, a processor and a transceiver which are sequentially communicatively connected, wherein the memory is used to store a computer program, the transceiver is used to send and receive messages, and the processor is used to read the computer program, and execute the interface risk assessment method based on online news traffic as described in any one of claims 1 to 7.

10. A computer program product comprising instructions, characterized in that When the instructions are executed on a computer, the computer is caused to execute the interface risk assessment method based on online news traffic as described in any one of claims 1 to 7.

Images