Method and related device for function test of android diagnostic software

Abstract

The application discloses a kind of function test method of Android diagnostic software and related device, method includes: applied to the vehicle diagnostic equipment based on Android system, first, obtain the function test instruction for the vehicle diagnostic equipment, then in response to the function test instruction, determine the function test urgency value of each Android diagnostic software in n Android diagnostic software corresponding, obtain n function test urgency value, then determine the k function test urgency value greater than preset function test urgency value in n function test urgency value, then determine the k Android diagnostic software corresponding to the k function test urgency value, finally, the function test operation is carried out to the k Android diagnostic software, and obtains k function test result. Using the present application embodiment, the test efficiency of Android diagnostic software in vehicle diagnostic equipment is improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle diagnostic technology, and in particular to a functional testing method and related apparatus for Android diagnostic software. Background Technology

[0002] In the field of vehicle diagnostic equipment based on the Android system, these devices typically run multiple Android diagnostic software programs with different functions. During software iterations and routine maintenance, efficient testing of these Android diagnostic software functions is crucial. Current testing methods mostly rely on manual execution or use third-party testing tools and scripts for automation, which is cumbersome and results in low efficiency for testing the Android diagnostic software in vehicle diagnostic equipment. Therefore, improving the testing efficiency of Android diagnostic software in vehicle diagnostic equipment is an urgent problem to be solved. Summary of the Invention

[0003] This application provides a functional testing method and related apparatus for Android diagnostic software, which improves the testing efficiency of Android diagnostic software in vehicle diagnostic equipment.

[0004] In a first aspect, embodiments of this application provide a functional testing method for Android diagnostic software, applied to vehicle diagnostic equipment based on the Android system, the method comprising: Obtain functional test instructions for the vehicle diagnostic equipment; In response to the functional test command, the functional test urgency value corresponding to each of the n Android diagnostic software is determined, resulting in n functional test urgency values; n is a positive integer, and the vehicle diagnostic equipment includes the n Android diagnostic software. Determine the k functional test urgency values ​​that are greater than the preset functional test urgency value from among the n functional test urgency values; k is an integer less than n; Determine the k Android diagnostic software programs corresponding to the k functional test urgency values; Perform functional tests on the k Android diagnostic software programs to obtain k functional test results.

[0005] Secondly, embodiments of this application provide a functional testing device for Android diagnostic software, applied to vehicle diagnostic equipment based on the Android system; the device includes: an acquisition unit and a processing unit; The acquisition unit is used to acquire functional test instructions for the vehicle diagnostic equipment; The processing unit is configured to respond to the functional test instruction, determine the functional test urgency value corresponding to each of the n Android diagnostic software programs, and obtain n functional test urgency values; n is a positive integer, and the vehicle diagnostic device includes the n Android diagnostic software programs; Determine the k functional test urgency values ​​that are greater than the preset functional test urgency value from among the n functional test urgency values; k is an integer less than n; Determine the k Android diagnostic software programs corresponding to the k functional test urgency values; Perform functional tests on the k Android diagnostic software programs to obtain k functional test results.

[0006] Thirdly, embodiments of the present invention provide an electronic device, including: a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor to cause the electronic device to perform the method as described in the first aspect.

[0007] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the method as described in the first aspect.

[0008] Fifthly, embodiments of the present invention provide a computer program product including a non-transitory computer-readable storage medium storing a computer program, such that a computer performs the method as described in the first aspect.

[0009] Implementing the embodiments of the present invention has the following beneficial effects: As can be seen, the functional testing method for Android diagnostic software described in this embodiment of the invention is applied to vehicle diagnostic equipment based on the Android system. First, a functional test instruction for the vehicle diagnostic equipment is obtained. Then, in response to the functional test instruction, a functional test urgency value is determined for each of the n Android diagnostic software programs, resulting in n functional test urgency values. Next, k functional test urgency values ​​greater than a preset functional test urgency value are determined. Then, k Android diagnostic software programs corresponding to the k functional test urgency values ​​are determined. Finally, functional test operations are performed on the k Android diagnostic software programs to obtain k functional test results. Using the embodiment of this application improves the testing efficiency of Android diagnostic software in vehicle diagnostic equipment. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0011] Figure 1 This is a flowchart of a functional testing method for Android diagnostic software provided in the embodiments of this application; Figure 2 This is a flowchart of an embodiment of the present application for determining the urgency values ​​of n functional tests; Figure 3 This is a flowchart provided in an embodiment of the present application for determining the urgency value of a functional test corresponding to a first Android diagnostic software; Figure 4 This is a flowchart of a method for determining k functional test results provided in an embodiment of this application; Figure 5 This is another flowchart for determining the results of k functional tests provided in this application's implementation method; Figure 6 This is a flowchart illustrating a method for determining functional test prompt information, as provided in an embodiment of this application. Figure 7 This is a schematic diagram of the structure of a functional testing device for Android diagnostic software provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present application.

[0013] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0014] In this document, the term "implementation" means that a specific feature, structure, or characteristic described in connection with an implementation may be included in at least one implementation of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same implementation, nor is it a separate or alternative implementation mutually exclusive with other implementations. It will be explicitly and implicitly understood by those skilled in the art that the implementations described herein can be combined with other implementations.

[0015] Please see Figure 1 , Figure 1 This is a flowchart of a functional testing method for Android diagnostic software provided in the embodiments of this application, including but not limited to the following steps: S101: Obtain functional test instructions for the vehicle diagnostic equipment.

[0016] In this embodiment, the Android-based vehicle diagnostic equipment is a type of dedicated on-board repair equipment running the Android operating system. It is primarily used in the fields of automotive repair and vehicle inspection. The equipment integrates a display module, an operation module, and a hardware interface for communication with the vehicle's electronic control system. It contains multiple Android diagnostic software programs with different functions. Leveraging the Android system's excellent interface interaction and application execution capabilities, these diagnostic software programs can complete a series of repair operations according to a set process, including reading vehicle fault codes, monitoring operational data streams, testing the functionality of electronic control components, program matching, and parameter setting. The Android-based vehicle diagnostic equipment can easily perform software updates and function iterations.

[0017] When an Android-based vehicle diagnostic device is in normal operation, it can obtain corresponding functional test commands through various interactive methods. Operators can directly click on the corresponding function icon, select menu options, or trigger a dedicated test button on the touch screen of the Android-based vehicle diagnostic device to manually issue a command to start the functional test. Alternatively, a timed task can be preset, and the vehicle diagnostic device will automatically generate and trigger the functional test command after the specified time. In addition, the vehicle diagnostic device can also receive remote control commands transmitted from external terminals. After recognizing and parsing the above-mentioned various operation signals, timed trigger signals, or external communication signals, the vehicle diagnostic device can determine and obtain the functional test command used to start the software testing process.

[0018] Functional test commands are control information used to trigger vehicle diagnostic equipment to start the internal Android diagnostic software testing process. These commands clearly define the intention to initiate software functional testing. Upon recognizing a functional test command, the vehicle diagnostic equipment switches to test mode and executes all subsequent test steps according to preset logic. For example, if an operator selects the batch test option on the vehicle diagnostic equipment's display interface and confirms, this action generates a functional test command to initiate testing of all Android diagnostic software within the equipment. Similarly, if an operator selects a specific Android diagnostic software and clicks the test button, a functional test command will be generated specifically for that software. When the vehicle diagnostic equipment runs according to a preset timed task, it will automatically generate the corresponding functional test command at the designated time point, thus initiating the automated testing process.

[0019] The functional test commands recognized by vehicle diagnostic equipment use a data format agreed upon internally by the equipment. The command consists of a command header, a command type field, a test object field, an additional parameter field, and a verification field. The command header serves as a fixed identifier, allowing the vehicle diagnostic equipment to quickly distinguish functional test commands from other control information. The command type field indicates the execution method of the functional test, differentiating between manual single-test, batch full-scale test, and timed loop test modes. The test object field specifies the Android diagnostic software to be tested, allowing for the designation of a single software, multiple specified software, or all Android diagnostic software within the vehicle diagnostic equipment. The additional parameter field supplements the test-related configuration, including auxiliary information such as the test process number, test duration, and result saving method. The verification field verifies whether data corruption occurred during the transmission and parsing of the entire functional test command, ensuring that the functional test command is accurately read and executed by the vehicle diagnostic equipment. For example, a functional test command that initiates a batch test of all Android diagnostic software has a fixed character sequence in its command header, a command type field marked as batch test, a test object field marked as all software, an additional parameter field containing the default test process and automatically saved results, and finally, corresponding verification content, forming a complete and standardized functional test command.

[0020] The functional tests conducted by the vehicle diagnostic equipment on the internal Android diagnostic software mainly focus on a comprehensive verification of the software's various intended uses, including basic software operation tests, interactive operation tests, core business function tests, and abnormal scenario adaptation tests.

[0021] The basic operation test checks whether the Android diagnostic software can start normally and remain stably in the vehicle diagnostic equipment system without issues such as crashes, lag, or loading failures. The interactive operation test examines routine operations such as clicking on the software interface, switching menus, and navigating pages to determine whether the software can accurately respond to operation commands. The core business function test is the focus of this test, mainly verifying whether the Android diagnostic software can normally complete professional diagnostic tasks such as reading vehicle fault codes, collecting vehicle operation data streams, detecting the function of vehicle electronic control components, and matching parameters with programs, and verifying whether the output results meet the standard requirements. The abnormal scenario adaptation test simulates special working conditions such as excessive device resource consumption and communication interruption to test whether the Android diagnostic software can maintain its running status and provide reasonable prompts, comprehensively judging whether the overall operating status and performance of the Android diagnostic software meet the standards.

[0022] S102: In response to the functional test instruction, determine the functional test urgency value corresponding to each of the n Android diagnostic software, and obtain n functional test urgency values.

[0023] In this embodiment, n is a positive integer, and the vehicle diagnostic device includes the n Android diagnostic software programs.

[0024] After receiving and parsing the functional test command, the vehicle diagnostic equipment determines the functional test urgency value for any one of the n Android diagnostic software programs. It first collects the time interval from the current moment to the last completed functional test operation for the selected Android diagnostic software as the first interval duration, and simultaneously collects the time interval from the current moment to the last completed version update operation for the same Android diagnostic software as the second interval duration. Then, based on a preset correspondence, it calculates the first functional test urgency value corresponding to the first interval duration and the second functional test urgency value corresponding to the second interval duration. Finally, it combines these two values ​​to calculate the functional test urgency value corresponding to the currently selected Android diagnostic software. This process is repeated for all remaining Android diagnostic software programs, ultimately resulting in n functional test urgency values ​​for each of the n Android diagnostic software programs.

[0025] Assigning a corresponding functional testing urgency value to each Android diagnostic software allows for quantitative grading and priority differentiation of all diagnostic software under test. This makes the test execution order and resource allocation clearer and more reasonable, avoiding the waste of time and computing power caused by indiscriminate testing. It also facilitates prioritizing the testing of software with high urgency and wide impact, thereby improving the overall efficiency of the testing process.

[0026] S103: Determine the k functional test urgency values ​​that are greater than the preset functional test urgency values ​​among the n functional test urgency values.

[0027] In this embodiment, k is an integer less than n. After obtaining n functional test urgency values ​​corresponding to n Android diagnostic software, the vehicle diagnostic equipment retrieves preset functional test urgency values ​​stored in the system. Then, it compares each functional test urgency value with the preset functional test urgency value one by one, and determines whether each value meets the condition of being greater than the preset functional test urgency value. Finally, it obtains k functional test urgency values ​​from the n functional test urgency values ​​that are greater than the preset functional test urgency values.

[0028] By selecting k functional test urgency values ​​that are greater than the preset standard from n functional test urgency values, we can accurately identify functional test objects with higher priority and those that need to be processed first, avoiding indiscriminate testing of all functions and effectively reducing unnecessary testing time and system resource consumption.

[0029] S104: Determine the k Android diagnostic software corresponding to the k functional test urgency values.

[0030] In this embodiment, based on the one-to-one correspondence between the functional test urgency values ​​and Android diagnostic software, a reverse matching query is performed to determine the software object to which each functional test urgency value that meets the conditions belongs, and finally the k Android diagnostic software corresponding to the k functional test urgency values ​​are determined.

[0031] S105: Perform functional testing on the k Android diagnostic software programs to obtain k functional test results.

[0032] In this embodiment, the complete functional test operations of these k Android diagnostic software can be performed sequentially according to a predetermined process. Each Android diagnostic software is started one by one and completes various tasks such as software running status detection, interface interaction detection, and core diagnostic business detection according to preset test steps. The running data, operation feedback, and function execution status generated by each Android diagnostic software during the test are recorded simultaneously. After the test process of all k Android diagnostic software is completed in sequence, the functional test results corresponding to each Android diagnostic software are summarized, and finally, k functional test results corresponding to the k Android diagnostic software are obtained.

[0033] As can be seen, upon receiving the functional test instruction, the system first calculates the urgency value of the functional tests for all Android diagnostic software within the vehicle diagnostic equipment. Then, it selects software whose values ​​exceed the preset standard for testing. This prioritizes testing Android diagnostic software with higher operational risks and greater need for verification, avoiding blindly performing tests on all software. This effectively reduces invalid testing steps, shortens the overall testing time, and improves the testing efficiency of the vehicle diagnostic equipment. At the same time, targeted functional verification of key software can promptly identify software issues that have not been tested for a long time or have anomalies after version updates. This ensures that all types of Android diagnostic software can reliably perform their diagnostic functions and also makes reasonable use of the vehicle diagnostic equipment's resources.

[0034] Please see Figure 2 , Figure 2 This application provides a flowchart for determining the urgency values ​​of n functional tests, including but not limited to the following steps: S201: Obtain the first interval time between the current time and the last time the first Android diagnostic software performed a functional test operation, and the second interval time between the current time and the last time the first Android diagnostic software performed a version update operation.

[0035] In this embodiment, the first Android diagnostic software is any one of the n Android diagnostic software programs.

[0036] Since the first Android diagnostic software is any one of the n Android diagnostic software, the method for determining the urgency value of the functional test corresponding to the first Android diagnostic software is the same as the method for determining the urgency value of the functional test corresponding to each of the n Android diagnostic software. Therefore, the urgency value of the functional test corresponding to each of the n Android diagnostic software can be determined according to the method for determining the urgency value of the functional test corresponding to the first Android diagnostic software, thus obtaining n urgency values ​​of the functional test.

[0037] The first interval duration refers to the first Android diagnostic software in the vehicle diagnostic equipment. It is the length of time since the first Android diagnostic software last completed a functional test operation from the current statistical time. This duration can intuitively reflect how close the first Android diagnostic software is to the most recent functional test. The larger the duration value, the longer the first Android diagnostic software has not undergone functional verification, and the higher the probability of malfunction.

[0038] The second interval refers to the first Android diagnostic software in the vehicle diagnostic equipment. It is the length of time since the first Android diagnostic software last completed a version update operation from the current statistical time. After the software completes a version update, it is often prone to problems such as compatibility failure and functional failure. This interval can reflect the running time of the first Android diagnostic software after the version update is completed. The shorter the interval, the more necessary it is to carry out functional testing.

[0039] Vehicle diagnostic equipment can retrieve internally stored operation logs and operation records to locate the time node when the first Android diagnostic software last completed a functional test operation. It can then calculate the time span between the two times by combining the current time to obtain the first interval duration. Simultaneously, it can continue to query log information to find the time node corresponding to the last version update operation of the first Android diagnostic software. By comparing this time with the current time, it can calculate the time span between the two time points to obtain the second interval duration.

[0040] S202: Determine the first functional test urgency value corresponding to the first interval duration and the second functional test urgency value corresponding to the second interval duration.

[0041] In this embodiment, it can be a first mapping relationship between a preset functional test interval duration and a functional test urgency value. Based on this first mapping relationship, the first functional test urgency value corresponding to the first interval duration can be determined.

[0042] It can be a second mapping relationship between a preset version update interval and a functional test urgency value. Based on this second mapping relationship, the second functional test urgency value corresponding to the second interval can be determined.

[0043] S203: Determine the functional test urgency value corresponding to the first Android diagnostic software based on the first functional test urgency value and the second functional test urgency value.

[0044] In this embodiment, the urgency values ​​of the first and second functional tests can be fused according to preset calculation rules and weight ratios. Taking into account the time elapsed since the last functional test of the first Android diagnostic software and the impact of the running status after the version update, a functional test urgency value corresponding to the first Android diagnostic software that can reflect the overall urgency of the test can be obtained.

[0045] It can be seen that by retrieving device logs, the time intervals between the last functional test and version update of Android diagnostic software can be accurately obtained. Using the pre-configured mapping relationship, the corresponding two urgency values ​​are obtained respectively. Then, the values ​​are fused according to the preset calculation rules and weights to finally obtain the functional test urgency value for each Android diagnostic software. By combining the two dimensions of test interval and version update status to judge the urgency of test requirements, software with potential operational risks can be accurately screened for functional testing, thus achieving precise allocation of test tasks.

[0046] Please see Figure 3 , Figure 3 This application provides a flowchart for determining the urgency value of a functional test corresponding to a first Android diagnostic software, including but not limited to the following steps: S301: Determine a reference functional test urgency value based on the first functional test urgency value and the second functional test urgency value.

[0047] In this embodiment, the urgency values ​​of the first functional test and the second functional test can be weighted, averaged, or weighted and fused according to preset calculation rules and weight allocation ratios. Combining the respective influence ratios of the first interval duration and the second interval duration on the test urgency, the two values ​​are comprehensively calculated to finally obtain a reference functional test urgency value that can comprehensively reflect the overall urgency of software testing.

[0048] For example, we can first determine the first weight corresponding to the urgency value of the first functional test and the second weight corresponding to the urgency value of the second functional test. The sum of the first weight and the second weight is 1. Specifically, we can pre-set the first weight and the second weight based on the actual application scenario, test management requirements, and the operating characteristics of the Android diagnostic software. The first weight corresponds to the urgency value of the first functional test and is used to reflect the influence of the software's historical test interval on the test priority. The second weight corresponds to the urgency value of the second functional test and is used to reflect the influence of the software version update interval on the test priority. We can flexibly allocate weights based on factors such as the frequency of use of vehicle diagnostic equipment, the frequency of software version iteration, and historical fault causes. If the software is more likely to cause operational failures if functional testing has not been carried out for a long time, we can appropriately increase the first weight and decrease the second weight accordingly. If compatibility issues and functional abnormalities are more likely to occur after a version update, we can increase the second weight and decrease the first weight.

[0049] S302: Obtain the frequency of fault occurrence of the first Android diagnostic software within a historical time period.

[0050] In this embodiment, the end time of the historical time period is earlier than the current time. The failure frequency of the first Android diagnostic software within the historical time period refers to the total number of times the vehicle diagnostic equipment retrieves its own stored historical operation logs, fault records, and abnormal alarm data, and counts various types of failures such as crashes, malfunctions, abnormal interactions, and diagnostic errors within a predefined historical time period. This is combined with the duration of the historical time period to calculate the failure frequency per unit time. This indicator can objectively reflect the past operational stability of the first Android diagnostic software. The higher the failure frequency, the greater the potential risks in the software's operation, and the more urgent the need for functional testing.

[0051] S303: Determine the adjustment parameters corresponding to the frequency of the fault occurrence.

[0052] In this embodiment, it can be a preset mapping relationship between the fault occurrence frequency and the adjustment parameter. Based on this mapping relationship, the adjustment parameter corresponding to the fault occurrence frequency can be determined.

[0053] S304: Adjust the reference functional test urgency value based on the adjustment parameters to obtain the functional test urgency value corresponding to the first Android diagnostic software.

[0054] In this embodiment, the urgency value of the functional test corresponding to the first Android diagnostic software can be calculated as follows: The urgency value of the first Android diagnostic software's corresponding functional test = reference functional test urgency value × (1 + adjustment parameters). The reference functional test urgency value can be adjusted based on the adjustment parameters in the above manner to obtain the functional test urgency value corresponding to the first Android diagnostic software.

[0055] As can be seen, by first combining the test interval and version update interval to obtain the reference functional test urgency value, and then introducing the past failure situation of the first Android diagnostic software to further optimize the result, and by comprehensively considering the software's historical operating status, long-term testing situation and version iteration situation, the final functional test urgency value is more in line with the actual operating risk of the software. It can accurately distinguish the testing priority of different software, and prioritize testing software with poor operating stability and frequent failures, effectively improving the overall operating reliability of Android diagnostic software in vehicle diagnostic equipment, thereby further optimizing the allocation and utilization efficiency of test resources.

[0056] Please see Figure 4 , Figure 4 This application provides a flowchart for determining k functional test results, including but not limited to the following steps: S401: Obtain the runtime resource utilization rate of each of the k Android diagnostic software, and obtain k runtime resource utilization rates.

[0057] In this embodiment, the runtime resource utilization rate of the Android diagnostic software refers to the proportion of hardware resources such as processor computing resources and memory storage resources occupied by the Android diagnostic software when it runs in the vehicle diagnostic device, relative to the total available resources of the device. The runtime resource utilization rate can intuitively reflect the current running load status of the software. An excessively high resource utilization rate will not only affect the stability of the software itself, but also drag down the overall operating efficiency of the device.

[0058] Resource data can be collected for each of the selected k Android diagnostic software programs, and the usage of core hardware resources such as the device processor and memory during the operation of each software can be detected in real time. The corresponding values ​​are recorded one by one, and finally, the resource usage rates corresponding to the k Android diagnostic software programs are collected and organized.

[0059] S402: Based on the k runtime resource utilization rates and the k functional test urgency values, determine the priority of each of the k Android diagnostic software programs to obtain k priorities.

[0060] In this embodiment, for any one of the k functional test urgency values, the Android diagnostic software corresponding to the functional test urgency value can be determined first, then the running resource utilization rate corresponding to the Android diagnostic software can be determined among the k running resource utilization rates, then the optimization factor corresponding to the Android diagnostic software can be determined, and the functional test urgency value can be optimized based on the optimization factor to obtain the target functional test urgency value corresponding to the Android diagnostic software.

[0061] Using the above method, the urgency values ​​of the k functional tests can be optimized based on the k resource utilization rates to obtain the urgency values ​​of the k target functional tests.

[0062] The urgency values ​​of the obtained k target functions are compared and sorted as a whole. Priority levels are assigned in descending order of the values. The higher the urgency value of the target function test, the more urgent the test requirement of the corresponding Android diagnostic software and the higher the operational risk. The higher the test priority is assigned, and vice versa. In this way, a corresponding level is assigned to each Android diagnostic software, and finally k priority levels are matched one by one.

[0063] By combining the utilization rate of operating resources with the urgency of functional testing to calculate priority, the urgency of testing diagnostic software and its actual operating status can be fully considered. By optimizing factors to reasonably adjust the urgency level, the unreasonable allocation of resources caused by relying solely on the urgency level can be avoided, effectively improving the rationality of test scheduling, reducing resource conflicts and test blockages, and ensuring that high-risk and high-urgency software is tested first, thereby improving the efficiency of functional test execution.

[0064] S403: Determine the functional test order corresponding to the k Android diagnostic software based on the k priorities.

[0065] In this embodiment, the Android diagnostic software is sorted and arranged according to its priority, with higher priority software placed at the beginning of the test sequence and lower priority software placed later. This clarifies the order in which all k Android diagnostic software are tested, ultimately forming a complete functional test sequence.

[0066] S404: Perform functional testing operations on the k Android diagnostic software based on the functional testing sequence to obtain the k functional test results.

[0067] In this implementation, a standardized functional testing process is initiated for each Android diagnostic software in the order of the established functional tests. Each function, operating status and interaction of the software is verified one by one, and various data and abnormal situations during the test are recorded in real time. After all k Android diagnostic software tests are completed, the test records for each software are summarized and organized to form a set of k corresponding functional test results.

[0068] As can be seen, by first collecting the resource usage of each Android diagnostic software, then combining the functional test urgency value to calculate the test priority, determining the functional test order based on the priority, and finally executing the tests in sequence and obtaining the functional test results, the system can fully combine the software load and test urgency to achieve intelligent scheduling, allowing high-risk and high-urgency software to be tested first, significantly improving the overall efficiency of diagnostic software functional testing.

[0069] Please see Figure 5 , Figure 5 This is another flowchart for determining k functional test results provided in this application, including but not limited to the following steps: S501: When performing functional testing on the second Android diagnostic software based on the functional testing sequence, obtain a pre-recorded test process file corresponding to the second Android diagnostic software.

[0070] In this embodiment, the second Android diagnostic software is any one of the k Android diagnostic software programs.

[0071] The pre-recorded test process file corresponding to the second Android diagnostic software can be generated by using a hidden switch built into the diagnostic software. Specifically, the switch can be activated by clicking the specified button five times in a row. After activation, a floating menu will be displayed on the interface, which includes options for starting to record the test process, stopping to record the test process, and loading the test process. The diagnostic software integrates process recording and storage capabilities. After the operator clicks to start recording the test process, they manually complete the entire set of test actions. The diagnostic software will automatically record each step of the operation and save the relevant content according to the preset format. After the test is completed, clicking to stop recording the test process will save the operation record completely to the device's local storage, forming a unique test process file.

[0072] It should be explained that the diagnostic device can be configured to hide the start switch and the floating menu. The hidden switch can be activated by repeatedly clicking a specified button and has an anti-accidental touch mechanism. When activated, a floating operation menu is displayed at the top of the application interface. The menu includes function options such as start recording test process, stop recording test process, and load test process. The floating menu does not interfere with the normal business process of the application and has state switching logic such as idle, recording, recorded, executing, and execution completed, thereby ensuring the stability and reliability of functional testing operations.

[0073] It should be noted that the test process file can be generated in advance using the software's built-in recording function and saved locally on the diagnostic device. After the recording function is enabled in a specific way, the entire process of manually completing the test operation will be completely recorded. The file contains all the operation actions, execution order, operation specifications, and corresponding testing standards in an orderly manner, which can completely restore the entire test process and can be repeatedly called, thereby achieving standardized and automated functional testing.

[0074] The test process file can include the specific meaning, value range and usage rules of fields such as interface name, interface type, control type, operation object and interface number. It can also specify the corresponding handling methods for abnormal situations such as missing fields, discontinuous numbers, mismatched interface names, and non-existent operation objects. It can also include the file storage path, naming rules, version identifier and overwrite strategy, so that the test process record file has a unified format and standard, ensuring that those skilled in the art can accurately implement and reproduce it.

[0075] It should be explained that the pre-recorded test process files can also be implemented using other data formats such as Extended Markup Language, Structured Data Format, and custom binary format. These formats can all completely record test process information such as interface name, interface type, operation object, and interface number, achieving the same function of recording and automatic execution.

[0076] It should be explained that, since the second Android diagnostic software is any one of the k Android diagnostic software, the functional test operation corresponding to the second Android diagnostic software is the same as the functional test operation corresponding to any one of the k Android diagnostic software. When performing functional test operations on the k Android diagnostic software based on the functional test order, the functional test operation corresponding to the second Android diagnostic software can be performed on any one of the k Android diagnostic software.

[0077] When the functional tests proceed to the second Android diagnostic software, the test process file, which is pre-recorded and specifically adapted to the diagnostic software, is automatically retrieved from local storage.

[0078] When testing a specified Android diagnostic software in the order of functional testing, directly obtaining the pre-recorded corresponding test process file can save the steps of reconfiguring the test environment, writing test scripts, and repeating manual operations, ensuring that the test process is fixed and consistent, without omissions or deviations, and greatly improving the test startup speed and execution efficiency.

[0079] S502: Based on the test process file, determine the a functional test execution steps corresponding to the second Android diagnostic software.

[0080] In this embodiment, 'a' is a positive integer. The 'a' functional test execution steps corresponding to the second Android diagnostic software are a series of ordered operation steps parsed and extracted from the test process file corresponding to the second Android diagnostic software. These functional test execution steps are arranged in the order of actual testing and cover the triggering operations, detection actions, status checks, and result verification of various functions of the software. Each functional test execution step has clear execution requirements, and the combination of all functional test execution steps can complete the complete functional test of the diagnostic software.

[0081] S503: Execute the a functional test execution steps sequentially to complete the functional test operation on the second Android diagnostic software and obtain the functional test results corresponding to the second Android diagnostic software.

[0082] In this embodiment, the a functional test execution steps are run sequentially, and each operation, function verification and status check is completed one by one. The full functional test of the second Android diagnostic software is carried out. The software running status, function response and various test data are recorded throughout the process. After all steps are completed, all test information is integrated and summarized to finally generate the functional test results corresponding to the second Android diagnostic software.

[0083] It should be explained that during the functional testing of the second Android diagnostic software by sequentially executing the aforementioned a functional test steps, it is first determined whether the currently displayed interface is the interface with the specified sequence number. If the current interface is the target sequence number interface, the click and other operations are automatically executed according to the test steps. If the current interface is not the target sequence number interface, it is automatically redirected to the target sequence number interface first, and then the corresponding click operation is executed. The test is completed interface by interface and step by step according to this logic until the test steps of the last interface are executed, at which point all test operations are stopped, and the functional test of the second Android diagnostic software is finally completed, and the corresponding functional test results are obtained.

[0084] It should be explained that the functional test results of Android diagnostic software can include the execution status of each operation step in the entire test process, whether the interface jump is normal, whether various click operations can be responded to smoothly, the running performance of various functions of the software, and record the actual situation of each test item and the comparison information with the preset standard, abnormal prompts, lag or fault problems that occur during operation, and can also summarize the test completion status of all interfaces and the comprehensive judgment conclusion on whether the overall test meets the standard.

[0085] For example, after loading the test process file, you can first obtain the currently displayed interface information and determine whether it is the starting interface specified by the process. If it is the starting interface, the corresponding click operation is executed directly. If it is not the starting interface, you can automatically jump to the starting interface according to the page routing rules, and then execute the subsequent operations in sequence according to the interface number. During the execution, you can also set timeout judgment, retry mechanism and abnormal exit rules to ensure that the test process can be completed automatically in a stable and orderly manner.

[0086] It should be noted that, since the second Android diagnostic software is any one of the k Android diagnostic software, the k Android diagnostic software are subjected to functional testing operations according to the functional testing order and based on the determination method of the functional test results corresponding to the second Android diagnostic software, so as to obtain the k functional test results.

[0087] As can be seen, by conducting the testing of diagnostic software one by one according to the preset test sequence, and by retrieving the exclusive pre-recorded test process file for each diagnostic software, breaking down the standardized test steps and executing them automatically, it is possible to not only unify the operation specifications of all test links, avoid the action deviations and process omissions caused by manual operation, and ensure that the test standards are consistent and the results are objective and reliable, but also to achieve automated testing with the help of preset processes, which can greatly reduce the workload of manual intervention and improve the overall functional testing efficiency of diagnostic equipment.

[0088] Please see Figure 6 , Figure 6 This is a flowchart illustrating a method for determining functional test prompt information, including but not limited to the following steps: S601: Obtain the expected function test results for each of the k Android diagnostic software programs, and obtain k expected function test results.

[0089] In this embodiment, the expected functional test results for the Android diagnostic software are pre-set standard reference contents. These standards clearly define the normal state, passing indicators, and judgment criteria that each test step, interface transition, click response, and function operation should exhibit. They also define the range of normal operation and are used to compare with the results obtained from actual tests to determine whether the software functions meet the standards and whether there are any abnormalities in its operation. The pre-set standard test data and normal operating status of each Android diagnostic software are retrieved, and reference criteria for each software are compiled. Finally, k sets of expected functional test results corresponding to k Android diagnostic software are obtained.

[0090] S602: Compare the k functional test results with the k expected functional test results to obtain m Android diagnostic software that pass the functional test and km Android diagnostic software that fail the functional test.

[0091] In this embodiment, m is an integer less than or equal to k. The execution status of each test step, interface transition status, operation response effect, and functional performance of each individual diagnostic software can be checked item by item. The measured data, operating status, and preset standard requirements and normal indicators are meticulously compared. If the actual performance of all test items of a software completely matches the expected standard, without any response delay, interface transition error, functional failure, or operational abnormality, the software is deemed to have passed the functional test. If the actual result of any test item deviates from the preset standard, resulting in functional failure, operational abnormality, or inconsistent status, the software is deemed to have failed the functional test. By comparing the k functional test results with the k expected functional test results using the above method, m Android diagnostic software programs that pass the functional test and km Android diagnostic software programs that fail the functional test are obtained.

[0092] S603: Generate first functional test prompt information based on the m Android diagnostic software.

[0093] In this embodiment, the first functional test prompt information is used to indicate that the functional tests of the m Android diagnostic software are qualified.

[0094] For the m Android diagnostic software programs that have passed functional testing after comparison, relevant information such as the corresponding software identifier, test number, and overall verification conclusion is integrated to generate a dedicated first functional test prompt message. This first functional test prompt message clearly marks the names or numbers of these software programs, explicitly informing relevant personnel that all test items for these software programs meet the preset standards, and the overall functional test result is qualified. It intuitively presents the verification conclusion, allowing staff to quickly understand the list of qualified software programs and the overall test status.

[0095] The first functional test prompt information can be presented through device interface pop-ups, text status bar displays, list page annotations, etc. The prompt content mainly includes the total number of software participating in this test, the name or number of qualified software, the overall verification conclusion of each test item, and clearly indicates that all functions of this batch of software meet the preset standards and the test result is qualified.

[0096] For example, the first functional test prompt message could be: A total of ten Android diagnostic software programs were tested. Six of them passed the test. A text prompt will pop up on the device interface, indicating that the test is complete. All test items of Android diagnostic software programs numbered 1, 2, 3, 5, 7, and 9 ran normally, and all indicators met the standards. The functional test results are qualified.

[0097] S604: Generate a second function test prompt message based on the km of Android diagnostic software.

[0098] In this embodiment, the second functional test prompt information is used to indicate that the functional test of the km Android diagnostic software failed.

[0099] For the km of Android diagnostic software deemed unqualified for functional testing after comparison, relevant information such as the corresponding software identifier, test number, abnormal items, problem description, and overall verification conclusion is integrated to generate a dedicated second functional test prompt message. This second functional test prompt message clearly marks these software names or numbers, lists the abnormal test steps and specific problems for each software, and clearly informs relevant personnel that these software items do not meet the preset standards, resulting in an overall functional test failure. It intuitively presents the problem details and verification conclusion, facilitating staff to quickly locate the problematic software and specific fault points.

[0100] The second function test prompt information can be presented through device interface pop-ups, text status bar displays, red-highlighted notes on list pages, and display of anomaly list pages. The prompt content mainly includes the total number of software participating in this test, the name or number of the unqualified software, the test steps for the corresponding software that caused the anomaly, the type of functional failure, and the overall verification conclusion. It also clearly indicates that the batch of software has functional anomalies, that various indicators do not fully meet the standards, and that the functional test result is unqualified.

[0101] For example, the second functional test prompt message could be: A total of ten Android diagnostic software programs were tested. Four of them failed the test. A text prompt will pop up on the device interface, indicating that the test is complete. Android diagnostic software programs numbered four, six, eight, and ten have functional abnormalities. The running status of some test items does not meet the preset standards, and the functional test results are unqualified. Specifically, software number four has an interface jump error, software number six has a click operation response failure, software number eight has some functions running sluggishly, and the test results of software number ten are inconsistent with the standards.

[0102] S605: Display the first function test prompt information and the second function test prompt information on the display interface of the vehicle diagnostic equipment.

[0103] In this embodiment, the display interface of the vehicle diagnostic equipment can simultaneously or separately display the first function test prompt information and the second function test prompt information in various combinations. It can scroll to display concise conclusions in the status bar at the top of the interface, or pop up the corresponding prompt content sequentially through independent pop-ups. It can also be presented in a dedicated test result list page with separate columns for qualified and unqualified software. Qualified entries are displayed in normal font and marked with the word "qualified", while unqualified entries are distinguished by eye-catching font or background color. At the same time, the number of each software and the overall test conclusion are fully displayed. For unqualified software, a specific description of the abnormal problem is also provided. When the staff views the interface, they can clearly distinguish between the two types of results and have a comprehensive understanding of the test status of all Android diagnostic software.

[0104] As can be seen, by first retrieving the standard functional test results of each software as a reference, and then comparing the actual functional test data with the standards item by item to classify the software as qualified and unqualified, and generating corresponding prompts and displaying them uniformly on the device interface, the objectivity and accuracy of the test judgment can be guaranteed by relying on the preset standards, accurately distinguishing the quality of the software, identifying the faulty software and related issues, and intuitively presenting all test conclusions through visual prompts, making it convenient for staff to quickly sort out the overall functional test situation, thereby improving the overall efficiency of functional test result review, problem investigation, and subsequent rectification work.

[0105] In summary, implementing the embodiments of the present invention has the following beneficial effects: As can be seen, the functional testing method for Android diagnostic software described in this embodiment of the invention is applied to vehicle diagnostic equipment based on the Android system. First, a functional test instruction for the vehicle diagnostic equipment is obtained. Then, in response to the functional test instruction, a functional test urgency value is determined for each of the n Android diagnostic software programs, resulting in n functional test urgency values. Next, k functional test urgency values ​​greater than a preset functional test urgency value are determined. Then, k Android diagnostic software programs corresponding to the k functional test urgency values ​​are determined. Finally, functional test operations are performed on the k Android diagnostic software programs to obtain k functional test results. Using the embodiment of this application improves the testing efficiency of Android diagnostic software in vehicle diagnostic equipment.

[0106] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a functional testing device for Android diagnostic software provided in an embodiment of this application. The functional testing device 700 for Android diagnostic software is applied to vehicle diagnostic equipment based on the Android system. The functional testing device 700 for Android diagnostic software includes: an acquisition unit 701 and a processing unit 702. The acquisition unit 701 is used to acquire functional test instructions for the vehicle diagnostic equipment. The processing unit 702 is configured to respond to the functional test instruction, determine the functional test urgency value corresponding to each of the n Android diagnostic software, and obtain n functional test urgency values; n is a positive integer, and the vehicle diagnostic device includes the n Android diagnostic software; Determine the k functional test urgency values ​​that are greater than the preset functional test urgency value from among the n functional test urgency values; k is an integer less than n; Determine the k Android diagnostic software programs corresponding to the k functional test urgency values; Perform functional tests on the k Android diagnostic software programs to obtain k functional test results.

[0107] In some possible implementations, in determining the functional test urgency value corresponding to each of the n Android diagnostic software programs to obtain n functional test urgency values, the processing unit 702 is specifically used for: The first interval between the current time and the last functional test operation of the first Android diagnostic software is obtained, and the second interval between the current time and the last version update operation of the first Android diagnostic software is obtained; the first Android diagnostic software is any one of the n Android diagnostic software; Determine the first functional test urgency value corresponding to the first interval duration and the second functional test urgency value corresponding to the second interval duration; The functional test urgency value corresponding to the first Android diagnostic software is determined based on the first functional test urgency value and the second functional test urgency value.

[0108] In some possible implementations, in determining the functional test urgency value corresponding to the first Android diagnostic software based on the first functional test urgency value and the second functional test urgency value, the processing unit 702 is specifically used for: A reference functional test urgency value is determined based on the first functional test urgency value and the second functional test urgency value; Obtain the frequency of fault occurrence of the first Android diagnostic software within a historical time period; the end time of the historical time period is earlier than the current time. Determine the adjustment parameters corresponding to the frequency of the fault occurrence; Based on the adjustment parameters, the reference functional test urgency value is adjusted to obtain the functional test urgency value corresponding to the first Android diagnostic software.

[0109] In some possible implementations, in performing functional testing operations on the k Android diagnostic software programs to obtain k functional test results, the processing unit 702 is specifically used for: Obtain the runtime resource utilization rate of each of the k Android diagnostic software, and obtain k runtime resource utilization rates; Based on the k runtime resource utilization rates and the k functional test urgency values, the priority of each of the k Android diagnostic software is determined, resulting in k priorities; The functional testing order of the k Android diagnostic software is determined based on the k priorities. Based on the aforementioned functional test sequence, functional tests are performed on the k Android diagnostic software programs to obtain the k functional test results.

[0110] In some possible implementations, in performing functional testing operations on the k Android diagnostic software based on the functional testing sequence to obtain the k functional test results, the processing unit 702 is specifically used for: When performing functional testing on the second Android diagnostic software based on the aforementioned functional testing sequence, a pre-recorded test process file corresponding to the second Android diagnostic software is obtained; the second Android diagnostic software is any one of the k Android diagnostic software programs. Based on the aforementioned test process document, determine a functional test execution steps corresponding to the second Android diagnostic software; where a is a positive integer. The a-th functional test execution steps are executed sequentially to complete the functional test operation on the second Android diagnostic software and obtain the corresponding functional test results of the second Android diagnostic software.

[0111] In some possible implementations, the processing unit 702 is further specifically used for: Obtain the expected function test results for each of the k Android diagnostic software, and obtain k expected function test results; The k functional test results are compared with the k expected functional test results to obtain m Android diagnostic software that pass the functional test and km Android diagnostic software that fail the functional test; m is an integer less than or equal to k. A first functional test prompt message is generated based on the m Android diagnostic software programs; the first functional test prompt message is used to indicate that the functional tests of the m Android diagnostic software programs are qualified. A second functional test prompt message is generated based on the km Android diagnostic software; the second functional test prompt message is used to indicate that the functional test of the km Android diagnostic software has failed. The first function test prompt information and the second function test prompt information are displayed on the display interface of the vehicle diagnostic equipment.

[0112] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 8 As shown, the electronic device 800 is applied to a vehicle diagnostic device based on the Android system. The electronic device 800 includes a transceiver 801, a processor 802, and a memory 803. These are connected via a bus 804. The memory 803 stores computer programs and data, and the transceiver 801 can transmit data stored in the memory 803 to the processor 802. The program includes instructions for performing the following steps: Obtain functional test instructions for the vehicle diagnostic equipment; In response to the functional test command, the functional test urgency value corresponding to each of the n Android diagnostic software is determined, resulting in n functional test urgency values; n is a positive integer, and the vehicle diagnostic equipment includes the n Android diagnostic software. Determine the k functional test urgency values ​​that are greater than the preset functional test urgency value from among the n functional test urgency values; k is an integer less than n; Determine the k Android diagnostic software programs corresponding to the k functional test urgency values; Perform functional tests on the k Android diagnostic software programs to obtain k functional test results.

[0113] In some possible implementations, the above procedure includes instructions for performing the following steps in order to determine the functional test urgency value for each of the n Android diagnostic software programs and obtain n functional test urgency values: The first interval between the current time and the last functional test operation of the first Android diagnostic software is obtained, and the second interval between the current time and the last version update operation of the first Android diagnostic software is obtained; the first Android diagnostic software is any one of the n Android diagnostic software; Determine the first functional test urgency value corresponding to the first interval duration and the second functional test urgency value corresponding to the second interval duration; The functional test urgency value corresponding to the first Android diagnostic software is determined based on the first functional test urgency value and the second functional test urgency value.

[0114] In some possible implementations, the above procedure includes instructions for performing the following steps in determining the functional test urgency value corresponding to the first Android diagnostic software based on the first functional test urgency value and the second functional test urgency value: A reference functional test urgency value is determined based on the first functional test urgency value and the second functional test urgency value; Obtain the frequency of fault occurrence of the first Android diagnostic software within a historical time period; the end time of the historical time period is earlier than the current time. Determine the adjustment parameters corresponding to the frequency of the fault occurrence; Based on the adjustment parameters, the reference functional test urgency value is adjusted to obtain the functional test urgency value corresponding to the first Android diagnostic software.

[0115] In some possible implementations, in performing functional testing on the k Android diagnostic software programs to obtain k functional test results, the above program includes instructions for performing the following steps: Obtain the runtime resource utilization rate of each of the k Android diagnostic software, and obtain k runtime resource utilization rates; Based on the k runtime resource utilization rates and the k functional test urgency values, the priority of each of the k Android diagnostic software is determined, resulting in k priorities; The functional testing order of the k Android diagnostic software is determined based on the k priorities. Based on the aforementioned functional test sequence, functional tests are performed on the k Android diagnostic software programs to obtain the k functional test results.

[0116] In some possible implementations, in order to perform functional testing operations on the k Android diagnostic software based on the functional testing sequence and obtain the k functional test results, the above procedure includes instructions for performing the following steps: When performing functional testing on the second Android diagnostic software based on the aforementioned functional testing sequence, a pre-recorded test process file corresponding to the second Android diagnostic software is obtained; the second Android diagnostic software is any one of the k Android diagnostic software programs. Based on the aforementioned test process document, determine a functional test execution steps corresponding to the second Android diagnostic software; where a is a positive integer. The a-th functional test execution steps are executed sequentially to complete the functional test operation on the second Android diagnostic software and obtain the corresponding functional test results of the second Android diagnostic software.

[0117] In some possible implementations, the above procedure includes instructions for performing the following steps: Obtain the expected function test results for each of the k Android diagnostic software, and obtain k expected function test results; The k functional test results are compared with the k expected functional test results to obtain m Android diagnostic software that pass the functional test and km Android diagnostic software that fail the functional test; m is an integer less than or equal to k. A first functional test prompt message is generated based on the m Android diagnostic software programs; the first functional test prompt message is used to indicate that the functional tests of the m Android diagnostic software programs are qualified. A second functional test prompt message is generated based on the km Android diagnostic software; the second functional test prompt message is used to indicate that the functional test of the km Android diagnostic software has failed. The first function test prompt information and the second function test prompt information are displayed on the display interface of the vehicle diagnostic equipment.

[0118] It should be understood that the electronic devices mentioned in this application may include smartphones (such as Android phones, iOS phones, Windows Phones, etc.), tablets, PDAs, laptops, mobile internet devices (MIDs) or wearable devices, servers, edge computing nodes, etc. The above-mentioned electronic devices are merely examples and not exhaustive, and include, but are not limited to, the electronic devices described above.

[0119] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the methods described in the above method embodiments.

[0120] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0121] It should be noted that, for the sake of simplicity, the aforementioned methods are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are optional, and the actions and modules involved are not necessarily essential to this application.

[0122] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0124] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0125] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0126] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0127] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0128] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The above description of the embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A functional testing method for Android diagnostic software, characterized in that, The method, applied to vehicle diagnostic equipment based on the Android system, includes: Obtain functional test instructions for the vehicle diagnostic equipment; In response to the functional test command, the functional test urgency value corresponding to each of the n Android diagnostic software is determined, resulting in n functional test urgency values; n is a positive integer, and the vehicle diagnostic equipment includes the n Android diagnostic software. Determine the k functional test urgency values ​​that are greater than the preset functional test urgency value from among the n functional test urgency values; k is an integer less than n; Determine the k Android diagnostic software programs corresponding to the k functional test urgency values; Perform functional tests on the k Android diagnostic software programs to obtain k functional test results.

2. The method as described in claim 1, characterized in that, The process of determining the functional test urgency value for each of the n Android diagnostic software programs results in n functional test urgency values, including: The first interval between the current time and the last functional test operation of the first Android diagnostic software is obtained, and the second interval between the current time and the last version update operation of the first Android diagnostic software is obtained; the first Android diagnostic software is any one of the n Android diagnostic software; Determine the first functional test urgency value corresponding to the first interval duration and the second functional test urgency value corresponding to the second interval duration; The functional test urgency value corresponding to the first Android diagnostic software is determined based on the first functional test urgency value and the second functional test urgency value.

3. The method as described in claim 2, characterized in that, The step of determining the functional test urgency value corresponding to the first Android diagnostic software based on the first functional test urgency value and the second functional test urgency value includes: A reference functional test urgency value is determined based on the first functional test urgency value and the second functional test urgency value; Obtain the frequency of fault occurrence of the first Android diagnostic software within a historical time period; the end time of the historical time period is earlier than the current time. Determine the adjustment parameters corresponding to the frequency of the fault occurrence; Based on the adjustment parameters, the reference functional test urgency value is adjusted to obtain the functional test urgency value corresponding to the first Android diagnostic software.

4. The method as described in claim 3, characterized in that, The functional testing operation on the k Android diagnostic software programs, resulting in k functional test results, includes: Obtain the runtime resource utilization rate of each of the k Android diagnostic software, and obtain k runtime resource utilization rates; Based on the k runtime resource utilization rates and the k functional test urgency values, the priority of each of the k Android diagnostic software is determined, resulting in k priorities; The functional testing order of the k Android diagnostic software is determined based on the k priorities. Based on the aforementioned functional test sequence, functional tests are performed on the k Android diagnostic software programs to obtain the k functional test results.

5. The method as described in claim 4, characterized in that, The process of performing functional tests on the k Android diagnostic software based on the functional test sequence to obtain the k functional test results includes: When performing functional testing on the second Android diagnostic software based on the aforementioned functional testing sequence, a pre-recorded test process file corresponding to the second Android diagnostic software is obtained; the second Android diagnostic software is any one of the k Android diagnostic software programs. Based on the aforementioned test process document, determine a functional test execution steps corresponding to the second Android diagnostic software; where a is a positive integer. The a-th functional test execution steps are executed sequentially to complete the functional test operation on the second Android diagnostic software and obtain the corresponding functional test results of the second Android diagnostic software.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain the expected function test results for each of the k Android diagnostic software, and obtain k expected function test results; The k functional test results are compared with the k expected functional test results to obtain m Android diagnostic software that pass the functional test and km Android diagnostic software that fail the functional test; m is an integer less than or equal to k. A first functional test prompt message is generated based on the m Android diagnostic software programs; the first functional test prompt message is used to indicate that the functional tests of the m Android diagnostic software programs are qualified. A second functional test prompt message is generated based on the km Android diagnostic software; the second functional test prompt message is used to indicate that the functional test of the km Android diagnostic software has failed. The first function test prompt information and the second function test prompt information are displayed on the display interface of the vehicle diagnostic equipment.

7. A functional testing device for Android diagnostic software, characterized in that, A vehicle diagnostic device based on the Android system; the device includes: an acquisition unit and a processing unit; The acquisition unit is used to acquire functional test instructions for the vehicle diagnostic equipment; The processing unit is configured to respond to the functional test instruction, determine the functional test urgency value corresponding to each of the n Android diagnostic software programs, and obtain n functional test urgency values; n is a positive integer, and the vehicle diagnostic device includes the n Android diagnostic software programs; Determine the k functional test urgency values ​​that are greater than the preset functional test urgency value from among the n functional test urgency values; k is an integer less than n; Determine the k Android diagnostic software programs corresponding to the k functional test urgency values; Perform functional tests on the k Android diagnostic software programs to obtain k functional test results.

8. An electronic device, characterized in that, The method includes a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the one or more programs include instructions for performing the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-6.

Images