UI automatic test system and method based on database input parameters

Abstract

The invention provides a UI automatic test system and method based on database input parameters, and belongs to the technical field of data processing, and the system specifically comprises a data acquisition and management module which is responsible for acquiring diversified test input parameters from a database in real time; the page operation module is responsible for positioning page elements; the test execution module is used for realizing large-scale data driving test; the test result analysis and report module is responsible for collecting, processing and visualizing all results in the test execution process, automatically generating detailed test logs, integrating all test data and generating a structured test report, and the reliability degree of test processing is improved.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and in particular relates to a UI automated testing system and method based on database input parameters. Background Technology

[0002] As modern web applications become increasingly complex and business logic continues to evolve, user interface (UI) automated testing plays an increasingly crucial role in ensuring software product quality and user experience. Traditional UI automated test scripts often hard-code test data or store it in static files. This static data model cannot effectively simulate the diversity and dynamic changes of data in real business environments, resulting in insufficient test scenario coverage and difficulty in discovering potential defects caused by specific data combinations.

[0003] Furthermore, once business requirements change, data structures are adjusted, or the testing environment is updated, hard-coded test data needs to be manually modified one by one, which is time-consuming, labor-intensive, and prone to human error, severely restricting the sustainable integration and continuous delivery (CI / CD) process of testing.

[0004] Therefore, existing UI automation testing frameworks still have many shortcomings in terms of element location stability, error handling robustness, and intelligent test report generation. These factors collectively affect the reliability, efficiency, and value of automated testing. Building a testing platform that directly connects to the database can greatly improve the reliability of automated testing. However, this also makes it crucial to determine how to manage the database cache associated with test cases based on the risk of location deviation for page elements corresponding to different test cases, thereby improving the efficiency and reliability of testing. Therefore, there is an urgent need for a new type of UI automated testing system and method that can overcome the above-mentioned defects and achieve dynamic test data, efficient test execution, and intelligent test reports. Summary of the Invention

[0005] To achieve the objectives of this invention, the following technical solution is adopted: Specifically, this application provides a UI automation testing system based on database input parameters, which includes: Data Acquisition and Management Module: Responsible for establishing dynamic connections with various databases, acquiring diverse test input parameters from the databases in real time according to preset query conditions, providing data caching, determining the identification deviation data of the page elements corresponding to the test cases based on the test data of the test cases, and determining the caching control strategy for the database input parameters of the test cases based on the identification deviation data. Page Operation Module: Responsible for abstracting each page of the application into an independent page object. Using intelligent element positioning algorithm, it can dynamically adjust the positioning strategy to achieve the positioning of page elements. Test execution module: By combining with the data acquisition and management module, it dynamically injects different datasets from the database into the same test case, enabling large-scale data-driven testing; Test Result Analysis and Reporting Module: Responsible for collecting, processing, and visualizing all results during test execution, automatically generating detailed test logs, integrating all test data, generating structured test reports, and determining the update management method for the cache management strategy of the test cases of the target control strategy by utilizing the similarity between page elements corresponding to different test cases and test cases of the target control strategy, the cache management method of the database associated with the test cases of the target control strategy.

[0006] Specifically, the test input parameters include product code, user ID, and order number.

[0007] Furthermore, it also includes a fallback data mechanism, which means that when the database connection fails or the query returns no results, the system can automatically use predefined default or backup test data.

[0008] Secondly, this application provides a UI automation testing method based on database input parameters, applied to the aforementioned UI automation testing system based on database input parameters, specifically including: S1 determines the identification deviation data of the page elements corresponding to the test cases based on the test data of the test cases, determines the cache management strategy of the database input parameters of the test cases based on the identification deviation data, and determines the cache impact risk type of the test cases using the cache management strategy and the associated databases of different test cases. S2 determines the cache impact risk type of the test cases of the database, and determines the cache management method of the database by combining the test case data of the target control strategy in the test cases of the database. S3 utilizes the similarity between page elements corresponding to different test cases and test cases of the target control strategy, as well as the cache management method of the associated database of test cases of the target control strategy, to determine the update management method of the cache control strategy for test cases of the target control strategy.

[0009] Furthermore, the test data for the test cases includes the test results of the test cases in history and the identification deviation data of the test results.

[0010] Furthermore, the identification deviation data of the page element corresponding to the test case is determined based on whether the page element to be verified by the test case was successfully identified in the historical test results.

[0011] Furthermore, the method for determining the caching control strategy for the database input parameters of the test cases is as follows: S11 takes the page element corresponding to the test case as the associated page element, and determines the number of times the associated page element has a recognition deviation in the test case based on the recognition deviation data of the associated page element. S12 uses the number of identification deviations to determine the identification risk page elements among the associated page elements; S13 determines the caching control strategy for the database input parameters of the test case based on the identified risk page element data in the associated page elements of the test case.

[0012] The beneficial effects of this invention are as follows: By utilizing the identification deviation data of the page elements corresponding to the test cases, the caching control strategy for the database input parameters of the test cases is determined. Based on the identification deviation of the associated page elements in historical tests, it is dynamically determined whether to implement the target control strategy of always caching the database input parameters of the test cases, so as to balance test execution efficiency and database access load, and ensure the efficiency and reliability of test processing.

[0013] By utilizing the test processing results of different test cases and the cache management method of the associated database of test cases under the target control strategy, the update management method of the cache control strategy for test cases under the target control strategy is determined. For test cases that have been marked as the target control strategy (i.e., always cached), the cache control strategy is determined based on the reliability of identifying risky page elements when there is identification bias and the impact of always cached on the cache requirements of other test cases, in order to avoid resource waste and adapt to changes in the page element identification status, while reducing the impact of cache resource contention on other test cases in the same database.

[0014] Other features and advantages will be set forth in the following description, and the objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0015] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] The above and other features and advantages of the present invention will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0017] Figure 1 This is a framework diagram of a UI automation testing system based on database input parameters; Figure 2 This is a flowchart for analyzing and processing marketing data to determine whether a targeted strategy is unnecessary. Figure 3 This is a flowchart illustrating how test case caching affects the determination of risk types. Figure 4 This is a flowchart illustrating the methods for determining database cache management. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0019] Example 1 like Figure 1 As shown, this application provides a UI automation testing system based on database input parameters, specifically including: Data Acquisition and Management Module: Responsible for establishing dynamic connections with various databases, acquiring diverse test input parameters from the databases in real time according to preset query conditions, providing data caching, determining the identification deviation data of the page elements corresponding to the test cases based on the test data of the test cases, and determining the caching control strategy for the database input parameters of the test cases based on the identification deviation data. Page Operation Module: Responsible for abstracting each page of the application into an independent page object. Using intelligent element positioning algorithm, it can dynamically adjust the positioning strategy to achieve the positioning of page elements. Test execution module: By combining with the data acquisition and management module, it dynamically injects different datasets from the database into the same test case, enabling large-scale data-driven testing; Test Result Analysis and Reporting Module: Responsible for collecting, processing, and visualizing all results during test execution, automatically generating detailed test logs, integrating all test data, generating structured test reports, and determining the update management method for the cache management strategy of the test cases of the target control strategy by utilizing the similarity between page elements corresponding to different test cases and test cases of the target control strategy, the cache management method of the database associated with the test cases of the target control strategy.

[0020] Specifically, the test input parameters include product code, user ID, and order number.

[0021] Furthermore, it also includes a fallback data mechanism, which means that when the database connection fails or the query returns no results, the system can automatically use predefined default or backup test data.

[0022] Data Acquisition and Management Module: This module is responsible for establishing dynamic connections with various databases (such as relational databases and non-relational databases). Based on preset query conditions, it retrieves diverse test input parameters (e.g., product codes, user IDs, order numbers, parent ASINs, and other business data) from the database in real time. To optimize performance, this module also integrates an efficient data caching mechanism to avoid performance overhead caused by repeated queries. Simultaneously, to ensure the robustness of the tests, this module also features a comprehensive fallback data mechanism. When a database connection fails or a query returns no results, the system automatically activates predefined default or backup test data, thereby ensuring the continuity of the testing process.

[0023] Page Operation Module: This module abstracts each page of the application into an independent page object. Each page object encapsulates all UI element location strategies for that page (e.g., XPath, CSS selectors, ID, Name, etc.) and their corresponding operation methods (e.g., click, input, select, wait, etc.). This module introduces an intelligent element location algorithm that can dynamically adjust the location strategy, enhancing the success rate and stability of element location. Furthermore, the module incorporates a sophisticated error handling mechanism, such as strategies for capturing and recovering from exceptions like element not found or page load timeouts, to improve the robustness of test scripts.

[0024] This embodiment provides an intelligent element location algorithm integrated into the page object model. This algorithm dynamically adjusts the location strategy for UI elements to improve the stability and success rate of automated testing. The algorithm maintains a multi-level pool of location strategies, with each page element corresponding to a set of predefined location methods, including but not limited to ID, Name, CSS selectors, XPath, and link text, dynamically sorted according to historical success rates. Before performing element operations, the algorithm first attempts to use the highest-priority location strategy, combined with an explicit waiting mechanism, to ensure the element appears within a specified time.

[0025] When a positioning strategy fails, the algorithm automatically captures the exception and triggers a strategy switching process. For example, if positioning by ID fails, it immediately attempts to re-position using CSS selectors or XPath, while recording the failure information for subsequent priority adjustments. Furthermore, the algorithm dynamically generates backup XPaths (such as those based on element text, position, or attribute combinations) based on page loading status and DOM structure changes to adapt to frequent changes in front-end code. All attempts are coupled with configurable timeouts and retries to avoid misjudgments caused by network latency or brief pauses.

[0026] Test Execution Module: This module is built on mainstream testing frameworks (e.g., pytest, TestNG, etc.). Its core function is to implement parameterized execution of test cases and efficient parallel testing. Through close collaboration with the data acquisition and management module, this module can dynamically inject different datasets from the database into the same test case, thereby enabling large-scale data-driven testing. Furthermore, this module supports multi-threaded or multi-process parallel test execution, allowing multiple test cases to be run simultaneously on multi-core processors or distributed environments, or tests to be executed on multiple browser instances, significantly shortening the testing cycle.

[0027] Test Result Analysis and Reporting Module: This module is responsible for collecting, processing, and visualizing all results during test execution. It automatically generates detailed test logs, recording every operation, assertion result, and exception information. When a test fails, the module automatically continues testing until the required number of failures is reached, at which point a screenshot will be taken. Finally, this module integrates all test data to generate a structured, easy-to-read, and interactive HTML test report, clearly displaying a test overview, pass rate, details of failed test cases, error messages, relevant logs, and screenshots.

[0028] Data Preparation Phase: In this phase, the system activates the data acquisition and management module. Based on the current testing requirements and environment configuration, it executes SQL queries (or other database query languages) from the specified database to dynamically retrieve the necessary test input parameters (e.g., product code list, user credential set, parent ASIN set, etc.). To improve the efficiency of subsequent test execution, the acquired data will be cached. If the database query fails or returns an empty result, a fallback data mechanism will be activated to ensure the continuity of test data supply.

[0029] Test Execution Phase: The test execution module utilizes parameterized testing techniques (such as the `@pytest.mark.parametrize` decorator in pytest) to inject dynamic test data obtained during the data preparation phase into test cases, either individually or in batches. Each parameterized test case instance will run independently using different test data. To further improve efficiency, the system supports parallel test execution, meaning that multiple test case instances (or different data instances of the same test case) can be executed concurrently in multiple browser instances or test processes.

[0030] Results Analysis Phase: After all test cases have been executed, the test results analysis and reporting module will collect all execution statuses, error messages, log records, and automatically captured images. Subsequently, this module will aggregate and analyze this raw data, ultimately generating a comprehensive and intuitive HTML test report for testers or developers to review, enabling them to quickly locate problems, assess software quality, and perform regression analysis.

[0031] Example 2 Secondly, this application provides a UI automation testing method based on database input parameters, applied to the aforementioned UI automation testing system based on database input parameters, specifically including: S1 determines the identification deviation data of the page elements corresponding to the test cases based on the test data of the test cases, determines the cache management strategy of the database input parameters of the test cases based on the identification deviation data, and determines the cache impact risk type of the test cases using the cache management strategy and the associated databases of different test cases. S2 determines the cache impact risk type of the test cases of the database, and determines the cache management method of the database by combining the test case data of the target control strategy in the test cases of the database. S3 uses the test processing results of different test cases and the cache management method of the associated database of the test cases of the target control strategy to determine the update management method of the cache control strategy of the test cases of the target control strategy.

[0032] Furthermore, the test data for the test cases includes the test results of the test cases in history and the identification deviation data of the test results.

[0033] Furthermore, the identification deviation data of the page element corresponding to the test case is determined based on whether the page element to be verified by the test case was successfully identified in the historical test results.

[0034] Specifically, such as Figure 2 As shown, the method for determining the caching control strategy for the database input parameters of the test cases is as follows: For test cases in an automated testing system, based on the identification deviation of their associated page elements in historical tests, a target control strategy of always caching the database input parameters of the test case is dynamically determined to balance test execution efficiency and database access load. The logic is as follows: First, the number of identification failures of the page elements involved in each test case in historical tests is counted as the identification deviation count; second, page elements with identification risks are filtered out according to a preset deviation count threshold; finally, based on whether the number of identified risky page elements in the test case exceeds a preset risky page element count threshold, it is determined whether the test case should adopt the target control strategy (i.e., always caching its input parameters). This reduces repeated database accesses caused by page element identification failures while ensuring test stability, thereby improving overall test response efficiency.

[0035] S11 takes the page element corresponding to the test case as the associated page element, and determines the number of times the associated page element has a recognition deviation in the test case based on the recognition deviation data of the associated page element. Related page elements: These refer to page components that are directly related to the test cases being analyzed and need to be identified and manipulated during test execution, such as input boxes, buttons, lists, and drop-down menus. These elements are the foundation for the successful execution of test cases.

[0036] Recognition deviation data: This data comes from historical test records and includes information on whether the system successfully recognized the required page elements in each test. If the elements were not recognized, a recognition deviation is recorded. This data is typically stored in log format, recording the execution time, test case identifier, involved elements, and recognition result for each test.

[0037] Recognition Deviation Count: For each associated page element, count the total number of times it failed to be successfully recognized in a specific number of historical test executions. This metric reflects the recognition stability of the element in historical runs; a higher value indicates that the element is more likely to cause test interruption or retries.

[0038] This step is included to quantify the reliability of each page element's identification in historical tests. Failure to identify a page element will prevent test cases from executing correctly, triggering repeated readings or retries of database input parameters, severely impacting testing efficiency. By counting the number of identification deviations, the abstract issue of identification stability can be transformed into quantifiable data metrics, providing an objective basis for subsequent risk identification.

[0039] Taking test case TC001 as an example, this test case is used to verify the user login function, involving three related page elements: username input box, password input box, and login button. In the most recent 20 historical tests, the number of times each element failed to be recognized was recorded: username input box failed 3 times, password input box failed 1 time, and login button failed 5 times. Therefore, the recognition deviations for these three elements are 3, 1, and 5 times, respectively.

[0040] S12 uses the number of identification deviations to determine the identification risk page elements among the associated page elements; Identify risky page elements: These are related page elements whose number of deviations exceeds a preset threshold. These elements have shown consistent or frequent identification failures in historical testing, posing a substantial threat to the stable execution of test cases.

[0041] Preset deviation frequency threshold: A pre-defined threshold value used to distinguish between normal fluctuations and high-risk deviations. This threshold can be determined based on the system's requirements for recognition accuracy, the complexity of page elements, or the statistical distribution of historical data.

[0042] This step is designed to filter out elements from a large pool of page elements that exhibit truly high-frequency failure rates. Not all failures require special attention; occasional failures may stem from network fluctuations or environmental factors. Only frequent failures exceeding a threshold indicate a problem with the element itself or its identification mechanism. By comparing thresholds, continuous data can be transformed into binary risk indicators, allowing us to focus on critical issues.

[0043] Continuing with the example above, let's set the preset deviation threshold to 3 times. For TC001, the username input box has a deviation count of 3, which equals the threshold (it needs to be greater than 3 to be considered, so it's not counted as a risk), the password input box 1 has a deviation count less than 3, and the login button 5 has a deviation count greater than 3. Therefore, the login button is identified as a risk-identifying page element. For TC002, all three elements have a deviation count of 2, which is less than 3, so there is no risk-identifying page element.

[0044] S13 determines the caching control strategy for the database input parameters of the test case based on the identified risk page element data in the associated page elements of the test case.

[0045] Specifically, the risk-identifying page element is the associated page element whose number of identification deviations exceeds a preset deviation threshold.

[0046] It should be noted that the number of risky page elements in the associated page elements of the test case is determined based on the risky page element data. When the number of risky page elements in the associated page elements exceeds a preset risky page element number threshold, the test case may frequently call the input data in the database because the associated page elements are not effectively identified. Therefore, in order to improve response efficiency, the caching management strategy for the database input parameters of the test case is determined to be the target management strategy, that is, the database input parameters of the test case are always kept in a cached state during the test. In other cases, the caching management strategy for the database input parameters of the test case is determined not to be the target management strategy.

[0047] Risk page element identification data: This refers to the list and quantity of risk elements included in each test case identified in step S12. This data directly reflects the degree to which the test case depends on unstable elements.

[0048] Cache management strategy: The cache management method for database input parameters of test cases, mainly divided into target management strategy (always cache) and non-target management strategy (on-demand cache or default strategy).

[0049] Preset threshold for the number of risky page elements: A pre-defined threshold value used to determine whether test cases require special caching. As required, this threshold is at least 2, meaning that the target control strategy is only considered when at least two risky page elements are present in the test case. This setting avoids overreacting to single, occasional issues, ensuring that cached resources are used for test cases with genuine systemic risks.

[0050] This step is designed to translate the number of risk elements into specific control decisions. When a test case contains at least two high-risk elements, the probability of identification failure increases significantly in each execution. The cumulative effect of multiple risk elements may lead to frequent retries and repeated database accesses. In this case, pre-caching input parameters locally can avoid re-querying the database after each failure, thereby significantly improving test execution efficiency. Conversely, if the number of risk elements is less than two, the risk is controllable, and conventional strategies can be used.

[0051] Assume the preset threshold for the number of risky page elements is 2. For TC001, the number of risky page elements identified is 1 (login button only), which is less than 2. Therefore, no target control strategy is adopted, and its database input parameters are managed in a conventional manner (e.g., on-demand caching or querying on each execution). For TC002, the number is 0, and the same strategy is not adopted. Now, assume another test case, TC003, which contains four related page elements, three of which have more than 3 identification deviations. The number of risky elements is 3, which is greater than or equal to 2. Therefore, the database input parameter caching control strategy for TC003 is determined to be the target control strategy, that is, its input parameters are always cached locally in subsequent tests to cope with frequent identification failures.

[0052] This method systematically analyzes the historical identification deviations of page elements associated with test cases and dynamically formulates cache control strategies based on the threshold of the number of risk elements. All judgments are based on actual historical test data, avoiding the arbitrariness of subjective experience judgments and making the formulation of cache strategies more scientific and objective.

[0053] By implementing a constant caching strategy for high-risk test cases, the number of repeated database queries caused by element recognition failures was significantly reduced, the average execution time of test cases was shortened, and the overall testing efficiency was improved. By filtering risky elements and determining the number threshold, attention was focused on the test cases that were most likely to affect the stability of the test, which facilitated further optimization of the page element recognition algorithm or adjustment of the test case design.

[0054] Specifically, such as Figure 3 As shown, the method for determining the risk type of the test case's caching impact is as follows: S21 uses the cache management strategy to determine the test cases belonging to the target management strategy in the associated database of the test cases, and uses the test cases belonging to the target management strategy in the associated database as target management test cases. Cache management strategy: refers to the cache management method defined for the database input parameters of test cases, including targeted management strategy (always cache) and non-targeted management strategy (on-demand cache). This strategy is determined in the early stage based on risk identification based on page elements.

[0055] Related databases: These refer to one or more databases from which a test case needs to read input parameters during execution. A single test case may be related to multiple databases, for example, retrieving data from different databases.

[0056] Target control test cases: A collection of all test cases tagged with target control strategies within a specific relational database. These test cases require their input parameters to be cached at all times due to their high-risk nature.

[0057] This step is set up to identify test cases in the database that are determined to always need to be cached, in relation to the test cases. Since target-managed test cases are the primary source of caching pressure, analyzing them helps to understand the database's cache load.

[0058] Taking test case T_A as an example, it is associated with two databases: DB1 and DB2. In DB1, there are 10 test cases, 3 of which are marked as target management policies (e.g., T_X, T_Y, T_Z); in DB2, there are 20 test cases, 5 of which are target management cases (e.g., T_U, T_V, etc.). Therefore, in the associated databases of T_A, the target management cases in DB1 are {T_X, T_Y, T_Z}, and the target management cases in DB2 are {T_U, T_V, ...}.

[0059] S22 determines the control impact factor of the associated database by the proportion of target control cases in the test cases in the associated database; The percentage of target control test cases: For each associated database, the percentage is the number of target control test cases divided by the total number of test cases in that database.

[0060] Control Impact Factor: This refers to the percentage mentioned above, used to quantify the degree to which the database is affected by the target control strategy. The higher the factor, the more use cases that need to be cached in the database, and the greater the pressure on the caching system.

[0061] This step is set up to abstract the cache load of each database into a comparable value. By using percentages, the impact of differences in database size can be eliminated, making the degree of impact between different databases comparable.

[0062] Continuing with the previous example, DB1 has 3 target control use cases, out of a total of 10, accounting for 0.3, meaning the control impact factor of DB1 is 0.3. DB2 has 5 target control use cases, out of a total of 20, accounting for 0.25, with a factor of 0.25.

[0063] S23 determines the cache impact risk type of the test case based on the control impact factors of the associated database of the test case.

[0064] It should be noted that if there is an associated database in the associated database of the test case with a control impact factor greater than the preset impact factor threshold, then the cache impact risk type of the test case is determined to be a severe impact risk type.

[0065] Preset impact factor threshold: A pre-defined value used to determine whether the control impact factor of a single database is too high. If it exceeds this value, the database is considered to be under high cache pressure.

[0066] This judgment is set up to quickly identify databases that are already under significant pressure. If the control impact factor of a certain related database exceeds the threshold, it indicates that a high percentage of test cases in that database require constant caching, and the caching system may be facing a significant burden. Therefore, the caching impact risk type of that test case is directly classified as severe impact.

[0067] The significance of this judgment lies in providing a fast track to avoid tedious multi-level analysis of high-risk situations, thereby improving decision-making efficiency.

[0068] Additionally, it is understood that if the associated database of the test cases does not contain an associated database with a control impact factor greater than the preset impact factor threshold, the following content is also included: Case 1: Based on the control impact factors of the associated databases of the test case, if the average value of the control impact factors of different associated databases of the test case is within the preset impact factor range, then the cache impact risk type of the test case is determined to be a severe impact risk type.

[0069] Preset impact factor range: A pre-defined range of values ​​(e.g., [0.3, 0.6]) used to determine whether the average impact of multiple databases is in the high-risk range.

[0070] Even if the pressure on a single database is not excessive, but the average pressure across all related databases is high, the overall cache burden remains heavy, which may lead to a decline in system performance. Therefore, if the average value falls within the preset high-risk range, it should also be considered a serious impact.

[0071] The significance of this judgment lies in comprehensively considering the combined impact of multiple databases, avoiding overlooking the overall pressure due to individual databases not exceeding the limit, and making risk identification more comprehensive.

[0072] Scenario 2: If the average value of the control impact factor of different associated databases of the test case is not within the preset impact factor range, the associated databases whose control impact factors are within the preset impact factor range will be used as the impact databases. If the proportion of the impact databases in the associated databases of the test case is greater than the preset impact database proportion threshold, then the cache impact risk type of the test case will be determined as the severe impact risk type.

[0073] Impact databases: These refer to the related databases whose control impact factors fall within the preset impact factor range. These databases are under certain pressure but have not exceeded the limit.

[0074] Preset threshold for the proportion of databases affected: A pre-set proportion value used to determine whether the proportion of databases affected is too high.

[0075] Even when the average value is not in the high-risk range, it is still necessary to examine the concentration of stress distribution. If most factors in the database are at a medium level (i.e., within the range), it indicates that stress is widespread and may still lead to a higher overall risk. Therefore, further screening using a percentage threshold is necessary. The significance of this judgment is to capture situations where stress is widespread but has not reached the average high-risk level, thus avoiding omissions.

[0076] Scenario 3: If the proportion of the affected database in the associated database of the test case is not greater than the preset threshold for the proportion of the affected database, the control impact value of the test case is determined by using the proportion of the affected database in the associated database of the test case and combining it with the proportion of the associated database of the test case with the target control strategy. It is then determined whether the control impact value is greater than the preset threshold for impact. If it is, the cache impact risk type of the test case is determined to be a general impact risk type. If not, the cache impact risk type of the test case is determined to be another impact risk type.

[0077] The proportion of databases with test cases containing target control strategies: This refers to the proportion of databases with at least one target control test case among all related databases.

[0078] Control Impact Value: A comprehensive indicator calculated from factors such as the percentage of databases affected and the proportion of databases with target control use cases, used to quantify the degree of impact under remaining circumstances.

[0079] Preset impact threshold: A pre-set value used to distinguish general impacts from other impacts.

[0080] When there is neither single-point high pressure nor widespread pressure, the degree of impact needs further assessment. By combining the proportion of affected databases with the proportion of databases with target control test cases, the potential impact of test cases on the caching system can be more precisely characterized. If the comprehensive indicators exceed the threshold, it is classified as a general impact and requires appropriate attention; otherwise, the impact is negligible and classified as other impacts.

[0081] The significance of this judgment lies in enabling a more refined classification of risk levels, allowing the system to take differentiated management measures for different levels.

[0082] A test case relates to two databases with factors of 0.3 and 0.15, respectively, within a preset range of [0.3, 0.6]. Only the first database is affected (0.5% of the total database). There are two databases containing the target control test case (both containing the target control test case), with a ratio of 1. If the control impact value is defined as the percentage of affected databases multiplied by this ratio, then 0.5 × 1 = 0.5. The preset impact threshold is 0.4. If 0.5 > 0.4, it is classified as a general impact risk type; if it is less than the threshold, it is classified as other impacts.

[0083] This embodiment focuses on an automated testing platform that has implemented a target control strategy (always caching its database input parameters) for some test cases based on page element risk identification. Taking test cases T1, T2, T3, and T4 as examples, this document details how to determine the type of risk impact from caching.

[0084] Step S21: Determine the associated database and target control cases for each test case.

[0085] Test case T1: Associates databases DB1 and DB2. DB1 contains 10 test cases, including 3 target control test cases; DB2 contains 20 test cases, including 5 target control test cases.

[0086] Test case T2: Associated databases DB3 and DB4. DB3 contains 8 test cases, 3 of which are target control test cases; DB4 contains 12 test cases, 4 of which are target control test cases.

[0087] Test case T3: Associates databases DB5, DB6, and DB7. DB5 has 10 test cases, with 2 target control test cases; DB6 has 15 test cases, with 2 target control test cases; DB7 has 5 test cases, with 1 target control test case.

[0088] Test case T4: Associates databases DB8 and DB9. DB8 has 10 test cases, with 1 target control test case; DB9 has 10 test cases, with 0 target control test cases.

[0089] Step S22: Calculate the control impact factor for each associated database.

[0090] T1: DB1 factor = 3 / 10 = 0.3; DB2 factor = 5 / 20 = 0.25.

[0091] T2: DB3 factor = 3 / 8 = 0.375; DB4 factor = 4 / 12 ≈ 0.333.

[0092] T3: DB5 factor = 2 / 10 = 0.2; DB6 factor = 2 / 15 ≈ 0.133; DB7 factor = 1 / 5 = 0.2.

[0093] T4: DB8 factor = 1 / 10 = 0.1; DB9 factor = 0 / 10 = 0.

[0094] Step S23: Determine the risk type for each test case.

[0095] Process T1 first: Check if there is a single factor greater than 0.5, and if neither 0.3 nor 0.25 is greater than 0.5, proceed to the next step.

[0096] The average value is calculated as (0.3 + 0.25) / 2 = 0.275, which is not within the preset range [0.3, 0.5]. Therefore, we proceed to case 2.

[0097] Identifying the affected databases: Only DB1 (0.3) has a factor within the range [0.3, 0.5], while DB2 does not. The number of affected databases is 1, and the total number of associated databases is 2, resulting in a percentage of 1 / 2 = 0.5.

[0098] Since the proportion of 0.5 is greater than the preset proportion threshold of 0.4, the cache impact risk type of T1 is determined to be a severe impact risk type.

[0099] This method systematically analyzes the distribution of target control test cases in the test case association database and uses a multi-level judgment mechanism to determine the type of risk affected by caching. It comprehensively considers multiple perspectives such as individual database pressure, average pressure, and pressure distribution, avoiding the one-sidedness of a single indicator and making risk identification more accurate.

[0100] By classifying risks into severe impact, general impact, and other impacts, the system can adopt differentiated response strategies to achieve optimal resource allocation. All judgments are based on actual target control use case data and quantitative factors, ensuring the objectivity and reliability of decision-making.

[0101] Specifically, such as Figure 4 As shown, the method for determining the database cache management method is as follows: For a single database, based on the distribution of cache impact risk types of its internal test cases and the proportion of target control test cases, the appropriate cache management method is dynamically determined to ensure test execution efficiency while reasonably controlling the database's cache load. The logic is as follows: First, count the number of test cases with different cache impact risk types in the database; second, calculate the database's control impact factor (i.e., the proportion of target control test cases); then, through multi-level judgments—including whether the control impact factor exceeds the limit, whether the number of severe risk test cases is excessive, and whether comprehensive indicators (control requirement factor, average impact weight) exceed the threshold—determine whether to use a preset cache management method or a target cache management method. The difference between the two methods lies in the threshold for the number of test cases that can be cached simultaneously. The target method allows for a larger number of concurrent caches and is suitable for higher-risk scenarios, while the preset method is more conservative.

[0102] S31 uses the cache impact risk type of the test cases in the database to determine the test cases with different cache impact risk types in the test cases of the database; Caching impact risk type: refers to the risk level classified according to the degree of impact on database caching based on test cases in the early stage, including severe impact risk type, general impact risk type, and other impact risk type.

[0103] Different caches affect test cases of different risk types: This refers to counting the number of test cases belonging to each risk type in the database to form distribution data.

[0104] This step is set up to obtain the risk composition of test cases in the database. Because test cases with different risk types put different pressures on the caching system, the subsequent cache management method needs to be adjusted according to this composition. The significance of this step is to provide basic classification data for subsequent decisions, so that the management method can specifically deal with the concentration of high-risk test cases.

[0105] Taking the database DB_Alpha as an example, there are 10 test cases in this database. Among them, 3 have a serious impact on the risk type, 2 have a general impact on the risk type, and 5 have other impacts on the risk type.

[0106] S32 determines the control impact factors of the database based on the test case data of the target control strategy in the test cases of the database; Test cases for target control strategies: These are test cases that have been identified as requiring constant caching of their input parameters; these are target control test cases. The identification of these test cases is based on historical identification biases of page elements.

[0107] Control Impact Factor: The proportion of the number of target control test cases to the total number of database test cases, reflecting the prevalence of the database being affected by the always-cached strategy.

[0108] This step is set up to quantify the proportion of use cases in the database that need to be permanently cached, because these use cases are the main source of caching pressure. The higher the factor, the heavier the database caching burden.

[0109] The significance of this step is to transform the raw count into a standardized metric, which is easier to compare with a preset threshold and determine the overall cache pressure level of the database.

[0110] In DB_Alpha, there are 3 target control use cases and a total of 10 use cases. Therefore, the control impact factor is 3 / 10=0.3.

[0111] S33 uses the database's control impact factors and test cases with different cache impact risk types in the database's test cases to determine the database's cache management method.

[0112] It is understandable that if the control impact factor of the database is greater than the preset impact factor threshold, it is determined that a large number of test cases in the database have been reliably cached and controlled, and therefore the cache management method of the database is determined to be the preset cache management method.

[0113] Preset impact factor threshold: A pre-defined value used to determine if the overall cache pressure on the database is too high. If this value is exceeded, it indicates that a large number of test cases are in a state of constant caching, and a preset cache management method needs to be adopted to control concurrency.

[0114] When the control impact factor is too high, the database cache resources are already heavily occupied. At this time, a stricter preset cache management method is needed to limit the addition of new cache and avoid cache overload. This judgment can quickly identify the high-pressure database and directly adopt a conservative strategy, simplifying the decision-making process.

[0115] Furthermore, if the control impact factor of the database is not greater than a preset impact factor threshold, the following content is also included: S331. Using test cases with different cache impact risk types in the test cases of the database, determine the test cases with serious impact risk types in the test cases of the database, and determine whether the number of test cases with serious impact risk types in the test cases of the database is greater than the preset serious risk test case number threshold. If yes, determine that the cache management method of the database is the preset cache management method. If no, proceed to step S332. Test cases that severely impact risk type: These are test cases that cache the risk type as severely impacted, which may put significant pressure on the database.

[0116] Preset threshold for the number of critical risk use cases: A pre-defined threshold value used to determine whether the number of critically impactful use cases is excessive.

[0117] Even if the overall impact factor is not high, if there are a large number of test cases with serious risk impact, these test cases may still frequently trigger cache operations during test execution, leading to concentrated pressure. Therefore, when the number exceeds the threshold, a preset cache management method should be adopted. This judgment captures the clustering effect of high-risk test cases and avoids ignoring local risks due to average indicators.

[0118] S332 uses the control impact factor of the database and the proportion of test cases with serious impact risk types in the test cases to determine the control requirement factor of the database, and determines whether the control requirement factor of the database is greater than the preset control requirement factor threshold. If yes, proceed to step S333; if no, determine the cache management method of the database as the target cache management method. Percentage of test cases that significantly impact risk types: This refers to the proportion of test cases that significantly impact risk types out of the total number of test cases in the database.

[0119] Controlled demand factor: A comprehensive indicator calculated by combining the controlled impact factor with the proportion of high-risk use cases in a certain way (e.g., product or weighted sum) to quantify the database's demand for cache management.

[0120] Preset control demand factor threshold: A pre-set value used to determine whether the demand level has reached a level that requires further analysis.

[0121] When neither the control impact factor nor the proportion of severe risks exceeds the limit individually, both need to be considered comprehensively. If the comprehensive indicator is high, it indicates that there is still potential pressure, and a more refined assessment is needed; otherwise, a relatively lenient target buffer management method can be adopted. This judgment achieves the integration of multiple factors and avoids the one-sidedness of a single indicator.

[0122] S333 uses the cache impact risk type of the test case to determine the impact weight value of the test case, and determines whether the average impact weight value of different test cases in the database is greater than the preset impact threshold. If so, the cache management method of the database is determined to be the target cache management method; otherwise, the cache management method of the database is determined to be the preset cache management method.

[0123] Impact Weight Value: Assign a numerical weight to each cache impact risk type to quantify its degree of impact. For example, severe impact has a weight of 3, moderate impact has a weight of 2, and other impacts have a weight of 1.

[0124] Average impact weight: The arithmetic mean of the impact weights of all test cases in the database, reflecting the overall risk level. Preset impact threshold: A pre-set value used to determine whether the average risk level is too high.

[0125] When the control requirement factor is high, it is necessary to more accurately assess the individual impact of each test case. By using a weighted average, the distribution of different risk types can be comprehensively considered. If the average value is too high, the impact is high. To reduce the impact on test cases, a target cache management method is adopted; otherwise, a preset cache management method can be used. This judgment achieves a refined quantification of risk distribution and reduces the impact on the test reliability of test cases.

[0126] It should be noted that the preset cache management method is to cache the data of the test cases in the associated database if the number of test cases currently being cached is below a preset number, and if the test duration of the test cases is above the target duration.

[0127] It should be noted that the target cache management method is to cache the data of the test cases in the associated database if the number of test cases currently being cached is below the target number, and if the test duration of the test cases is above the target duration, whereby the target number is greater than the preset number.

[0128] This embodiment focuses on two databases, DB_Alpha and DB_Beta, within an automated testing platform. Based on the risk types of caching impact from internal test cases and the distribution of target control test cases, it determines their respective cache management methods. The platform presets the following thresholds: First, the data in the database DB_Alpha is as follows: Total number of test cases: 10; Number of target control test cases: 3; Control impact factor = 0.3; Distribution of cache impact risk types: 3 severe impacts, 2 moderate impacts, and 5 other impacts; Percentage of severe impact test cases = 3 / 10 = 0.3.

[0129] Step S31: Determine the number of use cases for different risk types, as above.

[0130] Step S32: Control impact factor = 0.3.

[0131] Step S33: First, determine if 0.3 is not greater than 0.5. If not, proceed to S331.

[0132] S331: The number of severely affected use cases = 3 > 2, therefore the cache management method of DB_Alpha is directly determined to be the default cache management method.

[0133] That is, in DB_Alpha, when there is a test case that needs to be cached, check if the number of test cases currently being cached is less than 5, and if the test duration of the test case is greater than 1 hour, then cache its data.

[0134] This method systematically analyzes the risk composition of test cases within the database and the proportion of target control test cases, and uses a multi-level judgment mechanism to determine the cache management method. It delves deeper layer by layer from overall pressure, high-risk clusters, comprehensive indicators to individual weighting, to ensure that the decision is highly matched with the actual risk situation of the database.

[0135] By distinguishing between preset and target management methods, this approach ensures that high-risk databases are not overloaded while allowing low-risk databases to make fuller use of cache resources, thereby improving overall testing efficiency. The preset thresholds can be adjusted according to system load and business needs, enabling the method to adapt to databases of different sizes and scenarios.

[0136] Furthermore, the method for determining the update management method of the cache management strategy for the test cases of the target management strategy is as follows: For test cases marked with a target management strategy (i.e., always-cached), a cache management strategy is developed based on the reliability of identifying risky page elements when there are identification biases, and the impact of always-cached on the caching needs of other test cases. This strategy aims to avoid resource waste, adapt to changes in page element identification status, and reduce the impact on cache resource contention for other test cases in the same database. The logic is as follows: First, based on the similarity of identified risky page elements, reference test cases with common risk elements to the current test case are identified. Second, it examines which databases the current test case relies on use preset cache management methods (i.e., restricted databases), as these databases have strict limits on the number of concurrent cache requests, which may affect the caching opportunities of other test cases. Finally, considering the number of reference test cases, the distribution of restricted databases, and the occurrence of recent identification biases, a multi-level judgment is used to determine whether the cache management strategy for this test case should continue to be executed, canceled, or only executed under specific conditions, thereby achieving dynamic optimization of cache resources. When there are a large number of reference test cases, the judgment of identification deviation has higher statistical reliability due to the rich information of the group. Therefore, a refined adjustment method based on recent deviation can be adopted to maximize resource utilization while ensuring that the risk is controllable.

[0137] S41 uses the test cases of the target control strategy as cache control test cases, and determines the same number of risk identification page elements of the cache control test cases and different test cases based on the associated page elements of the test cases. The same number is used to determine the reference test cases of the cache control test cases. Cache management test cases: These are test cases that are currently marked as the target management strategy and require that their database input parameters be cached at all times. They are objects that need to be updated and managed.

[0138] Risk-identifying page elements: These are page elements identified as having potential risks during the initial analysis because the number of identified deviations exceeds a preset threshold. Each test case may have multiple risk-identifying page elements.

[0139] Same number: For another test case, count the number of risk-identifying page elements that it shares with the cache management test case.

[0140] Reference test cases: These are test cases that identify the same risky page elements as the cache management test cases, and whose number of identical elements accounts for a proportion greater than a preset risk percentage threshold among the total number of risky elements in the cache management test cases. These test cases can serve as a reference for judging the current identification status of risky elements.

[0141] This step is set up to find test cases with similar risk characteristics to the current test case. If there are a large number of such test cases, their recent performance can be observed to infer whether the risk elements of the current test case are still prone to errors, thus providing a basis for adjusting the caching strategy.

[0142] Taking test case U as an example, it has three risk identification page elements: E1, E2, and E3 (meeting the requirement of at least two). The preset risk percentage threshold is 50%. In the system, test case V has risk elements E1 and E4. E1 is the same as in U, with one identical element, accounting for 33.3% of the total 3 risk elements in U, which is less than 50%. Therefore, V is not a reference test case. Test case W has risk elements E1, E2, and E5. E1 and E2 are the same, with two identical elements, accounting for 66.7% > 50%. Therefore, W is a reference test case for U. Test case X has risk elements E2 and E3. E2 and E3 are the same, with two identical elements, accounting for 66.7% > 50%. It is a reference. Test case Y has risk elements E1 and E2. Both are the same, accounting for 66.7% > 50%. It is a reference. Therefore, U has three reference test cases: W, X, and Y.

[0143] S42 uses the cache management method of the associated database of the test cases of the target control strategy to determine the associated database of the preset cache management method in the associated database, and uses it as the restricted database; Related databases: These refer to the databases from which cache management test cases need to read input parameters during execution. There may be one or more such databases.

[0144] Cache management method: Each database is assigned a preset cache management method or a target cache management method based on the preliminary analysis. The preset method has stricter limits on the number of concurrent caches (the preset limit is small), while the target method is more lenient (the target limit is large).

[0145] Limited databases: These refer to related databases that use preset cache management methods. Because these databases have strict control over cache resources, adding new caches may more easily reach the limit, thus affecting the caching opportunities of other test cases.

[0146] This step is set up to identify which databases the current test case depends on are resource-constrained (using default methods), as these databases may be more sensitive to new cache additions, and the cache usage of the current test case may squeeze the cache space of other test cases. By identifying the limiting databases, the potential impact of the current test case on other test cases can be assessed.

[0147] Test case U is associated with three databases: DB1, DB2, and DB3. DB1 and DB3 use the default cache management method, while DB2 uses the target cache management method. Therefore, the databases are limited to DB1 and DB3, a total of two.

[0148] S43 determines the update result of the cache management strategy of the cache management test case based on the reference test case data of the cache management test case and the restriction database data.

[0149] Furthermore, the reference test case is the same risk-identifying page element as the cache management test case, but the proportion of risk-identifying page elements in the cache management test case is greater than a preset risk proportion threshold.

[0150] It should be noted that when obtaining the number of reference test cases for the cache management test cases, if the number of reference test cases for the cache management test cases is greater than the preset threshold for the number of reference test cases, then whether there is an identification deviation in the associated page elements can be determined by referring to a large number of reference test cases. Therefore, the update result of the cache management strategy of the cache management test cases is determined to be that no cache management processing is required. Only when there is an identification deviation in the reference test cases or the cache management test cases in the page elements identified by the cache management test cases within the most recent preset time period is cache management processing required in the next test process.

[0151] Preset reference test case quantity threshold: A pre-set value used to determine whether there are enough reference test cases, so that high reliability can be judged by using group information.

[0152] If the number of reference test cases exceeds a threshold, it indicates the existence of a large number of similar test cases, thus providing higher statistical reliability for identifying deviations. Based on this, a dynamic adjustment method based on recent deviations can be adopted: if, within the most recent preset time period, either the reference test case or the current test case exhibits identification deviations in its risk identification page elements, the risk still exists, and caching management continues; otherwise, the risk may have disappeared, and caching can be canceled to release resources. This method achieves precise "on-demand caching" when information is sufficient, ensuring the stability of risky test cases while avoiding resource waste from risk-free test cases.

[0153] Additionally, it is understood that if the number of reference test cases for the cache management test cases is not greater than a preset threshold for the number of reference test cases, the following situations also apply: Case 1: Obtain the proportion of the restricted database in the associated database of the cache management test case. When the proportion of the restricted database in the associated database of the cache management test case is less than the preset restricted proportion threshold, the update result of the cache management strategy of the cache management test case is determined to continue cache management processing.

[0154] Limit the proportion of databases: Limit the proportion of the number of databases to the total number of related databases.

[0155] Preset limit ratio threshold: A pre-set ratio value used to determine whether the restricted database constitutes a minority.

[0156] If the database ratio is very low, it means that the current test cases mainly rely on databases with ample resources. Their cache usage has little impact on other test cases. Therefore, caching can continue to ensure its own stability. Avoid blindly canceling caching when resources are plentiful, retain protection for high-risk test cases, and do not affect other test cases.

[0157] Scenario 2: When the proportion of restricted databases in the associated database of the cache management test case is not less than the preset restricted proportion threshold, the number of restricted databases in the associated database of the cache management test case is obtained. When the number of restricted databases in the associated database of the cache management test case is greater than the preset restricted database number threshold, the update result of the cache management strategy of the cache management test case is determined to be that no cache management processing is required. Cache management processing is only required in the next test if the reference test case or the cache management test case has an identification deviation in the identified risk page elements of the cache management test case within the most recent preset time period.

[0158] Preset database quantity threshold: This is a pre-defined critical value used to determine if there are too many restricted databases. If the proportion and quantity of restricted databases are high, it indicates that the dependency libraries of the current test cases are generally under strain, and their cache usage will significantly affect the caching opportunities of other test cases. In this case, priority should be given to releasing the cache to alleviate resource pressure, but recent deviations should be considered. If there have been recent deviations, protection is still necessary.

[0159] When resources are scarce, prioritize releasing the cache to make room for other use cases that may need it more, while preventing misjudgments through recent deviation checks.

[0160] Scenario 3: If the number of restricted databases in the associated database of the cache management test case is not greater than the preset limit database number threshold, then the update result of the cache management strategy of the cache management test case is determined to continue cache management processing. Only if there is no identification deviation in the reference test case or the cache management test case in the identified risk page elements of the cache management test case within the most recent preset time period, will cache management processing not be performed in the next test process.

[0161] No identification bias: This means that there has been no identification bias between the reference test case and this test case within the most recent preset time period.

[0162] When the database has a high percentage of users but a small number of users, resource pressure is limited, and continuing to cache has little impact on the overall system, so it can continue. However, if there are no deviations recently, it indicates that the risk may have disappeared, and you can try canceling the cache to free up resources. When resource pressure is moderate, adjust dynamically based on the actual identification situation to achieve fine-grained control, neither blindly retaining nor easily canceling the cache.

[0163] This embodiment focuses on test case U in an automated testing platform, which is currently marked as a target control policy and requires evaluation to determine whether to update its caching policy. The platform has set the following thresholds and parameters based on previous analysis to ensure consistency with previous embodiments: Step S41: Determine the reference test cases.

[0164] The system contains other test cases V, W, X, and Y. Their risk identification page elements are as follows: V: {E1, E4}, E1 is the same as U, and the same number is 1, accounting for 33.3% of the total number of risk elements in U (3), which is less than 50%, so V is not a reference.

[0165] W: {E1, E2, E5}, with E1 and E2 being identical, totaling 2, accounting for 66.7% > 50%, which is for reference.

[0166] X: {E2, E3}, with two identical values, E2 and E3, totaling 2, accounting for 66.7% > 50%, which is for reference only.

[0167] Y: {E1, E2}, all 2 are the same, accounting for 66.7% > 50%, which is for reference.

[0168] Therefore, U has three reference test cases: W, X, and Y.

[0169] Step S42: Determine the limiting database.

[0170] The cache management methods for U's associated databases DB_A, DB_B, and DB_C are as follows: DB_A: Preset cache management method (restricted database), DB_B: Target cache management method, DB_C: Preset cache management method (restricted database). Therefore, there are two restricted databases: DB_A and DB_C.

[0171] Step S43: First, the number of reference test cases is 3, which is compared with the preset threshold of 3. Since the rule is that a high reliability judgment is triggered only when the number is "greater than" the threshold, it is equal to the threshold here, so it is not greater than the threshold, and the process proceeds to the case branch.

[0172] The proportion of restricted databases in the associated database is calculated as 2 / 3 ≈ 0.667. Compared with the preset restriction proportion threshold of 0.5, 0.667 ≥ 0.5. Therefore, the judgment is entered into case 2 or case 3.

[0173] Furthermore, the number of databases is limited to 2. When compared with the preset limit of 2 databases, the rule is that if it is "greater than", then case 2 is triggered. Here, it is equal to, so it is not greater than, and case 3 is entered.

[0174] Scenario 3: The update result is determined to continue cache management, but there is one exception: if within the last 7 days, the reference test cases (W, X, Y) or U itself do not have any identification bias in their risk identification page elements, then the next test does not need to perform cache management.

[0175] Suppose that within the last 7 days, test case W experienced an E1 identification error, while X and Y did not, and neither did U. Since W exhibited an error, the condition of "none of them exist" is not met. Therefore, U's cache management strategy remains unchanged, meaning cache management continues. This implies that U still consumes cache resources, but due to the limited number of databases, the impact on other test cases is limited.

[0176] If all reference test cases and U show no identification deviation within the last 7 days, the update result is that cache management will not be performed in the next test, i.e., always-cached caching will be canceled. This frees up U's cache space on DB_A and DB_C, making room for other test cases that may be needed.

[0177] This method reliably manages the caching strategy of target control test cases by comprehensively considering the similarity of test cases, database resource constraints, and recent identification deviations. It avoids a static caching strategy and releases or retains cached resources in a timely manner based on actual conditions, improving resource utilization. At the same time, it reduces the impact of cache contention on other test cases in the same database. By combining the similarity of risk elements, database pressure, and recent actual performance, the decision-making is more comprehensive and reasonable. It ensures that test cases with high resource consumption and significant impact are released first when resources are scarce, balancing the needs of all parties.

[0178] When there are many reference test cases, the high reliability of group information is used to achieve fine-grained on-demand caching; when there are insufficient reference test cases, the system is processed in layers according to database limitations, which ensures both risk controllability and maximizes resource efficiency. It is applicable to any number of test cases and databases, providing a fine-grained solution for cache management in automated testing systems and effectively supporting resource scheduling in large-scale testing environments.

[0179] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0180] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0181] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A UI automated testing system based on database input parameters, characterized in that, Specifically, it includes: Data Acquisition and Management Module: Responsible for establishing dynamic connections with various databases, acquiring diverse test input parameters from the databases in real time according to preset query conditions, providing data caching, determining the identification deviation data of the page elements corresponding to the test cases based on the test data of the test cases, and determining the caching control strategy for the database input parameters of the test cases based on the identification deviation data. Page Operation Module: Responsible for abstracting each page of the application into an independent page object. Using intelligent element positioning algorithm, it can dynamically adjust the positioning strategy to achieve the positioning of page elements. Test execution module: By combining with the data acquisition and management module, it dynamically injects different datasets from the database into the same test case, enabling large-scale data-driven testing; Test Result Analysis and Reporting Module: Responsible for collecting, processing, and visualizing all results during test execution, automatically generating detailed test logs, integrating all test data, generating structured test reports, and determining the update management method for the cache management strategy of the test cases of the target control strategy by utilizing the similarity between page elements corresponding to different test cases and test cases of the target control strategy, the cache management method of the database associated with the test cases of the target control strategy.

2. The UI automated testing system based on database input parameters as described in claim 1, characterized in that, The test input parameters include product code, user ID, and order number.

3. The UI automated testing system based on database input parameters as described in claim 1, characterized in that, It also includes a fallback data mechanism, which means that when the database connection fails or the query returns no results, the system can automatically use predefined default or backup test data.

4. A UI automation testing method based on database input parameters, applied to the UI automation testing system based on database input parameters as described in any one of claims 1-3, characterized in that, Specifically, it includes: Based on the test data of the test cases, the identification deviation data of the page elements corresponding to the test cases is determined. Based on the identification deviation data, the cache management strategy of the database input parameters of the test cases is determined. Using the cache management strategy and the associated databases of different test cases, the cache impact risk type of the test cases is determined. Determine the cache impact risk type of the test cases for the database, and determine the cache management method for the database by combining the test case data of the target control strategy in the test cases of the database. By utilizing the similarity between page elements corresponding to different test cases and test cases of the target control strategy, and the cache management method of the associated database of test cases of the target control strategy, an update management method for the cache control strategy of the test cases of the target control strategy is determined.

5. The UI automated testing method based on database input parameters as described in claim 4, characterized in that, The test data for the test cases includes the test results of the test cases in history and the identification deviation data of the test results.

6. The UI automated testing method based on database input parameters as described in claim 4, characterized in that, The identification deviation data of the page element corresponding to the test case is determined based on whether the page element to be verified by the test case was successfully identified in the historical test results.

7. The UI automated testing method based on database input parameters as described in claim 4, characterized in that, The method for determining the caching management strategy for the database input parameters of the test cases is as follows: The page element corresponding to the test case is taken as the associated page element, and the number of times the associated page element is identified in the test case is determined based on the identification deviation data of the associated page element. Using the number of identification deviations, identify the page elements with identification risks among the associated page elements; Based on the risk identification page element data in the associated page elements of the test case, determine the caching control strategy for the database input parameters of the test case.

8. The UI automated testing method based on database input parameters as described in claim 7, characterized in that, The risk identification page element is the associated page element whose number of identification deviations exceeds a preset deviation number threshold.

9. The UI automated testing method based on database input parameters as described in claim 4, characterized in that, The method for determining the update management method of the cache management strategy for the test cases of the target management strategy is as follows: The test cases of the target control strategy are used as cache control test cases. Based on the associated page elements of the test cases, the same number of risk identification page elements of the cache control test cases and different test cases are determined. The same number is used to determine the reference test cases of the cache control test cases. Using the cache management method of the associated database of the test cases of the target control strategy, the associated database of the preset cache management method in the associated database is determined and used as the restricted database; Based on the reference test case data of the cache management test cases and the restriction database data, the update result of the cache management strategy of the cache management test cases is determined.

10. The UI automated testing method based on database input parameters as described in claim 9, characterized in that, The reference test case is the same risk-identifying page element as the cache management test case, but the test case has a proportion of risk-identifying page elements in the cache management test case that is greater than a preset risk proportion threshold.

Images