An automatic testing method and system for storage performance of an android device

Abstract

This application discloses an automated testing method and system for the storage performance of Android devices. The Android device has a storage performance testing application installed and establishes a communication connection with a test terminal via an Android debugging bridge. In this method, after launching the storage performance testing application on the Android device, a corresponding automated operation route is selected based on a preset test scenario to perform test operations on the storage performance testing application. Subsequently, the test result data output by the storage performance testing application is collected, and then the test result data is saved to the test terminal. This application's embodiment, by deploying the test application locally on the Android device and establishing communication via an Android debugging bridge, can eliminate dependence on servers, simplify the porting and debugging process across different devices or environments, and achieve standardized automated storage testing based on preset test scenarios, completing the collection and retention of test result data.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of Android device testing technology, and in particular to an automated testing method and system for the storage performance of Android devices. Background Technology

[0002] Existing mobile application automation testing frameworks (such as Appium) rely on server-based script deployment. Server downtime, network fluctuations, or port allocation conflicts can directly impact the normal progress of automated testing, leading to interruptions or errors. Furthermore, their porting process is complex, requiring reconfiguration of dependent component port mappings and other environmental parameters for different devices or environments, often consuming significant time for debugging to ensure the automation scripts function correctly. Summary of the Invention

[0003] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0004] This application provides an automated testing method and system for the storage performance of Android devices, which eliminates server dependence while ensuring stable testing, simplifies the porting and debugging process, and realizes standard automated storage testing and test data retention for Android devices.

[0005] This application provides an automated testing method for the storage performance of an Android device. The Android device has a storage performance testing application installed, and the Android device establishes a communication connection with a test terminal through an Android debugging bridge. The method includes: launching the storage performance testing application on the Android device; selecting a corresponding automated operation route to perform test operations on the storage performance testing application based on a preset test scenario; collecting test result data output by the storage performance testing application; and saving the test result data to the test terminal.

[0006] In one embodiment of this application, the automated operation route includes a component identification-driven route and a coordinate positioning-driven route. Selecting the corresponding automated operation route to perform test operations on the storage performance testing application includes: using the component identification-driven route, calling the Android automated testing framework to obtain the front-end component identifier of the storage performance testing application, locating the target test button according to the front-end component identifier and performing a simulated click operation to trigger and execute the storage performance testing operation; using the coordinate positioning-driven route, obtaining the coordinate information of the target test button of the storage performance testing application on the screen, and performing a simulated click operation on the position corresponding to the coordinate information through input commands from the Android debug bridge to trigger and execute the storage performance testing operation.

[0007] In one embodiment of this application, obtaining the front-end component identifier of the storage performance testing application includes: initializing the connection between the test terminal and the Android automated testing framework of the Android device; reading the interface component layout information of the storage performance testing application; and extracting the identifier information corresponding to the target test button from the interface component layout information as the front-end component identifier.

[0008] In one embodiment of this application, when using a component identification-driven approach to collect test result data output by the storage performance testing application, the process includes: detecting whether the result display component of the storage performance testing application has been fully loaded; if the result display component is detected to be fully loaded, obtaining the text information of the result display component; and extracting storage performance test data from the text information to obtain test result data.

[0009] In one embodiment of this application, after collecting the test result data, the method further includes: taking a screenshot of the result display interface of the storage performance test application and saving the first screenshot file to the Android device; and sending the first screenshot file from the Android device to the test terminal through the Android debugging bridge.

[0010] In one embodiment of this application, obtaining the coordinate information of the target test button of the storage performance testing application on the screen includes: clicking the target test button of the storage performance testing application, reading the touch coordinates displayed on the screen, and using the touch coordinates as the coordinate information of the target test button.

[0011] In one embodiment of this application, when using coordinate positioning to drive the route, the test result data output by the storage performance testing application is collected, including: monitoring whether the storage performance test of the storage performance testing application is completed; if the test is completed, performing a screenshot operation on the result display interface of the storage performance testing application and saving the second screenshot file to the Android device; sending the second screenshot file from the Android device to the test terminal through the Android debugging bridge; parsing the second screenshot file, extracting the storage performance test data, and obtaining the test result data.

[0012] In one embodiment of this application, before parsing the second screenshot file, the method further includes: cropping the screenshot file to obtain a screenshot file containing only test results; and binarizing and denoising the screenshot file containing only test results to obtain an optimized screenshot file.

[0013] In one embodiment of this application, saving the test result data to the test terminal includes: creating a data table, the data table containing test items, test results, and test time fields; filling the test result data and corresponding test items and test times into the data table; detecting whether a saved storage performance test table file exists in the test terminal; if it exists, filling the saved storage performance test table file with the content of the data table; if it does not exist, creating a new table file and filling the table file with the content of the data table.

[0014] On the other hand, embodiments of this application provide an automated testing system for the storage performance of an Android device, including a test terminal and an Android device. The Android device has a storage performance testing application installed, and the Android device and the test terminal are connected via an Android debug bridge. The test terminal includes a processor and a memory, and the memory stores multiple instructions, which are adapted to be loaded and executed by the processor using the aforementioned automated testing method for the storage performance of the Android device.

[0015] This application provides an automated testing method and system for Android device storage performance. The Android device has a storage performance testing application installed and establishes a communication connection with a test terminal via an Android debugging bridge. In this method, after launching the storage performance testing application on the Android device, a corresponding automated operation route is selected based on a preset test scenario to perform test operations on the storage performance testing application. Subsequently, the test result data output by the storage performance testing application is collected and then saved to the test terminal. This application, by deploying the test application locally on the Android device and establishing communication via an Android debugging bridge, can eliminate dependence on servers, avoid interference from server-related failures, simplify the porting and debugging process across different devices or environments, and achieve standardized automated storage testing based on preset test scenarios. It also completes the collection and retention of test result data, forming a highly compatible automated storage testing implementation path. Attached Figure Description

[0016] Figure 1 This is a flowchart of an automated testing method for the storage performance of Android devices provided in an embodiment of this application; Figure 2 This is a flowchart of obtaining the front-end component identifier provided in an embodiment of this application; Figure 3 This is provided by the embodiments of this application. Figure 1 The detailed flowchart of step 140; Figure 4 This is a flowchart of an automated test process for the storage performance of an Android device provided in an embodiment of this application. Detailed Implementation

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

[0018] It should be noted that although the flowchart shows a logical order, in some cases, the steps shown or described may be performed in a different order than that shown in the flowchart. The terms "first," "second," etc., used in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the structures, proportions, sizes, etc., depicted in the drawings are only used to complement the content disclosed in the specification for those skilled in the art to understand and read, and are not intended to limit the implementation conditions of this application. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in proportions, or adjustments to size, without affecting the effects and purposes achieved by this application, should still fall within the scope of the technical content disclosed in this application. Similarly, the terms such as "upper," "lower," "left," "right," "middle," and "one" used in this specification are only for clarity of description and are not used to limit the scope of implementation of this application. Changes or adjustments in their relative relationships, without substantially altering the technical content, should also be considered within the scope of implementation of this application.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] Existing mobile application automation testing frameworks (such as Appium) rely on server-based script deployment. Server downtime, network fluctuations, or port allocation conflicts can directly impact the normal progress of automated testing, leading to interruptions or errors. Furthermore, their porting process is complex, requiring reconfiguration of dependent component port mappings and other environmental parameters for different devices or environments, often consuming significant time for debugging to ensure the automation scripts function correctly.

[0021] In view of this, this application provides an automated testing method and system for Android device storage performance, wherein the Android device has a storage performance testing application installed and establishes a communication connection with the test terminal through an Android debugging bridge. In this method, after starting the storage performance testing application on the Android device, based on a preset test scenario, a corresponding automated operation route is selected to perform test operations on the storage performance testing application. Subsequently, the test result data output by the storage performance testing application is collected, and then the test result data is saved to the test terminal. This application, by deploying the test application locally on the Android device and establishing communication through an Android debugging bridge, can eliminate dependence on servers, avoid interference from server-related failures, simplify the porting and debugging process for different devices or environments, and achieve standardized automated storage testing based on preset test scenarios, completing the collection and retention of test result data, forming a highly compatible automated storage testing implementation path.

[0022] The embodiments of this application will be further described below with reference to the accompanying drawings.

[0023] Reference Figure 1 , Figure 1 This is a flowchart of an automated testing method for the storage performance of an Android device provided in an embodiment of this application. The Android device has a storage performance testing application installed and establishes a communication connection with the test terminal via an Android debugging bridge. This process may specifically include, but is not limited to, steps 110 to 140.

[0024] Step 110: Launch the storage performance test application on the Android device; Step 120: Based on the preset test scenario, select the corresponding automated operation route to perform test operations on the storage performance test application; Step 130: Collect test result data output by the storage performance test application; Step 140: Save the test result data to the test terminal.

[0025] Steps 110 to 140 will be described in detail below.

[0026] In one feasible embodiment, in step 110, storage performance testing applications such as AnTuTu and Androbench are typically used on the Android device to perform storage tests and record storage read and write speeds. Once the Android device establishes a communication connection with the test terminal through the Android debug bridge, the two can perform relevant data transmission and various command interactions.

[0027] In a feasible embodiment, step 120 includes an automated operation route comprising a component identification-driven route and a coordinate positioning-driven route. When selecting an automated operation route based on the test scenario, if the test scenario is for an AnTuTu application, the component identification-driven route can be selected to perform test operations on that application; if the test scenario is for an Androbench application, the coordinate positioning-driven route can be selected to perform test operations on that application. It is understood that different test applications often correspond to different functional modules and test logic. Selecting an appropriate test scenario based on application characteristics can make the testing process more targeted and the test results more closely aligned with actual application needs.

[0028] In a feasible embodiment, when the automated operation route adopted is the component identification driven route, during the process of performing test operations on the storage performance test application, the Android automated test framework can be called first to obtain the front-end component identifier of the storage performance test application, and then the target test button can be located according to the front-end component identifier and a simulated click operation can be performed to trigger and execute the storage performance test operation.

[0029] In one feasible embodiment, such as Figure 2 As shown, when the automated operation route adopted is the component identification driven route, the execution process of obtaining the front-end component identifier of the storage performance test application includes, but is not limited to, steps 210 to 230.

[0030] Step 210: Initialize the connection between the test terminal and the Android automated testing framework of the Android device; Step 220: Read the layout information of the interface components of the storage performance test application; Step 230: Extract the identifier information corresponding to the target test button from the interface component layout information as the front-end component identifier.

[0031] In a feasible embodiment, in step 210, the Android automated testing framework is built based on Python and uiautomator2. Python can call the uiautomator2 interface to locate and operate Android application interface components. The initial connection process essentially establishes a remote control channel between the test terminal and the Android device. During this process, the Android debug bridge can be used to complete device identification and permission configuration, ensuring that the test terminal can stably issue various test commands to the Android device, laying the communication foundation for subsequent automated operations.

[0032] In a feasible embodiment, in step 220, uiautomator2 has the ability to acquire Android application interface elements. After the framework connection is established, it can call relevant interfaces to scan and store all visual components within the current interface of the performance test application. These components include various interactive elements such as buttons and input boxes. The read interface component layout information can be returned to the test terminal in the form of structured data, which includes key attributes such as the position, size, and type of the components.

[0033] In a feasible embodiment, in step 230, the target test button is the core interactive element that triggers the storage performance test. Generally, different test buttons correspond to different test items. From the read interface component layout information, the target test button can be filtered out based on the component information, and its corresponding unique identifier information can be extracted. This identifier information can be the component's identifier (such as resource_id) or text content. The resource_id is the resource identifier of the Android application interface component, a unique identifier assigned to each interface element during Android application development. This identifier information can be accurately extracted using the relevant interfaces of the uiautomator2 library. This front-end component identifier will serve as the location basis for subsequent automated click operations. When actually performing automated operations, the test framework can call the element location interface of uiautomator2, passing the extracted resource_id as a location parameter. The framework can then accurately match the corresponding target test button in the application interface based on this unique identifier.

[0034] In one feasible embodiment, when the automated operation route is a coordinate positioning driven route, during the process of performing test operations on the storage performance test application, the coordinate information of the target test button of the storage performance test application on the screen can be obtained first, and then the input command of the Android debug bridge can be used to perform a simulated click operation on the position corresponding to the coordinate information to trigger and execute the storage performance test operation.

[0035] In a feasible embodiment, when the automated operation route is a coordinate positioning driven route, the execution process of obtaining the coordinate information of the target test button on the screen of the storage performance testing application mainly revolves around the instruction interaction of the Android debug bridge and the reading of touch coordinates. This process includes: clicking the target test button of the storage performance testing application and reading the touch coordinates displayed on the screen; using the touch coordinates as the coordinate information of the target test button. Specifically, the first step is to click the target test button of the storage performance testing application and simultaneously capture the touch behavior towards that button. Simultaneously with the click, the test terminal can read the touch coordinates displayed in real-time on the Android device screen through the Android debug bridge. These coordinates are in pixels and can accurately identify the specific location of the click position in the screen coordinate system. The second step is to use the touch coordinates as the coordinate information of the target test button. Since the target test button is located in a fixed display area in the application interface, the touch coordinates obtained from a single click can represent the core positioning point of the button on the screen. In actual processing, the coordinates obtained from multiple clicks can be averaged to reduce the impact of deviations from a single click. The final determined coordinate information will be stored in the test terminal as the core basis for subsequent automated coordinate positioning clicks via Android debugging bridge input commands, ensuring that automated operations can accurately trigger the target test button.

[0036] In a feasible embodiment, when the automated operation route is a component identification-driven route, after performing test operations on the storage performance test application, the execution process of step 130, which involves collecting the test result data output by the storage performance test application, includes: detecting whether the result display component of the storage performance test application has been loaded; if the result display component is detected to be loaded, obtaining the text information of the result display component; and extracting the storage performance test data from the text information to obtain the test result data.

[0037] In a feasible embodiment, when the automated operation route adopted is the component identification-driven route, after collecting the test result data, a screenshot operation can also be performed on the result display interface of the storage performance test application to save the first screenshot file to the Android device; and the first screenshot file is sent from the Android device to the test terminal through the Android debugging bridge.

[0038] In a feasible embodiment, when the automated operation route is a component recognition-driven route, during actual execution, the test framework can select the corresponding automated operation route according to the preset test scenario, and sequentially simulate clicks on a series of test button components within the storage performance test application to trigger the corresponding storage performance test items. The test framework can continuously monitor the running status of the test process. Once the test process is completed, it will automatically jump to the result display interface, at which point the loading detection process of the result display component can be started. The result display component is a dedicated interface element used to present test data. Its loading status can be determined through the component status monitoring interface of uiautomator2. When the visible and content attributes of the component both reach the preset standards, it can be determined that the loading is complete. After confirming that the result display component has been loaded, the test framework can call the text information acquisition interface of uiautomator2 to read all the text content within the component. At the same time, in order to retain the test results, a screenshot operation can also be performed synchronously to save the complete screen of the result display interface. This screenshot operation can be completed using the native screenshot function of the Android system, and the generated first screenshot file will be temporarily saved to the local storage path of the Android device. The testing framework can then use the communication channel established by the Android debug bridge to send file transfer commands, transmitting the first screenshot file stored on the Android device to the test terminal, completing the off-site backup and retention of the screenshot file. Afterwards, the core data for storage performance testing can be filtered and extracted from the read text information according to preset data extraction rules. This data can then be saved to the test terminal to provide data support for subsequent test analysis.

[0039] In a feasible embodiment, when the automated operation route is a coordinate positioning driven route, the execution process of step 130, collecting the test result data output by the storage performance test application, includes: monitoring whether the storage performance test of the storage performance test application is complete; if the test is complete, performing a screenshot operation on the result display interface of the storage performance test application and saving the second screenshot file to the Android device; sending the second screenshot file from the Android device to the test terminal through the Android debugging bridge; parsing the second screenshot file, extracting the storage performance test data, and obtaining the test result data. In actual execution, the test framework can leverage the command interaction capabilities of the Android debugging bridge to achieve screen coordinate positioning through commands, sequentially performing simulated click operations on the target test buttons within the storage performance test application, thereby triggering the corresponding storage performance test items. The test framework can continuously monitor the running status of the test process and confirm whether the storage performance test is complete by judging changes in the application interface status. After confirming that the test is complete, the test framework can call the native screenshot function of the Android system to perform a screenshot operation on the currently displayed result display interface, and the generated second screenshot file will be temporarily saved to the local storage path of the Android device. Subsequently, the testing framework can use the communication channel established by the Android debugging bridge to transfer the second screenshot file stored on the Android device to the test terminal, completing the off-site file retention. After the second screenshot file is transferred to the test terminal, the testing framework can rely on the scripting capabilities of the Python language, combined with OCR image recognition technology, to parse the screenshot file. OCR image recognition technology can convert the text content in the screenshot image into editable text data. The testing framework can then select core performance indicators for storage testing from the converted text data according to preset data extraction rules, such as sequential read / write speed and random read / write speed. After the above parsing and extraction operations, structured test result data can be obtained, providing data support for subsequent test result analysis and archiving.

[0040] In one feasible embodiment, before parsing the second screenshot file, the screenshot file can be cropped to obtain a screenshot file containing only the test results. Then, the screenshot file containing only the test results is binarized and denoised to obtain an optimized screenshot file. Cropping involves removing areas in the screenshot that are irrelevant to the test results, retaining only the core area that centrally presents the test data. Cropping reduces the processing scope of subsequent image recognition and minimizes interference from irrelevant elements. Binarization, performed after cropping, converts the color or grayscale screenshot image into a black and white image, presenting the text and numbers of the test results in high contrast and enhancing the distinction between text and background. Denoising removes interfering pixels from the image, such as noise from the screen display or blurry shadows at the edges of interface elements, reducing the impact of these interference factors on character recognition. The combined binarization and denoising processes improve the clarity and regularity of the screenshot image, increasing the accuracy of test result data extraction.

[0041] In one feasible embodiment, such as Figure 3 As shown, step 140, which involves saving the test result data to the test terminal, includes, but is not limited to, steps 310 to 340.

[0042] Step 310: Create a data table containing test items, test results, and test time fields; Step 320: Enter the test results data, along with the corresponding test items and test times, into the data table; Step 330: Check if a saved storage performance test table file exists in the test terminal; Step 340: If the data table exists, populate the saved storage performance test table file with the data table content; if the data table does not exist, create a new table file and populate the table file with the data table content.

[0043] In a feasible embodiment, during actual operation, the testing framework can rely on the pandas tool in Python to complete the above data storage process. The data table is a structured data carrier, where the test item field is used to record the type of storage test executed, such as continuous read test, continuous write test, etc., the test result field can be used to fill in the specific performance values ​​extracted, and the test time field can automatically record the timestamp of the test completion, ensuring that each piece of test data is traceable.

[0044] In one feasible implementation, when filling the data table with test results and corresponding test times, the pandas tool can integrate this scattered information into a well-structured DataFrame. This structure clearly corresponds to the rows and columns of the table, facilitating subsequent data processing and storage. After data filling is complete, the test framework searches the storage path specified by the test terminal to check if a saved storage performance test table file exists. This file is typically stored in xlsx or csv format.

[0045] In one feasible embodiment, if a corresponding table file already exists, the pandas tool can read the original data in the file and append the newly created table content containing the current test data to the file to achieve the cumulative saving of test data; if no saved table file is found, the pandas tool can create a new table file and completely fill the current test data into the file to form the initial test data table.

[0046] The following is a specific example illustrating the overall process of Android device storage performance testing.

[0047] like Figure 4 As shown, the storage performance testing applications installed on Android devices include AnTuTu and Androbench. The initial stage requires the installation of these two applications. The specific process is as follows: First, iterate through the apk folder in the same directory to obtain the apk files. These apk files are the installation package files corresponding to AnTuTu and Androbench. Then, install these obtained apk files one by one to ensure that the two storage performance testing applications can run normally on the Android device.

[0048] For AnTuTu storage performance testing, the specific process includes the following steps: First, relevant parameters need to be input, including the number of tests, test interval, main controller machine name, chip silkscreen, and firmware permissions. Next, the parameters are obtained, specifying that the screencap folder in the same directory is used to store the result images; this folder is the storage path mentioned earlier for storing the test result screenshots. Then, by automatically clicking the "Save Test" button, screenshots of the test results are saved to the sdcard directory of the Android device. The image names include timestamps to distinguish results from different test sessions. Subsequently, the result images from the sdcard are retrieved to the local computer (i.e., the test terminal) using the Android debugging bridge. After screenshotting and saving, the uiautomator2 library is called to obtain the component identifier (i.e., resource ID) corresponding to the returned results. The text data of the corresponding component is obtained through this component identifier, and this data is saved as a result list. Finally, the pandas library is used to write the result list to a new xlsx file, which is saved in the same directory as the executable file (exe file). This .xlsx file contains fields such as test count, score, sequential read, sequential write, random read, and random write, used for structured storage of various core data from AnTuTu tests.

[0049] For storage performance testing targeting Androbench, the specific process is similar to the AnTuTu testing process, with the following steps: First, input the relevant parameters, the parameter types are the same as in AnTuTu testing, including the number of tests, test interval, main controller machine name, chip silkscreen, and firmware permissions. Next, obtain the preset parameters, and again use the screencap folder in the same directory as the storage path for the result images. Then, trigger the test by automatically clicking the storage test button, save the test result image screenshot to the sdcard directory of the Android device, with the image name format including a timestamp, and then use the Android debugging bridge to pull the image to the local computer. Subsequently, call the uiautomator2 library to obtain the XPath component identifier corresponding to the returned result. This XPath component identifier is a type of component identifier. Use this identifier to obtain all XPath information of the corresponding component, and save this information as a result list. Finally, use the pandas library to write the result list to a new xlsx file, which is saved in the same directory as the executable file (exe file). This xlsx file contains fields such as the number of tests (count), sequential read, sequential write, random read, and random write, used for structured storage of the core data of the Androbench test.

[0050] It should be noted that this application uses Python combined with the uiautomator2 library to build an automated storage testing solution. Developers only need to configure a Python 3.6 or higher environment and install the uiautomator2 library to complete the basic runtime environment setup. Based on this technical architecture, the test program can also be packaged into an executable file (.exe file). The packaged program can be run directly on other Windows computers without requiring complex additional dependency environments on the target computer, thus having extremely low requirements for the runtime environment. In addition, the subsequent maintenance of this application is simple. The overall stability mainly depends on the communication connection established between the computer and the Android device through the Android debugging bridge. As long as this connection is stable, the testing process can be ensured to proceed smoothly. At the same time, the process resource consumption during runtime is low, and the test results will not deviate from the actual storage performance of the device due to excessive process consumption of system resources. Furthermore, this application does not have special permission requirements for Android devices and has good compatibility with Android devices that support simulated click functions, enabling testing on various Android terminals of different models.

[0051] This application also discloses an automated testing system for the storage performance of an Android device, which includes a test terminal and an Android device. The Android device has a storage performance testing application installed, and the Android device and the test terminal are connected through an Android debug bridge. The test terminal includes a processor and a memory. The memory stores multiple instructions, which are adapted to be loaded and executed by the processor using the aforementioned automated testing method for the storage performance of the Android device.

[0052] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An automated testing method for the storage performance of Android devices, characterized in that, The Android device has a storage performance testing application installed. The Android device establishes a communication connection with the test terminal through an Android debugging bridge. The method includes: Launch the storage performance test application on the Android device; Based on the preset test scenario, select the corresponding automated operation route to perform test operations on the storage performance test application; Collect the test result data output by the storage performance testing application; The test result data is saved to the test terminal.

2. The automated testing method for the storage performance of Android devices according to claim 1, characterized in that, The automated operation route includes a component identification drive route and a coordinate positioning drive route; Select the corresponding automated operation route to perform test operations on the storage performance testing application, including: The component identification-driven approach is adopted. The Android automated testing framework is called to obtain the front-end component identifier of the storage performance testing application. The target test button is located according to the front-end component identifier and a simulated click operation is performed to trigger and execute the storage performance test operation. The coordinate positioning-driven route is used to obtain the coordinate information of the target test button on the screen of the storage performance test application. The input command of the Android debug bridge is used to perform a simulated click operation on the position corresponding to the coordinate information, thereby triggering and executing the storage performance test operation.

3. The automated testing method for the storage performance of Android devices according to claim 2, characterized in that, Obtain the front-end component identifier of the storage performance testing application, including: Initialize the connection between the test terminal and the Android automated testing framework of the Android device; Read the layout information of the interface components of the storage performance test application; Extract the identifier information corresponding to the target test button from the interface component layout information as the front-end component identifier.

4. The automated testing method for the storage performance of Android devices according to claim 3, characterized in that, When using a component identification-driven approach, the test result data output by the storage performance testing application is collected, including: Check whether the result display component of the storage performance test application has been fully loaded; If the result display component is detected to have finished loading, obtain the text information of the result display component; Data from the storage performance test is extracted from the text information to obtain the test results.

5. The automated testing method for the storage performance of Android devices according to claim 4, characterized in that, After collecting the test result data, the method further includes: Take a screenshot of the result display interface of the storage performance test application and save the first screenshot file to the Android device; The first screenshot file is sent from the Android device to the test terminal via the Android debugging bridge.

6. The automated testing method for the storage performance of Android devices according to claim 2, characterized in that, Obtain the coordinate information of the target test button on the screen in the storage performance testing application, including: Click the target test button in the storage performance test application to read the touch coordinates displayed on the screen; The touch coordinates are used as the coordinate information of the target test button.

7. The automated testing method for the storage performance of an Android device according to claim 6, characterized in that, When using coordinate positioning to drive the route, the test result data output by the storage performance test application is collected, including: Monitor whether the storage performance test of the aforementioned storage performance test application has been completed; If the test is completed, take a screenshot of the result display interface of the storage performance test application and save the second screenshot file to the Android device. The second screenshot file is sent from the Android device to the test terminal via the Android debugging bridge; The second screenshot file is parsed to extract storage performance test data and obtain test result data.

8. The automated testing method for the storage performance of an Android device according to claim 7, characterized in that, Before parsing the second screenshot file, the method further includes: The screenshot file is cropped to obtain a screenshot file containing only the test results; The screenshot file containing only test results is binarized and denoised to obtain an optimized screenshot file.

9. The automated testing method for the storage performance of an Android device according to claim 1, characterized in that, Saving the test result data to the test terminal includes: Create a data table containing test items, test results, and test time fields; Enter the test results data, along with the corresponding test items and test times, into the data table; Check whether a saved storage performance test table file exists in the test terminal; If it exists, populate the contents of the data table into the saved storage performance test table file; If the table does not exist, create a new table file and populate it with the contents of the data table.

10. An automated testing system for the storage performance of an Android device, characterized in that, The system includes a test terminal and an Android device, wherein the Android device has a storage performance testing application installed, and the Android device and the test terminal are connected via an Android debug bridge; the test terminal includes a processor and a memory, wherein the memory stores multiple instructions, the instructions being adapted to be loaded by the processor and executed by the automated testing method for the storage performance of the Android device according to any one of claims 1-9.

Images