An UI Layout Files Analyzer for Test Data Generation

Prevention actions (trainings, audits) and inspections (tests, validations, code reviews) are the crucial factors in achieving a high quality level for any software application simply because low investments in this area are leading to significant expenses in terms of corrective actions needed for defect fixing. Mobile applications testing involves the use of various tools and scenarios. An important process is represented by test data generation. This paper proposes a test data generator (TDG) system for mobile applications using several sources for test data and it focuses on the UI layout files analyzer module. The proposed architecture aims to reduce time-to-market for mobile applications. The focus is on test data generators based on the source code, user interface layout files (using markup languages like XML or XAML) and application specifications. In order to assure a common interface for test data generators, an XML or JSON-based language called Data Specification Language (DSL) is proposed.


Introduction
Software testing is an important phase within the software development cycle.It is also an expensive phase counting about 40% of the total cost associated with software development [1], [2].According to ISO9000 standard [13], the quality associated to a deliverable is seen as being "the degree to which a set of inherent characteristics fulfill requirements".If the requirements are not (completely) met, severe consequences may follow, like intensive rework or even the risk of losing the business.From an economic point of view, quality measures are indicating the application actual metrics (in terms of cost, time and scope) that can be easily compared with the planned ones.To fulfill the requirements is crucial but the way in which these requirements are met in terms of time, cost and application scope is also very important because an application may be delivered in time but with a lot extra work and/or by using lighter inspections, so the project may not be so successful due to the reduced profits and very possible future implementation costs.When discussing about the quality of a software application, usually there are two types of costs assigned [14]:  poor quality costsdefects that must be repaired by corrective actions;  good quality costscode inspections and prevention activities, like planning, training and auditing.As illustrated into the Figure 1, any application can reach a great quality level at a reasonable cost by positioning itself just above the optimal point indicated by the vertical line.Testing methodologies include white-box and black-box approaches [3], [4].White-box testing considers the internal structure of programs.In this case, test data generation uses several coverage criteria (path, statement, branch etc.).Black-box testing does not depend on the internal structure of programs.Test data is generated based on program specifications.One area of software testing that can be automated is test data generation.Test data generation based on coverage can use random or optimized inputs, engaging advanced techniques [5], [6].

Fig. 1. Total Cost of Quality
There is a continuous uptrend of mobile application development.Compared with other software solutions, time-to-market for mobile applications tends to be shorter.A mobile application can be used on different versions of the target platform, on different hardware configurations (screen size, processor architecture, processor speed, memory capacity etc.), different types of networks (Wi-Fi, mobile) etc.In this respect, mobile applications testing is more challenging than other type of application testing [7], [8], [9].Every improvement of testing process for mobile applications helps achieving high quality software, reducing the development costs and the time-to-market.We propose a complex system for automated test data generation for mobile applications in order to reduce the required time for testing while keeping the same level of quality.This integrates our previous work that includes researches related to test data generators based on source code as in [6] and [10] where we proposed a test data generator using genetic algorithms and a framework for test data generators analysis.The system combines several inputs for test data generator in order to achieve an optimized set of inputs that assure the best coverage of code and the input domain.The paper is organized as follows: Section 2 describes the proposed framework for test data generators for mobile applications and the Data Specification Language (DSL).Section 3 presents the proposed components of the test data generator that are based on source code, user interface layout files and specification.Section 4 presents the same example implemented for two mobile platforms (Android and Windows Phone) in order to highlight the UI layout files challenges.Section 5 is dedicated to the discussion related to presented work.The paper ends with conclusions and future work.

Test Data Generators
The TDG is a complex system that include several subsystems that are linked together by inputs and outputs.The proposed system consists of the following components:  Source code analyzer;  User interface files analyzer;  Specification analyzer;  Test data generator.The input of the system consists of the source files, user interface layout files and specifications.The system components are depicted in Figure 2.

" ] } } ] } }
The framework is flexible enough to accept any other components that will provide data specification files based on DSL.The test data generator is further detailed in Figure 3.There are at least two types of inputs so there will be two distinct data generators, each one using a different way to produce the expected test data.The instrumented source files are the output of the source files analyzer.These will allow to record the code coverage by executing it.

Fig. 3. Test data generator components
The outputs of UI files analyzer and specification analyzer are DSL files that represent the input of data generator.This will parse the DSL files and will produce test data for the software under test (SUT).

TDG Analyzers 3.1 Source Code Instrumentation
This module will parse the source code and will instrument the files in order to record the code execution.Structural testing is subject to numerous papers, including [11] and [12].
Test data generators are based on the associated control flow graph (CFG), control flow diagram (CFD) or program tree.
After the source code is instrumented, it is used as input by the data generator.This will generate test data either randomly, or using evolutionary algorithms.The SUT will be executed using the generated data in order to achieve the targeted coverage criteria, depending on the required level: statements, branches, paths, blocks, data flows or functions [6].
The source code is modified by adding simple calls to output functions or to more complex functions.While SUT is running, the calls will record the executed functions to calculate the coverage with the current data set.
The source code analyzer could also generate the associated CFG, CFD or the program tree that can be used as inputs for other types of data generators.

User Interface Layout Files
Several mobile application development include, as other platforms, the possibility to declare the user interface layouts using separate files based on markup languages.For example, Android developers use XML files to declare the interface, iOS developers create storyboards while the Windows Phone developers rely on XAML files.The analyzer will parse the UI layout file and, for each control, will determine the associated properties.Based on the control type and the associated attributes the analyzer will generate test data specification using DSL format.For example, Table 1 presents an example for the basic input text control as defined by different UI layout markup languages.Several sources such as [15], [16], [17], [18] and [19] present the content and structure of Android, iOS and Windows Phone UI layout files.If the input type is specified, this will help in determining the data type for that input text control.Table 1 shows that the exemplified fields requires numeric input and so the test data domain will be narrowed to this type.Other controls may have two or more states or they can use a list of predefined values.
All of these can be used to describe the data that will be generated for the component under test.

Specifications
The specifications represent one of the most important source for the test data generation.The level of details (user and system specification), the representation and the storage medium for specifications may vary from one team to another.This high level of variation generates some challenges for generalization.In this respect, the analyzer will require a preprocessing phase that will unify the input for the specification analyzer.As stated in [2], the requirements are of two kinds, functional (related directly to the application) and nonfunctional (usability, performance, security etc.).Test data generator should focus on both types of requirements.Each component under test (module, class, screen etc.) will require the associated specification files.This could include inputs, outputs, source, destination, actions, preconditions and post-conditions etc.

UI Layout Files Analysis
In order to implement the UI layout file analyzer, the same example will be used for two platforms: Android and Windows Phone.The example consists of a screen used to collect user data such as first and last name and age.The UI layout analyzer should detect three text fields used for data entry.The third field (age) should contain only numbers.An excerpt from the UI layout file for the Android application is presented in Listing 2. For this example the targeted controls are EditText type.For these controls the android:inputType attribute is located in order to determine the input data type.Another attribute for the EditText control is android:maxLength that gives information related to the maximum text size that will be generated for this field.

Discussions
The test data generator designed for mobile applications include several analyzers that generate data specification files (based on DSL markup language) or instruments the source code.Data generators are implemented differently based on their inputs.Table 2 presents the main characteristics identified for data generators depending on their functionality.The analyzers for source code and user interface files require total or partial access to the application source files.The UI layout files are part of the application project and have to be parsed by the analyzer.The analyzer results can be combined to obtain test data specifications.The specification analyzer does not require access to any of the source files.The source code analyzer and the UI layout files analyzer require knowledge about the internal structure of the application.These modules are closely related to the developer.The specification analyzer is independent of the application implementation and it is closed to the user or customer.The code required to generate test data based on source files has a high complexity.TDGs are dependent on the programming language.Firstly, a source files has to be instrumented.Then, data generator will run SUT in order to record the code coverage.For UI layout files the parser is language dependent and it is DOI: 10.12948/issn14531305/18.2.2014.06possible to be implemented for several markup languages.The specification analyzer is less complex, but it requires a preprocessing phase, that could include manual work, in order to receive the desired input.The main advantages of the proposed solution are:  a broader source for test data generation;  it targets structural and functional testing approaches;  flexible design, that allows the development and use of other components;  uses standard input and output files in order to allow a common interface.The UI layout files analyzer is a useful tool for test data generation.It has a medium complexity, but could be very helpful in generating test data, especially when the specifications are missing or are incomplete.The proposed solution has components with a high level of complexity and it has to be adapted for each targeted platform.

Conclusion and Future Work
Reaching a high quality level for a software application can only be done by massively investing in prevention.This is why it is very important to position ourselves just above the optimal value of the TCQ (Total Cost of Quality) where the quality costs are minimal and the quality level is high enough.Due to the exponential grow of the TCQ shape, a very high quality level turns to be somehow uneconomical since the investments needed are much higher than the achievements in terms of quality.Test data is very important for the success of any application.Test data is required at several levels that are closed to the developer (source code) or to the users/customers of the developed application.There is no single solution for test data generation and these available options have to be used together in order to obtain the best results.The proposed system is based on several inputs for test data generation and it could be extended for other types of input.Each input will be used by a dedicated analyzer that will generate outputs for data generators.Finally, data generators will produce test data for the software under test.On the short term, the future work will include the development of the UI layout files parser for mobile applications together with the associated data generator, and a detailed description of DSL language.On the long term we intend to implement the proposed solution in order to be used in a real environment.

Fig. 4 .
Fig. 4. Example of a test screen from the Android application

Fig. 5 .
Fig. 5. Example of a test screen from the Windows Phone application POCATILU graduated the Faculty of Cybernetics, Statistics and Economic Informatics in 1998.He achieved the PhD in Economics in 2003 with thesis on Software Testing Cost Assessment Models.He has published as author and co-author over 45 articles in journals and over 40 articles on national and international conferences.He is author and co-author of 10 books, (Mobile Devices Programming and Software Testing Costs are two of them).He is professor at the Department of Economic Informatics and Cybernetics within the Bucharest University of Economic Studies, Bucharest.He teaches courses, seminars and laboratories on Mobile Devices Programming, Economic Informatics, Computer Programming and Project Quality Management to graduate and postgraduate students.His current research areas are software testing, software quality, project management, and mobile application development.

Table 1 .
Example of input text declaration The resulting DSL file (XML-based) is presented in Listing 4.

Table 2 .
Comparison of test data generators flows