Setting Appium Doctor , Java Home and Android home for Running appium

Setting Appium Doctor , Java Home and Android home for Running appium 


One of the biggest challenge that comes in Automating Mobile using Appium is its installation.
In this post I will try to layout step by step process to have minimal heckle to install and run Appium

We need two Basic thing to install and Run Appium.

Appium Doctor : to see Environment configurations are good for Appium.As pet their git page

Appium Doctor "Attempts to diagnose and fix common Node, iOS and Android configuration issues before starting Appium."

Installing Appium Doctor using below command

• npm install appium-doctor -g

Then run below command to see respective OS configuration:

• appium-doctor --android 

• appium-doctor --iOS

 

Currently Since my system has all the right configuration everything is coming green.If you also have green tick it means configuration is good.

Setting Android Home Path and Java Home Path

- open .

~/.bash_profile

add below lines.

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-13.0.1.jdk/Contents/Home
export PATH=$JAVA_HOME/bin:$PATH
export ANDROID_SDK_HOME=/Users/saif.siddiqui/Library/Android/sdk
export ANDROID_HOME=/Users/saif.siddiqui/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools
export ANDROID_HOME="/opt/intallation-location/android-sdk"

Keep in mind to change my system name with yours wherever applicable.

See below highlighted image for clarity

After making the changes , Run source ~/.bash_profile in CMD prompt.

Similarly Open - 

~/.profile

add below lines:

export ANDROID_HOME=/Users/saif.siddiqui/Library/Android/sdk;export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-13.0.1.jdk/Contents/Homeexport PATH=${JAVA_HOME}/bin:$PATH

Keep in mind to change my system name with yours wherever applicable.

See below highlighted image for clarity

After making the changes , Run source ~/.profile in CMD prompt.

Now Run :    appium-doctor --android 

If the configuration is good you will get all the green ticks.

Migration Testing Scenario for Android and iOS

Migration Testing Scenario for Android and iOS

Migration testing is one of the important testings particularly for mobile applications where a single mistake can take 3 days to 7 days to fix, deploy, and roll the app again on production. If you have a large user base and real-time application like Flight booking or Hotel Booking we need to be cautious while doing the migration testing.

Why we do Migration testing?

Migration is being done on the new OS, tech stack, or DataBase.
Particularly I will be discussing the migration of mobile apps which may include all or none of the above situations.

Use Case of migration:

1. To give users better performance, you don't want your million flight booking or hotel booking consumer to navigate to your competitor's site.
2. Moving to the new tech stack from the obsolete one. Why would you like to drag the legacy technology when new technology can bring you peace of mind and ROI.
3. Cost reduction of the maintenance of the application.Which may include the second point.

When the migration testing is done :

1. Do you remember the blackberry devices, they use to have their own OS. Slowly they were not able to compete with the Android OS so before they finally moved to the Android OS they were allowing the android developers to port their Android Apk on blackberry os with the help of the wrapper library they wrote. Since the .apk file was wrapped for Blackberry and it was migrated on BB OS we need to do migration testing for the new OS.
2. Currently, the Native apps are being replaced by React Native apps. This involves changes of tech stack apart from maintaining the DB of the user in the react native app which can affect different areas depending on the functionality of the app, the common one being login functionality.
3. Migration testing of the new app over old app having new features and bug fixes, example the previous functionality allowed your user to login with Email. Now they have SSO like Google login and Facebook login. We need to verify that after these new features are implemented they are working fine on the new app once they are installed over the old app.

Test Cases:

1. Install the new application and verify the migration.
2. Install the old app over the new app and verify the migration.
3. Install the new app and then the old app over it (Reverse migration for risk management).
4. Login in the old app and install the new app.If authentication token are grasped automatically all user data should be preserved else if the user is log in again on the new app they after login user should see all the data.
5. UI testing of the migrated app. Remember how Blackberry once allowed to port the Android app on their BB OS when they were not using android apps.I found many issues in my Indigo app at that time.
6. Install the new app over the old app and play with it in flight mode i.e. internet is not connected with the app.
7. Sometimes apple stores information like login in the key chain in the mobile. Now when the user login into the new app with his credential the key chain also passes some information which can lead to a crash. A perfect example is two authentications generated for the app in the same device for the same app.
8. Verify the migration of old app over the new app for different OS versions and devices available

Mobile Application Penetration Testing with MobSF

Subscribe to my youtube channel for more videos here:

What is MobSF?

As per their Github link :

Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static, dynamic, and malware analysis. It can be used for effective and fast security analysis of Android, iOS, and Windows mobile applications and support both binaries (APK, IPA & APPX ) and zipped source code. MobSF can do dynamic application testing at runtime for Android apps and has Web API fuzzing capabilities powered by CapFuzz, a Web API specific security scanner. MobSF is designed to make your CI/CD or DevSecOps pipeline integration seamless.

How to Configure MobSF

If you have a docker installed, up and running just use below command :


docker pull opensecurity/mobile-security-framework-mobsf 

docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest 

Running and doing static analysis of MobSF

- On running the above command MobSF will open in a browser on http://0.0.0.0:8000/ localhost.

- Drag and drop the APK/ipa file 

- MobSF will start doing the Static Analysis

Analyzing Report

Once the analysis of the file is complete you will get the result along with the potential issue that can be there in the app.

Dig out about them in detail and seek developers' help about how we can avoid these vulnerabilities.

Conclusion

Quite a user friendly and easy to use interface will surely be going to make you go-go.

It can be easily integrated with most of the CI/CD available in the market.

You can also download the PDF and share it with the concerned stakeholder. 

Running SonarQube locally with Docker: End to End

Running SonarQube with Docker in local Environment

docker pull sonarqube

$ docker run -d --name sonarqube -p 9000:9000 sonarqube

Once the installation is complete open sonarqube in Browser

http://localhost:9000

To see if the docker container is running in cmd  type 

docker container ls

ece799069a5f        sonarqube                                             "./bin/run.sh"           2 hours ago         Up 2 hours          0.0.0.0:9000->9000/tcp   reverent_goldwasser

By default you can login as admin with password admin, see authentication documentation. 

In the dashboard:

Create New Project

Enter Project Key>SetUp

Generate the token and Copy it

Select the Project Main Language,I have selected JavaScript

Download and unzip the Scanner for macOS

Configure the environment path for SonarQube in .bash profile by giving the path of the bin directory of SonarQube.It will be something like this:

Users/saif.siddiqui/Downloads/sonar-scanner-3/bin

To analyze a javascript project navigate to the project directory and run 

sonar-scanner \

  -Dsonar.projectKey=ProjectName

  -Dsonar.sources=. \

  -Dsonar.host.url=http://localhost:9000 \

  -Dsonar.login=Token\

 -Dsonar.exlusion=.node_module

OR

Running through configuration file 

Create sonar-project.properties file in the project directory to be scanned using command:

touch sonar-project.properties

Add this configuration to run js,jsx file:

sonar.projectKey= ProjectName \

sonar.sourceEncoding=UTF-8

sonar.javascript.file.suffixes=.js,.jsx

sonar.sources=detox/e2e

sonar.host.url=http://localhost:9000

sonar.login=generatedtoken

sonar.exclusions=.node_module

In the above code,sonar.javascript.file.suffixes=.js,.jsx will run only js,.jsx file other files will be ignored.

-sonar.sources will run the files in detox/e2e

-sonar.exclusions will exclude the node_module folder

Go to the project directory and run Sonar-Scanner 

Navigate to the Sonarqube Dashboard and Refresh,you will see the result something like this:

Emulator/Simulator or Real Devices,The Real Spartan ?

Emulator or Real Devices, which is better?

Why we should abstain ourself from using simulators/Emulators for Automation testing or Manual Testing altogether like:

- Testing on real devices is the best solution for uncovering bugs (regression included) and getting accurate results.

- Sometime things may seem to work on the simulator but may fail to work on Real Device,this can easily be deduced from the ongoing Native/RN task which quite often fails to work on OEM's.

-  Testing is being conducted in an environment that is not real and we are utilizing System hardware which cannot be compared to the Mobile Hardware.

- Simulators are not reliable since hardware features like GPS, camera, etc (though we only use  GPS) are either simulated or hardcoded in them and they are slow for automation purposes.

This Blog beautifully explains why we should `not use the simulator as the only source of the test environment`
https://mobilelabsinc.com/blog/simulators-vs-emulators