Automatic testing method, terminal device and storage medium for Google mobile services
By automatically extracting and assembling test statements, looping until they pass, the method of solving the problem of low efficiency of manual repeated tests in Google Mobile Services tests, realizing automated tests, improving efficiency and saving time costs.
Patent Information
- Application Number
- CN202011160975.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-10-26
- Publication Date
- 2024-12-10
- Estimated Expiration
- 2040-10-26
AI Technical Summary
Manual testing in existing Google Mobile Services tests is time-consuming and inefficient, resulting in staff having to manually repeat test cases that failed to pass multiple times to obtain pass results.
By extracting the report attribute information of the failed test cases in the test report, assembling the test statements and looping until the test case passes, automatic retesting of the failed test cases is realized, and the retesting step is automatically performed using the terminal device.
Save time costs, improve the efficiency of test failures, reduce manual intervention, and improve the degree of automated testing.
Smart Images

Figure CN112306868B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of Google mobile services, and in particular to an automatic testing method, terminal equipment and storage medium for Google mobile services. Background Art
[0002] GMS stands for Google Mobile Service. GMS is the driving force behind Google's development and promotion of the Android system, and it is also the soul of the Android system. GMS certification includes: CTS, CTS-verifier, CTS-ON-GSI, GTS, STS, VTS, TVTS. Electronic products equipped with the Android system (such as tablets) must output a 0fail (zero failure) report in the GMS test. There is currently no better solution for the test methods to obtain Google certification. Basically, it is to increase manpower investment to complete the output of test results. For example, the tester will test the failed test case about 10 or 20 times alone, and the failed test case may pass only when the tester is watching it all the time. Therefore, this testing method wastes time and affects work efficiency.
[0003] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention
[0004] The embodiments of the present application provide an automatic testing method, terminal device and storage medium for Google mobile services. The present application aims to solve the problem that manual testing in existing Google mobile service testing wastes time and affects work efficiency.
[0005] The present application embodiment provides an automatic testing method for Google mobile services, the method comprising:
[0006] When the set test items are completed, the test cases that failed the test are extracted from the test report;
[0007] Obtaining report attribute information of test cases that failed the test;
[0008] For each test case that failed the test, perform the following retest steps:
[0009] Extracting parameter data required for the test statement corresponding to the set test item from the report attribute information;
[0010] The test statements are assembled according to the parameter data, and the assembled test statements are executed cyclically until the test case currently being processed passes the test.
[0011] In some embodiments, extracting the test cases that failed the test from the test report includes:
[0012] Saving the test report in a preset format;
[0013] Opening the test report using a tool capable of operating the file in the preset format;
[0014] Invoke the search function of the tool to search for a total number of failures identifier in the test report, where the total number of failures identifier is used to indicate the total number of test cases that failed;
[0015] The positioning function of the tool is called to locate the row or column where the total number of failures identifier is located to obtain the total number of failed test cases.
[0016] In some embodiments, the preset format includes HTML format or XML format.
[0017] In some embodiments, obtaining report attribute information of the test case that failed the test includes:
[0018] Calling the search function of the tool to find the non-zero value of the failed module identifier in the test report, the failed module identifier is used to indicate the number of test cases of the module that failed the test; calling the positioning function of the tool to locate the row or column where the non-zero value of the failed module identifier is located to obtain the module name of the test case that failed the test;
[0019] Based on the module name, calling the search function of the tool to search for a failed case identifier in the test report, wherein the failed case identifier is used to indicate the name of a case that failed the test; calling the positioning function of the tool to locate the row or column where the failed case identifier is located to obtain the name of the test case that failed the test;
[0020] The retrieval function of the tool is called to search for the fingerprint identification word in the test report, where the fingerprint identification word is used to represent the version information of the test software; the positioning function of the tool is called to locate the row or column where the fingerprint identification word is located to obtain the fingerprint information.
[0021] In some embodiments, extracting parameter data required for a test statement corresponding to the set test item from the report attribute information includes:
[0022] The module name and the use case name required for the test statement corresponding to the set test item are extracted from the report attribute information.
[0023] In some embodiments, the test items include at least one of the following: a compatibility test suite, a compatibility test in a vendor test suite environment, a Google Mobile Services test suite, an Android security test suite, a vendor test suite, and a TV test suite.
[0024] In some embodiments, the retesting steps for multiple test cases that failed the test are performed in parallel.
[0025] In some embodiments, assembling a test statement according to the data includes:
[0026] Get test commands, test command parameters, module names, and use case names;
[0027] The test command, the test command parameters, the module name, and the use case name are assembled according to the format of the test statement specification.
[0028] The present application also proposes a terminal device, which includes a processor, a memory electrically connected to the processor, and an automatic testing program for Google mobile services stored in the memory and executable on the processor; the automatic testing program for Google mobile services is executed by the processor to perform the steps of the automatic testing method for Google mobile services.
[0029] The present application also proposes a computer-readable storage medium, which stores one or more programs. The one or more programs can be executed by one or more processors to implement the steps of the automatic testing method of Google mobile services.
[0030] This application extracts the report attribute information of the test case that failed the test from the test report, and extracts the parameter data required for the test statement corresponding to the set test item from the report attribute information, and the parameter data constitutes the name of the test case that failed, and then assembles the parameter data into a test statement, and executes the assembled test statement in a loop until the currently processed test case passes the test. A test is performed on a failed test case, and then the retesting step is automatically repeated for other failed test cases, so as to retest all failed test cases in the test report. This embodiment opens the test report through a terminal device and automatically performs repeated testing of failed test cases. Compared with the traditional method of manually executing the test of failed test cases, this embodiment saves time and cost, improves the work efficiency of the test cases that failed, and the staff does not need to perform the test manually, which brings convenience to the staff. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] Figure 1 A hardware architecture diagram of an embodiment of a terminal device of the present application;
[0032] Figure 2 A flowchart of an embodiment of the automatic testing method of Google mobile services of the present application;
[0033] Figure 3 for Figure 2 A flowchart of an embodiment of extracting test cases that failed a test from a test report;
[0034] Figure 4 for Figure 2 A flowchart of an embodiment of obtaining report attribute information of a test case that failed the test;
[0035] Figure 5 for Figure 2 A flowchart of an embodiment of assembling a test statement according to the parameter data. DETAILED DESCRIPTION
[0036] In order to better understand the above technical solution, exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.
[0037] GMS stands for Google Mobile Service. GMS is the driving force behind Google's development and promotion of the Android system, and is also the soul of the Android system. GMS certification includes: compatibility test suite, compatibility test in the vendor test suite environment, Google Mobile Service Test Suite, Android Security Test Suite, Vendor Test Suite, TV Test Suite, etc. Electronic products equipped with the Android system (such as tablets) need to output a 0fail report in the Google Mobile Service test in order to pass the Google Mobile Service certification.
[0038] At present, the reasons why most test cases fail in Google Mobile Service testing are not even analyzed by the software designers themselves, but Google will not exempt these test cases. Therefore, the staff have to retest manually. The efficiency of retesting is very low, generally hovering between 1 / 10 and 1 / 20. In other words, the tester will repeat this test case about 10 or 20 times before the test passes, and this test case can only pass when the tester is watching it all the time. Therefore, the existing testing method is a waste of time and affects work efficiency.
[0039] Therefore, it is necessary to save time and improve work efficiency and automation when testing failed test cases in Google mobile service testing. This application proposes an automatic testing method, terminal device and storage medium for Google mobile services.
[0040] Please refer to Figure 1 , a terminal device is introduced below, which may include: a processor 1001, such as a CPU, a memory 1005, a user interface 1003, a network interface 1004, and a communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the user interface 1003 may optionally include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may optionally be a storage device independent of the aforementioned processor 1001.
[0041] Optionally, the terminal device may also include an RF (Radio Frequency) circuit, a sensor, an audio circuit, a WiFi module, and the like.
[0042] Those skilled in the art will understand that Figure 1 The terminal device structure shown in the figure does not constitute a limitation on the terminal device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.
[0043] like Figure 4 As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an automatic test program for Google Mobile Services. The operating system is a program for managing and controlling the hardware and software resources of the terminal device, and supports the operation of the automatic test program for Google Mobile Services and other software or programs.
[0044] exist Figure 1 In the terminal device shown, the user interface 1003 is mainly used to receive test reports; the network interface 1004 is mainly used for the background server, and performs data communication with the background server; the processor 1001 can be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the steps of the automatic testing method of the Google mobile service as described above.
[0045] In some embodiments, the processor 1001 may be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the automatic testing method of the Google mobile service including:
[0046] When the set test items are completed, the test cases that failed the test are extracted from the test report;
[0047] Obtaining report attribute information of test cases that failed the test;
[0048] For each test case that failed the test, perform the following retest steps:
[0049] Extracting parameter data required for the test statement corresponding to the set test item from the report attribute information;
[0050] The test statements are assembled according to the parameter data, and the assembled test statements are executed cyclically until the test case currently being processed passes the test.
[0051] In some embodiments, the processor 1001 may be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the automatic testing method of the Google mobile service including:
[0052] The extracting of the test cases that failed the test from the test report includes:
[0053] Saving the test report in a preset format;
[0054] Opening the test report using a tool capable of operating the file in the preset format;
[0055] Invoke the search function of the tool to search for a total number of failures identifier in the test report, where the total number of failures identifier is used to indicate the total number of test cases that failed;
[0056] The positioning function of the tool is called to locate the row or column where the total number of failures identifier is located to obtain the total number of failed test cases.
[0057] In some embodiments, the processor 1001 may be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the automatic testing method of the Google mobile service including:
[0058] The preset format includes HTML format or XML format.
[0059] In some embodiments, the processor 1001 may be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the automatic testing method of the Google mobile service including:
[0060] Get the report attribute information of the test case that failed the test, including:
[0061] Calling the search function of the tool to find the non-zero value of the failed module identifier in the test report, the failed module identifier is used to indicate the number of test cases of the module that failed the test; calling the positioning function of the tool to locate the row or column where the non-zero value of the failed module identifier is located to obtain the module name of the test case that failed the test;
[0062] Based on the module name, calling the search function of the tool to search for a failed case identifier in the test report, wherein the failed case identifier is used to indicate the name of a case that failed the test; calling the positioning function of the tool to locate the row or column where the failed case identifier is located to obtain the name of the test case that failed the test;
[0063] The retrieval function of the tool is called to search for the fingerprint identification word in the test report, where the fingerprint identification word is used to represent the version information of the test software; the positioning function of the tool is called to locate the row or column where the fingerprint identification word is located to obtain the fingerprint information.
[0064] In some embodiments, the processor 1001 may be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the automatic testing method of the Google mobile service including:
[0065] Extracting parameter data required for a test statement corresponding to the set test item from the report attribute information includes:
[0066] The module name and the use case name required for the test statement corresponding to the set test item are extracted from the report attribute information.
[0067] In some embodiments, the processor 1001 may be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the automatic testing method of the Google mobile service including:
[0068] The test items include at least one of the following: compatibility test suite, compatibility test in vendor test suite environment, Google mobile service test suite, Android security test suite, vendor test suite, and TV test suite.
[0069] In some embodiments, the processor 1001 may be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the automatic testing method of the Google mobile service including:
[0070] The retesting steps of multiple test cases that failed the test are executed in parallel.
[0071] In some embodiments, the processor 1001 may be used to call the automatic testing program of the Google mobile service stored in the memory 1005, and execute the automatic testing method of the Google mobile service including:
[0072] The step of assembling a test statement according to the data comprises:
[0073] Get test commands, test command parameters, module names, and use case names;
[0074] The test command, the test command parameters, the module name, and the use case name are assembled according to the format of the test statement specification.
[0075] The terminal device of this embodiment extracts the report attribute information of the test case that failed the test from the test report, and extracts the parameter data required for the test statement corresponding to the set test item from the report attribute information, and the parameter data constitutes the name of the failed test case, and then assembles the parameter data into a test statement, and executes the assembled test statement in a loop until the currently processed test case passes the test. A test is performed on a failed test case, and then the retesting step is automatically repeated for other failed test cases, so as to retest all failed test cases in the test report. This embodiment opens the test report through the terminal device and automatically performs repeated testing of the failed test cases. Compared with the traditional method of manually executing the test of the failed test case, this embodiment saves time cost, improves the work efficiency of the test case that failed, and the staff does not need to perform the test manually, which brings convenience to the staff.
[0076] Please refer to Figure 2 Based on the hardware architecture of the above terminal device, the following is an automatic testing method for Google mobile services of the present application, and the automatic testing method for Google mobile services includes:
[0077] S110, when the set test items are tested, extract the test cases that failed the test from the test report;
[0078] The test items may include at least one of the following: CTS (Compatibility Test Suite), CTS-ON-GSI (Compatibility Test in Vendor Test Suite Environment), GTS (Google Mobile Services Test Suite), STS (Android Security Test Suite), VTS (Vendor Test Suite), TVTS (Television Test Suite). In other words, the test items targeted by this embodiment are of various types, and this embodiment may retest failed test cases for at least one of the above test items.
[0079] For details, please refer to Figure 3 , extract the test cases that failed the test from the test report, including:
[0080] S111, saving the test report in a preset format;
[0081] Specifically, the preset format may be HTML format or XML format.
[0082] S112, using a tool capable of operating the preset format file to open the test report;
[0083] It should be noted that the tool for operating the preset format file here can adopt different implementations according to different actual situations. For example, the test report can be opened using the statement specification of the JAVA language, the test report can be opened using the statement specification of the C++ language, or the test report can be opened using the statement specification of the python language. There is no limitation on the specific programming language used to open the test report.
[0084] S113, calling the search function of the tool to search for a total failure identifier in the test report, where the total failure identifier is used to indicate the total number of failed test cases; calling the positioning function of the tool to locate the row or column where the total failure identifier is located to obtain the total number of failed test cases.
[0085] The following introduces the general form of the test report of a certain project in the Google Mobile Service test. Please refer to Table 1. The test report of Google Mobile Services includes the total number of test cases that passed the test (i.e. 425223 represented by the row where Tests Passed is located), the total number of test cases that failed the test (i.e. 3 represented by the row where Tests Failed is located), and the fingerprint information (i.e. XXXXXX represented by the row where Fingerprint is located). It should be noted that the fingerprint information represents the unique identification information of the test software, which is used to distinguish and identify the version information of the test software. It should be noted that the test report also includes other parameters. Only a small number of parameters are selected here to illustrate the inventive concept of this application. The parameters included in the actual test report should be more than the parameters listed in Table 1.
[0086] It can be concluded from Table 1 that the English phrase "Tests Failed" is a word indicating the total number of failures. By retrieving "Tests Failed" in Table 1 and locating the value of the row or column where "Tests Failed" is located, the total number of test cases that failed can be obtained. Specifically, if the total number of test cases that failed is extracted by JAVA language. It can be done in the following way: first search for "Tests Failed" in the test report by using the boolQuery function (i.e., Boolean query function), and then locate the value of the row where "Tests Failed" is located by using the findElement function (i.e., positioning function) to obtain the total number of test cases that failed, which is 3. It can be understood that different forms may exist in different test reports. In a vertically arranged test report, the value of the column where "Tests Failed" is located can be located by using the findElement function (i.e., positioning function) to obtain the total number of test cases that failed, which is 3.
[0087]
[0088] Table 1
[0089] S120, obtaining report attribute information of the test case that failed the test;
[0090] The following introduces other parameters of the test report of a project in the Google Mobile Services test. Please refer to Table 2. The test report also includes the names of different modules (i.e. the column where Module is located), the number of test cases of different modules that have passed the test (i.e. the value in the column where Passed is located), the number of test cases of different modules that have failed the test (i.e. the value in the column where Failed is located), the total number of test cases of different modules (i.e. the value in the column where Total is located), and the test completion status of test cases of different modules (i.e. the true in the column where Test Done is located, true means correct).
[0091]
[0092]
[0093] Table 2
[0094] Please refer to Table 3. The test report also includes the test case name of the specific test case of the module that failed the test (that is, the Test column), the test result of the test case (that is, the Result column), and the specific details of the test case that failed the test (that is, the Details column).
[0095]
[0096] Table 3
[0097] By observing the test report of a project in the above Google Mobile Services test, it can be concluded that to determine which test case failed, on the one hand, it is necessary to determine the module name to which the test case belongs, and on the other hand, it is necessary to determine the case name of the test case. In other words, only by determining both the module name and the case name can it be determined which test case failed.
[0098] Therefore, in this embodiment, please refer to Figure 4 The step of obtaining the report attribute information of the test case that failed the test specifically includes:
[0099] S121, calling the search function of the tool to find the non-zero value of the failed module identifier in the test report, the failed module identifier is used to indicate the number of test cases of the module that failed the test; calling the positioning function of the tool to locate the row or column where the non-zero value of the failed module identifier is located to obtain the module name of the test case that failed the test;
[0100] It can be seen from Table 2 that when the English word "Failed" is not zero, it indicates that a failed test case appears in the test case of the module. Therefore, "Failed" can be set as the failed module identifier, and the module name of the test case that failed the test can be obtained by retrieving "Failed" in Table 2 and locating the "Module" in the row or column where "Failed" is located. Specifically, if JAVA language is used, the boolQuery function (i.e., Boolean query function) can be used to first search for the non-zero value 2 of "Failed" in the test report, and then the findElement function (i.e., positioning function) can be used to locate the "Module" in the row where the non-zero value 2 of "Failed" is located to obtain the module name C of the failed test case. It can be understood that different forms may exist in different test reports. In a vertically arranged test report, the findElement function (i.e., positioning function) can be used to locate the "Module" in the column where "Failed" is located to obtain the module name C of the failed test case.
[0101] S122, based on the module name, calling the search function of the tool to search for a failed case identifier in the test report, where the failed case identifier is used to indicate the name of a test case that failed the test; calling the positioning function of the tool to locate the row or column where the failed case identifier is located to obtain the name of the test case that failed the test;
[0102] It can be seen from Table 3 that when the English word "fail" is not zero, it indicates that a specific test case that failed to pass appears in the module. Therefore, "fail" can be set as the failed test case identifier, and the test case name of the test case that failed to pass the test can be obtained by retrieving "fail" in Table 2 and locating the "Test" in the row or column where the "fail" is located. Specifically, if the JAVA language is used, the "fail" in the test report can be first searched through the boolQuery function (i.e., Boolean query function), and then the "Test" in the row where the "fail" is located can be located through the findElement function (i.e., positioning function) to obtain the test case names C1 and C2 of the test case that failed. It can be understood that different forms may exist in different test reports. In the vertically arranged test report, the "Test" in the column where the "fail" is located can be located through the findElement function (i.e., positioning function) to obtain the test case names C1 and C2 of the test case that failed.
[0103] S123, calling the search function of the tool to search for a fingerprint identification word in the test report, where the fingerprint identification word is used to represent version information of the test software; calling the positioning function of the tool to locate the row or column where the fingerprint identification word is located to obtain fingerprint information.
[0104] When testing the failed test cases of specific Google mobile services, in order to improve the test efficiency, the retest steps of multiple failed test cases are executed in parallel. At this time, the test cases in multiple test reports are retested at the same time. In order to ensure that the test software version of the test project is correct, fingerprint information needs to be extracted from the test report. This fingerprint information can avoid errors in retesting multiple reports, that is, to ensure that the test project is tested with the correct software test version.
[0105] Specifically, the English word "Fingerprint" in Table 1 represents the fingerprint information of the software. The English word "Fingerprint" can be set as a fingerprint identifier. The fingerprint information can be obtained by retrieving the "Fingerprint" in Table 1 and locating the row or column where the "Fingerprint" is located. Specifically, if JAVA language is used, the "Fingerprint" in the test report can be first searched through the boolQuery function (i.e., Boolean query function), and then the row where the "Fingerprint" is located can be located through the findElement function (i.e., positioning function) to obtain the fingerprint information of the failed test case. It can be understood that different forms may exist in different test reports. In a vertically arranged test report, the fingerprint information can be obtained by locating the column where the "Fingerprint" is located through the findElement function (i.e., positioning function).
[0106] S130. For each test case that fails the test, perform the following retest steps:
[0107] Extracting parameter data required for the test statement corresponding to the set test item from the report attribute information;
[0108] The test statements are assembled according to the parameter data, and the assembled test statements are executed cyclically until the test case currently being processed passes the test.
[0109] Specifically, the module name and the use case name required for the test statement corresponding to the set test item are extracted from the report attribute information. The module name and the use case name obtained in step S120 can be used to determine the test case that failed.
[0110] For further information, please refer to Figure 5 , assembling a test statement according to the parameter data, including:
[0111] S1321. Obtain test command, test command parameters, module name, and use case name;
[0112] S1322. Assemble the test command, the test command parameters, the module name, and the use case name according to the format of the test statement specification, and execute the assembled test statement in a loop until the currently processed test case passes the test.
[0113] Specifically, different programming languages can be selected according to different actual needs to assemble module names and use case names to obtain test statements. When different programming languages are selected, the test commands and test command parameters should be adapted to the corresponding programming languages. In some embodiments, the JAVA language can be used to assemble module names and use case names. For example, the following test statement can be constructed in the JAVA language:
[0114]
[0115]
[0116] The "moduleName" in the code indicates the module name obtained in step S120, and the "TestCase" indicates the test case name obtained in step S120. This test statement can be used to retest the test case that has not passed.
[0117] Secondly, in order to achieve the effect of looping the assembled test statements until the currently processed test case passes the test. Whether the test case passes the test should be used as the judgment condition for whether the test statement continues to be executed. If the test fails, repeat the test; if the test passes, turn to the test of the next test case. Further, in order to realize the above idea at the program level, an identification variable can be set to test the failed test cases one by one. For example, an identification variable i can be set before looping the assembled test statements, and the initial value of the identification variable i is set to 0. After each test case is retested and passed, the value of the identification variable i is increased by 1 to count the test cases that have passed the retest. When the value of the identification variable i reaches the total number of failed test cases obtained in the previous step S113, all the test cases that have not passed the test in the test report are tested and all the tests are passed, and the automatic test ends.
[0118] Based on the concept of the aforementioned technical solution, an embodiment of a typical automatic testing method for Google mobile services is proposed below.
[0119] S1. Open the test report using a statement that complies with the Java language specification;
[0120] S2, searching the total number of failures identifier "Tests Passed" in the test report through the search function of the Java language, and then searching the value of the total number of failures identifier "Tests Passed" in the test report through the search function of the Java language to obtain the total number of failed test cases;
[0121] S3, set the identification variable i, and set the initial value of the identification variable i to 0;
[0122] S4, calling the search function of the Java language to find a non-zero value of "Failed" in the test report; calling the positioning function of the tool to locate the row where the non-zero value of "Failed" is located to obtain the module name of the test case that failed the test; based on the module name, calling the search function of the tool to find "fail" in the test report, calling the positioning function of the tool to locate the row where "fail" is located to obtain the case name of the test case that failed the test; constructing a test statement according to the module name and the case name, and performing a loop test on the test statement until the test case corresponding to the module name and the case name passes the test;
[0123] S5. If the test passes, the identification variable i is increased by 1. If the identification variable i is less than the total number of failed test cases, go to step S4 to implement a loop test on the next failed test case; if the identification variable is equal to the total number of failed test cases, all failed test cases in the test report have passed.
[0124] This embodiment extracts the report attribute information of the test case that failed the test from the test report, and extracts the parameter data required for the test statement corresponding to the set test item from the report attribute information, and the parameter data constitutes the name of the failed test case, and then assembles the parameter data into a test statement, and executes the assembled test statement in a loop until the currently processed test case passes the test. A test is performed on a failed test case, and then the retesting step is automatically repeated for other failed test cases, so as to retest all failed test cases in the test report. This embodiment opens the test report through a terminal device and automatically performs repeated testing of failed test cases. Compared with the traditional method of manually executing the test of failed test cases, this embodiment saves time and cost, improves the work efficiency of the test cases that failed, and the staff does not need to perform the test manually, which brings convenience to the staff.
[0125] The present application also proposes a computer-readable storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps in the automatic testing method, terminal device and storage medium of the Google mobile service.
[0126] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0127] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0128] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0129] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0130] It should be noted that in the claims, any reference signs placed between brackets shall not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claim. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention may be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third etc. does not indicate any order. These words may be interpreted as names.
[0131] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.
[0132] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.
Claims
1. An automatic testing method for Google mobile services, characterized in that: The method comprises: When the set test items are completed, the test cases that failed the test are extracted from the test report; Obtaining report attribute information of test cases that failed the test; For each test case that failed the test, perform the following retest steps: Extracting parameter data required for the test statement corresponding to the set test item from the report attribute information; Assembling test statements according to the parameter data, and looping through the assembled test statements until the currently processed test case passes the test; The extracting of the test cases that failed the test from the test report includes: Saving the test report in a preset format; Opening the test report using a tool capable of operating the file in the preset format; Invoke the search function of the tool to search for a total number of failures identifier in the test report, where the total number of failures identifier is used to indicate the total number of test cases that failed; Calling the positioning function of the tool to locate the row or column where the total number of failures identifier is located to obtain the total number of failed test cases; Get the report attribute information of the test case that failed the test, including: Calling the search function of the tool to find the non-zero value of the failed module identifier in the test report, the failed module identifier is used to indicate the number of test cases of the module that failed the test; calling the positioning function of the tool to locate the row or column where the non-zero value of the failed module identifier is located to obtain the module name of the test case that failed the test; Based on the module name, calling the search function of the tool to search for a failed case identifier in the test report, wherein the failed case identifier is used to indicate the name of a case that failed the test; calling the positioning function of the tool to locate the row or column where the failed case identifier is located to obtain the name of the test case that failed the test; The retrieval function of the tool is called to search for the fingerprint identification word in the test report, where the fingerprint identification word is used to represent the version information of the test software; the positioning function of the tool is called to locate the row or column where the fingerprint identification word is located to obtain the fingerprint information.
2. The method according to claim 1, characterized in that The preset format includes HTML format or XML format.
3. The method according to claim 1, characterized in that Extracting parameter data required for a test statement corresponding to the set test item from the report attribute information includes: The module name and the use case name required for the test statement corresponding to the set test item are extracted from the report attribute information.
4. The method according to claim 1, characterized in that The test items include at least one of the following: compatibility test suite, compatibility test in vendor test suite environment, Google mobile service test suite, Android security test suite, vendor test suite, and TV test suite.
5. The method according to claim 1, characterized in that The retesting steps of multiple test cases that failed the test are executed in parallel.
6. The method according to claim 1, characterized in that The step of assembling a test statement according to the parameter data comprises: Get test commands, test command parameters, module names, and use case names; The test command, the test command parameters, the module name, and the use case name are assembled according to the format of the test statement specification.
7. A terminal device, characterized in that: The terminal device includes a processor, a memory electrically connected to the processor, and an automatic testing program for Google mobile services stored in the memory and executable on the processor; when the automatic testing program for Google mobile services is executed by the processor, the steps of the automatic testing method for Google mobile services as described in any one of claims 1 to 6 are implemented.
8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the automatic testing method for Google mobile services as described in any one of claims 1 to 6.
Citation Information
Patent Citations
Testing method combining automatic tool and testing case
CN102662846A
Method and device for automatically generating unit test cases
CN103530223A
Method and device for testing set-top box browser
CN105306928A
Method for retesting test cases after test failure, client and server
CN108459961A
Systems and methods for testing a software application
US9111030B1
