Terminal performance detection method and system based on similar fault defect reason analysis
By establishing a correlation between test cases and the root causes of defects, the problems of low efficiency and poor accuracy in testing smart terminal software were solved, achieving efficient and accurate defect detection and improving the stability and reliability of terminal software.
Patent Information
- Application Number
- CN202511494093.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-20
- Publication Date
- 2026-02-13
AI Technical Summary
Existing smart terminal software testing methods are inefficient, inaccurate, unable to deeply match test cases with the root causes of defects, lack universality, and are easily affected by subjective factors and are costly.
By establishing the correlation between test cases and the root causes of defects, and using database query technology to quickly filter relevant test cases, a terminal performance testing method is established, including obtaining test case sets, executing tests, analyzing root causes, building mapping tables and typical test case sets, and optimizing the testing path.
It enables rapid and accurate defect detection, improves testing efficiency and quality, reduces the risk of software defects, covers a variety of terminal functions, and increases the defect detection rate.
Smart Images

Figure CN121524045A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of intelligent terminal defect detection technology, and more specifically, to a method and system for active protection and robustness detection of terminals based on the analysis of the root causes of terminal defects. Background Technology
[0002] With the widespread use of smart terminal devices, their software quality directly affects user experience and system stability. However, the complexity of smart terminal software is increasing daily, and defects have become a major factor affecting quality. Traditional software testing methods are no longer sufficient to meet the high complexity and large-scale defect detection needs of smart terminal software.
[0003] Existing test case selection methods have certain limitations. Manual selection relies on experience, is susceptible to subjective factors, and is inefficient and lacks a systematic approach. Automated selection methods are mostly based on simple rules and cannot deeply match test cases with the root causes of defects. Machine learning-based selection methods require large amounts of data, have high training costs, and are insufficient in interpretability and specificity. Furthermore, existing methods are mostly limited to specific scenarios and lack universality.
[0004] Therefore, there is an urgent need for an efficient and accurate test case selection method to improve the efficiency and quality of defect detection in smart terminals and ensure product stability and reliability. Summary of the Invention
[0005] The purpose of this invention is to address the above-mentioned problems by proposing a method for proactive protection and robustness detection of terminals based on the root cause analysis of defects in data acquisition terminals. By establishing the correlation between test cases and defect causes and utilizing database query technology, relevant test cases can be quickly and accurately selected based on defect causes. This enables targeted testing of software data acquisition terminal R&D defects, improves testing efficiency and quality, and reduces the risk of software defects.
[0006] The technical solution of this invention is: This invention provides a terminal performance testing method based on the analysis of similar fault defects, comprising the following steps: S1. Obtain a set of terminal test cases that cover multiple scenarios and functions. The set of test cases is used to evaluate the terminal performance and the expected results of each test case are recorded in advance. S2. Perform detection operations on each test case in the test case set, compare the actual running results with the expected results to determine whether there are defects, and record the terminal defect information; S3. Analyze the terminal defect information in the defect database to obtain the root cause, classify and organize the root causes to form a root cause analysis table, and mark each root cause and its corresponding defect information in the root cause analysis table; S4, for each test case in the test case set, extract the execution condition and result feature in the root cause analysis result as feature data, match the feature data with the root cause to establish an association relationship and construct a mapping table of test cases and root causes; S5, obtaining the feature data of the test cases, screening out the test cases highly related to each root cause, constructing a typical case set, detecting the terminal through the typical case set, recording the defect triggering situation in the detection process, and adjusting the case combination in the typical case set according to the defect triggering situation to optimize the detection path.
[0007] Further, S1 comprises: Collecting test cases covering multiple typical scenarios; For each functional detection item in the test case set, obtaining the corresponding test scene data, and constructing an initial test case library; Classifying the initial test case library to form a test case set suitable for different terminal performance evaluation, and pre-setting execution conditions and expected results for each test case in the test case set to guide the subsequent detection process and defect comparison.
[0008] Further, the test case involves multiple functional detection items of the terminal, including electric energy meter data acquisition, state quantity acquisition, pulse quantity acquisition, alternating current analog quantity acquisition, real-time and current data, historical daily data, meter reading daily data, historical monthly data, electric energy meter operation status monitoring, power quality data statistics, historical curve data, clock call measurement, power control period and fixed value, terminal parameter, meter reading parameter, control function, terminal event and remote communication.
[0009] Further, S2 comprises: For each test case in the test case set, obtaining its execution condition and test target; According to the execution condition, running the corresponding test case on the terminal, obtaining the state data in the running process, and comparing with the expected result to determine whether the terminal has defects; If it is determined that there is a defect, record the specific performance information of the defect, including defect description and corresponding test case identification, and store it as defect information in the defect database.
[0010] Further, S3 comprises: Obtaining the specific performance data in the terminal defect information, the specific performance data including defect description, corresponding test case identification and defect triggering condition; Using the cause-effect chain analysis method to trace the cause of the defect, first analyzing the direct cause of the defect, and then further tracing to the root cause; The root causes are categorized and organized to form a root cause analysis table. Each record in the root cause analysis table includes a root cause identifier, a corresponding list of defect information, and a list of test case identifiers that triggered the root cause.
[0011] Furthermore, S4 includes: For each test case in the test case set, the execution conditions and result features are extracted as feature data. The execution conditions include the environment configuration and input data required for the test case to run, and the result features include the output data and state changes after the test case runs. The feature data is matched with the root cause to establish an association. Based on the association, a mapping table between test cases and root causes is constructed. Each record in the mapping table contains a test case identifier, a list of feature data, and a corresponding root cause identifier.
[0012] Furthermore, S5 includes: Based on the mapping table, test cases that are highly relevant to each root cause are selected, and a typical test case set is constructed. Each test case in the typical test case set is strongly related to at least one root cause. Obtain each test case from the typical test case set, run the corresponding test case on the terminal according to the execution conditions, and record the defect triggering situation during the detection process, including the defect description, the corresponding test case identifier, and the triggering conditions; Adjust the combination of test cases in the typical test case set according to the defect triggering situation, optimize the detection path, and ensure that the typical test case set can cover all known root causes and maximize detection efficiency.
[0013] Furthermore, it also includes S6, constructing test case models that trigger similar defects based on the detection results of typical use case sets and the characteristics of triggering defects, specifically: Obtain defect triggering data of typical test case sets during terminal detection process. The defect triggering data includes the test case identifier that triggers the defect, the defect description, the triggering conditions, and the corresponding running status data. Analyze the defect triggering data, extract the patterns and conditions that trigger defects, and construct test case models that trigger similar defects; Set filtering parameters for the test case model. The filtering parameters include the input data range, environment configuration requirements, and running status thresholds, which are used to subsequently filter test cases that may trigger similar defects.
[0014] Furthermore, it also includes S7, calculating the matching degree between each test case in the test case set and the screening parameters based on the test case model and its screening parameters, selecting test cases that may trigger similar defects based on the matching degree to construct a test case set, and concentrating resources for in-depth testing, specifically: Obtaining a screening parameter set in the test case model, the screening parameter set including an input data range, an execution environment configuration, and a running state threshold value; For each test case in the test case set, extracting an execution condition and a result feature as feature data, the execution condition including an environment configuration and input data required for running the test case, and the result feature including output data and state changes after running the test case; Comparing the feature data of the test case with the screening parameter set item by item, calculating a similarity value of each item of feature data with the screening parameter set, and calculating a whole matching degree of the test case with the screening parameter set according to the similarity values of the items of feature data; According to the matching degree sorting result, screening out test cases with a matching degree higher than a preset threshold value, constructing a test case subset, and centrally arranging resources for deep detection.
[0015] A terminal performance detection system based on same-type fault defect reason analysis, the system being configured to perform the detection method.
[0016] The present application has the following beneficial effects: The present application discloses a terminal test method, which comprehensively evaluates terminal performance by constructing a test case set containing multiple typical scenarios; the method executes test cases and records defect information, traces root causes by adopting causal chain analysis, extracts test case features and establishes an association with root causes, constructs a typical test case set based on the association for targeted detection, and shortens a defect discovery path; further, a test model triggering same-type defects is constructed, and a test case subset most likely triggering defects is screened for efficient detection.
[0017] The method of the present application covers multiple functional items such as electric energy meter data acquisition and state quantity acquisition, quickly locates potential defects through deep testing, and improves test efficiency and defect discovery rate. The method realizes systematic analysis from defect phenomena to root causes, establishes precise association between test cases and defect causes, and provides an efficient and reliable solution for terminal testing.
[0018] Other features and advantages of the present application will be described in detail in the following specific embodiments. BRIEF DESCRIPTION OF DRAWINGS
[0019] The above and other objects, features and advantages of the present application will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which like reference characters refer to like parts throughout the several views, and in which:
[0020] Figure 1 A flowchart of a terminal performance detection method based on same-type fault defect reason analysis is shown. DETAILED DESCRIPTION
[0021] Preferred embodiments of the present application will be described in more detail with reference to the drawings. Although preferred embodiments of the present application are shown in the drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein.
[0022] Example 1
[0023] Figure 1 A flowchart of a terminal performance detection method based on similar fault defect cause analysis is shown.
[0024] As Figure 1 shown, the present application provides a terminal performance detection method based on similar fault defect cause analysis, comprising the following steps: S1, obtaining a terminal test case set containing multiple scenarios and function coverage, the test case set being used for evaluating terminal performance, and pre-recording expected results of each test case; Specifically, it includes collecting test cases covering multiple typical scenarios; for each function detection item in the test case set, obtaining corresponding test scenario data to construct an initial test case library; classifying the initial test case library to form a test case set suitable for different terminal performance evaluation, and pre-setting execution conditions and expected results for each test case in the test case set to guide the subsequent detection process and defect comparison.
[0025] In this embodiment, the test cases involve multiple function detection items of the terminal, including power meter data acquisition, state quantity acquisition, pulse quantity acquisition, AC analog quantity acquisition, real-time and current data, historical daily data, meter reading daily data, historical monthly data, power meter operation status monitoring, power quality data statistics, historical curve data, clock polling, power control period and fixed value, terminal parameters, meter reading parameters, control function, terminal event and remote communication.
[0026] S2, performing detection operation on each test case in the test case set, comparing actual running results with expected results to determine whether there is a defect, and recording terminal defect information; Specifically, it includes obtaining execution conditions and test targets for each test case in the test case set; running the corresponding test case on the terminal according to the execution conditions, obtaining state data in the running process, and comparing with the expected results to determine whether there is a defect in the terminal; if it is determined that there is a defect, recording specific performance information of the defect, including defect description and corresponding test case identification, and storing the defect information in a defect database.
[0027] In the embodiment, the recorded terminal defect information includes inaccurate power meter data acquisition, incomplete power meter data acquisition, communication failure, protocol incompatibility, etc.; for example, after executing a use case involving clock polling, the actual clock data is compared with the expected consistency, and if it does not match, it is recorded as a communication failure.
[0028] S3, analyzing the terminal defect information in the defect database to obtain root causes, classifying and arranging the root causes to form a root cause analysis table, and marking each root cause and its corresponding defect information in the root cause analysis table; Specifically, it includes obtaining specific performance data in the terminal defect information, the specific performance data including defect description, corresponding test case identifier, and defect trigger condition; using a cause-effect chain analysis method to trace the causes of defects, first analyzing the direct causes of defects, and then further tracing to the root causes; classifying and arranging the root causes to form a root cause analysis table, each record in the root cause analysis table containing a root cause identifier, a corresponding defect information list, and a test case identifier list triggering the root cause.
[0029] In the embodiment, the recorded terminal defect information is extracted from the defect database, such as incomplete data acquisition or protocol incompatibility, and the causes are traced step by step from the defect phenomenon. A cause-effect chain is constructed using a cause-effect chain analysis method, for example, for incomplete data acquisition (phenomenon) -> tracing to the failure of the collection task to be performed according to the plan (direct cause) -> further tracing to the application program logic bug or ineffective handling of abnormal situations (root cause). The traced root causes are classified and arranged, for example, memory leaks are classified as one category, and boundary value handling is classified as another category, to form a root cause analysis table, in which each category is marked with corresponding defect information such as phenomenon description and trigger condition. The root cause analysis table is updated to ensure that the correspondence between each root cause and defect information is clear for subsequent feature extraction.
[0030] S4, for each test case in the test case set, extracting the execution conditions and result features in the root cause analysis result as feature data, matching the feature data with the root causes to establish an association relationship and construct a mapping table of test cases and root causes; Specifically, it includes: for each test case in the test case set, extracting the execution conditions and result features as feature data, the execution conditions including the environment configuration and input data required for the test case to run, and the result features including the output data and state changes after the test case runs; matching the feature data with the root causes to establish an association relationship, and constructing a mapping table of test cases and root causes based on the association relationship, each record in the mapping table containing a test case identifier, a feature data list, and a corresponding root cause identifier.
[0031] In this embodiment, the execution conditions (such as boundary values of specific acquisition tasks) and result characteristics (such as data incompleteness phenomena) of each root cause are extracted from the root cause analysis table. For each use case in the test case set, the execution conditions and expected results are analyzed to generate feature data. For example, a use case involving terminal parameters includes parameter setting conditions and potential memory usage. The generated feature data is matched with the root causes in the root cause analysis table, for example, if the feature data shows abnormal memory usage, it is matched to the memory leak root cause, and the association is established. Based on the matching result, a mapping table is constructed, in which each test case is linked to the corresponding root cause, forming a corresponding relationship between test case id and root cause id. The integrity of the mapping table is verified to ensure that all feature data is matched, and the reliability of the association relationship is improved.
[0032] S5, acquire feature data of test cases, filter out test cases highly related to each root cause, construct a typical use case set, detect the terminal through the typical use case set, record the defect triggering situation in the detection process, and adjust the use case combination in the typical use case set according to the defect triggering situation to optimize the detection path.
[0033] Specifically, it includes filtering out test cases highly related to each root cause according to the mapping table, constructing a typical use case set, each use case in the typical use case set has strong association with at least one root cause; acquire each test case in the typical use case set, run the corresponding test case on the terminal according to the execution conditions, record the defect triggering situation in the detection process, including defect description, corresponding test case identification and triggering condition; adjust the use case combination in the typical use case set according to the defect triggering situation, which can delete inefficient use cases and supplement efficient use cases, optimize the detection path, and ensure that the typical use case set can cover all known root causes and maximize the detection efficiency.
[0034] In this embodiment, the feature data of test cases is obtained from the mapping table, the correlation degree of each use case with the root cause is calculated, for example, the similarity calculation method is used to evaluate the degree of feature matching. According to the correlation degree, highly related test cases are selected, for example, set a threshold to select use cases related to memory leak, and construct a typical use case set.
[0035] The terminal is detected by using the typical use case set, for example, the selected use case set is executed, and the defect triggering frequency and specific situation are recorded. Analyze the recorded defect triggering situation, for example, if some use case combination frequently triggers similar defects, adjust the combination and preferentially include high triggering use cases. Based on the adjusted use case combination, the detection path is optimized, the path is shortened to quickly locate the problem, and the overall detection efficiency is improved. The optimized path is iteratively verified to ensure that the defect discovery rate is improved in the acquisition terminal such as the electric energy meter data scene.
[0036] In one example, S6, a test case model triggering similar defects is constructed based on the detection results of typical use case sets and the characteristics of triggering defects.
[0037] Specifically, defect triggering data of the typical use case sets in the terminal detection process is obtained, the defect triggering data includes test case identification triggering defects, defect description, triggering condition and corresponding running state data; the defect triggering data is analyzed, the mode and condition triggering defects are extracted, and a test case model triggering similar defects is constructed; the test case model is set with screening parameters, the screening parameters include input data range, environment configuration requirement and running state threshold, which are used for subsequent screening of test cases that may trigger similar defects.
[0038] In this embodiment, the detection results and characteristics are used to construct a model to describe the mode of triggering similar defects. The characteristics triggering defects in the detection results are summarized, such as memory problems under specific execution conditions. These characteristics are integrated into a model to predict use cases triggering similar defects by associating characteristics. For example, for memory leak results, a test case model is constructed.
[0039] In this embodiment, based on the extracted test case characteristics, the typical use cases are screened to detect the terminal, the test path for discovering terminal R&D defects is shortened, and the potential problems are quickly located.
[0040] In one example, S7, according to the test case model and its screening parameters, the matching degree of each test case in the test case set with the screening parameters is calculated, the test case set triggering similar defects is constructed according to the matching degree, and the resources are concentrated for in-depth detection.
[0041] Specifically, the screening parameters set in the test case model are obtained, the screening parameters include input data range, execution environment configuration and running state threshold; for each test case in the test case set, the execution condition and result characteristics thereof are extracted as characteristic data, the execution condition includes the environment configuration and input data required for the test case to run, and the result characteristics include the output data and state change after the test case runs; the characteristic data of the test case is compared with the screening parameters item by item, the similarity value of each characteristic data with the screening parameters is calculated, the similarity value is determined by the numerical difference or the interval overlap ratio; according to the similarity value of each characteristic data, the overall matching degree of the test case with the screening parameters is calculated by weighting; the weight is pre-set according to the influence degree of the characteristic data on triggering defects; according to the matching degree sorting result, the test cases with a matching degree higher than a pre-set threshold are screened, a test case set is constructed, and resources are concentrated for in-depth detection.
[0042] In the embodiment, according to the output result of the typical use case set detection, the test case set is screened, and according to the set probability threshold or weight threshold, a test case subset most likely to trigger the same type of defects of the terminal is screened out, so that resources are concentrated to efficiently detect potential same type of defects, and test efficiency and defect discovery rate are improved.
[0043] Embodiment 2
[0044] The present application provides a terminal performance detection system based on the same type of fault defect cause analysis, which is configured to perform the detection method.
[0045] The above has described the embodiments of the present application, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those skilled in the art without departing from the scope and spirit of the described embodiments.
Claims
1. A terminal performance detection method based on same fault defect cause analysis, characterized in that, The method comprises the following steps: S1, obtaining a terminal test case set containing multiple scenes and function covers, the test case set being used for evaluating terminal performance, and pre-recording expected results of each test case; S2, performing a detection operation on each test case in the test case set, comparing actual running results with expected results to determine whether there is a defect, and recording terminal defect information; S3, analyzing terminal defect information in a defect database to obtain root causes, classifying the root causes to form a root cause analysis table, and marking each root cause and corresponding defect information in the root cause analysis table; S4, for each test case in the test case set, extracting execution conditions and result features in the root cause analysis result as feature data, matching the feature data with the root causes to establish an association relationship, and constructing a mapping table of test cases and root causes; S5, obtaining feature data of the test cases, screening out test cases highly related to each root cause, constructing a typical case set, detecting the terminal through the typical case set, recording defect triggering conditions in the detection process, and adjusting case combinations in the typical case set according to the defect triggering conditions to optimize the detection path.
2. The terminal performance detection method based on the same failure defect cause analysis according to claim 1, wherein, S1 comprises: collecting test cases covering multiple typical scenes; for each function detection item in the test case set, obtaining corresponding test scene data to construct an initial test case library; classifying the initial test case library to form a test case set suitable for different terminal performance evaluations, and pre-setting execution conditions and expected results for each case in the test case set to guide subsequent detection processes and defect comparison.
3. The terminal performance detection method based on the same failure defect cause analysis according to claim 2, wherein, The test cases involve multiple function detection items of the terminal, including power meter data acquisition, state quantity acquisition, pulse quantity acquisition, alternating current analog quantity acquisition, real-time and current data, historical daily data, meter reading daily data, historical monthly data, power meter operation status monitoring, power quality data statistics, historical curve data, clock polling, power control period and fixed value, terminal parameters, meter reading parameters, control function, terminal event and remote communication.
4. The terminal performance detection method based on the same failure defect cause analysis of claim 1, wherein S2 It comprises: for each test case in the test case set, obtaining its execution conditions and test targets; running the corresponding test case on the terminal according to the execution conditions, obtaining state data in the running process, and comparing with the expected results to determine whether there is a defect in the terminal; if it is determined that there is a defect, recording specific performance information of the defect, including defect description and corresponding test case identifier, and storing the defect information in a defect database as defect information.
5. The terminal performance detection method based on the same failure defect cause analysis of claim 1, wherein S3 It comprises: obtaining specific performance data in the terminal defect information, the specific performance data including defect description, corresponding test case identifier and defect triggering condition; using a cause-and-effect chain analysis method to trace the causes of the defect, first analyzing the direct cause of the defect, and then further tracing to the root cause; classifying the root causes to form a root cause analysis table, each record in the root cause analysis table containing a root cause identifier, a corresponding defect information list and a test case identifier list triggering the root cause.
6. The terminal performance detection method based on the same failure defect cause analysis according to claim 1, wherein, S4 comprises: For each test case in the test case set, extract the execution conditions and result features as feature data, the execution conditions including the environment configuration and input data required for the test case to run, and the result features including the output data and state changes after the test case runs; Match the feature data with the root causes to establish a correlation relationship, and build a mapping table of test cases and root causes based on the correlation relationship, each record in the mapping table containing a test case identifier, a feature data list, and a corresponding root cause identifier.
7. The terminal performance detection method based on the same failure defect cause analysis of claim 1, wherein S5 It comprises: According to the mapping table, filter out test cases highly related to each root cause to build a typical case set, each case in the typical case set having strong correlation with at least one root cause; Obtain each test case in the typical case set, run the corresponding test case on the terminal according to the execution conditions, and record the defect triggering conditions during the detection process, including defect description, corresponding test case identifier, and triggering condition; According to the defect triggering conditions, adjust the case combination in the typical case set, optimize the detection path, and ensure that the typical case set can cover all known root causes and maximize the detection efficiency.
8. The terminal performance detection method based on the same failure defect cause analysis of claim 1, wherein, It also includes S6, building a test case model for triggering similar defects based on the detection results of the typical case set and the features of the triggered defects, specifically: Obtain the defect triggering data of the typical case set during terminal detection, which includes the test case identifier of the triggered defect, defect description, triggering condition, and corresponding running state data; Analyze the defect triggering data, extract the pattern and condition of triggering defects, and build a test case model for triggering similar defects; Set filtering parameters for the test case model, including input data range, environment configuration requirements, and running state threshold, which are used for subsequent screening of test cases that may trigger similar defects.
9. The terminal performance detection method based on the same failure defect cause analysis of claim 1, wherein, It also includes S7, according to the test case model and its filtering parameters, calculating the matching degree of each case in the test case set with the filtering parameters, and screening out test cases that may trigger similar defects to build a test case sub-set, and concentrating resources for in-depth detection, specifically: Obtain the filtering parameters set in the test case model, which include input data range, execution environment configuration, and running state threshold; For each test case in the test case set, extract its execution conditions and result features as feature data, the execution conditions including the environment configuration and input data required for the test case to run, and the result features including the output data and state changes after the test case runs; Compare the feature data of the test case with the filtering parameters item by item, calculate the similarity value of each feature data with the filtering parameters, and calculate the overall matching degree of the test case with the filtering parameters based on the similarity values of each feature data; According to the matching degree sorting result, filter out test cases with a matching degree higher than a preset threshold to build a test case sub-set and concentrate resources for in-depth detection.
10. A terminal performance detection system based on same fault defect cause analysis, characterized by, The system is configured to perform the detection method of any one of claims 1-9.