Device testing method, apparatus, terminal device, and computer-readable storage medium

Abstract

This application discloses a device testing method, apparatus, terminal device, and computer-readable storage medium. The method includes: acquiring historical user behavior data; analyzing the historical behavior data to determine key user usage scenarios; generating test data corresponding to the key usage scenarios; and testing the device based on the test data to obtain test results. The method of this application uses real historical user behavior data as the basis for generating test data, introducing key user usage scenarios between the historical user behavior data and the test data generation. These key usage scenarios serve as the basis for test data generation and device testing, reflecting representative operational characteristics and usage trajectories of users during real-world use, thus improving the authenticity and effectiveness of performance evaluation of the tested device.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a device testing method, apparatus, terminal equipment, and computer-readable storage medium. Background Technology

[0002] Existing equipment testing and performance evaluation technologies typically rely on pre-defined test scripts or manually constructed test cases. These test cases are often derived from experience or idealized usage assumptions, making it difficult to comprehensively cover the complex behavioral patterns formed by real users during actual use. Because user behaviors exhibit correlations in terms of temporal sequence, operational relationships, and usage habits, different operations do not occur independently. Test data generated based on discrete behaviors or general processes cannot accurately reflect typical operational combinations formed during real-world use, thus the test results do not adequately characterize the device's performance under actual usage conditions. In other words, existing testing solutions cannot comprehensively and objectively evaluate the performance of tested equipment driven by real user behavior. Summary of the Invention

[0003] This application provides a device testing method, apparatus, terminal device, and computer-readable storage medium. It can use real historical user behavior data as the basis for generating test data, introduce key usage scenarios between the generation of user historical behavior data and test data, and use key usage scenarios as the basis for test data generation and device testing. This reflects the representative operational characteristics and usage trajectory of users in real use, thereby improving the authenticity and effectiveness of performance evaluation of the tested device.

[0004] The technical solution adopted by this invention to solve the problem is as follows: On the one hand, this application provides a device testing method, including: Obtain users' historical behavior data; Analyze historical behavioral data to identify key user scenarios; Generate test data corresponding to key use cases; The test equipment is tested based on the test data to obtain the test results.

[0005] In some implementation schemes of this application, historical behavioral data is analyzed to identify key user scenarios, including: Based on historical behavioral data, user behavior is modeled to obtain a user behavior model; Determine the use cases corresponding to the user behavior model; Identify key use cases within the user behavior model's corresponding usage scenarios.

[0006] In some embodiments of this application, user behavior is modeled based on historical behavioral data to obtain a user behavior model, including: Historical behavior data is input into the first intelligent model, which then outputs the user behavior chain extracted from the historical behavior data, as well as the frequency of occurrence of the corresponding user behavior chain. Based on the user behavior links that meet the first predetermined condition in terms of frequency of occurrence, the user behavior is modeled to obtain a user behavior model.

[0007] In some implementation schemes of this application, test data corresponding to key use cases is generated, including: Among multiple user behavior models, the model corresponding to the key use case is selected as the test behavior model; Determine the execution parameters corresponding to the test behavior model; Based on the execution parameters, test scripts corresponding to the test behavior model are generated, and test data is obtained.

[0008] In some implementation schemes of this application, the execution parameters corresponding to the test behavior model are determined, including: Historical behavior data is input into the second intelligent model, and the second intelligent model outputs the first data range of behavior parameters in the test behavior model. Based on the first data range of the behavioral parameters in the test behavior model, the execution parameters corresponding to the test behavior model are determined.

[0009] In some embodiments of this application, the test equipment is tested based on test data to obtain test results for the test equipment, including: The test equipment is tested based on the test data, and the performance data of the test equipment during the test process is collected. The performance data is analyzed to obtain the test results of the test equipment.

[0010] In some embodiments of this application, the test results include one or more of the following: performance mean, performance standard deviation, and anomaly rate. The performance data is analyzed to obtain the test results of the test equipment, including: Statistical analysis of the performance data yields the performance mean and standard deviation. When the performance data is not within the second data range, or the performance mean is not within the third data range, or the performance standard deviation is not within the fourth range, it is determined that the performance data is abnormal. The anomaly rate of the test equipment is obtained by calculating the proportion of abnormal performance data in the total performance data.

[0011] Secondly, embodiments of the present invention also provide a device testing apparatus, comprising: The acquisition module is used to acquire users' historical behavior data; The determination module is used to analyze historical behavior data to determine the user's key usage scenarios; The generation module is used to generate test data corresponding to key use cases; The testing module is used to test the testing equipment based on the test data and obtain the test results of the testing equipment.

[0012] Thirdly, this application also provides a terminal device, which includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor to implement the device testing method of any of the first aspects.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps of the device testing method of any of the first aspects.

[0014] The beneficial effects of this invention are as follows: By using real historical user behavior data as the basis for generating test data, and introducing key user usage scenarios between the generation of user historical behavior data and test data, the key usage scenarios serve as the basis for test data generation and device testing, reflecting the representative operational characteristics and usage trajectories of users in real use, thereby improving the authenticity and effectiveness of performance evaluation of test devices. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of a device testing system provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating one embodiment of the device testing method provided in this invention. Figure 3 This is a schematic diagram of the structure of the equipment testing system provided in an embodiment of the present invention; Figure 4 This is a schematic block diagram of the equipment testing device provided in the embodiment of the present invention; Figure 5 This is a schematic diagram of an embodiment of the terminal device provided in this invention. Detailed Implementation

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

[0018] In the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more of the stated features.

[0019] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0020] It should be noted that since the method in this application embodiment is executed in a terminal device, the processing objects of each terminal device exist in the form of data or information, such as time, which is essentially time information. It can be understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the terminal device can process them. Specific details will not be elaborated here.

[0021] This application provides a device testing method, apparatus, terminal device, and computer-readable storage medium, which will be described in detail below.

[0022] Please see Figure 1 , Figure 1 This is a schematic diagram of a device testing system provided in an embodiment of this application. The device testing system may include a terminal device 100, which integrates a device testing apparatus, such as... Figure 1 Terminal devices in the process.

[0023] In this embodiment, the terminal device 100 is mainly used to acquire users' historical behavior data; analyze the historical behavior data to determine the user's key usage scenarios; generate test data corresponding to the key usage scenarios; and test the test device based on the test data to obtain the test results of the test device. The user's real historical behavior data can be used as the basis for generating test data. By introducing the user's key usage scenarios between the generation of user historical behavior data and test data, and using the key usage scenarios as the basis for test data generation and device testing, the representative operational characteristics and usage trajectories of the user in real use can be reflected, which can improve the authenticity and effectiveness of performance evaluation of the test device.

[0024] In this embodiment, the terminal device 100 can be an independent server, a server network, or a server cluster. For example, the terminal device 100 described in this embodiment includes, but is not limited to, a computer, a network host, a single network server, a set of multiple network servers, or a cloud server composed of multiple servers. The cloud server is composed of a large number of computers or network servers based on cloud computing.

[0025] It is understood that the terminal device 100 used in the embodiments of this application can be a device that includes both receiving and transmitting hardware, that is, a device having receiving and transmitting hardware capable of performing bidirectional communication on a bidirectional communication link. Such a device may include: cellular or other communication devices having a single-line display, a multi-line display, or a cellular or other communication device without a multi-line display. Specifically, the terminal device 100 may be a desktop terminal or a mobile terminal, and the terminal device 100 may also be one of a mobile phone, tablet computer, laptop computer, etc.

[0026] Those skilled in the art will understand that Figure 1 The application environment shown is merely one application scenario of the solution in this application and does not constitute a limitation on the application scenario of the solution in this application. Other application environments may include those that are more specific to this application. Figure 1 The number of more or fewer terminal devices shown, for example Figure 1 Only one terminal device is shown in the diagram. It is understood that the device testing system may also include one or more other services, which are not specified here.

[0027] In addition, such as Figure 1 As shown, the device testing system may also include a memory 200 for storing data, such as historical behavior data, test data, test results, etc.

[0028] It should be noted that, Figure 1The schematic diagram of the device testing system shown is merely an example. The device testing system and scenario described in this application are for the purpose of more clearly illustrating the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of device testing systems and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0029] First, this application provides a device testing method. The device testing method is executed by a device testing apparatus, which is applied to a terminal device. The device testing method includes: acquiring historical behavior data of users; analyzing the historical behavior data to determine the key usage scenarios of users; generating test data corresponding to the key usage scenarios; and testing the device based on the test data to obtain the test results of the device.

[0030] like Figure 2 The diagram shown is a flowchart of an embodiment of the device testing method in this application. The device testing method may include the following steps S201 to S203, as detailed below: Step S201: Obtain the user's historical behavior data.

[0031] In one specific embodiment, the user can be a single user or a group of users. Historical behavior data is a collection of data generated by the user's operations on the device within a certain period of time, which can characterize the user's actual operational behavior. Historical behavior data may include application launch and exit records, application usage duration, function call sequence, interface switching behavior, input operations, network usage status changes, device status changes, etc. For example, in daily use, a user may unlock the device, launch an application, switch interfaces multiple times, operate continuously for a period of time, and then exit the application. The above continuous operation process can all be included as part of the historical behavior data.

[0032] Furthermore, acquiring historical user behavior data refers to collecting data reflecting the user's actual operational behavior from the operation of mobile phones or other electronic devices without affecting normal user use. This acquisition can be achieved using existing data collection mechanisms within the device and system, and the specific acquisition method is not limited to any one form. Specifically, historical user behavior data can be acquired at the operating system level. For example, through the operating system's recording mechanisms for application lifecycles, system events, and user interaction events, data can be collected on user actions such as application startup, switching, and exiting; interface navigation; input triggering; and system-level behavior data such as foreground / background switching and screen on / off. In addition, historical user behavior data can also be acquired at the application level. By setting up behavior recording modules within applications, user actions within the application can be recorded, such as access to function entry points, page dwell time, operation sequence, and function call frequency. Behavioral data collected from multiple applications can also be aggregated to form cross-application historical user behavior data. Historical user behavior data can also be obtained through the device's own logging system or monitoring modules, such as user operation-related information recorded in system logs, performance logs, or event logs. By parsing the log data, the user's operation trajectory during device use can be reconstructed.

[0033] Furthermore, when acquiring users' historical behavior data, the data can be anonymized or desensitized according to actual needs to protect user privacy, and the data can be filtered and organized according to preset time windows or usage scenarios.

[0034] Step S202: Analyze historical behavior data to determine the user's key usage scenarios.

[0035] In one specific embodiment, historical behavior data may include operation records, application usage records, and time information related to the operations generated by the user during device use. By analyzing the historical behavior data, not only can the order in which the user performs various operations be determined, but the usage context and corresponding purpose of the user during actual device use can also be identified.

[0036] In one specific embodiment, a key use case refers to an abstract representation of the overall device usage pattern exhibited by a user performing a series of operations. A key use case can include semantic content such as the user's purpose, operational rhythm, and environmental characteristics within that scenario. For example, a user quickly checking and replying to important messages during their morning commute can be defined as a key use case; another user's immersive use of browsing content and interacting with it for an extended period in the evening can also be defined as a key use case. In other words, key use cases are not limited to the user's most frequently used behaviors, but can also include combinations of operations that occur less frequently but are semantically important, such as usage scenarios involving the submission of important information, state switching, or the triggering of key functions. By analyzing historical behavioral data to determine key use cases, the usage characteristics of real users under specific semantic conditions can be extracted, providing scenario-level guidance for subsequent test data generation.

[0037] Step S203: Generate test data corresponding to key application scenarios.

[0038] In one specific embodiment, test data refers to a set of data that can drive the test device to perform corresponding operations or simulate corresponding usage states. After determining the key usage scenarios, corresponding test data can be generated based on the user's usage semantics and overall usage patterns reflected in those key usage scenarios. For example, by analyzing historical behavioral data, the typical usage sequence, operation frequency, or usage duration of a certain type of application can be obtained, and this information can be transformed into operation data that the test device can execute. The test data generated through this step, compared to preset or randomly generated data, is more able to reflect the behavioral characteristics of real users when using the device, thus providing more representative input for subsequent testing.

[0039] In some implementations, test data can be presented as operation sequence data, that is, a set of user operation instructions or event information recorded in chronological order. For example, test data may include continuous operations such as "unlocking the device—launching the first application—switching pages—triggering a function—switching to the second application—returning to the desktop," with each operation corresponding to a specific operation type, trigger time, or duration, thus allowing for the replay or simulation of the user's actual operation process on the test device. Furthermore, test data may also include data related to the device's operating status, used to simulate the device's state conditions during user operation. For example, it may include network status change data, battery status change data, foreground / background switching status, etc., placing the test device in an operating environment similar to real-world use during testing.

[0040] Step S204: Test the test equipment based on the test data to obtain the test results of the test equipment.

[0041] In one specific embodiment, the generated test data can be used as input to drive the test device to perform corresponding operations or operating states, thereby detecting the performance of the test device under the influence of the test data. The test device can be a mobile phone, tablet computer, or other electronic device to be evaluated, and the test result refers to performance-related data or evaluation conclusions collected during the test, such as the device's operational stability, response time, or resource consumption.

[0042] By conducting tests based on the aforementioned test data, the testing process can be made as close as possible to the actual user experience, thereby obtaining test results that reflect the performance of the test equipment in real-world usage scenarios, providing a more valuable basis for equipment performance evaluation.

[0043] In one specific implementation, historical behavior data is analyzed to determine key user scenarios, including: modeling user behavior based on historical behavior data to obtain a user behavior model; determining the usage scenarios corresponding to the user behavior model; and identifying key usage scenarios within the usage scenarios corresponding to the user behavior model.

[0044] In this embodiment, the analysis results of historical behavior data can be used to abstract and structure the operation sequence, operation relationships, and occurrence patterns exhibited by users during device use, thereby forming a model that can describe the overall behavioral characteristics of users. The user behavior model can be a mathematical or logical expression of user behavior on the device, and may include common user operation paths, the sequential relationship between different operations, the frequency or probability of a certain type of operation, etc. For example, by analyzing a large amount of historical behavior data, a behavior model describing the order in which users switch between different applications and the relationship between their usage duration can be constructed, or a behavior model describing the order of function calls within a certain application can be constructed. The user behavior model can summarize the common characteristics of user behavior, rather than relying on single, isolated behavior records.

[0045] After obtaining the user behavior model, the corresponding usage scenarios can be further determined. A usage scenario refers to the set of operation combinations and operation rules formed by users under specific usage purposes, usage backgrounds and usage conditions. It can include semantic information such as the user's usage intention, usage rhythm and related environmental conditions. For example, by analyzing the user behavior model, the following usage scenarios may be obtained: (1) Rapid information processing scenario: users quickly view messages, complete replies and return to the main interface during commuting or rest breaks; (2) Immersive content browsing scenario: users continuously browse content, switch pages and interact with content for a long time in the evening; (3) Key function operation scenario: when users submit orders or make payments, a series of operations and state switching are involved. Although the frequency of occurrence is low, the operation semantics are important.

[0046] Building upon this foundation, key use cases can be further identified from the usage scenarios corresponding to the user behavior model. Key use cases refer to those that are representative or important to user behavior characteristics under specific usage semantics. These can include high-frequency use cases as well as low-frequency but semantically important cases, such as scenarios involving important information submission, state switching, or key functional operations. By extracting key use cases, we can focus on the core behavioral patterns of users under specific usage conditions and purposes, providing scenario-level guidance for subsequent test data generation.

[0047] Based on key use cases, corresponding test data can be generated. For example, for the "rapid information processing scenario," the generated test data can include operation sequences such as unlocking the device, launching the messaging app, opening a new message, quickly replying, and returning to the main interface; for the "immersive content browsing scenario," the generated test data can include operation sequences such as continuous page switching, content scrolling, function clicking, and keeping the device running in the foreground for an extended period of time; for the "key function operation scenario," the test data includes a complete operation sequence from launching the application, entering the payment function, filling in information, submitting the operation, to status confirmation, along with device status change information, such as network status, battery status, or foreground / background switching information.

[0048] The test data generated in the above manner not only inherits the overall characteristics of real user behavior, but also reflects the semantic content of the usage scenario, making the test more closely resemble the actual operation and usage status of users in key usage scenarios.

[0049] In one specific implementation, user behavior is modeled based on historical behavior data to obtain a user behavior model, including: inputting historical behavior data into a first intelligent model, outputting user behavior links extracted from historical behavior data and the frequency of occurrence of user behavior links; and modeling user behavior based on user behavior links whose frequency of occurrence meets a first predetermined condition to obtain a user behavior model.

[0050] In this embodiment, the first intelligent model refers to an artificial intelligence model with data analysis and feature extraction capabilities. It can be a model trained based on machine learning or deep learning, used to process and analyze input historical behavioral data. A user behavior chain refers to a set of continuous behaviors or operation paths formed by a user during device use, exhibiting temporal sequence and logical correlation. For example, it could be a complete operation chain from starting the device, entering an application, sequentially performing multiple functional operations, to exiting the application. Compared to a single operation, a user behavior chain can more comprehensively reflect the user's actual behavior flow when using the device. The frequency of occurrence of a user behavior chain refers to the number of times or probability that the same behavior chain is repeatedly triggered at different times or by different users in historical behavioral data, reflecting the prevalence of the behavior chain in actual use. The first predetermined condition can be a threshold condition set for the frequency of occurrence, such as behavior chains with a frequency higher than a certain threshold, or those ranking among the top in frequency of occurrence, used to filter representative user behavior chains.

[0051] User operation records, event sequences, or log data generated during device use can be input into the first intelligent model as historical behavior data. The first intelligent model outputs user behavior links extracted from the historical behavior data and their corresponding frequencies of occurrence. Then, user behavior can be modeled based on user behavior links whose frequencies meet a first predetermined condition, resulting in a user behavior model that reflects mainstream or typical user usage paths.

[0052] By introducing an artificial intelligence model to automatically extract user behavior links and filter them based on their frequency of occurrence, the above approach helps to identify statistically significant and representative behavioral patterns from a large amount of complex historical behavior data. This avoids interference from occasional or low-frequency abnormal behaviors in model building, thus making the final user behavior model more reflective of the common usage behaviors of real users and providing a reliable model foundation for the subsequent generation of test data.

[0053] In one specific implementation, generating test data corresponding to key use cases includes: selecting the model corresponding to the key use case from multiple user behavior models as the test behavior model; determining the execution parameters corresponding to the test behavior model; and generating the test script corresponding to the test behavior model based on the execution parameters to obtain the test data.

[0054] In this implementation, multiple user behavior models of different types or characteristics can be constructed to describe the behavioral characteristics of different user groups, usage scenarios, or usage modes. For example, user behavior models for heavy users, light users, or user behavior models tailored to different application types or combinations of functions can be constructed. By setting multiple user behavior models, the behavioral characteristics of the device under different real-world usage modes can be more comprehensively covered. Based on this, a test behavior model can be selected from multiple user behavior models, and the execution parameters corresponding to the test behavior model can be determined. A test script corresponding to the test behavior model can then be generated based on the execution parameters.

[0055] When generating test data for key use cases, a model corresponding to the key use case can be selected from multiple user behavior models as the test behavior model. The selected test behavior model represents the typical combination of user operations and usage semantics in the key use case, guiding the generation of subsequent test data. Execution parameters refer to parameter information used to specify how the test behavior model is executed on the test device. These parameters may include the execution order of each operation, the time interval between operation triggers, the duration of the operation, the number of operations, or the degree of concurrency. For example, for a key use case of "rapid information processing," the corresponding execution parameters may include short operation intervals and high-frequency message viewing and reply times; for a key use case of "immersive content browsing," the corresponding execution parameters may include continuous operation, maintaining foreground operation for a long time, and page switching frequency. A test script is a set of instructions or operations that can be directly executed by the test device or test system, used to drive the test device to run according to the predetermined behavior model and execution parameters during the test process. By converting the test behavior model and its execution parameters into test scripts, the testing process can be automated and repeatable. The generated test scripts constitute the test data used for testing. They can reproduce user behavior in key usage scenarios on the test device, inheriting the overall characteristics of actual user use and reflecting the semantic features of key usage scenarios, thereby supporting the testing of the device's performance and functionality in specific usage situations.

[0056] In one specific implementation, determining the execution parameters corresponding to the test behavior model includes: inputting historical behavior data into a second intelligent model, and having the second intelligent model output a first data range of behavior parameters in the test behavior model; and determining the execution parameters corresponding to the test behavior model based on the first data range of behavior parameters in the test behavior model.

[0057] In this embodiment, the second intelligent model refers to an artificial intelligence model used to analyze the numerical or fluctuation characteristics of user behavior data. It may be the same as or different from the aforementioned first intelligent model, and is capable of learning and outputting the statistical distribution, variation range, or fluctuation pattern of behavioral parameters. Behavioral parameters are parameters used to quantitatively describe specific behavioral characteristics in a user behavior model, and may include operation interval time, duration of a single operation, number of triggers of a certain type of operation per unit time, page dwell time, application switching frequency, etc. For example, in a behavioral model describing a user browsing an application page, page dwell time is a type of behavioral parameter. The first data range of behavioral parameters in the test behavior model refers to the reasonable value range or fluctuation range of the corresponding behavioral parameter in real-world usage, given based on the actual values ​​of the corresponding behavioral parameter in historical behavioral data. For example, the dwell time of a certain page is usually distributed between a few seconds and tens of seconds; this range constitutes the first data range.

[0058] The operation records, event sequences, or log data generated by users during device use can be used as historical behavior data input into the second intelligent model. The second intelligent model outputs the first data range of behavioral parameters in the test behavior model. The first data range can reflect the changes in parameter values ​​in real user behavior, rather than a single fixed value.

[0059] Then, specific parameter values ​​can be selected or combined within the first data range as execution parameters corresponding to the test behavior model, guiding the actual execution of the test behavior model on the test device. For example, parameter values ​​can be randomly selected, selected according to a probability distribution, or selected according to preset rules within the first data range as specific execution parameters in the test script. Execution parameters determined in this way are controlled within a reasonable data range and can reflect the volatility of real user behavior.

[0060] In one specific implementation, the test equipment is tested based on test data to obtain test results, including: testing the test equipment based on test data and collecting performance data of the test equipment during the test process; analyzing the performance data to obtain test results of the test equipment.

[0061] In this embodiment, the generated test data can be used as input to drive the test device to run according to the user behavior or operation process described by the test data. For example, when the test data is a test script, the test device will execute operations such as application startup, interface switching, and function calls sequentially according to the script during the test, thereby simulating the usage process of a real user. During the test, the performance data of the test device can be collected in real time through the device's own monitoring module, operating system interface, or test tools. The performance data refers to the data generated during the execution of the test data by the test device, which reflects the device's operating status and performance. It may include, but is not limited to, processor utilization, memory utilization, response time, frame rate changes, power consumption changes, temperature changes, and abnormal event records.

[0062] The collected performance data can be statistically analyzed, compared, or evaluated to extract information reflecting the performance characteristics of the test equipment. For example, performance data can be analyzed over time to observe trends in performance indicators during continuous operation; the collected performance data can also be compared with preset performance thresholds or historical benchmark data to identify performance anomalies or bottlenecks. Through the analysis of performance data, evaluation results regarding the stability, smoothness, or resource utilization of the test equipment during testing can be obtained, i.e., the test results.

[0063] In one specific implementation, the test results include one or more of the following: performance mean, performance standard deviation, and anomaly rate. The performance data is analyzed to obtain the test results of the test equipment, including: performing statistical analysis on the performance data to obtain the performance mean and performance standard deviation; determining that the performance data is abnormal when the performance data is not within a second data range, or the performance mean is not within a third data range, or the performance standard deviation is not within a fourth range; and obtaining the anomaly rate of the test equipment based on the proportion of abnormal performance data in the total performance data.

[0064] In this embodiment, the test results include one or more of the following: performance mean, performance standard deviation, and anomaly rate. The performance mean refers to the average value of a performance indicator during the test, reflecting the overall level of that indicator on the device throughout the entire test. For example, calculating the average of processor utilization performance data yields the average proportion of processor resources used by the device during the test. The performance standard deviation refers to the dispersion or fluctuation range of performance data, used to measure the stability or consistency of the performance indicator during the test. For example, if the response time fluctuates significantly during application switching, the standard deviation will be high, indicating instability in device performance. The anomaly rate refers to the proportion of abnormal performance data during the test, used to quantify the frequency or severity of abnormal situations.

[0065] Performance data analysis includes statistical analysis of the collected data to obtain the performance mean and standard deviation. The performance data is then compared to predefined reference ranges. The second, third, and fourth data ranges correspond to the reasonable ranges for the performance data itself, the performance mean, and the performance standard deviation, respectively. For example, processor utilization should normally be between 10% and 80%, and this range can be considered the second data range. If the performance mean or standard deviation exceeds these ranges, it indicates potential anomalies in the performance data. By determining whether the performance data falls within these reasonable ranges, abnormal performance of the equipment during testing can be identified.

[0066] Furthermore, based on the proportion of abnormal performance data within the entire performance data set, the anomaly rate of the test equipment is calculated, thereby quantifying the frequency of performance anomalies during testing. For example, if 10 out of 1000 consecutive operations collect performance data that exceed the reasonable range, the anomaly rate is 1%. This approach not only provides insight into the overall performance level and fluctuations but also objectively reflects the frequency of anomalies, providing a basis for equipment performance evaluation and optimization.

[0067] In addition, test reports can be generated based on the test results. These reports can include various performance data collected during the test, especially highlighted anomalies, to visually present the device's performance during testing. Test reports can also analyze performance data trends, such as plotting line graphs of response time versus operation sequence, processor utilization distribution graphs, or memory usage curves, helping testers quickly identify performance fluctuation patterns. Furthermore, the reports can analyze the causes of anomalies, such as excessive workload, frequent application switching, or performance bottlenecks caused by specific function calls, and propose improvement suggestions, such as optimizing function implementation, adjusting system resource allocation, or improving application logic, to assist in device design optimization and performance improvement. By generating test reports, not only can test data and analysis results be comprehensively presented, but valuable references and guidance can also be provided for performance optimization.

[0068] like Figure 3As shown, the device testing system can include four layers, sequentially realizing the complete process from scenario simulation to performance evaluation and report generation. First, in the scenario simulation layer, the system uses AI assistance and scenario modeling to simulate typical user operations and usage scenarios on mobile phones or other electronic devices, generating data input for testing. This layer includes common usage scenarios such as screen locking, click responses, application launch and exit, page swiping and switching, as well as video playback and game operation, while also covering extreme scenarios to verify the device's performance under high load or abnormal conditions. By accurately reproducing real user behavior in the scenario simulation layer, the representativeness and authenticity of subsequent test data can be ensured.

[0069] Secondly, at the performance monitoring layer, during the simulation operation, the system collects key performance indicators in real time, including response latency, frame drop rate, CPU load, and memory load. This performance data comprehensively reflects the device's operating status under different operating and usage scenarios, providing an objective basis for subsequent analysis.

[0070] Subsequently, at the data analysis layer, the system processes and analyzes the collected performance data, using anomaly detection algorithms to identify performance fluctuations or abnormal events. Simultaneously, it calculates statistical indicators such as mean and standard deviation to quantify the overall performance level and stability of the equipment. By analyzing performance data trends and anomalies, the data analysis layer reveals potential performance bottlenecks and problems that may exist in real-world usage scenarios.

[0071] Finally, at the report generation layer, the system automatically generates test reports based on the data analysis results. These reports not only include key performance indicators such as frame drop rate, standard deviation, and average value, but also visualize performance trends, intuitively presenting the device's performance in various scenarios. Through these reports, testers can quickly understand the device's performance status, identify the causes of anomalies, and propose optimization suggestions based on the analysis results, thus providing a scientific basis for improving device performance.

[0072] To better implement the device testing method in the embodiments of this application, based on the device testing method, the embodiments of this application also provide a device testing apparatus, such as... Figure 4 As shown, the equipment testing apparatus 400 includes: Module 410 is used to acquire the user's historical behavior data; The determination module 420 is used to analyze historical behavior data and determine the user's key usage scenarios; The generation module 430 is used to generate test data corresponding to key use cases; Test module 440 is used to test the test equipment based on test data and obtain the test results of the test equipment.

[0073] In this embodiment, by using real historical user behavior data as the basis for generating test data, key user usage scenarios are introduced between the generation of user historical behavior data and test data. These key usage scenarios serve as the basis for test data generation and device testing, reflecting representative operational characteristics and usage trajectories of users during real use. This can improve the authenticity and effectiveness of performance evaluation of the test device.

[0074] In some embodiments of this application, the determining module 420 analyzes historical behavior data to determine the user's key usage scenarios, including: Based on historical behavioral data, user behavior is modeled to obtain a user behavior model; Determine the use cases corresponding to the user behavior model; Identify key use cases within the user behavior model's corresponding usage scenarios.

[0075] In some embodiments of this application, the determining module 420 models user behavior based on historical behavior data to obtain a user behavior model, including: Historical behavior data is input into the first intelligent model, which then outputs the user behavior chain extracted from the historical behavior data, as well as the frequency of occurrence of the corresponding user behavior chain. Based on the user behavior links that meet the first predetermined condition in terms of frequency of occurrence, the user behavior is modeled to obtain a user behavior model.

[0076] In some embodiments of this application, the generation module 430 generates test data corresponding to key use scenarios, including: Among multiple user behavior models, the model corresponding to the key use case is selected as the test behavior model; Determine the execution parameters corresponding to the test behavior model; Based on the execution parameters, test scripts corresponding to the test behavior model are generated, and test data is obtained.

[0077] In some embodiments of this application, the generation module 430 determines the execution parameters corresponding to the test behavior model, including: Historical behavior data is input into the second intelligent model, and the second intelligent model outputs the first data range of behavior parameters in the test behavior model. Based on the first data range of the behavioral parameters in the test behavior model, the execution parameters corresponding to the test behavior model are determined.

[0078] In some embodiments of this application, the test module 440 tests the test device based on test data to obtain test results for the test device, including: The test equipment is tested based on the test data, and the performance data of the test equipment during the test process is collected. The performance data is analyzed to obtain the test results of the test equipment.

[0079] In some embodiments of this application, the test results include one or more of the following: performance mean, performance standard deviation, and anomaly rate. The test module 440 analyzes the performance data to obtain the test results of the test equipment, including: Statistical analysis of the performance data yields the performance mean and standard deviation. When the performance data is not within the second data range, or the performance mean is not within the third data range, or the performance standard deviation is not within the fourth range, it is determined that the performance data is abnormal. The anomaly rate of the test equipment is obtained by calculating the proportion of abnormal performance data in the total performance data.

[0080] This application embodiment also provides a terminal device that integrates any of the device testing apparatuses provided in this application embodiment. The terminal device includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor from the steps of the device testing method in any of the embodiments described above.

[0081] This application also provides a terminal device that integrates any of the device testing apparatuses provided in this application. For example... Figure 5 As shown, it illustrates a structural schematic diagram of the terminal device involved in the embodiments of this application. Specifically: The terminal device may include components such as a processor 501 with one or more processing cores, a memory 502 with one or more computer-readable storage media, a power supply 503, and an input unit 504. Those skilled in the art will understand that... Figure 5 The terminal device structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 501 is the control center of the terminal device. It connects various parts of the terminal device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 502, and by calling data stored in the memory 502, thereby providing overall monitoring of the terminal device. Optionally, the processor 501 may include one or more processing cores; preferably, the processor 501 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 501.

[0082] The memory 502 can be used to store software programs and modules. The processor 501 executes various functional applications and data processing by running the software programs and modules stored in the memory 502. The memory 502 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 502 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 502 may also include a memory controller to provide the processor 501 with access to the memory 502.

[0083] The terminal device also includes a power supply 503 that supplies power to the various components. Preferably, the power supply 503 can be logically connected to the processor 501 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 503 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0084] The terminal device may also include an input unit 504, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0085] Although not shown, the terminal device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 501 in the terminal device loads the executable files corresponding to the processes of one or more applications into the memory 502 according to the following instructions, and the processor 501 runs the applications stored in the memory 502 to realize various functions, as follows: Obtain users' historical behavior data; Analyze historical behavioral data to identify key user scenarios; Generate test data corresponding to key use cases; The test equipment is tested based on the test data to obtain the test results.

[0086] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0087] Therefore, embodiments of this application provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc. A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps in any of the device testing methods provided in embodiments of this application. For example, the computer program loaded by the processor can execute the following steps: Obtain users' historical behavior data; Analyze historical behavioral data to identify key user scenarios; Generate test data corresponding to key use cases; The test equipment is tested based on the test data to obtain the test results.

[0088] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0089] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.

[0090] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0091] The above provides a detailed description of a device testing method, apparatus, terminal device, and computer-readable storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A device testing method, characterized by, include: Obtain users' historical behavior data; The historical behavior data is analyzed to determine the user's key usage scenarios; Generate test data corresponding to the key use cases; The test equipment is tested based on the test data to obtain the test results of the test equipment.

2. The device testing method of claim 1, wherein, The analysis of the historical behavior data to determine the user's key usage scenarios includes: Based on the historical behavior data, the user's behavior is modeled to obtain a user behavior model; Determine the usage scenarios corresponding to the user behavior model; In the usage scenarios corresponding to the user behavior model, the key usage scenarios are determined.

3. The method of claim 2, wherein, The process of modeling the user's behavior based on the historical behavior data to obtain a user behavior model includes: The historical behavior data is input into the first intelligent model, and the first intelligent model outputs the user behavior chain extracted from the historical behavior data, as well as the frequency of occurrence of the user behavior chain. Based on the user behavior links that meet the first predetermined condition in terms of frequency of occurrence, the user's behavior is modeled to obtain the user behavior model.

4. The method of claim 2, wherein, The generation of test data corresponding to the key use cases includes: In the user behavior model, the model corresponding to the key use scenario is selected as the test behavior model; Determine the execution parameters corresponding to the test behavior model; Based on the execution parameters, a test script corresponding to the test behavior model is generated, and the test data is obtained.

5. The method of claim 4, wherein, Determining the execution parameters corresponding to the test behavior model includes: The historical behavior data is input into the second intelligent model, and the second intelligent model outputs the first data range of the behavior parameters in the test behavior model. Based on the first data range of the behavioral parameters in the test behavior model, the execution parameters corresponding to the test behavior model are determined.

6. The method of claim 1, wherein, The step of testing the test equipment based on the test data to obtain the test results of the test equipment includes: The test equipment is tested based on the test data, and the performance data of the test equipment during the test process is collected. The performance data is analyzed to obtain the test results of the test equipment.

7. The method of claim 6, wherein, The test results include one or more of the following: performance mean, performance standard deviation, and anomaly rate. The analysis of the performance data to obtain the test results of the test equipment includes: Statistical analysis was performed on the performance data to obtain the performance mean and performance standard deviation; If the performance data is not within the second data range, or the performance mean is not within the third data range, or the performance standard deviation is not within the fourth range, it is determined that the performance data is abnormal. The abnormality rate of the test equipment is obtained based on the proportion of abnormal performance data in the total performance data.

8. A device for testing equipment, characterized in that, include: The acquisition module is used to acquire users' historical behavior data; The determination module is used to analyze the historical behavior data to determine the user's key usage scenarios; A generation module is used to generate test data corresponding to the key use cases. The testing module is used to test the testing equipment based on the test data and obtain the test results of the testing equipment.

9. A terminal device, characterized in that, The terminal device includes: one or more processors, a memory, and one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the device testing method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps of the device testing method according to any one of claims 1 to 7.

Images