White Box Software Testing for Android

The testing of software application internal infrastructure and coding is referred to as white box testing. White box testing is also called open box testing, clear box testing, transparent box testing, glass box testing, structural testing, or code-based testing [1]. White box testing primarily focuses on the internal structure, design, and implementation of the software with the aim of strengthening security, improving design and usability, and the flows of input and output within the application.

When using this approach, the tester concentrates on how the software performs what it is supposed to perform. In order to perform white box testing, a tester should have programming know-how in order for them to understand the code used within the software and understand its implementation. This is because the tester would be testing the software beyond the user interface and going into the nitty-gritty of the application. When conducting white box testing the tester would understand the various lines of code that are being executed and the ones that are not. In case there is a line of code not being executed it means there is missing logic or there is a typo that could lead to negative consequences. This method of testing of testing is referred to as white box because the software application in the eyes of the tester is like a transparent or white box where one can see clearly what is happening. There are two types of testing that a software would undergo namely white box testing and black box testing. Black box testing is testing from an end-user perspective. The names were coined based on the view the tester would have when performing each type of testing. Black box testing does not allow the tester to see the inside of the software. Rather they only interact with the end-user side of the software. Having the different types of testing ensures that the software is vigorously tested before it is launched into the market and any issues discovered can be sorted out.

When conducting white box testing, the tester is checking the software for:

• Internal security holes.
• Flow of specific inputs.
• Poorly structured paths.
• Expected output.
• Conditional loops functionality.
• Testing each object, statement, and function individually.

The tester would conduct the testing at system, integration, and unit levels of the software. The aim of white box testing is verifying the working flow of the software or application [2]. The tester would have to test using predefined inputs to check the expected outputs. In case a predefined input results in an unexpected output the tester would know there is a bug.

The first step involved in white box testing is understanding the code where the tester has to learn and understand the software's source code. Since white box testing involves testing the inner working of the software, the person testing should have knowledge of the programming language used in the software. Secure coding practices should be at the forefront of the tester's mind, and they need to know and understand them. The tester must be able to find any security issues and prevent attacks because the primary objective of white box testing is securing the software. The tester must also check to ensure that a user might not knowingly or unknowingly inject malicious code within the application.

The second step involved in white box testing is creating test cases and executing the test cases [3]. The tester would be testing the software's code for proper structure and flow. One of the way of conducting this test is by writing additional code for testing the software's source code.

For each process in the application, the tester would develop small tests aimed at checking the workings of the process. This step is mainly done by the developer because it requires the tester to have intimate knowledge of the code.

There are three main types of white box testing namely:

• Unit testing.
• Integration testing.
• Regression testing.

A unit test is a level of software testing that test individual components of a software. The aim of unit testing is validating if each component/unit is performing as expected. A component is considered the smallest part of a software that can be tested. The component normally has minimal inputs and a single output. Unit testing is normally the first testing type that is performed on a software. The programmer or developer is the one who conducts unit testing because it is done as the code is being written or developed. The programmer would write some lines of code, a function, or object and conduct a test to determine if they are working before progressing [4]. Conducting a unit test allows for the identification and fixing of bugs early on in the development of software, which makes it easy and cheap to fix the bugs.

Unit testing might seem or sound time consuming, but in the long run, it turns out to be more reliable than developer tests. Conducting test on individual components makes it easy to reuse the codes with confidence that they will work and this does reduce the coding time. Conducting unit testing as the development is ongoing allows for easy troubleshooting because only the most recent changes need to be checked in case there is a bug. A good example would be the manufacture of a ball point pen. Each component is manufactured separately. The components are the cap, body, ink cartridge, ballpoint, and tail. These components need to be checked individually to establish if they are working as expected. Once a component has been manufactured it is tested to see if it works and if it does not then it fails the next process. Only those components that are working would progress to the next stage.

During this testing stage, individual components are combined together and tested to establish if they produce the desired results. The main aim of this testing is to bring out any faults with the interaction of the integrated units [5]. Integration testing can be performed by the developers or independent tester. When doing integration testing the tester could use different approaches like:

• Big bang.
• Top down.
• Bottom up.
• Sandwich/hybrid.

The big bang approach is where all components are integrated and tested at the same time. This approach is normally used when the software is submitted for testing in one bundle.

It should be noted that the big bang approach only tests the interaction between the units and not the entire software. The Top Down approach is a systematic way of conducting the testing where the tester would start with the top-level units and move down till the last/bottom unit is tested.

This differs with the Bottom Down approach that begins testing from the bottom units heading upwards systematically unit by unit. The Bottom Up approach is only used if the software development was conducted using the bottom-up approach. Finally, the Sandwich/Hybrid approach is a combination of Bottom Up and Top Down approaches.

In order to carry out a successful integration testing the tester should be able to have a detailed document that shows where the interaction of the different units take place. Without this information, the tester would not be able to conduct this test. Integration testing should not be conducted if Unit testing has not taken place. This ensures that each unit is working as expected and in case of any bugs the tester can link them to the integration and not individual unit. Using the ballpoint manufacturing example, integration testing would take place when two or more units are ready and have been tested individually. The units are assembled and tested to establish if the cap does fit, or the ballpoint cartridge fits as expected into the body.

Regression is a type of testing that verifies a software is still working as expected after a change or modification has taken place. The changes may include configuration changes, patches, or software enhancements. Regression testing involves the execution of partial or full test case that had previously been executed in order to check if the software functionalities are working fine [6]. Developers need to conduct regression testing to ensure that the changes they have done to the software have not resulted in faults or bugs. Another reason to conduct regression testing is to determine if a change in one part of the software would have an impact on another part of the same software. When carrying out regression testing, not all test cases need to be reused, only a select few that are related with the change or modification carried out need to be run.

For example, when working with a software for managing employee records, there could be three modules Personal Information, Admin Module, and Employment Module. If a bug is discovered in the Admin module that prevents a genuine user to log in, then that bug should be reported and fixed by the developers. Once the bug has been fixed the tester would have to recheck the software again to ensure that the reported bug has been fixed, this type of re-testing is known as regression testing.

When testing for android applications, the main types of white box testing to be carried out are unit testing and regression testing. However, this does not mean that integration testing does not take place. Integration testing could be taking place, but currently, it has been coupled up with unit testing on android.

Android unit tests are the same as explained above and they basically refers to the testing of individual components of an application. The tester must be aware of the Android SDK and should have Eclipse installed on their machine. In Android, the smallest possible unit is called a method, class, or component, and the tester would have to exercise the functionality of the unit repeatedly to ensure that it provides the same result all the time. Unit tests should only be built when the developer wants to verify logic for specific code within the application. Normally unit code is done in isolation to ensure that the test only monitors changes and affects that particular unit only. For a tester to isolate a unit, they can create a mocking framework. A mocking framework is the creation of mock objects that mimic real objects behavior in controlled ways. A mock object is created when a programmer wants to test the behavior of another object. A mocking framework is only used for object-oriented programming, and Android falls perfectly within this category of programming. A developer can make use of various automated test applications, but the most recommended one is JUnit Testing Framework. JUnit pushes for developers to first develop tests then start coding [7]. This approach increases the programmer's productivity because they have to test a little and code a little. With this kind of approach, the programmer is able to stay focused, and they can increase the speed with which they work on the application. JUnit offers a perfect test environment for Android applications developers because most applications are written in Java.

When testing Android applications using unit tests one would have to use either local tests or instrumented tests. Local tests are tests that the developer would run on their local machine. The tests are run on the Java Virtual Machine (JVM), and the developer would compile them locally. The reason for using this environment is that is reduces execution time and when the test do not require or have Android framework dependencies.

Instrumented tests are tests that are carried out on an emulator or android device. The tests would have access to instrumentation information. This approach should only be used when the tests being performed cannot be run locally using mock objects and have Android dependencies.

Android applications require a lot of updates and code modification before the application can be released to the general public. Even after release there is need to keep working on the application to fix any issues that the end-users might discover in their normal usage. For this case, it is vital that a developer has a way for retesting their application after any changes without having to conduct an individual unit test for each unit. Regression testing plays a big role, especially for android developers. There are various automated applications that allow the developer to create regression tests easily and run the test automatically. With regression testing, the developer would only need to conduct few tests to check for the changes they have conducted and if the changes have had any major impact on the application's working. The recommended application for running regression tests for Android application is monkeyrunner. Monkeyrunner provides an API for programmer to write programs for controlling Android devices from outside of Android code. When using monkeyrunner to test an application, it will conduct the test at the framework/functional level. The tool can also be used for running unit tests. If a developer decides to use monkeyrunner for regression testing. The application would compare the application stability against output screenshots know to be correct.