Appium server will generate many logs when running, but many people don't understand the meaning and can't grasp useful information. This article will explain in detail how to read appium
Log and double your testing efficiency.
**Open service**
The first line of the log shows the Appium version and running address.
$ appium [Appium] Welcome to Appium v1.8.0-beta3 (REV 40e40975ebd3593d08c3f83de2546258f7ddf11d) [Appium] Appium REST http interface listener started on 0.0.0.0:4723
If you add parameters to Appium, they will be displayed in the log. If you add defaultCapabilities, the log will also be displayed.
Appium parameter:
http://appium.io/docs/en/writing-running-appium/server-args/
See the following for defaultCapabilities:
http://appium.io/docs/en/writing-running-appium/default-capabilities-arg/
$ appium --address 172.19.131.113 --port 8000 --default-capabilities '{"showIOSLog": true}'
[Appium] Welcome to Appium v1.8.0-beta3 (REV 40e40975ebd3593d08c3f83de2546258f7ddf11d)
[Appium] Non-default server args:
[Appium] address: 172.19.131.113
[Appium] port: 8000
[Appium] defaultCapabilities: {
[Appium] showIOSLog: true
[Appium] }
[Appium] Default capabilities, which will be added to each request unless overridden by desired capabilities:
[Appium] showIOSLog: true
[Appium] Appium REST http interface listener started on 172.19.131.113:8000
This information is very important for automated testing, because different Appium versions have different functions and problems. You must know your Appium version.
**Create Session**
In order to run the automated test, the session needs to do a lot of things. The log provides some basic session information, especially the desired capabilities and
default capabilities. You should always pay attention to whether the Appium service correctly receives the request content. The log lists the creation of automation session
automation session (see the link below).
desired capabilities:
http://appium.io/docs/en/writing-running-appium/caps/
[Appium] Creating new XCUITestDriver (v2.68.0) session
[Appium] Capabilities:
[Appium] app: /Users/isaac/apps/UICatalog-iphonesimulator.app
[Appium] platformName: iOS
[Appium] platformVersion: 11.3
[Appium] deviceName: iPhone 6
[Appium] automationName: XCUITest
[Appium] noReset: true
[Appium] maxTypingFrequency: 30
[Appium] clearSystemFiles: true
[Appium] showXcodeLog: false
[debug] [BaseDriver]
[debug] [BaseDriver] Creating session with MJSONWP desired capabilities: {"app":"/Users/isaac/code/a...
**Appium instruction**
Appium is a REST service that receives HTTP requests, displays the request contents, and returns some results. Appium
The server log shows the contents of the request and return with lines and arrows. Between the two arrows is the log information of Appium server executing the request command:
What is a REST Service:
https://en.wikipedia.org/wiki/Representational_state_transfer
[HTTP] --> GET /wd/hub/status {}
[debug] [MJSONWP] Calling AppiumDriver.getStatus() with args: []
[debug] [MJSONWP] Responding to client with driver.getStatus() result: {"build":{"version":"1.8.0-beta3","revision":"30e7b45bdc5668124af33c41492aa5195fcdf64d"}}
[HTTP] <-- GET /wd/hub/status 200 121 ms - 126
**Troubleshooting**
Using logs can be very convenient for troubleshooting errors, which usually occur after the automation session. But sometimes, if session
If it persists, errors can also occur. So the first step is to find out where the mistake is.
As can be seen from the following example, each instruction is marked with [HTTP] -- > and [HTTP] < -- tags. Between these tags are instruction details, including error output:
[HTTP] --> POST /wd/hub/session <SNIP> [debug] [AndroidDriver] Shutting down Android driver [debug] [AndroidDriver] Called deleteSession but bootstrap wasn't active [debug] [Logcat] Stopping logcat capture [debug] [ADB] Getting connected devices... [debug] [ADB] 1 device(s) connected [debug] [ADB] Running '/home/user/Android/Sdk/platform-tools//adb' with args: ["-P",5037,"-s","ec8c4df","shell","am","force-stop","io.appium.unlock"] [debug] [AndroidDriver] Not cleaning generated files. Add `clearSystemFiles` capability if wanted. [MJSONWP] Encountered internal error running command: Error: Cannot stop and clear com.company.app. Original error: Error executing adbExec. Original error: 'Command '/home/user/Android/Sdk/platform-tools//adb -P 5037 -s ec8c4df shell pm clear com.company.app' exited with code 1'; Stderr: 'Error: java.lang.SecurityException: PID 22126 does not have permission android.permission.CLEAR_APP_USER_DATA to clear data of package com.company.app'; Code: '1' at Object.wrappedLogger.errorAndThrow (../../lib/logging.js:63:13) at ADB.callee$0$0$ (../../../lib/tools/adb-commands.js:334:9) at tryCatch (/home/linuxbrew/.linuxbrew/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.js:67:40) at GeneratorFunctionPrototype.invoke [as _invoke] (/home/linuxbrew/.linuxbrew/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.js:315:22) at GeneratorFunctionPrototype.prototype.(anonymous function) [as throw] (/home/linuxbrew/.linuxbrew/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.js:100:21) at GeneratorFunctionPrototype.invoke (/home/linuxbrew/.linuxbrew/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.js:136:37) at <anonymous> at process._tickCallback (internal/process/next_tick.js:188:7) [HTTP] <-- POST /wd/hub/session 500 40811 ms - 557
The user tried to start a session with Android driver, but an error occurred. Appium turns off and clears AUT in preparation for session
We found an error in the process of, which let us know two things:
-
What is Appium trying to do
-
What went wrong
In this example, Appium tries to run the adb command (adb shell am force stop), and the adb parameter is also displayed in the error message. It happened
Android system permission error. At this point, we can manually run the adb command to see if the error can be repeated. If the error reappears, check the error online! If the adb command runs successfully, it may be
Appium's bug should be checked or submitted on Github's issue. (the error in the example is caused by the safety model of the equipment manufacturer)
This example is just one of many errors, but it illustrates the crucial point. When an error occurs, the log can provide more information. Without complete log information, it is even more difficult to troubleshoot Appium.
**You can change the parameters of log output**
Usually, the default log content is enough. If you want to go to Github for help, of course, the more information, the better! The following parameters can change the logging behavior of Appium server:
- --Log level - change the Appium log display level.
Appium displays all logs by default. It has the following options: 'info', 'info:debug', 'info:info', 'info:warn',
'info:error', 'warn', 'warn:debug', 'warn:info', 'warn:warn', 'warn:error',
'error', 'error:debug', 'error:info', 'error:warn', 'error:error', 'debug',
'debug:debug', 'debug:info', 'debug:warn', 'debug:error'.
-
--Log no colors - if your console has no color (the log may produce some strange characters, such as "TODO: find the color"), you can turn off the color with this parameter.
-
--Log timestamp - add a timestamp in front of the log, which is effective in troubleshooting timeout errors, as shown below:
2018-03-15 13:17:58:663 - [Appium] Welcome to Appium v1.8.0-beta3 (REV 30e7b45bdc5668124af33c41492aa5195fcdf64d)
2018-03-15 13:17:58:664 - [Appium] Non-default server args:
2018-03-15 13:17:58:665 - [Appium] logTimestamp: true
2018-03-15 13:17:58:732 - [Appium] Appium REST http interface listener started on 0.0.0.0:4723
** _
Come to Hogwarts test and development society to learn more advanced technologies of software testing and test development. The knowledge points include web automated testing, app automated testing, interface automated testing, test framework, performance testing, security testing, continuous integration / continuous delivery / DevOps, test left, test right, precision testing, test platform development, test management, etc, The course technology covers bash, pytest, junit, selenium, appium, postman, requests, httprunner, jmeter, jenkins, docker, k8s, elk, sonarqube, Jacobo, JVM sandbox and other related technologies, so as to comprehensively improve the technical strength of test and development engineers