Disclosure of Invention
The invention aims to provide a preference setting-oriented android application testing method, which is used for testing preference settings as comprehensively as possible with the lowest testing cost as possible based on given test cases, so that the testing effect is further improved.
In order to achieve the purpose, the method has the technical scheme that the method for testing the android application oriented to the preference setting is characterized by mainly comprising the following steps of:
step 1, performing static analysis on an android application to be tested to obtain preference settings and attributes thereof defined in the application, and recording a set of all the preference settings as PI;
step 2, carrying out dynamic analysis on a given test case to obtain associated preference settings under each test case, and enumerating all relevant preference settings under the test case and all possible input combinations of the preference settings, wherein any combination is called a test scene, and a set formed by all test scenes is marked as PS;
and 3, in the target-oriented execution mode, dividing the application code into basic blocks, analyzing the basic blocks contained in each test case and the preference setting associated with each basic block, so as to decompose the PS into the combination of the preference setting input and the basic blocks, namely the test targets, the set of which is marked as PB, and continuously selecting the test scene covering the most test targets for execution.
Further, preference settings are defined in the android application in the form of resource files, and these resource files are mapped in the logic code to GUI interfaces by calling the android API interface, thereby allowing the user to modify these preference settings. Therefore, in the static analysis, the preference setting defined in the application and the attribute contained in the preference setting are identified through the obtained resource file, and the identified preference setting set is the PI.
Further, the static analysis, in addition to identifying the preference setting, also confirms the GUI interface where the preference setting included in the corresponding resource file is located through the calling position of the API interfaces by constructing the calling relationship of the application, so as to perform setting operation on the preference setting in the subsequent execution mode.
Further, the dynamic analysis is to obtain an execution track of the code in the execution of each test case by means of instrumentation, and then obtain the preference setting associated with the test case by symbolically reproducing this track. Then, all combinations of these preference settings and their possible inputs are exhausted, and the set formed by these combinations under all test cases is PS.
Further, in the android application, the preference setting uses a key value storage mechanism of SharedPreferences and uses a specific value of an attribute key (referred to as a key value for short) as a key to read and store. Therefore, when the execution tracks of the test cases are symbolically reproduced, the dynamic analysis symbolizes the parameters of all SharedPreferences reading operations in the tracks, and takes the calculation result as the key value to find the elements with the same key value in the PI: if yes, the preference setting corresponding to the element is associated with the test case; if not, the read operation is skipped.
Further, the relevant preference settings obtained in the analysis of each test case in the dynamic analysis are rejected if the relevant preference settings do not play a role in case execution after reading, that is, the relevant preference settings are not used for judging branch selection in the conditional expression of the conditional branch.
Further, the possible input values of preference setting in dynamic analysis may come from resource file acquisition of the static analysis application; if the resource file does not contain the input value, the dynamic analysis randomly gives an input value according to the data type set by the preference.
Further, the basic blocks in the target-oriented execution mode represent a sequence of statements executed sequentially in the test application code program, with only one entry and one exit, and only branch statements can appear at the exit or entry positions.
Furthermore, in the target-oriented execution mode, when the relevance between the basic block and the preference setting is analyzed, the way of analyzing the relevance between the test case and the preference setting can be used, and the relevance result is divided according to the basic block; then, under a certain basic block, the test of a group of input combinations of associated preference settings, called test targets, exhaustively enumerates the set formed by all test targets, namely PB.
Further, the execution mode of the target guide comprises the following specific steps:
step 31, cutting PB according to a test target which is achieved in the execution of the original test case;
step 32, searching a certain test scenario in the PS, wherein the uncovered test targets contained in the test scenario, namely the test targets still contained in the PB are the most, and performing combined execution of preference setting input and an original test case according to the test scenario;
step 33, obtaining the test target achieved in the execution of the previous step;
step 34, if the test targets which have not been reached before are reached, the PB is reduced according to the test targets; otherwise, cutting down the PB according to all the test targets in the execution, and putting the test targets into a retry list;
step 35, repeating the steps 32-34 until PB is empty;
and step 36, recovering the state from the PS to the state after the step 32, finding the test scene which contains the test target and has the least test target from the PS for each test target in the retry list, and repeatedly executing the test scene.
Further, in the specific steps 31 and 36 of the guided execution mode, when there are a plurality of combinations found, different selection strategies may be used, including all the combinations being selected, and the three types are selected preferentially and randomly according to the validity of the test case.
Further, in the specific steps 31 and 34 of the guided execution mode, according to the reduction of the test targets in the PB, these test targets are also deleted for the test scenarios in the PS, and the preference setting inputs related only to these test targets in the scenarios are deleted.
Further, the joint execution in the specific step 32 of the guided execution mode includes the following steps:
step 321, taking out a set of preference settings and corresponding inputs from the test scenario in order, and executing step 322 and 323 until all preference settings and corresponding inputs in the combination are executed;
step 322, opening a GUI (graphical user interface) where the preference setting is located, which is obtained according to static analysis, by means of an ADB (Adadb) tool provided by an Android platform;
step 323, finding the specific position on the GUI interface according to the attribute of the preference setting, and completing the modification of the preference setting according to the type and the given input;
and 324, executing the original test case.
Compared with the prior art, the method makes up the defect of poor test effect of the preference setting part in the current mainstream test method, and initiatively provides a test method specially aiming at preference setting of android application for the test case only to test the preference setting input combination related to the test case;
secondly, the invention selects the combination of the test case covering the most test targets and the preference setting for testing, thereby reducing the test of repeated preference setting input combination under each test case and greatly reducing the test cost;
furthermore, the present invention starts from a given test case and is therefore compatible with other test methods, including automated test input generation methods and manual testing: for the former, the invention can effectively improve the test effect, and for the latter, the test case writer can reduce or even not need to write the test case with preference setting of the part of functions under the support of the invention, thereby greatly reducing the test cost.
Detailed Description
The technical solution of the present invention is further described in detail by the accompanying drawings and embodiments.
As shown in fig. 1, a schematic flow chart of the preference setting-oriented android application testing method of this embodiment is shown, and is also a general flow chart of this method, which includes three steps:
step 101, performing static analysis on an executable file of an application to be tested, namely an APK file, to obtain all preference settings defined in the application, wherein a set of the preference settings is marked as PI and is used for assisting the analysis of the next step 102;
102, analyzing the associated preference settings in each test case in a mode of dynamically executing the test cases on the application to be tested, thereby enumerating combinations of all the relevant preference settings and possible inputs thereof under all the test cases, wherein the total set is marked as PS;
and 103, calculating the test targets which are possibly reached by the combination under each PS through a target-oriented execution mode, continuously selecting the combination with the most test targets from the PS, namely, the combination which can bring the maximum promotion effect to the test for execution, and reducing the PS according to the execution result until the PS is empty.
As shown in fig. 2, this is a specific flow chart of static analysis of the preference setting-oriented android application testing method of this embodiment, and static program analysis is performed on an executable file of an application to be tested to obtain all preference settings and attributes thereof defined in the application, i.e., a set PI, and specific steps are as follows:
step 201, acquiring a resource file of an executable file, namely an APK (android package) file, of an application to be tested through an apktool or a jadx reverse tool;
in step 202, find the files for describing the preference settings, and read the preference settings and their attributes, including key (for uniquely marking the preference settings), title (for displaying text on the interface), postblevalue (all possible values), and catelog (type).
Step 203, analyzing and obtaining all functions defined in the android program to be tested and call relations thereof from the APK file with the help of a Java analysis tool Soot, thereby constructing a function call relation graph (including implicit calls therein);
step 204, finding out the call of the specific android API function which loads and maps the resource files into the GUI interface in all functions, and performing traversal selection;
step 205, in the graph constructed in step 203, all functions directly and indirectly containing the call are searched;
step 206, if there is a lifecycle function of a certain Activity in the functions, the resource file mapped in the call is loaded and mapped to the GUI interface corresponding to the Activity, in this case, step 207 is skipped; otherwise, it indicates that the resource file is not really loaded, and jumps to step 208;
step 207, adding the Activity information as a new attribute location for all the preference settings contained in the loaded resource file, where the attribute represents the location of the GUI interface where the preference settings are located.
Step 208, searching whether calls of the specific android API functions which are not traversed exist, and if yes, returning to the step 204 to continue circulation; and if not, jumping out, wherein a set formed by all the preference settings and the attributes contained in the preference settings is the PI.
As shown in fig. 3, this is a specific flowchart of dynamic analysis of the preference setting-oriented android application testing method according to this embodiment, and a process of dynamically analyzing the preference setting associated with each test case through the analyzed preference setting set PI and a given test case, and finally generating a set PS includes the following specific steps:
step 301, inserting a recorder, namely a pile, into the application executable file, and then installing the application executable file into the android device;
step 302, selecting an unexecuted test case, executing the test case on the instrumented application, and then obtaining an execution track of an application code in the test case execution from a recorder;
step 303, constructing a linear program statement execution sequence according to the trajectory; this step and the above step 301 can be completed with the help of a Java analysis tool, root;
step 304, selecting sentences in sequence to perform symbolization execution;
step 305, in symbolic execution, if the statement includes a call to a read operation function of sharedpreference, if the statement includes the call, the step 306 is skipped; if not, go to step 309.
Step 306, symbolically calculating the parameter in the reading operation, and taking the calculation result as a key value to search preference settings with the same key value in the PI;
step 307, if the corresponding preference setting can be found, skipping to step 308; if not, return to step 309;
step 308, replacing the output value of the reading operation with a specific symbol representing the preferred setting, and participating in the subsequent symbolization execution and calculation;
step 309, checking whether the statement is a branch statement, if yes, jumping to step 310; otherwise, jumping to step 313;
step 310, symbolically calculating the conditional expression of the branch statement;
step 311, if the numerical values obtained by the symbolic calculation include specific symbols representing specific preference settings, it indicates that the values of the preference settings are to be used for determining the branch selection, i.e. play a role in the test case execution, and then go to step 312; otherwise, jumping to step 313;
step 312, regarding the preference setting playing a role in the test case, identifying that the preference setting is associated with the test case, and recording;
313, judging whether a next statement exists, and if so, returning to 304 for circulation; otherwise, jumping out to step 313;
step 314, judging whether a test case which is not executed exists or not, if so, jumping to the step 302 for circulation; if not, jumping to step 315;
step 315, enumerating all relevant preference settings and combinations of possible inputs (the posblevalue attribute of the preference setting, which is randomly given according to the data type when the attribute is empty) of all test cases, and finally obtaining a set as PS.
Fig. 4 is a specific flowchart of a target-oriented execution mode of the preference setting-oriented android application testing method according to this embodiment, and the specific steps are as follows:
step 401, in the above dynamic analysis process, by dividing the execution stream by using the basic block as a unit, calculating all test targets included in a certain test scenario, that is, in a certain basic block, a set of related preference settings and combinations of input values thereof;
step 402, during dynamic execution, obtaining an execution track of a test case, wherein the execution track includes branch selection in the execution of the original test case, so that a test target which is reached in the original test can be calculated, and a PB is reduced according to the test target, so that the PB only includes test targets which are not reached in the original test;
step 403, judging whether PB is empty, and if not, skipping to step 404 to start a loop; if the state is empty, the loop is stopped, and the process jumps to 408;
step 404, selecting a test scenario with the most test targets from the PS for execution, and if there is a combination with the most test targets, randomly selecting one of the test scenarios for execution;
step 405, checking whether any test target is covered according to the execution result, and if so, jumping to step 406; if not, go to step 407;
step 406, now covering any test targets, so these will be deleted from the PB;
step 407, at this time, any test target is not covered, so that these test targets with coverage failure are not only deleted from PB, but also need to be added into the failure list;
deleting the test targets in the steps 402, 406 and 407, and also deleting the test targets in the corresponding test scenes in the PS, and deleting preference setting input only related to the test targets in the scenes;
step 408, recovering the state from the PS to the step 402;
step 409, selecting a test target from the failure list;
step 410, selecting a combination from the PS to execute, wherein the combination should include the test target and the number of the test targets is the minimum, and if there are a plurality of such combinations, randomly selecting one of the combinations to execute;
step 411, checking whether there are unselected test targets in the failure list, if yes, skipping to step 409 to repeat the cycle; if not, the execution mode of the target guide is ended.
In addition, the execution of steps 404 and 410 according to a given test scenario, as also shown on the right side of fig. 4, includes the following specific steps:
step e401, traversing the preference setting and the corresponding input in the selection combination;
step e402, opening the GUI interface where the android ADB tool is located according to the location attribute set by the preference; then, positioning the specific position of the preference setting title on the interface according to the preference setting title attribute;
step e403, modifying the preference setting according to the specific input;
step e404, checking whether the preference setting and the input which are not selected exist, if so, skipping to e401 to repeat the cycle; if not, jumping out of the cycle to e 405;
and e405, executing the original test case.
The above description is only a preferred embodiment of the present invention, and should not be taken as limiting the invention in any way, and any insubstantial modifications or equivalent changes made by the technical spirit of the present invention without departing from the scope of the present invention are intended to be covered by the claims of the present invention.