Memory performance test method and device, readable storage medium and electronic equipment

Abstract

The invention discloses a memory performance test method and device, a readable storage medium and electronic equipment, and the method comprises the steps: obtaining a function script selected by a user, controlling first equipment to carry out user simulation operation according to the function script, and collecting a system debugging log; analyzing the system debugging log to obtain a log command group set; converting all the log command groups in the log command group set into test commands to obtain a test command set; and sequentially sending the test commands of the test command set to at least one to-be-tested device, and indicating the to-be-tested device to complete the test. The corresponding system debugging log is collected after the user operation is simulated on the first equipment through the function script, the system debugging log is converted into the test command for equipment testing, the test command can be automatically distributed to the corresponding to-be-tested equipment, the labor cost is reduced, meanwhile, the uncertainty caused by manual testing is reduced, and the test efficiency is improved. Therefore, the test efficiency and precision are improved.

Description

Technical Field

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

[0002] At present, the existing test methods for storage device performance usually use benchmark performance test tools for single testing. For example, the existing Android platform benchmark performance test uses tools such as FIO (Flexible I / O Tester) and iozone. The test is performed with specific access mode and specific write data size. The stress scenario test is also completed based on the single increase of different data and access thread number. The test process relies solely on the tester's experience to adjust parameters, and cannot dynamically simulate real-time usage scenarios. In addition, repeated operations are required between different systems, reducing test 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 equipment to improve testing efficiency and accuracy.

[0004] In order to solve the above technical problems, the technical solution adopted by the present invention is: A memory performance testing method, comprising: Obtaining a function script selected by a user, controlling the first device to perform a user simulation operation according to the function script, and collecting a system debugging log; Parsing the system debugging log to obtain a log command group set; Convert all the log command groups in the log command group set into test commands to obtain a test command set; The test commands of the test command set are sent to at least one device to be tested in sequence, instructing the device to be tested to complete the test.

[0005] In order to solve the above technical problems, another technical solution adopted by the present invention is: A memory performance testing device, comprising: an acquisition module, used to acquire a function script selected by a user, control the first device to perform a user simulation operation according to the function script, and collect a system debugging log; A parsing module, used for parsing the system debugging log to obtain a log command group set; A conversion module, used for converting all the log command groups in the log command group set into test commands to obtain a test command set; The sending module is used to send the test commands of the test command set to at least one device to be tested in sequence, and instruct the device to be tested to complete the test.

[0006] In order to solve the above technical problems, another technical solution adopted by the present invention is: A computer-readable storage medium stores a computer program, which implements the various steps of the memory performance testing method as described above when executed by a processor.

[0007] In order to solve the above technical problems, another technical solution adopted by the present invention is: An electronic device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the various steps in the above-mentioned memory performance testing method when executing the computer program.

[0008] The beneficial effects of the present invention are as follows: the operation process and the specific parameters used in the operation process are separated, the operation process is organized into a function script, and the corresponding system debug log is collected after simulating the user operation on the first device through the function script, that is, the specific parameters corresponding to the operation process are obtained by simulating the actual user operation. Compared with directly inputting the specific parameters for testing, the system debug log is converted into a test command for device testing, so that the test command is close to the actual usage scenario; after obtaining the test command set, the test command can be automatically distributed to the corresponding device to be tested, so as to realize the reuse of the test command set, reduce labor costs, and reduce the uncertainty caused by manual testing, thereby improving the test efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A flowchart of a memory performance testing method according to an embodiment of the present invention; Figure 2 A schematic diagram of the overall architecture of a memory performance testing method according to an embodiment of the present invention; Figure 3 is a schematic structural diagram of a memory performance testing device according to an embodiment of the present invention; Figure 4 is another step flow chart of a memory performance testing method according to an embodiment of the present invention; Figure 5 A schematic diagram of key fields of a system log of a memory performance testing method according to an embodiment of the present invention; Figure 6 A schematic diagram of a shard log of a memory performance testing method according to an embodiment of the present invention; Figure 7 A schematic diagram of a shard log reading method for a memory performance test in an embodiment of the present invention; Figure 8 A schematic diagram of a database insertion format of a memory performance testing method according to an embodiment of the present invention; Fig. 9 A schematic diagram of performance results of a memory performance testing method according to an embodiment of the present invention; Fig.10 Schematic diagram of the structure of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION

[0010] In order to explain the technical content, achieved objectives and effects of the present invention in detail, the following is an explanation in conjunction with the implementation modes and the accompanying drawings.

[0011] A memory performance testing method, comprising: Obtaining a function script selected by a user, controlling the first device to perform a user simulation operation according to the function script, and collecting a system debugging log; Parsing the system debugging log to obtain a log command group set; Convert all the log command groups in the log command group set into test commands to obtain a test command set; The test commands of the test command set are sent to at least one device to be tested in sequence, instructing the device to be tested to complete the test.

[0012] From the above description, it can be seen that the beneficial effects of the present invention are: separating the operation process and the specific parameters used in the operation process, organizing the operation process into a function script, and collecting the corresponding system debug log after simulating the user operation on the first device through the function script, that is, obtaining the specific parameters corresponding to the operation process by simulating the actual user operation. Compared with directly entering the specific parameters for testing, the system debug log is converted into a test command for device testing, so that the test command is close to the actual usage scenario; after obtaining the test command set, the test command can be automatically distributed to the corresponding device to be tested, realizing the reuse of the test command set, reducing labor costs, and reducing the uncertainty caused by manual testing, thereby improving test efficiency and accuracy.

[0013] Further, the parsing of the system debug log to obtain a log command group set includes: Combining command lines with the same key fields in the system debugging log into a log command group in a preset form; 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; The log command groups without the start timestamp are discarded, and the log command groups that are not discarded are sorted according to the start timestamp or the end timestamp to obtain the log command group set.

[0014] From the above description, it can be seen that through key field identification, the command lines in the system debug log can be effectively extracted to obtain the log command group; at the same time, since the log command group without a start flag cannot determine the size of the written data, and the start time is not in the system log, it can be ruled out that it is the read and write operation caused by the running of the test script. Therefore, the log command group without a start timestamp is discarded, which can improve the accuracy of subsequent tests.

[0015] Furthermore, after obtaining the log command group set, the step of: Slice all the log command groups at preset time intervals according to the start timestamp to obtain log command group slices; Sending the test commands of the test command set in sequence to at least one device to be tested comprises: The test commands corresponding to each of the log command group fragments are sequentially issued to at least one device to be tested according to the preset time interval.

[0016] From the above description, it can be seen that by sharding all log command groups at preset time intervals and issuing log command group shards at preset time intervals during testing, it is possible to simulate the dynamic issuance of operation commands when users use the device, thereby testing the device in a dynamic simulation distribution manner, which is closer to the actual usage scenario.

[0017] Further, obtaining the log command group fragments includes: Marking different log command group fragments with different fragment sequence numbers; The sending out of the log command group fragments in sequence according to the preset time interval includes: Determine whether the shard sequence number corresponding to the current target log command group is consistent with 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 the preset time interval is reached.

[0018] From the above description, it can be seen that by marking different log command group fragments with different fragment serial numbers, when the log command groups are subsequently issued for testing, it is possible to effectively determine whether adjacent log command groups belong to the same fragment, ensuring that the log command groups in each log command group fragment are tested within the preset time interval.

[0019] Further, converting all the log command groups in the log command group set into test commands includes: Sequentially traverse all logical block addresses starting from the starting logical block address of the log command group, and determine the continuity of adjacent logical block addresses to obtain the continuous number and total number of the logical block addresses; Obtaining a sequential read and random read ratio according to the continuous number and total number of the logical block addresses; The sequential read and random read ratio is used as a test parameter, and the test parameter is converted into the test command.

[0020] From the above description, it can be seen that by traversing the logical block addresses of the log command group and obtaining continuous logical block addresses through continuity judgment, the sequential read and random read ratio can be obtained, thereby realizing the extraction of the sequential read and random read ratio.

[0021] Further, the sending of the test commands corresponding to each of the log command group fragments to at least one device to be tested in sequence according to the preset time interval includes: Read each test parameter in the target log command group shard; Combining the test parameters into slice test commands by a test tool; The slice test command is sent to at least one device to be tested through the debug bridge command line interface.

[0022] From the above description, it can be seen that after the test parameters are combined into shard test commands through the test tool, the shard test commands are sent to each device to be tested based on the debug bridge command line interface. For example, based on the Android debug bridge, the Android device can be controlled, thereby completing the test of the Android device.

[0023] Further, after sending the slicing test command to at least one device to be tested through the debug bridge command line interface, the method further includes: The test results are stored in a fixed directory, and a performance curve diagram is drawn based on the test results.

[0024] From the above description, it can be seen that by drawing a performance curve chart based on the test results and presenting the test results in a graphical form, it is possible to provide developers with a more valuable and intuitive performance report, which is helpful for understanding the performance of the product in real scenarios of various operating systems.

[0025] Another embodiment of the present invention provides a memory performance testing device, comprising: an acquisition module, used to acquire a function script selected by a user, control the first device to perform a user simulation operation according to the function script, and collect a system debugging log; A parsing module, used for parsing the system debugging log to obtain a log command group set; A conversion module, used for converting all the log command groups in the log command group set into test commands to obtain a test command set; The sending module is used to send the test commands of the test command set to at least one device to be tested in sequence, and instruct the device to be tested to complete the test.

[0026] Another embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program implements the steps of the memory performance testing method as described above.

[0027] Another embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the above-mentioned memory performance testing method when executing the computer program.

[0028] The memory performance testing method, device, readable storage medium and electronic device provided by the present invention can be applied to the testing scenario of solid-state memory firmware algorithm, which is described below through specific implementation methods: Embodiment 1 Please refer to Figure 1 , a memory performance testing method, comprising: S1. Obtain a 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 clicking the screen for a long time, and collect system debugging logs after executing the corresponding operations.

[0029] For example, in actual applications, the above steps can be implemented based on the sampling module. Specifically, first turn on the debug log switch, and the user selects and runs a pre-written python script that simulates 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 user automated operations. After all simulation scripts are executed, turn off the debug log switch. At the same time, the sampling module can use machine learning to learn and train users to read and write data collected. After the user simulates the specified operation method, the system debug log can be quickly generated, reducing the amount of script development, and different data combinations can be enriched without relying on the physical platform.

[0030] S2. Parse the system debug log to obtain a set of log command groups; for example, pull the system debug log from the directory specified by the sampled Android platform. Each debug 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.

[0031] S21, the command lines with the same key fields in the system debug log are formed into a log command group in a preset form; for example, in two debug logs, one log command flag is the start, the other command flag is the end, and the start log timestamp is less than the end log timestamp, and the starting lba+chunksize is consistent, and these two debug logs form a complete log command group. All command groups are screened 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 size. Among them, the log command group set exists and 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.

[0032] S22, discard the log command group without the start timestamp, and sort the log command group that is not discarded according to the start timestamp or the end timestamp to obtain a log command group set. Since this part of the command group cannot determine the start time point of the command issuance, it is necessary to discard it because it is impossible to determine whether the write data size and the start time are within the preset test time; the reason why the command group without the end timestamp is not discarded is that all test parameters can be extracted from the start command, but the possible problem is that the command write time is very long, and the system log intercepted by the system within the preset time period does not get the end command, but it can be shown that this operation occurred at this time, but the write time is shortened, but the write data size and other methods are not changed. It is equivalent to increasing the pressure of reading and writing in disguise, and it tests the performance of the storage device. However, if it is discarded, it is equivalent to reducing this part of the operation, which has a certain deviation from the actual simulation operation, and it is more desirable to test it in a harsh environment. Then the combined log is sorted according to the start timestamp to obtain a sorted combined log.

[0033] S23. Slice all log command groups at preset time intervals according to 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 a time interval of ten minutes, multiple shard logs are obtained and then the logs are parsed to extract the read and write data size and chunksize ratio distribution of sequential read, sequential write, random read, and random write within each ten minutes and the range of lba, convert the extracted test parameters into shard test commands, set the test duration of each command to 10 minutes, and append them to the command set. The specific steps are as follows: Among them, the steps for extracting test parameters from multiple shard logs are consistent. At the same time, shard logs are classified into: read shard logs and write shard logs according to read or write commands. The detailed test parameter extraction methods for read / write shard logs are consistent. This embodiment extracts the first shard log (hereinafter referred to as read shard log 1) to describe the parameter extraction steps: A1. Extract all chunksizes of read shard log 1, obtain the ratio of each chunksize, and round the obtained percentage to an integer ratio. The total ratio needs to be an integer of 100, so verification will be performed for flexible padding when setting the last ratio.

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

[0035] A3. Extract the starting lba+chunksize of the read shard log 1, and sort the extracted starting lba in sequence. Traverse this sequential sorting combination. If the difference between the current lba and the adjacent right lba is less than the chunksize corresponding to the current lba, then the two lba are considered to be 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 the next lba is naturally in the continuous set, and the aforementioned random or sequential lba screening steps will not be performed. Follow this step to traverse all sequential lba, and the first lba in the sequential / random set is marked as the starting lba sequential / random. Divide the number of lba in the set by the total number of lba to get the ratio of sequential reads to random reads. Finally, insert the above-obtained parameters into the elastic database according to the column headers of: shard log sequence number, data access type, chunksize ratio, starting lba, and access data size. For example, the following results are obtained: Get a list (variable type in Python) collection in the following format: "ket : reslut" (this line is a comment) [ "1: Shard log 1 random read command" "1: Shard log 1 random write command" "2: Shard log 2 random write command" "2: Shard log 2 sequential read command" ... “n: Shard log n xxx” ] In actual application scenarios, the above steps can be implemented through the data analysis module. Among them, the preset time interval can be adjusted according to actual needs. This embodiment uses 10 minutes as the interval because: 10 minutes of test time is usually enough for the system to enter a stable operating 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 minimum time period for data to be stable, representative and analyzable. Therefore, it is carried out according to 10 minutes.

[0036] 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 commands and task distribution based on a multi-task distribution module, such as Figure 2 As shown, the host computer can accurately control the platform to be tested, such as the Android platform, through the ADB (Android Debug Bridge) interface + device serial number; the FIO benchmark performance test tool plus the extraction parameters are combined into a new test command to simulate the user's operation; wherein, 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 the same, but Android ADB can only control Android devices. If the Hongmeng system is compatible with this protocol, it can also be executed to replace the platform with the Hongmeng system, but IOS is not compatible with this protocol, and it is impossible to test the IOS system device; the specific steps are as follows: 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 them by time and access type; then read the elastic database and read the test parameters of each row in sequence according to the shard log sequence number size.

[0037] S32. Combine the test parameters into fragmented test commands through the test tool. Specifically, combine each row of data into a test command, randomly select the necessary parameters for other FIO tests, the running time in each test command parameter is 10 minutes, and the performance result is recorded every 1 second. Run each command in the Android background in turn.

[0038] S4. Send the test commands of the test command set to at least one device to be tested in sequence, instructing the device to be tested to complete the test; wherein, it is necessary to send the test commands corresponding to each log command group fragment to at least one device to be tested in sequence according to the preset time interval; by judging whether the fragment sequence number corresponding to the current target log command group is consistent with the fragment sequence 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 the preset time interval is reached, when sending: send the fragment test command to at least one device to be tested through the debug bridge command line interface, by polling the device serial number list and the elastic database, and sending the combined command to each test device in the manner of step S3, if the original data fragment log sequence number of the current command is consistent with the original data fragment log sequence number of the previous command, the current command will be sent immediately, otherwise it will wait for 10 minutes until all the test commands are sent.

[0039] According to the list set in step S3, each new command is appended to the last line. When the command is executed at the end, it will be traversed from the first line downwards. After the first line is executed, it will immediately determine whether the key (i.e., the shard log sequence number) of the second line is the same as the first line. If they are the same, the next line will be executed immediately. If they are not consistent, it will wait for 10 minutes before executing the next command and then make the same key judgment. Since the test time for each command is ten minutes, it will ensure that all commands in each shard are executed before testing the next shard log command.

[0040] S5. Store the test results in a fixed directory and draw a performance curve based on the test results. For example, mark the result file of each test command with the shard log sequence number and keep the test results in the / data / results directory. For example, the final result in the / data / results directory includes the following results: Randread_1 Randwrite_1 Ramdwrite_2 Seqwrite_2 The suffix number indicates the number of the command set shard log; if you need to extract all the randwrite test results, you can read them from small to large numbers, so as to reflect the performance change trend of ranwrite performance on the time axis. The steps for drawing results for each device are the same, as follows: extract the test result file from the / data / results directory, filter out the bandwidth of each second according to the serial number size of the result file, and obtain the performance change trend chart during the entire test period according to the time dimension.

[0041] Embodiment 2 Please refer to Figure 3 , a memory performance testing device, comprising: An acquisition module, used to acquire a function script selected by a user, control the first device to perform a user simulation operation according to the function script, and collect a system debugging log; A parsing module is used to parse the system debugging log and obtain a log command group set; A conversion module, used for converting all log command groups in the log command group set into test commands to obtain a test command set; The sending module is used to send the test commands of the test command set to at least one device to be tested in sequence, and instruct the device to be tested to complete the test.

[0042] Embodiment 3 A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, each step of the memory performance testing method according to the first embodiment is implemented; Please refer to Figure 4 ,Computer programs can be divided into sampling modules, data analysis modules, multi-task distribution modules and result drawing modules according to the ,execution content; Figure 2 As shown in the figure, the host computer is connected to different test devices and sampling devices. The deviceid collections of the sampling devices and test devices are filled in the ini file respectively, and each device is accurately controlled according to the adb command; the storage products pre-simulated and tested are placed in the sampling device; different storage products or different operating systems can be used in the test device to compare whether there are obvious differences in performance between different operating systems and different storage products; the host computer is the core of the entire architecture, completing the interaction between users, devices and data. Through the uiautomator2 library to interact with the Android UI, after the user checks the corresponding simulation script, clicking run will directly trigger the logic operation. 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.

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

[0044] The data analysis module is used to automatically analyze the system debugging log, obtain the parameters of each test command in the time dimension and store them in the database. Specifically: 1. The program automatically extracts the debug log from the sampling device; Figure 5 As shown, the following steps are Figure 5 Take this as an example for data analysis.

[0045] 2. Data analysis: Line 16 and line 18, one is the start flag (issue), the other is the end flag (complete), and the startlba and chunksize of the two command lines are the same. Such commands become a complete command group, and all command groups are filtered out from the entire log; a complete command group is reassembled into a new log according to the start timestamp, end timestamp, read (R) or write (W) access type, start lba, and chunksize; at the same time, an incomplete command group is filled with the start timestamp or end timestamp according to the start or end flag. Sort by the start timestamp, if there is no start timestamp, sort by the end timestamp, and the resulting sorted combined log is as follows Figure 6 as shown; logs without a start timestamp are then deleted.

[0046] 2.1. Divide the sorted log into multiple shard logs at 10-minute intervals based on the start timestamp, and perform the same test parameter extraction operation on each shard log in turn; Figure 6 The time period is within a 10-minute period. Figure 6 Give an example.

[0047] 2.2. According to the access data type, it is divided into read shard log and write shard log. Read shard log is as follows: Figure 7 shown.

[0048] 2.2.1. The chunksize ratio is 8 / 25:64 / 25:88 / 25:120 / 25. The obtained percentage is rounded to an integer ratio. The total ratio needs to be an integer of 100, so a check will be performed when setting the last ratio for flexible filling.

[0049] 2.2.2. Total access data size: sum of chunksizes * minimum sector size (usually 512 bytes by default) = 143360.

[0050] 2.2.3. Data processing is performed according to step A3 in Example 1 to obtain a sequence set of (5820256, 5821208, 5821304, 6029160), combined with the corresponding chunksize and the ratio of random lba to sequential lba being 1:0.

[0051] 3. From the above information, we can see that the specific types of shard log 1 only include random read and random write. If there is both random and sequential access mode, the corresponding access data size is equal to the total data size multiplied by the random and sequential LBA ratios. Figure 8 The data shown is inserted into the elastic database.

[0052] The multi-task distribution module is used to read database information, assemble test commands, and distribute them to multiple test machines. Specifically: 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.

[0053] 2. Extract and read each row from the elastic database in sequence, and combine the test parameters according to the FIO parameter standard. The data access type rw parameter 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; the output parameter is the / data / results directory, and the generated result file will carry the data access type and the shard log sequence number; some other parameters such as ioengine, numjobs, iodepth, and direct cannot be obtained from the debug log, and will be randomly selected from the more common parameter set; that is, after reading a row of data, a new command will be formed; after forming a command, it will be issued to each device through the adb interface. After issuing the new combination of performance test commands, each command will be executed in the background, and the shard log sequence number of the current command will be recorded; after all test device commands are completed, the next row of data will be read to form a new test command. After that, the new next command will determine whether the shard log sequence number is consistent with the previous command. If it is consistent, it will be issued immediately, otherwise it will wait for ten minutes before issuing it. The commands with the same shard log sequence number are all commands issued within a 10-minute time period. Since they are run in the background, they will not be blocked. Commands with the same shard log sequence number will run at the same time. The command with the next shard log sequence number will be issued after waiting for 10 minutes, that is, 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 in terms of time period.

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

[0055] 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. There are 60 test results 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. Fig. 9 As shown, four curves are drawn on the same picture. The x-axis is (0,10...50) representing different time periods in min, and the y-axis is the data size under a certain access mode. Each device is polled in turn to extract the test data.

[0056] Assuming the test lasts 50 minutes in total, there are 50 data points for each access type. Each data point is the average of the test performance results per minute. The results are plotted using pyplot and saved in the execution directory. Each device completes the operation in turn until the performance results of all test devices are plotted.

[0057] Embodiment 4 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, each step in the memory performance testing method of the first embodiment is implemented.

[0058] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including 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 at least one of other programmable logic devices, discrete gates 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 methods, steps, and logic block diagrams disclosed in the embodiments of the present application.

[0059] The memory may 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 electric erasable programmable read-only memory (EEPROM), etc. The memory is used to store a computer program, and the processor may execute the computer program accordingly after receiving an execution instruction.

[0060] In summary, the memory performance testing method, device, readable storage medium and electronic device provided by the present invention can replace manual operation of mobile phones to simulate user usage, which is closer to actual usage scenarios, reduces test complexity, reduces labor costs, and reduces the uncertainty brought by manual testing; from the perspective of test command parameter tuning, the command parameters in the time dimension can be automatically analyzed from the system debug log, and automatically distributed to multiple machines to be tested for execution. Comprehensive performance data is obtained through multi-tasking and multi-distribution operations, and the test results are presented in the form of pictures, thereby providing developers with more valuable reference and more intuitive performance reports, understanding the performance of products in real scenarios of various operating systems, and realizing automated dynamic simulation distribution testing.

[0061] In the above embodiments provided in the present application, it should be understood that the disclosed methods, devices, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or components or modules, which can be electrical, mechanical or other forms.

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

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

[0064] If the integrated module is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this 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, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0065] It should be noted that, for the convenience of description, the aforementioned method embodiments are all described as a series of action combinations, but those skilled in the art should be aware 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 be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0066] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0067] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the present invention's specification and drawings, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A memory performance testing method, characterized in that: include: Obtaining a function script selected by a user, controlling the first device to perform a user simulation operation according to the function script, and collecting a system debugging log; Parsing the system debugging log to obtain a log command group set; Convert all the log command groups in the log command group set into test commands to obtain a test command set; The test commands of the test command set are sent to at least one device to be tested in sequence, instructing the device to be tested to complete the test.

2. The memory performance testing method according to claim 1, characterized in that: The system debugging log is parsed to obtain a log command group set including: Combining command lines with the same key fields in the system debugging log into a log command group in a preset form; 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; The log command groups without the start timestamp are discarded, and the log command groups that are not discarded are sorted according to the start timestamp or the end timestamp to obtain the log command group set.

3. The memory performance testing method according to claim 2, characterized in that: The step of obtaining the log command group set further includes: Slice all the log command groups at preset time intervals according to the start timestamp to obtain log command group slices; Sending the test commands of the test command set in sequence to at least one device to be tested comprises: The test commands corresponding to each of the log command group fragments are sequentially issued to at least one device to be tested according to the preset time interval.

4. The memory performance testing method according to claim 3, characterized in that: The obtaining of the log command group fragments includes: Marking different log command group fragments with different fragment sequence numbers; The sending out of the log command group fragments in sequence according to the preset time interval includes: Determine whether the shard sequence number corresponding to the current target log command group is consistent with the shard sequence number corresponding to the previous log command group. If so, issue the target log command group; If not, the target log command group is issued after the preset time interval is reached.

5. The memory performance testing method according to claim 3, characterized in that: The converting all the log command groups in the log command group set into test commands comprises: Sequentially traverse all logical block addresses starting from the starting logical block address of the log command group, and determine the continuity of adjacent logical block addresses to obtain the continuous number and total number of the logical block addresses; Obtaining a sequential read and random read ratio according to the continuous number and total number of the logical block addresses; The sequential read and random read ratio is used as a test parameter, and the test parameter is converted into the test command.

6. The memory performance testing method according to claim 3, characterized in that: The sending of the test commands corresponding to each of the log command group fragments to at least one device to be tested in sequence according to the preset time interval includes: Read each test parameter in the target log command group shard; Combining the test parameters into slice test commands by a test tool; The slice test command is sent to at least one device to be tested through the debug bridge command line interface.

7. The memory performance testing method according to claim 6, characterized in that: After sending the slicing test command to at least one device to be tested through the debug bridge command line interface, the following step further includes: The test results are stored in a fixed directory, and a performance curve diagram is drawn based on the test results.

8. A memory performance testing device, characterized in that: include: an acquisition module, used to acquire a function script selected by a user, control the first device to perform a user simulation operation according to the function script, and collect a system debugging log; A parsing module, used for parsing the system debugging log to obtain a log command group set; A conversion module, used for converting all the log command groups in the log command group set into test commands to obtain a test command set; The sending module is used to send the test commands of the test command set to at least one device to be tested in sequence, and instruct the device to be tested to complete the test.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the memory performance testing method as described in any one of claims 1 to 7 is implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the processor implements the various steps in the memory performance testing method as described in any one of claims 1 to 7.

Images