Vehicle interface testing method, apparatus, device, and storage medium

Abstract

The application relates to a vehicle interface test method, device, equipment and storage medium. The method comprises the following steps: acquiring a first image of a vehicle-mounted screen of a vehicle according to a playback test instruction to execute a target test case, wherein the target test case is determined according to recorded information stored when the vehicle-mounted screen executes a preset operation; acquiring a second image stored when the vehicle-mounted screen executes the preset operation; and comparing the first image with the second image to generate a test result. The scheme provided by the application can more simply realize interface testing and reduce assertion cost.

Description

Technical Field

[0001] This application relates to the field of interface testing technology, and in particular to a vehicle interface testing method, apparatus, equipment, and storage medium. Background Technology

[0002] User interface (UI) automation testing refers to testing the functionality and stability of a software interface by simulating user actions using automated tools. Currently, commonly used UI automation testing methods mainly include two types: one is to capture and manipulate UI elements, and then assert whether the behavior of these elements meets expectations. UI elements can be captured using image recognition or APIs. The other is to record the operations of UI elements and reproduce these operations through playback, and then assert whether the system's performance meets expectations. An assertion is a type of first-order logic in a program, used to represent and verify the results expected by the software developer.

[0003] Then, the major interface automation testing tools of related technologies mainly focus on capturing the controls on the interface, and assertions need to be made based on the properties of the controls, which makes the assertion cost relatively high. Summary of the Invention

[0004] To address or partially address the problems existing in related technologies, this application provides a vehicle interface testing method, apparatus, device, and storage medium, which can more easily implement interface testing and reduce assertion costs.

[0005] The first aspect of this application provides a vehicle interface testing method, including:

[0006] The first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction is obtained, wherein the target test case is determined based on the recording information stored when the in-vehicle screen performs a preset operation;

[0007] Acquire the second image stored when the vehicle screen performs the preset operation;

[0008] The test results are generated by comparing the first image with the second image.

[0009] Optionally, acquiring the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction includes:

[0010] After establishing a connection with the vehicle's in-vehicle screen, the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction is obtained;

[0011] The recording of the vehicle screen performing preset operations includes:

[0012] After establishing a connection with the vehicle's in-vehicle screen, the preset operation performed by the in-vehicle screen is recorded.

[0013] Optionally, comparing the first image with the second image to generate test results includes:

[0014] Determine the business type of the target test case;

[0015] Select the comparison method based on the business type of the target test case;

[0016] Based on the selected comparison method, the first image and the second image are compared to generate test results.

[0017] Optionally, after obtaining the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction, the method further includes:

[0018] The first image is subjected to noise reduction processing to obtain the noise-reduced first image;

[0019] The step of acquiring the second image stored when the vehicle screen performs the preset operation includes: acquiring the second image stored when the vehicle screen performs the preset operation and performing noise reduction processing.

[0020] Optionally, the noise reduction process includes:

[0021] Different noise reduction processes are performed according to different noise reduction strategies, wherein the noise reduction strategy is determined according to the business type of the target test case.

[0022] Optionally, the target test case includes screen coordinate information and operation type information of a preset operation, and the vehicle screen executes the target test case according to the playback test instruction, including:

[0023] The vehicle screen replays the preset operation in the target test case using the screen coordinate information and operation type information of the preset operation.

[0024] Optionally, acquiring the second image stored when the vehicle screen performs the preset operation further includes:

[0025] The system can acquire a second image stored when the vehicle screen performs a preset operation recorded by itself; or, acquire a second image stored when the vehicle screen performs a preset operation recorded by another device.

[0026] A second aspect of this application provides a vehicle interface testing apparatus, comprising:

[0027] The first acquisition module is used to acquire a first image of the vehicle's in-vehicle screen executing a target test case according to a playback test instruction, wherein the target test case is determined based on the recording information stored when the in-vehicle screen performs a preset operation.

[0028] The second acquisition module is used to acquire the second image stored when the vehicle screen performs the preset operation;

[0029] The comparison module is used to compare the first image with the second image and generate test results.

[0030] A third aspect of this application provides an electronic device, comprising:

[0031] Processor; and

[0032] A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0033] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method described above.

[0034] The technical solution provided in this application may include the following beneficial effects:

[0035] This application acquires a first image of a vehicle's in-vehicle screen executing a target test case according to a playback test instruction, wherein the target test case is determined based on recording information stored when the in-vehicle screen performs a preset operation; acquires a second image stored when the in-vehicle screen performs the preset operation; and compares the first image and the second image to generate a test result. This application performs interface testing by comparing screenshots from recording and playback. Compared to related technologies, this saves on actions such as control recognition and attribute judgment, making interface testing simpler and reducing assertion costs.

[0036] The technical solution of this application can also establish a connection with the vehicle screen before playback recording, avoiding the problems of app development costs, app installation, failed app permission requests, and app crashes caused by app recording; this application selects appropriate comparison methods for different images, achieving a balance between high comparison accuracy and tolerance for pixel-level errors; this application selects appropriate noise reduction methods for different images to reduce the impact of interference factors on image comparison and reduce false alarm rates; this application performs playback based on screen coordinates, avoiding the risk of interface element recognition failure and reducing testing costs.

[0037] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0038] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0039] Figure 1 This is a schematic flowchart illustrating the vehicle interface testing method according to an embodiment of this application;

[0040] Figure 2 This is another schematic flowchart of the vehicle interface testing method shown in the embodiments of this application;

[0041] Figure 3 This is a schematic diagram of a preset test task model shown in an embodiment of this application;

[0042] Figure 4 This is a schematic diagram illustrating the connection relationship between the vehicle's in-vehicle screen and the testing equipment, as shown in an embodiment of this application.

[0043] Figure 5 This is a flowchart of the vehicle interface testing method provided in the embodiments of this application;

[0044] Figure 6 This is another flowchart of the vehicle interface testing method provided in the embodiments of this application;

[0045] Figure 7 This is a schematic diagram of the structure of the vehicle interface testing method apparatus shown in the embodiments of this application;

[0046] Figure 8 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0047] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0048] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0049] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0050] The major interface automation testing tools for related technologies mainly focus on capturing controls on the interface, and assertions need to be made based on the properties of the controls, which makes the assertion cost relatively high.

[0051] To address the aforementioned issues, this application provides a vehicle interface testing method that compares recorded and replayed screenshots to perform interface testing. Compared to related technologies, this method saves on actions such as control recognition and attribute judgment, making interface testing simpler and reducing assertion costs.

[0052] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0053] Figure 1 This is a flowchart illustrating the vehicle interface testing method shown in the embodiments of this application.

[0054] See Figure 1 The method includes:

[0055] Step 101: Obtain the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction, wherein the target test case is determined based on the recording information stored when the in-vehicle screen performs a preset operation.

[0056] Many tests of equipment or software require operation and inspection through the user interface. Software changes also require extensive testing through the user interface. Automating interface testing can greatly improve testing efficiency and speed up the testing process.

[0057] In this embodiment, a testing device can be used to test the interface of a vehicle's in-vehicle screen. During the testing, the testing device first sends a playback test command to the in-vehicle screen. The in-vehicle screen then executes the target test case according to the playback test command. The target test case is determined based on the recording information stored when the in-vehicle screen performs preset operations. After executing the preset operations in the target test case, a first image is acquired. It is understood that the recording information includes data from the preset operations performed during the recording process, such as information about the vehicle where the in-vehicle screen is located, operation-related information, images, and other important data.

[0058] Step 102: Obtain the second image stored when the vehicle screen performs a preset operation.

[0059] During the recording process, corresponding preset operations can be performed according to the test objectives. After the preset operations are completed, a second image of the vehicle screen can be captured and stored. The second image can be retrieved when needed.

[0060] Step 103: Compare the first image with the second image to generate test results.

[0061] After obtaining the first image captured during the playback test and the second image captured during the recording process, the similarity between the first and second images can be compared to determine whether the test is passed, thereby generating the test result.

[0062] This application discloses a vehicle interface testing method. It obtains a first image of the vehicle's in-vehicle screen executing a target test case according to a playback test instruction. The target test case is determined based on recording information stored when the in-vehicle screen performs a preset operation. A second image of the in-vehicle screen executing the preset operation is obtained. The first and second images are compared to generate a test result. Interface testing is performed by comparing the recorded and playback screenshots. Compared to related technologies, this method saves on control recognition and attribute judgment, making interface testing simpler and reducing assertion costs.

[0063] Figure 2 This is another schematic flowchart illustrating the vehicle interface testing method in the embodiments of this application.

[0064] See Figure 2 The method includes:

[0065] Step 201: Obtain the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction, wherein the target test case is determined based on the recording information stored when the in-vehicle screen performs a preset operation.

[0066] In an optional embodiment of this application, the target test case includes screen coordinate information and operation type information of a preset operation. The vehicle screen executes the target test case according to the playback test instruction, including:

[0067] The vehicle screen replays the preset operations in the target test case using the screen coordinate information and operation type information of the preset operation.

[0068] The target test case includes screen coordinate information and operation type information for a preset operation. During playback testing, the preset operation in the target test case can be replayed using the screen coordinate information and operation type information. In this embodiment, operation playback is based on screen coordinate information, which reduces implementation cost and the risk of recognition failure.

[0069] The operation type information can be obtained based on screen coordinates. When the target test case is executed, corresponding logs are generated. These logs can be captured using the command "adb shell getevent -t". After capturing the logs, read them and parse the flags. These flags include the start and end positions of the preset operation in the target test case. The logs record the screen coordinates corresponding to the start and end positions of the preset operation. If the screen coordinates of the start and end positions are the same, the operation type can be determined to be a click; if the screen coordinates of the start and end positions are different, the operation type can be determined to be a swipe.

[0070] In this embodiment of the application, the target test case can be generated by a preset test task model, such as... Figure 3 The diagram illustrates a preset test task model. During recording, the Operation component in the preset test task model records basic information about the preset operation performed by the user, including: the module, device serial number, target screenshot, and timestamp. Step is an abstraction of the user's operation, including types such as click, swipe, wait, and long press. The ReplayLog records playback information. By integrating with CICD (Continuous Integration; Continuous Deployment), the preset test task model can continuously integrate and deploy target test cases corresponding to the preset operations. Then, test tasks are created based on the target test cases, and the in-vehicle screen is tested by executing these test tasks.

[0071] In an optional embodiment of this application, step 201 includes:

[0072] After establishing a connection with the vehicle's in-vehicle screen, the first image of the target test case executed by the vehicle's in-vehicle screen according to the playback test command is obtained.

[0073] like Figure 4The diagram shows the connection between the vehicle's in-vehicle screen and the testing equipment. The in-vehicle screen and the testing equipment are connected for communication. The testing equipment can also communicate with a cloud server. The testing equipment can be a computer. The software to be tested can be installed on both the vehicle's in-vehicle screen and the testing equipment. The testing equipment is also equipped with a recording tool to record the screen of the device under test. The recording tool is cross-platform and supports Windows, Linux, and Mac.

[0074] During the test, the test equipment can obtain the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instructions after establishing a connection with the in-vehicle screen.

[0075] By performing playback tests on a computer connected to the in-vehicle screen, manually operating or remotely controlling the in-vehicle screen, relevant information about the playback test can be obtained, avoiding issues such as the cost of developing an app, installing an app, failing to apply for app permissions, and app crashing during operation.

[0076] In an optional embodiment of this application, during the playback test, the first image can be obtained by taking a screenshot of the in-vehicle screen interface according to the screenshot command "adb shell screencap".

[0077] Step 202: Obtain the second image stored when the vehicle screen performs a preset operation.

[0078] During the recording process, corresponding preset operations can be performed according to the test objectives. After the preset operations are completed, a second image of the vehicle screen can be captured and stored. The second image can be retrieved when needed.

[0079] In an optional embodiment of this application, recording the vehicle screen performing preset operations includes:

[0080] Record the preset operations performed on the vehicle's screen after establishing a connection with the screen.

[0081] During recording, the testing equipment can establish a connection with the vehicle's in-vehicle screen before recording preset operations performed on the screen. During recording, the testing equipment can either listen to manually performed operations on the vehicle's in-vehicle screen or project the vehicle's screen onto the testing equipment, allowing the testing equipment to perform operations on the software to be tested on the in-vehicle screen based on preset operations.

[0082] By recording on a computer connected to the vehicle screen, and manually or remotely controlling the vehicle screen, relevant information about the recorded operation can be obtained, avoiding problems such as the cost of app development, app installation, failure to apply for app permissions, and app freezing during operation.

[0083] In an optional embodiment of this application, step 202 includes:

[0084] Acquire a second image stored when the vehicle screen performs a preset operation recorded by itself; or, acquire a second image stored when the vehicle screen performs a preset operation recorded by another device.

[0085] It should be noted that recording and playback tests can be performed on the same device, such as capturing a second image stored on the same device when the in-vehicle screen performs a preset operation, or on different devices, such as in a master-slave mode, where recording is performed on the master device and playback is performed on the slave device that is connected to the master device, with real-time comparison of the screenshots from the recording and playback tests. Using a master-slave mode can shorten testing time and improve testing efficiency.

[0086] In an optional embodiment of this application, during the recording process, the second image can be obtained by taking a screenshot of the in-vehicle screen interface according to the screenshot command "adbshell screencap".

[0087] Step 203: Determine the business type of the target test case.

[0088] The business logic refers to the specific presentation of the in-vehicle screen's functions, such as changing vehicle settings in the vehicle's "Settings app" or listening to music in the "In-Vehicle Music app." Different types of business logic have different interfaces. Some interfaces have dynamic effects, such as changing clouds over the ground on the system homepage, or constantly changing time and battery level on the status bar. The business logic is accompanied by user interface interactions; for example, changing certain settings requires opening a pop-up window. Different business logic interfaces will also affect the operations in the target test cases. For example, turning on a switch on a settings page requires only a few clicks to reach the specific page, and then clicking again to turn it on. However, adjusting the volume requires a swipe operation to adjust the volume cursor position. Therefore, it's helpful to first determine the business logic type of the target test cases.

[0089] Step 204: Select the comparison method based on the business type of the target test case.

[0090] Different target test cases involve different business types, and the interference factors on the in-vehicle screen interface also vary. In this embodiment, multiple comparison methods can be provided, and the comparison method can be selected according to the business type of the target test case. If the interface contains dynamic effects such as changing clouds, and the difference between the first image and the second image is large, the average hash algorithm can be used. For some interfaces with less interference, the histogram comparison method can be used to compare the images.

[0091] Step 205: Compare the first image with the second image according to the selected comparison method, and generate test results.

[0092] If the average hash algorithm is used, the two images are first converted to grayscale and compressed. The hash values ​​of the two images are obtained by comparing pixels. The Hamming distance between the two hash values ​​is then calculated for comparison. The average hash algorithm is fast, highly sensitive, and has improved tolerance for differences. If the histogram comparison method is used, the two images are first converted to grayscale. The histogram is normalized by dividing the number of pixels of each intensity by a normalization factor. Then, the similarity between the two histograms is calculated for comparison between the first and second images. Histogram comparison is suitable for images with high similarity and is faster. The first and second images are compared according to the selected comparison method to generate a playback test result to determine whether the test passes. For different images, an appropriate comparison method is selected to achieve a balance between high accuracy and tolerance for pixel-level errors.

[0093] It should be noted that, in an optional embodiment of this application, after step 201, the following steps are also included:

[0094] The first image is denoised to obtain the denoised first image;

[0095] Step 202 also includes: acquiring a second image that has been stored and noise-reduced when the vehicle screen performs a preset operation.

[0096] For in-vehicle screens, some elements are variable, such as time, Wi-Fi (Wireless Fidelity) signal strength, and UI (User Interface) dynamic effects. If these variable elements are not pre-processed, they may affect the comparison results. Since the positions of these variable elements can be determined beforehand, and we want to ignore them during comparison, noise reduction processing can be performed on the variable elements in the image. Therefore, after acquiring the first image, noise reduction processing can be performed on the first image to obtain a noise-reduced first image.

[0097] The second image can be denoised immediately after recording, thus obtaining a denoised second image.

[0098] In an optional embodiment of this application, noise reduction processing includes:

[0099] Different noise reduction processes are applied based on different noise reduction strategies, with the specific noise reduction strategy determined according to the business type of the target test case.

[0100] Different target test cases have different business types, user interfaces, and different locations on the interface that need to be processed. Therefore, a suitable noise reduction strategy can be selected based on the business type. This application provides the following noise reduction schemes: Masking certain areas: For in-vehicle screens, information such as time and Wi-Fi signal are generally located in fixed positions in the status bar. Therefore, before comparison, these fixed-position areas are filled with color to mask the information in these fixed positions; Comparing certain areas: During the operation of the in-vehicle screen system, there are many pop-up panels. Generally, the information within these pop-up panels is valid. Therefore, the image can be cropped to only include the pop-up panel area, thus comparing only the elements within the pop-up panel. Normalization processing: To accommodate pixel offsets on the in-vehicle large screen interface, the image can also be normalized. Those skilled in the art will understand that this application does not limit the noise reduction strategy; type conversion methods can also be used. The above methods are merely examples, and those skilled in the art can choose a suitable noise reduction strategy based on the actual situation. It is understood that the noise reduction strategy used for the first image and the second image can be consistent. For different images, appropriate noise reduction methods are selected to reduce the impact of interference factors on image comparison and reduce the false alarm rate.

[0101] In an optional embodiment of this application, the recording and playback test go through the same set of operations. After reaching the target interface, a screenshot is taken to obtain the first image and the second image. After comparison, if the first image and the second image are determined to be consistent, the playback test can be considered successful. At this time, the first image, the second image, and the test result can be uploaded to the cloud server that is connected to the test device for storage.

[0102] In an optional embodiment of this application, other assertion methods can be added, such as using an automated interface testing tool to count the number of interface elements and comparing element attributes such as element position, spatial attributes, element path, whether it is clickable, and whether it is draggable, thereby expanding the testing boundaries.

[0103] like Figure 5 The diagram shown is a flowchart of the vehicle interface testing method provided in this application embodiment:

[0104] Operation refers to a series of operations performed on the device under test (DUT) during the recording process, including operation-1, ..., operation-n; record records the preset test case and takes a screenshot of the DUT's interface to obtain a second image; parse parses the preset test case log to obtain relevant information about user operations; replay executes the parsed user operation information to replay the DUT and obtain a first image; denoises the second image and the first image; finally, assertions are used to compare the denoised second image with the first image (diff).

[0105] This application discloses a vehicle interface testing method. It involves acquiring a first image of a vehicle's in-vehicle screen executing a target test case according to a playback test command. The target test case is determined based on recording information stored when the in-vehicle screen performs a preset operation. A second image stored when the in-vehicle screen performs the preset operation is acquired. The business type of the target test case is determined. A comparison method is selected based on the business type of the target test case. The first image and the second image are compared according to the selected comparison method to generate a test result. This application performs interface testing by comparing recorded and played-back screenshots. Compared to related technologies, this method saves on actions such as control recognition and attribute judgment, simplifying interface testing and reducing assertion costs. Furthermore, it achieves a balance between high accuracy and tolerance for pixel-level errors by selecting appropriate comparison methods for different images.

[0106] like Figure 6 The diagram shown is another flowchart of the vehicle interface testing method provided in this application embodiment. This embodiment illustrates the example of using the same testing equipment for both recording and playback tests.

[0107] The method includes:

[0108] Step 601: After the test equipment establishes a connection with the vehicle's in-vehicle screen, record the in-vehicle screen performing preset operations and take screenshots of the preset operations.

[0109] During recording, the system can either monitor manual operations performed on the vehicle's in-vehicle screen using the testing equipment, or project the vehicle's screen onto the testing equipment and perform operations on the software to be tested on the vehicle's screen based on preset commands. After each operation is completed, the specific instructions can be parsed and screenshots taken in real time.

[0110] Step 602: Denoise the screenshots obtained during recording and store them.

[0111] For in-vehicle screens, some elements are variable, such as time, Wi-Fi signal strength, and UI dynamic effects. If these variable elements are not pre-processed, they may affect the comparison results. Since the positions of these variable elements can be determined beforehand, and we want to ignore them during comparison, noise reduction processing can be performed on the variable elements in the image. Therefore, after recording and obtaining a screenshot, noise reduction processing can be applied to the screenshot obtained during recording to obtain a noise-reduced screenshot.

[0112] This application can perform different noise reduction processes based on different noise reduction strategies, where the noise reduction strategy can be determined according to the business type of the target test case. For details on the relevant noise reduction methods, please refer to [link / reference needed]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.

[0113] Step 603: Perform a replay test and obtain screenshots of the vehicle's in-vehicle screen executing the target test cases according to the replay test instructions.

[0114] The target test cases are determined based on the recording information stored when the vehicle screen performs preset operations.

[0115] The target test case may include screen coordinate information and operation type information of the preset operation during recording. The vehicle screen executes the target test case according to the playback test instruction, including: playing back the preset operation in the target test case through the screen coordinate information and operation type information of the preset operation.

[0116] The target test case includes screen coordinate information and operation type information for a preset operation. During playback testing, the preset operation in the target test case can be replayed using the screen coordinate information and operation type information. In this embodiment, operation playback is based on screen coordinate information, which reduces implementation cost and the risk of recognition failure.

[0117] Step 604: Perform noise reduction processing on the screenshots obtained during playback testing.

[0118] The method for denoising the screenshots obtained during playback testing can be the same as the method for denoising the screenshots obtained during recording, and the denoising strategy used can be consistent, which will not be elaborated here.

[0119] Step 605: Determine the business type of the target test case.

[0120] Step 606: Select the comparison method based on the business type of the target test case.

[0121] Different target test cases involve different business types, and the interference factors on the in-vehicle screen interface also vary. In this embodiment, multiple comparison methods can be provided, and the comparison method can be selected according to the business type of the target test case. If the interface contains dynamic effects such as changing clouds, and the difference between the first image and the second image is large, the average hash algorithm can be used. For some interfaces with less interference, the histogram comparison method can be used to compare the images.

[0122] Step 607: Based on the selected comparison method, compare the screenshots taken during recording with the screenshots taken during playback testing, and generate test results.

[0123] If the average hash algorithm is used, the two images are first converted to grayscale and compressed. The hash values ​​of the two images are then obtained by comparing their pixels. The Hamming distance between the two hash values ​​is then calculated to compare the two images. If the histogram comparison method is used, the two images are first converted to grayscale. The histograms are then normalized by dividing the number of pixels for each intensity by a normalization factor. The similarity between the two histograms is then calculated to compare the screenshots taken during recording with those taken during playback testing.

[0124] The recorded screenshots are compared with the playback screenshots using the selected comparison method to generate playback test results and determine whether the test passed. If the recorded screenshots and the playback screenshots are found to be consistent, the playback test is considered successful. At this point, the recorded screenshots, the playback screenshots, and the test results can be uploaded to a cloud server connected to the test device for storage.

[0125] The vehicle interface testing method disclosed in this application performs interface testing by comparing recorded and played-back screenshots. Compared with related technology testing methods, it saves actions such as control recognition and attribute judgment, making interface testing simpler and lowering assertion costs. For different images, an appropriate comparison method is selected to achieve a balance between high comparison accuracy and tolerance for pixel-level errors. For different images, an appropriate noise reduction method is selected to reduce the impact of interference factors on image comparison and reduce the false alarm rate.

[0126] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a vehicle interface testing device, electronic device, and corresponding embodiments.

[0127] Figure 7 This is a schematic diagram of the vehicle interface testing device shown in the embodiments of this application.

[0128] See Figure 7 The vehicle interface testing device 700 includes: a first acquisition module 701, a second acquisition module 702, and a comparison module 702.

[0129] The first acquisition module 701 is used to acquire the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction, wherein the target test case is determined based on the recording information stored when the in-vehicle screen performs a preset operation.

[0130] The second acquisition module 702 is used to acquire the second image stored when the vehicle screen performs a preset operation.

[0131] The comparison module 703 is used to compare the first image with the second image and generate test results.

[0132] In an optional embodiment of this application, the first acquisition module 701 is further configured to acquire, after establishing a connection with the vehicle's in-vehicle screen, the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction;

[0133] The second acquisition module 702 is also used to record the preset operations performed by the vehicle screen after establishing a connection with the vehicle screen.

[0134] Comparison module 703 includes: a business type submodule, a comparison method submodule, and a comparison submodule;

[0135] The business type submodule is used to determine the business type of the target test case;

[0136] The comparison method submodule is used to select the comparison method based on the business type of the target test case.

[0137] The comparison submodule is used to compare the first image with the second image according to the selected comparison method and generate test results.

[0138] The vehicle interface testing device 700 also includes: a noise reduction module;

[0139] The noise reduction module is used to perform noise reduction processing on the first image to obtain the noise-reduced first image.

[0140] The second acquisition module 702 is also used to acquire a second image that has been stored and noise-reduced when the vehicle screen performs a preset operation.

[0141] The noise reduction process includes performing different noise reduction processes according to different noise reduction strategies, wherein the noise reduction strategy is determined according to the business type of the target test case.

[0142] The target test cases include screen coordinate information and operation type information of the preset operation. The first acquisition module 701 is also used for the vehicle screen to replay the preset operation in the target test cases through the screen coordinate information and operation type information of the preset operation.

[0143] The second acquisition module 702 is also used to acquire the second image stored when it records the vehicle screen performing a preset operation; or, to acquire the second image stored when other devices record the vehicle screen performing a preset operation.

[0144] This application discloses a vehicle interface testing device. It acquires a first image of the vehicle's in-vehicle screen executing a target test case according to a playback test instruction. The target test case is determined based on the recording information stored when the in-vehicle screen performs a preset operation. It acquires a second image stored when the in-vehicle screen performs a preset operation, compares the first image with the second image, and generates a test result. By comparing the screenshots of the recording and playback, it saves the actions of control recognition and attribute judgment, and the assertion cost is low.

[0145] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0146] Figure 8 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0147] See Figure 8 The electronic device 800 includes a memory 810 and a processor 820.

[0148] The processor 820 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0149] Memory 810 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by the processor 820 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 810 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 810 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, a high-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0150] The memory 810 stores executable code, which, when processed by the processor 820, can cause the processor 820 to execute part or all of the methods described above.

[0151] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0152] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) thereon, which, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0153] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A vehicle interface testing method, characterized in that: The first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction is obtained, wherein the target test case is determined based on the recording information stored when the in-vehicle screen performs a preset operation; The first image is subjected to noise reduction processing to obtain the noise-reduced first image; Acquire the second image stored when the vehicle screen performs the preset operation; This includes: acquiring a second image that has been stored and noise-reduced when the vehicle screen performs the preset operation; Comparing the first image with the second image to generate test results includes: determining the business type of the target test case; selecting a comparison method based on the business type of the target test case; and comparing the first image with the second image based on the selected comparison method to generate test results. The noise reduction process includes: Different noise reduction processes are performed according to different noise reduction strategies, wherein the noise reduction strategy is determined according to the business type of the target test case.

2. The method according to claim 1, characterized in that, The step of acquiring the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction includes: After establishing a connection with the vehicle's in-vehicle screen, the first image of the vehicle's in-vehicle screen executing the target test case according to the playback test instruction is obtained; The recording of the vehicle screen performing preset operations includes: After establishing a connection with the vehicle's in-vehicle screen, the preset operation performed by the in-vehicle screen is recorded.

3. The method according to claim 1, characterized in that, The target test cases include screen coordinate information and operation type information of preset operations. The vehicle screen executes the target test cases according to the playback test instructions, including: The vehicle screen replays the preset operation in the target test case using the screen coordinate information and operation type information of the preset operation.

4. The method according to claim 1, characterized in that, The step of acquiring and recording the second image stored when the vehicle screen performs the preset operation further includes: The system can acquire a second image stored when the vehicle screen performs a preset operation recorded by itself; or, acquire a second image stored when the vehicle screen performs a preset operation recorded by another device.

5. A vehicle interface testing device, characterized in that: The first acquisition module is used to acquire a first image of the vehicle's in-vehicle screen executing a target test case according to a playback test instruction, wherein the target test case is determined based on the recording information stored when the in-vehicle screen performs a preset operation. A noise reduction module is used to perform noise reduction processing on the first image to obtain a noise-reduced first image. The second acquisition module is used to acquire a second image stored when the vehicle screen performs the preset operation; wherein, the second acquisition module is further used to acquire a second image stored when the vehicle screen performs the preset operation and subjected to noise reduction processing; The comparison module is used to compare the first image and the second image to generate test results; it includes: a business type submodule, used to determine the business type of the target test case; a comparison method submodule, used to select a comparison method according to the business type of the target test case; and a comparison submodule, used to compare the first image and the second image according to the selected comparison method to generate test results. The noise reduction process includes performing different noise reduction processes according to different noise reduction strategies, wherein the noise reduction strategy is determined according to the business type of the target test case.

6. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-4.

7. A computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-4.

Images