Android Conversion Support Framework for Android Software

4 downloads 372979 Views 450KB Size Report
tool named Android Conversion Support Framework (ACSF). The ACSF has several functions which help to remove some repetitive or unnecessary tasks on the ...
Android Conversion Support Framework for Android Software Won Shin1, Tae-Wan Kim2, and Chun-Hyon Chang1, * 1

Department of Computer Engineering, University of Konkuk, Seoul, Korea Department of Electrical Engineering, University of Myongji, Gyeonggido, Korea

2

Abstract - The android software is needed huge test process for many kinds of devices and android platforms because android platform does not support interoperability among various platform versions, and it can be modified by device manufacturer. To resolve this problem, we suggested a new tool named Android Conversion Support Framework (ACSF). The ACSF has several functions which help to remove some repetitive or unnecessary tasks on the software testing. Those functions execute automatically and find some points of software which seem to have problems and need to fix. In this paper, we show several components of the tool and explain characteristics of the tool in detail. Developers who use the tool can fix problems of their software, are related with portability, on the porting process easily and quickly. Keywords: Android interoperability

1

Software,

Test-case,

Framework,

Introduction

We can see lots of android software as known as App easily. Manufacturer of device which is based on android platform can modify android platform code for their devices suitably because Google allows to modify source code of the platform if the platform can be passed CTS test. Android platform is also well known that it is not support interoperability among various platform versions. It means that there are a lot of difficulties in testing software on various platforms and devices. For instance, a developer make an application based android platform version 2.0 but he does not sure about that his application executes well on the version 2.1 because of the interoperability. Therefore, the android software is needed huge tests process for diverse devices and android platform versions. Many tools and techniques exist for automating the testing of mature, well-established applications, such as desktop or server programs. However, the physical constraints of various device as well as interoperability problem of android platform make android software prone to new kinds *

Corresponding author.

of bugs [2]. To resolve this problem, we suggested a new tool named Android Conversion Support Framework (ACSF). The ACSF support several functions and those functions help developers to reduce a time for doing repetitive or unnecessary tasks on the software testing. Those functions are mostly automatic and detect potential bugs in the software. Developers get helpful information from the tool without their effort when they only use the tool. To find potential error, first, developer generates monitoring code. Secondly, the monitoring code is compiled and is executed on emulator automatically. Finally, the ACSF try to detect errors in logs generated from the software. In this paper, we show several components of the tool and explain characteristics of the tool in detail. Developers who use the tool can fix problems of their software, which are related with portability, on the porting process easily and quickly. The rest of the paper is organized as follows. Section 2 describes related works and ACSF we suggested. Section 3, then, presents characteristics of the tool in detail. Finally, Section 4 concludes and explains future works.

2 2.1

Related works Previous Test Techniques

To test android software is needed to verify whether functions of the software have some problems or not. Developers usually use a tool or framework for functionality test such as JUnit [4], Robotium [6], Android Testing Framework [1]. Those solutions support developers to make test-case for testing android software easily. For instance, JUnit for android has a function to generate test source for Activity, Intent and so on. Developer can define an action when an activity is creating or destroying via the function of JUnit. In testing phase with JUnit, once developer makes a test-case using them, and then they run the test-case. Android software is GUI software, therefore, it require GUI test which verify to be executed well by some GUI

events such as click, drag and drop, and so on. There are three kinds of GUI test technique. Record Play-Back (RPB) technique is the most famous and is known well among them because to use it is easier than the others. In the RPB technique, one event is called the Record and script includes several records [7]. In testing phase with GUI test technique, one developer makes an event script which contains sequence of events, and then feed each event from the script.

program analysis component analyzes software for making an Analysis Information which contains scope of analysis. The monitoring code generating component makes a meta file and generate source code as a test-case using the meta file[3, 9]. The program auto test component compiles the test-case and execute on emulator[10]. The acquire log and the log analysis component collect logs and make a report via analyzing the logs.

For applying the RPB technique to the android software testing, it firstly needs to consider how to adopt concepts of android software such as Activity, Intent and so on. It also adds new method to reduce effort for making test-case because there is no support to generate a test-case automatically.

3

2.2

Design of ACSF

Developers have several tasks for software test, for example, making a test-case, running the test-case, analyzing a log. Some logs are generated during running software via logging instructions. Developers try to detect potential errors in the logs. A role of ACSF reduces tasks of developer, hence, architecture of ACSF is considered android platform and technique about automatic comparison logs like Fig 1. Program Analysis Component Program Analyzer Analysis Info. Generator

Monitoring CodeGenerating Component Analysis Info. Monitoring Sensor Template

Monitoring Sensor Gen. Monitoring Code Gen.

_____ _____ _____ _____ _____ _____ Log Analysis Component _____ _____ _____ _____ _____ _____

Log Analyzer

Report Gen.

Log Repository

Program Auto Test Component Compile Automation

Acquire log Component

Report Template

Testcase

Execute Automation

Communicati on Module Log Gen.

Figure 1 Architecture of Portability Analysis Tool

A process of android software is very similar development phase of embedded software. Testing software on emulator or real device is vital element in development of the embedded software. A testing on emulator is rather important than a testing real device because a testing on real one takes more time and it is difficult to test whole devices due to its price. Moreover, it needs more tasks for testing. For instance, once developer prepares a device and copy software in the device. And then they tests software using the device. After testing, they move a log which is made during running the software to the desktop computer. Finally, they analyze the log. However, testing on emulator, it just requires configuration of emulator. Architecture of ACSF is based on conceptual development process for android software[8]. The Architecture is largely divided into five components. The

Implementation of ACSF

Many developers use Eclipse with Android Development Tool (ADT) plugin which help us to develop android software easily via emulator, monitoring tool, etc. Therefore we decide to develop our tool based on Eclipse plug-in. ACSF consists of five kinds of components like Fig 1. In this paper, we concentrates on generating test-case, auto executing android software on emulate or device and analyzing portability of the software because those components have to considered android environment and vice versa.

3.1

Generating test cases process

An Android software is GUI based software, therefore,, functions of the software are executed by events generated from users. Also, events can have sequences or not. On the other hands, test-case may contain sequence of events. Consequently, we divide manual mode and automatic mode for making test-case. The manual mode has dependency with user’s events or data, and vice versa. The manual mode is based on improved RPB technique which record user event as a script and execute the script. If developer only changes some event in the script, developer makes a script again although the script exists. Therefore we support sequence concept which is method to modify or arrange a script. As making a sequence, user can use records as well as UI components contained in activity. The manual mode is used for alerted software error due to malfunctions of the software. Fig 2 illustrates manual test-case generator.

Figure 2 Manual Test-case Generator

On the automatic mode, user only chooses pair of activity name and sensor type. It means that selected activity will be generated logs from selected sensor. The sensor is a source code for making various logs and is used for various

purposes such as verification status, making screenshot and so on. Table 1 illustrates types of sensors.

troublesome works because it is repetitive. Compile the code first to make an APK file and then upload the APK file to emulator. Finally, run test cases. The program auto test component supports above process automatically.

Table 1. Types of monitoring sensor Sensor Type TIA TIE TIC DIV DIS UIU

Description (purpose of this sensor) Whether activities run well or not Whether events run well or not Capture device’s screen Important variable value System status User defined log

TIA and TIE are function to verify whether activity or event is running well or not. Thus those are inserted next instruction which creating and destroying activity, and event execution. A log, which is made by TIA and TIE, explain that operation of activity is normal and event has no problem because it is impossible to be generated the log if program is not running well. TIC sensor captures a screen in various devices to discern difference. Actually, to compare two images is a role of developer because they must be too subjective. The tool can only give numerical value related to image’s color or structure, and those value is use to divide into two groups which need to verity and not. DIV is monitored values of some variables because variable must have boundary and an error is occurred when the variable has under or upper boundary. DIS is to make a log related to system status. The reason why gathering system status log is that embedded system like a mobile affects from system a lot. It means that it is important a system log to find a bug on software. The automatic mode is used for finding unexpected error in software because it generates randomly input in test-case. Fig 3 illustrate automatic test-case generator.

Users select first what device is needed a test and then they choose test-case which is made in previous step. They click the test-case create button to generate selected test-case. For making the test-case, we use compilation technique which parses the source code and then makes an Abstract Syntax Tree (AST), transform the AST and travel the tree to generate the test code. Transform the tree means that search several parts of code, which the position for inserting the monitoring code, and then insert special AST node into the tree. The special AST node is made from a code which has special instruction such as printing log, capturing screen and so on.

Figure 4 Automatic Execution Test-case

3.3

Analyze portability

Software may generate several logs post-run. Actually, developers compare and analyze those logs. They try to find differences among the logs because those must be no change if software is not modified. Existing difference means that the software is affected by android platform or device, hence ACSF finds candidates which are expected to generate error, and then generate a report.

Figure 3 Automatic Test-case Generator

3.2

Automation running the test cases

After making monitoring code, it will be run on the various platforms or devices. Those tasks are really

Figure 5 Portability Analysis

To make a report, developer should select two kinds of logs. One of them is generated by software which has no errors and finished already software development. It is to be the criteria for comparison logs and is named default platform. Another one is generated by the others except default platform, and it seems to expect making an error.

make an error during running the software, but developer must know existence of the potential error. Developer should fix it or prevent problem due to it. To use the tool, it may reduce the time for software testing, therefore, developers concentrate on the service of their software and improve software quality. In future, we will make more meaningful information for developers to help their development process.

5

Acknowledgments

This research was supported by R&DB Support Center of Seoul Development Institute, Korea, under Seoul R&BD Program (ST100107)

6

References

[1] Android Testing Framework, “http://developer.android.com/guide/topics/testing/index.html ”

Figure 6 Report of the ACSF

Information of a report is largely divided by summary information, compilation information, execution information like Fig 6. The summary information contains of description, statistics, it help understand structure of the software, recognize status of test phase and explains what devices are tested. Developers can decide how much effort is needed to fix bugs of this software via the summary information. The compilation information explains how many errors are occurred during compile source code and which platforms make problems. Moreover, it also contains compilation error logs. Developers can recognize what kinds of errors are occurred without running their software on the platform. They just find why error is occurred on that platform and then resolve the problem. The execution information describe comparing image of execution activity on each platforms and explain differences between logs. It is difficult to find a problem which is made by difference between resolutions of two devices, hence ACSF just support two kinds of images of each platforms.

4

Conclusion

Most developers have a difficult time finding the bug which is due to portability. To overcome this difficulty, they use tool which support several functions to reduce their repetitive and unnecessary tasks. The ACSF generates a report from analyzing and running software. The report contains diverse information such as summary information, compilation information, execution information. Especially, candidate of error in the execution information is the most important one. We are not sure about that the candidates will

[2] Cuixiong Hu, Iulian Neamtiu, “Automating GUI Testing for Android Applications”, Proc. of International Workshop on Automation of Software Test, pp. 77-83, 2011. [3] Doo-Ho Park, Won Shim, Tae-Wan Kim, Chun-Hyon Chang, “Android Software Test case Generation System using Record-PlayBack”, Proc. of the Korea Computer Congress 2011, Vol. 38, No. 1(B), pp. 171-174, 2011. [4] JUnit, “http://www.junit.org” [5] Monkey UI/Application Exerciser, “http://developer.android.com/guide/developing/tools/monkey .html” [6] Robotium, “http://code.google.com/p/robotium/” [7] Wei Hoo Chong MIET, “RPB in Software Testing”, Proc. of the International Multi-Conference on Computing in the Global Information Technology (ICCGI), pp. 8-13, 2007. [8] Won Shin, Tae-Wan Kim, Chun-Hyon Chang, “Portability Analysis Tool for Android Application”, Proc. of the JCCIS, Vol. 4, No. 2, pp. 186-189, 2010. [9] Won Shin, Jung-Min Park, Tae-Wan Kim, Chun-Hyon Chang, “Methodology of Automatic Test-case Generation for Android Software”, Proc. of the Korea Computer Congress 2011, Vol.38, No. 1(A), pp.198-201, 2011. [10] Won Shin, Jong-Soo Seok, Tae-Wan Kim, Chun-Hyon Chang, “Test Automation System for Android Software”, Proc. of the Korea Computer Congress 2011, Vol.38, No. 1(A), pp.202-205, 2011.