Game user interface test method, terminal and readable storage medium
By collecting multi-source data from game user interfaces and adjusting weights using long short-term memory networks and attention mechanisms, the problem of missed detections in existing game UI testing technologies has been solved, achieving more comprehensive and reliable testing results.
Patent Information
- Application Number
- CN202511478957.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-16
- Publication Date
- 2026-03-03
AI Technical Summary
Existing game user interface testing methods suffer from operation omissions in high-speed interactive scenarios, and rendering monitoring tools cannot correlate GPU shader compilation time with UI response latency, making it impossible to achieve comprehensive and reliable game UI testing.
Collect DOM-level data, user-level data, and system-level data of the game user interface, use a long short-term memory network to predict initial weights, and adjust the weights in combination with attention mechanisms and device type to calculate performance scores to obtain user interface test results.
By collecting data from multiple sources to avoid missed detections, using long short-term memory networks to achieve dynamic weight prediction, and combining attention mechanisms and device type to adjust weights, the comprehensiveness and reliability of game UI testing are improved, enabling precise quantification of game user interface performance.
Smart Images

Figure CN121597556A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of game testing technology, and in particular to a game user interface testing method, terminal, and readable storage medium. Background Technology
[0002] Current testing methods for game user interfaces (UIs) suffer from operational omissions in high-speed interactive scenarios, while rendering monitoring tools (such as VirtualUETool) cannot correlate GPU shader compilation time with UI response latency, thus failing to achieve comprehensive and reliable game UI testing. Summary of the Invention
[0003] The technical problem to be solved by the present invention is to provide a game user interface testing method, terminal and readable storage medium, which can improve the comprehensiveness and reliability of game UI testing.
[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for testing a game user interface, comprising the following steps: Collect DOM-level data, user-level data, and system-level data from the game's user interface; The initial weights of the DOM-level data, the user-level data, and the system-level data are predicted using a long short-term memory network, respectively. Obtain the device type running the game; The initial weights are adjusted based on the attention mechanism and the device type to obtain the final weights; The game's performance score is calculated based on the final weights, the DOM-level data, the user-level data, and the system-level data, and the user interface test results are obtained based on the performance score.
[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A game user interface testing terminal includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the various steps of the game user interface testing method described above.
[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A computer-readable storage medium storing a computer program that is executed by a processor to implement the steps of the above-described game user interface testing method.
[0007] The beneficial effects of this invention are as follows: Based on the collected DOM-level data, user-level data, and system-level data of the game's user interface, a Long Short-Term Memory (LSTM) network is used to predict the initial weights of the DOM-level data, user-level data, and system-level data, respectively. The device type running the game is obtained, and the initial weights are adjusted based on the attention mechanism and device type to obtain the final weights. The game's performance score is calculated based on the final weights, DOM-level data, user-level data, and system-level data, and the user interface test results are obtained based on the performance score. By collecting multi-source data, missed detections are avoided, and dynamic weight prediction is achieved using the LSM network. At the same time, the final weights of the multi-source data are obtained by adjusting the weights based on the attention mechanism and device type, making the results more comprehensive and accurate. Calculating the performance score based on the multi-source data and the final weights can accurately quantify the performance of the game's user interface, thereby improving the comprehensiveness and reliability of game UI testing. Attached Figure Description
[0008] Figure 1 This is a flowchart of a game user interface testing method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a game user interface testing terminal according to an embodiment of the present invention; Figure 3 This is a test flowchart of a game user interface testing method according to an embodiment of the present invention; Figure 4 This is a flowchart of weight prediction in a game user interface testing method according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the data alignment process in a game user interface testing method according to an embodiment of the present invention. Figure 6 This is a schematic diagram illustrating the performance scoring method in a game user interface testing method according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the cause-effect relationship between memory leaks and UI lag in a game user interface testing method according to an embodiment of the present invention. Detailed Implementation
[0009] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.
[0010] Definitions: DOM-level data refers to data related to the rendering performance of the game's user interface, including the actual rendering time of user interface elements, the number of drawing calls, vertex processing time, etc. These data reflect the rendering efficiency and resource consumption of UI elements.
[0011] Long Short-Term Memory (LSTM): A special type of recurrent neural network (RNN) designed to solve the gradient vanishing / exploding problem that traditional RNNs often encounter when processing long sequences of data, thereby effectively capturing long-term dependencies.
[0012] In existing technologies, functional verification tools have operational omission issues in high-speed interactive scenarios, and rendering monitoring tools cannot correlate GPU shader compilation time with UI response latency, thus failing to achieve comprehensive and reliable game UI testing.
[0013] Please refer to Figure 1 This invention provides a method for testing game user interfaces, including the following steps: Collect DOM-level data, user-level data, and system-level data from the game's user interface; The initial weights of the DOM-level data, the user-level data, and the system-level data are predicted using a long short-term memory network, respectively. Obtain the device type running the game; The initial weights are adjusted based on the attention mechanism and the device type to obtain the final weights; The game's performance score is calculated based on the final weights, the DOM-level data, the user-level data, and the system-level data, and the user interface test results are obtained based on the performance score.
[0014] As can be seen from the above description, the beneficial effects of the present invention are as follows: Based on the collected DOM-level data, user-level data, and system-level data of the game's user interface, a Long Short-Term Memory (LSTM) network is used to predict the initial weights of the DOM-level data, user-level data, and system-level data, respectively. The device type running the game is obtained, and the initial weights are adjusted based on the attention mechanism and device type to obtain the final weights. The game's performance score is calculated based on the final weights, DOM-level data, user-level data, and system-level data, and the user interface test results are obtained based on the performance score. This approach avoids missed detections by collecting multi-source data, utilizes the LTM network for dynamic weight prediction, and combines the attention mechanism and device type to adjust the weights to obtain the final weights of the multi-source data, resulting in a more comprehensive and accurate assessment. Calculating the performance score based on the multi-source data and the final weights allows for precise quantification of the game's user interface performance, thereby improving the comprehensiveness and reliability of game UI testing.
[0015] Furthermore, the initial weights for predicting the DOM-level data, the user-level data, and the system-level data using a Long Short-Term Memory network include: The DOM-level data, user-level data, and system-level data are respectively segmented by time windows to obtain segmented DOM-level data, segmented user-level data, and segmented system-level data; Clock synchronization compensation is performed on the segmented DOM-level data, the segmented user-level data, and the segmented system-level data respectively to obtain synchronized DOM-level data, synchronized user-level data, and synchronized system-level data; Generate the DOM-level feature matrix of the synchronized DOM-level data, the user-level feature matrix of the synchronized user-level data, and the system-level feature matrix of the synchronized system-level data; The DOM-level feature matrix, the user-level feature matrix, and the system-level feature matrix are respectively input into a long short-term memory network for weight prediction to obtain the initial weights of the DOM-level data, the user-level data, and the system-level data.
[0016] As described above, time window segmentation and clock synchronization compensation can better align multi-source data, eliminate drift, generate feature matrices for various types of data, and input them into LSTM prediction to obtain the initial weights for various types of data. LSTM can separately mine long-range dependencies on each time series, and the given initial weights are more in line with real-time bottlenecks, improving the sensitivity and accuracy of scoring and optimization.
[0017] Furthermore, the initial weights are adjusted based on the attention mechanism and the device type to obtain the final weights, including: Anomaly detection is performed on the DOM-level data, the user-level data, and the system-level data respectively to obtain anomaly scores; If the abnormal score exceeds the first preset value, the initial weight is adjusted based on the abnormal score using an attention mechanism to obtain the adjusted weight. Obtain the device weight corresponding to the device type, and use the device weight to perform a second adjustment on the adjusted weight to obtain the final weight; If the abnormal score does not exceed a first preset value, then the device weight corresponding to the device type is obtained, and the initial weight is adjusted using the device weight to obtain the final weight.
[0018] As described above, anomaly detection is performed on DOM-level data, user-level data, and system-level data to obtain anomaly scores. If the anomaly score exceeds a first preset value, the initial weights are adjusted based on the anomaly score using an attention mechanism to accurately amplify bottleneck sources. Then, device weights are used to adjust the adjusted weights a second time, taking into account hardware computing power, to obtain the final weights. If the anomaly score does not exceed the first preset value, the initial weights are adjusted using device weights to directly adapt to the device, thereby achieving adaptive and accurate game UI testing.
[0019] Furthermore, the DOM-level data includes the actual rendering time of user interface elements; The user-level data includes input event response latency; The system-level data includes the current frame rate and the historical lowest frame rate; The game's performance score is calculated based on the final weights, the DOM-level data, the user-level data, and the system-level data, including: Obtain the baseline rendering time; DOM-level deviation is calculated based on the actual rendering time of the user interface elements and the baseline rendering time. Calculate the user-level deviation based on the input event response delay; Obtain the device's nominal frame rate; Calculate the system-level deviation based on the current frame rate, the historical lowest frame rate, and the device's nominal frame rate; The game's performance score is calculated based on the DOM-level deviation, the user-level deviation, the system-level deviation, and the final weight.
[0020] As described above, by calculating DOM-level deviation, user-level deviation, and system-level deviation, and combining the final weights of rendering time, input event response, and frame rate, the game's performance score is more comprehensive and reliable.
[0021] Furthermore, the DOM-level deviation is calculated based on the actual rendering time of the user interface element and the baseline rendering time, specifically as follows: ; In the formula, Indicates DOM-level deviation. Indicates the actual rendering time of user interface elements. Indicates the baseline rendering time; The user-level deviation is calculated based on the input event response delay, specifically as follows: ; In the formula, Indicates user-level deviation. This indicates a delay in the response to input events; The system-level deviation is calculated based on the current frame rate, the historical lowest frame rate, and the device's nominal frame rate, specifically as follows: ; In the formula, Indicates system-level deviation. Indicates the current frame rate. Indicates the lowest historical frame rate. This indicates the device's nominal frame rate.
[0022] As described above, DOM-level deviation quantifies the rendering inflation relative to the baseline as a percentage, intuitively reflecting the rendering efficiency. User-level deviation only penalizes excessive latency with a 100 ms boundary, directly corresponding to perceptible stuttering. System-level deviation normalizes "current-minimum / nominal-minimum" to 0-1, linking it to the device's upper limit, providing a unified and comparable quantitative basis for subsequent weighted scoring.
[0023] Furthermore, the game's performance score is calculated based on the DOM-level deviation, the user-level deviation, the system-level deviation, and the final weight, specifically as follows: ; In the formula, Score represents the game's performance rating. w i Indicates the first i The final weights of the data types include the final weights of DOM-level data, user-level data, and system-level data. Indicates the first i Deviation of class data includes DOM-level deviation, user-level deviation, and system-level deviation.
[0024] As described above, the greater the deviation, the lower the performance score. By calculating the performance score, the test results of the game UI can be obtained directly and accurately.
[0025] Furthermore, the user interface test results of the game obtained based on the performance score include: If the performance score is greater than or equal to the second preset value, then the user interface test result of the game is determined to be a pass. If the performance score is less than the second preset value, the user interface test result of the game is determined to be unsuccessful, and the maximum weight is selected from the final weights of the DOM-level data, the user-level data, and the system-level data. The user interface of the game is optimized based on the maximum weight.
[0026] As described above, if the performance score is less than the second preset value, the game's user interface test result is determined to be unsuccessful. The maximum weight is selected from the final weights of DOM-level data, user-level data, and system-level data. The game's user interface is then optimized based on the maximum weight. By utilizing the weights, performance bottlenecks can be accurately located, and the game's user interface can be optimized in a targeted manner to improve optimization efficiency.
[0027] Further, the device weight corresponding to the device type is obtained, and the adjusted weight is adjusted a second time using the device weight to obtain the final weight, which includes: If the device type is a personal computer, then obtain the first device weight corresponding to the personal computer, and multiply the first device weight by the adjusted weight to obtain the final weight; If the device type is a mobile device, then the second device weight corresponding to the mobile device is obtained, and the second device weight is multiplied by the adjusted weight to obtain the final weight.
[0028] As described above, device types include personal computers or mobile devices. Multiplying the device weight by the adjusted weight to obtain the final weight can effectively adapt to the device type and ensure the accuracy of UI test results.
[0029] Please refer to Figure 2 Another embodiment of the present invention provides a game user interface testing terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the game user interface testing method described above.
[0030] Another embodiment of the present invention provides a computer-readable storage medium storing a computer program that is executed by a processor to implement the various steps of the game user interface testing method described above.
[0031] The game user interface testing method, terminal, and readable storage medium described above in this invention are applicable to game UI testing scenarios. The specific implementation methods are described below: Please refer to Figure 1 One embodiment of the present invention is as follows: A method for testing a game user interface, comprising the following steps: S1. Collect DOM-level data, user-level data, and system-level data of the game's user interface.
[0032] The DOM-level data includes the actual rendering time of user interface elements, the number of draw calls, vertex processing time, and particle effect update frequency; the user-level data includes input event response latency, operation command interval time, and touch trajectory coordinate sequence; the system-level data includes the current frame rate, historical minimum frame rate, GPU shader execution time, CPU thread scheduling latency, video memory bandwidth utilization, device surface temperature, and network latency fluctuation, with a frame rate of 1000ms. The total time per frame is calculated based on GPU shader execution time, UI rendering time, vertical synchronization wait time, and other time-consuming factors.
[0033] Specifically, such as Figure 3 As shown, the Unity engine is used to intercept the CommandBuffer rendering instruction stream and insert timestamps during the UI element drawing phase; the Unreal Engine (virtual engine) is used to capture the start and end times of the UI event handling chain using the Slate framework's SWidget callback interface, thereby determining the actual rendering time of user interface elements, the number of drawing calls, vertex processing time, and particle effect update frequency. GPU shader execution time and memory bandwidth utilization are obtained through ADB (Android) / Metal API (iOS); CPU thread scheduling latency is obtained by monitoring the scheduling latency and priority inversion events of the UI thread; the device surface temperature is collected in real time through the Thermal API; and the impact of network fluctuations on input latency in cloud gaming scenarios is detected to obtain network latency fluctuations. The system collects input event response delay, operation command interval time, and touch trajectory coordinate sequence through touch event injection and high-speed camera motion capture.
[0034] In one optional implementation, the DOM-level data, the user-level data, and the system-level data are stored in a circular buffer to prevent data loss in high-concurrency scenarios.
[0035] In one alternative implementation, an improved NTP (Network Time Protocol) is used to achieve cross-device clock synchronization, preferably with a synchronization accuracy controlled within ±1ms.
[0036] S2. Use a Long Short-Term Memory (LSTM) network to predict the initial weights of the DOM-level data, the user-level data, and the system-level data, respectively, specifically including S21-S24: S21. Perform time window segmentation on the DOM-level data, the user-level data, and the system-level data respectively to obtain segmented DOM-level data, segmented user-level data, and segmented system-level data, such as... Figure 3 As shown.
[0037] S22. Perform clock synchronization compensation on the segmented DOM-level data, the segmented user-level data, and the segmented system-level data respectively to obtain synchronized DOM-level data, synchronized user-level data, and synchronized system-level data.
[0038] Specifically, such as Figure 3 As shown, a timestamp processor is used to perform clock synchronization compensation on the segmented DOM-level data, the segmented user-level data, and the segmented system-level data respectively, resulting in synchronized DOM-level data, synchronized user-level data, and synchronized system-level data, as follows. Figure 5 As shown, specifically: 1. Clock skew compensation: Calculate the clock skew for each data source: t = |T_GPU - T_input|; Use the equipment calibration formula: ,in γ The value is dynamically determined based on the device type (e.g., 0.8 for mobile devices and 1.2 for personal computers). 2. Interpolation compensation: When DOM-level data is missing, time-weighted interpolation is used: def interpolate(prev, next): return (prev 0.3) + (next 0.7) / / Guarantee timing continuity The interpolated frame is marked as is_interpolated=True for subsequent modules to identify; 3. Outlier removal: Calculate the range of 3σ standard deviation based on a sliding window; Filter out abnormal data with rendering time > 50ms or operation delay > 100ms; Output: Generates a time-aligned DataChunk structure containing the following fields: struct DataChunk { uint64_t timestamp; / / Calibrated timestamp (ns) float dom_metrics[5]; / / DOM-level metric array float user_latency; / / User-level latency (ms) system_info_t sys_data; / / System-level data structure bool is_interpolated; / / Whether to generate interpolations }
[0039] S23. Generate the DOM-level feature matrix of the synchronized DOM-level data, the user-level feature matrix of the synchronized user-level data, and the system-level feature matrix of the synchronized system-level data.
[0040] Specifically, Principal Component Analysis (PCA) is used to generate the DOM-level feature matrix of the synchronized DOM-level data, Fourier Transform (FFT) is used to generate the user-level feature matrix of the synchronized user-level data, and Exponential Weighted Moving Average (EWMA) is used to generate the system-level feature matrix of the synchronized system-level data.
[0041] The feature dimensions of the DOM-level feature matrix include rendering depth, transparency, and update frequency; the feature dimensions of the user-level feature matrix include operation interval and touch trajectory entropy; and the feature dimensions of the system-level feature matrix include CPU utilization and memory leak rate.
[0042] S24. Input the DOM-level feature matrix, the user-level feature matrix, and the system-level feature matrix into a Long Short-Term Memory network respectively to perform weight prediction, thereby obtaining the initial weights of the DOM-level data, the user-level data, and the system-level data, as follows: Figure 4 As shown.
[0043] Among them, such as Figure 4 As shown, the Long Short-Term Memory Network includes an input layer, a 128-unit hidden layer, an attention mechanism layer, and an output layer.
[0044] By dynamically adjusting the weight ratio of the three-level indicators through the Long Short-Term Memory Network, such as increasing the initial weight of system-level data when the GPU overheats, the performance bottleneck of the next frame can also be predicted through the initial weight, such as warning of rendering delay when the entropy increase of the feature matrix is greater than 0.3.
[0045] S3. Obtain the device type running the game.
[0046] S4. Adjust the initial weights based on the attention mechanism and the device type to obtain the final weights, specifically including S41-S44: S41. Perform anomaly detection on the DOM-level data, the user-level data, and the system-level data respectively to obtain anomaly scores.
[0047] Specifically, a sliding window (window size 1 second) is used to calculate the mean and standard deviation of each data point; if a data point exceeds 3 times the standard deviation or exceeds a predefined threshold (e.g., rendering time > 50ms), it is marked as an anomaly; the proportion of anomalies in each data source within the window is counted as an anomaly score.
[0048] S42. If the abnormal score exceeds the first preset value, the initial weight is adjusted once based on the abnormal score according to the attention mechanism to obtain the adjusted weight.
[0049] Specifically, if the abnormal score exceeds the first preset value, the abnormal score is input into the softmax function to obtain the attention weight; the attention weight is multiplied by the initial weight to obtain the adjusted weight.
[0050] The attention mechanism employs a 4-head parallel attention structure with an attention dimension of 64.
[0051] S43. Obtain the device weight corresponding to the device type, and use the device weight to perform a second adjustment on the adjusted weight to obtain the final weight, specifically including S431-S432: S431. If the device type is a personal computer (PC), then obtain the first device weight corresponding to the personal computer, and multiply the first device weight by the adjusted weight to obtain the final weight.
[0052] S432. If the device type is a mobile device, then obtain the second device weight corresponding to the mobile device, and multiply the second device weight by the adjusted weight to obtain the final weight.
[0053] For example, if the device type is PC, then the first device weight corresponding to PC is [0.4, 0.3, 0.3], which corresponds to the first device weights of DOM-level data, user-level data, and system-level data, respectively. If the device type is MOBILE, then the second device weight corresponding to MOBILE is [0.3, 0.5, 0.2], which corresponds to the second device weights of DOM-level data, user-level data, and system-level data, respectively.
[0054] S44. If the abnormal score does not exceed the first preset value, then obtain the device weight corresponding to the device type, and use the device weight to adjust the initial weight to obtain the final weight.
[0055] S5. Calculate the game's performance score based on the final weights, the DOM-level data, the user-level data, and the system-level data, and obtain the game's user interface test results based on the performance score, such as... Figure 3 As shown, specifically including S51-S59: S51, Obtain the baseline rendering time.
[0056] S52. Calculate the DOM-level deviation based on the actual rendering time of the user interface element and the baseline rendering time, specifically as follows: ; In the formula, Indicates DOM-level deviation. Indicates the actual rendering time of user interface elements. Indicates the baseline rendering time.
[0057] In one alternative implementation, the method further includes marking UI components whose actual rendering time is greater than 16ms or whose vertex processing time is greater than 5ms as out-of-range elements.
[0058] S53. Calculate the user-level deviation based on the input event response delay, specifically as follows: ; In the formula, Indicates user-level deviation. This indicates a delay in responding to input events.
[0059] In one optional implementation, the method further includes: determining whether the rate of change of the interval between five consecutive operations is greater than 15% based on the interval between operation instructions; if so, triggering a warning.
[0060] S54. Obtain the device's nominal frame rate.
[0061] S55. Calculate the system-level deviation based on the current frame rate, the historical lowest frame rate, and the device's nominal frame rate, specifically as follows: ; In the formula, Indicates system-level deviation. Indicates the current frame rate. Indicates the lowest historical frame rate. This indicates the device's nominal frame rate.
[0062] In one optional implementation, the method further includes: determining whether the GPU temperature is 75°C, and if so, outputting an overheat warning.
[0063] S56. Calculate the game's performance score based on the DOM-level deviation, the user-level deviation, the system-level deviation, and the final weight, specifically as follows: ; In the formula, Score represents the game's performance rating. w i Indicates the first iThe final weights of the data types include the final weights of DOM-level data, user-level data, and system-level data. Indicates the first i Deviation of class data includes DOM-level deviation, user-level deviation, and system-level deviation.
[0064] S57. If the performance score is greater than or equal to the second preset value, then the user interface test result of the game is determined to be a pass. Figure 6 As shown.
[0065] In one alternative implementation, such as Figure 6 As shown, the second preset value is 85.
[0066] S58. If the performance score is less than the second preset value, the user interface test result of the game is determined to be unsuccessful, and the maximum weight is selected from the final weights of the DOM-level data, the user-level data, and the system-level data.
[0067] S59. Optimize the game's user interface based on the maximum weight, such as... Figure 3 and Figure 6 As shown.
[0068] Specifically, if the maximum weight is the final weight of the DOM-level data, then the drawing batches are merged or the resolution is reduced; if the maximum weight is the final weight of the user-level data, then the event handling is optimized; if the maximum weight is the final weight of the system-level data, then the pressure coefficient is adjusted.
[0069] In an alternative implementation, it may also include: using regression analysis to locate DOM-level and user-level latency correlations, and using causal graph analysis to identify system-level bottlenecks.
[0070] Specifically, regression analysis was used to locate the correlation between DOM-level and user-level latency. Establish the regression equation for rendering time (DOM level) and operation latency (user level): t_response = 0.7t_render + 0.2t_event + ε; In the above formula, t_response (operation delay): the total time from user operation (such as clicking) to the UI producing visible feedback, which belongs to user-level data (such as input event response delay). t_render (rendering time): The time it takes for a UI element to be rendered from the start to the end. It is DOM-level data (such as the actual rendering time of user interface elements). t_event (event processing time): The time required for the game engine to process input events (such as click events), which is part of user-level data (such as derived from the interval between operation commands). Coefficients 0.7 and 0.2: obtained through linear regression analysis of historical data, representing the contribution of t_render and t_event to t_response; ε: Error term, representing other unmodeled factors (such as system load).
[0071] Optimization rules: If the rendering factor is greater than 0.6 and t_render is greater than 16ms, then optimize the rendering. If the event coefficient is greater than 0.25 and t_event is greater than 5ms, then simplify the event chain.
[0072] The conditions for optimizing rendering are as follows: when the t_render coefficient is greater than 0.6 (strong impact) and the actual rendering time exceeds the limit, the rendering batches are merged or the resolution is reduced; the conditions for simplifying the event chain are as follows: when the t_event coefficient is greater than 0.25 (significant impact) and the event processing time is greater than 5ms, the event processing level is compressed or the pre-computation logic is adjusted.
[0073] Using causal graph analysis to identify system-level bottlenecks, specifically: Generate a causal graph of memory leaks (system-level) and UI lag, such as... Figure 7 As shown, the causal graph is processed according to priority: when a memory leak is detected (memory usage is greater than 80% and continues to increase), memory optimization is triggered; when GPU overheating is identified (temperature is greater than 70℃ and utilization is greater than 90%), the load intensity is automatically reduced; when network latency occurs (fluctuation is greater than 30ms), streaming compensation is enabled.
[0074] In one optional implementation, the game's user interface is optimized using a PID (Proportional-Integral-Derivative) controller. After optimization, the above process can be re-executed for testing iterations until the test passes. Figure 3 As shown.
[0075] The method described above can be applied to ACT (action) game combo testing scenarios to detect latency fluctuations during continuous operations. The threshold setting conforms to the persistence of vision characteristics of the human eye. It can also be applied to MMO (massively multiplayer online) simultaneous rendering testing scenarios to simulate multiple simultaneous screen scenarios, meeting the requirements of online game industry standards. It can also be used for mobile adaptation testing scenarios to predict the frame rate decay trend of low-end GPUs. The measured error is at an industry-leading level.
[0076] The game user interface testing method described above uses a Long Short-Term Memory (LSTM) network to predict the initial weights of the collected DOM-level, user-level, and system-level data of the game's user interface, respectively. It then obtains the device type running the game, adjusts the initial weights based on an attention mechanism and the device type, and calculates the final weights. Finally, it calculates the game's performance score based on the final weights, DOM-level, user-level, and system-level data, and obtains the user interface test results based on the performance score. This method avoids missed detections by collecting multi-source data and utilizes a LTM network for dynamic weight prediction. Simultaneously, by combining attention mechanisms and device type to adjust weights, the final weights of multi-source data are obtained, making the results more comprehensive and accurate. Performance scores are calculated based on multi-source data and the final weights, which can accurately quantify the performance of the game's user interface, thereby improving the comprehensiveness and reliability of game UI testing. In addition, if the performance score is less than the second preset value, the game's user interface test result is determined to be unsuccessful. The maximum weight is selected from the final weights of DOM-level data, user-level data, and system-level data, and the game's user interface is optimized based on the maximum weight. By using weights, performance bottlenecks can be accurately located, and the game's user interface can be optimized in a targeted manner, improving optimization efficiency.
[0077] According to another aspect of the invention, Figure 2 This is a schematic diagram illustrating a game user interface testing terminal according to an embodiment of the present invention. The terminal includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the game user interface testing method described above.
[0078] According to another aspect of the present invention, a computer-readable medium is provided. The computer-readable medium stores a computer program that is executed by a processor to implement the game user interface testing method described above.
[0079] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A method for testing a game user interface, characterized in that, Including the following steps: Collect DOM-level data, user-level data, and system-level data from the game's user interface; The initial weights of the DOM-level data, the user-level data, and the system-level data are predicted using a long short-term memory network, respectively. Obtain the device type running the game; The initial weights are adjusted based on the attention mechanism and the device type to obtain the final weights; The game's performance score is calculated based on the final weights, the DOM-level data, the user-level data, and the system-level data, and the user interface test results are obtained based on the performance score.
2. The game user interface testing method according to claim 1, characterized in that, The initial weights for predicting the DOM-level data, user-level data, and system-level data using a Long Short-Term Memory network include: The DOM-level data, user-level data, and system-level data are respectively segmented by time windows to obtain segmented DOM-level data, segmented user-level data, and segmented system-level data; Clock synchronization compensation is performed on the segmented DOM-level data, the segmented user-level data, and the segmented system-level data respectively to obtain synchronized DOM-level data, synchronized user-level data, and synchronized system-level data; Generate the DOM-level feature matrix of the synchronized DOM-level data, the user-level feature matrix of the synchronized user-level data, and the system-level feature matrix of the synchronized system-level data; The DOM-level feature matrix, the user-level feature matrix, and the system-level feature matrix are respectively input into a long short-term memory network for weight prediction to obtain the initial weights of the DOM-level data, the user-level data, and the system-level data.
3. The game user interface testing method according to claim 1, characterized in that, The initial weights are adjusted based on the attention mechanism and the device type to obtain the final weights, which include: Anomaly detection is performed on the DOM-level data, the user-level data, and the system-level data respectively to obtain anomaly scores; If the abnormal score exceeds the first preset value, the initial weight is adjusted based on the abnormal score using an attention mechanism to obtain the adjusted weight. Obtain the device weight corresponding to the device type, and use the device weight to perform a second adjustment on the adjusted weight to obtain the final weight; If the abnormal score does not exceed a first preset value, then the device weight corresponding to the device type is obtained, and the initial weight is adjusted using the device weight to obtain the final weight.
4. The game user interface testing method according to claim 1, characterized in that, The DOM-level data includes the actual rendering time of user interface elements; The user-level data includes input event response latency; The system-level data includes the current frame rate and the historical lowest frame rate; The game's performance score is calculated based on the final weights, the DOM-level data, the user-level data, and the system-level data, including: Obtain the baseline rendering time; DOM-level deviation is calculated based on the actual rendering time of the user interface elements and the baseline rendering time. Calculate the user-level deviation based on the input event response delay; Obtain the device's nominal frame rate; Calculate the system-level deviation based on the current frame rate, the historical lowest frame rate, and the device's nominal frame rate; The game's performance score is calculated based on the DOM-level deviation, the user-level deviation, the system-level deviation, and the final weight.
5. A game user interface testing method according to claim 4, characterized in that, The DOM-level deviation is calculated based on the actual rendering time of the user interface element and the baseline rendering time, specifically as follows: ; In the formula, Indicates DOM-level deviation. Indicates the actual rendering time of user interface elements. Indicates the baseline rendering time; The user-level deviation is calculated based on the input event response delay, specifically as follows: ; In the formula, Indicates user-level deviation. This indicates a delay in the response to input events; The system-level deviation is calculated based on the current frame rate, the historical lowest frame rate, and the device's nominal frame rate, specifically as follows: ; In the formula, Indicates system-level deviation. Indicates the current frame rate. This indicates the lowest historical frame rate. This indicates the device's nominal frame rate.
6. A game user interface testing method according to claim 4, characterized in that, The game's performance score is calculated based on the DOM-level deviation, the user-level deviation, the system-level deviation, and the final weight, specifically as follows: ; In the formula, Score represents the game's performance rating. w i Indicates the first i The final weights of the data types include the final weights of DOM-level data, user-level data, and system-level data. Indicates the first i Deviation of class data includes DOM-level deviation, user-level deviation, and system-level deviation.
7. A game user interface testing method according to claim 1, characterized in that, The user interface test results of the game obtained based on the performance score include: If the performance score is greater than or equal to the second preset value, then the user interface test result of the game is determined to be a pass. If the performance score is less than the second preset value, the user interface test result of the game is determined to be unsuccessful, and the maximum weight is selected from the final weights of the DOM-level data, the user-level data, and the system-level data. The user interface of the game is optimized based on the maximum weight.
8. A game user interface testing method according to claim 3, characterized in that, Obtain the device weight corresponding to the device type, and use the device weight to perform a secondary adjustment on the adjusted weight to obtain the final weight, including: If the device type is a personal computer, then obtain the first device weight corresponding to the personal computer, and multiply the first device weight by the adjusted weight to obtain the final weight; If the device type is a mobile device, then the second device weight corresponding to the mobile device is obtained, and the second device weight is multiplied by the adjusted weight to obtain the final weight.
9. A game user interface testing terminal, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements each step of the game user interface testing method according to any one of claims 1 to 8.
10. A computer-readable storage medium storing a computer program that is executed by a processor to implement the steps of a game user interface testing method according to any one of claims 1 to 8.