Test failure root cause diagnosis method

Abstract

The invention discloses a test failure root cause diagnosis method, which relates to the technical field of electric digital data processing, and is characterized in that after a test failure signal is captured, comprehensive analysis is carried out in combination with multi-source log information of a test case and test environment configuration data, so that the influence of environment configuration on a test is fully considered, and information in a log is fully mined; according to the method, a more accurate diagnosis result is obtained, and a corresponding solution is matched according to a test failure root cause to solve the problem of test failure, so that the problems of low efficiency and high misjudgment probability of manual analysis, neglect of the influence of a test environment on the test failure, difficulty in identifying implicit connection between texts in a log and difficulty in testing failure in the prior art can be solved. Therefore, the technical problem that the obtained analysis result is difficult to be used for accurate root cause diagnosis is solved, the diagnosis efficiency of test failure root causes is improved, the diagnosis precision is improved, and the overall test period is shortened.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electric digital data processing, and in particular to a diagnosis method of test failure root cause. BACKGROUND

[0002] In the related art, when diagnosing the test failure root cause of server testing, the artificial or semi-artificial analysis method is low in efficiency, and is highly subjective and dependent on the technical experience of technicians, so that the probability of false diagnosis is high. In the semi-artificial analysis, the preliminary analysis based on the log analysis tool is used for root cause diagnosis, which only analyzes the log and ignores the influence of the test environment on the test failure, so that the obtained data is poor in comprehensiveness, and the log analysis tool is difficult to identify the implicit connection between the texts in the log, so that the obtained analysis result is difficult to be used for accurate root cause diagnosis, which needs to be improved. SUMMARY

[0003] The present application provides a diagnosis method of test failure root cause, which at least solves the technical problems that the artificial analysis is low in efficiency and high in false diagnosis probability in the related art, the preliminary analysis using the log analysis tool ignores the influence of the test environment on the test failure, the obtained data is poor in comprehensiveness, and the log analysis tool is difficult to identify the implicit connection between the texts in the log, so that the obtained analysis result is difficult to be used for accurate root cause diagnosis.

[0004] The present application provides a diagnosis method of test failure root cause, which comprises: capturing a test failure signal of at least one server tester, and determining a test case based on the test failure signal to obtain multi-source log information and test environment configuration data of the test case; calculating the test environment configuration similarity between the test case and a historical case based on the test environment configuration data, and analyzing the multi-source log information to obtain corresponding log semantic features; calculating the comprehensive score of the test case based on the test environment configuration similarity and the log semantic features, determining the test failure root cause of the test case based on the comprehensive score, matching the corresponding solution based on the test failure root cause, and pushing the solution to the at least one server tester.

[0005] The application further provides a diagnosis device for a test failure root cause, comprising: an acquisition module, configured to capture a test failure signal of at least one server test machine, and determine a test case based on the test failure signal, to acquire multi-source log information and test environment configuration data of the test case; an analysis module, configured to calculate a test environment configuration similarity between the test case and a historical case based on the test environment configuration data, and analyze the multi-source log information to obtain corresponding log semantic features; and a diagnosis module, configured to calculate a comprehensive score of the test case based on the test environment configuration similarity and the log semantic features, to determine a test failure root cause of the test case based on the comprehensive score, and match a corresponding solution based on the test failure root cause, and push the solution to the at least one server test machine.

[0006] The application further provides an electronic device, comprising: a memory, configured to store a computer program; and a processor, configured to implement the steps of any of the diagnosis methods for a test failure root cause when executing the computer program.

[0007] The application further provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program implements the steps of any of the diagnosis methods for a test failure root cause when executed by a processor.

[0008] The application further provides a computer program product, comprising a computer program, and the computer program implements the steps of any of the diagnosis methods for a test failure root cause when executed by a processor.

[0009] According to the application, after the test failure signal is captured, the corresponding test case is determined, and the multi-source log information and the test environment configuration data of the test case are comprehensively analyzed to diagnose the failure root cause, wherein the test environment configuration data can calculate the test environment configuration similarity between the test case and the historical case, and the multi-source log information can analyze the implicit connection between the texts, and then the test failure root cause of the test case is determined based on the test environment configuration similarity and the log semantic features, so that the influence of the environment configuration on the test is fully considered, the information in the log is fully mined, a more accurate diagnosis result is obtained, and then the corresponding solution is matched according to the test failure root cause to solve the test failure problem, thereby solving the technical problems that the efficiency of manual analysis is low and the misjudgment probability is high in the related art, the influence of the test environment on the test failure is ignored when the log analysis tool is used for preliminary analysis, the obtained data is poor in comprehensiveness, and the log analysis tool cannot recognize the implicit connection between the texts in the log, so that the obtained analysis result cannot be used for accurate root cause diagnosis, and the diagnosis efficiency of the test failure root cause is improved, the diagnosis accuracy is increased, and the overall test cycle is shortened. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. Obviously, the drawings described below are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort based on these drawings.

[0011] Figure 1 A flow chart of a diagnosis method for a test failure root cause according to an embodiment of the present application; Figure 2 A flow chart of a diagnosis method for a test failure root cause according to an embodiment of the present application; Figure 3 A structural schematic diagram of a diagnosis device for a test failure root cause according to an embodiment of the present application. DETAILED DESCRIPTION

[0012] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort fall within the protection scope of the present application.

[0013] It should be noted that, in the description of the present application, the terms "comprise", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms "first", "second" and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0014] In order for those skilled in the art to better understand the technical solutions of the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0015] It can be understood that, in the server test process, when the test case appears FAIL result, the accurate diagnosis of the failure root cause is the key link to guarantee the test efficiency and the server quality. In the server test work, when the test case appears FAIL result, the multi-dimensional log information such as test script log, OS log, BMC log, etc. needs to be comprehensively analyzed to effectively analyze and locate the failure root cause.

[0016] Currently, the related art mainly adopts two analysis methods to diagnose the root cause of test failure: one is manual analysis, the test personnel need to view various logs line by line, and troubleshoot problems by manual comparison and experience judgment. This method not only consumes a lot of time and manpower, but also is prone to deviation in analysis results due to experience differences of different personnel. The second is semi-automatic analysis, which preliminarily screens and processes by means of the existing log analysis system, and then manually completes the final root cause determination.

[0017] However, the preliminary screening and processing by means of the existing log analysis system has obvious limitations. The log analysis tool only focuses on the matching of error text, ignores the influence of test environment configurations such as hardware models and software versions on errors, and makes the generated solutions have poor universality, which is difficult to cope with diversified scenarios. The rule engine based on keyword matching cannot recognize the context semantic association of logs, and the implicit connection between errors and previous and next entries in server logs is ignored, which easily leads to one-sided analysis and affects the accuracy of root cause positioning. In addition, the historical solutions under similar configurations are not effectively reused, and when the same or similar problems occur, repeated analysis is still needed, which seriously reduces the efficiency.

[0018] To break through the limitations of the related art, the present application proposes a test failure root cause diagnosis method that combines configuration similarity and semantic analysis, which realizes rapid and accurate diagnosis of test failure root cause and provides efficient support for server testing in multi-configuration complex scenarios.

[0019] As shown in Figure 1 The embodiment of the present application provides a test failure root cause diagnosis method, which comprises the following steps: In step S101, the test failure signal of at least one server tester is captured, and the test case is determined based on the test failure signal to obtain the multi-source log information of the test case and the test environment configuration data.

[0020] The test case is a set of specific test conditions, steps and expected results, which is used to verify whether a certain function of software works normally according to the design requirements.

[0021] The multi-source log information can be log data generated by different software components, services or devices during testing and system running, which may vary in format and content. The multi-source log information can be composed of multiple parts, such as web server, application server, database, cache service, message queue, etc. Each part will generate its own log file.

[0022] The test environment configuration data is all related settings and parameters of the server environment during testing. It can include operating system version, version number of software dependent library, database connection string, allocation of memory and CPU, network configuration, environment variable, etc.

[0023] In actual implementation, the embodiment of the present application can communicate with the server to obtain the server log information and the test environment configuration data in real time or periodically. In order to obtain more targeted data, the embodiment of the present application can also obtain the corresponding test case, and the multi-source log information and the test environment configuration data of the test case from the server after capturing the test failure signal of the server test set.

[0024] For example, the embodiment of the present application can obtain the server test machine currently triggering the test failure signal from the test management platform, pull the server configuration data (various component models, quantities, OS, BMC version, etc.) from the mysql database of the test platform, collect the test script log, the OS log and the BMC log in real time, and store them to the log pool.

[0025] In step S102, the test environment configuration similarity of the test case and the historical case is calculated based on the test environment configuration data, and the multi-source log information is analyzed to obtain the corresponding log semantic features.

[0026] It can be understood that many test failures are not code logic errors, but are caused by incorrect or inconsistent environment configurations. For example, the code runs normally in the production environment, but fails in the test environment, which is likely to be caused by the fact that the database version of the test environment is too old, or the value of a certain configuration item is set incorrectly.

[0027] The single-source log can only reflect the local phenomenon of the problem. The embodiment of the present application forms a global view by associating the multi-source log information, so as to obtain a more accurate diagnosis result of the test failure root cause.

[0028] As a possible implementation manner, the embodiment of the present application can calculate the similarity of the current test environment configuration data and the test environment configuration data of the historical case by using a weighted cosine similarity algorithm; the embodiment of the present application can also preprocess the multi-source log information, and perform semantic coding on the preprocessed multi-source log information to analyze the semantics and extract the log semantic features, so as to comprehensively diagnose the test failure root cause based on the log semantic features and the test environment configuration similarity in the subsequent process.

[0029] Optionally, in an embodiment of the present application, the multi-source log information is analyzed to obtain the corresponding log semantic features, including: cleaning the multi-source log information, and dividing the cleaned multi-source log information by using a pre-constructed log field dictionary to obtain a plurality of log segments; calculating the error type probability distribution based on the plurality of log segments; and extracting the error event based on the error type probability distribution to obtain the log semantic features.

[0030] Further, the embodiment of the present application can preprocess the multi-source log information: ① Log cleaning: filter out noise such as timestamps, IPs, etc. ② Tokenization: use log domain dictionary to enhance segmentation.

[0031] Semantic encoding of pre-processed multi-source log information: input log segments into fine-tuned BERT model, output error type probability distribution.

[0032] Event graph construction: extract error events, generate directed edges according to timestamps; merge repeated events (such as continuous "memory allocation failure").

[0033] In order to realize the correlation analysis of the multi-source log information, the embodiment of the present application can count the frequency of occurrence of various error types in a period of time, form a probability distribution, that is, an error type probability distribution. Those error types with a sudden significant increase in probability are considered abnormal and important. Then, the embodiment of the present application can extract each specific log record of these error types as an independent error event.

[0034] So that the embodiment of the present application can automatically focus on the most likely related and sudden error events in the current test failure from thousands of logs.

[0035] Based on the above steps, the embodiment of the present application can extract the log semantic features from the log text, which can represent the core meaning and content of the log.

[0036] Optionally, in an embodiment of the present application, after extracting error events based on error type probability distribution, it further includes: generating corresponding directed edges based on the timestamps of error events; constructing an event graph using directed edges to calculate semantic similarity based on the event graph.

[0037] In actual execution process, the embodiment of the present application can traverse all error events, for any two events (event A and event B), if the timestamp t_A of A is earlier than the timestamp t_B of B, and the time difference (t_B - t_A) is less than a preset threshold (for example, 5 minutes), then a directed edge is created between them, from A to B (i.e. A -> B). To connect the discrete event points into a potential causal chain with time sequence.

[0038] Further, the embodiment of the present application can combine all error events as nodes and all directed edges as edges into a directed graph, that is, an event graph, to show the potential dependency and influence relationship between faults.

[0039] Embodiments of the present application can determine the similarity between the log semantic features corresponding to the multi-source log information and the error events in the event graph in the context of the topology of the event graph. The error events in the multi-source log (test script, OS, BMC) are converted into a weighted directed graph, with nodes representing error types and edges representing time or logical association (such as "PCIe error -> driver load failure").

[0040] Embodiments of the present application can also match the common subgraph of the current error chain and the historical cases through the graph similarity algorithm, improving the accuracy of root cause positioning.

[0041] Embodiments of the present application can combine time sequence and semantic association to jointly infer the root cause, effectively avoiding false positives caused by single-dimensional analysis (only looking at time or only looking at keywords), making the positioning result more reliable.

[0042] Optionally, in an embodiment of the present application, before segmenting and cleaning the multi-source log information using the pre-constructed log field dictionary, it further includes: defining the hierarchical relationship of the server components; and constructing the log field dictionary based on the hierarchical relationship. The log field dictionary can be a dictionary customized for a specific system or business field, containing key terms and concepts, containing server-specific vocabulary, helping the analysis algorithm to more accurately understand the log content and identify which logs are related to core business or critical services, thereby improving the accuracy of analysis.

[0043] In actual execution, embodiments of the present application can describe the architecture of the entire server application system in a structured manner, to clearly define the ownership and dependency relationship of each component in the system, i.e., to define the hierarchical relationship, and to construct a dictionary specific to the business system by taking the key entities (such as service name, module name, API endpoint, and key error code) in the hierarchical relationship as terms, so that the subsequent log analysis algorithm is no longer a general text processing, but a text processing specific to a particular field. When segmenting and recognizing logs, the algorithm can preferentially recognize these field-specific vocabulary, greatly improving the accuracy of log parsing and feature extraction.

[0044] Optionally, in an embodiment of the present application, the error events are extracted based on the error type probability distribution to obtain the log semantic features, including: importing a plurality of historical test cases that meet the preset case conditions; constructing a pre-training model based on the plurality of historical test cases to calculate the error type probability distribution using the pre-training model.

[0045] In other embodiments, a large number of labeled historical test case logs can also be collected. These labels can be error types such as "database error", "network timeout", "memory overflow", etc. These data are used to fine-tune a model such as a BERT model. BERT is a pre-trained language model that can deeply understand the context semantics. Unlike traditional methods that only match keywords, it can understand the high similarity in different semantics.

[0046] Through fine-tuning, the BERT model can be converted into a model that is more suitable for the needs of the embodiments of the present application for analyzing the root cause of test failures. The fine-tuning process enables the model to learn which combinations of words and grammatical structures correspond to specific error types in the context of a particular server application.

[0047] In the embodiments of the present application, the log field dictionary enables the embodiments of the present application to more accurately understand the log content and reduce misinterpretation. Based on NLP models such as BERT, the embodiments of the present application perform deep semantic analysis on unstructured log text to identify error types (such as "memory leak" and "network timeout") and their causal chains (such as "service A crash -> service B timeout"), breaking through the limitations of traditional keyword matching.

[0048] Optionally, in an embodiment of the present application, the test environment configuration data is used to calculate the test environment configuration similarity between the test case and the historical cases, including: extracting numerical features from the test environment configuration data, and normalizing the numerical features to obtain numerical data; performing variable conversion on the category features in the test environment configuration data to obtain encoded data; based on the numerical data and the encoded data, calculating the cosine similarity between the test case and the plurality of historical test cases, and obtaining the historical cases based on the cosine similarity.

[0049] When searching for similar cases in historical test cases based on the current test environment configuration data, the embodiments of the present application can first perform feature vectorization processing, normalizing numerical features (such as memory capacity) to eliminate the bias caused by the dimension and numerical range. Then, the embodiments of the present application can perform One-Hot encoding on the category features (such as CPU model) to convert the category relationship into a spatial relationship. Finally, the cosine similarity is calculated based on the normalized numerical features and the encoded category features, that is, the normalized numerical features and the One-Hot encoded category features are spliced into a long and unified feature vector, and then the cosine similarity between the current environment vector and all historical case environment vectors is calculated.

[0050] The embodiment of the application can adopt a weighted cosine similarity algorithm, combine structured data such as hardware models (such as CPU, memory), software versions (such as operating system, driver), and dynamically adjust the weights of various configuration characteristics (such as CPU model weight 0.6, memory weight 0.3), to ensure the accuracy of the similarity calculation.

[0051] Optionally, in an embodiment of the application, the historical case based on the cosine similarity includes: judging whether there is at least one case in the historical test case whose cosine similarity is greater than a preset similarity threshold; if there is at least one case, obtaining the historical case based on the cosine similarity; if there is no at least one case, verifying the calculation validity of the cosine similarity by using the historical test case; in the case that the calculation validity does not meet a preset valid condition, generating an error prompt, otherwise, generating a new case prompt.

[0052] The embodiment of the application can set a similarity threshold, such as 0.7, when the similarity is greater than the similarity threshold, the historical test case can be retained, in the case that only one historical test case corresponds to a similarity greater than the similarity threshold, the historical test case is the historical case similar to the test case corresponding to the current test environment, if there are multiple historical test cases corresponding to a similarity greater than the similarity threshold, the multiple historical test cases can be sorted according to the similarity, and the historical test case with the highest similarity is selected as the historical case.

[0053] If there is no historical test case similar to the test case corresponding to the current test environment, the embodiment of the application can call multiple historical test cases with known similarity to each other to perform similarity calculation to determine whether there is an error in the calculation process of the similarity, to verify the calculation validity of the cosine similarity.

[0054] If the calculation validity of the cosine similarity is valid, it indicates that the test case corresponding to the current test environment is a new test failure test case, the embodiment of the application can generate a new case prompt, and after the user processes the test case, the test case is stored as a historical test case.

[0055] If the calculation validity of the cosine similarity is invalid, a corresponding error prompt can be generated to remind the user to promptly troubleshoot the error.

[0056] By setting the similarity threshold, the cases with a certain degree of similarity can be screened from the historical test cases, and according to the similarity sorting, the historical test case with the highest similarity can be obtained as the historical case. In the case that there is no high-similarity case, the embodiment of the application can automatically verify the reason for the low similarity to implement the learning optimization process of new case input or perform fault processing to avoid affecting the subsequent analysis.

[0057] In step S103, the test environment configuration similarity and the log semantic feature are used to calculate a comprehensive score of the test case, to determine a test failure root cause of the test case based on the comprehensive score, and to match a corresponding solution based on the test failure root cause, and to push the solution to at least one server test machine.

[0058] The embodiment of the present application can weight and integrate the test environment configuration similarity and the log semantic feature to obtain a comprehensive score of the test case, to determine a test failure root cause, and to match a corresponding solution based on the test environment configuration similarity and the test failure root cause, so that the solution can consider the influence of the environment configuration and increase the error repair probability.

[0059] Optionally, in an embodiment of the present application, the test environment configuration similarity and the log semantic feature are used to calculate a comprehensive score of the test case, to determine a test failure root cause based on the comprehensive score, including: calculating a semantic similarity between the test case and a historical case based on the log semantic feature; respectively assigning corresponding weights to the test environment configuration similarity, the semantic similarity and a historical effectiveness score corresponding to the historical case; calculating a comprehensive score of the test case based on the weights, the test environment configuration similarity, the semantic similarity and the historical effectiveness score, and determining the test failure root cause based on the comprehensive score.

[0060] In actual execution process, the embodiment of the present application can determine a test failure root cause based on the log semantic feature, the test environment configuration similarity and an effectiveness score of a historical case processing.

[0061] For example, the embodiment of the present application can perform multi-dimensional integration. For each similar case, a comprehensive score is calculated: Score=0.4×Config_Sim+0.4×Semantic_Match+0.2×Historical_Effectiveness.

[0062] Wherein, Config_Sim is the test environment configuration similarity, Semantic_Match is a semantic matching degree of the log semantic feature, and Historical_Effectiveness is an effectiveness of a historical case processing.

[0063] Wherein, the semantic matching degree is calculated by an event graph subgraph isomorphism algorithm.

[0064] The embodiment of the present application can design a weighted score model (α+β+γ=1) integrating configuration similarity (α), semantic matching degree (β) and historical solution effectiveness (γ), to realize collaborative decision of multi-dimensional data.

[0065] Optionally, in an embodiment of the present application, matching the corresponding solution based on the test failure root cause comprises: matching a plurality of historical solutions based on the test failure root cause; sorting the plurality of historical solutions based on the effectiveness scores corresponding to the plurality of historical solutions to obtain a solution recommendation table; determining the solution to the test failure root cause based on the solution recommendation table, and storing the solution, the test failure root cause, and the effectiveness score input by the user based on the execution result of the solution, or determining a new solution based on the order of the solution recommendation table.

[0066] It can be understood that there can be multiple solutions for the same test failure root cause, for example, there are solutions determined after user access, there are solutions matched according to the similarity of historical test cases, and there are solutions directly matched for the test failure root cause.

[0067] After determining the test failure root cause, the embodiment of the present application can match a plurality of historical solutions, and sort the plurality of historical solutions according to the effectiveness score given by the user for each historical solution, or the effectiveness score converted by the server test data after the server executes the historical solution, for example, the success rate of solving the problem, the solving speed, or the number of positive feedbacks after the solution is executed, to obtain a solution recommendation table.

[0068] The embodiment of the present application can execute the solution with the highest effectiveness score in the order of the solution recommendation table, if the solution solves the test failure root cause, it is confirmed that the solution is effective, if the solution cannot solve the test failure root cause, the next solution is selected based on the order of the solution recommendation table to start execution.

[0069] The effectiveness score of the embodiment of the present application can be calculated by referring to various data, so that the effectiveness score can better represent the effect of solving the corresponding problem, and the embodiment of the present application can more accurately and quickly filter out the solution most likely to solve the problem from a large number of historical solutions, to improve the problem solving efficiency and reduce the dependence on human experience.

[0070] Optionally, in an embodiment of the present application, after determining the solution of the test failure root cause based on the scheme recommendation table, further comprising: executing the solution and receiving a validity score input by the user; determining whether the validity score is greater than or equal to a first preset score, if greater than or equal to the first preset score, optimizing the weight of the solution in the historical validity score based on the validity score; determining whether the validity score is less than or equal to a second preset score, if less than or equal to the second preset score, correcting the test failure root cause based on the actual test failure root cause input by the user, and optimizing the weight of the comprehensive score calculation of the test case based on the validity score, wherein the second preset score is less than the first preset score.

[0071] After executing the solution, the embodiment of the present application can receive the user's evaluation on this problem solving, if the user's evaluation is high, i.e. greater than a certain score threshold, it can be confirmed that the solution is effective, and the weight of the solution in the historical validity score can be increased, so that the next time a similar problem is encountered, the solution can be placed in front of the scheme recommendation table, and the problem can be solved more quickly. If the user's evaluation is low, i.e. lower than a certain score threshold, it can be confirmed that the solution is invalid, or the solution does not meet the user's expectations, or the identified root cause does not match the actual root cause, and the weight of the solution in the historical validity score can be reduced, so that the next time a similar problem is encountered, the solution can be placed at the back of the scheme recommendation table, reducing the probability of executing the solution, or receiving the actual root cause input by the user to adjust the calculation weight in the comprehensive score.

[0072] Through cyclic optimization, the optimized matching of the solution is realized, and in the case of identifying errors, the data can be updated in time to continuously improve the identification efficiency, identification accuracy and effectiveness of the solution matching of the embodiment of the present application.

[0073] Optionally, in an embodiment of the present application, the test environment configuration similarity and the log semantic feature are used to calculate the comprehensive score of the test case, to determine the test failure root cause of the test case based on the comprehensive score, further comprising: obtaining multi-source monitoring data of at least one server test machine; converting the multi-source monitoring data into a corresponding feature vector; obtaining the architecture topology relationship of the at least one server test machine, to capture the dependency relationship between the components of the at least one server test machine based on the architecture topology relationship; combining the feature vector, the test environment configuration similarity and the log semantic feature to calculate the comprehensive score; and determining the test failure root cause based on the comprehensive score and the dependency relationship.

[0074] The multi-source monitoring data is various runtime performance indexes collected from a server test machine, including but not limited to: CPU usage, load, memory usage, swap partition state, disk I / O throughput, delay, network bandwidth, connection number, packet loss rate, process resource occupation, thread state, and the like.

[0075] Embodiments of the present application can convert multi-dimensional monitoring data into a unified numerical vector representation through mathematical transformation. For example: mean, variance, and trend within a sliding window are converted into time series features; quantiles, peak values, and abnormal points are converted into statistical features; periodic patterns are extracted through Fourier transform and converted into frequency domain features, and the like.

[0076] Embodiments of the present application can construct a directed graph describing the connection and dependency relationship between components in a server system to capture the dependency relationship between components, i.e., the dependency strength of components in the topological relationship, such as call frequency, data flow, timeout dependency, transaction consistency requirement, resource competition relationship, and the like.

[0077] Embodiments of the present application can fuse multiple dimensions of features, and on the basis of comprehensive calculation and scoring of environmental configuration features and log semantic features, fuse monitoring data features to calculate a comprehensive score for representing a test failure root cause.

[0078] On the basis of the existing comprehensive score, the dependency relationship between components is further considered to more accurately locate the root cause. For example, even if the direct error log score of a certain component is not high, but if it is a common dependency of multiple faulty components, it may be the root cause.

[0079] Embodiments of the present application can identify performance bottlenecks, resource competition, and other implicit faults that cannot be discovered by pure log analysis, and based on the topological dependency relationship, can reversely deduce the propagation path of the fault to more accurately match a solution.

[0080] Optionally, in an embodiment of the present application, the test failure root cause is determined in combination with the comprehensive score and the dependency relationship, including: acquiring a causal dependency relationship between a component of a server test machine corresponding to a historical test case and a corresponding test failure root cause; determining an influence degree of a fault of the component on the test case based on the causal dependency relationship; performing counterfactual analysis on the failure root cause based on the influence degree to obtain an analysis result, to match a solution based on the analysis result.

[0081] Embodiments of the present application can learn the causal relationship between component faults and test failures from historical cases, for example, A component fault causes B component fault, and further causes test failure, to determine the influence degree of the fault of the component on the test case. The influence degree is a quantitative value representing the influence size of each component fault on the test failure, for example, the probability or number of times that a certain component fault causes a test failure is statistically calculated.

[0082] Further, the embodiment of the present application can perform counterfactual analysis on the failure root cause based on the influence degree to obtain an analysis result, and match a solution based on the analysis result. For example, the embodiment of the present application can make an assumption that component A does not fail, infer whether the test failure root cause occurs, and further obtain the importance of component A for each candidate test failure root cause, or determine whether component A is the main root cause of the test failure.

[0083] According to the above counterfactual analysis, the embodiment of the present application can determine the test failure root cause, find the corresponding solution from historical cases, for example, the embodiment of the present application can sort the solutions according to the effectiveness score, and on the basis of the sorting, promote the solutions involving component A.

[0084] Through the historical causal dependency relationship, the influence of component failure is evaluated, and surface analysis based on the current failure phenomenon is avoided to accurately locate the root cause. According to the analysis result, a solution is matched, which can quickly provide effective solutions and improve the operation and maintenance efficiency.

[0085] In combination Figure 2 As shown in FIG. 1, the working principle of the test failure root cause diagnosis method of the embodiment of the present application is described in detail.

[0086] Firstly, the embodiment of the present application can construct a configuration feature dictionary: define the hierarchical relationship of server components (such as "CPU" containing "model", "core number", "main frequency" and other sub-features).

[0087] Initialize the knowledge base: import 500+ historical cases (including configuration, log, root cause, solution), and complete the first fine-tuning of the BERT model.

[0088] As shown in FIG. 2, the embodiment of the present application can include the following steps: Figure 2 Step S201, a test failure signal is triggered.

[0089] Step S202, data is acquired. After the test failure signal is triggered, the structured test environment configuration data and multi-dimensional unstructured log data of the server under test in the current test environment are collected in real time.

[0090] For example, the embodiment of the present application can obtain the current server test machine from the test management platform. The server configuration data (various component models, quantities, OS, BMC version, etc.) is pulled from the mysql database of the test platform. The test script log, OS log and BMC log are collected in real time and stored in the log pool. The structured configuration data and multi-source log files are output.

[0091] ​Step S203, calculate the configuration similarity. Calculate the similarity of the current test environment configuration data and the test environment configuration data of the historical cases in the knowledge base module. Convert the structured configuration data into a feature vector, and calculate the similarity with the configuration vector in the historical case library by a weighted cosine similarity algorithm to obtain a similar configuration case set.

[0092] The embodiment of the application can obtain server configuration data for feature vectorization, normalize numerical features (such as memory capacity), and perform One-Hot encoding on category features (such as component model and CPU model). Then, similarity calculation is performed: load historical configuration cases from the knowledge base, sort according to the weighted cosine similarity, and retain configuration cases with a similarity greater than 0.7. Obtain a similar configuration list and a similarity score.

[0093] Step S204, log semantic analysis. Perform semantic analysis on multi-dimensional log information to extract log semantic features. Use a BERT model that is fine-tuned based on log field corpus to perform semantic encoding on the unstructured log to generate error type probability distribution and a time-stamped directed event graph.

[0094] The embodiment of the application can preprocess multi-source log texts such as OS logs, test script logs, and BMC logs, and perform log cleaning to filter timestamps, IPs, and other noise in the logs; use a log field dictionary to enhance segmentation. Then, perform semantic encoding, input the log segments into the fine-tuned BERT model, and output error type probability distribution. Then, perform event graph construction, extract error events, and generate directed edges according to timestamps; merge repeated events (such as continuous multiple “memory allocation failures”). Obtain error type labels and event graph JSON.

[0095] Step S205, configuration similarity and log semantic joint analysis. The embodiment of the application can determine the test failure root cause based on log semantic features, test environment configuration similarity, and historical case processing effectiveness score. The similarity value, semantic matching degree, and historical case effectiveness are fused by a weighted scoring model, and a candidate root cause list is output according to the comprehensive score.

[0096] For example, the embodiment of the application can perform multi-dimensional fusion. For each similar case, calculate the comprehensive score: Score=0.4×Config_Sim+0.4×Semantic_Match+0.2×Historical_Effectiveness.

[0097] Wherein, Config_Sim is a test environment configuration similarity, Semantic_Match is a semantic matching degree of log semantic features, and Historical_Effectiveness is a historical case processing effectiveness.

[0098] Wherein, the semantic matching degree is calculated by an event graph subgraph isomorphism algorithm.

[0099] A root cause diagnosis candidate set is obtained.

[0100] Step S206, retrieving a knowledge base based on the analysis result. The knowledge base for storing historical test cases and corresponding solutions is retrieved to determine a test failure root cause and recommend a solution.

[0101] Embodiments of the present application can process the root cause diagnosis result candidate set according to: 1. retrieving a historical solution corresponding to the root cause in the knowledge base; 2. ranking according to the effectiveness score and recommending a Top-1 solution; 3. recording the diagnosis result to the knowledge base (effective after manual confirmation).

[0102] Step S207, recommending a solution. The solution is ranked according to the effectiveness to be recommended.

[0103] Step S208, feedback optimization. The root cause and solution confirmed by the manual are written back to the knowledge base, and the model parameters and case weights are dynamically adjusted according to the feedback result. According to the effectiveness evaluation of the user feedback, the calculation method of the test failure root cause and the recommendation standard of the solution are optimized.

[0104] The manual effectiveness score of the recommended solution (1-5 stars).

[0105] Process: if the score is ≥4 stars: automatically mark the case as "high-quality case" and improve the Historical_Effectiveness weight. If the score is ≤2 stars: trigger manual intervention, correct the root cause, and re-store it in the knowledge base, and fine-tune the joint analysis model in reverse. Get the updated knowledge base and model parameters.

[0106] Based on the above process, embodiments of the present application can implement the following embodiments.

[0107] Scenario: a server test case "memory stress test" fails, and the test machine configuration is "CPU: Intel Xeon E5-2680 v4, memory: 32GB DDR4 2133MHzx4, OS: CentOS 7.9".

[0108] S1 Data acquisition: Configuration data: structured feature vector (CPU model: E5-2680 v4, memory capacity: 128GB, OS version: CentOS 7.9, etc.)

[0109] Log snippet: OS log: "Out of memory: Kill process 1234 (memtest) score 582 or sacrifice child" Test script log: "[ERROR] Memory allocation failed, 5 consecutive 4GB space allocation timeouts" S2 Configuration similarity calculation: Matched 3 similar cases from the knowledge base (similarity 0.82, 0.78, 0.73), all with "same CPU model + memory capacity ≥ 64GB" configuration.

[0110] S3 Log semantic analysis: Error label: "Memory overflow (probability 92%)".

[0111] Event graph: "Memory allocation failed → Process killed" (timestamp continuous, correlation 0.95).

[0112] S4 Joint analysis: Comprehensive score: Case 1: 0.4 × 0.82 + 0.4 × 0.95 + 0.2 × 0.9 (historical solution effective) = 0.87; Case 2: 0.4 × 0.78 + 0.4 × 0.8 + 0.2 × 0.7 = 0.77; Case 3: 0.4 × 0.73 + 0.4 × 0.75 + 0.2 × 0.6 = 0.70.

[0113] Output: Top-1 root cause "Memory allocation strategy unreasonable, not enabled large page memory".

[0114] S5 Solution recommendation: Recommended solution: "Execute echo 1> / sys / kernel / mm / hugepages / hugepages-2048kB / nr_hugepages to enable large page memory, restart test service".

[0115] Manual verification: After execution, the test passes, mark the solution effective and store it in the knowledge base.

[0116] In summary, the embodiment of the present application can automatically complete root cause positioning in a short time through automatic configuration matching and semantic analysis, greatly improving the diagnosis efficiency. It supports concurrent processing of multiple test failure cases, is suitable for test scenarios of large-scale server clusters, and significantly shortens the overall test cycle. Combined with server configuration similarity and log context semantics (such as error association chain), it greatly reduces the analysis misjudgment rate. Improve accuracy. Structured storage of historical cases of configuration, error patterns and solutions forms a traceable knowledge base, solving the problem of strong dependence on traditional manual experience and easy loss. Reduce the dependence on senior test engineers, junior personnel can also use the system to quickly locate problems, greatly reducing the enterprise labor cost.

[0117] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment.

[0118] As shown in Figure 3 The embodiment of the present application also provides a test failure root cause diagnosis device 10, which comprises an acquisition module 100, an analysis module 200 and a diagnosis module 300.

[0119] Specifically, the acquisition module 100 is used for capturing a test failure signal of at least one server test machine, and determining a test case based on the test failure signal, to acquire multi-source log information and test environment configuration data of the test case.

[0120] The analysis module 200 is used for calculating test environment configuration similarity of the test case and historical cases based on the test environment configuration data, and analyzing the multi-source log information to obtain corresponding log semantic features.

[0121] The diagnosis module 300 is used for calculating a comprehensive score of the test case based on the test environment configuration similarity and the log semantic features, determining a test failure root cause of the test case based on the comprehensive score, matching a corresponding solution based on the test failure root cause, and pushing the solution to the at least one server test machine.

[0122] Optionally, in an embodiment of the present application, the diagnosis module 300 comprises a matching unit, a sorting unit and a determination unit.

[0123] The matching unit is used for matching a plurality of historical solutions based on the test failure root cause.

[0124] The sorting unit is used for sorting the plurality of historical solutions based on the effectiveness scores corresponding to the plurality of historical solutions to obtain a solution recommendation table.

[0125] The determining unit is configured to determine a solution to the test failure root cause based on the scheme recommendation table, and store the solution, the test failure root cause, and the effectiveness score input by the user based on an execution result of the solution, or determine a new solution based on an order of the scheme recommendation table.

[0126] Optionally, in an embodiment of the present application, the test failure root cause diagnosis apparatus 10 further comprises a receiving module, a first judging module, and a second judging module.

[0127] The receiving module is configured to execute the solution and receive the effectiveness score input by the user.

[0128] The first judging module is configured to judge whether the effectiveness score is greater than or equal to a first preset score, and if so, optimize the weight of the solution in the historical effectiveness score based on the effectiveness score.

[0129] The second judging module is configured to judge whether the effectiveness score is less than or equal to a second preset score, and if so, correct the test failure root cause based on the actual test failure root cause input by the user, and optimize the weight of the comprehensive score calculation of the test case based on the effectiveness score, wherein the second preset score is less than the first preset score.

[0130] Optionally, in an embodiment of the present application, the diagnosis module 300 comprises a first calculating unit, an assigning unit, and a second calculating unit.

[0131] The first calculating unit is configured to calculate the semantic similarity between the test case and the historical case based on the log semantic features.

[0132] The assigning unit is configured to assign corresponding weights to the test environment configuration similarity, the semantic similarity, and the historical effectiveness score corresponding to the historical case, respectively.

[0133] The second calculating unit is configured to calculate the comprehensive score of the test case based on the weights, the test environment configuration similarity, the semantic similarity, and the historical effectiveness score, and determine the test failure root cause based on the comprehensive score.

[0134] Optionally, in an embodiment of the present application, the analysis module 200 comprises a cleaning unit, a third calculating unit, and an extracting unit.

[0135] The cleaning unit is configured to clean the multi-source log information, and segment the cleaned multi-source log information by using a pre-constructed log field dictionary to obtain a plurality of log segments.

[0136] The third calculating unit is configured to calculate the error type probability distribution based on the plurality of log segments.

[0137] The extraction unit is configured to extract error events based on the error type probability distribution, and obtain log semantic features.

[0138] Optionally, in an embodiment of the present application, the analysis module 200 further comprises a generation unit and a fourth calculation unit.

[0139] The generation unit is configured to generate a corresponding directed edge based on the timestamp of the error event.

[0140] The fourth calculation unit is configured to construct an event graph using the directed edge, and calculate semantic similarity based on the event graph.

[0141] Optionally, in an embodiment of the present application, the analysis module 200 further comprises a definition unit, a construction unit and a training unit.

[0142] The definition unit is configured to define a hierarchical relationship of the server components.

[0143] The construction unit is configured to construct a log field dictionary based on the hierarchical relationship.

[0144] Optionally, in an embodiment of the present application, the extraction unit comprises an import unit and a training unit.

[0145] The import unit is configured to import a plurality of historical test cases satisfying a preset case condition.

[0146] The training unit is configured to construct a pre-training model based on the plurality of historical test cases, and calculate the error type probability distribution using the pre-training model.

[0147] Optionally, in an embodiment of the present application, the analysis module 200 comprises a processing unit, a conversion unit and a fifth calculation unit.

[0148] The processing unit is configured to extract numerical features from the test environment configuration data, and perform normalization processing on the numerical features to obtain numerical data.

[0149] The conversion unit is configured to perform variable conversion on the category features in the test environment configuration data to obtain encoded data.

[0150] The fifth calculation unit is configured to calculate the cosine similarity between the test case and the plurality of historical test cases based on the numerical data and the encoded data, and obtain the historical case based on the cosine similarity.

[0151] Optionally, in an embodiment of the present application, the fifth calculation unit comprises a judgment subunit, a first acquisition subunit, a calculation subunit and a reminding subunit.

[0152] The judgment subunit is configured to judge whether there is at least one case in the historical test case with a cosine similarity greater than a preset similarity threshold.

[0153] The first acquisition subunit is configured to obtain the historical case based on the cosine similarity when there is at least one case.

[0154] The calculation subunit is configured to verify the calculation validity of the cosine similarity by using the historical test case when there is no at least one case.

[0155] The reminding subunit is configured to generate an error reminder when the calculation validity does not satisfy a preset valid condition, and otherwise, generate a new case reminder.

[0156] Optionally, in an embodiment of the present application, the diagnosis module 300 further comprises a first acquisition unit, a conversion unit, a second acquisition unit, a sixth calculation unit and a diagnosis unit.

[0157] The first acquisition unit is configured to acquire multi-source monitoring data of at least one server test machine.

[0158] The conversion unit is configured to convert the multi-source monitoring data into a corresponding feature vector.

[0159] The second acquisition unit is configured to acquire an architecture topology relationship of the at least one server test machine, so as to capture a dependency relationship between components of the at least one server test machine based on the architecture topology relationship.

[0160] The sixth calculation unit is configured to calculate a comprehensive score in combination with the feature vector, a test environment configuration similarity and a log semantic feature.

[0161] The diagnosis unit is configured to determine a test failure root cause in combination with the comprehensive score and the dependency relationship.

[0162] Optionally, in an embodiment of the present application, the diagnosis unit comprises a second acquisition subunit, a determination subunit and an analysis subunit.

[0163] The second acquisition subunit is configured to acquire a causal dependency relationship between a component of a server test machine corresponding to a historical test case and a corresponding test failure root cause.

[0164] The determination subunit is configured to determine an influence degree of a fault of the component on a test case based on the causal dependency relationship.

[0165] The analysis subunit is configured to perform counterfactual analysis on the failure root cause based on the influence degree to obtain an analysis result, and match a solution based on the analysis result.

[0166] The features of the embodiments of the diagnostic device for the root cause of the test failure can refer to the related descriptions of the embodiments of the diagnostic method for the root cause of the test failure, which will not be repeated here.

[0167] The embodiments of the present application also provide an electronic device, comprising a memory and a processor, the memory stores a computer program, and the processor is configured to execute the computer program to perform the steps in any of the above-mentioned embodiments of the diagnostic method for the root cause of the test failure.

[0168] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program, wherein the computer program is configured to perform the steps in any of the above-mentioned embodiments of the diagnostic method for the root cause of the test failure when executed.

[0169] In an example embodiment, the above-mentioned computer readable storage medium can include but is not limited to: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0170] The embodiments of the present application also provide a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps in any of the above-mentioned embodiments of the diagnostic method for the root cause of the test failure.

[0171] The embodiments of the present application also provide another computer program product, which comprises a non-volatile computer readable storage medium, and the non-volatile computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps in any of the above-mentioned embodiments of the diagnostic method for the root cause of the test failure.

[0172] The skilled person can further realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in the above description in general terms. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0173] The above describes in detail the diagnostic method for testing failure root cause provided by the present application. The principles and implementation manners of the present application are described by using specific examples, and the above description of the examples is only applicable to help understand the method of the present application and the core idea thereof. It should be pointed out that, for those skilled in the art, some improvements and modifications can be made to the present application without departing from the principles of the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A method for diagnosing the root cause of test failure, characterized in that, Includes the following steps: Capture test failure signals from at least one server test machine, and determine test cases based on the test failure signals to obtain multi-source log information and test environment configuration data for the test cases; Based on the test environment configuration data, the similarity of the test environment configuration between the test case and the historical cases is calculated, and the multi-source log information is analyzed to obtain the corresponding log semantic features; The test case is calculated by combining the similarity of the test environment configuration and the semantic features of the logs. The root cause of the test failure is determined based on the comprehensive score. The corresponding solution is matched based on the root cause of the test failure and the solution is pushed to at least one of the server test machines.

2. The method for diagnosing the root cause of test failure according to claim 1, characterized in that, The solutions based on the root cause matching of the test failure include: Based on the root cause of the test failure, multiple historical solutions were matched; The historical solutions are sorted based on their effectiveness scores to obtain a solution recommendation table, and the solution for determining the root cause of the test failure is determined based on the solution recommendation table. Execute the solution, and store the solution, the root cause of the test failure, and the validity score input by the user based on the execution result of the solution, or determine a new solution based on the order of the solution recommendation table.

3. The method for diagnosing the root cause of test failure according to claim 2, characterized in that, After determining the solution to the root cause of the test failure based on the solution recommendation table, the method further includes: Execute the solution and receive the validity score input by the user; Determine whether the validity score is greater than or equal to a first preset score. If it is greater than or equal to the first preset score, optimize the weight of the solution in the historical validity score based on the validity score. Determine whether the validity score is less than or equal to the second preset score. If it is less than or equal to the second preset score, then correct the root cause of the test failure based on the actual root cause of the test failure input by the user, and optimize the weight of the comprehensive score calculation of the test case based on the validity score, wherein the second preset score is less than the first preset score.

4. The method for diagnosing the root cause of test failure according to claim 3, characterized in that, The step of calculating a comprehensive score for the test case based on the similarity of the test environment configuration and the semantic features of the logs, and determining the root cause of the test case failure based on the comprehensive score, includes: The semantic similarity between the test cases and the historical cases is calculated based on the semantic features of the logs; Assign corresponding weights to the test environment configuration similarity, the semantic similarity, and the historical validity scores corresponding to the historical cases; The comprehensive score of the test case is calculated based on the weight, the similarity of the test environment configuration, the semantic similarity, and the historical validity score, and the root cause of the test failure is determined based on the comprehensive score.

5. The method for diagnosing the root cause of test failure according to claim 4, characterized in that, The analysis of the multi-source log information yields corresponding log semantic features, including: The multi-source log information is cleaned, and the cleaned multi-source log information is segmented using a pre-built log domain dictionary to obtain multiple log fragments; Calculate the error type probability distribution based on multiple log fragments; Error events are extracted based on the error type probability distribution to obtain the log semantic features.

6. The method for diagnosing the root cause of test failure according to claim 5, characterized in that, After extracting error events based on the error type probability distribution, the process further includes: Generate corresponding directed edges based on the timestamps of the error events; An event graph is constructed using the directed edges, and the semantic similarity is calculated based on the event graph.

7. The method for diagnosing the root cause of test failure according to claim 5, characterized in that, Before segmenting and cleaning the multi-source log information using a pre-built log domain dictionary, the process also includes: Define the hierarchical relationship of server components; The log domain dictionary is constructed based on the hierarchical relationship.

8. The method for diagnosing the root cause of test failure according to claim 5, characterized in that, The step of extracting error events based on the error type probability distribution to obtain the log semantic features includes: Import multiple historical test cases that meet the preset test case conditions; A pre-trained model is constructed based on multiple historical test cases to calculate the error type probability distribution.

9. The method for diagnosing the root cause of test failure according to claim 1, characterized in that, The calculation of the test environment configuration similarity between the test cases and historical cases based on the test environment configuration data includes: Numerical features are extracted from the test environment configuration data, and the numerical features are normalized to obtain numerical data. The categorical features in the test environment configuration data are transformed to obtain coded data; Based on the numerical data and the encoded data, the cosine similarity between the test case and multiple historical test cases is calculated, and the historical test cases are obtained based on the cosine similarity.

10. The method for diagnosing the root cause of test failure according to claim 9, characterized in that, The process of obtaining the historical cases based on the cosine similarity includes: Determine whether there is at least one case in the historical test cases whose cosine similarity is greater than a preset similarity threshold; If at least one of the aforementioned cases exists, the historical cases are obtained based on the cosine similarity. If at least one of the aforementioned cases does not exist, the validity of the cosine similarity calculation is verified using the historical test cases. If the calculation validity does not meet the preset validity conditions, an error reminder is generated; otherwise, a new case reminder is generated.

11. The method for diagnosing the root cause of test failure according to claim 1, characterized in that, The step of calculating a comprehensive score for the test case based on the similarity of the test environment configuration and the semantic features of the logs, and determining the root cause of the test case failure based on the comprehensive score, further includes: Acquire multi-source monitoring data from at least one of the server test machines; The multi-source monitoring data is converted into corresponding feature vectors; Obtain the architectural topology of at least one of the server test machines to capture the dependencies between the components of at least one of the server test machines based on the architectural topology. The comprehensive score is calculated by combining the feature vector, the test environment configuration similarity, and the log semantic features; The root cause of the test failure is determined by combining the overall score and the dependency relationship.

12. The method for diagnosing the root cause of test failure according to claim 11, characterized in that, The determination of the root cause of the test failure by combining the comprehensive score and the dependency relationship includes: Obtain the causal dependencies between the components of the server test machine corresponding to the historical test cases and the root causes of the corresponding test failures; Based on the causal dependency, determine the degree of impact of the component failure on the test case; Based on the degree of impact, a counterfactual analysis is performed on the root cause of the failure to obtain the analysis results, and the solution is matched based on the analysis results.

Images