It might seem too good to be true, but yes, you can use a single script to test across platforms. We even give you the script!
Can You Use a Single Script to Test On All Platforms? The Answer Is Yes.
It can seem like a challenge to your budget, as well as your patience, to test mobile apps and get them working effectively and consistently across popular mobile device platforms including Apple® and Android™.
Before mobile apps can be deployed, enterprise developers typically go through three rounds of development and testers do an inordinate amount of testing. The process can become time-consuming and costly, especially when you consider the number of mobile apps large companies are deploying today.
Regardless of the testing strategy you use, developing apps that can crossover from Web to mobile, desktop to Web, or iOS to Android, often causes one common question to emerge: how do you automate application testing across all three environments with a single script or framework?
Our answer is the common data model.
Native App Testing and the Common Data Model
Just as Android devices look different from Apple mobile devices, the objects within apps that run on each platform are different.
For example, an application may have a list of results displayed for the user to select from; in Android it is coded as “android.widget.ListView,” and for iOS, it is coded as “UITableView.”
In addition, the properties for an Android list are different than those for iOS. So, if you’re testing the app on both iOS and Android devices, how do you avoid writing two platform-specific scripts?
This is where the common data model can be applied to mobile application testing.
The common data elements of apps – such as the button in our example above – might be implemented differently between iOS and Android platforms from a technical perspective, but the functional intent of each object is identical.
This allows both “android.widget.ListView” and “UITableView” to be turned into a single test object known as a “MobiList” that can be utilized regardless of platform.
The data model then handles the technical interaction with the specific device OS “under the hood,” providing a uniform and streamlined automation experience.
How do Platform Differences Affect App Testing?
To the end user, applications may act very similar across multiple platforms, however when it comes to development and testing, the small differences can create quite a challenge.
From the testing perspective, using a tool that leverages the common data model to map equivalent UI elements from different mobile platforms is instrumental. This approach can help testers write a script for an iOS app, for example, and then, with no changes to the script or objects, run the script again to test an app on an Android device.
The Single Script You Can Use
Building the common script requires a little understanding of how attributes are used to identify objects at runtime and a familiarity with the Mobile Labs’ common object model. Once we understand these two concepts, it will be possible to write the script using an iOS device and then we can disconnect from the iOS device, connect to an Android device, and run the script again with no changes to the script or the objects.
We start with the Mobile Labs common object model, which is simply the set of objects that can be identified in a mobile app using HPE Unified Functional Testing (UFT) integration tools like Object Spy. Our Mobile Labs Trust™ for UFT plug-in tracks the same attributes and the same methods on both platforms. An easy way to visualize this is to look at the “MobiDateTimePicker” object that maps into the three-wheel iOS and Android controls that allow a user to select a date by dialing up a day, a month, and a year. The illustration below shows the object as it appears on both platforms:
The illustration shows the appearance of a MobiDateTimePicker in both Android and in iOS. Even though the objects appear dissimilar, their base function is so alike that we can support them identically. At the top of the image is a screen capture from a UFT session in which we exposed the object methods of MobiDateTimePicker. The methods are the same regardless of the target platform. The fact that the methods are tailored to the UI element and not some other abstraction like the screen or the physical appearance of the objects gives the script writer tremendous power to capitalize on this UI element in either platform.
To write the single script, I used the Mobile Labs mobile device lab manager, deviceConnect™, to select a remote iOS device and then later a remote Android device for testing. As the partial inventory of my deviceConnect installation shows, I had an iPhone 6 and a Samsung Galaxy S4 available for this test. deviceConnect allowed me to switch between these two devices at will even though neither was right at my desktop.
For this example, I decided to write the script while connected to the iPhone 6. Once the script ran to my satisfaction, I disconnected Ai Display from the iPhone 6, connected to the Samsung Galaxy S4, and pressed the UF “run” button again.
The next task in my project was to define the objects to the UFT repository. To do this, I used the “Object Spy” tool that obtains, through our HPE-certified plug in, the object inventory of the application.
In the illustration below, I used “Object Spy” to add the Username and Password MobiEdit boxes and the “Sign In” MobiButton to the UF object repository:
The application on the right is Trust deviceViewer, which showed me the contents of the screen on the iPhone 6. The Trust Agent supplied our certified plug-in with the relevant properties of, in this case, the Username MobiEdit box. Adding it to the repository was as simple as clicking the “add” button at the top of the UF Object Spy application, which is the window to the left. Once I completed this process for Username, Password, Sign In, and the ‘Search’ button from the first app page, I had a complete object repository for my test case:
It is worth noting that I adjusted the UFT identification properties slightly for each object so that UF and our certified plug-in could correctly identify them at run time on both platforms. For the MobiButton, I used its text value, “Sign In”:
For each of the MobiEdit fields, I used the index property that identifies each according to the order in which it is defined. For username, I used index 0; for password, I used index 1. I removed any physical attributes like color, font, id, etc:
With these adjustments to the identification properties, I was ready to write the script. To time the script and the login, I used UFT Services.StartTransaction and Services.EndTransaction statements. In the remainder of the discussion, I will show certain sections in isolation. With a liberal allowance for comments, the script ran to 56 lines.
'# Start an overall transaction timer Services.StartTransaction "Script" '# Ensure that the app is in the proper state to login If MobiDevice("PhoneLookup").MobiEdit("Username").Exist(3) = False Then Reporter.ReportEvent micFail, "Login", "Failed to Login." ExitTest End If '# Log in to app and record transaction time<p>Services.StartTransaction "Login" MobiDevice("PhoneLookup").MobiEdit("Username").Set "mobilelabs" MobiDevice("PhoneLookup").MobiEdit("Password").Set "demo" MobiDevice("PhoneLookup").MobiButton("SignIn").Click</p>'# Assess success or failure of the login attempt If MobiDevice("PhoneLookup").MobiButton("Search").Exist(3) Then Services.EndTransaction "Login", Pass Else Services.EndTransaction "Login", Fail Reporter.ReportEvent micFail, "Login", "Failed to Login." ExitTest End If
This part of the script is extremely simple. Making the script object references was a matter of dragging the object from the “Available Keywords” pane into the script pane, where I could adjust the methods or parameters, for example, supplying the userid and password to the appropriate objects. Once the data is entered into the MobiEdit objects, the script clicks the “Sign In” MobiButton and then tests to make sure that the login was successful by checking for the existence of the Search button on the first app screen. When the login succeeds, the script closes the transaction, which gives us a measurement of the elapsed time that the device took to complete the request.
Once logged in, the script presses the search button on the first screen to perform the default search for the platform. Once the search is complete, the script is done, and closes the overall transaction to get a comparison of how the platforms performed on the entire task:
'# Schedule the default search for the platform, measuring the transaction time MobiDevice("PhoneLookup").MobiButton("Search").Click '# End the main transaction, recording results and transaction time Services.EndTransaction "Script", Pass 'Capture Transaction Times
The remaining item of business was to run the test on both devices. I ran first on iOS and then disconnected, selected a Samsung Galaxy S4 from deviceConnect, and then pressed ‘run’ again. Examining the results showed that the SamsungGalaxy S4 was two seconds slower than the iPhone 6 in completing the entire script:
Looking at the login transaction times, the iPhone 6 was less than second faster than the Samsung Galaxy S4:
iOS login time
Android login time
To give a feeling for how the script looked as it ran on the two devices, I turned to the UF results summary that includes screen captures for each step in the test. At top we see the screen when the password was entered on the Android device; on the bottom we see the screen when the password was entered on the iOS device.
Although the two pages are different if taken in a visual context (fonts, colors, positions, sizes), the logical content of the screens is identical, and that allowed me to leverage the Mobile Labs’ common object model to write one script that ran, unchanged, on both devices. I made use of two of the common objects, MobiEdit and MobiButton, and chose identification properties that allowed a single object repository and a single script to run a test against the app without necessitating any changes to the objects, their properties, or the script itself.
So, the example shows the power and potential of the common object model, use of Mobi objects, and selective use of object identification properties. The result is to make single-script execution possible on multiple platforms. Mobile Labs will be expanding the model over time and will extend it to other platforms, in addition to iOS and Android, as they become supported.
Android Password entry
iOS password entry
Have questions about deviceConnect? Learn more about this
private device cloud, available as both an on-premises and as a hosted solution
by viewing our video demo.