A method and system for testing the functions of a smart terminal

Abstract

This invention discloses a method and system for functional testing of smart terminals, belonging to the field of smart terminal functional testing technology. The method includes: constructing a dynamic requirement tracking mechanism, parsing UI elements and generating a topology map that marks resource usage types and hierarchical dependencies; establishing a requirement-use case-defect association matrix to automatically update use case status when requirements change; executing tests based on the topology map and matrix, traversing paths according to a preset strategy and collecting data to compare expected results; optimizing and iterating based on test results, adjusting node weights and matrix mapping relationships, and generating new test paths and use case suggestions. The system includes modules for dynamic requirement tracking, association matrix management, test execution, optimization iteration, and data storage. This invention achieves precise adaptation of the test scope to requirement changes, improves test coverage and defect tracing efficiency, forms a closed-loop optimization mechanism for test strategies, and adapts to the testing needs of complex systems and agile development models.

Description

Technical Field

[0001] This invention relates to the field of smart terminal function testing technology, and in particular to a smart terminal function testing method and system. Background Technology

[0002] With the rapid development of smart terminal technology, its functions are becoming increasingly complex and modular, and multi-module collaborative systems are becoming mainstream. Meanwhile, agile development models are widely used in the industry, placing higher demands on the efficiency, coverage, and adaptability of functional testing. Currently, the field of smart terminal functional testing has gradually introduced automation technology, covering UI element parsing, test path planning, test case management, and defect tracking. This uses tools to replace some manual operations to adapt to the rapid iteration pace of development, and the industry generally focuses on the systematization and standardization of testing processes.

[0003] Several technical problems exist in current functional testing of smart terminals: First, the correlation between requirements, test cases, and defects is not close. When requirements are added, modified, or deleted, it is difficult to quickly identify the affected test cases, leading to a mismatch between the test scope and the requirements. Second, test paths lack structured management, with insufficient recording of the resource consumption characteristics and hierarchical dependencies of page nodes, resulting in blind path planning and a tendency for incomplete coverage or uncontrolled resource consumption. Third, test execution and result analysis lack a closed-loop mechanism, making it difficult to optimize test paths and test case design based on test data, thus hindering the continuous adaptation of test strategies to system iterations. These problems limit testing efficiency and make it difficult to meet the testing needs of complex systems and agile development models. Summary of the Invention

[0004] The purpose of this invention is to overcome one or more shortcomings of the prior art and provide a method and system for testing the functions of a smart terminal.

[0005] The objective of this invention is achieved through the following technical solution:

[0006] A method for testing the functionality of a smart terminal includes the following steps:

[0007] S1. Construct a dynamic demand tracking mechanism, parse the UI elements of the smart terminal, extract the type, attributes and interaction logic of the elements, generate a topology graph with the page as the node and the jump operation as the edge, mark the resource occupation type of each node in the topology graph, including the occupation characteristics of computing resources, storage resources and network resources, and record the hierarchical relationship and dependency rules between nodes.

[0008] S2. Establish a requirement-use case-defect association matrix. The matrix contains requirement items, test cases, defect information, and mapping relationship parameters between the three. When a requirement is added, modified, or deleted, the status update of the associated test cases is automatically triggered through the association rules of the matrix, and a status change log and a list of affected areas are generated synchronously.

[0009] S3. Perform tests based on the topology graph and association matrix. After determining the starting node of the test, perform jump operations according to the preset path traversal strategy, collect the response data, operation results and resource usage data of each node in real time, and compare the collected data with the expected results in the association matrix.

[0010] S4. Based on the test results, perform optimization iterations, analyze uncovered requirements and high-frequency defect nodes, adjust the node weights and mapping relationships of the association matrix in the topology graph, and generate new test paths and supplementary test case suggestions.

[0011] Furthermore, in step S1, when parsing the UI elements of the smart terminal, a combination of static parsing and dynamic capture is used. Static parsing obtains the basic attributes of the elements, while dynamic capture records the state changes of the elements during the interaction process.

[0012] Furthermore, in step S2, the mapping parameters of the association matrix include the coverage of requirements and use cases, and the association strength between use cases and defects. The parameter values ​​are obtained through training with historical test data.

[0013] Furthermore, in step S3, the preset path traversal strategies include depth-first traversal and breadth-first traversal, which can be automatically selected or combined according to the number of nodes and hierarchical relationships in the topology graph.

[0014] Furthermore, in step S4, when analyzing the uncovered requirements, the missing test case types and supplementation directions corresponding to the uncovered requirements are determined by combining the mapping relationships in the association matrix.

[0015] Furthermore, when dynamically capturing changes in element state, the response time, display style, and data interaction content of the element under different operation commands are recorded.

[0016] Furthermore, when the mapping parameters of the association matrix are lower than a preset threshold, an early warning is automatically issued, prompting a re-verification of the accuracy of the association between requirements, use cases, and defects.

[0017] Furthermore, during the path traversal, paths containing key functional nodes are marked as mandatory to ensure that the path is executed completely.

[0018] A smart terminal functional testing system, comprising: a dynamic requirements tracking module, an association matrix management module, a test execution module, and an optimization iteration module;

[0019] The dynamic demand tracing module is used to perform the topology graph generation and resource marking operations in step S1;

[0020] The association matrix management module is used to implement the matrix creation and status update functions in step S2;

[0021] The test execution module is used to complete the test execution and data acquisition in step S3;

[0022] The optimization iteration module is used to perform result analysis and strategy adjustment for step S4.

[0023] Furthermore, it also includes a data storage module for storing topology graph data, correlation matrix information, test data, and optimization iteration records, supporting data querying, exporting, and historical version backtracking.

[0024] The beneficial effects of this invention are:

[0025] (1) By using dynamic requirement tracking and association matrix management linkage technology, the automatic validity marking and rapid screening of test cases in the requirement iteration scenario can be achieved, so as to accurately adapt the test scope to requirement changes, reduce manual intervention costs and improve test preparation efficiency;

[0026] (2) By using the test execution and optimization iteration connection technology, the topology weight dynamic adjustment effect based on historical defect data is achieved, the test coverage depth of high-frequency defect paths is strengthened, and the association matrix is ​​driven to supplement the test case mapping, forming a closed-loop optimization mechanism for the test strategy.

[0027] (3) Through the cross-stage data backtracking technology of the data storage module, the effect of comparing and analyzing the multi-version topology diagram and matrix parameters in the test strategy review scenario is achieved, which helps to identify the effectiveness differences of different test schemes and supports the formulation of better strategies and optimization of resource allocation. Attached Figure Description

[0028] Figure 1 A flowchart illustrating the specific steps of a smart terminal function testing method provided in this embodiment of the invention;

[0029] Figure 2 A collaborative diagram of a smart terminal function testing system module provided in an embodiment of the present invention;

[0030] Figure 3 This is a closed-loop flowchart of a smart terminal function testing method provided in an embodiment of the present invention. Detailed Implementation

[0031] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0032] Example 1:

[0033] See Figure 1 This paper provides a method for testing the functionality of smart terminals, including the following steps:

[0034] S1. Construct a dynamic demand tracking mechanism, parse the UI elements of the smart terminal, extract the type, attributes and interaction logic of the elements, generate a topology graph with the page as the node and the jump operation as the edge, mark the resource occupation type of each node in the topology graph, including the occupation characteristics of computing resources, storage resources and network resources, and record the hierarchical relationship and dependency rules between nodes.

[0035] S2. Establish a requirement-use case-defect association matrix. The matrix contains requirement items, test cases, defect information, and mapping relationship parameters between the three. When a requirement is added, modified, or deleted, the status update of the associated test cases is automatically triggered through the association rules of the matrix, and a status change log and a list of affected areas are generated synchronously.

[0036] S3. Perform tests based on the topology graph and association matrix. After determining the starting node of the test, perform jump operations according to the preset path traversal strategy, collect the response data, operation results and resource usage data of each node in real time, and compare the collected data with the expected results in the association matrix.

[0037] S4. Based on the test results, perform optimization iterations, analyze uncovered requirements and high-frequency defect nodes, adjust the node weights and mapping relationships of the association matrix in the topology graph, and generate new test paths and supplementary test case suggestions.

[0038] In step S1, when parsing the UI elements of the smart terminal, a combination of static parsing and dynamic capture is used. Static parsing obtains the basic attributes of the elements, while dynamic capture records the state changes of the elements during the interaction process.

[0039] In step S2, the mapping parameters of the association matrix include the coverage of requirements and use cases, and the association strength between use cases and defects. The parameter values ​​are obtained by training with historical test data.

[0040] In step S3, the preset path traversal strategies include depth-first traversal and breadth-first traversal, which can be automatically selected or combined according to the number of nodes and hierarchical relationships in the topology graph.

[0041] In step S4, when analyzing the uncovered requirements, the missing test case types and supplementation directions corresponding to the uncovered requirements are determined by combining the mapping relationships in the association matrix.

[0042] When dynamically capturing changes in element state, record the element's response time, display style, and data interaction content under different operation commands.

[0043] When the mapping parameters of the association matrix are lower than a preset threshold, an early warning will be automatically issued, prompting a re-verification of the accuracy of the association between requirements, use cases, and defects.

[0044] During path traversal, paths containing key functional nodes are marked as mandatory to ensure that the path is executed completely.

[0045] See Figure 2 A smart terminal functional testing system is provided, including: a dynamic requirements tracking module, an association matrix management module, a test execution module, and an optimization iteration module;

[0046] The dynamic demand tracing module is used to perform the topology graph generation and resource marking operations in step S1;

[0047] The association matrix management module is used to implement the matrix creation and status update functions in step S2;

[0048] The test execution module is used to complete the test execution and data acquisition in step S3;

[0049] The optimization iteration module is used to perform result analysis and strategy adjustment for step S4.

[0050] The data storage module is used to store topology graph data, correlation matrix information, test data, and optimization iteration records, and supports data querying, exporting, and historical version backtracking.

[0051] The modular architecture of the intelligent terminal functional testing system consists of five core closed-loop processes: dynamic requirement tracking, correlation matrix management, test execution, optimization iteration, and data storage. Upward, it supports matrix creation and status updates, execution result analysis, and strategy adjustment functions. Downward, it corresponds to topology generation and resource marking, test execution and data acquisition, topology and matrix data storage, and backtracking functions.

[0052] Furthermore, dynamic requirement tracking and association matrix management work together: In agile development scenarios with frequent requirement iterations, after the dynamic requirement tracking module identifies changes in UI interaction logic, it can trigger the association matrix management module to automatically mark the validity of associated test cases and quickly filter test cases that need to be updated or added.

[0053] Furthermore, in regression testing scenarios, the historical defect data collected by the test execution module can drive the optimization iteration module to prioritize adjusting the topology weights of high-frequency defect nodes, thereby strengthening the test coverage of key paths.

[0054] Furthermore, in test strategy review scenarios, the data storage module retains the topology map version and matrix association parameter history records, which can support comparative analysis of the effectiveness of different test scheme versions and assist in formulating better strategies.

[0055] Furthermore, in complex page interaction scenarios, the multi-branch topology path generated by the dynamic requirement tracking module can guide the test execution module to automatically select a depth-first traversal strategy and penetrate to verify the integrity of nested functions.

[0056] Furthermore, in scenarios involving the assessment of the impact of requirement changes, the correlation matrix management module, combined with historical correlation data from the data storage module, can quickly estimate the impact of changes on test cases and defects, and plan the scope of regression testing in advance.

[0057] Example 2:

[0058] This embodiment relates to the field of functional testing technology for smart terminals. Through a systematic design encompassing dynamic requirement tracking, correlation matrix management, test execution, and iterative optimization, it addresses issues such as delayed requirement response, insufficient test case coverage, and difficulty in defect tracing in traditional testing. This method is applicable to functional testing of complex multi-module smart terminal systems. By employing structured steps, it automates and refines the testing process, ensuring comprehensive test coverage and reliable results.

[0059] S1. Establish a dynamic requirements tracking mechanism:

[0060] S1.1 employs static parsing tools to analyze the installation packages or source code of smart terminal applications, extracting the basic attributes of UI elements, including element type (such as buttons, input boxes, lists, pop-ups, etc.), unique identifiers (such as ID, name), location information (such as coordinates, hierarchy), default states (such as enabled / disabled, visible / hidden), and basic interaction logic (such as basic actions triggered by clicks). Static parsing ensures the acquisition of the inherent attributes of elements, providing a benchmark for subsequent dynamic interaction analysis.

[0061] S1.2 During application operation, the dynamic capture tool monitors the state changes of UI elements in real time during the interaction process and records the response time of the element after receiving the operation command (such as click, input, swipe), that is, the time interval from triggering to completing the response (such as page jump, content refresh);

[0062] Capture the display style of an element in different states, such as color, size, font, and icon changes (e.g., the color intensity of a button before and after a click, and the border style of an input box when it is focused).

[0063] Records data interactions between elements and the backend or other modules, such as text transmission in input boxes, data sources and formats for list loading, and dynamic information displayed in pop-ups (such as prompt text and status codes). Combining dynamic capture with static parsing, it fully presents the attributes and interactive characteristics of UI elements, providing comprehensive data for topology map construction.

[0064] S1.3 Based on the parsed UI element attributes and interaction logic, a test path topology graph is constructed, using independent pages of the smart terminal as nodes (such as the homepage, settings page, details page, etc.) and page navigation operations as directed edges (such as clicking the "Settings" button to navigate from the homepage to the settings page, and returning from the details page to the list page). The topology graph must completely cover all possible page navigation relationships within the application, including normal paths (such as the normal user operation flow) and abnormal paths (such as navigating to an error message page after entering invalid parameters).

[0065] S1.4 Mark the resource usage type for each page node in the topology graph, including the characteristics of computing resource usage (such as the CPU usage mode (continuous usage, peak usage) and thread usage (single-thread, multi-thread) during page loading and running).

[0066] Storage resource consumption characteristics (such as the frequency of local cache read / write during page runtime, resource consumption of database operations (query, insert, update), and logic for creating and deleting temporary files);

[0067] Network resource consumption characteristics (such as the type of network request for page loading (GET, POST), data transmission volume (text, images, video), and network connection stability requirements (such as whether offline mode is supported)). Marking the resource consumption type provides a basis for resource consumption analysis and path optimization in subsequent tests.

[0068] S1.5 Analyze the hierarchical relationship of each page node in the topology diagram, such as "Home" as a first-level node, "Settings Page" and "Personal Center Page" as second-level nodes, and "Account Settings Page" as a third-level node (relying on "Personal Center Page" for navigation), forming a clear hierarchical structure.

[0069] At the same time, the dependency rules between nodes are recorded, including prerequisite dependencies (such as the "payment page" depending on the "login page" to complete authentication before it can be accessed), data dependencies (such as the "order details page" depending on the order ID parameter passed by the "order list page" to load content), and state dependencies (such as the "edit mode page" depending on the "edit" button of the "view mode page" to be triggered before it can be accessed).

[0070] Recording hierarchical relationships and dependency rules ensures the completeness and rationality of the test path, avoiding test omissions due to missing dependencies.

[0071] S2. Establish a requirement-use case-defect correlation matrix:

[0072] The S2.1 association matrix contains three core elements and their inter-mapping relationships: the requirement items include a unique requirement identifier, a requirement description (such as "implement user avatar upload function"), a requirement priority (such as core requirement, secondary requirement), and a requirement version number;

[0073] Test cases include a unique identifier for the test case, the topology path corresponding to the test case (e.g., "Homepage → Personal Center Page → Avatar Upload Page"), the execution conditions for the test case (e.g., "Network environment is normal, user is logged in"), and the expected result (e.g., "Avatar uploaded successfully and displayed in real time").

[0074] Defect information includes a unique defect identifier, the use case to which the defect belongs, a defect description (e.g., "failed without prompting when uploading images larger than 50MB"), a defect status (e.g., "new", "fixed", "closed"), and a defect severity (e.g., "blocking", "general").

[0075] The three are linked through mapping parameters to form a closed-loop link of "requirement-use case-defect".

[0076] The mapping parameters of the S2.2 association matrix include the coverage of requirements and use cases (representing how many use cases cover a single requirement and the coverage depth of each use case on the requirement (e.g., "full coverage" or "partial coverage"), with parameter values ​​obtained through training on the matching frequency of requirements and use cases in historical test data), and the association strength between use cases and defects (representing the probability of triggering a specific defect when a use case fails, with parameter values ​​calculated based on the number of associations of "use case failure → defect occurrence" in historical data). The parameters need to be trained on multiple rounds of historical data to ensure they accurately reflect the association characteristics of the three.

[0077] S2.3 When a requirement is added, modified, or deleted, the system automatically executes the operation based on the matrix association rules:

[0078] When a new requirement is added, the system automatically retrieves the functional modules related to that requirement from the matrix, generates initial use case suggestions (use case templates based on similar requirements), and marks them as "to be designed".

[0079] When modifying requirements, identify the affected use cases (such as changes in requirement descriptions that cause mismatches between expected and actual use case results), update their status to "pending update", and simultaneously generate a status change log (recording the use case content before and after the change, the change time, and the operator).

[0080] When a requirement is deleted, the associated use case status is marked as "invalid," the relevant defect status is updated to "no fix required," and a list of affected scopes is generated (listing the affected use case ID, defect ID, and module name). After the status is updated, the system pushes a notification to testers to ensure timely handling of the change.

[0081] S2.4 When the mapping relationship parameters of the association matrix are lower than the preset threshold (e.g., coverage < 0.6, association strength < 0.5), the system will automatically issue an early warning, prompting testers to re-verify: if the coverage of requirements and use cases is lower than the threshold, check whether there are scenarios where requirements are not covered by use cases, or whether the use case design does not match the requirement description.

[0082] If the correlation strength between a use case and a defect is below a threshold, verify whether the defect was triggered by that use case, or whether there are other unrecorded associated use cases. The alert information must include the current parameter value, the threshold, the associated requirement / use case / defect ID, and verification suggestions to ensure the accuracy of the matrix correlation.

[0083] S3. Perform tests based on the topology graph and association matrix:

[0084] S3.1 Determine the starting node for testing based on the testing objectives (such as verifying new features, regression testing) and the priority of requirements in the correlation matrix:

[0085] The starting point for testing new features is the entry page to which the new feature belongs (e.g., the starting point for "new message notification feature" is the "message center page").

[0086] Full regression testing starts with the application's initial page (such as the homepage) to ensure coverage of all core paths; specialized testing (such as performance testing) starts with high-resource-consuming pages (such as video playback pages) and focuses on monitoring resource usage data.

[0087] The determination of the starting node needs to be combined with the hierarchical relationship of the topology graph to ensure that the target test range can be covered starting from this node.

[0088] S3.2's preset path traversal strategies include depth-first traversal and breadth-first traversal, with the specific selection methods as follows:

[0089] Depth-first traversal starts from the starting node and prioritizes traversing along a path to the deepest node (such as "Homepage → Settings Page → Account Settings → Password Change"). It is suitable for testing the integrity of complex business processes.

[0090] Breadth-first traversal starts from the starting node, first traversing all adjacent nodes (such as the "Settings", "Personal Center", and "Messages" pages on the homepage), and then traversing the child nodes of each node in turn. It is suitable for testing the parallel functions of multiple modules.

[0091] The system automatically selects a strategy based on the number of nodes and hierarchical relationships in the topology graph: depth-first search is selected when there are few nodes and deep hierarchies; breadth-first search is selected when there are many nodes and shallow hierarchies; and in complex scenarios, a combination of strategies can be used (such as depth-first search for core paths and breadth-first search for secondary paths).

[0092] Before traversing the path, S3.3 sets a mandatory test flag for nodes containing key functions (such as payment nodes, login nodes, and data submission nodes) to ensure that the node and its associated path are executed completely: the nodes with the mandatory test flag must meet the requirement that "failure to execute will result in the lack of core function testing" (e.g., if the payment node is not tested, the transaction function cannot be verified).

[0093] For the paths of nodes that must be tested, a complete traversal must be enforced (including normal and abnormal operations, such as payment success, payment failure, and payment scenarios when the network is interrupted).

[0094] If a mandatory node is not covered during the test, the system will issue a real-time alert and pause the test until the node is tested.

[0095] S3.4 executes page redirection operations according to the selected path traversal strategy, collecting response data in real time (feedback information from each node after receiving the operation, such as pop-up prompts, page loading completion signals, and interface return codes), operation results (whether the redirection was successful and whether the function was executed normally, such as whether the data was actually stored after the "save" operation), and resource usage data (collecting real-time data on computing resources (CPU utilization, number of threads), storage resources (cache usage, database read / write time), and network resources (uplink / downlink speed, request response time) based on the resource types marked in the topology diagram). The collection process must be synchronized with the operation to ensure the timeliness and accuracy of the data. The collection frequency is dynamically adjusted according to the resource consumption characteristics of the nodes (e.g., high-consumption nodes collect data once per second, and low-consumption nodes collect data once every 5 seconds).

[0096] S3.5 compares the collected response data, operation results, and resource usage data with the expected results of the test cases in the correlation matrix: the response data comparison needs to check whether the actual pop-up text and return code are consistent with the expectations (e.g., whether the expected "upload successful" prompt is actually the same).

[0097] The comparison of operation results needs to verify whether the function execution meets expectations (e.g., whether the data is really removed from the list after the "delete" operation); the comparison of resource usage data needs to confirm whether resource consumption is within the preset threshold (e.g., whether the expected CPU usage is <80% and whether it actually exceeds the limit).

[0098] The comparison results are divided into "pass", "fail", and "partially pass". For items that fail, the difference details should be recorded (e.g., the actual return code is 500, and the expected code is 200) to provide a basis for subsequent defect analysis.

[0099] S4. Optimize and iterate based on the test results:

[0100] S4.1 Analyze the requirements that are not covered by tests: determine whether the reason for the lack of coverage is missing test cases (no corresponding test cases), untraversed paths (test cases exist but the corresponding paths are not executed), or test case design defects (test cases do not cover all scenarios of the requirements).

[0101] Identify the types of missing test cases, such as missing boundary scenarios (e.g., not testing the maximum value of parameters), missing abnormal scenarios (e.g., not testing the functional performance when the network is interrupted), and missing related scenarios (e.g., not testing the interaction with other functions).

[0102] Define supplementary directions, generate supplementary use cases for missing types (such as "add an exception use case for 'file format error' for the file upload function"), and associate them with the corresponding requirement items in the association matrix.

[0103] S4.2 Analyze the common characteristics of nodes with high defect frequency during the statistical testing process (such as a page that frequently has defects in multiple tests): In terms of resource characteristics, determine whether the node belongs to the type of high computing resource or high network resource consumption (such as video editing pages that are prone to defects due to CPU overload).

[0104] Regarding path characteristics, check whether the defects are concentrated on a certain jump path (such as the "homepage → details page → edit page" path where the defect rate is high);

[0105] Regarding related use cases, verify whether the use cases that trigger defects share common design features (e.g., all involve large file transfers). The analysis results are used to locate potential risk points in nodes, providing direction for subsequent optimization (e.g., optimizing resource allocation strategies for nodes with high defects).

[0106] S4.3 Based on the test results, adjust the weights of each node in the topology graph. The weights reflect the test priority of the nodes: increase the weight of nodes corresponding to uncovered requirements to ensure that subsequent tests traverse them first; increase the weight of high-frequency defect nodes to increase the test frequency.

[0107] Nodes that are defect-free and whose requirements have been met will have their weights reduced to minimize unnecessary redundant testing. After the weights are adjusted, the path traversal strategy of the topology graph will automatically adapt to the new weights, prioritizing paths to nodes with higher weights.

[0108] S4.4 Based on the test case execution status and defect association data in the test results, update the mapping relationship parameters of the association matrix: if a test case successfully covers a newly added requirement scenario, increase its coverage parameter with the corresponding requirement; if a test case triggers a new defect multiple times, update its association strength parameter with the defect.

[0109] For "dead" use cases, remove their mapping relationships with requirements and defects to avoid interfering with subsequent testing. Adjustments to mapping relationships must be recorded synchronously in historical versions to support retrospective analysis.

[0110] Based on the above analysis and adjustments, S4.5 generates new test paths and supplementary test case suggestions: The new test paths combine the adjusted node weights and topology graph dependencies, prioritizing the coverage of high-weight nodes, uncovered requirement nodes, and high-frequency defect nodes;

[0111] For missing types of uncovered requirements, it is recommended to add new test cases (such as "adding an exception test case for 'file upload without network'"). For high-frequency defect scenarios, it is recommended to optimize existing test cases (such as "adding a step-by-step verification test case for large file uploads").

[0112] The recommendations should include a detailed path description, key points of test case design, and expected requirements / scenarios to be covered, providing clear guidance for the next round of testing.

[0113] This embodiment constructs a complete intelligent terminal functional testing system through the coordinated execution of steps S1 to S4: a dynamic requirement tracking mechanism ensures comprehensive analysis of UI elements and paths, providing a structured foundation for testing; an association matrix enables precise association and dynamic updates of requirements, test cases, and defects, ensuring the relevance of testing; during the test execution phase, reasonable path strategies and data collection ensure the effectiveness of the testing process; and the optimization and iteration phase continuously improves the testing strategy, enhancing test coverage and defect tracing efficiency. This method, through pure textual description and logical expansion, achieves the systematization and automation of intelligent terminal functional testing, applicable to various multi-module complex system testing scenarios, and solves the problems of traditional testing.

[0114] Example 3:

[0115] See Figure 3 This paper presents an implementation process for a functional testing method for smart terminals, which constructs an automated testing closed loop through module collaboration.

[0116] After the module starts the process, the dynamic requirements tracking module parses the smart terminal UI elements and interaction logic, and the topology map generation module simultaneously constructs the page jump path, with the two working together in a two-way linkage.

[0117] If the smart terminal's functions are iterated, the dynamic requirements tracking identifies new page interaction rules, and the topology graph generation module automatically supplements the page's jump relationships with upstream and downstream nodes to ensure that the test path covers the latest functions.

[0118] The association matrix management module establishes associations based on mapping rules for requirements, test cases, and defects. When a requirement version is updated, it automatically marks the status of the affected test cases and clarifies the test scope.

[0119] During the test execution phase, the virtual machine environment creation module simulates multi-terminal configurations (such as system version and hardware parameters) to support parallel testing.

[0120] The path traversal execution module traverses the page's regular and abnormal interaction paths according to the depth or breadth strategy of the topology graph.

[0121] The real-time data acquisition module synchronously captures response results and resource consumption data. Simultaneously, the log analysis module parses the runtime logs in real time; if an operation triggers an error, it automatically marks the faulty node, assisting the test execution module in deciding on retry or pause logic.

[0122] After the test data is transferred to the optimization and iteration module, if a high-frequency defect path is detected, the module automatically increases the test weight of the corresponding topology node.

[0123] If a gap in requirement coverage is identified, the association matrix management module is driven to supplement test case mappings and dynamically adjust the testing strategy. The data storage module retains the topology structure, matrix relationships, and full-process test data. During test strategy review, historical version data can be retrieved to compare defect distribution and path coverage differences across different iteration cycles, assisting in solution optimization.

[0124] The final process reaches the endpoint module, completing the automated closed loop of smart terminal function testing, adapting to dynamic requirements and complex scenario testing needs.

[0125] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for testing the functionality of a smart terminal, characterized in that, Includes the following steps: S1. Construct a dynamic demand tracking mechanism, parse the UI elements of the smart terminal, extract the type, attributes and interaction logic of the elements, generate a topology graph with the page as the node and the jump operation as the edge, mark the resource occupation type of each node in the topology graph, including the occupation characteristics of computing resources, storage resources and network resources, and record the hierarchical relationship and dependency rules between nodes. S2. Establish a requirement-use case-defect association matrix. The matrix contains requirement items, test cases, defect information, and mapping relationship parameters between the three. When a requirement is added, modified, or deleted, the status update of the associated test cases is automatically triggered through the association rules of the matrix, and a status change log and a list of affected areas are generated synchronously. S3. Perform tests based on the topology graph and association matrix. After determining the starting node of the test, perform jump operations according to the preset path traversal strategy, collect the response data, operation results and resource usage data of each node in real time, and compare the collected data with the expected results in the association matrix. S4. Based on the test results, perform optimization iterations, analyze uncovered requirements and high-frequency defect nodes, adjust the node weights and mapping relationships of the association matrix in the topology graph, and generate new test paths and supplementary test case suggestions.

2. The method according to claim 1, characterized in that, In step S1, when parsing the UI elements of the smart terminal, a combination of static parsing and dynamic capture is used. Static parsing obtains the basic attributes of the elements, while dynamic capture records the state changes of the elements during the interaction process.

3. The method according to claim 1, characterized in that, In step S2, the mapping parameters of the association matrix include the coverage of requirements and use cases, and the association strength between use cases and defects. The parameter values ​​are obtained by training with historical test data.

4. The method according to claim 1, characterized in that, In step S3, the preset path traversal strategies include depth-first traversal and breadth-first traversal, which are automatically selected or combined according to the number of nodes and hierarchical relationships in the topology graph.

5. The method according to claim 1, characterized in that, In step S4, when analyzing the uncovered requirements, the mapping relationship in the association matrix is ​​used to determine the missing test case types and supplementation directions for the uncovered requirements.

6. The method according to claim 2, characterized in that, When dynamically capturing changes in element state, record the element's response time, display style, and data interaction content under different operation commands.

7. The method according to claim 3, characterized in that, When the mapping parameters of the association matrix are lower than a preset threshold, an early warning will be automatically issued, prompting a re-verification of the accuracy of the association between requirements, use cases, and defects.

8. The method according to claim 4, characterized in that, During path traversal, paths containing key functional nodes are marked as mandatory to ensure that the path is executed completely.

9. A smart terminal function testing system, used to execute a smart terminal function testing method according to any one of claims 1-8, characterized in that, include: The module includes a dynamic requirements tracing module, an association matrix management module, a test execution module, and an optimization iteration module. The dynamic demand tracing module is used to perform the topology graph generation and resource marking operations in step S1; The association matrix management module is used to implement the matrix creation and status update functions in step S2; The test execution module is used to complete the test execution and data collection in step S3; The optimization iteration module is used to perform result analysis and strategy adjustment for step S4.

10. The system according to claim 9, characterized in that, It also includes a data storage module for storing topology graph data, correlation matrix information, test data, and optimization iteration records, supporting data querying, exporting, and historical version backtracking.

Images