TWI803376B - A test method and device for an android mobile device - Google Patents

Abstract

A test method for an Android mobile device, wherein a plurality of Android mobile devices electrically connected to a test device is tested, further comprising the following steps: (A) generating, by the test device, an initial test report, checking the SIM card type of each Android mobile device; (B) reading, by the test device, the class value of the initial test report and judging that it is the first preset value and executing the test script to generate a test command to the Android test suite; (C) making, by the test device, the Android test suite according to the test command re-tests the Android mobile devices corresponding to the first preset value and generating a re-test report; and (D) determining, by the test device, that the number of test failure items in the re-test report is greater than or equal to a threshold, repeating steps (A) to (C) until the number of test failure items reported by the re-test is less than the threshold.

Description

Android mobile device testing method and device

The present invention relates to a testing method, in particular to a testing method for Android mobile devices.

The known testing method of the Android mobile device is manually operated by the tester, and the tester needs to manually operate the Android mobile device to perform the next test step on the Android mobile device.

In addition, in the process of using the test suite, from the beginning to the end of the test, the tester can only estimate the time to generate the test report based on past experience. Generally speaking, it takes 3 days to generate the test report for manual testing. That is to say, the conventional testing methods for Android mobile devices are time-consuming and laborious, and the testing efficiency is low.

Therefore, how to save time and manpower for testing Android mobile devices and improve testing efficiency has become one of the issues to be solved in related technical fields.

Therefore, the object of the present invention is to provide a tester for an Android mobile device. A trial method can overcome at least one shortcoming of the above-mentioned prior art.

Thus, a test method for an Android mobile device provided by the present invention is to test a plurality of Android mobile devices electrically connected to it by a test device, and each Android mobile device can be configured with a specific user identification module; the test method includes the following Steps: (A) when the test device determines that one of the Android test suites generates an initial test report after performing an initial test on the Android mobile devices, the test device checks the specific user identification module of each Android mobile device category to confirm the category of each Android mobile device; (B) the test device reads a category value of the initial test report and executes a test script after judging that the category value is a first preset value to generate a corresponding A test command of the initial preset value is given to the Android test suite; (C) the test device makes the Android test suite according to the test command corresponding to the first default value, and the category and corresponding The Android mobile devices corresponding to the first preset value perform a retest and generate a retest report; and (D) when the test device judges that the number of failed test items in the retest report is greater than or equal to a threshold value, repeat the steps (A)~(C), until the number of failed items reported by the retest is less than the threshold.

In some implementations, the test method further includes the following steps before step (A): (a1) the test device generates the test script by executing a machine learning model; and (a2) the test device pre-obtains each The specific user of an Android mobile device identifies the category of the module to know the category of each Android mobile device.

In some implementations, in step (A), the test device determines that the safety When the Zhuo test suite does not generate the initial test report, perform the following steps: (E) the test device executes the test script to generate an initial test command to the Android test suite; and (F) the test device makes the Android test The kit performs the initial test on the Android mobile devices according to the initial test command to generate the initial test report, and returns to step (A).

In some implementation aspects, in step (A), each Android mobile device will be classified as having a telecom card, having a universal IC card, or having no card based on the specific user identification module therein being a telecom card, a general IC card or no card. Card or no card.

In some implementations, in step (a1), the test device generates the test script by inputting a test suite command parameter, a retry parameter and a category parameter, the test suite command parameter is related to setting the Android test suite The test command, the retry parameter is related to setting the number of retries of the Android test suite, and the category parameter is related to setting the category of the Android mobile devices corresponding to the Android test suite.

Another object of the present invention is to provide a testing device for an Android mobile device, which can overcome at least one of the disadvantages of the above-mentioned prior art.

Therefore, a test device for an Android mobile device provided by the present invention is used to test a plurality of Android mobile devices electrically connected to it, and each Android mobile device can be configured with a specific user identification module; the test device includes an interface module , a memory and a processor.

The interface module is electrically connected to the Android mobile devices.

The memory is used for storing an Android test suite and a pre-acquired initial test report related to the Android mobile devices.

The processor is connected to the interface module and the storage, and the processor obtains the specific user identification module of each Android mobile device through the interface module and after knowing the type of each Android mobile device, reads the storage After determining a class value in the initial test report of the storage and judging that the class value is a first default value, execute a test script to generate a test command corresponding to the first default value for the Android test The suite is configured to make the Android test suite perform a retest on the Android mobile devices whose category corresponds to the first preset value according to the test command corresponding to the first preset value and generate a retest report.

In some implementations, before the processor obtains the category of the specific user identification module of each Android mobile device through the interface module, the processor generates the test script by executing a machine learning model, and Obtain the category of the specific user identification module of each Android mobile device to know the category of each Android mobile device; and when the processor cannot read the initial test report from the storage, the processor executes the Test script, to generate an initial test command to the Android test suite, so that the Android test suite performs an initial test on the Android mobile devices according to the initial test command to generate the initial test report, and store the initial test report in that storage.

In some implementations, each Android mobile device will be classified as having a telecom card, with general IC card or without card.

In some implementations, the processor generates the test script by inputting a test suite command parameter, a retry parameter and a class parameter, the test suite command parameter is related to the test command for setting the Android test suite, the retry The parameter is related to setting the number of retries of the Android test suite, and the category parameter is related to setting the category of the Android mobile devices corresponding to the Android test suite for retrying.

The effect of the present invention is that: during the testing process of the test device, the processor first confirms that the first test report obtained in advance is stored in the memory, and obtains the first test report of each Android mobile device through the interface module. After the specific user identification module knows the category of each Android mobile device, read the category value stored in the initial test report in the memory and judge that the category value is the first preset value, and execute The test script is used to generate the test command corresponding to the first preset value to the Android test suite, so that the Android test suite can test the categories of the Android mobile devices according to the test command corresponding to the first preset value. The Android mobile devices corresponding to the first default value perform the retest and generate the retest report, and when the number of failed test items in the retest report is judged to be greater than or equal to the threshold, the above steps are automatically repeated ( A) ~ (C), until the number of failed items in the re-test report is less than the threshold, the test process for these Android mobile devices is ended, so that the tester does not need to manually operate the test device during the test Then the next test step can be carried out, which can effectively save the time and manpower for testing these Android mobile devices and improve the test efficiency.

1: Test device

11:Interface module

12: Storage

13: Processor

2:Android mobile device

3: Input device

S21~S29: Steps

Other features and effects of the present invention will be clearly presented in the implementation manner with reference to the drawings, wherein: FIG. 1 is a block diagram illustrating an embodiment of a testing device for an Android mobile device of the present invention; and FIG. 2 is a A flowchart illustrating how a processor of the testing device in FIG. 1 executes an embodiment of the testing method for an Android mobile device of the present invention.

Before the present invention is described in detail, it should be noted that in the following description, similar elements are denoted by the same numerals.

Referring to Fig. 1, it is an embodiment of the test device 1 of the Android mobile device of the present invention, which is used to test a plurality of Android mobile devices 2 electrically connected to it, and is suitable for being electrically connected with an input device 3, each Android mobile device 2 can be configured with a subscriber identity module (SIM for short), and the testing device 1 includes an interface module 11 , a storage 12 , and a processor 13 . The test device 1 can be implemented as a computer server or any electronic device with computing (computing) capability. The Android mobile devices 2 may include, for example, an Android tablet computer or any electronic device using an Android system. The input module 3 may include, for example, a mouse, a keyboard or any user input device. The interface module 11 is electrically connected to the Android mobile devices 2 . The storage 12 is used to store an Android test suite and a pre-acquired initial test report related to the Android mobile devices 2 . The Android test suite is, for example, the Vendor Test Suite (VTS for short) proposed by Google ^™ , the mobile service test suite (Google Mobile Services Test Suite, GTS for short) proposed by Google ^™ , the Security Test suite (Security Test Suite, referred to as STS), Compatibility Test Suite (Compatibility Test Suite, referred to as CTS) or any test suite suitable for Android mobile devices2.

The processor 13 is connected to the interface module 11 and the storage 12, and before the processor 13 obtains the category of the specific user identification module of each Android mobile device 2 through the interface module 11, it will execute a The machine learning model generates a test script according to a test suite command parameter, a retry parameter and a category parameter input by the input device 3, and obtains the category of the specific user identification module of each Android mobile device 2. In this embodiment, the machine learning model is a machine learning model combination tool library (may be but not limited to: combo.py), which is used to collect the information of each Android mobile device 2 (could be but not limited to, for example, the serial number ( S/N), telecom card number, relevant software and firmware version, network status (can be connected to internal network or external network) and other data parameters) to make corresponding operations (but not limited to, such as arranging the test The script correspondingly allocates, screens and excludes the Android mobile devices 2 that are not tested, updates the software and firmware version, connects to the external network test website, and adjusts the test items of the Android mobile devices 2 to be tested, such as the Android mobile devices 2 to be tested. If the Android mobile device 2 has missing components, you can arrange to test other executable test items first). In this embodiment, each Android mobile device 2 will be classified as having a telecom card, having a universal IC card or no card. And the test suite command parameter is related to setting the test command of the Android test suite, the retry parameter is related to setting the number of retries of the Android test suite, and the category parameter is related to the setting corresponding to the Android test suite when retrying. etc. android mobile device2 category. In other words, the test suite command parameter is used to set the test command of each Android test suite (for example, setting this test is to run the compatibility test suite), and the retry parameter is used to set the restart of each Android test suite. The number of times of testing, this category parameter is used to set the category of the Android mobile device 2 to be tested by each of the Android test suites (such as having a telecom card, having a general IC card or no card), for example, when the category parameter is 0, the Android The test suite will test all Android mobile devices 2. When the category parameter is 1, the Android test suite will test the Android mobile device 2 with a telecom card. When the category parameter is 2, the Android test suite will test the general Android mobile device with IC card2. The category parameter corresponds to the retry parameter, for example, when the category parameter is changed from 3 to 4, the retry parameter is also changed from 3 to 4, and so on.

When the processor 13 does not read the initial test report from the storage 12, the processor 13 executes the test script to generate an initial test command to the Android test suite, so that the Android test suite according to the initial test order, for such safety The mobile device 2 performs an initial test to generate the initial test report, and stores the initial test report in the storage 12 .

After the processor 13 obtains the specific user identification module of each Android mobile device 2 through the interface module 11 and knows the category of each Android mobile device 2, it reads the initial test report stored in the memory 12 After determining that the category value is a first preset value, execute the test script to generate a test command corresponding to the first preset value to the Android test suite, so that the Android test suite can be used according to the According to the test command of the first default value, a retest is performed on the Android mobile devices 2 whose category corresponds to the first default value among the Android mobile devices 2 and a retest report is generated, for example, if the The first default value is 1, and then the re-test is performed on those Android mobile devices 2 whose category is having a telecommunication card among the Android mobile devices 2 .

Hereinafter, referring to FIG. 1 and FIG. 2 , how the processor 13 cooperates with the interface module 11 , the storage 12 and the input device 3 to execute a testing method for an Android mobile device according to an embodiment of the present invention will be described in detail. The testing method of the Android mobile device includes the following steps S21-S29.

First, before testing the Android mobile devices 2, the processor 12 will first execute step 21. In step S21, the processor 13 executes the machine learning model and according to the input device 3 input The test suite command parameter, the retry parameter and the category parameter generate the test script. In this embodiment, the Android test suite is a compatibility test suite. It should be noted that the number of retries is related to the currently executed For the Android test suite, taking the compatibility test suite as an example, the recommended number of retries is 3 times, and it is recommended to set the number of retries in multiples of 3.

Next, the processor 12 executes step 22. In step S22, the processor 13 pre-acquires the category of the specific user identification module of each Android mobile device 2 through the interface module 11 to know that each Android mobile device 2 categories.

Then, the processor 12 executes step 23. In step S23, the processor 13 determines whether the storage 12 has the initial test report. If the judging result is affirmative, the processor 12 will execute step S26. On the contrary, if the determination result is negative, the processor 12 will execute step S24.

Therefore, in step S23, when the processor 13 judges that the initial test report does not exist in the storage 12, that is, when it is judged that the Android test suite does not generate the initial test report, in step S24, the processor 13. Execute the test script to generate the initial test command for the Android test suite.

Then, the processor 12 executes step 25. In step S25, the processor 13 makes the Android test suite perform the initial test on the Android mobile devices 2 according to the initial test command to generate the initial test report.

And, in order to confirm whether this Android test kit successfully produces this initial test report in step S25, this processor 13 returns to step S23, judges again whether there is this initial test report in this storage 12, if not (that is, this storage 12 when the initial test report does not exist), the processor 13 will repeatedly execute steps S24, S25 until the The processor 13 determines (in step S23 ) that the storage 12 has the initial test report.

Conversely, in step S23, when the processor 13 judges that the initial test report exists in the storage 12, that is, when it is judged that the Android test suite has produced the initial test report, the processor 12 executes step 26, and In step S26 , the processor 13 checks the category of the specific user identification module of each Android mobile device 2 to confirm the category of each Android mobile device 2 . It should be noted that the purpose of confirming the category of each Android mobile device 2 before each test is, firstly, to ensure that each Android mobile device 2 is successfully connected with the interface module 11, and secondly, the processor 12 After performing a complete test, operations such as factory reset or flash image file (flash image) will be performed on each Android mobile device 2 to confirm the software and Therefore, in step S26, the processor 13 needs to check the category of the specific user identification module of each Android mobile device 2 to confirm the category of each Android mobile device 2 .

Next, the processor 12 executes step 27. In step S27, the processor 13 reads the category value of the initial test report and executes the test script after judging that the category value is the first preset value, so as to generate The test command should be the first preset value to the Android test suite.

Then, the processor 12 executes step 28. In step S28, the processor 13 makes the Android test suite test the Android mobile devices 2 according to the test command corresponding to the first default value and the class and the first default value. The Android mobile devices corresponding to a preset value Set to 2 to perform a retest and generate a retest report.

Finally, the processor 12 executes step 29. In step S29, the processor 13 determines whether a test failure item number in the retest report is greater than or equal to a threshold. When the processor 13 judges that the number of test failure items in the retest report is greater than or equal to the threshold, the processor 13 repeats steps S26 to S28 until it is judged that the number of test failure items in the retest report is less than the threshold, Just finished the testing process to the Android mobile device 2. It should be noted that the threshold is usually set as a positive integer less than 10, such as 9, because when the number of test failure items is less than 10, the tester can manually check the remaining test failure items.

Table 1 exemplarily illustrates an aspect of the test-related parameters of the test method of the Android mobile device of the present invention after 1 test and 3 retests:

Referring to Table 1, in the present embodiment, in the retest (retest 1), since the category value in the initial test is 0, the Android test suite will test all the Android mobile devices 2 regardless of category . And in the subsequent retest (retest 2), because the category value of the previous retest (retest 1) is 1, the Android test suite will only test these Android mobile devices 2 with telecom cards , while retesting after In (retest 3), because the category value of previous retest (retest 2) is 2, so this android test suite can only be tested to these android mobile devices 2 with universal IC card.

Generally speaking, the number of retries is set to 3 times, because after the test method of the Android mobile device in this embodiment passes through 1 initial test and 3 retests, the number of failed items in the test can usually be converged to less than 10 (as shown in Table 1).

And when the number of retries is set to exceed 3 times, for example, the number of retries is set to 9, and the corresponding dialogue values (session) are 0~8 respectively, because the Android mobile devices 2 tested have three types different (with a telecommunication card, with a general-purpose IC card or without a card), therefore, the mode of taking the remainder is used here to convert the dialogue value into a category value as the category of these Android mobile devices 2 to be tested by the test command. For example, when 0, 3, 6 is divided by 3 and the remainder is 0, then the category value is 0 and means that all such Android mobile devices 2 need to be tested. Divide 1, 4, 7 by 3, and the remainder is 1, then the category value is 1 and means that those Android mobile devices 2 with telecom cards need to be tested. Divide 2, 5, 8 by 3, and the remainder is 2, then the category value is 2 and means that those Android mobile devices 2 that have common IC cards need to be tested. It should be noted that the class value described here refers to the class value of the processor 13 reading the last retest report as the next retest as the class of the Android mobile devices 2 to be tested by the test command. The category of the Android mobile devices 2 required to be tested by the test command.

It should be noted that, after the processor 13 executes the test script to perform multiple retests, the number of failed items in the test still cannot be converged to be no greater than When the threshold is reached, the processor 13 will generate a summary report. The summary report is related to the situation where the number of test failure items cannot be converged, and may include historical records of similar situations encountered by the processor 13 in the past when executing the test script. The historical record data records the disposal operation procedures at that time. The test script can be adjusted based on the historical record data. Before the processor 13 executes the test script to carry out the initial test of the Android mobile devices 2, the processor 13 will first confirm whether there are test failure items that could not be converged in the past in this test. If so, the processor 13 controls a display (not shown) to display a webpage dialog box, the text content of the webpage dialog box is related to the previously unconvergent test failure item to remind the testers to pay attention.

In addition, the processor 13 will also record the handling procedures for the test failure items in the past historical test reports during the process of executing the test script to test the Android mobile devices 2. When retesting next time, the processor 13 will When executing the test script to test these Android mobile devices 2, when the same test failure item is encountered, it will be processed according to the handling procedure of the corresponding test failure item in the past historical test report, which can speed up the testing process. When the processor 13 executes the test script to test the Android mobile devices 2, it will also be based on a plurality of conditions (for example, whether the Android mobile devices 2 have specific software equipment, hardware equipment, the Android mobile devices 2 or not). Whether the device 2 has successfully established a connection with the interface module 11) counts the correlation between these conditions and the results of the summary report, so as to find out the test method or test sequence that allows the most Android mobile devices 2 to pass the test.

In summary, since the test device 1 is in the testing process, the processor 13 first confirms that the first test report obtained in advance is stored in the memory 12, and then obtains each Android action through the interface module 11. After the specific user identification module of the device knows the category of each Android mobile device, it reads the category value stored in the initial test report of the memory 12 and determines that the category value is the first preset After setting the value, execute the test script to generate the test command corresponding to the first preset value to the Android test suite, so that the Android test suite acts on the Androids according to the test command corresponding to the first preset value The Android mobile devices 2 whose category corresponds to the first default value in the device 2 perform the retest and generate the retest report, and when it is judged that the number of failed test items in the retest report is greater than or equal to the threshold, The above-mentioned steps S26~S28 are automatically repeated until the number of failed items in the re-test report is less than the threshold, and the test process for the Android mobile devices 2 is ended, thereby eliminating the need for manual operation by the tester during the test The test device 1 can proceed to the next test step, which can effectively save time and manpower for testing the Android mobile devices 2 and improve test efficiency, and can indeed achieve the effect and purpose of the present invention.

But the above-mentioned ones are only embodiments of the present invention, and should not limit the scope of the present invention. All simple equivalent changes and modifications made according to the patent scope of the present invention and the content of the patent specification are still within the scope of the present invention. Within the scope covered by the patent of the present invention.

S21~S29: Steps

Claims (9)

A test method for an Android mobile device, a plurality of Android mobile devices electrically connected to it are tested by a test device, each Android mobile device can be configured with a specific user identification module; the test method comprises the following steps: (A) the test When the device judges that one of the Android test suites generates an initial test report after performing an initial test on the Android mobile devices, the test device checks the category of the specific user identification module of each Android mobile device to confirm that each Android mobile device has an initial test report. the category of the mobile device; (B) the test device reads a category value of the initial test report and executes a test script after judging that the category value is a first preset value, to generate a corresponding to the first default value The test command is given to the Android test suite; (C) the test device makes the Android test suite correspond to the first default value according to the test command corresponding to the first default value, and the category of the Android mobile devices corresponds to the first default value The Android mobile devices perform a re-test and generate a re-test report; and (D) when the test device judges that the number of test failure items in the re-test report is greater than or equal to a threshold value, repeat steps (A)~(C) until the number of failed items reported by the retest is less than the threshold. The testing method for an Android mobile device as described in Claim 1, wherein, the following steps are also included before step (A): (a1) the testing device generates the test script by executing a machine learning model; and (a2) The test device obtains the category of the specific user identification module of each Android mobile device in advance to know the category of each Android mobile device. The testing method of the Android mobile device as described in claim item 1, wherein, in step (A), when the test device judges that the Android test suite does not produce the initial test report, the following steps are performed: (E) the test device Execute the test script to generate an initial test command to the Android test suite; and (F) the test device enables the Android test suite to perform the initial test on the Android mobile devices according to the initial test command to generate the initial test Report, and return to step (A). The testing method of the Android mobile device as described in claim 1, wherein, in step (A), each Android mobile device will be classified as a telecom card, a general IC card or no card based on the specific user identification module therein. The categories are with a telecom card, with a general IC card or without a card. The testing method of the Android mobile device as described in claim 2, wherein, in step (a1), the test device generates the test script by inputting a test suite command parameter, a retry parameter and a category parameter, the test suite The command parameter is related to setting the test command of the Android test suite, the retry parameter is related to setting the number of retries of the Android test suite, and the category parameter is related to setting the corresponding Android mobile devices when retrying the Android test suite category. A testing device for an Android mobile device, used for testing a plurality of Android mobile devices electrically connected to it, each Android mobile device can be configured with a specific user identification module; the testing device includes: an interface module for the Android mobile devices The mobile device is electrically connected; a memory for storing an Android test suite and a pre-acquired and Initial test reports related to the Android mobile devices; and a processor connected to the interface module and the storage, and the processor obtains the specific user identification module of each Android mobile device through the interface module After knowing the category of each Android mobile device, read a category value in the initial test report stored in the memory and determine that the category value is a first preset value, and execute a test script to generate a pair of The test command of the first preset value should be given to the Android test suite, so that the Android test suite can correspond to the first preset value for the category of the Android mobile devices according to the test command corresponding to the first preset value or perform a retest and generate a retest report. The test device for Android mobile devices as described in claim 6, wherein, before the processor obtains the category of the specific user identification module of each Android mobile device through the interface module, the processor will execute a machine learning model, generating the test script, and obtaining the category of the specific user identification module of each Android mobile device to know the category of each Android mobile device; and the processor cannot read the initial When testing the report, the processor executes the test script to generate an initial test command to the Android test suite, so that the Android test suite performs an initial test on the Android mobile devices according to the initial test command to generate the initial test. report, and store the initial test report in the memory. The test device for Android mobile devices as described in claim 6, wherein each Android mobile device can be classified as having a telecom card, having a telecom card, having Universal IC card or no card. The test device of Android mobile device as described in claim item 6, wherein, where The manager generates the test script by inputting a test suite command parameter, a retry parameter and a class parameter, the test suite command parameter is related to setting the test commands of the Android test suites, and the retry parameter is related to setting the Android test The number of retries of the suite, the category parameter is related to the category of the Android mobile devices corresponding to the set retry of the Android test suite.

Images