Recommended
More Related Content
Similar to Low level android automation with ADB
Similar to Low level android automation with ADB (20)
Recently uploaded
Recently uploaded (20)
Low level android automation with ADB
- 1. Tomer Cohen Low-Level Android Automation with ADB @tomercohen95
- 2. Tomer Cohen - Automating since 2014 - Android automation team leader - Automation architect & consultant - Blog owner - Automatzia.com
- 4. Agenda - My testing journey - Automation for the low-level - Introduction to ADB - Applying automation with ADB
- 5. Low-level automation - It’s all about the abstraction layers - Less abstraction means more reliable automation
- 8. 3 Elements of ADB Client adbdServer
- 10. adb devices - all connected devices adb -s <serial> <command> - send command to a specific device adb push <file> <path_on_device> - push file to device adb pull <file> <path_on_computer> - pull file from device adb install <apk_path> adb uninstall <package_name> adb shell - enter device’s shell $ input <source> <command> - send input event $ screencap -p <path>.png - save screenshot $ dumpsys (-l) - system info $ dumpsys cpuinfo -h - cpu usage $ dumpsys battery - battery info $ dumpsys meminfo - memory info $ logcat (-d) - all device’s logs ADB cheat sheet
- 11. def local_cmd(cmd): return subprocess.getoutput(cmd) def adb_cmd(cmd): return local_cmd(‘adb ‘+ cmd) def adb_shell_cmd(cmd): return adb_cmd(‘shell ‘+ cmd)
- 12. def main(): # install app # open app # check for apps in logs # take screenshot # pull screenshot
- 13. Don’t use a cannon to kill a mosquito
Editor's Notes
- My story what kind of product i tested how i was testing it I started my journey as a manual tester in the android QA team in my organization. The applications in my organization don’t have a graphic user interface. How do we test this kind of apps? Most of what we had to do was just run the applications and see what is going on in the background, how it interacts with other applications on the device and maybe send some intents to run specific tasks from the app. But none of our tests required interaction with the user interface of the android device. When we started testing these apps the development team suggested us to use adb for the installation, for looking at the logs and for any other interaction with the mobile device. For a while, we had been using adb for testing, before we even started with the automated tests. After a few months, the project manager asked me to find an automation tool that will help us write some automated tests to the application. And so, i consulted with one of my colleagues who was experienced with automation, and he said.. There is no question. If you want to apply automation for mobile devices - use Appium. So we tried. I installed Appium and started writing my first script and then I realized appium asks me to insert the package name and activity for opening the application. It looked weird for me, who said I want to open the application, who said I want to start my scenario when the app is installed? Maybe I want to open get the dumps and logs from the device before starting the app, and to see the difference after I started? So, I went to look at the appium documentation. And started reading about the architecture and features it has, and I was amazed. It looked very powerful. But it didn’t seem to fit my specific needs, and also it had much more than I needed. Basically, all i needed was sending few commands to control the android device. Commands that adb supplied to me in an almost perfect way. So I asked myself, why wouldn’t I try writing an automated script with ADB?
- The main goal for this talk - Introduce you to adb, its architecture and usage And share how I did it..
- The name of this talk is “Low-level android automation with ADB”, so I want to clarify first - what do I mean by “low level automation”? When i speak about low- level automation or low-level testing, we usually don’t speak about writing assembly code to test software, and it doesn’t really mean writing code that tests a product that was written in assembly. Usually, the lower the level of the abstraction over the operating system is, the more low-level the software it is. So let’s take a look the this layers model.
- Separating our software to different levels of abstractions is considered a good practice because it means our code will be more decoupled, every layer can work on its own and changes in higher abstraction layers won’t affect the lower level. So, we can almost every software has layers of abstraction and every layer has more layers in it. For example - here, in the applicatio layer we can see that there are different applcations and im sure every application has its business logic layer, databases, and GUI.
- If you test a mobile application, ask your developers - what can be tested in a lower lever? Use only what you need, if you need to perform small tasks don’t use a monster.
- My story what kind of product i tested and how i was testing it
- The applications in my organization don’t have a graphic user interface. How do we test this kind of apps? Most of what we had to do was just run the applications and see what is going up in the background, how it interacts with other applications on the device and maybe send some intents to run specific tasks from the app. But none of our tests required interaction with the user interface of the android device. When we started testing these apps we the development team suggested us to use adb for the installation, for looking at the logs and for any other interaction with the mobile device. For a while, we had been using adb for testing, before we even started with the automated tests. After a few months, project manager asked me to find an automation tool that will help us write some automated tests to the application. And so, i consulted with one of my colleagues who was experienced with automation, and he said.. There is no question. If you want to apply automation for mobile devices - use Appium. So we tried. I installed Appium and started writing my first script and then I realized appium asks me to insert the package name and activity for opening the application. It looked weird for me, who said I want to open the application, who said I want to start my scenario when the app is installed? Maybe I want to open get the dumps and logs from the device before starting the app, and to see the difference after I started? So, I went to look at the appium documentation. And started reading about the architecture and features it has, and I was amazed. It looked very powerful. But it didn’t seem to fit my specific needs, and also it had much more than I needed. Basically, all i needed was sending few commands to control the android device. Commands that adb supplied to me in an almost perfect way. So I asked myself, why wouldn’t I try writing an automated script with ADB?