A terminal test model generation method, device and storage medium

Abstract

The application provides a terminal test model generation method, comprising: presetting a monitoring point of a terminal; acquiring data of the preset monitoring point and outputting monitoring data summary of the terminal; and forming a test model of the terminal according to the monitoring data summary. In addition, the application also provides a terminal and a storage medium. The technical problem of low processing efficiency and high cost of manual repeated simulation, analysis and pressure test in the prior art is solved, an automatic full-coverage and intelligent terminal test model is generated, the efficiency of terminal testing is improved, the problem that various operation scenes of the terminal are difficult to simulate and the test dimension is difficult to grasp is solved, and the use experience of users and the stability and usability of products are improved.

Description

Technical Field

[0001] This invention relates to the field of terminal testing, and in particular to a method, device and storage medium for generating terminal test models. Background Technology

[0002] With the continuous development of network communication technology, the application of terminal devices is becoming increasingly widespread. Therefore, functional testing of these devices is becoming increasingly important. In existing technologies, the increasing number of terminal functions and the growing complexity of interaction scenarios mean that testing cannot fully cover all user scenarios, leading to a degraded user experience. Furthermore, during terminal troubleshooting, operators often need to manually perform repeated simulations, analyses, and stress tests, significantly increasing processing time and reducing overall testing efficiency. Therefore, there is an urgent need for a method that can intelligently generate terminal test models to reduce frequent manual interactions, improve test scenario coverage, and thereby enhance terminal stability and user experience.

[0003] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this invention is to provide a method for generating terminal test models, which aims to solve the technical problems of current terminal testing methods that involve frequent manual interaction and cannot fully cover test scenarios.

[0005] To achieve the above objectives, the present invention provides a method for generating a terminal test model, comprising:

[0006] Pre-set monitoring points at the terminal;

[0007] Acquire data from the preset monitoring points and output a summary of the terminal's monitoring data;

[0008] The test model of the terminal is formed by summarizing the monitoring data.

[0009] Preferably, after the step of summarizing the monitoring data to form the test model of the terminal, the method further includes:

[0010] Check whether the terminal test model covers all test scenarios;

[0011] If so, the terminal test model shall be used as the final test model;

[0012] If not, then add the terminal preset monitoring point.

[0013] Preferably, after the step of summarizing the monitoring data to form the test model of the terminal, the method further includes:

[0014] Detect whether the terminal test model covers all the preset monitoring points;

[0015] If so, the terminal test model shall be used as the final test model;

[0016] If not, then the terminal test model will be reformulated.

[0017] Preferably, the step of setting a preset monitoring point on the terminal includes:

[0018] Multiple monitoring points are preset on the terminal;

[0019] The multiple monitoring points are categorized according to their functional characteristics;

[0020] Output the corresponding monitoring data according to the classification identifier of the monitoring points.

[0021] Preferably, the step of monitoring the data from the preset monitoring points and outputting the summary monitoring data from the terminal includes:

[0022] Monitor the monitoring data output according to the classification identifier;

[0023] The monitoring data is then categorized and summarized into corresponding monitoring data.

[0024] Preferably, the step of acquiring data from the preset monitoring points and outputting the summary monitoring data from the terminal further includes:

[0025] When abnormal data is detected, the abnormal data will be marked.

[0026] Abnormal data from monitoring points under different classification labels are aggregated according to their respective classification labels.

[0027] Preferably, the step of analyzing and summarizing the monitoring data to form the terminal test model includes:

[0028] From the aggregated monitoring data, scenarios with operation frequencies higher than a preset threshold are extracted. It is then checked whether the test model covers the scenarios. If not, the scenarios are added to the test cases.

[0029] From the aggregated monitoring data, third-party applications with operation frequencies higher than a preset threshold are identified. The test model is then checked to see if the application is covered. If not, the application is added to the test cases.

[0030] From the aggregated monitoring data, the operation scenarios under abnormal information are extracted, and it is checked whether the test model covers the scenarios. If not, the scenarios are added to the test cases.

[0031] Preferably, the method further includes:

[0032] The data categorized by label are aggregated and cross-analyzed to generate cross-test cases;

[0033] Store the cross-test cases into the test case model;

[0034] The terminal test model is updated according to a preset cycle.

[0035] In addition, to achieve the above objectives, the present invention also provides a terminal device, the terminal device comprising: a memory, a processor, and a terminal test model generation program stored in the memory and executable on the processor, wherein when the terminal test model generation program is executed by the processor, it implements the steps of the terminal test model generation method as described in any of the above claims.

[0036] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a terminal test model generation program, which, when executed by a processor, implements the terminal test model generation program as described in any of the preceding claims.

[0037] This invention provides a method for generating a terminal test model, comprising: setting preset monitoring points on the terminal; acquiring data from the preset monitoring points and outputting a summary of the terminal's monitoring data; and forming a test model for the terminal based on the summary of the monitoring data. This method solves the technical problems of low efficiency and high cost in existing technologies where terminal testing requires repeated manual simulations, analyses, and stress tests. It achieves automated generation of a fully covered and intelligent terminal test model, improving the efficiency of terminal testing, and resolving the difficulties in simulating various user operation scenarios and maintaining consistent testing dimensions. This enhances the user experience and improves the stability and usability of the product. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the terminal / device structure of the hardware operating environment involved in the embodiments of the present invention;

[0039] Figure 2 This is a flowchart illustrating an embodiment of the terminal test model generation method of the present invention;

[0040] Figure 3 This is a flowchart illustrating the second embodiment of the terminal test model generation method of the present invention;

[0041] Figure 4 This is a flowchart illustrating the third embodiment of the terminal test model generation method of the present invention;

[0042] Figure 5 This is a flowchart illustrating the fourth embodiment of the terminal test model generation method of the present invention;

[0043] Figure 6 for Figure 2 A detailed flowchart of step S20 is shown below;

[0044] Figure 7 for Figure 2 A detailed flowchart of step S30 is shown below;

[0045] Figure 8 This is a flowchart illustrating the fifth embodiment of the terminal test model generation method of the present invention.

[0046] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0047] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0048] The main solution of this invention is: to preset monitoring points on the terminal; to acquire data from the preset monitoring points and output a summary of the terminal's monitoring data; and to form a test model for the terminal based on the summary of the monitoring data.

[0049] As existing technologies enable terminals to have more and more functions, more and more usage scenarios, and more and more complex interaction scenarios, it is impossible to fully cover all user usage scenarios during the terminal testing process, resulting in a decrease in user experience. Furthermore, when problems occur on the terminal, manual repeated simulation, analysis, and stress testing are required, which greatly prolongs the problem-solving time.

[0050] This invention provides a solution that requires pre-installing monitoring points on the terminal, analyzing and summarizing the data from these points, and then aggregating the data output from all monitoring points to generate corresponding test cases, ultimately forming a test case model for the terminal. This achieves full coverage of all common terminal usage scenarios while significantly reducing testing time through the automatically generated terminal test model, resulting in substantial savings in manpower and resources.

[0051] like Figure 1 As shown, Figure 1 This is a schematic diagram of the terminal structure of the hardware operating environment involved in the embodiments of the present invention.

[0052] The terminal in this invention embodiment can be a PC, or a smartphone, tablet computer, e-book reader, MP3 (Moving Picture Experts Group Audio Layer III) player, MP4 (Moving Picture Experts Group Audio Layer IV) player, portable computer, or other portable terminal devices with display functions.

[0053] like Figure 1 As shown, the terminal may include: a processor 1001, such as a CPU; a network interface 1004; a user interface 1003; a memory 1005; and a communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and an input unit such as a keyboard. Optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0054] Optionally, the terminal may also include a camera, RF (Radio Frequency) circuitry, sensors, audio circuitry, a WiFi module, and so on. Sensors may include light sensors, motion sensors, and other sensors. Specifically, light sensors may include ambient light sensors and proximity sensors. The ambient light sensor can adjust the display brightness according to the ambient light level, while the proximity sensor can turn off the display and / or backlight when the mobile terminal is moved to the ear. As a type of motion sensor, a gravity accelerometer can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity, and can be used for applications that identify the mobile terminal's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition functions (such as pedometers, taps), etc. Of course, the mobile terminal may also be equipped with other sensors such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, which will not be elaborated here.

[0055] Those skilled in the art will understand that Figure 1 The terminal structure shown does not constitute a limitation on the terminal and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0056] like Figure 1 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a terminal test model generation program.

[0057] exist Figure 1 In the terminal shown, network interface 1004 is mainly used to connect to the backend server and communicate with it; user interface 1003 is mainly used to connect to the client (user terminal) and communicate with it; while processor 1001 can be used to call the terminal test model generation program stored in memory 1005 and perform the following operations:

[0058] Multiple monitoring points are preset on the terminal;

[0059] The multiple monitoring points are categorized according to their functional characteristics;

[0060] Output the corresponding monitoring data according to the classification identifier of the monitoring points.

[0061] Furthermore, the processor 1001 can call the network operation control application stored in the memory 1005 and also perform the following operations:

[0062] Check whether the terminal test model covers all test scenarios;

[0063] If so, the terminal test model shall be used as the final test model;

[0064] If not, then add the terminal preset monitoring point.

[0065] Furthermore, the processor 1001 can call the network operation control application stored in the memory 1005 and also perform the following operations:

[0066] Detect whether the terminal test model covers all the preset monitoring points;

[0067] If so, the terminal test model shall be used as the final test model;

[0068] If not, then the terminal test model will be reformulated.

[0069] Furthermore, the processor 1001 can call the network operation control application stored in the memory 1005 and also perform the following operations:

[0070] Multiple monitoring points are preset on the terminal;

[0071] The multiple monitoring points are categorized according to their functional characteristics;

[0072] Output the corresponding monitoring data according to the classification identifier of the monitoring points.

[0073] Furthermore, the processor 1001 can call the network operation control application stored in the memory 1005 and also perform the following operations:

[0074] Monitor the monitoring data output according to the classification identifier;

[0075] The monitoring data is then categorized and summarized into corresponding monitoring data.

[0076] Furthermore, the processor 1001 can call the network operation control application stored in the memory 1005 and also perform the following operations:

[0077] When abnormal data is detected, the abnormal data will be marked.

[0078] Abnormal data from monitoring points under different classification labels are aggregated according to their respective classification labels.

[0079] Furthermore, the processor 1001 can call the network operation control application stored in the memory 1005 and also perform the following operations:

[0080] From the aggregated monitoring data, scenarios with operation frequencies higher than a preset threshold are extracted. It is then checked whether the test model covers the scenarios. If not, the scenarios are added to the test cases.

[0081] From the aggregated monitoring data, third-party applications with operation frequencies higher than a preset threshold are identified. The test model is then checked to see if the application is covered. If not, the application is added to the test cases.

[0082] From the aggregated monitoring data, the operation scenarios under abnormal information are extracted, and it is checked whether the test model covers the scenarios. If not, the scenarios are added to the test cases.

[0083] Furthermore, the processor 1001 can call the network operation control application stored in the memory 1005 and also perform the following operations:

[0084] The data categorized by label are aggregated and cross-analyzed to generate cross-test cases;

[0085] Store the cross-test cases into the test case model;

[0086] The terminal test model is updated according to a preset cycle.

[0087] Reference Figure 2 The first embodiment of the terminal test model generation method of the present invention provides a terminal test model generation method, the method comprising:

[0088] Step S10: Set up a monitoring point on the terminal;

[0089] Specifically, in this embodiment, monitoring points are pre-installed on the terminal under test. That is, during the initial design of the terminal, monitoring points are pre-installed based on the existing terminal system. When the terminal is running, all pre-installed monitoring points automatically output their data. Furthermore, monitoring points are pre-installed for different scenarios of the terminal, such as basic usage scenarios, interactive usage scenarios, performance usage scenarios, and abnormal usage scenarios, depending on the actual situation.

[0090] Step S20: Obtain the data from the preset monitoring points and output the summary monitoring data from the terminal;

[0091] Specifically, in this embodiment, the terminal system analyzes and summarizes the monitoring data output by the pre-embedded monitoring points. Specifically, the terminal system receives the monitoring data output by all monitoring points of the terminal, analyzes the data output under different scenarios, and statistically analyzes all the data under that scenario to finally form a data summary for that scenario.

[0092] Step S30: Based on the monitoring data, a test model for the terminal is formed. Specifically, in this embodiment, the terminal system summarizes the data output from all preset monitoring points within the terminal and generates corresponding test cases according to different application scenarios. That is, test cases corresponding to the basic scenario are generated based on the data output from monitoring points under the basic usage scenario; test cases for the interactive scenario are generated based on the data output from monitoring points under the interactive scenario; and test cases corresponding to the performance scenario are generated based on the data output from terminal monitoring points under the performance scenario. When abnormal information appears in the data output from the monitoring points, the abnormal data is analyzed and summarized, and the abnormal data is used as marker data. The abnormal information sets a threshold for basic data monitoring abnormal information for a single model and a threshold for basic data monitoring abnormal information for the entire system. Within a unit of time, the thresholds can be divided into emergency, high, medium, and low thresholds (e.g., how many abnormal information is generated by a single model in a day, a month, or a quarter; how many abnormal information is generated by the entire system in a day, a month, or a quarter; how many abnormal information is generated by a single abnormal information in a day, a month, or a quarter, etc.).

[0093] In this embodiment, monitoring points are pre-embedded within the terminal during the initial design phase. Data output from these monitoring points is then analyzed and summarized to generate test cases for different scenarios. All test cases are then aggregated to create a test model for the terminal. This solves the high-cost and low-efficiency problems associated with traditional testing methods that require extensive manual testing and simulation.

[0094] Furthermore, refer to Figure 3Based on the above embodiments, a second embodiment of the terminal test model generation method of the present invention is proposed. In this embodiment, reference is made to... Figure 3 The step S30 is followed by:

[0095] Step S401: Detect whether the terminal test model covers all test scenarios;

[0096] Step S4011: If yes, use the terminal test model as the final test model;

[0097] Step S4012: If not, add the terminal preset monitoring point.

[0098] Specifically, in this embodiment, the terminal system analyzes and summarizes the data output from pre-embedded monitoring points on the terminal to form a test model for the terminal. The final terminal test model includes test cases formed from the data output from all monitoring points on the terminal. In this embodiment, the test model formed by the terminal is tested, including whether all application scenarios are covered and whether the terminal test model can meet the test data of all scenarios of the terminal. If it fully covers all application scenarios, the terminal test model is stored as the final terminal test model on the terminal server. If it cannot fully cover all application scenarios of the terminal, monitoring points need to be added in the uncovered application scenarios. The terminal system then executes the terminal test model generation method of steps S10 to S30 above on the data of the added monitoring points to regenerate the terminal test model. In this way, the terminal test model provided by the present invention includes test cases for all application scenarios of the terminal.

[0099] In this embodiment, the terminal system detects whether the terminal model generated by monitoring covers all application scenarios of the terminal. If not, new monitoring points need to be added to the terminal. This ensures that the terminal test model generated by this invention includes all test scenarios of the terminal, and also guarantees the efficiency of terminal testing.

[0100] Furthermore, referring to Figure 4 Based on the above embodiments, a third embodiment of the terminal test model generation method of the present invention is proposed. In this embodiment, reference is made to... Figure 4 The step S30 is followed by:

[0101] Step S402: Detect whether the terminal test model covers all the preset monitoring points;

[0102] Step S4021: Use the terminal test model as the final test model;

[0103] Step S4022: If not, then re-form the terminal test model.

[0104] Specifically, in this embodiment, the terminal system obtains the final terminal test model according to steps S10 to S30 in Embodiment 1 above. The final terminal test model should include all data output from all pre-embedded monitoring points of the terminal. Specifically, in this embodiment, it is detected whether the final terminal test model covers all the preset monitoring points of the terminal. If it is detected that the terminal test model has covered all the preset monitoring points of the terminal, then the terminal test model is used as the final terminal test model; if it is detected that the terminal test model does not fully cover all the preset monitoring points of the terminal, then steps S10 to S30 in Embodiment 1 above are repeated to regenerate a terminal test model containing all the monitoring points of the terminal.

[0105] In this embodiment, the generated terminal test model is checked to see if it contains data from all the pre-installed monitoring points of the terminal. If it does not, the terminal test model generation method provided by this invention is repeated until the generated terminal test model contains data from all the preset test points of the terminal. This ensures the reliability and practicality of the generated terminal test model.

[0106] Furthermore, referring to Figure 5 Based on the above embodiments, a fourth embodiment of the terminal test model generation method of the present invention is proposed. In this embodiment, reference is made to... Figure 5 The step S10 is followed by:

[0107] Step S101: Pre-set multiple monitoring points on the terminal;

[0108] Step S102: Classify the multiple monitoring points according to their functional characteristics;

[0109] Step S103: Output the corresponding monitoring data according to the classification identifier of the monitoring point.

[0110] Specifically, in this embodiment, multiple data monitoring points are pre-embedded in the terminal system. All preset monitoring points are classified and labeled. The data can be categorized into basic data, interactive data, performance data, and abnormal information based on the different monitored data. The basic data monitoring points include: terminal model, core, MAC address, terminal ID information; WIFI / Bluetooth module information, voice module information, power on / off status (e.g., power-on command is infrared power-on, voice power-on, CEC (Consumer Electronics Control) power-on, true standby status, AI standby status, etc.), and other information related to user's regular operation. The basic data referred to in this invention includes, but is not limited to, the above-mentioned classification labels.

[0111] Interactive data monitoring points include: application startup process recording (e.g., entering HDMI, opening the movie center, opening local media, opening third-party applications), interaction process recording (e.g., opening menus, switching image and sound modes, switching resolution, etc.), voice interaction recording, click operations on various interfaces, etc. (not limited to the above categories);

[0112] Performance data monitoring points include: available memory, system application usage, current application running memory, application startup time, etc. (not limited to the above categories);

[0113] Anomaly information tracking points include: power on / off anomalies, playback anomalies, data and communication anomalies, application opening anomalies, switching anomalies, stopping operation, no response, operation lag, etc. (not limited to the above categories). The terminal outputs corresponding data summaries according to the category labels, and analyzes and summarizes them into test cases for that category scenario.

[0114] Furthermore, referring to Figure 6 Step S20 further includes:

[0115] Step S201: Monitor the monitoring data output according to the classification identifier;

[0116] Step S202: The monitoring data is summarized according to the classification identifier.

[0117] Step S203: When abnormal data is detected, the abnormal data is marked;

[0118] Step S204: Summarize the abnormal data that appear at monitoring points with different classification labels according to different classification labels.

[0119] Specifically, in this embodiment, the terminal system receives and aggregates data output from all monitoring points based on the classification identifiers of the monitoring points. It then generates different test cases according to the classification and application scenarios, and finally aggregates these test cases to form the terminal's final test model. Specifically, basic data serves as foundational data for statistical analysis of relevant models, mechanisms, and user's routine operation data. Interactive data analysis is the primary data analysis for the terminal. It involves directly accessing relevant channels, launching application classification statistics, and classifying and statistically analyzing data such as operation steps, motor frequency, and playback duration within the channel or application interface, and correlates these data with the basic data. Performance data serves as auxiliary data, playing a supporting role in the analysis of interactive data. It involves analyzing and statistically analyzing interactive data, as well as its numerical curve changes and frequency within a unit of time, and correlates it with the basic data and interactive data.

[0120] Furthermore, in this embodiment, when the terminal detects abnormal information, the threshold for basic data monitoring abnormal information of a single model and the threshold for basic data monitoring abnormal information of the rectification terminal system can be set according to the abnormal information. Moreover, within a fixed period, the thresholds can be divided into emergency, high, medium and low thresholds. For example, how many abnormal information is generated by a single model in a day, a month or a quarter, how many abnormal information is generated in the entire system in a day, a month or a quarter, how many abnormal information is generated by a single abnormal information in a day, a month or a quarter, etc.

[0121] In this embodiment, the monitoring points embedded in the terminal are labeled with classification tags, and the monitoring data is output according to the classification tags. When abnormal data is detected, the abnormal data is marked, and the abnormal data appearing at monitoring points with different classification tags are summarized according to different classification tags. This solves the problem that it is difficult to simulate various user operation scenarios and difficult to grasp the testing dimensions, thereby improving the user experience and the stability and usability of the product.

[0122] Furthermore, refer to Figure 7 Based on the above embodiments, a fifth embodiment of the terminal test model generation method of the present invention is proposed. In this embodiment, reference is made to... Figure 7 The step S30 is followed by:

[0123] Step S301: Extract scenarios with operation frequency higher than a preset threshold from the monitoring data summary, check whether the test model covers the scenarios, and if not, add the scenarios to the test cases.

[0124] Specifically, in this embodiment, the terminal system extracts the most frequently manipulated scenarios from the aggregated monitoring data, such as powering on / off and switching resolution in a television system. It then checks whether the aggregated data covers application scenarios exceeding a preset threshold. If not, the uncovered application scenarios are added to the regular test cases, ensuring basic, routine user operations are protected.

[0125] Step S302: Extract third-party applications with operation frequencies higher than a preset threshold from the monitoring data summary, check whether the test model covers the application, and if not, add the application to the test case.

[0126] Specifically, in this embodiment, when the terminal system receives a summary of data from all preset monitoring points, it extracts the most frequently used third-party applications from the analyzed data summary, such as common video and music playback software. The terminal then checks whether the monitoring data summary obtained in Embodiment 1 contains test data for operation scenarios of these frequently used third-party applications. If it does not cover these scenarios, the missing third-party application operation scenarios are added to the test cases. This ensures both basic routine operations for users and the normal use of third-party applications.

[0127] Step S303: Extract the operation scenarios under abnormal information from the monitoring data summary, check whether the test model covers the scenarios, and if not, add the scenarios to the test cases.

[0128] Specifically, in this embodiment, the abnormal information data in the monitoring data is used to extract the operation scenarios under the emergency and high-risk states of abnormal data reports, and to check whether the test cases cover the relevant scenarios. If not, they are added to the regular test cases or interactive scenario test cases. The abnormal information data in the monitoring data is used to extract the operation scenarios under the medium and low-risk states of abnormal data reports, and to check whether the test cases cover the relevant scenarios. If not, they are added to the interactive scenario test cases or stress test cases.

[0129] In this embodiment, by checking whether the terminal's regular functional scenarios, the most frequently used third-party application scenarios, and abnormal scenarios are included in the generated terminal test model, and adding the corresponding test cases to the terminal test cases when they are not present, the technical problems of difficulty in simulating terminal test scenarios and difficulty in mastering test dimensions are solved, and the comprehensiveness and practicality of the terminal test model provided by this invention are improved.

[0130] Furthermore, based on the above embodiments, referring to Figure 8 The terminal test model generation method of the present invention further includes:

[0131] Step S40: The data classified by category is aggregated and cross-analyzed to generate cross-test cases;

[0132] Step S50: Store the cross-test cases into the test case model;

[0133] Step S60: Update the terminal test model according to a preset cycle.

[0134] Specifically, in this embodiment, the terminal test model generation method provided by the present invention further includes, after the terminal system outputs corresponding data summaries according to different classification identifiers, cross-analyzing the test cases under different classification identifiers according to actual usage needs. For example, in which interactive control scenarios do the most abnormal information occur, in which interactive scenarios do the least performance data occur, and in which interactive scenarios do the most basic control abnormal information occur? These cross-analyzed test cases are also stored in the terminal's test case model. Furthermore, to ensure the timeliness of the terminal test model generation method provided by the present invention, when the terminal has new functions or new requirements, new monitoring points are added to the terminal. When the frequency of abnormal data exceeds a preset threshold, new preset monitoring points are also added. When new abnormalities occur during monitoring and cannot be detected, new monitoring points are added after analysis and problem-solving. Even without abnormalities or new functions, monitoring points must be added, replaced, or deleted according to a preset cycle (week, month, quarter, or year) to ensure that the terminal test cases generated by the present invention closely follow market and user needs.

[0135] In this embodiment, by summarizing and cross-analyzing data under different classification labels, test cases for the terminal in interactive scenarios are generated, solving the technical problem that it is difficult to simulate various user operation scenarios. Furthermore, by automatically updating the test model on a periodic basis, the timeliness of the terminal test model is increased.

[0136] Furthermore, the present invention also provides a terminal device, the terminal device comprising: a memory, a processor, and a terminal test model generation program stored in the memory and executable on the processor, wherein when the terminal test model generation program is executed by the processor, it implements the steps of the terminal test model generation method described in any of the above embodiments.

[0137] Furthermore, embodiments of the present invention also propose a computer-readable storage medium storing a terminal test model generation program, which, when executed, performs the following operations:

[0138] Pre-set monitoring points at the terminal;

[0139] Acquire data from the preset monitoring points and output a summary of the terminal's monitoring data;

[0140] The test model of the terminal is formed by summarizing the monitoring data.

[0141] Furthermore, after the step of summarizing the monitoring data to form the test model of the terminal, the method further includes:

[0142] Check whether the terminal test model covers all test scenarios;

[0143] If so, the terminal test model shall be used as the final test model;

[0144] If not, then add the terminal preset monitoring point.

[0145] Furthermore, after the step of summarizing the monitoring data to form the test model of the terminal, the method further includes:

[0146] Detect whether the terminal test model covers all the preset monitoring points;

[0147] If so, the terminal test model shall be used as the final test model;

[0148] If not, then the terminal test model will be reformulated.

[0149] Furthermore, the step of setting up a preset monitoring point on the terminal includes:

[0150] Multiple monitoring points are preset on the terminal;

[0151] The multiple monitoring points are categorized according to their functional characteristics;

[0152] Output the corresponding monitoring data according to the classification identifier of the monitoring points.

[0153] Furthermore, the step of monitoring the data from the preset monitoring points and outputting the summary monitoring data from the terminal includes:

[0154] Monitor the monitoring data output according to the classification identifier;

[0155] The monitoring data is then categorized and summarized into corresponding monitoring data.

[0156] Furthermore, the step of acquiring data from the preset monitoring points and outputting the summary monitoring data from the terminal also includes:

[0157] When abnormal data is detected, the abnormal data will be marked.

[0158] Abnormal data from monitoring points of different classification labels are summarized according to their respective classification labels.

[0159] Furthermore, the step of analyzing and summarizing the monitoring data to form the terminal test model includes:

[0160] From the aggregated monitoring data, scenarios with operation frequencies higher than a preset threshold are extracted. It is then checked whether the test model covers the scenarios. If not, the scenarios are added to the test cases.

[0161] From the aggregated monitoring data, third-party applications with operation frequencies higher than a preset threshold are identified. The test model is then checked to see if the application is covered. If not, the application is added to the test cases.

[0162] From the aggregated monitoring data, the operation scenarios under abnormal information are extracted, and it is checked whether the test model covers the scenarios. If not, the scenarios are added to the test cases.

[0163] Furthermore, the method also includes:

[0164] The data categorized by label are aggregated and cross-analyzed to generate cross-test cases;

[0165] Store the cross-test cases into the test case model;

[0166] The terminal test model is updated according to a preset cycle.

[0167] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0168] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0169] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0170] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for generating a terminal test model, characterized in that, include: Multiple monitoring points are preset on the terminal for different application scenarios; wherein, the application scenarios include basic usage scenarios, interactive usage scenarios, performance usage scenarios, and abnormal usage scenarios; The multiple monitoring points are categorized according to their functional characteristics, forming basic data monitoring points, interactive data monitoring points, performance data monitoring points, and abnormal information monitoring points. The basic data monitoring points include terminal model, core, MAC address, terminal ID information, WIFI / Bluetooth module information, voice module information, and power on / off status. The interactive data monitoring points include application startup process records, interaction process records, voice interaction records, and click operations on various interfaces. The performance data monitoring points include currently available memory, system application usage, current application running memory, and application startup time. The abnormal information monitoring points include power on / off anomalies, playback anomalies, data and communication anomalies, application opening anomalies, switching anomalies, stopping operation, no response, and operation lag. Output the corresponding monitoring data according to the classification identifier of the monitoring point, and summarize the monitoring data according to the classification identifier. Based on the aggregated monitoring data, different test cases are generated according to the classification identifiers and different application scenarios. The different test cases are aggregated to form the test model of the terminal.

2. The terminal test model generation method as described in claim 1, characterized in that, The step of summarizing the different test cases to form the test model of the terminal further includes: Check whether the terminal test model covers all test scenarios; If so, the terminal test model shall be used as the final test model; If not, then add the terminal preset monitoring point.

3. The terminal test model generation method as described in claim 1, characterized in that, The step of summarizing the different test cases to form the test model of the terminal further includes: Check whether the terminal test model covers all preset monitoring points; If so, the terminal test model shall be used as the final test model; If not, then the terminal test model will be reformulated.

4. The terminal test model generation method as described in claim 1, characterized in that, The step of outputting corresponding monitoring data according to the classification identifier of the monitoring point and forming a corresponding monitoring data summary according to the classification identifier further includes: When abnormal data is detected, the abnormal data will be marked. Abnormal data from monitoring points under different classification labels are aggregated according to their respective classification labels.

5. The terminal test model generation method as described in claim 1, characterized in that, The step of generating different test cases based on the aggregated monitoring data, according to the classification identifier and the different application scenarios, and aggregating the different test cases to form the test model of the terminal includes: From the aggregated monitoring data, scenarios with operation frequencies higher than a preset threshold are extracted. It is then checked whether the test model covers the scenarios with operation frequencies higher than the preset threshold. If not, the scenarios with operation frequencies higher than the preset threshold are added to the test cases. From the aggregated monitoring data, third-party applications with operation frequencies higher than a preset threshold are identified. The test model is then checked to see if the application is covered. If not, the application is added to the test cases. From the aggregated monitoring data, the operation scenarios under abnormal information are extracted. It is then checked whether the test model covers the operation scenarios under abnormal information. If not, the operation scenarios under abnormal information are added to the test cases.

6. The terminal test model generation method according to any one of claims 1-5, characterized in that, The method further includes: The data categorized by label are aggregated and cross-analyzed to generate cross-test cases; Store the cross-test cases into the test case model; The terminal test model is updated according to a preset cycle.

7. A terminal device, characterized in that, The terminal device includes: a memory, a processor, and a terminal test model generation program stored in the memory and executable on the processor. When the terminal test model generation program is executed by the processor, it implements the steps of the terminal test model generation method as described in any one of claims 1 to 6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a terminal test model generation program, which, when executed by a processor, implements the terminal test model generation program as described in any one of claims 1 to 6.

Images