Hi Guys,
Its been a long time since wrote an article since I was busy on the personal front. Today I will be discussing about a topic that is something I am very passionate about and that is none other than J2ME Testing.
What is J2ME ?
J2ME(Java 2 Micro Edition) is a framework from Java that is used for writing programs and applications for mobile devices such as mobile phones, PDAs, smart phones,tablets,set top boxes etc. In J2ME an application specification is given by two terms. They are :-
The CDC is a Library that provides API fro devices such as tablets, set top boxes, Television etc.It also provides networking capabilities to the application and upward compatability with other Java Libraries like J2EE and J2SE.
MIDP is a set of Java API. Both MIDP & CLDC work together to provide complete application runtime environment for mobile phones
As a matter of information I would like to tell you all that J2ME application runs on KVM(Kilo byte Virtual Machine) unlike other Java Applications that run on JVM(Java Virtual Machine) . We use KVM instead of JVM as JVM cannot be deployed on these devices due to resources constratints.
All applications that are developed using J2ME APIs are called MIDlet. The MIDlet runs on Application Management Software(AMS) that is already installed in MIDP devices. One J2ME software can have multiple MIDlets bundled in it.
The MIDlet has a life cycle.It has 3 stages
Ok Dude now I know what is J2ME.What are the testing aspects here ?
Though J2ME seems simple. There are numerous aspects of testing to these applications. They are as follows:-
I will now be discussing each of these in detail.
Functionality Testing
Like any other testing the aim of the testing is to find out whether the application is doing what it is supposed to do and not doing what it is not supposed to do. This includes input validation, validating application workflows, login validations to view the application etc.This can be tested both on device and an emulator. If any exception is thrown which makes the application to quit must be reported as a bug in this phase
State Based Testing
This Testing is to ensure that MIDlet lifecycle is carried out smothly while the MIDlet is running. In certain cases A MIDlet cannot be exited when doing certain critical opertaions such as fund tranfer from one bank account to another. The AMS should not allow the MIDlet to exit, Such testing can be done in this phase. In such cases the IllegalStateException is thrown and this does not allow the user to exit. Also in cases of any interruptions such as phone call or sms, the application must be observed as how the applications goes to paused state and resumes once when the high priority process is over.
UI Testing
This testing mainly focuses on whether the UI is user friendly or not, The UI navigation of the application and whether proper GUI objects are placed for certain operations. Eg: If an application is doing a Bluetooth Search a Gauge has to be placed on the screen with appropriate message. Instead if a blank screen or the existing GUI is displayed then it is considered as a bug as it gives a notion that the application is hanging. Also any exception thrown from UI must be handled accordingly. If any exception(from UI perspective) is not handled then bugs must be raised for the same.
Exception Handling Testing
This testing maily comes in White box testing particularly in Unit Testing Phase of V & V-V model. For every exception handled in the code the tester must try to create a situation such that the exception is handled by the application and the appliucation does not crash. This enables to understand how the application behaves in the environment. Also any unhandled exceptions can be found by this testing. This has to be done for all parts of the code written for each and every MIDlet
Persistent Storage\RMS Testing
This Testing comes part of White box testing. RMS is a storage facility in J2ME applications for storing data. It is somewhat similar to file handling. All information are stored in the form of byte array in the RMS. Data entered here must be stored in Type-Length format in the byte array for each record. An example is given below
Its been a long time since wrote an article since I was busy on the personal front. Today I will be discussing about a topic that is something I am very passionate about and that is none other than J2ME Testing.
What is J2ME ?
J2ME(Java 2 Micro Edition) is a framework from Java that is used for writing programs and applications for mobile devices such as mobile phones, PDAs, smart phones,tablets,set top boxes etc. In J2ME an application specification is given by two terms. They are :-
- MIDP(Midlet Information Device Profile)
- CLDC(Connected Limited Device Configuration)\CDC(Connected Device Configuration)
The CDC is a Library that provides API fro devices such as tablets, set top boxes, Television etc.It also provides networking capabilities to the application and upward compatability with other Java Libraries like J2EE and J2SE.
MIDP is a set of Java API. Both MIDP & CLDC work together to provide complete application runtime environment for mobile phones
As a matter of information I would like to tell you all that J2ME application runs on KVM(Kilo byte Virtual Machine) unlike other Java Applications that run on JVM(Java Virtual Machine) . We use KVM instead of JVM as JVM cannot be deployed on these devices due to resources constratints.
All applications that are developed using J2ME APIs are called MIDlet. The MIDlet runs on Application Management Software(AMS) that is already installed in MIDP devices. One J2ME software can have multiple MIDlets bundled in it.
The MIDlet has a life cycle.It has 3 stages
- Active State: When the currently invoked MIDlet is running
- Paused State: When the currently invoked MIDlet is paused due to interruptions such as phone call, SMS etc
- Destroyed State: When currently invoked MIDLet is exited\destroyed.
 |
| MIDlet Life Cycle |
Ok Dude now I know what is J2ME.What are the testing aspects here ?
Though J2ME seems simple. There are numerous aspects of testing to these applications. They are as follows:-
- Functionality Testing
- State Based Testing
- UI Testing
- Exception handling Testing
- Persistant Storage\RMS Testing
- Generic Connectivity Framework(Such as SMS, GPRS,Bluetooth) Testing
- Device Compatability Testing
- OTA(Over The Air) Deployment Testing
- Performance Testing
I will now be discussing each of these in detail.
Functionality Testing
Like any other testing the aim of the testing is to find out whether the application is doing what it is supposed to do and not doing what it is not supposed to do. This includes input validation, validating application workflows, login validations to view the application etc.This can be tested both on device and an emulator. If any exception is thrown which makes the application to quit must be reported as a bug in this phase
State Based Testing
This Testing is to ensure that MIDlet lifecycle is carried out smothly while the MIDlet is running. In certain cases A MIDlet cannot be exited when doing certain critical opertaions such as fund tranfer from one bank account to another. The AMS should not allow the MIDlet to exit, Such testing can be done in this phase. In such cases the IllegalStateException is thrown and this does not allow the user to exit. Also in cases of any interruptions such as phone call or sms, the application must be observed as how the applications goes to paused state and resumes once when the high priority process is over.
UI Testing
This testing mainly focuses on whether the UI is user friendly or not, The UI navigation of the application and whether proper GUI objects are placed for certain operations. Eg: If an application is doing a Bluetooth Search a Gauge has to be placed on the screen with appropriate message. Instead if a blank screen or the existing GUI is displayed then it is considered as a bug as it gives a notion that the application is hanging. Also any exception thrown from UI must be handled accordingly. If any exception(from UI perspective) is not handled then bugs must be raised for the same.
Exception Handling Testing
This testing maily comes in White box testing particularly in Unit Testing Phase of V & V-V model. For every exception handled in the code the tester must try to create a situation such that the exception is handled by the application and the appliucation does not crash. This enables to understand how the application behaves in the environment. Also any unhandled exceptions can be found by this testing. This has to be done for all parts of the code written for each and every MIDlet
Persistent Storage\RMS Testing
This Testing comes part of White box testing. RMS is a storage facility in J2ME applications for storing data. It is somewhat similar to file handling. All information are stored in the form of byte array in the RMS. Data entered here must be stored in Type-Length format in the byte array for each record. An example is given below
 | ||
| TL Format in RMS |
The testing scope here would predominantly be whether the records are being successfully stored and retrieved from the RMS without any exception thrown. Whether all exceptions are being handled or not. Whether searching for a record is efficient etc. Some exceptions handled here are RecordStoreNotOpen Exception,RecordStoreFullException,RecordStoreException:raised when a genral exception happens in record store,SecurityException.
Generic Connectivity Framework Based Testing
Generic Connectivity Framework(GCF) is Framework of J2ME that uses Network Connectivity such as GPRS, Socket Connection, SMS,Bluetooth,Infra Red etc. It is this framework that gives the potential for mobile devices to compute despite having minimum resources. In this section I will be discussing about SMS,GPRS and Bluetooth based testing below:-
SMS Based Testing
In SMS based applications there are two types of SMS.
1. Text SMS
2. Binary SMS
In Binary SMS the payload data is converted to bytearray format while the message is sent through the channel.However this does not mean that the SMS is secured.
Also SMS can be sent to specific ports in mobile devices and servers. In case of specific ports the SMS will be delivered only to the application and not to SMS inbox of the mobile devices.
So the basic functionality that a tester can test here are
1. Whether the Binary SMS is converted and the SMS is the same as it is at the Sender's side
2. SMS are being sent and received by the client and server
3. For port specific operations a tester needs to check whether the client is able to receive the SMS in the application and not in the SMS INBOX
4. For port specific operations whether the server is receiving the SMS in the specific port
5. Whether the client is able to receive the SMS at the specified port
6.Whether the mbile application is able to send the SMS in the specified port
7. If connection is disconnected during critical operations whether exceptions are handled or not. Whether the operations in server is rolled back or not.
GPRS Based Testing
In GPRS based operations the mobile device connects to a web\application server. The server process the request and then sends the response to the mobile device.
Here testers are required to test the following:-
1. Whether the mobile device is able to connect to the server at the given port smoothly without throwing any exception
2. Whether the mobile device is able to send GET and POST request to the server
3.Whether the Server is able to receive the request
4.Whether the mobile deivce is able to receive the response from the server
5.Whether the mobile device is able to understand the response from the server
Tester should also ensure whether the IOException has been handled or not as a lot of information exchange tends to happen and the control of the system tends to get lost easily. So the application must be robust and reliable at the same time even when control from the user is lost.
Bluetooth Based Testing
In J2ME communication through Bluetooth can be taken place using L2CAP layer and the RFCOMM layer.
Devices should not be able to detect more than 30 devices within its bluetooth range.Information sent through Bluetooth are sent in bytearray format.
The following that are to be tested here are:-
1. Whether the mobile application is able to detect devices in the given region
2. If the device is able to detect devices is it able to detect all devices if number of devices within the given region is less than 30
3.If there are more than 30 devices, is it able to detect exactly 30 devices
4.Whether the mobile application can connect to the device in the specified layer
5.Whether the two mobile device running the same mobile applications are able to send and receive messages
6. If the two mobile devices are able to send and receive messages then both mobile devices should be able to produce the same information as sent by the sender
7. Whether the mobile devices are maintaing connection within the specified bluetooth range
8. If the Bluetooth connection disconnects abruptly during critical operations how the application responds.
9.Whether BluetoothException is handled or not
Device Compatability Testing
Although most mobile phones have the same specification of MIDP and CLDC a device compatability testing has to be done since each mobile phoone's configuration is different. This testing has to be done by deploying the application in each and every mobile phone and checking whether the functionality is working fine, display is proper, GCF such as bluetooth is compatable with other mobile devices or not etc.
Generally when mobile application is developed several versions are created that are targetted for certain mobile phone.eg: we have angry birds for nokia s6 phones, iphonone,blackberry etc.
OTA(Over The Air) Deployment Testing
J2ME applications can be directly downloaded to the mobile phone using GPRS\EDGE\W-LAN\3G connectivity. This is called OTA Deployment. The deployment takes place by typing the link address of the JAR or JAD file of the application that resides in the server on the mobile phone. The application genrally gets donwloaded into the phone memory directly.
What needs to be ensured here is that the JAR file is built correctly with the right MIDP and CLDC configurations. If JAD file is being deployed in the server the specification of the JAD file needs to be verified.
Performance Testing
In mobile applications what is crucial is the space utilized by the mobile applications since the mobile devices has a very low physical memory.Also thread utilization also has to be minimal although it is very difficult to do without using of threads. The emulators provided by the IDE(NetBeans and Eclipse) provides features of checking these parameters while testing the application. These parameters in turn affect the quality of the application
I hope I was able to throw some light on J2ME testing.
Till then Cheers From,
Sai :)
good one!!!
ReplyDelete