KR20140033580A - Method for generating activity based state diagram of android applications - Google Patents

Abstract

The present invention relates to a method for generating an activity based state diagram of android applications which is a preceding step of creating scenarios for GUI testing of android applications. The method comprises the steps of: performing reverse engineering for a source of the applications; generating a state diagram focused on activity for the result of the reverse engineering performed; and adding a life cycle of the activity to the state diagram.

Description

A method for generating an activity-based state of an Android application

The present invention relates to an activity-based state diagram generation method for generating a test case by taking information on activity generated by reverse engineering an Android application into information.

The penetration rate of smartphones based on Android is rising and the range of application of Android OS is spreading to society as a whole. The Android application that has been applied to various devices and has various functions is being released one day differently.

However, since the problems that occur in the application may affect the Android OS, it is necessary for the developer to research and develop a software testing tool in order to improve the quality by discovering potential problems through self test in advance. Android applications have a different structure from traditional Java applications and are optimized to work in limited hardware environments such as mobile devices.

Android provides three basic JUnit [1], Monkey [2], and MonkeyRunner [3] for testing. JUnit is supported for unit testing of Android. However, since JUnit that is executed in existing JVM can not guarantee the target, it provides Androiod Test Case Class separately.

In addition to testing simple APIs, it also provides instrumentation based testing techniques. The function test is performed by expressing the contents of the user's behavior in code. Monkey can send a random event from Android to the target to perform a stress test that tests whether an error occurs or how long it takes. MonkeyRunner is a tool that allows you to create scripted code with Jython for action coordinates and action events.

Android software consists of four components. The four components are activities, services, Broadcast Receivers, and Content Providers. Android does not have a unique entry point like the main function, and the first instance constructor is the actual entry point. Among the components, the activity used in the present invention is a basic building block constituting the Android application, displaying a user interface constituted by a view while occupying a screen, processing a user's input, It consists of different activities that constitute different screens.

Conventional mobile software testing methods have had a problem that can not be tested for an Android application having a property called an activity.

The present invention proposes a method for generating a state diagram based on an activity characteristic of Android characteristics before a scenario is created for GUI testing of an application for Android.

In particular, the goal is to create a state diagram based on an activity, which is a screen unit displayed on the device, and to add life cycle of such activity to perfect the scenario to be created later, and to perform stable GUI testing of the application.

The present invention relates to a method for generating an activity-based state diagram of an Android application, which is a step prior to creating a scenario for GUI testing of an Android application, comprising: performing reverse engineering of an application source; Generating a state diagram based on the activity for the result of the reverse engineering performed as described above; And adding a life cycle of the activity to the state diagram.

The adding of the life cycle of the activity may include checking whether a finish function exists for each of the activities, and if the activity includes a finish function, the previous step (N-2). Adding an event bag moving to), and adding an event bag moving to the previous step (N-1) when the activity function is not included in the activity.

Activities must have their own lifecycles and describe event backs (backyck events) as examples of life cycles. By automatically generating a state diagram to which such an activity life cycle is added, it is possible to complete the scenario to be created later.

1 is a diagram showing a test case generation procedure of an Android application.
2 is a diagram for explaining a call graph derived through reverse engineering the source code of an application according to the present embodiment.
FIG. 3 is a diagram for explaining a state diagram in which a call graph derived according to the present embodiment is simplified based on activities.
4 is a view for explaining an activity-based state diagram to which an activity life cycle is added according to the present embodiment.
5 is a diagram for explaining an activity life cycle.

Hereinafter, the present embodiment will be described in detail with reference to the accompanying drawings. It should be understood, however, that the scope of the inventive concept of the present embodiment can be determined from the matters disclosed in the present embodiment, and the spirit of the present invention possessed by the present embodiment is not limited to the embodiments in which addition, Variations.

FIG. 1 is a diagram illustrating a test case generation procedure of an Android application. FIG. 2 is a diagram illustrating a call graph derived through reverse engineering of an application source code according to an embodiment of the present invention. FIG. 4 is a view for explaining an activity-based state diagram to which an activity life cycle is added according to the present embodiment. 5 is a diagram for explaining an activity life cycle. Hereinafter, a method of generating an activity-based state diagram according to an embodiment will be described with reference to the drawings.

In this embodiment, a call graph representing a call relationship between unit programs (functions, procedures, activities, and the like) is generated by a reverse engineering method using a static analyzer for test case generation . The node of the call graph represents a unit program, and the trunk represents a call between unit programs.

There are black box tests and white box tests for testing Android applications, and black box tests are used to check what results are obtained for the input values, regardless of the intermediate internals (for example, source code) White-box testing, on the other hand, is used to check whether the application works properly within the source code, and function call relationships can be targeted.

This embodiment is for a white-box test of an Android application, and a method for testing a GUI.

Referring to FIG. 1, in order to generate an activity-based test case, an activity-based call graph is first generated through reverse engineering from the source code, and an activity state diagram is generated by adding call graph and activity lifecycle information.

Then, in the activity state diagram, you can create a test case with depth-first search. Hereinafter, a method for generating an activity-based state diagram for generating a GUI test case for a notepad application will be described with reference to an exemplary embodiment of the present invention.

In order to test the GUI of the Android application, we need to create a scenario for each screen unit activity of the application. We will explain how to create a state diagram based on activities that should be preceded in order to complete the scenario creation before the scenario creation.

Various methods can be used as a method of generating a call graph, and a call graph can be generated as shown in FIG. 2 by generating a call graph from a notepad sample source code of an application of the Android using a conventional method.

Referring to FIG. 2, the notepad application may include a NoteList (a first activity, 10), a NoteEditor (a second activity 20), and a TitleEditor (a third activity 30) corresponding to an activity, Includes at least one or more functions.

For example, the function may include functions (14, 15, 16) that operate in the activity and functions (11, 12, 13) that call other activities. Among the functions that call other activities, a function (OnOptionItemselected, 11) that calls a plurality of activities may be included, or a function (OnContextItemselected, OnListItemClick) that calls a different activity may be included.

On the other hand, the OnCreate function is called when the activity is created, performs activity initialization, and receives the status information stored by the savedInstanceState method as a parameter.

OnStart is called just before the activity appears, and OnResume is called when the activity is in the foreground state, and the activity is at the top of the activity stack. It indicates the start of play of an animation, music, etc. in a state in which the user can operate.

In addition, OnPause is called when another activity is executed and the current activity is going to be in the Background state, and the program stores the state information to be maintained continuously.

OnStop is called when the activity is no longer visible to the user in the background state, and when the memory is full, the system can terminate the process without calling OnStop.

OnRestart is called when the activity changes from background to foreground, OnDestroy is called when the activity ends, and when the memory is full, the system can terminate the process without calling OnDestroy.

Next, referring to FIG. 3, as described above, in the generated call graph, a node connecting one activity to another activity is connected to an edge between two activities, and the other nodes are connected to the cycle trunk of the activity Activity-based state graphs can be simplified.

However, the graph of the simplified state diagram does not include the lifecycle characteristic of the activity. Each activity has a different lifecycle, so the order in which you move to the previous activity is different. Adding the lifecycle information of these activities leads to an important problem that the previous state must exist because the life cycle of the start activity also exists.

To this end, the operation of adding the lifecycle of the activity as shown in FIG. 5 to the simplified state diagram is performed. The activity life cycle is often determined by the Android OS and includes activity, running, pause, stop, and killed.

An operation to add this activity lifecycle to the state diagram is performed (Figure 5), adding the mobile interference from the simplified state diagram (Figure 3) to the previous activity according to the back_Key event not implemented in the source code (Figure 5).

You can complete an activity state diagram that takes into account the characteristics of Android by adding an arbitrary initial state to return to the pre-application state when moving from the first activity or other activity of the application to the previous state.

The generated activity state diagram is transformed into a linear graph, and a test case can be created by using the depth-first search method and utilized in the state-based white box test.

Let's take a more detailed example of how to create a state diagram with an activity life cycle added.

For example, each activity checks whether there is a finish function that indicates the end of the activity. finish indicates the end of the activity pointing to the screen. For reference, since the life cycle of an activity such as a back key is not known only by performing reverse engineering, it is difficult to predict a result value when a scenario is created in this state diagram.

Simplify the function lists for the source code of the application analyzed through reverse engineering, and add the lifecycle of activities (for example, hardware back key) to the simplified state diagram. This state diagram is a display format used in software engineering (SE) and automatically generates a simplified state diagram by processing a call graph.

On the other hand, as a result of checking whether each activity has a finish function, an event to the (N-2) -th stage of the previous step is added to the activity including the finish function, and for the activity not including the finish function, (N-1).

Activities must have their own lifecycles and describe event backs (backyck events) as examples of life cycles. By automatically generating a state diagram to which such an activity life cycle is added, it is possible to complete the scenario to be created later.

Claims (2)

A method for generating an activity-based state diagram of an Android application, prior to creating a scenario for GUI testing of an Android application,
Performing reverse engineering on the source of the application;
Generating a state diagram based on the activity for the result of the reverse engineering performed as described above; And
And adding a life cycle of the activity to the state diagram. The method of claim 1,
Adding a life cycle of the activity,
Checking whether there is a finish function for each of the activities;
If the activity includes a finishing function, an event bag that moves to the previous stage (N-2) is added. If the activity does not include a finishing function, an event bag that moves to the previous stage (N-1) is added And generating an activity-based state diagram of the Android application.

Images