软件测试 | 读懂 Appium 日志,让测试效率翻倍!

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介: Appium 服务器运行时会产生很多日志,但是很多人并不了解其中的意义,也无法掌握有用的信息。本文将详细解读如何读懂 Appium 日志,并让你的测试效率翻倍。

image.png

Appium 服务器运行时会产生很多日志,但是很多人并不了解其中的意义,也无法掌握有用的信息。本文将详细解读如何读懂 Appium 日志,并让你的测试效率翻倍。

开启服务

日志第一行显示了 Appium 版本和运行地址。

$ appium
[Appium] Welcome to Appium v1.8.0-beta3 (REV 40e40975ebd3593d08c3f83de2546258f7ddf11d)
[Appium] Appium REST http interface listener started on 0.0.0.0:4723

如果你在 Appium 上添加了参数,他们会在日志中展示,如果添加了 defaultCapabilities,日志也会显示出来。

$ 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

对于自动化测试来说,这个信息很重要,因为不同的 Appium 版本有不同的功能和问题,必须要知道自己的 Appium 版本。

创建 Session

为了自动化测试跑起来,session 要做很多事,日志提供了一些基本的 session 信息,特别是 desired capabilities 和 default capabilities。应该时刻注意 Appium 服务是否正确接收了请求内容,日志列出了创建 automation session。

[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 指令

Appium 是一个 REST 服务,接收 HTTP 请求,展示请求内容,返回某种结果。Appium 服务端日志用线和箭头展示了请求和返回的内容。在两个箭头之间是 Appium 服务端执行请求命令的日志信息:

[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

错误排查

利用日志可以非常方便的排查错误,错误通常发生在 automation session 之后。但有时,如果 session 持续存在,错误也可能发生。所以第一步是找出错误在哪。

下面的例子可以看出,每个指令用 [HTTP] --> 和 [HTTP] <-- 标记。这些标记之间是指令细节,包含了错误输出:

[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

用户试图用 Android driver 启动一个 session,但发生了错误。Appium 为准备 session 而关掉并清除 AUT 时发现了错误,这个错误让我们知道两件事:

  1. Appium 正在尝试做什么
  2. 哪里出错了

在这个例子中,Appium 尝试运行 adb 命令(adb shell am force-stop),adb 参数在错误信息中也有显示。发生了 Android 系统权限错误。此时,我们可以手动运行这个 adb 命令,看看错误是不是可以重现。如果错误重现,上网查错吧!如果 adb 命令成功运行,可能是 Appium 的 bug,应该去 Github 的 issue 上查看或者提交这个 bug 。(例子中的错误是设备制造商的安全模型造成的)

这个例子只是众多错误中的一个,但它说明至关重要的一点,当错误发生时,日志可以提供更多的信息,如果没有完整的日志信息,对 Appium 排错难上加难。

可以改变日志输出的参数

通常,默认的日志内容已经足够,如果你想去 Github 上寻求帮助,信息当然越多越好!下面一些参数可以改变 Appium 服务端的日志行为:

  • -log-level - 改变Appium日志显示级别。

Appium 默认展示所有日志,它有以下一些选项:'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 - 如果你的控制台没有颜色(日志可能会产生一些奇怪的字符,比如"TODO: find the color"),你可以用这个参数关闭颜色。
  • -log-timestamp - 在日志前添加时间戳,在排查超时错误时有奇效,展示如下:
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
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
8天前
|
测试技术 UED Python
探索软件测试的边界:自动化与手动测试的协同
【8月更文挑战第59天】在追求效率和质量的软件生产中,自动化测试与手动测试的辩论从未停止。本文将通过实际案例,揭示二者如何相辅相成,共同构建更健壮的软件测试体系。我们将深入探讨自动化测试的优势、手动测试不可替代的角色以及它们如何在实际项目中协同工作,旨在为读者提供一种平衡的视角来看待软件测试的实践。
101 65
|
2天前
|
机器学习/深度学习 人工智能 自然语言处理
软件测试中的人工智能革命:提升测试效率与质量的新篇章
随着人工智能技术的不断成熟,其在软件测试领域的应用正逐渐改变传统测试方式。本文将探讨AI在软件测试中的应用现状、优势以及面临的挑战,并通过具体案例分析展示AI如何提高测试效率和质量。最后,我们将讨论未来AI在软件测试中的发展趋势及其对人类测试工程师角色的影响。
|
3天前
|
设计模式 敏捷开发 jenkins
软件测试中的自动化测试实践指南
本文旨在探讨软件测试中自动化测试的实施方法及其重要性,通过具体案例分析自动化测试的步骤、工具选择及最佳实践。我们将从自动化测试的基本概念入手,逐步解析其在实际项目中的应用,并提供一些常见问题的解决方案。
|
7天前
|
机器学习/深度学习 人工智能 安全
软件测试中的探索性测试:一种高效发现软件缺陷的方法
本文将深入探讨软件测试中的一种关键方法——探索性测试。探索性测试是一种动态的、探索性的软件测试方法,它依赖于测试人员的直觉和经验,通过实际操作软件来发现潜在的问题和缺陷。与传统的基于预定义用例的测试方法相比,探索性测试更加灵活,能够更全面地覆盖软件的各个方面,从而更有效地发现难以预见的错误和漏洞。
|
8天前
|
监控 中间件 测试技术
『软件测试5』测开岗只要求会黑白盒测试?NO!还要学会性能测试!
该文章指出软件测试工程师不仅需要掌握黑盒和白盒测试,还应该了解性能测试的重要性及其实现方法,包括负载测试、压力测试等多种性能测试类型及其在保证软件质量中的作用。
『软件测试5』测开岗只要求会黑白盒测试?NO!还要学会性能测试!
|
8天前
|
测试技术 程序员 C语言
『软件测试4』耗子尾汁!2021年了,你还不知道这4种白盒测试方法吗?
该文章深入介绍了四种常用的白盒测试方法,包括语句覆盖、判定覆盖、条件覆盖以及路径覆盖,并探讨了这些方法在软件测试中的应用。
『软件测试4』耗子尾汁!2021年了,你还不知道这4种白盒测试方法吗?
|
8天前
|
机器学习/深度学习 Web App开发 测试技术
『软件测试3』八大典型的黑盒测试方法已来袭,快快接住!
该文章介绍了八种常用的黑盒测试方法,包括等价类划分、边界值分析、错误推测法、因果图法、决策表测试、状态转换法、场景法以及随机测试,并提供了相应的案例说明。
|
8天前
|
测试技术 数据库
『软件测试2』 关于黑盒测试和测试用例的基础知识
该文章讲解了黑盒测试的基本概念以及如何编写有效的测试用例,包括选择合适的输入数据、预期结果的设定和测试执行的步骤。
|
8天前
|
监控 安全 测试技术
『软件测试1』你需要了解的软件测试基础知识
该文章介绍了软件测试的基础知识,涵盖了软件缺陷的定义、类型、处理流程以及软件测试的目标和重要性等内容。
|
8天前
|
测试技术 UED 开发者
软件测试的艺术:从代码审查到用户反馈的全景探索在软件开发的宇宙中,测试是那颗确保星系正常运转的暗物质。它或许不总是站在聚光灯下,但无疑是支撑整个系统稳定性与可靠性的基石。《软件测试的艺术:从代码审查到用户反馈的全景探索》一文,旨在揭开软件测试这一神秘面纱,通过深入浅出的方式,引领读者穿梭于测试的各个环节,从细微处着眼,至宏观视角俯瞰,全方位解析如何打造无懈可击的软件产品。
本文以“软件测试的艺术”为核心,创新性地将技术深度与通俗易懂的语言风格相结合,绘制了一幅从代码审查到用户反馈全过程的测试蓝图。不同于常规摘要的枯燥概述,这里更像是一段旅程的预告片,承诺带领读者经历一场从微观世界到宏观视野的探索之旅,揭示每一个测试环节背后的哲学与实践智慧,让即便是非专业人士也能领略到软件测试的魅力所在,并从中获取实用的启示。
下一篇
无影云桌面