Interface call assertion monitoring method and computer device

Abstract

The present application relates to an interface call assertion monitoring method and computer device. The method includes: generating an interface tracing address identifier in response to a triggered interface call instruction; running the interface test code and obtaining the test log and interface response value generated during the test code execution; injecting the tracing address identifier into the test log and interface response value, and binding the test log including the tracing address identifier to the interface response value including the tracing address identifier; and performing assertion analysis on the bound test log and interface response value according to common assertions and custom assertions in an assertion library to obtain an assertion result for the interface call. This method can improve the accuracy of interface call assertions.

Description

Technical Field

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

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

[0003] In related technologies, when asserting and monitoring an interface call, an interface response value of the interface call is usually generated after the test code of the interface is tested. The interface response value indicates whether there is an exception during the interface call process.

[0004] However, the related technical interface call assertion monitoring 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. Summary of the Invention

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

[0006] In a first aspect, the present application provides an interface call assertion monitoring method, comprising:

[0007] In response to the triggered interface call instruction, generating a tracing address identifier of the interface;

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

[0009] Injecting the tracing address identifier into the test log and the interface response value, and binding the test log including the tracing address identifier with the interface response value including the tracing address identifier;

[0010] According to the common assertions and custom assertions in the assertion library, assertion analysis is performed on the bound test logs and interface response values ​​to obtain the assertion results of the interface call.

[0011] In one embodiment, according to the common assertions and custom assertions in the assertion library, assertion analysis is performed on the bound test logs and interface response values ​​to obtain the assertion results of the interface call, including:

[0012] According to the common assertions in the assertion library, the test log is identified for anomalies to obtain the anomaly identification results;

[0013] If the exception identification result is that an exception exists, the assertion result of the interface call is determined based on the interface request address, tracking address identifier and exception log;

[0014] If the exception identification result is that there is no exception, then continue to perform assertion analysis on the bound test logs and interface response values ​​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, anomaly identification is performed on the test log according to the general assertions in the assertion library to obtain anomaly identification results, including:

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

[0017] If there is no exception assertion, get the log level of the test log;

[0018] If the log level is 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 the preset threshold;

[0019] If the alarm in the test log is not in the whitelist and the number of alarms is greater than the preset threshold, the anomaly identification result is determined to be an anomaly.

[0020] In one embodiment, determining an assertion result of an interface call based on the interface request address, the tracing address identifier, and the exception log includes:

[0021] If the exception identification result is a result assertion exception, the exception type description, interface request address, tracking address identifier and exception log are used as the assertion result of the interface call;

[0022] If the exception identification result is a log-level assertion exception, the log level, interface request address, tracing address identifier, and exception log are used as the assertion result of the interface call.

[0023] In one embodiment, assertion analysis is continued on the bound test logs and interface response values ​​according to the common assertions and custom assertions in the assertion library to obtain assertion results of the interface call, including:

[0024] According to the general assertions in the assertion library, assertions are made on the interface response time, loop statements in the test log, and test code coverage to determine the general assertion analysis results;

[0025] According to the custom assertions in the assertion library, perform custom assertion analysis on the bound test logs and interface response values ​​to obtain the custom assertion analysis results;

[0026] Use the general assertion analysis results and custom assertion analysis results as the assertion results of the interface call.

[0027] In one embodiment, a custom assertion analysis is performed on the bound test log and the interface response value to obtain a custom assertion analysis result, including:

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

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

[0030] According to the configured custom assertion, the bound test log and interface response value are analyzed to obtain the custom assertion analysis result.

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

[0032] Assertions include the integrity of the number of services tracking address identification;

[0033] Assertions include consistency of operations on database tables that track address identifiers;

[0034] Assert consistency of parameters in test logs;

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

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

[0037] Asserts the reliability of implicit argument passing.

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

[0039] During the process of running the test code of the interface, the running test code is dyed in real time;

[0040] Calculate the test coverage of the test code based on the dyed test code;

[0041] If the test coverage is greater than a preset threshold, it is determined that the coverage test of the test code has passed.

[0042] In one embodiment, calculating the test coverage of the test code based on the colored test code includes:

[0043] Filter out updated test codes from the test codes based on the version of the test codes or the update time of the test codes;

[0044] The test coverage of the test code of the updated part is calculated according to the colored codes in the test code of the updated part.

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

[0046] A generating module, configured to generate a tracing address identifier of the interface in response to a calling instruction of the triggered interface;

[0047] Get the module, which is used to run the test code of the interface and obtain the test log and interface response value generated during the test code running;

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

[0049] The analysis module is used to perform assertion analysis on the bound test logs and interface response values ​​according to the common assertions and custom assertions in the assertion library to obtain the assertion results of the interface call.

[0050] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the content of any one embodiment of the interface call assertion monitoring method in the first aspect is implemented.

[0051] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the content of any one embodiment 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, comprising a computer program, which, when executed by a processor, implements the content of any one embodiment of the interface call assertion monitoring method in the first aspect above.

[0053] The above-mentioned interface call assertion monitoring method and computer device generate a tracing address identifier of the interface in response to the call instruction of 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 tracing address identifier into the test log and the interface response value, and bind the test log including the tracing address identifier to the interface response value including the tracing 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. This method can accurately associate the test log, response data, performance indicators and other multi-dimensional data of the interface call through the tracing address identifier. When a test failure occurs, the complete test log can be quickly located directly through the tracing address identifier, which can effectively monitor the entire process of multi-service collaborative operation, timely discover the hidden risks in the interface call, and improve the accuracy and efficiency of the interface call assertion. 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 briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

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

[0056] Figure 2 A first flow chart of an interface call assertion monitoring method in one embodiment;

[0057] Figure 3 A second flow chart of an interface call assertion monitoring method in one embodiment;

[0058] Figure 4 A third flow chart of an interface call assertion monitoring method according to an embodiment;

[0059] Figure 5 A fourth flow chart of an interface call assertion monitoring method according to an embodiment;

[0060] Figure 6 A fifth flow chart of an interface call assertion monitoring method according to an embodiment;

[0061] Figure 7 A sixth flow chart of an interface call assertion monitoring method according to an embodiment;

[0062] Figure 8A seventh flow chart of an interface call assertion monitoring method according to an embodiment;

[0063] Figure 9 This is an eighth flow chart of an interface call assertion monitoring method according to one embodiment;

[0064] Figure 10 A ninth flow chart of an interface call assertion monitoring method according to an embodiment;

[0065] Figure 11 A schematic diagram of a general assertion process in one embodiment;

[0066] Figure 12 A schematic diagram of a process for obtaining test coverage in one embodiment;

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

[0068] Figure 14 The figure is a structural block diagram of an interface call assertion monitoring device in one embodiment. DETAILED DESCRIPTION

[0069] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0070] Before introducing the technical solution of the present application in detail, a brief introduction to the background technology of the present application is first given.

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

[0072] In related technologies, when asserting and monitoring an interface call, an interface response value of the interface call is usually generated after the test code of the interface is tested. The interface response value indicates whether there is an exception during the interface call process.

[0073] However, related technical interface call assertion monitoring 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, it only relies on interface response values ​​for surface verification and lacks the ability to track data flow paths, intermediate transaction consistency, and resource call links in real time, resulting in low efficiency in anomaly location. In addition, the low coverage of test case execution often leads to test blind spots and the hidden accumulation of technical debt in projects. The coverage of version incremental code can be used as a standard to evaluate whether the test is sufficient. In addition, the current testing strategy lacks a coverage threshold quality assessment system for new or changed code in the iteration. This leads to the lack of incremental code coverage measurement. In addition, the existing testing system has blind spots in SQL execution efficiency monitoring and lacks assertion interception for database performance anti-patterns such as slow queries, full table scans, and index misses.

[0074] To address the above issues, this application provides an interface call assertion monitoring method and computer device. This method implements dynamic intelligent assertions based on requirements code coverage (code coloring and original requirements), code logic (performing code coverage analysis), interface calls (recording requests / responses, dependency service interactions), and log output (capturing runtime status, exceptions, and intermediate data), thereby improving the efficiency of anomaly detection. Furthermore, through multi-dimensional verification, including interface return value assertions (associated with related technologies), process data assertions (such as transmission data errors, database changes, message queues, and cache status), link consistency assertions (logical closure verification of requirements, code, interfaces, test cases, and logs), and coverage assertions (combined with execution path analysis, identification of uncovered logic branches, and supplementary assertions), the anomaly detection process is more comprehensive and the resulting assertion results are more accurate. By coloring the test code during execution, incremental code coverage can be intuitively viewed, providing a foundation for subsequent optimization. Furthermore, adding assertions for SQL statements to the assertion library can reduce blind spots in test assertion monitoring. The following describes the interface call assertion monitoring method in detail.

[0075] The interface call assertion monitoring method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. For example, the computer device may be a server, a personal computer, a laptop computer, a smartphone, a tablet computer, a smart mobile phone, etc. The computer device may include a processor, a memory, and a network interface connected via a system bus or wirelessly. 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 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 via a network connection. When the computer program is executed by the processor, it implements an interface call assertion monitoring method. The computer device may be implemented as an independent computer device or a computer device cluster consisting 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 high-speed random access memory, volatile solid-state memory, etc. In addition, the composition architecture of the computer device is not limited to the above-mentioned situation, and some components may be added or omitted.

[0076] In an exemplary embodiment, Figure 2 As shown, an interface call assertion monitoring method is provided, which is applied to Figure 1 The computer device in the embodiment is used as an example to illustrate the method, including the following steps 101 to 104. Among them:

[0077] S101 : In response to a triggered interface call instruction, generate a trace address identifier of the interface.

[0078] In an embodiment of the present application, the interface calling instruction may be triggered by a user clicking a function button or initiating a data query request, or it may be triggered by an internal timed task, or it may be triggered by an external event linkage.

[0079] Upon receiving a triggered interface call instruction, the computer device can parse the interface call instruction, extract key information from the instruction, and record information such as the time and Internet Protocol Address (IP) of the interface call. Key information may include the caller's identity, interface name, and interface request parameters. For example, for a user login interface call, the parsed information may include the username, password, and client device type.

[0080] Afterwards, the computer device generates a tracking address identifier using the parsed key information according to a pre-set generation method. For example, the pre-set generation method may be based on a combination of a timestamp and a random number, a hash algorithm, or the like.

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

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

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

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

[0085] In an embodiment of the present application, a computer device can use aspect-oriented programming (AOP) technology to inject a tracing address identifier into the test case execution lifecycle of a test framework. Simultaneously, responses are uniformly intercepted at the interface processing layer, and the tracing address identifier of the current request is added to the interface response value. In this way, the tracing address identifier can be used to bind the test log to the interface response value.

[0086] S104 , performing assertion analysis on the bound test logs and interface response values ​​according to the common assertions and user-defined assertions in the assertion library to obtain an assertion result of the interface call.

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

[0088] In an embodiment of the present application, the computer device may first perform a general assertion analysis on the bound test logs and interface response values ​​according to the general assertions in the assertion library to obtain a general assertion analysis result. If the general assertion analysis result meets the preset conditions, the computer device may then perform a custom assertion analysis on the bound test logs and interface response values ​​according to the custom assertions in the assertion library to obtain a custom assertion analysis result.

[0089] In the above-mentioned interface call assertion monitoring method, in response to the call instruction of the triggered interface, a tracing address identifier of the interface is generated; the test code of the interface is run, and the test log and interface response value generated during the running of the test code are obtained; the tracing address identifier is injected into the test log and the interface response value, and the test log including the tracing address identifier is bound to the interface response value including the tracing address identifier; according to the general assertions and custom assertions in the assertion library, the bound test log and interface response value are subjected to assertion analysis to obtain the assertion result of the interface call. This method can accurately associate the test log, response data, performance indicators and other multi-dimensional data of the interface call through the tracing address identifier. When a test failure occurs, the complete test log can be quickly located directly through the tracing address identifier, which can effectively monitor the entire process of multi-service collaborative operation, timely discover the hidden risks in the interface call, and improve the accuracy and efficiency of the interface call assertion.

[0090] In one embodiment, Figure 3 As shown in the figure, according to the common assertions and custom assertions in the assertion library, the bound test logs and interface response values ​​are analyzed to obtain the assertion results of the interface call, including:

[0091] S201: Perform exception identification on the test log according to the general assertions in the assertion library to obtain an exception identification result.

[0092] In an embodiment of the present application, general assertions include test log anomaly identification, performance assertions, and code coverage assertions. The three assertion processes exist in a chronological order, so the test log is first identified for anomalies. Specifically, during the identification process, the computer device can first determine whether there is an anomaly in the test log. If so, the anomaly identification result is determined to be an anomaly. If there is no anomaly, then determine whether an error log appears in the test log. If so, determine the anomaly identification result to be an anomaly. If not, continue to determine whether there is an alarm log. If so, 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 identification result is an anomaly; if it belongs to the whitelist, or the number of logs is small, then determine that the anomaly identification result is that there is no anomaly.

[0093] S202: If the abnormality identification result is that an abnormality exists, the assertion result of the interface call is determined based on the interface request address, the tracking address identifier and the abnormality log.

[0094] In an embodiment of the present application, when the exception identification result is determined to be an exception, the controller can determine the assertion result of the interface call based on the cause of the exception. Specifically, if the exception identification result is a result assertion exception, the exception type description, interface request address, tracking address identifier, and exception log are used as the assertion result of the interface call; if the exception identification result is a log level assertion exception, the log level, interface request address, tracking address identifier, and exception log are used as the assertion result of the interface call.

[0095] S203, if the abnormality identification result is that there is no abnormality, then continue to perform assertion analysis on the 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 embodiment of the present application, if the abnormality identification result is determined to be no abnormality, then the general assertion analysis is first performed on the bound test logs and interface response values ​​according to the performance assertion and code coverage assertion in the general assertion. After the general assertion analysis is completed, the custom assertion analysis is performed on the bound test logs and interface response values ​​according to the custom assertion to obtain the assertion analysis result of the interface call.

[0097] In the above-mentioned interface call assertion monitoring method, the test log is identified for anomalies according to the general assertions in the assertion library to obtain an anomaly identification result. If the anomaly identification result indicates an anomaly exists, the assertion result of the interface call is determined based on the interface request address, tracking address identifier, and anomaly log. If the anomaly identification result indicates no anomaly exists, assertion analysis is continued on the bound test log and interface response value according to the general assertions and custom assertions in the assertion library to obtain an assertion result of the interface call. Through comprehensive analysis of test logs and assertion processing in different situations, this method can more effectively identify problems in interface calls and improve the stability and reliability of the interface.

[0098] In one embodiment, Figure 4 As shown, the specific content of the abnormality identification result obtained by performing abnormality identification on the test log according to the general assertions in the assertion library is introduced, and the specific content includes:

[0099] S301: Based on the log recognition result of the test log, determine whether there is an abnormal assertion.

[0100] In an embodiment 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 it can be integrated with the assertion mechanism in the test framework to embed the exception assertion into the test case to determine the log identification result of the test log.

[0101] After obtaining the log identification results, compare the test log's log identification results with common exception types. If the log identification results match a common exception type, it can be determined that an exception assertion exists. If the log identification results do not match a common exception type, it can be determined that no exception assertion exists. If an exception assertion is determined to exist, the exception assertion analysis results are used as the assertion result of the interface call.

[0102] In one embodiment, if the exception identification result is a result assertion exception, the exception type description, interface request address, tracking address identifier, and exception log are used as the assertion result of the interface call. Subsequent judgment steps are not required. The exception assertion analysis result includes: exception type + interface request address + tracking address identifier + exception test log.

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

[0104] S302: If no exception assertion exists, obtain the log level of the test log.

[0105] Log levels include error and warning. An error is triggered by the appearance of any "ERROR" log, resulting in immediate failure and an associated tracking address to identify the abnormality. An alarm is triggered by the appearance of "WARNING" more than a preset number of times (for example, three) for the same interface request, resulting in failure.

[0106] In the embodiment of the present application, if it is determined that no exception assertion exists, the subsequent judgment is continued, that is, whether an error or warning appears in the test log, thereby determining the log level of the test log. It should be noted that if "ERROR" or "WARNING" appears in the test log, the log level of the test log is determined to be error.

[0107] If the log level of the test log is error, there is no need to continue with the subsequent judgment steps, and the abnormality identification result is determined to be abnormal.

[0108] In one embodiment, if the abnormality identification result is a log-level assertion abnormality, the log level, interface request address, tracing address identifier, and abnormality 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 + tracing address identifier + abnormality test log.

[0109] S303: If the log level is 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.

[0110] In this embodiment of the present application, when determining the log level to be an alarm, it is also necessary to determine whether the alarm in the test log is on the whitelist. This can prevent alarms that have no impact on the abnormal result (for example, cache penetration) from being misidentified. Before determining whether the alarm in the test log is on the whitelist, test logs not triggered by the current test can be filtered out based on the trace address identifier to prevent these test logs from affecting the judgment result.

[0111] During the judgment process, the computer device may compare the alarms in the test log with the alarms in the whitelist to determine whether the alarms in the test log are on the whitelist. If all the alarms in the test log are on the whitelist, the subsequent judgment steps are continued. If none of the alarms in the test log are on the whitelist, or if some of the alarms in the test log are not on the whitelist, the number of alarms that are not on the whitelist is counted, and then a determination is made as to whether the count exceeds a preset threshold, i.e., whether the number of alarms in the test log is greater than the preset threshold.

[0112] If the alarm in the test log belongs to the whitelist, or the number of alarms is less than or equal to the preset threshold, proceed to the subsequent judgment steps.

[0113] S304: If the alarm in the test log is not in the whitelist and the number of alarms is greater than the preset threshold, the abnormality identification result is determined to be abnormality.

[0114] In an embodiment of the present application, when it is determined that the alarms in the test log are not in the whitelist and the number of alarms is greater than the preset threshold, indicating that the number of alarms not in the whitelist is too large, the abnormality identification result can be determined as an abnormality.

[0115] In the above-mentioned interface call assertion monitoring method, based on the log identification 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 an alarm, it is further determined whether the alarm in the test log is in the whitelist, and whether the number of alarms in the test log is greater than the preset threshold; if the alarm in the test log is not in the whitelist, and the number of alarms is greater than the preset threshold, then the abnormal identification result is determined to be an abnormality. This method first determines whether there is an abnormal assertion through multi-level and multi-dimensional analysis and judgment of the test log. If not, it further analyzes the specific situation when the log level is an alarm. It comprehensively considers whether the alarm is in the whitelist and whether the number of alarms is greater than the preset threshold. It can accurately identify the real abnormal situation, effectively avoid misjudging normal alarm information as abnormal, and greatly improve the accuracy of the test results.

[0116] When the abnormality identification result is that there is no abnormality, in one embodiment, Figure 5 As shown, the specific content of the assertion result of the interface call obtained by performing assertion analysis on the bound test logs and interface response values ​​according to the general assertions and custom assertions in the assertion library is introduced. The specific content includes:

[0117] S401 , according to the general assertions in the assertion library, assertions are made on the interface response time, loop statements in the test log, and coverage of the test code to determine the general assertion analysis result.

[0118] In an 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), the log data of the interface response tracking address identifier, request parameters, response parameters, and precise time consumption are recorded.

[0119] Perform millisecond-level time series monitoring of SQL statement execution times (including but not limited to inserts, updates, deletes, and queries). When a statement execution time exceeds a second preset time threshold (e.g., T1 = 10ms), it is marked as a slow query and the tracking address identifier and context information are recorded. The first and second preset time thresholds can be dynamically adjusted. The computer device can use the same tracking address identifier in the test log as the grouping dimension and sort the test logs in ascending order. Use a time window to obtain the time boundary. 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: obtain SQL execution statements within a certain time range, and when the execution statement content is the same except for the parameters, it is judged 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 timestamp, original SQL statement, thread address, client address, session address and other information. (2) Normalization processing engine, which can use hash algorithm to perform data normalization processing, remove parameter information, 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 sliding window length to T = 5 minutes (dynamically adjustable) and the sliding step size to 1 minute.

[0121] Computers can use SQL parsers to identify loop statements, identify optimization points within them, and recommend output. Optimization detection can also be further enhanced through tools such as scalable databases, slow query logs, and index recommendation engines.

[0122] Specifically, the optimization detection rules in loop statements include: detecting query (for example, SELECT *) statements, comparing table structure metadata to identify unused fields, and optimizing for redundant field queries, such as recommending explicitly listing required fields; detecting and analyzing true / false expressions (for example, WHERE1=1) in specified query conditions (WHERE) statements, and optimizing for invalid conditions, such as detecting SQL injection risks or invalid filter conditions; checking multi-table queries without conditions, and optimizing for Cartesian product risks, such as warning about missing association conditions; detecting and identifying type mismatches between fields and values ​​in WHERE statements, and optimizing for implicit type conversions, such as avoiding index failures and prompting display type conversions; detecting deep paging issues, and optimizing for paging, such as recommending the use of cursor paging.

[0123] The optimization detection rule set combined with the extended tool includes: comparing the fields in the conditions with the actual database indexes, optimizing for missing indexes, and relying primarily on database metadata; parsing (EXPLAIN) output and combining it with the Abstract Syntax Tree (AST) to locate high-cost operations (such as full table scans), optimizing for execution plan analysis, and relying primarily on database execution plans; analyzing the filter conditions and data statistics in the WHERE statement, optimizing for the distribution of hot and cold data, and relying primarily on data distribution histograms; and detecting repeated calls to the same SQL template in loops (which requires combined call stack analysis), optimizing for the N+1 query problem.

[0124] S402 , performing custom assertion analysis on the bound test log and interface response value according to the custom assertion in the assertion library to obtain a custom assertion analysis result.

[0125] Among them, the custom assertions in the assertion library are determined based on the calling scenario of the interface.

[0126] In an 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. It then reads the custom assertion rules from the assertion library, asserts the test log or interface response value based on each assertion rule, obtains the assertion result corresponding to each assertion rule, and then merges 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 results of the interface call and displayed to the user in a visual manner.

[0129] In the above-mentioned interface call assertion monitoring method, according to the general assertions in the assertion library, assertions are made on the interface response time, loop statements in the test log, and test code coverage to determine the general assertion analysis results; according to the custom assertions in the assertion library, custom assertion analysis is performed on the bound test logs and interface response values ​​to obtain the custom assertion analysis results; the general assertion analysis results and the custom assertion analysis results are used as the assertion results of the interface call. This method performs comprehensive detection of interface calls from multiple key dimensions by making general assertions on the interface response time, test log loop statements, and test code coverage, while combining custom assertions on the bound test logs and interface response values, greatly improving the comprehensiveness and accuracy of anomaly detection.

[0130] Next, the specific content of the custom assertion analysis result obtained by performing custom assertion analysis on the bound test log and interface response value is introduced through an embodiment. Figure 6 As shown, the specific content includes:

[0131] S501: Determine whether the interface request address is maintained in a custom assertion in an 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. The interface request address is then matched with the key in the custom assertion library. When it is determined that the interface request address does not exist in the custom 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 is performed directly on the mutually bound test log and interface response value 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 this embodiment of the present application, if 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, two services, including a payment service and a reconciliation service) and database table data (for example, two payment record tables and a transaction flow table) based on the interface call scenario and test code. The number of services associated with the interface and the database table data are then set in the custom assertion in the assertion library.

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

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

[0137] Assertions include the integrity of the number of services tracking address identification;

[0138] Assertions include consistency of operations on database tables that track address identifiers;

[0139] Assert consistency of parameters in test logs;

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

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

[0142] Asserts the reliability of implicit argument passing.

[0143] Asserting the integrity of service data is primarily used to verify the integrity of the inter-service call chain. The rule is: after executing a microservice test case, the associated trace address identifiers should cover the expected number of services. If the number of services decreases, the assertion is considered a failure.

[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 (for example, query, insert) associated with the tracking address identifier must be consistent with the expected set. If there is any inconsistency, the assertion is determined to have failed.

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

[0146] Structured Query Language assertions are mainly used to verify the correctness of test complex logic. The rule is: for scenarios that require multiple conditions to be met (for example, permission verification scenarios), the condition combination is verified by tracking the SQL statements associated with the address identifier.

[0147] Conditional filter assertions are primarily used to ensure the accuracy of conditional filtering logic. The rules are: verifying whether specific business conditions are met (for example, only orders from customers who have not been deleted are allowed). Tracking address identifiers are used to check if the test log contains the expected conditional statements.

[0148] Implicit parameter assertions are primarily used to ensure the reliability of implicit parameter passing. The rule is to verify that the parameters automatically passed by the backend (for example, parameters generated based on the account address during login) meet expected values.

[0149] It's important to note that custom assertions take precedence over general assertions. For example, for interfaces with long response times, you can configure a custom assertion time threshold. If the interface response time falls between the general and custom assertion thresholds, no assertion exception is generated.

[0150] In the above-mentioned interface call assertion monitoring method, a determination is made as to whether the interface request address is maintained in the custom assertion library. If not, the number of services and database tables corresponding to the interface request address is configured in the custom assertion. According to the configured custom assertion, a custom assertion analysis is performed on the bound test logs and interface response values ​​to obtain the custom assertion analysis results. This method performs customized assertion analysis on each interface request address based on the actual number of associated services and database tables. This allows for more detailed detection of anomalies in the interaction between the interface and various system components, avoiding misjudgments or missed judgments due to failure to consider the specific business context of the interface, significantly improving the accuracy of test results.

[0151] The above embodiments are all assertions of test logs and interface return values. During the running of the test code, the test code can also be colorized. Figure 7 As shown, the method further includes:

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

[0153] In an embodiment of the present application, a computer device can utilize code coloring technology to color test code in real time during its execution. This allows the user to visually observe the execution location of the test code through the color of the test code. The code coloring technology can be either an on-the-fly mode that dynamically modifies bytecode during class loading or an offline mode that inserts probes during compilation using a build tool.

[0154] S602: Calculate the test coverage of the test code based on the colored test code.

[0155] The test coverage of the test code refers to the proportion of the running part of the test code.

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

[0157] In one case, the test coverage of the newly added or modified test code in the test code can also be calculated. Then, in one embodiment, if Figure 8 As shown, the specific content of calculating the test coverage of the test code based on the dyed test code includes:

[0158] S701 , filtering out updated test codes from the test codes according to the versions of the test codes or the update time of the test codes.

[0159] In an embodiment of the present application, the computer device can determine the code differences between the latest version of the test code and other versions of the test code based on a comparison between the test code versions, and use the test code with the code differences as the updated test code. Alternatively, 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 based on the update time of the test code, and use the test code with the code differences as the updated test code.

[0160] S702 , calculating the test coverage of the updated test code according to the colored code in the updated 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, and calculate the ratio of the coloring code to the test code of the updated part, and use the ratio as the test coverage of the test code of the updated part.

[0162] S603: If the test coverage is greater than a preset threshold, it is determined that the coverage test of the test code has passed.

[0163] In an embodiment of the present application, after obtaining the test coverage, the computer device may further compare the test coverage with a preset threshold. If it is determined that the test coverage is greater than the preset threshold, the execution process of the code during the test is relatively complete, and the coverage test of the test code is determined to have passed. If it is determined that the test coverage is less than or equal to the preset threshold, the execution process of the code during the test is not complete, and the coverage test of the test code can be determined to have failed.

[0164] In the aforementioned interface call assertion monitoring method, while running the interface test code, the running test code is dyed in real time; based on the dyed test code, the test code's test coverage is calculated; if the test coverage exceeds a preset threshold, the test code coverage test is determined to have passed. By dyeing the test code in real time, testers can simultaneously observe which code paths have been executed and which have not been covered during test execution, and can also more accurately calculate the test code coverage.

[0165] In a detailed embodiment, Figure 9 As shown, the interface calls the assertion monitoring method including:

[0166] S801, in response to a triggered interface call instruction, generating an interface tracking address identifier;

[0167] S802, running the test code of the interface, and obtaining the test log and interface response value generated during the running of the test code;

[0168] S803, injecting the tracing address identifier into the test log and the interface response value, and binding the test log including the tracing address identifier with the interface response value including the tracing address identifier;

[0169] S804, judging whether there is an abnormal assertion based on the log recognition result of the test log according to the common assertions in the assertion library;

[0170] S805, if no exception assertion exists, obtain the log level of the test log;

[0171] S806, if the log level is 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 alarm in the test log is not in the whitelist and the number of alarms is greater than the preset threshold, the abnormality identification result is determined to be abnormal;

[0173] S808, determining the assertion result of the interface call based on the interface request address, the tracking address identifier, and the exception log;

[0174] S809, if the alarm in the test log is in the whitelist, or the number of alarms is less than or equal to the preset threshold, and if the anomaly identification result is no anomaly;

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

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

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

[0178] S813, performing custom assertion analysis on the bound test log and interface response value according to the configured custom assertion to obtain a 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 10The present invention is a flow chart of an interface call assertion monitoring method, which includes: S11: generating an interface tracking address identifier in response to an interface call instruction triggered by an interface call; S12: running the interface test code and obtaining the test log and interface response value generated during the test code running process; S13: injecting the tracking address identifier into the test log and the interface response value, and binding the test log including the tracking address identifier to the interface response value including the tracking address identifier; S14: asserting the mutually bound test log and interface response value according to the general assertion to obtain a general assertion result; S15: determining 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: determining whether the custom assertion is successful, if so, executing step S18, if not, executing step S19; S18: displaying the page as successful; S19: displaying the general assertion result and the custom assertion result as the assertion result.

[0181] Figure 11 This is a flowchart of a general assertion, which 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 represented by: interface request address + tracking address identifier + exception type + exception log; S24: judging whether the log level is error, if so, executing step S25, if not, executing step S26; S25: ending the assertion execution, and the assertion result is represented by: interface request address + tracking address identifier + exception type + exception log; Request address + tracking address identifier + error test log; S26: Determine whether an alarm log appears, if so, execute step S27, if not, execute step S30; S27: Determine whether the alarm log is in the whitelist, if so, execute step S30, if not, execute step S28; S28: Determine whether the number of alarm logs is greater than the preset threshold (N), if so, execute step S29, if not, execute step S30; S29: End assertion execution: interface request address + tracking address identifier + alarm test log. S30: Determine whether the interface response time is greater than T1, if so, execute step S31, if not, execute step S32; S31: Record the interface response time on the interface request address and mark it in red; S32: Determine whether the execution time of a single SQL statement is greater than T2, if so, execute step S33, if not, execute step S34; S33: Record the displacement tracking address identifier + timeout log on the interface request address; S34: Determine in time interval Check whether 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 whether 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 whether the incremental code coverage is greater than N%, if so, execute step S40, if not, execute step S39; S39: output the request code + requirement coverage; S40: general assertion is completed, and custom assertion begins.

[0182] Figure 12 Schematic diagram of the process of obtaining test coverage, the process includes: S41: responding to the triggered interface call; S42: performing real-time coloring on the running test code during the running of the interface test code; S43: filtering out the updated test code from the test code according to the version of the test code or the update time of the test code; S44: calculating the test coverage of the updated test code according to the coloring code in the updated test code; S45: judging whether the test coverage is greater than the preset threshold, if so, executing step S47, if not, executing step S46; S46: outputting the test coverage and displaying the document information of the uncovered code, and judging that the assertion failed; S47: outputting the test coverage and judging that the assertion passed.

[0183] Figure 13 This is a schematic diagram of the efficiency improvement ratio, where the horizontal axis is the indicator and the vertical axis is the percentage. By calling the assertion monitoring method through the interface provided in this application, the test log, test link and indicator problem are bound by tracking the address identifier, which improves the problem location efficiency by 70%. By covering scenarios that are difficult to verify by traditional means through automated assertions, the test coverage rate is increased by 60%. By reducing false alarms and shortening the average repair time through intelligent baseline alerts, the operation and maintenance costs are reduced by 50%. Automated and manual execution of test cases can share the same assertion library. The system also contains a general assertion configuration and automatically records the execution results, which reduces the maintenance time of the test case assertion library by 35%. Intelligent monitoring of abnormal results through logs. Reduce the probability of ignoring anomalies, so that the anomaly detection capability is improved by 40%. Automatically detect performance problems and prompt them, improve code performance, and improve performance by 25%.

[0184] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0185] Based on the same inventive concept, embodiments of the present application also provide an interface call assertion monitoring device for implementing the aforementioned interface call assertion monitoring method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more embodiments of the interface call assertion monitoring device provided below can be found in the aforementioned limitations of the interface call assertion monitoring method and will not be further elaborated here.

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

[0187] A generating module 11 is configured to generate a tracing address identifier of the interface in response to a triggered interface call instruction;

[0188] Acquisition module 12, used to run the test code of the interface and obtain the test log and interface response value generated during the test code running process;

[0189] A binding module 13, configured to inject the tracing address identifier into the test log and the interface response value, and bind the test log including the tracing address identifier with the interface response value including the tracing address identifier;

[0190] The analysis module 14 is used to perform assertion analysis on the bound test logs and interface response values ​​according to the common assertions and user-defined assertions in the assertion library to obtain the assertion result of the interface call.

[0191] In an exemplary embodiment, the analysis module includes: an anomaly identification unit, a determination unit, and an analysis unit, wherein:

[0192] The exception identification unit is used to identify exceptions in the test log according to the common assertions in the assertion library and obtain exception identification results;

[0193] A determination unit, configured to determine an assertion result of the interface call based on the interface request address, the tracking address identifier, and the exception log when the exception identification result indicates that an exception exists;

[0194] The analysis unit is used to continue to perform assertion analysis on the bound test logs and interface response values ​​according to the general assertions and custom assertions in the assertion library when the exception identification result is that there is no exception, and obtain the assertion result of the interface call.

[0195] In an exemplary embodiment, the above-mentioned exception identification unit is also used to determine whether there is an exception assertion based on the log identification result of the test log; if there is no exception assertion, obtain the log level of the test log; if the log level is an alarm, continue to determine whether the alarm in the test log belongs to the whitelist, and determine whether the number of alarms in the test log is greater than a preset threshold; if the alarm in the test log is not in the whitelist, and the number of alarms is greater than the preset threshold, then determine that the exception identification result is that there is an exception.

[0196] In an exemplary embodiment, the first determining unit is further configured to, when the exception identification result is a result assertion exception, use the exception type description, the interface request address, the tracing address identifier, and the exception log as the assertion result of the interface call;

[0197] When the exception identification result is a log-level assertion exception, the log level, interface request address, tracing address identifier, and exception log are used as the assertion result of the interface call.

[0198] In an exemplary embodiment, the analysis unit is further configured to perform assertions on the interface response time, 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 results; and to perform custom assertion analysis on the bound test logs and interface response values ​​according to the custom assertions in the assertion library to obtain custom assertion analysis results.

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

[0200] In an exemplary embodiment, the analysis unit is further configured to determine whether the interface request address is maintained in a custom assertion 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 assertion; perform custom assertion analysis on the bound test logs and interface response values ​​according to the configured custom assertion to obtain a custom assertion analysis result;

[0201] Custom assertion analysis includes at least one of the following situations:

[0202] Assertions include the integrity of the number of services tracking address identification;

[0203] Assertions include consistency of operations on database tables that track address identifiers;

[0204] Assert consistency of parameters in test logs;

[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] Asserts the reliability of implicit argument passing.

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

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

[0210] A calculation module, used for calculating the test coverage of the test code according to the dyed test code;

[0211] The determination module is used to determine whether the coverage test of the test code has passed when the test coverage is greater than a preset threshold.

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

[0213] A screening unit, configured to screen out updated test codes from the test codes according to the version of the test codes or the update time of the test codes;

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

[0215] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the content of any embodiment of the above-mentioned interface call assertion monitoring method when executing the computer program.

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

[0217] In one embodiment, a computer program product is provided, including a computer program, which implements the content of any embodiment of the above-mentioned interface call assertion monitoring method when executed by a processor.

[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 used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0219] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the 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-mentioned methods. Among them, any reference to memory, database or other media 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), magnetic 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 take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0220] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, 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, they should be considered to be within the scope of this application.

[0221] The above embodiments merely illustrate several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. An interface call assertion monitoring method, characterized in that: The method comprises: In response to a triggered interface call instruction, a tracking address identifier of the interface is generated, and it is determined whether the generated tracking address identifier of the interface is repeated with a tracking address identifier already existing in the database; the interface call involves the coordinated operation of multiple services; If there is a duplication, regenerate the tracking address identifier until the generated tracking address identifier does not duplicate the tracking address identifier already existing in the database; Run the test code of the interface and obtain the test log and interface response value generated during the running of the test code; Injecting the tracing address identifier into the test log and the interface response value, and binding the test log including the tracing address identifier to the interface response value including the tracing address identifier; including: injecting the tracing address identifier into the test case execution lifecycle of the test framework through aspect-oriented programming technology, and uniformly intercepting the response at the interface processing layer, adding the tracing address identifier of the current request to the interface response value, so as to bind the test log including the tracing address identifier to the interface response value including the tracing address identifier; According to the general assertions in the assertion library, anomaly identification is performed on the test log to obtain an anomaly identification result; If the abnormality identification result is that no abnormality exists, then according to the general assertions in the assertion library, assertions are made on the time of the interface response, the loop statements in the test log, and the coverage of the test code to determine the general assertion analysis result; According to the custom assertions in the assertion library, a custom assertion analysis is performed on the mutually bound test logs and the interface response value to obtain a custom assertion analysis result; including: determining whether the interface request address is maintained in the custom assertion in the assertion library; if not, configuring 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 assertions, a custom assertion analysis is performed on the mutually bound test logs and the interface response value to obtain the custom assertion analysis result; The general assertion analysis result and the custom assertion analysis result are used as the assertion result of the interface call.

2. The method according to claim 1, characterized in that The method further comprises: If the abnormality identification result is that an abnormality exists, the assertion result of the interface call is determined based on the interface request address, the tracking address identifier and the abnormality log.

3. The method according to claim 1, characterized in that The step of performing abnormality identification on the test log according to the general assertions in the assertion library to obtain an abnormality identification result includes: Based on the log recognition result of the test log, determining whether there is an abnormal assertion; If no exception assertion exists, obtain the log level of the test log; If the log level is an alarm, continue to determine whether the alarm in the test log belongs to the whitelist, and determine whether the number of alarms in the test log is greater than a preset threshold; If the alarm in the test log is not in the whitelist and the number of the alarms is greater than the preset threshold, it is determined that the abnormality identification result is that an abnormality 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 tracking address identifier and the exception log includes: If the exception identification result is a result assertion exception, the exception type description, the interface request address, the tracking address identifier and the exception log are used as the assertion result of the interface call; If the exception identification result is a log-level assertion exception, the log level, the interface request address, the tracking address identifier and the exception log are used as the assertion result of the interface call.

5. The method according to any one of claims 1 to 4, characterized in that The calling instruction of the interface is triggered by the user clicking a function button or initiating a data query request, or is triggered by an internal timed task.

6. The method according to any one of claims 1 to 4, characterized in that The general assertions in the assertion library refer to commonly used assertion rules, and the custom assertions are assertions determined based on interface call scenarios.

7. The method according to any one of claims 1 to 4, characterized in that The custom assertion analysis includes at least one of the following situations: Asserting the integrity of the service quantity identified by the tracking address; Asserting consistency of operations on the database table 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; Asserts the reliability of implicit argument passing.

8. The method according to any one of claims 1 to 4, characterized in that The method further comprises: During the process of running the test code of the interface, performing real-time coloring processing on the running test code; Calculating the test coverage of the test code according to the dyed test code; If the test coverage is greater than a preset threshold, it is determined that the coverage test of the test code passes.

9. The method according to claim 8, characterized in that The step of calculating the test coverage of the test code according to the dyed test code includes: Filtering updated test codes from the test codes according to the version of the test codes or the update time of the test codes; The test coverage of the updated portion of the test code is calculated according to the colored codes in the updated portion of the test code.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 9 are implemented.

Images