Memory Performance Testing Method, Device, Readable Storage Medium, and Electronic Device

Abstract

The present invention discloses a method, apparatus, readable storage medium and electronic device for testing memory performance, including: obtaining a function script selected by a user, controlling a first device to perform user simulation operations according to the function script, and collecting system debugging logs; parsing the system debugging logs to obtain a set of log command groups; converting all the log command groups in the set of log command groups into test commands to obtain a set of test commands; and sequentially sending the test commands in the set of test commands to at least one device to be tested, instructing the device to be tested to complete the test. By simulating user operations on the first device through a function script and then collecting the corresponding system debugging logs, converting the system debugging logs into test commands for device testing, and being able to automatically distribute the test commands to the corresponding devices to be tested, it reduces labor costs and at the same time reduces the uncertainty brought by manual testing, thereby improving the test efficiency and accuracy.

Description

Technical Field

[0001] The present invention relates to the technical field of storage device performance testing, and particularly to a memory performance testing method, device, readable storage medium and electronic device. Background Art

[0002] Currently, the existing testing methods for storage device performance usually use benchmark performance testing tools for single testing. For example, the existing Android platform benchmark performance testing uses tools such as FIO (Flexible I / O Tester) and iozone. During testing, it is carried out with a specific access mode and a specific write data size, and the stress scenario testing is also completed based on a single increase in different data and access thread numbers. The testing process only relies on the tester's experience to adjust parameters, and cannot dynamically simulate real-time usage scenarios. Moreover, repeated operations are required between different systems, reducing the testing efficiency. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a memory performance testing method, device, readable storage medium and electronic device, so as to improve the testing efficiency and accuracy.

[0004] To solve the above technical problem, the technical solution adopted by the present invention is as follows:

[0005] A memory performance testing method includes:

[0006] Obtaining a function script selected by a user, controlling a first device to perform user simulation operations according to the function script, and collecting system debugging logs;

[0007] Parsing the system debugging logs to obtain a set of log command groups;

[0008] Converting all the log command groups in the set of log command groups into test commands to obtain a set of test commands;

[0009] Sequentially sending the test commands in the set of test commands to at least one device to be tested, and instructing the device to be tested to complete the test.

[0010] To solve the above technical problem, another technical solution adopted by the present invention is as follows:

[0011] A memory performance testing device includes:

[0012] An obtaining module, configured to obtain a function script selected by a user, control a first device to perform user simulation operations according to the function script, and collect system debugging logs;

[0013] A parsing module, configured to parse the system debugging logs to obtain a set of log command groups;

[0014] A conversion module, configured to convert all the log command groups in the log command group set into test commands to obtain a test command set;

[0015] A sending module, configured to sequentially send the test commands in the test command set to at least one device to be tested, and instruct the device to be tested to complete the test.

[0016] To solve the above technical problem, another technical solution adopted by the present invention is:

[0017] A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each step of the memory performance test method as described above is implemented.

[0018] To solve the above technical problem, another technical solution adopted by the present invention is:

[0019] An electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and when the processor executes the computer program, each step in the memory performance test method as described above is implemented.

[0020] The beneficial effects of the present invention are as follows: separating the operation process and the specific parameters used in the operation process, organizing the operation process into a function script, collecting corresponding system debugging logs after simulating user operations on the first device through the function script, that is, obtaining the specific parameters corresponding to the operation process by simulating actual user operations. Compared with directly inputting specific parameters for testing, converting the system debugging logs into test commands for device testing makes the test commands closer to the actual usage scenario; after obtaining the test command set, it can automatically distribute the test commands to the corresponding devices to be tested, realizing the reuse of the test command set, reducing labor costs, and at the same time reducing the uncertainty brought by manual testing, thereby improving the test efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a flowchart of the steps of a memory performance test method in an embodiment of the present invention;

[0022] Figure 2 It is an overall architecture diagram of a memory performance test method in an embodiment of the present invention;

[0023] Figure 3 It is a structural diagram of a memory performance test device in an embodiment of the present invention;

[0024] Figure 4 It is another flowchart of the steps of a memory performance test method in an embodiment of the present invention;

[0025] Figure 5Schematic diagram of system log key fields for a memory performance testing method in an embodiment of the present invention;

[0026] Figure 6 Schematic diagram of shard logs for a memory performance testing method in an embodiment of the present invention;

[0027] Figure 7 Schematic diagram of read shard logs for a memory performance testing method in an embodiment of the present invention;

[0028] Figure 8 Schematic diagram of the format for inserting into a database for a memory performance testing method in an embodiment of the present invention;

[0029] Figure 9 Schematic diagram of performance results for a memory performance testing method in an embodiment of the present invention;

[0030] Figure 10 Schematic diagram of the structure of an electronic device in an embodiment of the present invention. Detailed implementation manners

[0031] To describe in detail the technical content, achieved objectives and effects of the present invention, the following is described in conjunction with the implementation manners and with reference to the accompanying drawings.

[0032] A memory performance testing method includes:

[0033] Obtain a function script selected by a user, control a first device to perform user simulation operations according to the function script, and collect system debugging logs;

[0034] Analyze the system debugging logs to obtain a set of log command groups;

[0035] Convert all the log command groups in the set of log command groups into test commands to obtain a set of test commands;

[0036] Send the test commands in the set of test commands to at least one device to be tested in sequence, instructing the device to be tested to complete the test.

[0037] As can be seen from the above description, the beneficial effects of the present invention are as follows: separating the operation process from the specific parameters used in the operation process, organizing the operation process into a function script, collecting corresponding system debugging logs after simulating user operations on the first device through the function script, that is, obtaining the specific parameters corresponding to the operation process by simulating actual user operations. Compared with directly inputting specific parameters for testing, converting the system debugging logs into test commands for device testing makes the test commands closer to the actual usage scenario. After obtaining the set of test commands, it can automatically distribute the test commands to the corresponding devices to be tested, realizing the reuse of the set of test commands, reducing labor costs, and at the same time reducing the uncertainty brought by manual testing, thereby improving the test efficiency and accuracy.

[0038] Further, the parsing of the system debugging logs to obtain the set of log command groups includes:

[0039] Forming a log command group in a preset form for the command lines with the same keyword fields in the system debugging logs;

[0040] The keyword fields include the starting logical block address and the data size, and the command line includes a start timestamp or an end timestamp;

[0041] Discarding the log command groups without the start timestamp, and sorting the non-discarded log command groups according to the start timestamp or the end timestamp to obtain the set of log command groups.

[0042] As can be seen from the above description, the command lines in the system debugging logs can be effectively extracted to obtain log command groups through keyword field recognition; at the same time, since the log command groups without a start flag bit have an uncertain written data size and the start time is not in the system log, it can be excluded that they are read and write operations brought about after the test script runs. Therefore, discarding the log command groups without a start timestamp can improve the accuracy of subsequent tests.

[0043] Further, after obtaining the set of log command groups, it further includes:

[0044] Slicing all the log command groups at a preset time interval according to the start timestamp to obtain sliced log command groups;

[0045] Sending the test commands in the set of test commands to at least one device to be tested in sequence includes:

[0046] Sequentially sending the test commands corresponding to each sliced log command group to at least one device to be tested according to the preset time interval.

[0047] As described above, by sharding all log command groups at a preset time interval and issuing the shards of the log command groups at the preset time interval during testing, it is possible to simulate the issuance of operation commands in a dynamic manner when a user uses the device, thereby realizing the testing of the device in a dynamic simulation distribution manner, which is closer to the actual usage scenario.

[0048] Further, after obtaining the shards of the log command groups, it includes;

[0049] Mark different shards of the log command groups with different shard sequence numbers;

[0050] The step of sequentially issuing the shards of the log command groups according to the preset time interval includes:

[0051] Determine whether the shard sequence number corresponding to the current target log command group is the same as the shard sequence number corresponding to the previous log command group. If so, issue the target log command group; if not, issue the target log command group after reaching the preset time interval.

[0052] As described above, by marking different shards of the log command groups with different shard sequence numbers, when subsequently issuing the log command groups for testing, it is possible to effectively determine whether adjacent log command groups belong to the same shard, ensuring that the log command groups within each shard of the log command groups are tested within the preset time interval.

[0053] Further, the step of converting all the log command groups in the log command group set into test commands includes:

[0054] Sequentially traverse all the logical block addresses starting from the starting logical block address of the log command group, and judge the continuity of adjacent logical block addresses to obtain the continuous quantity and the total quantity of the logical block addresses;

[0055] Obtain the sequential read and random read ratios according to the continuous quantity and the total quantity of the logical block addresses;

[0056] Use the sequential read and random read ratios as test parameters, and convert the test parameters into the test commands.

[0057] As described above, by traversing the logical block addresses of the log command group and obtaining continuous logical block addresses through continuity judgment, it is possible to obtain the sequential read and random read ratios, realizing the extraction of the sequential read and random read ratios.

[0058] Further, the step of sequentially issuing the test commands corresponding to each shard of the log command groups to at least one device to be tested according to the preset time interval includes:

[0059] Read each test parameter in the shards of the target log command group;

[0060] Combine the test parameters into a shard test command through a test tool;

[0061] Send the shard test command to at least one device under test through the debug bridge command line interface.

[0062] As can be seen from the above description, after combining the test parameters into a shard test command through a test tool, and then sending the shard test command to each device under test based on the debug bridge command line interface, for example, based on the Android Debug Bridge, the control of Android devices can be realized, thereby completing the testing of Android devices.

[0063] Further, after sending the shard test command to at least one device under test through the debug bridge command line interface, it further includes:

[0064] Store the test results in a fixed directory, and draw a performance curve graph according to the test results.

[0065] As can be seen from the above description, by drawing a performance curve graph according to the test results and presenting the test results in the form of pictures, a more valuable and intuitive performance report can be provided for developers, which is beneficial to understanding the performance of the product in the real scenarios of each operating system.

[0066] Another embodiment of the present invention provides a memory performance testing device, including:

[0067] An acquisition module, configured to acquire a function script selected by a user, control a first device to perform user simulation operations according to the function script, and collect system debug logs;

[0068] An analysis module, configured to analyze the system debug logs to obtain a set of log command groups;

[0069] A conversion module, configured to convert all the log command groups in the set of log command groups into test commands to obtain a set of test commands;

[0070] A sending module, configured to sequentially send the test commands in the set of test commands to at least one device under test, instructing the device under test to complete the test.

[0071] Another embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements each step of the memory performance testing method as described above.

[0072] Another embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, each step in the memory performance test method as described above is implemented.

[0073] The memory performance test method, device, readable storage medium, and electronic device provided by the present invention can be applied to the test scenario of solid-state memory firmware algorithms, which will be described below through specific embodiments:

[0074] Embodiment 1

[0075] Please refer to Figure 1 , a memory performance test method, including:

[0076] S1. Obtain the function script selected by the user, control the first device to perform user simulation operations according to the function script, and collect system debugging logs. Taking an Android device as an example, automatically control the Android device to perform user simulation operations according to the function script selected by the user. For example, the function script includes operations such as playing videos, downloading files, installing applications, and long-clicking on the screen, and collect system debugging logs after performing the corresponding operations.

[0077] In actual applications, the above steps can be implemented based on the sampling module. Specifically: first, turn on the debugging log switch. The user selects and runs a Python script pre-written with simulated user operations or some special operations, and interacts with the Android UI through the uiautomator2 library, including controlling the Android device to play videos, download files, install applications, and simulate a series of automated operation methods of the user. After all the simulation scripts are executed, turn off the debugging log switch. At the same time, the sampling module can use machine learning to learn and train the data reading and writing situations used by the user. After the user simulates the specified operation method, system debugging logs can be quickly generated, reducing the script development volume, and enriching different data combinations without relying on the physical platform.

[0078] S2. Analyze the system debugging logs to obtain a set of log command groups. For example, pull the system debugging logs from the specified directory of the sampled Android platform. Each debugging log includes the following key fields: timestamp, start (issue) or end (complete) command flag, read (R) or write (W) access type, starting logical block address (LBA), and data (chunksize) size.

[0079] S21. Command lines with the same key fields in the system debug log are combined into a log command group in a preset form. For example, in two debug logs, one log command flag is set to start, the other command flag is set to end, and the start log timestamp is less than the end log timestamp, and the starting lba + chunksize are consistent. These two debug logs form a complete log command group. All command groups are filtered out from the entire system debug log. A complete command group is formed into a new log in the preset form of: start timestamp, end timestamp, read (R) or write (W) access type, starting lba, and chunksize. Among them, the log command group set cannot form a complete command group. For example, this log has a start flag but no end timestamp; this log has an end flag but no start timestamp.

[0080] S22: Log command groups without start timestamps are discarded, and the remaining log command groups are sorted by start timestamp or end timestamp to obtain a set of log command groups. Since the start time of command issuance cannot be determined for these command groups, and since it is impossible to determine whether the written data size and start time are within the preset test time, they need to be discarded. Command groups without end timestamps are not discarded because all test parameters can be extracted from the start command. However, a potential problem is that the command write time is very long, and the system logs intercepted within the preset time period do not receive the end command. This indicates that the operation occurred at that time, but the write time is shortened, while the written data size and other parameters remain unchanged. This is equivalent to increasing the read and write pressure in disguise, further testing the performance of the storage device. However, if these command groups are discarded, it is equivalent to reducing these operations, which will deviate from the actual simulated operation. Testing in a more rigorous environment is preferred. The combined logs are then sorted by start timestamp to obtain a sorted combined log.

[0081] S23. Slice all log command groups at preset time intervals based on the start timestamp to obtain log command group shards. At the same time, mark different log command group shards with different shard sequence numbers. For example, after slicing the sorted combination log at ten-minute time intervals, multiple shard logs are obtained. The logs are then parsed to extract the read and write data size and chunksize ratio distribution of sequential reads, sequential writes, random reads, and random writes within each ten minutes, as well as the range of lba. The extracted test parameters are converted into shard test commands, and the test duration of each command is set to 10 minutes. The commands are then appended to the command set. The specific steps are as follows:

[0082] Among them, the steps for extracting test parameters of multi - shard logs are the same. At the same time, the shard logs are classified into read shard logs and write shard logs according to read or write commands. The methods for extracting detailed test parameters of read / write shard logs are the same. In this embodiment, the steps for parameter extraction are described by taking the extraction of the first shard log (hereinafter referred to as read shard log 1) as an example:

[0083] A1. Extract all chunksizes of read shard log 1, obtain the ratio of each chunksize, round the obtained percentage to get an integer ratio, and the sum of the whole ratio should be an integer of 100. Therefore, a check will be performed for flexible filling when setting the last ratio.

[0084] A2. Extract all the accessed data of read shard log 1, which is equal to the sum of all chunksizes multiplied by the minimum sector size (usually defaulted to 512 bytes).

[0085] A3. Extract the starting lba + chunksize of read shard log 1, sort the extracted starting lbas in ascending order, traverse this sorted combination. If the difference between the current lba and the adjacent right - hand lba is less than the chunksize corresponding to the current lba, it is determined that these two lbas are in the continuous set; otherwise, the current lba is in the random set. If it is determined that the current lba and the next lba are continuous, then naturally the next lba is in the continuous set, and the previous random or sequential lba screening steps will not be performed again. After traversing all the sequential lbas in this way, the first lba in the sequential / random set is marked as the starting lba sequential / random. Divide the number of lbas in the set by the total number of lbas to obtain the sequential read and random read ratios. Finally, insert the above - obtained parameters into the elastic database according to the column headers of: shard log serial number, data access type, chunksize ratio, starting lba, and access data volume size. For example, the following results are obtained:

[0086] Get a set of a list (variable type in python) in the following format:

[0087] "ket : reslut" (this line is a comment)

[0089] "1: Random read command of shard log 1"

[0090] "1: Random write command of shard log 1"

[0091] "2: Random write command of shard log 2"

[0092] "2: Sequential read command of shard log 2" ...

[0093] ​"n: Sharded log n xxx"

[0095] In actual application scenarios, the above steps can be implemented through a data analysis module. Among them, the preset time interval can be adjusted according to actual needs. In this embodiment, 10 minutes is used as the interval because: 10 minutes of test time is usually sufficient for the system to enter a stable running state, and 10 minutes has the effect of smoothing short-term fluctuations; at the same time, it can simulate the parameter changes of reading and writing in time as much as possible, and 10 minutes is the smallest time period for the data to have stability, representativeness, and analyzability. Therefore, it is carried out according to 10 minutes.

[0096] S3. Convert all log command groups in the log command group set into test commands to obtain a test command set; for example, implement test command and task distribution based on a multi-task distribution module, as Figure 2 shown, the host computer can accurately control the platform to be tested through the ADB (Android Debug Bridge) interface + device serial number, for example, for the Android platform; it will combine the FIO benchmark performance test tool and the extracted parameters to form a new test command to simulate the user's operation; among them, the command line execution method in this embodiment depends on the selected FIO test tool and has nothing to do with the platform; the test commands are all the same, but Android ADB can only control Android devices. If the HarmonyOS is compatible with this protocol, the platform can also be replaced with the HarmonyOS, but IOS is not compatible with this protocol, so IOS system devices cannot be tested; the specific steps are as follows:

[0097] S31. Read each test parameter in the target log command group shard. Specifically, for example, by polling the deviceid list, push the FIO test tool to the / DATA / TEST directory of each Android environment and classify it according to time and access type; then read the elastic database and read the test parameters of each row in sequence according to the sharded log serial number size.

[0098] S32. Combine the test parameters into sharded test commands through the test tool. Specifically: combine each line of data into a test command, randomly select other necessary parameters for the FIO test, the running time in each test command parameter is 10 minutes, and the performance results are recorded once every 1 second, and each command is run in the Android background in sequence.

[0099] ​S4. Sequentially send the test commands in the test command set to at least one device under test, instructing the device under test to complete the test. Among them, it is necessary to sequentially send the test commands corresponding to each shard of the log command group to at least one device under test according to a preset time interval. By judging whether the shard serial number corresponding to the current target log command group is the same as the shard serial number corresponding to the previous log command group, if so, send the target log command group; if not, send the target log command group after reaching the preset time interval. When sending, send the shard test command to at least one device under test through the debug bridge command line interface, poll the device serial number list and the elastic database, and download the combined commands to each test device in the manner of step S3. If the original data shard log serial number of the current command is the same as that of the previous command, the current command will be sent immediately; otherwise, it will wait for 10 minutes until all test commands are sent.

[0100] According to the set of lists in step S3, each new command is appended to the last line. When finally executing the commands, it will traverse line by line from the first line. After the first line is executed, immediately judge whether the key (i.e., the shard log serial number) of the second line is the same as that of the first line. If so, immediately execute the next line. If not, it will wait for 10 minutes and then execute the next command and make the same key judgment. Since the test time for each command is ten minutes, it is ensured that all commands in each shard are executed before testing the next shard log command.

[0101] S5. Store the test results in a fixed directory and draw a performance curve graph according to the test results. For example, mark the result file of each test command with the shard log serial number and retain the test results in the / data / results directory. For example, the following results are finally placed in the / data / results directory:

[0102] Randread_1

[0103] Randwrite_1

[0104] Ramdwrite_2

[0105] Seqwrite_2

[0106] The label of the suffix represents the label of the command set sharded log; if it is necessary to extract all the randwrite test results, they can be read in ascending order according to the numbers, so as to reflect the change trend of the ranwrite performance on the time axis. Among them, the steps of drawing the results for each device are the same, as follows: Extract the test result files from the / data / results directory, filter out the Bandwidth of each second according to the serial number of the result files, and obtain the performance change trend chart during the entire test period according to the time dimension.

[0107] Embodiment 2

[0108] Please refer to Figure 3 , a memory performance test device, including:

[0109] An acquisition module, configured to acquire a function script selected by a user, control a first device to perform user simulation operations according to the function script, and collect system debugging logs;

[0110] An analysis module, configured to analyze the system debugging logs to obtain a set of log command groups;

[0111] A conversion module, configured to convert all the log command groups in the set of log command groups into test commands to obtain a set of test commands;

[0112] A sending module, configured to sequentially send the test commands in the set of test commands to at least one device to be tested, and instruct the device to be tested to complete the test.

[0113] Embodiment 3

[0114] A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each step of the memory performance test method as in Embodiment 1 is implemented;

[0115] Please refer to Figure 4 , the computer program can be divided into a sampling module, a data analysis module, a multi-task distribution module, and a result drawing module according to the execution content; as Figure 2As shown in the figure, the host computer is connected to different test devices and sampling devices. The device ID sets of the sampling devices and test devices are filled in the ini file respectively, and each device is precisely controlled according to the adb command. A storage product for pre-simulation testing is placed in the sampling device. Different storage products or different operating systems can be used in the test device to finally compare whether there are obvious differences in performance among different operating systems and different storage products. The host computer is the core of the entire architecture, completing the interaction between the user, devices, and data. It interacts with the Android UI through the uiautomator2 library. After the user checks the corresponding simulation script and clicks run, the logic will be directly triggered to run. After the operation is completed, a prompt window will pop up. After confirmation, click view results to jump to the default path to view the performance curve graph.

[0116] The sampling module is used to: receive the simulation requirements selected by the user, automatically execute the simulation script, and generate system debug logs. The simulation script is integrated in the Unitest framework (a framework for organizing and executing test cases). The Android system debug log switch (an internal debug command) will be defaultly turned on before the test starts. When there is no script in the queue, that is, when all scripts are executed, the Android system debug log switch will be automatically turned off, and finally a system debug log will be generated.

[0117] The data analysis module is used to: automatically analyze the system debug logs, obtain the parameters of each test command in the time dimension and store them in the database. Specifically:

[0118] 1. The program automatically extracts the debug logs from the sampling device; as Figure 5 shown, the following steps take Figure 5 as an example for data analysis.

[0119] 2. Data analysis:

[0120] For line 16 and line 18, one is the start flag (issue), and the other is the end flag (complete). And the startlba and chunksize of the two command lines are the same. Such commands form a complete command group. All command groups are filtered out from the entire log; a complete command group is recombined into a new log according to the start timestamp, end timestamp, read (R) or write (W) access type, starting lba, and chunksize size. At the same time, for incomplete command groups, the start timestamp or end timestamp is filled according to the start or end flag. Sort according to the start timestamp. If there is no start timestamp, sort according to the end timestamp. The sorted combined log is as Figure 6 shown; then the logs without start timestamps are deleted.

[0121] 2.1. Divide the sorted logs into multiple shard logs at 10-minute intervals according to the start timestamp, and perform the same test parameter extraction operation on each shard log in turn. Among them, Figure 6 The time period of Figure 6 is within a 10-minute time period, and

[0122] 2.2. Divide the shard logs into read shard logs and write shard logs according to the access data type. The read shard logs are as Figure 7 shown.

[0123] 2.2.1. The chunksize ratio is: 8 / 25:64 / 25:88 / 25:120 / 25. Round the obtained percentage to get an integer ratio. The sum of the whole ratio should be an integer of 100. Therefore, verification and flexible filling will be performed when setting the last ratio.

[0124] 2.2.2. The total access data size: the sum of chunksize * the minimum sector size (usually default is 512 bytes) = 143360.

[0125] 2.2.3. Perform data processing according to step A3 in Embodiment 1. The obtained sequential set is (5820256, 5821208, 5821304, 6029160). The combined ratio of the corresponding chunksize and the random lba and sequential lba is 1:0.

[0126] 3. From the above information, it can be seen that in the specific type of shard log 1, there are only random reads and random writes. If there is an access mode that is both random and sequential, the corresponding access data size is equal to the total data size multiplied by the proportion of random and sequential lba. Insert data into the elastic database according to the data as Figure 8 shown.

[0127] The multi-task distribution module is used to: read database information, assemble test commands, and distribute them to multiple test machines. Specifically:

[0128] 1. After completing the test parameter extraction operation, poll and control each test device, and push the test tool of test FIO to the execution directory.

[0129] 2. Extract and read each row from the elastic database, combining test parameters into commands according to the FIO parameter standard. The data access type parameter rw is the data access type; the bssplit parameter is the chunksize ratio; the offset parameter is startlba; the size parameter is the access data size; the runtime parameter is 10m; the status_interval parameter is 1s; and the output parameter is the / data / results directory. The generated result file contains the data access type and shard log sequence number. Other parameters such as ioengine, numjobs, iodepth, and direct are not available in the debug log and are randomly selected from the more common parameter set. After reading a row of data, a new command is formed. This command is then issued to each device via the ADB interface. After issuing the newly combined performance test command, each command is executed in the background, and the shard log sequence number of the current command is recorded. After all test device commands are completed, the next row of data is read to form a new test command. The next command then checks whether the shard log sequence number matches the previous command. If so, it is issued immediately; otherwise, it waits ten minutes before issuing. Commands with the same shard log sequence number are all commands issued within a 10-minute time period. Since they run in the background, they are not blocked. Commands with the same shard log sequence number are all executed simultaneously. The command with the next shard log sequence number is not issued until 10 minutes have passed. This means that all commands with the previous shard log sequence number have been executed. This simulates the read and write operations of users using the app at different times.

[0130] 3. Until all data in the database is read, all commands are issued, and the test equipment is completed.

[0131] The result drawing module is used to collect test results and draw performance curves. Specifically, it reads performance test results from the / data / results directory of each device. Since there will be multiple copies of test results, the test result files can be read with the same access type and shard log sequence number size. 60 test results are obtained per minute, and the average value is taken as the test result for that minute. If there is no access type in a certain time period, the result on the corresponding time axis is 0, and a total of 4 groups of data are obtained: random read, random write, sequential read, and sequential write. Figure 9 As shown, four curves are plotted on the same graph. The x-axis represents different time periods (0, 10...50) in minutes, and the y-axis represents the data size under a certain access mode. Test data is extracted by polling each device in turn.

[0132] Assume that the total test time is 50 minutes, then there are 50 data for each access type. Each data is the mean value of the test performance results per minute. Use pyplot to plot the results and save the results to the execution directory; each device completes the operation in turn until the performance results of all test devices are plotted.

[0133] Embodiment 4

[0134] Please refer to the figure. An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements each step in the memory performance test method of Embodiment 1.

[0135] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc., which can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application.

[0136] The memory can be, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. Among them, the memory is used to store the computer program, and after receiving the execution instruction, the processor can execute the computer program accordingly.

[0137] In summary, the memory performance testing method, device, readable storage medium, and electronic device provided by the present invention can replace manual operation of a mobile phone to simulate the user usage situation, be closer to the actual usage scenario, reduce the testing complexity, reduce labor costs, and at the same time reduce the uncertainty brought by manual testing; in terms of optimizing test command parameters, it can automatically analyze the command parameters in the time dimension from the system debug log, automatically distribute them to multiple devices to be tested for execution, obtain comprehensive performance data through multi-task and multi-distribution operations, and present the test results in the form of pictures, so as to provide developers with a more valuable and intuitive performance report, understand the performance of the product in the real scenarios of various operating systems, and achieve automated dynamic simulation distribution testing.

[0138] In the above embodiments provided by the present application, it should be understood that the disclosed method, device, computer-readable storage medium, and electronic device can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods. For example, multiple components or modules can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces, and the indirect coupling or communication connection of the device or component or module can be in an electrical, mechanical or other form.

[0139] The components described as separate components may or may not be physically separated. The components displayed as components may or may not be physical modules, that is, they can be located in one place, or they can be distributed to multiple network modules. Some or all of the components can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0140] In addition, in each embodiment of the present invention, the various functional modules can be integrated in one processing module, or each component can exist physically alone, or two or more modules can be integrated in one module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules.

[0141] When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0142] It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily all essential to the present invention.

[0143] In the above embodiments, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0144] The above are only the embodiments of the present invention, and do not limit the patent scope of the present invention accordingly. All equivalent transformations made by using the content of the specification and drawings of the present invention, directly or indirectly applied in the relevant technical fields, are equally included in the patent protection scope of the present invention.

Claims

1. A method for testing memory performance, characterized in that, Including: Obtain the function script selected by the user, control the first device to perform user simulation operations according to the function script, and collect system debugging logs; Parse the system debugging logs to obtain a set of log command groups; Convert all the log command groups in the set of log command groups into test commands to obtain a set of test commands; Send the test commands in the set of test commands to at least one device under test in sequence, instructing the device under test to complete the test; The parsing of the system debugging logs to obtain a set of log command groups includes: Form a log command group in a preset form for the command lines with the same key fields in the system debugging logs; The key fields include the starting logical block address and the data size, and the command line includes a start timestamp or an end timestamp; Discard the log command groups without the start timestamp, and sort the non-discarded log command groups according to the start timestamp or end timestamp to obtain the set of log command groups.

2. The memory performance testing method according to claim 1, wherein After obtaining the set of log command groups, it further includes: Slice all the log command groups at a preset time interval according to the start timestamp to obtain sliced log command groups; Sending the test commands in the set of test commands to at least one device under test in sequence includes: Sequentially issue the test commands corresponding to each sliced log command group to at least one device under test according to the preset time interval.

3. The memory performance testing method according to claim 2, wherein After obtaining the sliced log command groups, it includes; Mark different sliced log command groups with different slice sequence numbers; The sequentially issuing the sliced log command groups according to the preset time interval includes: Judge whether the slice sequence number corresponding to the current target log command group is the same as the slice sequence number corresponding to the previous log command group. If so, issue the target log command group; If not, issue the target log command group after reaching the preset time interval.

4. The memory performance testing method according to claim 2, wherein The converting all the log command groups in the set of log command groups into test commands includes: Perform sequential traversal of all logical block addresses starting from the starting logical block address of the log command group, and judge the continuity of adjacent logical block addresses to obtain the continuous quantity and total quantity of the logical block addresses; Obtain the sequential read and random read ratios according to the continuous quantity and total quantity of the logical block addresses; Use the sequential read and random read ratios as test parameters, and convert the test parameters into the test commands.

5. The memory performance testing method according to claim 2, wherein The sequentially issuing the test commands corresponding to each sliced log command group to at least one device under test according to the preset time interval includes: Read each test parameter in the target sliced log command group; Combine the test parameters into sliced test commands through a test tool; Issue the sliced test commands to at least one device under test through the debug bridge command line interface.

6. The memory performance testing method according to claim 5, wherein After issuing the sliced test commands to at least one device under test through the debug bridge command line interface, it further includes: Store the test results in a fixed directory, and draw a performance curve graph according to the test results.

7. A memory performance testing device, characterized in that, Including: An acquisition module, configured to acquire a function script selected by a user, control a first device to perform user simulation operations according to the function script, and collect system debugging logs; A parsing module, configured to parse the system debugging logs to obtain a set of log command groups; A conversion module, configured to convert all the log command groups in the set of log command groups into test commands to obtain a set of test commands; A sending module, configured to sequentially send the test commands in the set of test commands to at least one device to be tested, and instruct the device to be tested to complete the test; The parsing of the system debugging logs to obtain a set of log command groups includes: Forming a log command group in a preset form with command lines having the same key fields in the system debugging logs; The key fields include a starting logical block address and a data size, and the command line includes a start timestamp or an end timestamp; Discarding the log command groups without the start timestamp, and sorting the undiscarded log command groups according to the start timestamp or the end timestamp to obtain the set of log command groups.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements each step of the memory performance test method according to any one of claims 1-6.

9. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements each step in the memory performance test method according to any one of claims 1-6.

Images