Interface call assertion monitoring method and computer equipment

Abstract

The invention relates to an interface calling assertion monitoring method and computer equipment. The method comprises the following steps: in response to a triggered interface calling instruction, generating a tracking address identifier of an interface; running a test code of the interface, and obtaining a test log and an interface response value generated in the running process of the test code; injecting the tracking address identifier into the test log and the interface response value, and binding the test log comprising the tracking address identifier with the interface response value comprising the tracking address identifier; according to the universal assertion and the self-defined assertion in the assertion library, assertion analysis is carried out on the test log and the interface response value which are bound with each other, and an assertion result of interface calling is obtained. By adopting the method, the accuracy of interface calling assertion can be improved.

Description

Technical Field

[0001] This application relates to the technical field of interface calls, and in particular, to an interface call assertion monitoring method and a computer device. Background Art

[0002] In high-concurrency or distributed transaction scenarios, a business request often needs to call multiple services through interfaces for collaborative operations. The collaborative process not only involves frequent interface calls but also multi-service interactions. Therefore, it is crucial to perform assertion monitoring on exceptions during the interface call process.

[0003] In the related art, when performing assertion monitoring on interface calls, usually after the test code of the interface is tested, an interface response value for the interface call is generated, and this interface response value indicates whether there are exceptions during the interface call process.

[0004] However, the assertion monitoring of the related art interface calls cannot effectively monitor the entire process of multi-service collaborative operations, resulting in difficulty in discovering hidden risks in interface calls and affecting the accuracy of interface call assertions. Summary of the Invention

[0005] Based on this, in view of the above technical problems, it is necessary to provide an interface call assertion monitoring method and a computer device that can improve the accuracy of interface call assertions.

[0006] In a first aspect, this application provides an interface call assertion monitoring method, including:

[0007] In response to a call instruction for an interface being triggered, generate a trace address identifier for the interface;

[0008] Run the test code of the interface and obtain the test log and interface response value generated during the running of the test code;

[0009] Inject the trace address identifier into the test log and interface response value, and bind the test log including the trace address identifier to the interface response value including the trace address identifier;

[0010] According to the general assertions and custom assertions in the assertion library, perform assertion analysis on the mutually bound test log and interface response value to obtain the assertion result of the interface call.

[0011] In one of the embodiments, according to the general assertions and custom assertions in the assertion library, performing assertion analysis on the mutually bound test log and interface response value to obtain the assertion result of the interface call includes:

[0012] According to the general assertions in the assertion library, perform exception identification on the test log to obtain an exception identification result;

[0013] If the anomaly recognition result indicates an anomaly, determine the assertion result of the interface call based on the interface request address, trace address identifier, and anomaly log;

[0014] If the anomaly recognition result indicates no anomaly, continue to perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call.

[0015] In one embodiment, perform anomaly recognition on the test log according to the general assertions in the assertion library to obtain the anomaly recognition result, including:

[0016] Based on the log recognition result of the test log, determine whether there is an abnormal assertion;

[0017] If there is no abnormal assertion, obtain the log level of the test log;

[0018] If the log level is a warning, continue to determine whether the warning in the test log belongs to the whitelist and whether the number of warnings in the test log is greater than the preset threshold;

[0019] If the warning in the test log is not in the whitelist and the number of warnings is greater than the preset threshold, determine that the anomaly recognition result is an anomaly.

[0020] In one embodiment, determine the assertion result of the interface call based on the interface request address, trace address identifier, and anomaly log, including:

[0021] If the anomaly recognition result is a result assertion anomaly, use the anomaly type description, interface request address, trace address identifier, and anomaly log as the assertion result of the interface call;

[0022] If the anomaly recognition result is a log level assertion anomaly, use the log level, interface request address, trace address identifier, and anomaly log as the assertion result of the interface call.

[0023] In one embodiment, continue to perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call, including:

[0024] Perform assertions on the response time of the interface response, loop statements in the test log, and test code coverage according to the general assertions in the assertion library to determine the general assertion analysis result;

[0025] Perform custom assertion analysis on the mutually bound test log and interface response value according to the custom assertions in the assertion library to obtain the custom assertion analysis result;

[0026] Use the general assertion analysis result and the custom assertion analysis result as the assertion result for interface calls.

[0027] In one embodiment, perform custom assertion analysis on the mutually bound test logs and interface response values to obtain a custom assertion analysis result, including:

[0028] Determine whether the interface request address is maintained in the custom assertions of the assertion library;

[0029] If not, configure the number of services and the number of database tables corresponding to the interface request address in the custom assertions;

[0030] According to the configured custom assertions, perform custom assertion analysis on the mutually bound test logs and interface response values to obtain a custom assertion analysis result.

[0031] In one embodiment, the custom assertion analysis includes at least one of the following cases:

[0032] Assert the integrity of the number of services including the trace address identifier;

[0033] Assert the consistency of database table operations including the trace address identifier;

[0034] Assert the consistency of parameters in the test logs;

[0035] Assert the correctness of the structured query language in the test logs;

[0036] Assert the correctness of the conditional filtering logic in the test logs;

[0037] Assert the reliability of implicit parameter passing.

[0038] In one embodiment, the method further includes:

[0039] During the process of running the test code of the interface, perform real-time coloring on the running test code;

[0040] According to the colored test code, calculate the test coverage rate of the test code;

[0041] If the test coverage rate is greater than the preset threshold, determine that the coverage test of the test code passes.

[0042] In one embodiment, calculating the test coverage rate of the test code according to the colored test code includes:

[0043] According to the version of the test code or the update time of the test code, filter out the updated part of the test code from the test code;

[0044] Calculate the test coverage of the test code for the updated part according to the coloring code in the test code for the updated part.

[0045] In a second aspect, the present application further provides an interface call assertion monitoring device, including:

[0046] A generation module, configured to generate a tracking address identifier for the interface in response to a call instruction for the triggered interface;

[0047] An acquisition module, configured to run the test code for the interface and acquire the test log and the interface response value generated during the running of the test code;

[0048] A binding module, configured to inject the tracking address identifier into the test log and the interface response value, and bind the test log including the tracking address identifier to the interface response value including the tracking address identifier;

[0049] An analysis module, configured to perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call.

[0050] In a third aspect, the present application further provides a computer device, including a memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, it implements the content of any one of the embodiments of the interface call assertion monitoring method in the first aspect above.

[0051] In a fourth aspect, the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the content of any one of the embodiments of the interface call assertion monitoring method in the first aspect above.

[0052] In a fifth aspect, the present application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, it implements the content of any one of the embodiments of the interface call assertion monitoring method in the first aspect above.

[0053] The above interface call assertion monitoring method and computer device generate a trace address identifier for an interface in response to a call instruction for the triggered interface; run the test code of the interface, and obtain the test log and interface response value generated during the running of the test code; inject the trace address identifier into the test log and interface response value, and bind the test log including the trace address identifier to the interface response value including the trace address identifier; perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call. Through the trace address identifier, this method can accurately associate multi-dimensional data such as test logs, response data, and performance metrics of interface calls. When a test fails, it is possible to quickly locate the complete test log directly through the trace address identifier, effectively monitor the entire process of multi-service collaborative operations, promptly discover hidden risks in interface calls, and improve the accuracy and efficiency of interface call assertions. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for the description of the embodiments of the present application or related technologies. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other related drawings can also be obtained based on these drawings.

[0055] Figure 1 It is an application environment diagram of the interface call assertion monitoring method in an embodiment;

[0056] Figure 2 It is a first process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0057] Figure 3 It is a second process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0058] Figure 4 It is a third process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0059] Figure 5 It is a fourth process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0060] Figure 6 It is a fifth process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0061] Figure 7 It is a sixth process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0062] Figure 8It is the seventh process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0063] Figure 9 It is the eighth process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0064] Figure 10 It is the ninth process schematic diagram of the interface call assertion monitoring method in an embodiment;

[0065] Figure 11 It is the process schematic diagram of the general assertion in an embodiment;

[0066] Figure 12 It is the process schematic diagram of obtaining the test coverage rate in an embodiment;

[0067] Figure 13 It is the schematic diagram of the efficiency improvement ratio in an embodiment;

[0068] Figure 14 It is the structural block diagram of the interface call assertion monitoring device in an embodiment. Specific embodiments

[0069] In order to make the purpose, technical solution and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0070] Before introducing the technical solution of the present application in detail, the background technology of the present application will be briefly introduced.

[0071] In high-concurrency or distributed transaction scenarios, a business request often needs to call multiple services through interfaces for collaborative operations. The collaborative process not only involves frequent interface calls but also multi-service interactions. Therefore, it is crucial to perform assertion monitoring on exceptions during the interface call process.

[0072] In the related art, when performing assertion monitoring on interface calls, usually after the test code of the interface is tested, the interface response value of the interface call will be generated, and this interface response value indicates whether there are exceptions during the interface call process.

[0073] However, the assertion monitoring of related technology interface calls cannot effectively monitor the entire process of multi-service collaborative operations, making it difficult to discover hidden risks in interface calls and affecting the accuracy of interface call assertions. At the same time, relying solely on the surface verification of interface response values lacks the ability to track the data flow path, intermediate state transaction consistency, and resource call link in real time, resulting in low efficiency in abnormal location. In addition, the low coverage rate of test case execution often leaves test blind spots and hidden accumulation of technical debt in the project. The coverage rate of incremental code in a version can be used as a standard to evaluate whether the test is sufficient. And the current test strategy lacks a quality evaluation system for the coverage rate threshold of newly added or changed code in iterations, resulting in the lack of measurement of incremental code coverage. Moreover, the existing test system has a blind spot in monitoring the SQL execution efficiency and lacks assertion interception for database performance anti-patterns such as slow queries, full table scans, and index misses.

[0074] In view of the above problems, the present application provides an interface call assertion monitoring method and a computer device. Based on the code coverage rate (code coloring and original requirements) of the requirements, code logic (performing code coverage analysis), interface calls (recording requests / responses, dependent service interactions), log output (capturing runtime states, exceptions, intermediate data), etc., dynamic intelligent assertions are implemented, which can improve the efficiency of anomaly detection. At the same time, through multi-dimensional validations including interface return value assertions (assertions in related technologies), process data assertions (such as transmission data errors, database changes, message queues, cache states), link consistency assertions (logical closed-loop verification of requirements, code, interfaces, test cases, and logs), and coverage rate assertions (combining execution path analysis, identifying uncovered logical branches, and supplementing assertions), it can ensure that the process of anomaly detection is more comprehensive and the obtained assertion results will be more accurate. By coloring the test code during the running process, the incremental code coverage rate can be visually viewed, providing a basis for subsequent optimization processes. In addition, adding assertions for SQL statements to the assertion library can reduce the monitoring blind spots of test assertions. Next, the detailed content of the interface call assertion monitoring method will be introduced.

[0075] The interface call assertion monitoring method provided by the embodiments of the present application can be applied to, for example Figure 1In the application environment shown. For example, the computer device can be a server, a personal computer, a laptop computer, a smart phone, a tablet computer, a smart mobile phone, etc. The computer device may include a processor, a memory, and a network interface connected by a system bus or wirelessly. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device may include a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data during the interface call assertion monitoring process. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it implements an interface call assertion monitoring method. Among them, the computer device can be implemented by an independent computer device or a computer device cluster composed of multiple computer devices. It should be noted that the memory of the computer device is not limited to the above-mentioned memory, and may also include a high-speed random access memory, a volatile solid-state memory, and so on. In addition, the composition architecture of the computer device is not limited to the above situation, and some components can also be added or omitted.

[0076] In an exemplary embodiment, as Figure 2 shown, a method for monitoring interface call assertions is provided. Taking the computer device in Figure 1 as an example, the method includes the following steps 101 to 104. Among them:

[0077] S101, in response to a trigger of an interface call instruction, generate a trace address identifier for the interface.

[0078] In the embodiments of the present application, the interface call instruction can be triggered by a user clicking a certain function button or initiating a data query request, or can also be triggered by an internal timing task, or can also be triggered by an external event linkage.

[0079] After receiving the triggered interface call instruction, the computer device can parse the interface call instruction, extract the key information in the call instruction, and record information such as the time of the interface call and the Internet Protocol Address (IP). Among them, the key information can be the identity information of the caller, the interface name, and the interface request parameters, etc. Taking the interface call of user login as an example, the parsed information may include the user name, password, and client device type, etc.

[0080] After that, according to the pre-set generation method, the computer device generates a tracking address identifier by using the key information obtained through parsing. For example, the pre-set generation method can be a method based on the combination of a timestamp and a random number, a method generated by a hashing algorithm, etc.

[0081] After generating the tracking address identifier of the interface, the computer device can also perform a uniqueness check on the identifier to ensure that the identifier has not been used in the current system. The check method can be to query the tracking address identifiers already existing in the database. If a duplicate is found, the tracking address identifier is regenerated until the tracking address identifier of the interface is obtained.

[0082] S102, run the test code of the interface, and obtain the test log and the interface response value generated during the running of the test code.

[0083] In the embodiments of the present application, in order to record the detailed information during the running of the test code, it is necessary to configure the log recording function. Specifically, before the test code is executed, configuration information such as the log level, output format, and storage path needs to be executed. During the test, when the test code is integrated into the automated test framework, the test code can be started to run. During the running of the test code, the test log can record the information generated during the running of the test code. After the test is completed, the interface response value is output.

[0084] S103, inject the tracking address identifier into the test log and the interface response value, and bind the test log including the tracking address identifier to the interface response value including the tracking address identifier.

[0085] In the embodiments of the present application, the computer device can inject the tracking address identifier during the execution life cycle of the test case of the test framework through Aspect-Oriented Programming (AOP) technology. At the same time, the response is intercepted uniformly at the interface processing layer, and the tracking address identifier of the current request is added to the interface response value. In this way, the test log can be bound to the interface response value through the tracking address identifier.

[0086] S104, perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library, and obtain the assertion result of the interface call.

[0087] Among them, the general assertions in the assertion library refer to common assertion rules, and the custom assertions are assertions determined based on the interface call scenario.

[0088] In the embodiments of the present application, the computer device may first perform general assertion analysis on the mutually bound test log and interface response value according to the general assertions in the assertion library to obtain a general assertion analysis result. When the general assertion analysis result meets the preset conditions, then perform custom assertion analysis on the mutually bound test log and interface response value according to the custom assertions in the assertion library to obtain a custom assertion analysis result.

[0089] In the above interface call assertion monitoring method, in response to the call instruction of the triggered interface, generate a trace address identifier for the interface; run the test code of the interface, and obtain the test log and interface response value generated during the running of the test code; inject the trace address identifier into the test log and interface response value, and bind the test log including the trace address identifier to the interface response value including the trace address identifier; perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call. Through the trace address identifier, this method can accurately associate multi-dimensional data such as the test log, response data, and performance metrics of the interface call. When a test fails, directly locate the complete test log quickly through the trace address identifier, which can effectively monitor the entire process of multi-service collaborative operation, can timely discover hidden risks in interface calls, and improve the accuracy and efficiency of interface call assertions.

[0090] In one embodiment, as Figure 3 shown, performing assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call includes:

[0091] S201, perform anomaly recognition on the test log according to the general assertions in the assertion library to obtain an anomaly recognition result.

[0092] In the embodiments of the present application, the general assertions include anomaly recognition of the test log, performance assertion, and code coverage assertion. There is a chronological order among the three assertion processes. Therefore, anomaly recognition of the test log is performed first. Specifically, during the recognition process, the computer device may first determine whether there is an anomaly in the test log. If there is, determine that the anomaly recognition result is that there is an anomaly. If there is no anomaly, then determine whether there is an error log in the test log. If there is, determine that the anomaly recognition result is that there is an anomaly. If not, continue to determine whether there is an alarm log. If there is, continue to determine whether the alarm log belongs to the whitelist, and determine whether the number of alarm logs is greater than the preset threshold. If it does not belong to the whitelist and the number of logs is greater than the preset threshold, then determine that the anomaly recognition result is that there is an anomaly; if it belongs to the whitelist, or the number of logs is small, then determine that the anomaly recognition result is that there is no anomaly.

[0093] S202, if the anomaly recognition result is that an anomaly exists, determine the assertion result of the interface call based on the interface request address, trace address identifier, and anomaly log.

[0094] In the embodiments of the present application, when it is determined that the anomaly recognition result is that an anomaly exists, the controller can determine the assertion result of the interface call according to the cause of the anomaly. Specifically, if the anomaly recognition result is a result assertion anomaly, use the anomaly type description, interface request address, trace address identifier, and anomaly log as the assertion result of the interface call; if the anomaly recognition result is a log level assertion anomaly, use the log level, interface request address, trace address identifier, and anomaly log as the assertion result of the interface call.

[0095] S203, if the anomaly recognition result is that no anomaly exists, continue to perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call.

[0096] In the embodiments of the present application, if it is determined that the anomaly recognition result is that no anomaly exists, first perform general assertion analysis on the mutually bound test log and interface response value in sequence according to the performance assertion and code coverage assertion in the general assertions. After the general assertion analysis is completed, then perform custom assertion analysis on the mutually bound test log and interface response value according to the custom assertions to obtain the assertion analysis result of the interface call.

[0097] In the above interface call assertion monitoring method, anomaly recognition is performed on the test log according to the general assertions in the assertion library to obtain the anomaly recognition result; if the anomaly recognition result is that an anomaly exists, determine the assertion result of the interface call based on the interface request address, trace address identifier, and anomaly log; if the anomaly recognition result is that no anomaly exists, continue to perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call. This method can more effectively discover problems in interface calls and improve the stability and reliability of the interface through comprehensive analysis of the test log and assertion processing in different situations.

[0098] In one embodiment, as Figure 4 shown, introduce the specific content of the above anomaly recognition of the test log according to the general assertions in the assertion library to obtain the anomaly recognition result. The specific content includes:

[0099] S301, based on the log recognition result of the test log, determine whether there is an anomaly assertion.

[0100] In the embodiments of the present application, the computer device can intercept exceptions in the test results through AOP technology, or parse the exception stack in the test results, or can also be integrated with the assertion mechanism in the test framework to embed exception assertions into the test cases to determine the log recognition result of the test log.

[0101] After obtaining the log recognition result, compare the log recognition result of the test log with common exception types. If the log recognition result belongs to a common exception type, it can be determined that there is an exception assertion; if the log recognition result does not belong to a common exception type, it can be determined that there is no exception assertion. If it is determined that there is an exception assertion, use the exception assertion analysis result as the assertion result of the interface call.

[0102] In one embodiment, if the exception recognition result is a result assertion exception, use the exception type description, interface request address, trace address identifier, and exception log as the assertion result of the interface call. And there is no need to perform subsequent judgment steps. The exception assertion analysis result includes: exception type + interface request address + trace address identifier + exception test log.

[0103] It can be understood that the exception assertion rule set includes exception types, detection scenarios, and corresponding processing strategies. The exception types can include four types: null pointer exception, mainly used in null pointer reference scenarios, and the corresponding processing strategy is: immediately prompt failure and prompt the null object location; data truncation exception, mainly used in database field truncation scenarios, and the corresponding processing strategy is: fail and record the details of the truncated data; connection refused exception, mainly used in microservice / database connection failure scenarios, and the corresponding processing strategy is: fail and mark the dependent service as unavailable; index out-of-bounds exception, mainly used in array / collection out-of-bounds scenarios, and the corresponding processing strategy is: fail and output the out-of-bounds index value.

[0104] S302, if there is no exception assertion, obtain the log level of the test log.

[0105] Among them, the log levels include error and warning. The trigger condition for error is the appearance of any "ERROR" log, and the corresponding processing logic is: immediately fail and associate the trace address identifier to locate the exception. The trigger condition for warning is that the number of "WARNING" occurrences for the same interface request exceeds a preset number (for example, 3 times), and the corresponding processing logic is: mark as failed.

[0106] In the embodiments of the present application, in the case of determining that there is no exception assertion, continue with subsequent judgment, that is, judge whether there is an error or warning in the test log to determine the log level of the test log. It should be noted here that if "ERROR" and "WARNING" appear in the test log, it is determined that the log level of the test log is error.

[0107] If the log level of the test log is an error, there is no need to continue with the subsequent judgment steps, and it is determined that the anomaly recognition result is that there is an anomaly.

[0108] In one embodiment, if the anomaly recognition result is a log level assertion anomaly, the log level, the interface request address, the trace address identifier, and the anomaly log are used as the assertion result of the interface call. That is, the analysis result of the log level assertion includes: log level + interface request address + trace address identifier + anomaly test log.

[0109] S303, if the log level is a warning, continue to determine whether the warnings in the test log belong to the whitelist, and determine whether the number of warnings in the test log is greater than a preset threshold.

[0110] In the embodiment of the present application, when it is determined that the log level is a warning, it is also necessary to determine whether the warnings in the test log belong to the whitelist, so as to avoid misjudgment of warnings that have no impact on the anomaly result (for example, cache penetration). Before determining whether the warnings in the test log belong to the whitelist, the test logs not triggered by the current test can also be filtered based on the trace address identifier to avoid the influence of the test logs not triggered by the current test on the judgment result.

[0111] During the judgment process, the computer device can compare the warnings in the test log with the warnings in the whitelist to determine whether the warnings in the test log belong to the whitelist. If all the warnings in the test log belong to the whitelist, continue with the subsequent judgment steps. If none of the warnings in the test log belong to the whitelist, or some of the warnings in the test log do not belong to the whitelist, count the number of warnings that do not belong to the whitelist, and then determine whether the counted number exceeds the preset threshold, that is, determine whether the number of warnings in the test log is greater than the preset threshold.

[0112] If the warnings in the test log belong to the whitelist, or the number of warnings is less than or equal to the preset threshold, continue with the subsequent judgment steps.

[0113] S304, if the warnings in the test log are not in the whitelist and the number of warnings is greater than the preset threshold, determine that the anomaly recognition result is that there is an anomaly.

[0114] In the embodiment of the present application, when it is determined that the warnings in the test log are not in the whitelist and the number of warnings is greater than the preset threshold, it means that the number of warnings not in the whitelist is too large, and it can be determined that the anomaly recognition result is that there is an anomaly.

[0115] In the above interface call assertion monitoring method, based on the log recognition result of the test log, it is determined whether there is an abnormal assertion; if there is no abnormal assertion, the log level of the test log is obtained; if the log level is a warning, it is further determined whether the warning in the test log belongs to the whitelist, and whether the number of warnings in the test log is greater than a preset threshold; if the warning in the test log is not in the whitelist and the number of warnings is greater than the preset threshold, it is determined that the abnormal recognition result is that there is an abnormality. This method conducts multi-level and multi-dimensional analysis and judgment on the test log. First, it determines whether there is an abnormal assertion. If not, it further analyzes the specific situation when the log level is a warning, comprehensively considering aspects such as whether the warning is in the whitelist and whether the number of warnings is greater than the preset threshold, and can accurately identify the real abnormal situation, effectively avoiding misjudging normal warning information as abnormal, and greatly improving the accuracy of the test result.

[0116] In the case where the abnormal recognition result is that there is no abnormality, in one embodiment, as Figure 5 shown, the specific content of the above-mentioned continued assertion analysis of the mutually bound test log and interface response value according to the general assertion and custom assertion in the assertion library to obtain the assertion result of the interface call is introduced. The specific content includes:

[0117] S401, according to the general assertion in the assertion library, assert the time of the interface response, the loop statement in the test log, and the code coverage of the test code, and determine the general assertion analysis result.

[0118] In the embodiment of the present application, the assertion rule for the time of the interface response is: when the time of the interface response is greater than the first preset time threshold (for example, T1 = 1s), log data such as the trace address identifier, request parameters, response parameters, and accurate elapsed time of the interface response is recorded.

[0119] Perform millisecond-level time series monitoring on the execution time of sql statements (including but not limited to insert, update, delete, and query). When the statement execution time is greater than the second preset time threshold (for example, T1 = 10ms), it is marked as a slow query, and the trace address identifier and context information are recorded. Among them, the first preset time threshold and the second preset time threshold can be dynamically corrected. The computer device can use the same trace address identifier in the test log as the grouping dimension, sort the test log in ascending order. Use a time window to obtain the time boundary, and subtract the execution time of the first test log from the time of the last test log to obtain the sql statement execution time.

[0120] The assertion rule for loop statements is as follows: Obtain SQL execution statements within a certain time range. When the content of other execution statements except parameters is matched as the same, it is determined as an interface loop call. It mainly includes three key steps: (1) Data collection and preprocessing: ① Database proxy mode: Capture complete SQL statements by deploying database middleware; ② Driver layer interception: Record execution statements through database connection standard driver extension; ③ Database audit log. The collected metadata can include information such as timestamp, original SQL statement, thread address, client address, session address, etc. (2) Normalization processing engine. The hash algorithm can be used for data normalization processing to remove parameter information therein, and generate a unique identifier (fingerprint) based on the processed SQL structure, which can be used in scenarios such as SQL statement structure similarity judgment. (3) Real-time detection algorithm. Configure the length of the sliding window as T = 5 minutes (dynamically adjustable), and the sliding step as 1 minute.

[0121] The computer device can identify loop statements through an SQL parser, determine the optimization points in the loop statements, and suggest output. At the same time, further complete optimization detection through tools such as an extensible database, slow query log, and index recommendation engine.

[0122] Specifically, the optimization detection rules in loop statements include: Detect query (e.g., SELECT *) statements, compare table structure metadata to identify unused fields, and the optimization direction is redundant field query, for example, it is recommended to explicitly list the required fields; Detect and analyze constant true / false expressions (e.g., WHERE 1 = 1) in the specified query condition (WHERE) statement, and the optimization direction is invalid conditions, for example, detect SQL injection risks or invalid filtering conditions; Check multi-table queries without conditions, and the optimization direction is Cartesian product risk, for example, warn about the missing association condition; Detect and identify type mismatches between fields and values in the WHERE statement, and the optimization direction is implicit type conversion, for example, avoid index failure and prompt explicit type conversion; Detect deep paging problems, and the optimization direction is paging optimization, for example, it is recommended to use cursor paging.

[0123] The optimization detection rule set combined with extension tools includes: Compare the fields in the condition with the actual database index, and the optimization direction is index missing, mainly relying on database metadata; Parse (EXPLAIN) the output, combine with the Abstract Syntax Tree (AST) to locate high-cost operations (such as full table scan), and the optimization direction is execution plan analysis, mainly relying on the database execution plan; Analyze the filtering conditions in the WHERE statement and data statistical information, and the optimization direction is hot and cold data distribution, mainly relying on the data distribution histogram; Detect the same SQL template repeatedly called in the loop (requiring combined call stack analysis), and the optimization direction is the N + 1 query problem.

[0124] S402. According to the custom assertions in the assertion library, perform custom assertion analysis on the mutually bound test log and interface response value to obtain the custom assertion analysis result.

[0125] Among them, the custom assertions in the assertion library are determined based on the call scenarios of the interfaces.

[0126] In the embodiment of the present application, after obtaining the test log and interface response value, the computer device can clean the data in the test log and interface response value to remove duplicate and invalid data. Then read the custom assertion rules from the assertion library, perform assertions on the test log or interface response value based on each assertion rule, and after obtaining the assertion results corresponding to each assertion rule, fuse the assertion results of all assertion rules to obtain the custom assertion analysis result.

[0127] S403. Use the general assertion analysis result and the custom assertion analysis result as the assertion result of the interface call.

[0128] In the embodiment of the present application, after obtaining the general assertion analysis result and the custom assertion analysis result, both analysis results can be used as the assertion result of the interface call. And display it to the user in a visual way.

[0129] In the above interface call assertion monitoring method, according to the general assertions in the assertion library, perform assertions on the response time of the interface, the loop statements in the test log, and the coverage rate of the test code to determine the general assertion analysis result; according to the custom assertions in the assertion library, perform custom assertion analysis on the mutually bound test log and interface response value to obtain the custom assertion analysis result; use the general assertion analysis result and the custom assertion analysis result as the assertion result of the interface call. This method performs general assertions on the interface response time, test log loop statements, and test code coverage rate, and at the same time combines custom assertions on the bound test log and interface response value to comprehensively detect the interface call from multiple key dimensions, greatly improving the comprehensiveness and accuracy of anomaly detection.

[0130] Next, through an embodiment, the specific content of the above-mentioned custom assertion analysis of the mutually bound test log and interface response value to obtain the custom assertion analysis result will be introduced. As Figure 6 shown, the specific content includes:

[0131] S501. Determine whether the interface request address is maintained in the custom assertions in the assertion library.

[0132] In an embodiment of the present application, after obtaining the general assertion analysis result, the computer device can read the custom assertion from the assertion library in the distributed database according to the interface request address. Then, the interface request address is matched with the keys in the custom assertion library. When it is determined that the interface request address does not exist in the custom assertion in the assertion library, it is determined that the interface request address is not maintained in the custom assertion in the assertion library. When it is determined that the address exists in the custom assertion library, the custom assertion analysis of the mutually bound test log and the interface response value is directly performed according to the configured custom assertion to obtain the custom assertion analysis result.

[0133] S502. If not, configure the number of services and the number of database tables corresponding to the interface request address in the custom assertion.

[0134] In an embodiment of the present application, when it is determined that the interface request address is not maintained in the custom assertion in the assertion library, it is necessary to determine the number of services associated with the interface (for example, 2 services including payment service and reconciliation service) and the database table data (for example, 2 tables including payment record table and transaction flow table) based on the interface call scenario and the test code. And set the number of services associated with the interface and the database table data in the custom assertion in the assertion library.

[0135] S503. Perform custom assertion analysis on the mutually bound test log and the interface response value according to the configured custom assertion to obtain the custom assertion analysis result.

[0136] In one embodiment, the custom assertion analysis includes at least one of the following situations:

[0137] The assertion includes tracking the integrity of the number of services identified by the trace address;

[0138] The assertion includes tracking the consistency of database table operations identified by the trace address;

[0139] The assertion tests the consistency of parameters in the test log;

[0140] The assertion tests the correctness of the structured query language in the test log;

[0141] The assertion tests the correctness of the conditional filtering logic in the test log;

[0142] The assertion tests the reliability of implicit parameter passing.

[0143] Among them, the assertion of the integrity of service data is mainly used to verify the integrity of the service call chain. The rule is: after the microservice test case is executed, the associated trace address identifier should cover the expected number of services. If the number of services decreases, it is determined that the assertion fails.

[0144] Database table operation assertions are mainly used to ensure that data layer operations meet expectations. The rule is: after the test case is executed, the database table operations (such as queries, inserts) associated with the trace address identifier need to be consistent with the expected set. If there is an inconsistency, the assertion is determined to fail.

[0145] Log parameter assertions are mainly used to verify the consistency between business logic and data. The rule is: the number and value of parameters in the test log need to match the input parameters of the test case.

[0146] Structured Query Language assertions are mainly used to verify the correctness of test composite logic. The rule is: for scenarios that need to meet multiple conditions (such as permission verification scenarios), verify the condition combination through the SQL statements associated with the trace address identifier.

[0147] Condition filtering assertions are mainly used to ensure the accuracy of condition filtering logic. The rule is: verify whether specific business conditions are met (for example, only allowing customers who have not been deleted to place orders). Retrieve whether the expected condition statements are included in the test log by tracing the address identifier.

[0148] Implicit parameter passing assertions are mainly used to ensure the reliability of implicit parameter passing. The rule is: verify whether the parameters automatically passed by the backend (such as the parameters generated based on the account address during login) meet the expected values.

[0149] It should be noted that the priority of custom assertions is higher than that of general assertions. For example, for interfaces with long response times, a custom assertion time threshold can be configured. When the interface response time is between the general assertion threshold and the custom assertion threshold, assertion exceptions will not be output.

[0150] In the above interface call assertion monitoring method, determine whether the interface request address is maintained in the custom assertion of the assertion library; if not, configure the number of services and the number of database tables corresponding to the interface request address in the custom assertion; according to the configured custom assertion, perform custom assertion analysis on the mutually bound test log and interface response value to obtain the custom assertion analysis result. This method performs customized assertion analysis for each interface request address according to the actual number of associated services and database tables, can more carefully detect anomalies during the interaction between the interface and various components of the system, and avoid misjudgment or missed judgment caused by not considering the specific business background of the interface, significantly improving the accuracy of the test results.

[0151] The above embodiments are all processes of asserting the test log and the interface return value. During the running process of the test code, the test code can also be dyed. In one embodiment, as Figure 7 shown, this method further includes:

[0152] S601. During the process of running the test code of the interface, perform real-time coloring processing on the running test code.

[0153] In the embodiments of the present application, the computer device can use code coloring technology to perform real-time coloring processing on the test code during the running process of the test code. In this way, the execution position of the test code can be visually observed through the color of the test code. Among them, the code coloring technology can be the just-in-time mode (On-the-fly) of dynamically modifying bytecode during class loading, or the offline mode (Offline) of inserting probes through a build tool during compilation truncation.

[0154] S602. Calculate the test coverage rate of the test code according to the colored test code.

[0155] Among them, the test coverage rate of the test code refers to the proportion of the running part of the test code.

[0156] In the embodiments of the present application, the computer device can obtain the data volume of the colored test code, calculate the ratio of the data volume of the colored test code to the data volume of all test codes, and use this ratio as the test coverage rate of the test code. For example, the test coverage rate can be 70%.

[0157] In one case, it is also possible to calculate the test coverage rate of the newly added or changed test code in the test code. Then, in one embodiment, as Figure 8 shown, the specific content of calculating the test coverage rate of the test code according to the colored test code includes:

[0158] S701. Screen out the updated part of the test code from the test code according to the version of the test code or the update time of the test code.

[0159] In the embodiments of the present application, the computer device can determine the code differences between the test code of the latest version and the test code of other versions according to the comparison between the versions of the test code, and use the test code with code differences as the updated part of the test code. Or, the computer device can also determine the code differences between the test code at the latest update time and the test code at other times according to the update time of the test code, and use the test code with code differences as the updated part of the test code.

[0160] S702. Calculate the test coverage rate of the updated part of the test code according to the colored code in the updated part of the test code.

[0161] In an embodiment of the present application, after obtaining the test code of the updated part, the computer device can determine the coloring code in the test code of the updated part, calculate the ratio of the coloring code to the test code of the updated part, and use this ratio as the test coverage rate of the test code of the updated part.

[0162] S603. If the test coverage rate is greater than the preset threshold, it is determined that the coverage test of the test code passes.

[0163] In an embodiment of the present application, after obtaining the test coverage rate, the computer device can also compare the test coverage rate with the preset threshold. When it is determined that the test coverage rate is greater than the preset threshold, the execution process of the code during the test is relatively perfect, and it is determined that the coverage test of the test code passes. When it is determined that the test coverage rate is less than or equal to the preset threshold, the execution process of the code during the test is not perfect, and it can be determined that the coverage test of the test code fails.

[0164] In the above interface call assertion monitoring method, during the process of running the test code of the interface, real-time coloring processing is performed on the running test code; according to the colored test code, the test coverage rate of the test code is calculated; if the test coverage rate is greater than the preset threshold, it is determined that the coverage test of the test code passes. By performing real-time coloring on the test code, testers can synchronously observe which code paths have been executed and which have not been covered during the test execution process, and can also calculate the test coverage rate of the test code more accurately.

[0165] In a detailed embodiment, as Figure 9 shown, the interface call assertion monitoring method includes:

[0166] S801. In response to the call instruction of the triggered interface, generate a trace address identifier for the interface;

[0167] S802. Run the test code of the interface and obtain the test log and the interface response value generated during the running process of the test code;

[0168] S803. Inject the trace address identifier into the test log and the interface response value, and bind the test log including the trace address identifier to the interface response value including the trace address identifier;

[0169] S804. According to the general assertions in the assertion library, based on the log recognition result of the test log, determine whether there is an abnormal assertion;

[0170] S805. If there is no abnormal assertion, obtain the log level of the test log;

[0171] S806, if the log level is a warning, continue to determine whether the warning in the test log belongs to the whitelist, and determine whether the number of warnings in the test log is greater than a preset threshold;

[0172] S807, if the warning in the test log is not in the whitelist and the number of warnings is greater than the preset threshold, determine that the anomaly recognition result is that there is an anomaly;

[0173] S808, based on the interface request address, the trace address identifier, and the anomaly log, determine the assertion result of the interface call;

[0174] S809, if the warning in the test log is in the whitelist, or the number of warnings is less than or equal to the preset threshold, if the anomaly recognition result is that there is no anomaly;

[0175] S810, according to the general assertions in the assertion library, assert the response time of the interface, the loop statements in the test log, and the code coverage of the test code to determine the general assertion analysis result;

[0176] S811, determine whether the interface request address is maintained in the custom assertions in the assertion library;

[0177] S812, if not, configure the number of services and the number of database tables corresponding to the interface request address in the custom assertions;

[0178] S813, according to the configured custom assertions, perform custom assertion analysis on the mutually bound test log and interface response value to obtain the custom assertion analysis result;

[0179] S814, use the general assertion analysis result and the custom assertion analysis result as the assertion result of the interface call.

[0180] Figure 10It is a schematic flow diagram of an interface call assertion monitoring method, and the method includes: S11: generating a tracking address identifier of the interface in response to an interface call instruction triggered by the call of the interface; S12: running the test code of the interface and obtaining the test log and interface response value generated during the running of the test code; S13: injecting the tracking address identifier into the test log and interface response value, and binding the test log including the tracking address identifier to the interface response value including the tracking address identifier; S14: performing an assertion on the mutually bound test log and interface response value according to a general assertion to obtain a general assertion result; S15: judging whether the interface request address is maintained in the assertion library, if so, executing step S17, if not, executing step S16; S16: configuring the number of services and the number of database tables corresponding to the interface in the assertion library; S17: judging whether the custom assertion is successful, if so, executing step S18, if not, executing step S19; S18: the page displays success; S19: displaying the general assertion result and the custom assertion result as the assertion result.

[0181] Figure 11 It is a schematic flow diagram of a general assertion, and the process includes: S21: responding to the triggered interface call; S22: judging whether there is an exception judgment, if so, executing step S24, if not, executing step S23; S23: ending the assertion execution, and the assertion result is expressed as: interface request address + tracking address identifier + exception type + exception log; S24: judging whether the log level: error appears, if so, executing step S25, if not, executing step S26; S25: ending the assertion execution, and the assertion result is expressed as: interface request address + tracking address identifier + error test log; S26: judging whether there is an alarm log, if so, executing step S27, if not, executing step S30; S27: judging whether the alarm log is in the white list, if so, executing step S30, if not, executing step S28; S28: judging whether the number of alarm logs is greater than a preset threshold (N), if so, executing step S29, if not, executing step S30; S29: ending the assertion execution: interface request address + tracking address identifier + alarm test log. S30: judging whether the interface response time is greater than T1, if so, executing step S31, if not, executing step S32; S31: recording the interface response time on the interface request address and highlighting it in red; S32: judging whether the execution time of a single sql statement is greater than T2, if so, executing step S33, if not, executing step S34; S33: recording the displacement tracking address identifier + timeout log on the interface request address; S34: judging within the time interval Inside, check if the number of SQL statement loops is greater than n. If so, execute step S35; if not, execute step S36. S35: Record the displacement tracking address identifier + SQL loop statement on the interface request address. S36: Determine if the SQL statement meets the rule set. If so, execute step S38; if not, execute step S37. S37: Record the displacement tracking address identifier + SQL loop statement + the reason for not meeting the rule set on the interface request address. S38: Determine if the incremental code coverage rate is greater than N%. If so, execute step S40; if not, execute step S39. S39: Output the request code + requirement coverage rate. S40: The general assertion is completed, and the custom assertion starts.

[0182] Figure 12 It is a schematic diagram of the process for obtaining the test coverage rate. This process includes: S41: Respond to the triggered interface call. S42: During the process of running the test code of the interface, perform real-time coloring processing on the running test code. S43: According to the version of the test code or the update time of the test code, filter out the updated part of the test code from the test code. S44: Calculate the test coverage rate of the updated part of the test code based on the coloring code in the updated part of the test code. S45: Determine if the test coverage rate is greater than the preset threshold. If so, execute step S47; if not, execute step S46. S46: Output the test coverage rate and display the document information of the uncovered code, and determine that the assertion fails. S47: Output the test coverage rate and determine that the assertion passes.

[0183] Figure 13 It is a schematic diagram of the efficiency improvement ratio. The abscissa in the figure is the index, and the ordinate is the percentage. Through the interface call assertion monitoring method provided by this application, the test log, test link, and index problems are bound through the tracking address identifier, resulting in a 70% improvement in the problem location efficiency. By automating assertions to cover scenarios that are difficult to verify by traditional means, the test coverage rate is increased by 60%. By using intelligent baseline alarms to reduce false alarms and shorten the average repair time, the operation and maintenance cost is reduced by 50%. The automated execution and manual execution of test cases can share the same assertion library. And the system contains general assertion configurations and automatically records the execution results, reducing the maintenance time of the test case assertion library by 35%. Monitor abnormal results through log intelligence. Reduce the probability of abnormal ignoring, improving the abnormal detection ability by 40%. Automatically detect performance problems and prompt to improve the code performance, resulting in a 25% performance improvement.

[0184] It should be understood that although the steps in the flowcharts involved in the above embodiments are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise clearly stated in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0185] Based on the same inventive concept, an embodiment of the present application also provides an interface call assertion monitoring device for implementing the interface call assertion monitoring method described above. The implementation solution provided by this device to solve problems is similar to the implementation solution described in the above method. Therefore, the specific limitations in one or more embodiments of the interface call assertion monitoring device provided below can refer to the limitations on the interface call assertion monitoring method in the above text, and will not be repeated here.

[0186] In an exemplary embodiment, as Figure 14 shown, an interface call assertion monitoring device is provided, including: a generation module 11, an acquisition module 12, a binding module 13, and an analysis module 14, where:

[0187] The generation module 11 is configured to generate a trace address identifier of the interface in response to a trigger of an interface call instruction;

[0188] The acquisition module 12 is configured to run the test code of the interface and acquire the test log and the interface response value generated during the running of the test code;

[0189] The binding module 13 is configured to inject the trace address identifier into the test log and the interface response value, and bind the test log including the trace address identifier to the interface response value including the trace address identifier;

[0190] The analysis module 14 is configured to perform assertion analysis on the mutually bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call.

[0191] In an exemplary embodiment, the above analysis module includes: an exception recognition unit, a determination unit, and an analysis unit, where:

[0192] The exception recognition unit is configured to perform exception recognition on the test log according to the general assertions in the assertion library to obtain an exception recognition result;

[0193] A determination unit, configured to, when the anomaly recognition result indicates the existence of an anomaly, determine the assertion result of the interface call based on the interface request address, the trace address identifier, and the anomaly log;

[0194] An analysis unit, configured to, when the anomaly recognition result indicates the non - existence of an anomaly, continue to perform assertion analysis on the mutually - bound test log and the interface response value according to the general assertions and custom assertions in the assertion library, and obtain the assertion result of the interface call.

[0195] In an exemplary embodiment, the above - mentioned anomaly recognition unit is further configured to, based on the log recognition result of the test log, determine whether there is an abnormal assertion; if there is no abnormal assertion, obtain the log level of the test log; if the log level is a warning, continue to determine whether the warning in the test log belongs to the whitelist, and determine whether the number of warnings in the test log is greater than a preset threshold; if the warning in the test log is not in the whitelist and the number of warnings is greater than the preset threshold, determine that the anomaly recognition result is the existence of an anomaly.

[0196] In an exemplary embodiment, the above - mentioned first determination unit is further configured to, when the anomaly recognition result is an assertion anomaly of the result, use the anomaly type description, the interface request address, the trace address identifier, and the anomaly log as the assertion result of the interface call;

[0197] When the anomaly recognition result is a log - level assertion anomaly, use the log level, the interface request address, the trace address identifier, and the anomaly log as the assertion result of the interface call.

[0198] In an exemplary embodiment, the above - mentioned analysis unit is further configured to perform assertions on the response time of the interface, the loop statements in the test log, and the code coverage of the test code according to the general assertions in the assertion library to determine the general assertion analysis result; perform custom assertion analysis on the mutually - bound test log and the interface response value according to the custom assertions in the assertion library to obtain the custom assertion analysis result;

[0199] Use the general assertion analysis result and the custom assertion analysis result as the assertion result of the interface call.

[0200] In an exemplary embodiment, the above - mentioned analysis unit is further configured to determine whether the interface request address is maintained in the custom assertions in the assertion library; if not, configure the number of services and the number of database tables corresponding to the interface request address in the custom assertions; perform custom assertion analysis on the mutually - bound test log and the interface response value according to the configured custom assertions to obtain the custom assertion analysis result;

[0201] Among them, the custom assertion analysis includes at least one of the following situations:

[0202] Assert the integrity of the number of services that track address identifiers;

[0203] Assert the consistency of database table operations that track address identifiers;

[0204] Assert the consistency of parameters in the test log;

[0205] Assert the correctness of the Structured Query Language in the test log;

[0206] Assert the correctness of the conditional filtering logic in the test log;

[0207] Assert the reliability of implicit parameter passing.

[0208] In an exemplary embodiment, the above interface call assertion monitoring device further includes: a coloring module, a calculation module, and a determination module, where:

[0209] The coloring module is used to perform real-time coloring processing on the running test code during the process of running the test code of the interface;

[0210] The calculation module is used to calculate the test coverage rate of the test code according to the colored test code;

[0211] The determination module is used to determine that the coverage test of the test code passes when the test coverage rate is greater than a preset threshold.

[0212] In an exemplary embodiment, the above calculation module includes: a screening unit and a calculation unit, where:

[0213] The screening unit is used to screen out the updated part of the test code from the test code according to the version of the test code or the update time of the test code;

[0214] The calculation unit is used to calculate the test coverage rate of the updated part of the test code according to the colored code in the updated part of the test code.

[0215] In an exemplary embodiment, a computer device is provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, it implements the content of any one of the above interface call assertion monitoring method embodiments.

[0216] In an embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it implements the content of any one of the above interface call assertion monitoring method embodiments.

[0217] In an embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, it implements the content of any one of the above interface call assertion monitoring method embodiments.

[0218] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data that have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of the relevant data need to comply with the relevant regulations.

[0219] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in this application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in this application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logic devices, data processing logics based on quantum computing, artificial intelligence (AI) processors, etc., without limitation.

[0220] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this application.

[0221] The above embodiments only express several implementation manners of this application, and their descriptions are relatively specific and detailed. However, it should not be construed as a limitation to the patent scope of this application. It should be noted that for those of ordinary skill in the art, without departing from the concept of this application, several deformations and improvements can still be made, and these all belong to the protection scope of this application. Therefore, the protection scope of this application shall be subject to the appended claims.

Claims

1. An interface call assertion monitoring method, characterized in that The method includes: Generating a trace address identifier for the interface in response to a call instruction for the triggered interface; Running the test code of the interface and obtaining the test log and the interface response value generated during the running of the test code; Injecting the trace address identifier into the test log and the interface response value, and binding the test log including the trace address identifier and the interface response value including the trace address identifier; Performing assertion analysis on the mutually bound test log and the interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call.

2. The method according to claim 1, wherein The performing assertion analysis on the mutually bound test log and the interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call includes: Performing exception identification on the test log according to the general assertions in the assertion library to obtain an exception identification result; If the exception identification result indicates that an exception exists, determining the assertion result of the interface call based on the interface request address, the trace address identifier, and the exception log; If the exception identification result indicates that no exception exists, continuing to perform assertion analysis on the mutually bound test log and the interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call.

3. The method according to claim 2, wherein The performing exception identification on the test log according to the general assertions in the assertion library to obtain an exception identification result includes: Judging whether there is an exception assertion based on the log identification result of the test log; If there is no exception assertion, obtaining the log level of the test log; If the log level is a warning, continuing to judge whether the warning in the test log belongs to the whitelist and whether the number of warnings in the test log is greater than a preset threshold; If the warning in the test log is not in the whitelist and the number of warnings is greater than the preset threshold, determining that the exception identification result is that an exception exists.

4. The method according to claim 3, characterized in that, The determining the assertion result of the interface call based on the interface request address, the trace address identifier, and the exception log includes: If the exception identification result is that the result assertion is abnormal, using the exception type description, the interface request address, the trace address identifier, and the exception log as the assertion result of the interface call; If the exception identification result is that the log level assertion is abnormal, using the log level, the interface request address, the trace address identifier, and the exception log as the assertion result of the interface call.

5. The method according to any one of claims 2-4, characterized in that The continuing to perform assertion analysis on the mutually bound test log and the interface response value according to the general assertions and custom assertions in the assertion library to obtain the assertion result of the interface call includes: Performing assertions on the response time of the interface, the loop statements in the test log, and the code coverage of the test code according to the general assertions in the assertion library to determine the general assertion analysis result; Performing custom assertion analysis on the mutually bound test log and the interface response value according to the custom assertions in the assertion library to obtain the custom assertion analysis result; Use the general assertion analysis result and the custom assertion analysis result as the assertion result for the interface call.

6. The method according to claim 5, characterized in that Perform custom assertion analysis on the mutually bound test log and the interface response value to obtain a custom assertion analysis result, including: Determine whether the interface request address is maintained in the custom assertions in the assertion library; If not, configure the number of services and the number of database tables corresponding to the interface request address in the custom assertions; According to the configured custom assertions, perform custom assertion analysis on the mutually bound test log and the interface response value to obtain the custom assertion analysis result.

7. The method according to claim 6, characterized in that, The custom assertion analysis includes at least one of the following situations: Assert the integrity of the number of services identified by the tracking address; Assert the consistency of database table operations identified by the tracking address; Assert the consistency of parameters in the test log; Assert the correctness of the structured query language in the test log; Assert the correctness of the conditional filtering logic in the test log; Assert the reliability of implicit parameter passing.

8. The method according to any one of claims 1-4, characterized in that, The method further includes: During the execution of the test code of the interface, perform real-time coloring on the running test code; Calculate the test coverage rate of the test code according to the colored test code; If the test coverage rate is greater than a preset threshold, determine that the coverage test of the test code passes.

9. The method according to claim 8, characterized in that The calculating the test coverage rate of the test code according to the colored test code includes: Filter out the updated part of the test code from the test code according to the version of the test code or the update time of the test code; Calculate the test coverage rate of the updated part of the test code according to the colored code in the updated part of the test code.

10. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

Images