让测试更快更稳更可靠
使用Appium时，会遇到又慢又不稳定的情况。Appium使用的底层工具可能会限速，在功能测试中，许多环境问题也会导致自动化测试不稳定。其实有一些方法可以避开这些问题。本篇文章是系列中的一篇，后面也会有相应文章讨论稳定性和速度。
** 创建Session片状**
片状其实就是不可能靠的意思--
如果在本地测试成功，在未来它可能运行失败，这是不是不可靠？这个问题很复杂，Appium确实会出现不稳定问题，但你需要找出问题所在！
-
你是否了解app或者设备的速度，app稳定性，屏幕大小，或者动态内容？是否毫无根据的假设这些值
-
app本身就不稳定（也许是app自身存在的问题或者人为，人工操作是否也会出现这个问题）
-
设备内存和处理器计算不足
-
网络问题（用http发送到后端可能失败）
-
设备问题（设备会出现各种奇怪的问题）
如果你说，上面这些情况都没问题，问题肯定就出在Appium上！其实，Appium只是众多技术的一环，下面这个图说明了iOS测试的底层技术栈：
你看到没，Appium并不是一个庞大的怪兽，相反，它使用了许多底层工具，问题可能出在这些底层工具上（比如XCUITest 和 UiAutomator2
）。我不是为了逃避责任，而是想说，希望你能调查清楚问题所在！某种问题并不孤立，而是在整个构建中随机出现。当您检查日志时，您会发现这种片状现象总是在一天的某个时间发生。这是非常重要信息，这可能有一个计时代码正在执行!询问其他团队，他们可能知道问题所在。
后面的文章会详细讨论这些问题，现在我给出一些在CI上的建议：
-
将测试添加到构建前，检测是否有片状问题。多次运行它(可能100次?)以确保可靠，如果100%通过，很好，merger这个commit到master分支吧。
-
如果测试有一些没有通过，说明存在不可靠或者片状问题。花点时间调查原因，也许仅仅因为定位或者等待问题。Appium日志和一步一步的截图很重要。
-
当发现问题时，如果能解决，就解决它。如果解决不了，可以向Appium或者Apple提供错误报告，你还可以丢弃这个测试或者注释掉（如果有时间，也可以手动测试）。
-
如果您在构建中了保留测试并允许构建在失败时重试测试，您必须跟踪重试次数的统计数据，并设置一些可靠性阈值，超过该阈值再进行调查研究。如果测试随着时间的推移，片状问题越来越多，你的应用程序可能有问题。
Appium测试是功能测试，不是单元测试。单元测试与其他任何东西都是隔离的，而功能测试则生活在真实的世界中，要混乱得多。功能测试不可能覆盖所有代码问题，应该只考虑关键的用户操作，并通过少量测试捕获bug，从bug中提取有价值的信息。与此同时，要确保那些少量的测可能可靠。通过强化一些测试，您将了解关于应用程序和整个环境的很多信息。这样你就能从一开始就把学到的东西投入到新的测试中去，而不是在以后的道路上一遍又一遍的解决同样的问题。
想了解更多关于健壮性测试?期待第2部分的文章吧，在那里我们将讨论如何快速、可靠地查找应用程序中的元素!
** 创建Session**
Appium（或者Selenium）在app UI对象操作前，需要找到它，有许多不同的查找策略，比如下面这样：
这里使用className这个定位方式找"Button"，这个方法会返回一个WebElement。注意：“class
Name”不跨平台。比如XCUIElementTypeButton 或者 android.widget.Button是iOS和Android的button
UI。
与此同时，也可能找出多个button按钮，这个定位方式并不唯一
，下面是Appium支持的定位策略：
有一些定位是Appium独有的，比如accessibility id。
Xpath
在另一篇文章，我们说拒绝使用Xpath，链接如下。总结一下，有的人喜欢用Xpath，是因为它可以找到UI中的任何元素，但是Xpath很脆弱，当app的结构变化时，Xpath就不起作用了！Appium需要Xpath是因为，有一些元素是多层结构，只有Xpath才可以定位到。
Accessibility ID
我建议用Accessibility
ID替代Xpath，它跨平台，独一无二，快速！iOS和Android都有可访问标签，iOS上被称作“accessibility
ID”，安卓上被称作“content description”（或者content-
desc）。可访问标签是独一无二的（一般开发人员都会这么做），比如下面的Java代码：
WebElement el = driver.findElement(MobileBy.AccessibilityID("foo"));
有时，没能可访问标签，或者说可访问标签并不是独一无二的，该怎么办？
iOS上的定位策略
在另一篇文章我讨论过此事，这个定位方式可以替代Xpath，因为它是基于层级定位。最好用的定位策略是“-ios class
chain”，就像一个精简版的Xpath。
不用Xpath：https://appiumpro.com/editions/8
你可以使用各种查询语句，而且它的速度快于Xpath，唯一缺点就是只能用在iOS上，下面是一个例子：
String selector = "**/XCUIElementTypeCell[`name BEGINSWITH "C"`]/XCUIElementTypeButton[10]";
driver.findElement(MobileBy.iOSClassChain(selector));
它的意思是找到第10个按钮，它是UI层次结构中任何XCUIElementTypeCell的子元素，它的名称以字符“C”开头。由于类链查询的形式更加严格，所以性能保证比XPath更好。
Android上的定位策略
Android上的定位策略
Appium团队实现了一个特殊的解析器，它支持大部分UiSelector API。我们通过“-android
uiautomator”定位器策略使这个解析器可用，选择器应该是以new UiSelector()开头的Java代码。让我们来看一个例子:
UiSelector：https://developer.android.com/reference/android/support/test/uiautomator/UiSelector
String selector = "new UiSelector().className(\"ScrollView\").getChildByText(new UiSelector().className(\"android.widget.TextView\"), \"Tabs\")";
driver.findElement(MobileBy.AndroidUIAutomator(selector));
我们再次使用MobileBy策略，因为该策略仅适用于Appium。首先构造一个字符串，它会被Appium解析和解释当命令被发送。表达式的意思是用“Tabs”找到的第一个TextView元素，它是层次结构中第一个ScrollView的一个子元素。这个表达式比XPath笨拙一些，但拥有更好的性能。
与iOS类链策略一样，它的主要缺点是只能用于Android。(此外，它支持任意版本的Java，它受限于UiSelector API)。
使用哪种定位
如何知道哪些选择器可以用这些策略呢?如果你是一个应用程序开发者，你可以简单地看一下代码，或者你可能记得你给了一个特定的元素一个特定的可访问性标签。如果你不能访问代码，或者你想要一个方法来显示Appium在你的应用程序中看到的内容，那么最好使用Appium
Desktop。Appium
Desktop是一个运行Appium和检查应用程序的GUI工具。您可以使用它来启动带有任意所需功能的“检查器会话”。检查会话向您显示应用程序的屏幕快照、UI层次结构(作为XML)以及关于您选择的任何元素的大量元数据：
检查器的一大优点是，当您单击层次结构中的一个元素时，它会智能地为您建议定位器策略和选择器。在上面的图像中，您可以看到对于所选元素，建议是“accessibility
id”，它的选择器是“Login
Screen”。你也可以手动查看XML树，查看元素是否确实存在。如果没有，这意味着Appium(即底层自动化框架)看不到它，您需要询问应用程序开发人员原因.
** _
来霍格沃兹测试开发学社，学习更多软件测试与测试开发的进阶技术，知识点涵盖web自动化测试 app自动化测试、接口自动化测试、测试框架、性能测试、安全测试、持续集成/持续交付/DevOps，测试左移、测试右移、精准测试、测试平台开发、测试管理等内容，课程技术涵盖bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相关技术，全面提升测试开发工程师的技术实力
QQ交流群：484590337
公众号 TestingStudio
点击获取更多信息
