Self-adaptive Android device driver test process selection method and system

Through the adaptive Android device driver test process selection method, the test case library is dynamically generated and anomalies are monitored in real time. This solves the problems of delayed test process adjustment and resource waste in Android device driver testing, improves test efficiency and resource utilization, and generates detailed reports.

CN120780587APending Publication Date: 2025-10-14浪潮智能终端有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510680274.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-05-26
Publication Date
2025-10-14

AI Technical Summary

Technical Problem

The existing Android device driver testing cannot dynamically adjust the test process, resulting in delayed exception recovery, waste of resources, and low efficiency.

Method used

An adaptive Android device driver test process selection method is adopted. By collecting device hardware configuration information, a test case library is dynamically generated. The rule engine is used to match the optimal test process, monitor and handle exceptions in real time, and generate test reports.

Benefits of technology

It implements a test process that is adaptive to device characteristics, improves test efficiency, reduces manual intervention, optimizes resource utilization, and generates detailed test reports.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120780587A_ABST
    Figure CN120780587A_ABST
Patent Text Reader

Abstract

The invention relates to the field of intelligent devices, and particularly provides a self-adaptive Android device driver test process selection method and system, and the method comprises the following steps: S1, collecting hardware configuration and driver version information of a to-be-tested device; s2, dynamically generating a test case library based on the acquired equipment hardware component configuration; s3, matching an optimal test process option suitable for the equipment through a rule engine; s4, executing a test according to the matched test process options; s5, monitoring the test process in real time and automatically processing exceptions; and S6, generating a test report. Compared with the prior art, the method and the device have the advantages that the process test can be adaptively carried out, the normal operation of the equipment is not influenced, and certain intellectualization is realized.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of smart devices, and in particular to a method and system for providing an adaptive Android device driver test process selection method. Background Art

[0002] Currently, Android device driver testing has the following technical pain points:

[0003] 1. Static testing process: Traditional testing cannot be dynamically adjusted according to the hardware configuration of different devices (e.g., equipped with card readers, printers, barcode scanners, etc.);

[0004] 2. Delayed recovery from abnormalities: Manual intervention is required for diagnosis after test interruption, resulting in low efficiency;

[0005] 3. Waste of resources: The fixed testing process contains a large number of redundant steps and does not effectively utilize reusability.

[0006] Therefore, there is a need for a test process selection method and supporting system that can adapt to device characteristics, intelligently handle exceptions, and efficiently utilize resources. Summary of the Invention

[0007] The present invention aims to address the above-mentioned deficiencies in the prior art and provides a highly practical and adaptive Android device driver test process selection method.

[0008] A further technical task of the present invention is to provide a rationally designed, safe and applicable Android device driver test process selection system.

[0009] The technical solution adopted by the present invention to solve its technical problem is:

[0010] The adaptive Android device driver test process selection method has the following steps:

[0011] S1. Collect the hardware configuration and driver version information of the device under test;

[0012] S2. Dynamically generate a test case library based on the acquired device hardware component configuration;

[0013] S3. Use the rule engine to match the optimal test process option for the device;

[0014] S4. Execute the test according to the matched test process options;

[0015] S5, real-time monitoring of the test process and automatic handling of exceptions;

[0016] S6. Generate a test report.

[0017] Furthermore, in step S1, after the device to be tested is powered on, the hardware component configuration information of the device is obtained, and the corresponding component drivers are obtained according to the hardware configuration information.

[0018] Furthermore, in step S2, the test case processes generated based on the hardware components include a basic test process, a factory test process, and a stress test process;

[0019] In step S3, according to the hardware component configuration information of the current device and in combination with some generated test processes, the test execution path that is most suitable for each hardware component of the device is selected.

[0020] Furthermore, in step S4, based on the hardware component driver obtained in step S1, the driver is loaded into the execution memory, and the test execution begins according to the test execution path;

[0021] In step S5, during the test execution process, the execution status of the test process is monitored in real time, and normal test results and abnormal status information are recorded;

[0022] In step S6, a test report including the test results of the pass rate and failure rate of each component test process is finally generated.

[0023] Adaptive Android device driver test process selection system, including test process generation module, basic process module, test process matching module, test execution module, test exception handling module and test report generation module;

[0024] The test process generation module is used to generate a test process;

[0025] The basic process module is used to define the test functions of all hardware components;

[0026] The test process matching module is used to match the test process path suitable for the device;

[0027] The test execution module is used to load the component driver to execute the test according to the matched test process path;

[0028] The test exception handling module is used to solve the situation where an exception occurs when executing the test component drive;

[0029] The test report generation module is used to generate a test report for this test.

[0030] Furthermore, the test process generation module generates a test process applicable to the device according to the hardware components and device information of the device, and each test process corresponds to different test components and process paths.

[0031] Furthermore, in the basic process module, each individual hardware component has its own unique functional definition, which is defined and explained in detail in this module;

[0032] In the test process matching module, the information used for matching includes the hardware component configuration information of the device, the basic functions of the components defined in the basic process module, and the generated test process.

[0033] Furthermore, the test execution module is responsible for recording real-time test results and test logs;

[0034] When an abnormal situation occurs in the component driver executing the test, the test exception handling module will select an appropriate strategy according to the definition. The optional strategies include repeating the current erroneous function, skipping the current function, or terminating the current test process.

[0035] Furthermore, the test report generation module is used to generate a test report for this test based on the test execution status when the test is terminated. The test report content includes components that passed the test, components that failed the test, functional test failures of components, and error code information of test failures.

[0036] Compared with the prior art, the adaptive Android device driver test process selection method and system of the present invention has the following outstanding beneficial effects:

[0037] The present invention adaptively performs process testing when a device equipped with an Android system interacts with components, does not affect the normal operation of the device, and has a certain degree of intelligence. This system provides effective technical support for this method, does not require manual operation, is extremely convenient and applicable, makes up for the shortcomings of existing technologies, and has certain market value. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0039] Figure 1 This is a flow chart of an embodiment of an adaptive Android device driver test process selection method;

[0040] Figure 2 It is a system diagram of an adaptive Android device driver test process selection method. DETAILED DESCRIPTION

[0041] In order to enable those skilled in the art to better understand the solutions of the present invention, the present invention will be further described in detail below in conjunction with specific embodiments. Obviously, the embodiments described are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0042] A best embodiment is given below:

[0043] The adaptive Android device driver test process selection method in this embodiment has the following steps:

[0044] S1. Collect the hardware configuration and driver version information of the device under test;

[0045] After the device under test is powered on, the hardware configuration information of the device is obtained, including but not limited to the operating system version, memory usage, and component configuration list (whether it contains a card reader, a printer, a barcode scanner, and other modules, which will not be repeated here), and the corresponding component drivers are obtained based on this hardware configuration information.

[0046] S2. Dynamically generate a test case library based on the acquired device hardware component configuration;

[0047] The test case processes that can be generated based on hardware components include basic test process, factory test process, stress test process, etc.

[0048] S3. Use the rule engine to match the optimal test process option for the device;

[0049] According to the hardware component configuration information of the current device and in combination with some generated test processes, the test execution path that is most suitable for each hardware component of the device is selected.

[0050] S4. Execute the test according to the matched test process options;

[0051] According to the hardware component driver obtained in step S1, the driver is loaded into the execution memory, and the test is started according to the test execution path.

[0052] S5, real-time monitoring of the test process and automatic handling of exceptions;

[0053] During the test execution process, the execution status of the test process is monitored in real time, and normal test results and abnormal status information are recorded.

[0054] S6. Generate a test report;

[0055] Finally, a test report is generated that includes the test results such as the pass rate and failure rate of each component test process.

[0056] like Figure 1 As shown:

[0057] An adaptive Android device driver test process selection method includes the following steps:

[0058] S100: Collect the hardware configuration and driver version information of the device under test;

[0059] After the device under test is powered on, obtain the device's hardware component configuration list and each component's manufacturer, interface type, firmware version, driver installation status, driver version, and other information. Based on this component information, obtain the corresponding component driver.

[0060] S200: Dynamically generate a test case library based on the acquired device hardware component configuration;

[0061] Generate a basic test process based on the hardware components of the device. The basic test process includes all functional tests of all components.

[0062] Generate a factory test process based on the hardware components of the equipment. The factory test process includes the factory test function of the components and meets the most frequently used functional tests.

[0063] Generate a stress test process based on the hardware components of the device. The stress test process includes repeated functional tests of some components, and the number of repetitions and termination conditions can be set;

[0064] S300: Use the rule engine to match the optimal test process option for the device;

[0065] According to the hardware component configuration information of the current device and in combination with some generated test processes, the test execution path that is most suitable for each hardware component of the device is selected.

[0066] S400: Execute the test according to the matched test process options;

[0067] According to the hardware component driver obtained in step 1, the driver is loaded into the execution memory and the test is started according to the test execution path.

[0068] S500: monitors the test process in real time and automatically handles exceptions;

[0069] During the test execution process, the execution status of the test process is monitored in real time, and normal test results and abnormal status information are recorded.

[0070] S600: Generate a test report.

[0071] Finally, a test report is generated that includes the test results such as the pass rate and failure rate of each component test process.

[0072] Based on the above method, the adaptive Android device driver test process selection system in this embodiment includes a test process generation module, a basic process module, a test process matching module, a test execution module, a test exception handling module and a test report generation module;

[0073] The test flow generation module is used to generate test flows based on the device's hardware components and device information. These flows can include basic test flows, stress test flows, and factory test flows. Each test flow corresponds to different test components and flow paths.

[0074] The basic process module is used to define the test functions of all hardware components. Each individual hardware component has its own unique function definition, which is defined and explained in detail in this module.

[0075] The test process matching module is used to match the test process path suitable for the device. The information used for matching includes the device's hardware component configuration information, the basic functions of the components defined by the basic process module, and the generated test process.

[0076] The test execution module is used to load the component driver to execute the test according to the matched test process path, and is responsible for recording real-time test results and test logs.

[0077] The test exception handling module is used to resolve the situation when an exception occurs when executing the test component driver. It will select the appropriate strategy according to the definition. The optional strategies include repeating the current erroneous function, skipping the current function, terminating the current test process, etc.

[0078] The test report generation module is used to generate a test report for this test based on the test execution status when the test is terminated. The test report content includes information such as the components that passed the test, the components that failed the test, which function of the component failed the test, and the error code of the test failure.

[0079] like Figure 2 As shown:

[0080] The test flow generation module is used to generate test flows. Based on the device's hardware components and device information, it generates a test flow suitable for the device. Test flows can include basic test flows, stress test flows, and factory test flows. Each test flow corresponds to different test components and flow paths.

[0081] The basic process module is used to define the test functions of all hardware components. Each individual hardware component has its own unique function definition, which is defined and explained in detail in this module.

[0082] The test process matching module is used to match the test process path suitable for the device. The information used for matching includes the device's hardware component configuration information, the basic functions of the components defined by the basic process module, and the generated test process;

[0083] The test execution module is used to load the component driver to execute the test according to the matched test process path. It is also responsible for recording real-time test results and test logs.

[0084] The test exception handling module is used to select the appropriate strategy according to the definition when an exception occurs in the component driver executing the test. The optional strategies include repeating the current erroneous function, skipping the current function, terminating the current test process, etc.

[0085] The test report generation module is used to generate a test report for this test based on the test execution status when the test is terminated. The test report content includes information such as the components that passed the test, the components that failed the test, which function of the component failed the test, and the error code of the test failure.

[0086] Additionally, the test verification module records detailed operation logs and generates detailed test reports that document the test results. If a test fails, the tester can choose to provide relevant fault information to maintenance personnel.

[0087] The self-service terminal device will prompt whether it is necessary to use the first configuration file's attached information to perform driver repair based on the fault information.

[0088] The above-mentioned specific implementation methods are only specific cases of the present invention. The patent protection scope of the present invention includes but is not limited to the above-mentioned specific implementation methods. Any technical solutions that conform to the above-mentioned specific implementation methods of the present invention and any appropriate changes or substitutions made thereto by ordinary technicians in the relevant technical field shall fall within the patent protection scope of the present invention.

[0089] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. An adaptive Android device driver test process selection method, characterized in that: The steps are as follows: S1. Collect the hardware configuration and driver version information of the device under test; S2. Dynamically generate a test case library based on the acquired device hardware component configuration; S3. Use the rule engine to match the optimal test process option for the device; S4. Execute the test according to the matched test process options; S5, real-time monitoring of the test process and automatic handling of exceptions; S6. Generate a test report.

2. The adaptive Android device driver test process selection method according to claim 1, characterized in that: In step S1, after the device to be tested is powered on, the hardware component configuration information of the device is obtained, and the corresponding component drivers are obtained according to the hardware configuration information.

3. The adaptive Android device driver test process selection method according to claim 2, characterized in that: In step S2, the test case processes generated according to the hardware components include basic test process, factory test process and stress test process; In step S3, according to the hardware component configuration information of the current device and in combination with some generated test processes, the test execution path that is most suitable for each hardware component of the device is selected.

4. The adaptive Android device driver test process selection method according to claim 3, characterized in that: In step S4, according to the hardware component driver obtained in step S1, the driver is loaded into the execution memory, and the test is started according to the test execution path; In step S5, during the test execution process, the execution status of the test process is monitored in real time, and normal test results and abnormal status information are recorded; In step S6, a test report including the test results of the pass rate and failure rate of each component test process is finally generated.

5. Adaptive Android device driver test process selection system, characterized by: It includes test process generation module, basic process module, test process matching module, test execution module, test exception handling module and test report generation module; The test process generation module is used to generate a test process; The basic process module is used to define the test functions of all hardware components; The test process matching module is used to match the test process path suitable for the device; The test execution module is used to load the component driver to execute the test according to the matched test process path; The test exception handling module is used to solve the situation where an exception occurs when executing the test component drive; The test report generation module is used to generate a test report for this test.

6. The adaptive Android device driver test process selection system according to claim 5, characterized in that: The test process generation module generates a test process suitable for the device based on the hardware components and device information of the device. Each test process corresponds to different test components and process paths.

7. The adaptive Android device driver test process selection system according to claim 6, characterized in that: In the basic process module, each individual hardware component has its own unique function definition, which is defined and explained in detail in this module; In the test process matching module, the information used for matching includes the hardware component configuration information of the device, the basic functions of the components defined in the basic process module, and the generated test process.

8. The adaptive Android device driver test process selection system according to claim 7, characterized in that: Responsible for recording real-time test results and test logs in the test execution module; When an abnormal situation occurs in the component driver executing the test, the test exception handling module will select an appropriate strategy according to the definition. The optional strategies include repeating the current erroneous function, skipping the current function, or terminating the current test process.

9. The adaptive Android device driver test process selection system according to claim 8, characterized in that: The test report generation module is used to generate a test report for this test based on the test execution status when the test is terminated. The test report content includes the components that passed the test, the components that failed the test, the functional test failure of the components, and the error code information of the test failure.