Performance test method, device, chip and mobile terminal of application program

Abstract

This application relates to a performance testing method, apparatus, chip, and mobile terminal for an application. The method includes: in a scenario where a target application is being performed on for performance testing, obtaining an initial trace file containing display information throughout the entire testing process of the target application; converting the initial trace file into a target trace file; wherein the target trace file and the initial trace file have different file formats; segmenting the target trace file to obtain multiple consecutive trace sub-files corresponding to the target trace file; and obtaining the performance test results of the target application based on the multiple consecutive trace sub-files. This method can improve the testing efficiency of the target application.

Description

Technical Field

[0001] This application relates to the technical field of software testing, and in particular to a method, apparatus, chip, and mobile terminal for testing the performance of an application. Background Technology

[0002] With the rapid development of mobile internet technology, mobile devices have become an important tool in people's daily lives and work. Various applications are installed on mobile devices. As users' demands for application responsiveness increase, especially in gaming scenarios, their expectations for the gaming experience are rising. Application performance directly affects user experience and user retention rates; therefore, it is necessary to test application performance.

[0003] However, traditional application testing methods suffer from low efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for testing the performance of an application, in response to the above-mentioned technical problems.

[0005] In a first aspect, this application provides a method for testing the performance of an application, the method comprising:

[0006] In a scenario where performance testing is performed on a target application, the initial trace file containing the displayed information throughout the entire testing process of the target application is obtained.

[0007] Convert the initial trace file to a target trace file; the target trace file has a different file format than the initial trace file.

[0008] The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0009] The performance test results of the target application are obtained based on multiple consecutive trace subfiles.

[0010] In one embodiment, performance test results of the target application are obtained based on multiple consecutive trace subfiles, including:

[0011] Repair each tracking subfile and obtain the repaired tracking subfile corresponding to each tracking subfile;

[0012] Based on each repair tracking subfile, obtain the performance test results of the target application.

[0013] In one embodiment, each tracking sub-file is repaired to obtain the repaired tracking sub-file corresponding to each tracking sub-file, including:

[0014] The first repair method is used to repair the first tracking sub-file to obtain the first repaired tracking sub-file; the first tracking sub-file is the first tracking sub-file obtained among all tracking sub-files; the first repair method is to repair the tail line data in the first tracking sub-file.

[0015] The second repair method is used to repair the second tracking sub-file to obtain the second repaired tracking sub-file; the second tracking sub-file is the other tracking sub-files besides the first tracking sub-file; the second repair method is to repair the first line and the last line of data in the second tracking sub-file.

[0016] In one embodiment, a first repair method is used to repair the first tracking sub-file, resulting in a first repaired tracking sub-file comprising:

[0017] The first repair method is used to delete the tail line data of the first tracking sub-file to obtain the first repaired tracking sub-file.

[0018] In one embodiment, a second repair method is used to repair the second tracking sub-file to obtain a second repaired tracking sub-file, including:

[0019] The first and last lines of data in the second tracking sub-file are deleted to obtain the optimized second tracking sub-file.

[0020] The header information of the first tracking sub-file is added to the header position of the optimized second tracking sub-file to obtain the second repaired tracking sub-file.

[0021] In one embodiment, the target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file, including:

[0022] The target tracking file is segmented according to a preset segmentation step size to obtain multiple consecutive tracking sub-files corresponding to the target tracking file; or,

[0023] The target tracking file is segmented according to a preset number of lines to obtain multiple consecutive tracking sub-files corresponding to the target tracking file.

[0024] In one embodiment, the method further includes:

[0025] If the performance test results do not meet the preset conditions, the abnormal tracking subfile is determined from multiple consecutive tracking subfiles based on the performance test results;

[0026] Based on the timestamp information in the exception tracking subfile and the preset time alignment mechanism, the abnormal running time period of the target application is determined; the preset time alignment mechanism is the mapping relationship between the timestamps of the tracking subfile and the internal logical time of the target application.

[0027] Based on the abnormal operation period, determine the abnormal operation information of the target application.

[0028] Secondly, this application also provides an application performance testing device, the device comprising:

[0029] The trace file acquisition module is used to acquire the initial trace file of the target application's display information throughout the entire testing process in the scenario of performing performance testing on the target application;

[0030] The trace file conversion module is used to convert the initial trace file into a target trace file; the target trace file and the initial trace file have different file formats.

[0031] The tracking file segmentation module is used to segment the target tracking file to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0032] The test result determination module is used to obtain the performance test results of the target application based on multiple consecutive trace subfiles.

[0033] Thirdly, this application also provides a computer chip, including a processor and a communication interface, wherein the processor is configured to cause the chip to perform:

[0034] In a scenario where performance testing is performed on a target application, the initial trace file containing the displayed information throughout the entire testing process of the target application is obtained.

[0035] Convert the initial trace file to a target trace file; the target trace file has a different file format than the initial trace file.

[0036] The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0037] The performance test results of the target application are obtained based on multiple consecutive trace subfiles.

[0038] Fourthly, this application also provides a mobile terminal, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0039] In a scenario where performance testing is performed on a target application, the initial trace file containing the displayed information throughout the entire testing process of the target application is obtained.

[0040] Convert the initial trace file to a target trace file; the target trace file has a different file format than the initial trace file.

[0041] The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0042] The performance test results of the target application are obtained based on multiple consecutive trace subfiles.

[0043] Fifthly, this application also provides a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0044] In a scenario where performance testing is performed on a target application, the initial trace file containing the displayed information throughout the entire testing process of the target application is obtained.

[0045] Convert the initial trace file to a target trace file; the target trace file has a different file format than the initial trace file.

[0046] The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0047] The performance test results of the target application are obtained based on multiple consecutive trace subfiles.

[0048] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0049] In a scenario where performance testing is performed on a target application, the initial trace file containing the displayed information throughout the entire testing process of the target application is obtained.

[0050] Convert the initial trace file to a target trace file; the target trace file has a different file format than the initial trace file.

[0051] The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0052] The performance test results of the target application are obtained based on multiple consecutive trace subfiles.

[0053] Seventhly, this application also provides a computer program product comprising a computer program that, when executed by a processor, performs the following steps:

[0054] In a scenario where performance testing is performed on a target application, the initial trace file containing the displayed information throughout the entire testing process of the target application is obtained.

[0055] Convert the initial trace file to a target trace file; the target trace file has a different file format than the initial trace file.

[0056] The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0057] The performance test results of the target application are obtained based on multiple consecutive trace subfiles.

[0058] The aforementioned performance testing methods, devices, chips, and mobile terminals, when performing performance testing on a target application, first obtain an initial trace file containing the display information throughout the entire testing process of the target application. This ensures the completeness and comprehensiveness of the data in the initial trace file obtained through a single, complete test. Next, the initial trace file is converted into a target trace file. The target trace file has a different file format than the initial trace file, which facilitates subsequent segmentation of the target trace file. This segmentation yields multiple consecutive trace sub-files corresponding to the target trace file, allowing existing performance analysis tools to directly analyze each smaller trace sub-file, thereby improving performance analysis efficiency. Finally, based on these multiple consecutive trace sub-files, the performance test results of the target application are obtained. This helps developers optimize the target application promptly based on the performance test results, ensuring a good user experience. Attached Figure Description

[0059] Figure 1 Flowcharts of application performance testing methods provided in some embodiments of this application;

[0060] Figure 2 A flowchart illustrating the process of obtaining performance test results provided in some embodiments of this application;

[0061] Figure 3 A flowchart for repairing tracking subfiles is provided for some embodiments of this application;

[0062] Figure 4 A flowchart for obtaining a second repair tracking subfile is provided for some embodiments of this application;

[0063] Figure 5 A flowchart for determining abnormal operation information of a target application, provided for some embodiments of this application;

[0064] Figure 6 Structural block diagram of an application performance testing apparatus provided in some embodiments of this application;

[0065] Figure 7 This is an internal structural diagram of a computer device provided in some embodiments of this application. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0067] With the rapid development of mobile internet technology, mobile devices have become essential tools for people's daily lives and work. Various applications are installed on mobile devices. As users' demands for application responsiveness increase, especially in gaming scenarios where user expectations for gaming experience are rising, application performance directly impacts user experience and user retention. Therefore, application performance testing is necessary. However, traditional application testing methods suffer from relatively low efficiency.

[0068] To address the aforementioned technical problems, this application provides a method for performance testing of an application. This method can be applied to mobile terminals, including smartphones, tablets, etc., and the application can be a game. When performance testing of a target application is required, an initial trace file containing the display information throughout the entire testing process of the target application can be obtained to ensure the completeness and comprehensiveness of the data in the initial trace file obtained through a single, complete test. The initial trace file is then converted into a target trace file, which has a different file format than the initial trace file, to facilitate subsequent segmentation. The target trace file is then segmented to obtain multiple consecutive trace sub-files, allowing existing performance analysis tools to directly analyze each smaller trace sub-file, thereby improving performance analysis efficiency. Finally, based on the multiple consecutive trace sub-files, the performance test results of the target application are obtained, enabling developers to optimize the target application based on the performance test results.

[0069] In one embodiment, such as Figure 1 As shown, this method is illustrated using an example of its application to a mobile terminal. In this embodiment, the method includes the following steps:

[0070] Step 102: In the scenario of performing performance testing on the target application, obtain the initial trace file of the display information of the target application throughout the entire testing process.

[0071] The target application is one that requires long-term performance and stability testing. For example, the target application can be an Android application, such as a game or video application. Performance testing can be a quantitative evaluation of the target application's graphics rendering performance and system responsiveness, specifically including performance metrics such as frame rate, number of dropped frames, and maximum consecutive frame drops.

[0072] The initial trace file can be a collection of test data captured by existing performance analysis tools during a complete test process, i.e., a complete test cycle. The initial trace file can include CPU scheduling information (such as which CPU each thread runs on and its duration), GPU activity information (such as GPU rendering instructions and shader execution time), system service information (such as the activities of SurfaceFlinger (the display compositing system) responsible for compositing and display, and BufferQueue (the buffer queue) responsible for producer-consumer buffer activities), application process activity information (such as function calls of the application's main thread, rendering thread, and IO (Input / Output) thread), and kernel event information (such as interrupts and memory allocations).

[0073] Optionally, existing performance analysis tools can be used to start recording at the beginning of the test and stop recording at the end. The recording items configured by the system can include events such as system scheduling, graphics, and application activity. In this way, existing performance analysis tools can be used to capture complete performance event data for the entire long test cycle at once. Compared with traditional multiple start and stop recording, this implementation obtains the initial trace file of the display information of the target application during the entire test process at once, which can ensure the integrity of the initial trace file and the reliability of the performance test results obtained based on the initial trace file.

[0074] Step 104: Convert the initial tracking file into the target tracking file.

[0075] The target tracking file has a different file format than the initial tracking file.

[0076] Understandably, the initial trace file is usually in binary format. Since splitting a binary file destroys its internal structure, it becomes unparseable by existing performance analysis tools. In other words, binary files are not suitable for direct segmentation and text analysis. Therefore, it is necessary to convert the initial binary trace file into a text-based target trace file. The target trace file is typically in Systrace text format, meaning it's a readable text file with a .html or .txt extension. This allows the initial trace file to be easily segmented while also facilitating the inspection and repair of any formatting incompleteness caused by the segmentation.

[0077] Alternatively, existing performance analysis tools can be used to convert the initial trace file in binary format into a target trace file in text format, thereby converting binary data that cannot be directly segmented into a text format that is easier to segment later.

[0078] Step 106: Segment the target tracking file to obtain multiple consecutive tracking sub-files corresponding to the target tracking file.

[0079] Understandably, the initial trace file obtained after a complete testing cycle is quite large. For example, after a game program has undergone a test lasting half an hour, the initial trace file may be 3 to 5 GB in size. If existing performance testing tools are used to analyze it directly, there may be system lag issues, resulting in low efficiency in performance testing of the target application. Therefore, in this embodiment, the target trace file will be segmented first, so that the individual trace sub-files obtained from the segments are smaller, for example, the size range of each trace sub-file is 100 to 300 MB. This makes it easier for performance testing tools to directly open and analyze these smaller trace sub-files, thereby helping to improve the efficiency of performance testing of the target application.

[0080] Among them, the trace subfile is a series of smaller and continuous trace files that are cut from the target trace file of the complete test cycle according to the time sequence and size limit.

[0081] Optionally, the target tracking file can be segmented based on a preset segmentation mechanism to obtain multiple consecutive tracking sub-files.

[0082] Step 108: Obtain the performance test results of the target application based on multiple consecutive trace sub-files.

[0083] The performance test results can be a structured performance analysis report, which may include performance metrics and problem locations. Performance metrics may include frame rate, number of dropped frames, and maximum number of consecutive dropped frames. Problem locations can be determined based on trace files showing anomalies in the performance metrics. Since each trace file corresponds to a period of time within the entire testing cycle of the target application, the corresponding test time period can also be determined based on the anomaly trace files.

[0084] Alternatively, existing performance analysis tools can be used to automatically parse each trace subfile, collect and summarize various performance metrics, and obtain the performance test results of the target application.

[0085] The performance testing method described above, when testing a target application, first obtains the initial trace file containing the displayed information throughout the entire testing process. This ensures the completeness and comprehensiveness of the data in the initial trace file obtained through a single, complete test. Next, the initial trace file is converted into a target trace file. Since the target trace file has a different file format than the initial trace file, this facilitates subsequent segmentation. The target trace file is then segmented to obtain multiple consecutive trace sub-files, allowing existing performance analysis tools to directly analyze each smaller trace sub-file, thereby improving performance analysis efficiency. Finally, based on these multiple consecutive trace sub-files, the performance test results of the target application are obtained. This helps developers optimize the target application promptly based on the performance test results, ensuring a good user experience.

[0086] Understandably, when segmenting a target trace file, the text-formatted trace file contains nested event block structures, such as start and end markers for a function or a process activity interval. This can lead to incomplete information in the trace sub-files due to segmentation. Therefore, after obtaining multiple consecutive trace sub-files through segmentation, each sub-file can be repaired to ensure the accuracy and reliability of the final performance test results. In one embodiment, such as... Figure 2 As shown, performance test results for a target application are obtained based on multiple consecutive trace subfiles, which may specifically include the following steps:

[0087] Step 202: Repair each tracking sub-file and obtain the repaired tracking sub-file corresponding to each tracking sub-file.

[0088] Optionally, existing repair tools can be used to repair each tracking subfile according to a preset repair strategy, resulting in a repaired tracking subfile. For example, the preset repair strategy could be to repair incomplete first and last lines of data in the tracking subfile to obtain the corresponding repaired tracking subfile. This repair tool can understand the syntax and structure of text-formatted tracking subfiles and can parse the text into an event tree, marking incomplete nodes, thus enabling the identification and repair of incomplete data.

[0089] Step 204: Based on each repair tracking sub-file, obtain the performance test results of the target application.

[0090] Optionally, existing performance analysis tools can be used to calculate performance metrics for each repair tracing sub-file, obtaining the calculation results. Based on the calculation results and the preset thresholds corresponding to each performance metric, the performance test results of the target application can be determined. Performance metric indicators may include frame rate, number of dropped frames, maximum number of consecutive dropped frames, etc. Furthermore, based on these performance test results, a visualized performance analysis report can be generated to help developers locate problems in abnormal repair tracing sub-files and optimize the target application. For example, the performance test results of all repair tracing sub-files can be concatenated in chronological order to generate a complete performance analysis report.

[0091] In this embodiment, each trace sub-file is repaired first, which ensures the data integrity of each repaired trace sub-file, thereby improving the reliability of the subsequent performance test results of the target application based on each trace sub-file. Furthermore, by analyzing each smaller repaired trace sub-file, compared to the traditional method of directly analyzing a large initial trace file, the efficiency of obtaining the performance test results of the target application can be improved.

[0092] Considering that the tracking subfiles are arranged in chronological order, the repair positions required for the first tracking subfile within a complete test cycle are different from those required for other tracking subfiles during segmentation. Therefore, the repair processing for the first tracking subfile within a complete test cycle will also differ from the repair processing for other tracking subfiles. In one embodiment, such as... Figure 3 As shown, repairing each tracing sub-file and obtaining the repaired tracing sub-file corresponding to each tracing sub-file can specifically include the following steps:

[0093] Step 302: Use the first repair method to repair the first tracking sub-file to obtain the first repaired tracking sub-file.

[0094] The first tracking subfile is the earliest obtained tracking subfile among all tracking subfiles. The first repair method is to repair the tail line data in the first tracking subfile.

[0095] Understandably, the first trace subfile corresponds to the beginning of the initial trace file, and its first line is the start of the initial trace file, typically a valid header. This header can include metadata such as file version information and process lists; that is, the first line structure is complete. Therefore, during splitting, there is no need to repair the first line of the first trace subfile. However, since the last line of the first trace subfile is the first part of the file to be truncated at a split point, this split point may fall in the middle of an event—for example, a function execution halfway through, or a rendering frame event not yet finished. This results in the last line of the first trace subfile being a fragment of an event, thus requiring repair of the incomplete last line.

[0096] Optionally, when repairing the first tracking sub-file, only the last line of the first tracking sub-file can be repaired. This can improve the repair efficiency of the first tracking sub-file.

[0097] Step 304: Use the second repair method to repair the second tracking sub-file to obtain the second repaired tracking sub-file.

[0098] The second tracking sub-file consists of the remaining tracking sub-files besides the first tracking sub-file. The second repair method involves repairing the first and last lines of data in the second tracking sub-file.

[0099] Understandably, the beginning of each second tracking subfile immediately follows the breakpoint of the previous tracking subfile. When the previous subfile is cut off in the middle of an event, the first line of the current second tracking subfile represents the latter half of that event; that is, the first line of the second tracking subfile may be incomplete. The end of the second tracking subfile is also a breakpoint; therefore, like the end of the first tracking subfile, the last line of the second tracking subfile may also be cut off in the middle of an event.

[0100] Optionally, when repairing the second tracking sub-file, both the first and last lines of data in the second tracking sub-file can be repaired.

[0101] In this embodiment, repairing the last line data of the first tracking sub-file ensures that the first data block, i.e., the first tracking sub-file, can end in a syntactically complete and logically closed state, thus facilitating direct analysis using existing performance analysis tools after loading. Repairing the first and last lines of the second tracking sub-file transforms each intermediate data block, i.e., the second tracking sub-file, into a valid file that is complete at both ends and can be parsed independently, thereby ensuring efficiency when batch processing the second tracking sub-file using existing performance analysis tools.

[0102] In one embodiment, the first repair method is used to repair the first tracking sub-file to obtain the first repaired tracking sub-file, which includes: using the first repair method to delete the tail line data of the first tracking sub-file to obtain the first repaired tracking sub-file.

[0103] Understandably, based on the above analysis, the tail line data of the first tracking sub-file may be incomplete during segmentation. As shown in the figure, guessing and completing this incomplete tail line data through complex logic may introduce errors. Therefore, when repairing the first tracking sub-file, the tail line data of the first tracking sub-file can be directly deleted, which will help improve the efficiency of subsequent performance analysis.

[0104] In one embodiment, such as Figure 4 As shown, the second repair method is used to repair the second tracking sub-file, resulting in a second repaired tracking sub-file, which includes:

[0105] Step 402: Delete the first and last lines of data in the second tracking sub-file to obtain the optimized second tracking sub-file.

[0106] Optionally, the first and last lines of data in the second tracking sub-file can be directly deleted to obtain an optimized second tracking sub-file. This removes data spikes caused by the splitting process, thus ensuring the syntactic correctness and temporal continuity of the data within the block.

[0107] Step 404: Add the header information of the first tracking sub-file to the header position of the optimized second tracking sub-file to obtain the second repaired tracking sub-file.

[0108] The header information, a series of metadata at the beginning of the initial trace file, defines the framework and environment of the entire tracing session. The header information provides parsing context so that performance analysis tools can understand subsequent event data. For example, when identifying an event with thread ID "123", the performance analysis tool needs to find out from the header information which process thread "123" belongs to. Additionally, the header information defines the data format and system status, such as how the data was collected or configured, and the system's baseline state at the time of collection (e.g., the maximum and minimum CPU frequencies).

[0109] For example, header information may include a process-thread mapping table, system configuration information, CPU frequency table, memory information, GPU information, etc. The process-thread mapping table records the IDs and names of all tracked processes and threads. Without a process-thread mapping table, all events are just anonymous numbers and cannot be associated with specific applications or system components. System configuration information may include the version number of the tracking file, time information, buffer size, etc.

[0110] Understandably, since the first trace subfile is cut from the very beginning of the original file, its header is complete and reliable. Therefore, the header information of the first trace subfile can be directly copied to the header of each second trace subfile, so that each second repair trace subfile can be an independent, complete trace file that can be loaded and parsed independently by any analysis tool. This helps to ensure efficiency and reliability during subsequent parallel analysis.

[0111] Alternatively, the entire header information of the first tracking sub-file can be directly copied to the header of each second tracking sub-file to obtain a second repair tracking sub-file.

[0112] In this embodiment, after deleting the first and last lines of data in the second tracing sub-file, the header information of the first tracing sub-file is added to the header of the optimized second tracing sub-file to obtain the second repaired tracing sub-file. This converts the incomplete intermediate data fragment (the second tracing sub-file) into an independent and usable standard tracing file, thereby enabling the second repaired tracing sub-file to define key metadata such as process mapping and system configuration. This facilitates subsequent parallel processing of the second repaired tracing sub-file, improving performance detection efficiency while ensuring the reliability of performance detection results.

[0113] Furthermore, considering that deleting the last line data of the first tracking sub-file and the first and last lines data of the second tracking sub-file may delete data containing defects, such as in two adjacent second tracking sub-files where the merged last line data of the earlier sub-file and the first line data of the later sub-file correspond to a complete defect data point, in order to further improve the accuracy of subsequent performance test results, in another embodiment, a preset data integrity identification algorithm can be introduced to identify the last line data of the first tracking sub-file and the first and last lines data of the second tracking sub-file respectively.

[0114] The preset data integrity identification algorithm can identify syntax boundaries such as newline characters, event start or end markers, and necessary fields (such as pid (process id), tid (thread id), etc.) in the data to determine whether a data record is complete.

[0115] For example, when it is identified that the last line data of the first tracking sub-file and the first and last lines data of the second tracking sub-file are all complete data, that is, the last line data of the first tracking sub-file and the first and last lines data of the second tracking sub-file all have a newline character at the end, then there is no need to delete the last line data of the first tracking sub-file and the first and last lines data of the second tracking sub-file. When it is identified that the last line data of the first tracking sub-file is incomplete, that is, the last line data of the first tracking sub-file does not have a newline character at the end, then the last line data of the first tracking sub-file is deleted. When it is identified that the first and last lines data of the second tracking sub-file are incomplete, that is, the first or last line data of the second tracking sub-file does not have a newline character at the end, then the corresponding incomplete line data is deleted.

[0116] In one embodiment, the target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file, including:

[0117] The target tracking file is segmented according to a preset segmentation step size to obtain multiple consecutive tracking sub-files corresponding to the target tracking file; or,

[0118] The target tracking file is segmented according to a preset number of lines to obtain multiple consecutive tracking sub-files corresponding to the target tracking file.

[0119] It is understandable that the preset segmentation step size is the preset file size, such as 100MB or 200MB. The specific preset segmentation step size can be determined according to the requirements. When the target tracking file is segmented according to the preset segmentation step size, the last line data of the first tracking sub-file and the first and last line data of the second tracking sub-file may be incomplete. In this case, the first and second tracking sub-files need to be repaired.

[0120] The preset line count is the logical line count in the text format. For example, if the preset line count is 100,000 lines, the target tracking file will be segmented every 100,000 lines to obtain multiple consecutive tracking sub-files. When the target tracking file is segmented according to the preset line count, the last line data of the first tracking sub-file and the first and last lines data of the second tracking sub-file will not be incomplete. Therefore, in this case, there is no need to repair the first and second tracking sub-files.

[0121] In this embodiment, segmenting the target tracking file according to a preset segmentation step size or a preset number of lines can divide a large target tracking file into smaller tracking sub-files, thereby enabling parallel analysis and processing of multiple tracking sub-files to obtain the final performance detection result, which is highly efficient.

[0122] In one embodiment, such as Figure 5 As shown, the method also includes:

[0123] Step 502: If the performance test results do not meet the preset conditions, determine the abnormal tracking subfile from multiple consecutive tracking subfiles based on the performance test results.

[0124] The preset conditions are a series of quantitative indicators or rules for judging whether the target application meets the standards. These preset conditions can be performance thresholds. As discussed above, the performance quantitative indicators in this embodiment mainly include frame rate, number of dropped frames, and maximum consecutive dropped frames. Frame rate = buffer consumption / trace time, i.e., frame rate = buffer consumption / trace sub-file duration. The number of dropped frames is determined based on whether there is buffer consumption in each frame, and multiple consecutive instances without buffer consumption can be combined into one. The maximum consecutive dropped frames characterizes the situation where there is no buffer consumption in multiple consecutive frames.

[0125] For example, the frame rate threshold can be set to 55 FPS. A frame rate less than 55 FPS is considered not to meet the preset conditions. The number of dropped frames can be two or more, and the threshold for two or more dropped frames can be 60. The maximum number of consecutive dropped frames can be 50. The corresponding problem identification points are abnormal frame rates, frequent frame drops, and long periods of continuous frame drops. Assuming each tracking sub-file is divided according to a preset file size and has a corresponding duration of 58.7s, and assuming the mobile terminal's refresh rate is 60Hz (refreshing every 16.6ms), then the number of buffers consumed for each tracking sub-file should be 58.7s / 16.6ms = 3522. If the number of buffers consumed for a certain tracking sub-file is 3408, then the frame rate = 3408 / 58.7 = 58.06 FPS > 55 FPS. Therefore, the frame rate of this tracking sub-file meets the preset frame rate standard.

[0126] Optionally, existing performance analysis tools can be used to statistically analyze the frame rate, number of times two or more frames are dropped, and maximum number of consecutive dropped frames for each tracking subfile. When one or more of the frame rate, number of times two or more frames are dropped, and maximum number of consecutive dropped frames for a tracking subfile exceed the corresponding threshold, the tracking subfile can be identified as an abnormal tracking subfile, and the filename of the abnormal tracking subfile can be recorded.

[0127] Step 504: Based on the timestamp information in the exception tracking subfile and the preset time alignment mechanism, determine the abnormal running time period of the target application.

[0128] The preset time alignment mechanism tracks the mapping relationship between the timestamps of sub-files and the internal logical time of the target application.

[0129] It's understandable that the target application has a loading time at startup, so the timestamp information in the trace file differs from the target application's internal logical time, but a mapping relationship exists. For example, the target application might start testing at 9:00:00 on December 20, 2025. However, because loading resources takes time, say 58 seconds, the actual start time is 9:00:58 on December 20, 2025. Assuming this is the 0th second of the actual start time, the initial trace file has already recorded 58 seconds, as it was captured by existing performance analysis tools from the start of the target application test. Based on this time difference, the abnormal running period corresponding to the anomaly trace file can be determined.

[0130] Optionally, based on the timestamp information and time difference in the exception tracking subfile, the abnormal running time period of the target application can be determined, where the time difference is the time difference between the timestamp information in the initial tracking file and the internal logical time of the target application.

[0131] Step 506: Determine the abnormal operation information of the target application based on the abnormal operation period.

[0132] The abnormal operation information can be runtime information from a tracking subfile about the abnormality. This information includes the time period of the abnormal operation and its corresponding test scenario information, event information, performance quantification indicators, etc. The abnormal operation information can also be presented in the form of a visual analysis report, allowing developers to optimize the target application in a timely manner based on this information.

[0133] Understandably, during the testing process, the target application corresponds to different test scenario information at different testing stages. Based on the abnormal running time period, the corresponding abnormal test scenario and the corresponding event can be determined. Based on the abnormal test scenario, event, and abnormal performance quantification indicators, clearer abnormal running information can be obtained.

[0134] Optionally, based on the abnormal operation period, the corresponding abnormal test scenario information and events are determined, and based on the abnormal operation period and its corresponding abnormal test scenario information, events and corresponding performance quantification indicators, the abnormal operation information of the target application is determined.

[0135] In this embodiment, after using existing performance analysis tools to perform performance testing on each tracer subfile in parallel, the abnormal tracer subfile is first identified, and then the corresponding abnormal running time period and test scenario information are determined. This can generate more specific and clear abnormal running information, so that R&D personnel can optimize the target application in a timely manner based on the abnormal running, thereby ensuring a good user experience when using the target application.

[0136] In one detailed embodiment, the application performance testing method may specifically include the following steps:

[0137] Step A10: In the scenario of performing performance testing on the target application, obtain the initial trace file of the display information of the target application throughout the entire testing process.

[0138] For example, for a mobile game that can run on the Android system, the initial tracking file of the test player within 30 minutes can be obtained, resulting in an initial tracking file of 3GB.

[0139] Step A20: Convert the initial tracking file into the target tracking file.

[0140] The target tracking file has a different file format than the initial tracking file.

[0141] For example, the initial 3GB binary trace file is first converted into a target trace file in text format using existing performance analysis tools.

[0142] Step A30: The target tracking file is segmented according to the preset segmentation step size to obtain multiple continuous tracking sub-files corresponding to the target tracking file.

[0143] For example, assuming the preset segmentation step size is 200MB, segmenting the initial 3GB tracking file according to the preset segmentation step size of 200MB will result in approximately 15.36 consecutive tracking sub-files. Since the file cannot be completely divided equally, intelligent segmentation is required. The size of the first 14 files can be 200MB, and the size of the 15th file can be 272MB. In other words, a total of 15 consecutive tracking sub-files can be obtained.

[0144] Step A40: Using the first repair method, delete the tail line data of the first tracking sub-file to obtain the first repaired tracking sub-file.

[0145] Among them, the first tracking sub-file is the first tracking sub-file obtained among all tracking sub-files; the first repair method is to repair the tail line data in the first tracking sub-file.

[0146] For example, the tail line data of the first tracking subfile in the above 15 consecutive tracking subfiles is deleted to obtain the first repaired tracking subfile.

[0147] Step A50: Delete the first and last lines of data in the second tracking sub-file to obtain the optimized second tracking sub-file; add the header information of the first tracking sub-file to the header of the optimized second tracking sub-file to obtain the second repaired tracking sub-file.

[0148] The second tracking sub-file is the remaining tracking sub-files excluding the first tracking sub-file; the second repair method is to repair the first and last lines of data in the second tracking sub-file.

[0149] For example, the first and last lines of data in the 2nd to 15th consecutive tracking subfiles (i.e., the second tracking subfile) are deleted to obtain the second repaired tracking subfile.

[0150] Step A50: Based on each repair tracking subfile, obtain the performance test results of the target application.

[0151] For example, existing performance analysis tools are used to calculate the performance quantification metrics of the first repair tracking subfile and each of the second repair tracking subfiles. The performance quantification metrics may include frame rate, number of times two or more frames are dropped, and maximum number of consecutive dropped frames.

[0152] Step A60: If the performance test results do not meet the preset conditions, determine the abnormal tracking subfile from multiple consecutive tracking subfiles based on the performance test results.

[0153] For example, the values ​​of each performance quantification index calculated above are compared with the corresponding preset thresholds to determine the abnormal tracking subfile from 15 consecutive tracking subfiles.

[0154] Assume the performance test results of the 15 consecutive trace subfiles are as shown in Table 1:

[0155] Table 1

[0156]

[0157] The filenames in Table 1 are the filenames corresponding to the 15 tracking sub-files. According to Table 1, 20250430-150524-1.html, 20250430-150524-3.html, and 20250430-150524-4.html are abnormal tracking sub-files.

[0158] Step A70: Based on the timestamp information in the exception tracking subfile and the preset time alignment mechanism, determine the abnormal running time period of the target application.

[0159] The preset time alignment mechanism tracks the mapping relationship between the timestamps of sub-files and the internal logical time of the target application.

[0160] For example, assuming that the 0th second of the game's start time corresponds to the 45.3th second of the Trace time, and the 1790th second of the game's start time corresponds to the 1835.3th second of the Trace time, the mapping relationship between game time and Trace time can be derived: Game time = Trace time - 45.3 seconds. When an anomaly tracking subfile is determined based on performance test results, first determine the time period corresponding to the anomaly tracking subfile, and then determine the corresponding time period during the mobile game test based on the above mapping relationship. For example, if the time period of the anomaly tracking subfile is 11 minutes 45.6 seconds to 12 minutes 44.4 seconds = 705.6 seconds to 764.4 seconds, after conversion, the mobile game running time period can be determined to be 660.3 seconds to 719.1 seconds. Further calculation shows that the anomaly time in the game is 11 minutes 00.3 seconds to 11 minutes 59.1 seconds.

[0161] Step A80: Determine the abnormal operation information of the target application based on the abnormal operation period.

[0162] For example, based on the abnormal running time periods corresponding to the three anomaly tracking sub-files 20250430-150524-1.html, 20250430-150524-3.html, and 20250430-150524-4.html, the corresponding abnormal test scenario information can be determined. For instance, the abnormal test scenario information corresponding to these three anomaly tracking sub-files are the first large-scale 5v5 team battle, the map BOSS battle, and the final battle, respectively. The corresponding events are 10 heroes releasing skills simultaneously, 8 players + BOSS melee, and full-screen ultimate skill effects + weather system activation, respectively. Based on the abnormal running time period, abnormal test scenario information, corresponding events, and corresponding performance quantification indicators, the abnormal running information of the mobile game can be determined. For example, from 11 minutes 00.3 seconds to 11 minutes 59.1 seconds of game time, the game lags due to the first large-scale 5v5 team battle.

[0163] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0164] Based on the same inventive concept, this application also provides a performance testing apparatus for implementing the performance testing method for the application described above. This apparatus can be applied to or integrated into a chip or chip module, for example. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more application performance testing apparatus embodiments provided below can be found in the limitations of the application performance testing method described above, and will not be repeated here.

[0165] In one embodiment, such as Figure 6 As shown, an application performance testing device is provided, including: a trace file acquisition module 602, a trace file conversion module 604, a trace file segmentation module 606, and a test result determination module 608, wherein:

[0166] The trace file acquisition module 602 is used to acquire the initial trace file of the display information of the target application throughout the entire testing process in the scenario of performance testing of the target application.

[0167] The trace file conversion module 604 is used to convert the initial trace file into a target trace file; the target trace file has a different file format than the initial trace file.

[0168] The tracking file segmentation module 606 is used to segment the target tracking file to obtain multiple consecutive tracking sub-files corresponding to the target tracking file.

[0169] The test result determination module 608 is used to obtain the performance test results of the target application based on multiple consecutive trace subfiles.

[0170] In one embodiment, the test result determination module 608 includes a file repair submodule and a result acquisition submodule. The file repair submodule is used to repair each traced subfile and acquire the repaired traced subfile corresponding to each traced subfile. The result acquisition submodule is used to acquire the performance test results of the target application based on each repaired traced subfile.

[0171] In one embodiment, the file repair submodule includes a first repair unit and a second repair unit. The first repair unit is used to repair a first tracking subfile using a first repair method to obtain a first repaired tracking subfile. The first tracking subfile is the first tracking subfile obtained among all tracking subfiles. The first repair method is to repair the last line data in the first tracking subfile. The second repair unit is used to repair a second tracking subfile using a second repair method to obtain a second repaired tracking subfile. The second tracking subfile is the remaining tracking subfiles besides the first tracking subfile among all tracking subfiles. The second repair method is to repair the first line data and the last line data in the second tracking subfile.

[0172] In one embodiment, the first repair unit is further configured to use a first repair method to delete the tail line data of the first tracking sub-file to obtain a first repaired tracking sub-file.

[0173] In one embodiment, the second repair unit is further configured to delete the first and last lines of data in the second tracking sub-file to obtain an optimized second tracking sub-file; and to add the header information of the first tracking sub-file to the header position of the optimized second tracking sub-file to obtain a second repaired tracking sub-file.

[0174] In one embodiment, the tracking file segmentation module 606 is further configured to segment the target tracking file according to a preset segmentation step size to obtain multiple consecutive tracking sub-files corresponding to the target tracking file; or, to segment the target tracking file according to a preset number of lines to obtain multiple consecutive tracking sub-files corresponding to the target tracking file.

[0175] In one embodiment, the device further includes an abnormal operation information determination module, which is used to determine an abnormal tracking sub-file from multiple consecutive tracking sub-files based on the performance test results when the performance test results do not meet preset conditions; determine the abnormal operation period of the target application based on the timestamp information in the abnormal tracking sub-file and a preset time alignment mechanism; the preset time alignment mechanism is the mapping relationship between the timestamp of the tracking sub-file and the internal logical time of the target application; and determine the abnormal operation information of the target application based on the abnormal operation period.

[0176] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0177] In one exemplary embodiment, a computer device is provided, which may be a mobile terminal, and its internal structure diagram may be as follows. Figure 7As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a performance testing method for an application. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0178] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0179] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0180] Based on the same inventive concept, this application also provides a chip, including a processor and a communication interface; the communication interface is used to receive or send data; the processor is configured to cause the chip to perform the following steps:

[0181] In a scenario where performance testing is performed on a target application, the initial trace file containing the displayed information throughout the entire testing process of the target application is obtained.

[0182] Convert the initial trace file to a target trace file; the target trace file has a different file format than the initial trace file.

[0183] The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0184] Based on multiple consecutive trace subfiles, performance test results of the target application are obtained. In one embodiment, the processor is configured to cause the chip to perform the following steps:

[0185] In a scenario where performance testing is performed on a target application, the initial trace file containing the displayed information throughout the entire testing process of the target application is obtained.

[0186] Convert the initial trace file to a target trace file; the target trace file has a different file format than the initial trace file.

[0187] The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file;

[0188] The performance test results of the target application are obtained based on multiple consecutive trace subfiles.

[0189] It is understood that the chip involved in the embodiments of this application may be a field-programmable gate array (FPGA), may be an application-specific integrated circuit (ASIC), may be a system on chip (SoC), may be a central processor unit (CPU), may be a network processor (NP), may be a digital signal processor (DSP), may be a microcontroller unit (MCU), may be a programmable logic device (PLD), or other integrated chips, etc.

[0190] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0191] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0192] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0193] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0194] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0195] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A performance testing method for an application, characterized in that, The method includes: In a scenario where performance testing is performed on a target application, the initial trace file containing the display information of the target application throughout the entire testing process is obtained; The initial trace file is converted into a target trace file; the target trace file has a different file format than the initial trace file. The target tracking file is segmented to obtain multiple consecutive tracking sub-files corresponding to the target tracking file; Based on the multiple consecutive trace sub-files, the performance test results of the target application are obtained.

2. The method according to claim 1, characterized in that, The process of obtaining the performance test results of the target application based on the multiple consecutive trace sub-files includes: Each of the aforementioned tracking sub-files is repaired to obtain the repaired tracking sub-file corresponding to each of the aforementioned tracking sub-files; Based on the repair tracking sub-files, the performance test results of the target application are obtained.

3. The method according to claim 2, characterized in that, The step of repairing each of the aforementioned tracking sub-files and obtaining the repaired tracking sub-file corresponding to each of the aforementioned tracking sub-files includes: The first repair method is used to repair the first tracking sub-file to obtain the first repaired tracking sub-file; the first tracking sub-file is the first tracking sub-file obtained among all the tracking sub-files; the first repair method is to repair the tail line data in the first tracking sub-file. The second repair method is used to repair the second tracking sub-file to obtain the second repaired tracking sub-file; the second tracking sub-file is the other tracking sub-files besides the first tracking sub-file; the second repair method is to repair the first line data and the last line data in the second tracking sub-file.

4. The method according to claim 3, characterized in that, The first repair method is used to repair the first tracking sub-file, resulting in a first repaired tracking sub-file, which includes: Using the first repair method, the tail line data of the first tracking sub-file is deleted to obtain the first repaired tracking sub-file.

5. The method according to claim 3, characterized in that, The second repair method is used to repair the second tracking sub-file to obtain a second repaired tracking sub-file, including: The first and last lines of data in the second tracking sub-file are deleted to obtain the optimized second tracking sub-file. The header information of the first tracking sub-file is added to the header position of the optimized second tracking sub-file to obtain the second repaired tracking sub-file.

6. The method according to claim 1, characterized in that, The segmentation of the target tracking file to obtain multiple consecutive tracking sub-files corresponding to the target tracking file includes: The target tracking file is segmented according to a preset segmentation step size to obtain multiple consecutive tracking sub-files corresponding to the target tracking file; or, The target tracking file is segmented according to a preset number of lines to obtain multiple consecutive tracking sub-files corresponding to the target tracking file.

7. The method according to claim 1, characterized in that, The method further includes: If the performance test results do not meet the preset conditions, an abnormal tracking subfile is determined from the plurality of consecutive tracking subfiles based on the performance test results; Based on the timestamp information in the anomaly tracking subfile and the preset time alignment mechanism, the abnormal running time period of the target application is determined; the preset time alignment mechanism is the mapping relationship between the timestamps in the tracking subfile and the internal logical time of the target application. Based on the abnormal operation period, the abnormal operation information of the target application is determined.

8. A performance testing device for an application, characterized in that, The device includes: The trace file acquisition module is used to acquire the initial trace file of the display information of the target application throughout the entire testing process in the scenario of performing performance testing on the target application; A tracing file conversion module is used to convert the initial tracing file into a target tracing file; the target tracing file has a different file format than the initial tracing file. The tracking file segmentation module is used to segment the target tracking file to obtain multiple consecutive tracking sub-files corresponding to the target tracking file; The test result determination module is used to obtain the performance test results of the target application based on the multiple consecutive trace sub-files.

9. A computer chip comprising a processor and a communication interface, the processor being configured to cause the chip to perform the steps of the method according to any one of claims 1 to 7.

10. A mobile terminal, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

Images