A method, apparatus, device and storage medium for applying performance testing

Abstract

The application provides a method, device and equipment for application performance testing and a storage medium. The method comprises the following steps: determining a preset number of target processes running in a device based on running state monitoring information of the device; and determining a running occupancy rate of each target process in the device to obtain performance testing data of a to-be-tested application. The technical solution provided by the application can more comprehensively obtain the performance testing data of the to-be-tested application, avoid the limitation of application performance testing, and improve the accuracy of application performance testing by comprehensively analyzing the performance testing data of the to-be-tested application from different aspects.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device, and storage medium for application performance testing. Background Technology

[0002] To improve the performance of various client applications, it is usually necessary to test the performance data of various client applications on the device in advance to determine whether they can meet the performance indicators proposed by the user.

[0003] Currently, when testing a device with a specific application, the CPU usage of each process on the device is typically monitored by executing the `adb shell top` command while the application is running. The CPU usage of the application's process is then used as performance test data to analyze the application's performance.

[0004] However, executing the `adb shell top` command within the device also consumes additional CPU resources. In other words, the performance testing process adds an extra process and consumes additional CPU resources compared to the application's normal operation. This results in a discrepancy between the CPU utilization obtained during the performance test and the actual CPU utilization during normal operation. Therefore, using the CPU utilization of the process containing the application to test application performance will significantly impact the accuracy of the performance test. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for application performance testing, which can more comprehensively obtain performance test data of the application under test and improve the accuracy and effectiveness of application performance testing.

[0006] In a first aspect, embodiments of this application provide a method for application performance testing, the method comprising:

[0007] Based on the running status monitoring information of the device where the application to be tested is located, a preset number of target processes that are running in the device are determined.

[0008] Determine the runtime utilization of each target process within the device to obtain performance test data for the application under test.

[0009] Secondly, embodiments of this application provide an apparatus for application performance testing, the apparatus comprising:

[0010] The target process determination module is used to determine a preset number of target processes running in the device based on the running status monitoring information of the device where the application to be tested is located.

[0011] The performance testing module is used to determine the runtime utilization of each target process within the device and obtain performance test data for the application under test.

[0012] Thirdly, embodiments of this application provide an electronic device, which includes:

[0013] A processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to perform the application performance testing method provided in the first aspect of this application.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium for storing a computer program that causes a computer to perform the application performance testing method provided in the first aspect of this application.

[0015] Fifthly, embodiments of this application provide a computer program product, including a computer program / instructions, characterized in that, when the computer program / instructions are executed by a processor, they implement the application performance testing method provided in the first aspect of this application.

[0016] This application provides a method, apparatus, device, and storage medium for application performance testing. During the operation of the application under test on the device, based on the operating status monitoring information of the device, a preset number of target processes running on the device are determined. Then, the running occupancy rate of each target process on the device is determined, thereby obtaining more comprehensive performance test data of the application under test, avoiding the limitations of application performance testing, and improving the accuracy of application performance testing by comprehensively analyzing the performance test data of the application under test from different aspects. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating an application performance testing method according to an embodiment of this application;

[0019] Figure 2This is a schematic diagram illustrating the runtime status monitoring information obtained by the adb shell top command in an embodiment of this application.

[0020] Figure 3 This is a schematic diagram illustrating the FPS parameter changes of the application under test within the device, as shown in an embodiment of this application.

[0021] Figure 4 and Figure 5 These are schematic diagrams illustrating the changes in GPU frequency and GPU percentage within the device where the application under test is located, as shown in the embodiments of this application.

[0022] Figure 6 A flowchart illustrating another application performance testing method as shown in an embodiment of this application;

[0023] Figure 7 This is a schematic diagram illustrating how the user-mode time and kernel-mode time of a target process are determined using the command `proc / [pid]> / stat`, as shown in an embodiment of this application.

[0024] Figure 8 This is a schematic block diagram of an application performance testing device according to an embodiment of this application;

[0025] Figure 9 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0028] Considering that the `adb shell top` command executed during application performance testing adds an extra process and consumes additional CPU resources, a discrepancy may arise between the CPU utilization obtained during application performance testing and the actual CPU utilization during normal application operation, thus affecting the accuracy of application performance testing. Therefore, this application designs a new application performance testing scheme. By monitoring the running status information of the device where the application under test is located, multiple target processes running on the device are identified, and then the CPU utilization of each target process is determined. This provides a more comprehensive set of performance test data for the application under test, avoiding the limitations of traditional application performance testing. By comprehensively analyzing the performance test data from different perspectives, the accuracy of application performance testing is improved.

[0029] Figure 1 This is a flowchart illustrating an application performance testing method according to an embodiment of this application. The method can be executed by the application performance testing apparatus provided in this disclosure, which can be implemented in any software and / or hardware manner. Exemplarily, the application performance testing apparatus can be applied to any electronic device, including but not limited to tablets, mobile phones (such as foldable phones, large-screen phones, etc.), wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), smart TVs, smart screens, high-definition TVs, 4K TVs, smart speakers, smart projectors, and other IoT-enabled devices. This application does not limit the specific type of electronic device.

[0030] Specifically, such as Figure 1 As shown, the method may include the following steps:

[0031] S110, based on the operating status monitoring information of the device where the application under test is located, determine the preset number of target processes currently running on the device.

[0032] The application to be tested can be any client application developed by the developers that requires testing of its actual performance. This allows for optimization of potential issues based on the test results before application deployment, thereby ensuring the stability of the application during actual operation. For example, the application to be tested in this application could be a newly developed virtual reality (VR) game suitable for various Android devices.

[0033] In this application, the performance testing of the application under test mainly involves testing its actual operation on a specific device. Therefore, this application pre-installs the application under test on a device so that the user can open the application and perform various application operations. This device can be any terminal device that supports the successful operation of the application under test. Then, a communication connection is established between this device and the personal computer (PC) used for application testing, allowing the PC to monitor the actual operation of the application under test on the device in real time. In other words, the application performance testing scheme in this application is primarily applied to the PC, which executes each performance test step for the application under test, avoiding any impact on the actual operation of the device and thus ensuring the accuracy of the application performance test as much as possible.

[0034] As an optional implementation of this application, when performing performance testing on the application under test, the first step is to identify the connected device on which the application under test is installed. Then, the application under test is required to be launched on the device and perform corresponding application operations, thus placing the application under test in an actual running state on the device. Furthermore, during the actual operation of the application under test on the device, a certain method can be used to dynamically monitor the resource usage of each process within the device in real time and obtain the device's operational status monitoring information.

[0035] The device's operational status monitoring information may include, but is not limited to, the total number of processes configured within the device, the number of processes currently running, and the user ID of the process owner, process priority, and CPU utilization rate of each process during actual operation.

[0036] Then, considering that the application under test will run in a specific process on the device, and the running status of other processes may also affect the actual running status of the process containing the application under test, this application can obtain the actual running status of each process within the device by analyzing the running status monitoring information of the device containing the application under test. Then, based on the actual running status of each process, a preset number of target processes can be selected from all processes within the device, so as to use the running status of multiple target processes to comprehensively analyze whether the running performance of the application under test is abnormal.

[0037] For example, such as Figure 2 As shown, this application can use the `top` command in the terminal command-line mode (i.e., the `adb shell top` command) to obtain a preset number of target processes running on the device where the application under test is located. Among them, Figure 2 The process selected in the middle box is an additional process added when the `adb shell top` command is executed on this device, which will affect the resource usage of other processes. At this point, the `adb shell top` command can filter out the top 100 processes by CPU usage, and the CPU usage (i.e.,...) Figure 2 The target processes whose [%CPU] value is not zero. That is, the default number in this application is 100.

[0038] S120, determine the utilization rate of each target process within the device, and obtain the performance test data of the application under test.

[0039] After determining the preset number of target processes running on the device where the application to be tested is located, the resource usage of each target process on the device can be used to determine the CPU utilization rate of that target process within the current runtime segment.

[0040] At this point, considering that the performance of the application under test may be affected by the operation of other processes, this application can unify the utilization rate of each target process as the performance test data of the application under test. This allows for a comprehensive analysis of the performance anomalies of the process containing the application under test, based on the running conditions of different processes, to determine whether the anomalies are caused by the process itself or by the anomalies of other processes, thereby achieving a more accurate performance test of the application under test.

[0041] It should be noted that the performance of the same application may be affected by the device's own configuration when running on different devices. Therefore, to ensure the comprehensiveness of application performance testing, this application will test the performance of the application under test on multiple different versions of devices to understand how the application performs on different devices. Then, based on the performance test results of the application under test on multiple different system versions, optimizations will be made to address any potential issues, making it suitable for more device versions and improving the application's performance on any device.

[0042] As an optional implementation scheme in this application, in order to further ensure the accuracy of application performance testing, a performance index threshold is pre-set for each target process based on the performance test data of the application under test, that is, the running utilization rate of each target process, in order to determine whether there are performance abnormalities in each target process in the device where the application under test is located, and then analyze whether it affects the running performance of the process where the application under test is located.

[0043] Optionally, to ensure the accuracy of the performance metric thresholds, this application will perform test training on the application under test on at least two versions of devices to obtain test training data for the application under test on each version of device; based on the test training data of the application under test on each version of device, the performance metric thresholds of the application under test will be determined, so as to determine the performance test results of the application under test according to the performance test data and performance metric thresholds of the application under test.

[0044] In other words, before the actual test, at least two versions of devices are first set up. Then, the application performance test steps described above can be executed once on each version of device to obtain the runtime utilization of each target process on that version of device. Furthermore, the runtime utilization of each target process on each version of device is used as the test training data for the application under test on that version of device. Thus, for the same target process, there will be a runtime utilization rate for that target process on each version of device. At this point, for each target process, the average runtime utilization rate across all versions of devices can be calculated. Therefore, the average runtime utilization rate for each target process can represent a reference metric for that target process on any device. Therefore, based on the average runtime utilization rate of each target process across all versions of devices, a runtime utilization threshold for each target process can be set and uniformly used as the performance metric threshold for the application under test. Furthermore, during subsequent actual performance testing, the runtime utilization of each target process in the performance test data of the application under test can be compared with the runtime utilization threshold of each target process in the performance indicator threshold to determine the running status of each target process on a specific device during the actual operation of the application under test on that device. Then, using the running status of each target process on that device, a comprehensive analysis can be conducted to determine whether the performance anomaly of the process containing the application under test is caused by its own inherent characteristics or by the abnormal running of other processes, thereby more accurately testing the performance of the application under test and obtaining the performance test results. Moreover, the performance indicator thresholds of the application under test determined by the testing and training method on multiple versions of devices in this application have significant guiding value for the formulation of product standards or version performance evaluation during subsequent actual deployment of the application.

[0045] In addition, to ensure the comprehensiveness of application performance testing, this application, besides using the CPU utilization rate of each target process within the device where the application under test is located as the performance test data of the application under test, will also analyze the number of frames per second (FPS) transmitted by the application under test within the device and the graphics processing parameters of the device where the application under test is located (such as the frequency and percentage of the graphics processing unit (GPU) within the device).

[0046] For example, regarding the FPS parameter of the application under test on the device, when the device is a VR device, the `logcat` command can be used directly to obtain the FPS log information of the application under test. By continuously obtaining and parsing this log information, the maximum, minimum, mean, and variance of the FPS parameter during the test can be calculated. Figure 3 As shown, the changes in FPS parameters in the application under test can be displayed graphically, thereby analyzing whether there are any performance anomalies in the application. Here, the FPS parameter is continuously monitored, and the data analysis not only includes the mean FPS to evaluate the overall frame rate level of the application, but also uses the FPS variance to evaluate the frame rate stability throughout the entire application testing process.

[0047] For the graphics processing parameters of the device running the application under test, specific text records containing GPU frequency and percentage can be retrieved repeatedly during application testing. Then, by parsing this specific text, the maximum, minimum, mean, and variance of the GPU frequency and percentage during the test can be calculated. For example... Figure 4 and Figure 5 As shown, the changes in GPU frequency and percentage in the application under test can be displayed graphically, thereby analyzing whether there are any performance anomalies in the application under test.

[0048] In summary, this application can comprehensively evaluate application performance by measuring FPS values, CPU utilization of each target process within the device, and GPU frequency and usage during application testing, thus effectively assessing application performance levels. Furthermore, it provides effective log and monitoring information for development analysis and troubleshooting when application issues arise.

[0049] The technical solution provided in this application embodiment determines the preset number of target processes running on the device based on the running status monitoring information of the device where the application is located, and then determines the running occupancy rate of each target process on the device, thereby obtaining more comprehensive performance test data of the application under test, avoiding the limitations of application performance testing, and improving the accuracy of application performance testing by comprehensively analyzing the performance test data of the application under test from different aspects.

[0050] As an optional implementation in this application, since obtaining device runtime status monitoring information by executing the `adb shell top` command can lead to a certain deviation between the CPU utilization rate obtained during application performance testing and the actual CPU utilization rate during normal application operation, this application further uses the `prco / [pid] / stat` command to obtain the specific runtime data of the target process represented by the PID. This specific runtime data includes not only the data information of the target process as the main process but also the data information of each child thread under the target process. Then, the runtime utilization rate of each target process within the device is calculated more accurately using this data. The specific calculation process of the runtime utilization rate of each target process within the device will be explained in detail below.

[0051] Figure 6 A flowchart illustrating another application performance testing method as shown in an embodiment of this application. (Refer to...) Figure 6 The method may specifically include the following steps:

[0052] S610 periodically acquires the operating status monitoring information of the device where the application under test is located at the current time according to a preset interval.

[0053] Considering the discrepancy between the CPU utilization rate obtained by the adb shell top command for each target and the actual CPU utilization rate during normal operation, this application can analyze the actual CPU running time of the process at different times by comparing the CPU utilization rate of the same process at different times, thereby accurately calculating the running utilization rate of each target process in the device.

[0054] In this application, a preset interval is set, and during application testing, the operating status monitoring information of the device where the application under test is located is periodically obtained after each preset interval. That is, according to the preset interval, the operating status monitoring information of the device at different times will be obtained.

[0055] S620 determines the preset number of candidate processes that the device is running at that moment based on the operating status monitoring information at each moment.

[0056] After acquiring the device's operational status monitoring information at each current moment, the `adb shell top` command is used to parse this information and determine the preset number of processes currently running on the device. At each moment when the device's operational status monitoring information is acquired periodically at preset intervals, the preset number of processes currently running on the device are determined as candidate processes in this application.

[0057] S630, determine the target process for each preset interval based on the intersection of the candidate processes at the start and end times of each preset interval.

[0058] Since the processes running on a device may differ at different times, only processes that run continuously within a preset interval can have their utilization rate analyzed. Therefore, this application determines the start and end times of each preset interval. At both the start and end times of this preset interval, there are a preset number of candidate processes. By performing an intersection operation on the candidate processes at the start and end times of each preset interval, the candidate processes that exist at both the start and end times of this preset interval are obtained and used as the target processes for that preset interval.

[0059] Therefore, following the same method described above, the corresponding target process running within each preset interval will be determined.

[0060] S640, for each preset interval, determine the total running time of each target process at the start and end times of that preset interval.

[0061] As an optional implementation scheme in this application, for each preset interval, the specific running state of each target process at the start and end times of the preset interval can be analyzed, thereby determining the total running time of each target process at the start and end times of the preset interval, so as to subsequently determine the actual running time of each target process within the preset interval.

[0062] For example, such as Figure 7 As shown, for any time between the start and end of each preset interval, this application can use the command `proc / [pid]> / stat` to obtain the user-mode time and kernel-mode time of each target process within that preset interval at that specific time. Here, `pid` in the `proc / [pid]> / stat` command represents the current target process identifier.

[0063] Moreover, such as Figure 7The `proc / [pid] / stat` file shown can contain a sequence of all execution results accumulated from system startup to the current time for a specific target process. Specifically, the 14th value of the result sequence represents the total execution time (utime) of the main process (represented by the target process) in user mode; the 15th value represents the total execution time (stime) of the main process (represented by the target process) in kernel mode; the 16th value represents the total execution time (cutime) of the child processes under the target process in user mode; and the 17th value represents the total execution time (cstime) of the child processes under the target process in kernel mode. Therefore, it can be seen that the user mode time for each target process at any time between the start and end of each preset interval can be utime + cutime, and the kernel mode time can be stime + cstime.

[0064] Then, by calculating the sum of the user-mode time and kernel-mode time of each target process at any time between the start and end times of each preset interval, this application can obtain the total running time of the target process at that time: processCPUTime = utime + stime + cutime + cstime.

[0065] S650 calculates the running occupancy rate of the target process in the device based on the difference between the total running time of each target process at the start and end times of the preset interval and the preset interval, and obtains the performance test data of the application to be tested.

[0066] Optionally, for each preset interval, the actual running time of the target process within that preset interval can be obtained by calculating the difference between the total running time of each target process at the start and end times of that preset interval. Then, the running occupancy rate of the target process within the device can be obtained by calculating the ratio of this difference to the preset interval.

[0067] For example, the total running time of the target process at the beginning of each preset interval can be denoted as processCPUTime_start, and the total running time at the end of the preset interval can be denoted as processCPUTime_end. Then, the running utilization rate of the target process during the preset interval can be expressed as (processCPUTime_end - processCPUTime_start) / preset interval.

[0068] Following the same calculation steps described above, the runtime utilization of each target process within each preset interval can be accurately calculated. Furthermore, by continuously analyzing the changes in the runtime utilization of each target process over multiple preset intervals, it can be determined whether the application under test exhibits any operational anomalies.

[0069] The technical solution provided in this application embodiment determines the preset number of target processes running on the device based on the running status monitoring information of the device where the application is located, and then determines the running occupancy rate of each target process on the device, thereby obtaining more comprehensive performance test data of the application under test, avoiding the limitations of application performance testing, and improving the accuracy of application performance testing by comprehensively analyzing the performance test data of the application under test from different aspects.

[0070] Figure 8 This is a schematic block diagram illustrating an application performance testing apparatus according to an embodiment of this application. Figure 8 As shown, the device 800 may include:

[0071] The target process determination module 810 is used to determine a preset number of target processes running in the device based on the running status monitoring information of the device where the application to be tested is located.

[0072] The performance testing module 820 is used to determine the runtime utilization of each target process within the device and obtain the performance test data of the application under test.

[0073] Furthermore, the target process determination module 810 can be specifically used for:

[0074] The operating status monitoring information of the device where the application under test is located is acquired periodically at preset intervals at the current time.

[0075] Based on the operational status monitoring information at each moment, a preset number of candidate processes that the device is running at that moment are determined;

[0076] The target process for each preset interval is determined by the intersection of the candidate processes at the start and end times.

[0077] Furthermore, the performance testing module 820 can be specifically used for:

[0078] For each preset interval, determine the total running time of each target process at the start and end times of that preset interval;

[0079] The occupancy rate of the target process within the device is calculated based on the difference between the total running time of each target process at the start and end times of the preset interval and the preset interval.

[0080] Furthermore, the performance testing module 820 can be specifically used for:

[0081] For any time between the start and end times of each preset interval, obtain the user-mode time and kernel-mode time of each target process at that time, and take the sum of the user-mode time and kernel-mode time of the target process at that time as the total running time of the target process at that time.

[0082] Furthermore, the preset number of target processes running within the device are determined using the top command in the terminal command line mode.

[0083] Furthermore, the performance test data of the application under test also includes the number of frames transmitted per second by the application under test within the device and the graphics processing parameters of the device where the application under test is located.

[0084] Furthermore, the application performance testing apparatus 800 may also include:

[0085] The test training module is used to perform test training on the application under test on at least two versions of devices respectively, and obtain test training data of the application under test on each version of device.

[0086] The performance metric determination module is used to determine the performance metric threshold of the application under test based on the test training data of the application under test on each version of the device, so as to determine the performance test result of the application under test according to the performance test data of the application under test and the performance metric threshold.

[0087] In this embodiment, during the operation of the application under test on the device, based on the running status monitoring information of the device, a preset number of target processes running on the device are determined, and then the running occupancy rate of each target process on the device is determined, thereby obtaining more comprehensive performance test data of the application under test, avoiding the limitations of application performance testing, and improving the accuracy of application performance testing by comprehensively analyzing the performance test data of the application under test from different aspects.

[0088] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details will not be provided here. Specifically, Figure 8 The apparatus 800 shown can execute any of the method embodiments provided in this application, and the foregoing and other operations and / or functions of each module in the apparatus 800 are respectively for implementing the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0089] The apparatus 800 of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0090] Figure 9 This is a schematic block diagram of the electronic device 900 provided in the embodiments of this application.

[0091] like Figure 9 As shown, the electronic device 900 may include:

[0092] The system includes a memory 910 and a processor 920. The memory 910 stores computer programs and transfers the program code to the processor 920. In other words, the processor 920 can retrieve and run the computer program from the memory 910 to implement the methods described in the embodiments of this application.

[0093] For example, the processor 920 can be used to execute the above-described method embodiments according to instructions in the computer program.

[0094] In some embodiments of this application, the processor 920 may include, but is not limited to:

[0095] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0096] In some embodiments of this application, the memory 910 includes, but is not limited to:

[0097] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0098] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 910 and executed by the processor 920 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0099] like Figure 9 As shown, the electronic device may also include:

[0100] Transceiver 930, which can be connected to processor 920 or memory 910.

[0101] The processor 920 can control the transceiver 930 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 930 may include a transmitter and a receiver. The transceiver 930 may further include antennas, and the number of antennas may be one or more.

[0102] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0103] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0104] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0105] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0106] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0107] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0108] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for application performance testing, characterized in that, include: Based on the running status monitoring information of the device where the application to be tested is located, a preset number of target processes that are running in the device are determined. Determine the runtime utilization rate of each target process within the device to obtain performance test data for the application under test; The step of determining a preset number of target processes running within the device based on the operational status monitoring information of the device where the application under test is located includes: The operating status monitoring information of the device where the application under test is located is acquired periodically at preset intervals at the current time. Based on the operational status monitoring information at each moment, a preset number of candidate processes that the device is running at that moment are determined; The target process for each preset interval is determined by the intersection of the candidate processes at the start and end times.

2. The method according to claim 1, characterized in that, Determining the runtime utilization rate of each target process within the device includes: For each preset interval, determine the total running time of each target process at the start and end times of that preset interval; The occupancy rate of the target process within the device is calculated based on the difference between the total running time of each target process at the start and end times of the preset interval and the preset interval.

3. The method according to claim 2, characterized in that, The step of determining the total running time of each target process within each preset interval at the start and end times of that preset interval includes: For any time between the start and end times of each preset interval, obtain the user-mode time and kernel-mode time of each target process at that time, and take the sum of the user-mode time and kernel-mode time of the target process at that time as the total running time of the target process at that time.

4. The method according to claim 1, characterized in that, The preset number of target processes running within the device are determined using the top command in the terminal command line mode.

5. The method according to claim 1, characterized in that, The performance test data of the application under test also includes the number of frames transmitted per second by the application under test within the device and the graphics processing parameters of the device where the application under test is located.

6. The method according to claim 1, characterized in that, The method further includes: The application under test is tested and trained on at least two versions of devices to obtain test training data for the application under test on each version of device. Based on the test training data of the application under test on each version of the device, a performance indicator threshold for the application under test is determined, and the performance test result of the application under test is determined according to the performance test data of the application under test and the performance indicator threshold.

7. An application performance testing apparatus, characterized in that, include: The target process determination module is used to determine a preset number of target processes running in the device based on the running status monitoring information of the device where the application to be tested is located. The performance testing module is used to determine the runtime utilization of each target process within the device and obtain the performance test data of the application under test. The target process determination module is specifically used for: The operating status monitoring information of the device where the application under test is located is acquired periodically at preset intervals at the current time. Based on the operational status monitoring information at each moment, a preset number of candidate processes that the device is running at that moment are determined; The target process for each preset interval is determined by the intersection of the candidate processes at the start and end times.

8. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the application performance testing method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform an application performance test method as described in any one of claims 1-6.

Images