Home » APK file » Page 2

Tag: APK file

Mobile App Update Testing

During the development process of mobile apps manual and automated testing is highly recommended. But there is another test you should do before releasing or submitting your app to a store. Testing the update procedure! Testing the update procedure from the current store version to the new release candidate is really important and it is often not done by developers or QA experts. With this test you verify, that the new app is not affecting the old installed version. Here are three facts that will be covered with that test.

Test that the update…

  • … will not logout a user from the app e.g. before the update he was logged in.
  • … will not affect the local database e.g. existing data will not be modified or deleted.
  • … will be installed correctly from the store (simulation).

You can also test the update from far older versions to the latest one, to see what is happening.
For the two big players Android and iPhone I will describe, how to test the update from one version to another using different tools.

On the iOS side there are two ways of testing the update procedure. The first one can be done with iTunes. See also the Technical Note TN2285 from Apple.

  1. Build an adhoc app version of the app that is currently live in iTunes store. HINT: This version must have the same bundle identifier as the new app.
  2. Be sure that no older versions of the app are installed within iTunes and on your test iOS device (Sync with iTunes to be sure).
  3. Drag the app from step 1 into iTunes and sync the version to your test device.
  4. Launch the app and do some manual testing to see that the app is working.
  5. Build the new release candidate version of the app and drag it to iTunes and sync to the device. iTunes should confirm, that the older version will be removed. HINT: DO NOT delete the old build! In the next step iTunes will install the new app over the old one and will simulate the update from the app store.
  6. Launch the new version and see if everything is ok.

The second way of testing the update procedure for iOS is using the iPhone Configuration Utility. Using this tool is more comfortable, especially if you want to test the update procedure on more iOS test devices like iPhone 3G, iPhone 3GS, iPhone 4(S), iPhone 5 or iPads.

  1. Build an adhoc app version of the app that is currently live in iTunes store. HINT: This version must have the same bundle identifier as the new app.
  2. Be sure that no older versions of the app are installed on the test device.
  3. Install the app from step 1 to the devices you want to check.
  4. Launch the app and do some manual testing to see that the app is working.
  5. Build the new release candidate version of the app and install it with the tool. The update procedure will be simulated.
  6. Launch the new version and see if everything is ok.

The same can be done also on the Android side. To test the update for Android you can use adb to simulate the procedure.

  1. Install the current Google Play store version of your app to your phone.
  2. Check that the version is working.
  3. Build a release candidate of the Android app. HINT: Be sure to sign the release candidate with the Play store keystore.
  4. Use the following command to test the update procedure:
    ./adb install -r APPNAME.apk. The option -r means reinstall the app and keeping its data.
  5. The new version is now installed and can be tested.

That’s it! Try it for your next release!


Robotium, Jenkins and Ant

I think it is time for a new How to/ Tutorial on my blog. Today, I want to give you an overview of how to setup your Robotium test project to build it with the tool Ant. If the project is configured for Ant, I will explain how to integrate it into the continuous integration server Jenkins. With the combination of the build tool Ant and the CI Server Jenkins, you are able to build up your own mobile test automation environment. Written Robotium tests can be executed on schedule or directly after a developer commits new code to the repository. Read more

Mobile Cloud Testing Services use jailbroken and rooted devices

In my last blog post I wrote about a new Cloud Testing Service for Android and mobile web apps. A few hours after writing this post, I found this very interesting blogpost about mobile cloud testing services and the use of jailbroken and rooted devices. Please read this post and think about it, if you consider to use such services!

Why are mobile cloud test solutions using Jailbroken and Rooted devices?

The main reason that mobile cloud test solutions Jailbreak (and rooting it for Android)  their devices is their need to gain full control over the phone so they can delete data that one customer inserted to the phone while running his tests, before a different customer starts running his tests on the device.

Find the complete post here: http://www.mobileappstesting.com/2012/06/08/mobile-cloud-testing-solutions-use-of-jailbreak-and-rooted-devices-analysis-implications/

AppThwack – Android and Webapp Cloud Testing Service

Another new cloud testing service is available, named AppThwack. AppThwack is currently available for testing Android Apps but will soon provide the possibility to test also mobile web apps on different test devices. See a Sneak Peak in the company blogpost about the web app testing.
If you want to test your Android app on different devices you have 2 options to test your app.

The first one is to upload the production apk file and see what is happening with your app, if it is installed and executed on different devices. This is a very basic test just to see if your app is running and not crashing. The second approach is that you upload also your Robotium test apk file. Then your own test automation is also executed in the testlab on different devices.

After the test execution, AppThwack provide really nice test result statistics including Screenshots, Logs, Stack Traces and Trend in real time.

AppThwack Overall statisticsAppThwack Statistics on ErrorAppThwack Detail Statistics
Right now AppThwack has an open beta process where you can register. To get a overview of the feature set you can start a live demo.

Here is a short list of the provided features:

  • Real Devices
  • No Configuration
  • Custom Tests
  • Deep Analysis
  • Project Support
  • Multiple Users
  • Real Time
  • Private

The cloud testing service AppThwack looks really good and promising. I really like the real time overview in the statistic section. You should sign for the current beta!

Let’s see what the payment is, when they go live with the service, And how the competitors Apkudo and testdroid will react.

Have fun!

Source: http://www.appthwack.com/

YAATT – Yet Another Android Testing Tool

Thanks to my colleague @the_qa_guy I got the information that there is another test automation tool for Android Apps. The tool is called bot-bot and provide a selenium like test automation for native Android Apps using a capture & replay functionality.
The tool is developed by Imaginea and based on the keyword driven approach. bot-bot uses the following open source tools:

To provide a capture & replay mode, bot-bot has three different components:

  1. The Recorder: Is responsible for recording the user action on the Android App under test. The recorded actions are send to the Server.
  2. The Runner: Is responsible for the test execution. Also generates html test results.
  3. The Server: Is responsible for tracking the user actions that come from the Recorder. Besides that it give the qa expert the possibility to export the recorded test cases in csv format. The csv file than can be used with the Runner to execute the testcases again.

bot-bot is currently available in the first version 0.7 and provide the following features (List from http://imaginea.github.com/bot-bot/pages/currently.html):

  • Record user actions of any apk file without the need of the source code.
  • Functional testing on any android app for which the apk file is available.
  • Record user actions on simulator or using an actual phone.
  • Store the recorded actions on the server for future refferences.
  • Edit/modify recorded cases.
  • Allow the recorded cases to be exported in csv format
  • Generation of html reports after test execution.
  • Support for extension of test api, for adding or enhancing any existing cases.

The nice thing is, that the qa expert has the possibility to choose between the testing frameworks that is used by the Runner. He can choose between Robotium or NativeDriver!

To get more information check the tool website on github: https://github.com/Imaginea/bot-bot or http://imaginea.github.com/bot-bot/ .
There you find information about How to Install and about the Components.

See how bot-bot works: 

If I get the time, I will setup an environment with bot-bot to check how good the capture & replay function is!

Let me know, if you already have some experience with the tool.

Have FUN!