企业官网建设流程全解析

1. 项目概述：为什么Appium定位是自动化测试的基石

做移动端自动化测试，尤其是跨平台的，Appium几乎是绕不开的名字。但很多刚入门的同学，包括我当年，都容易陷入一个误区：觉得Appium环境搭建好了，脚本能跑起来了，就万事大吉。结果真到写用例的时候，第一个拦路虎就来了——元素定位。脚本对着屏幕一通操作，结果要么报错找不到元素，要么点错了地方，测试流程直接卡壳。我见过太多项目，前期轰轰烈烈，后期就因为元素定位不稳定、维护成本太高而烂尾。所以，今天我们不谈那些宏大的框架设计，就扎扎实实地聊聊Appium自动化测试中最核心、最基础，也最考验功力的部分：定位方法。

你可以把Appium想象成一个遥控机器人，你的测试脚本就是遥控指令。而定位方法，就是你告诉机器人“去点击屏幕上那个红色的登录按钮”的具体方式。如果指令不清晰、不准确，机器人就会不知所措。在移动应用开发中，尤其是Android和iOS生态差异巨大、应用迭代频繁的背景下，找到一套稳定、高效、可维护的元素定位策略，是保障自动化测试脚本长期稳定运行的生命线。无论是测试工程师验证核心业务流程，还是开发人员做冒烟测试，甚至是追求研发效能团队搭建CI/CD流水线，精准的元素定位都是第一步，也是最关键的一步。这篇文章，我将结合我这些年踩过的坑和积累的经验，为你系统梳理Appium的各种定位方法，不止告诉你“怎么用”，更重点剖析“什么时候用”以及“为什么这么用”，帮你构建起一套应对复杂真实场景的定位方法论。

2. 核心定位策略解析：八种武器与选型心法

Appium提供了多种定位元素的方式，就像工具箱里的不同工具，没有绝对的好坏，只有是否适合当前场景。盲目使用或者只会用一两种，都会导致脚本脆弱。下面我们来逐一拆解这八种核心定位器，并深入探讨其背后的原理和适用边界。

2.1 通过资源ID定位：首选但非万能

resource-id(Android) 和name(iOS， 对应Accessibility Identifier) 是定位元素的首选方式，相当于元素的身份证号，理想情况下应该是唯一的。

原理与实操：在Android中，resource-id对应视图控件的android:id属性；在iOS中，我们通常为控件设置唯一的accessibilityIdentifier，Appium将其映射为name属性进行定位。使用find_element(By.ID, “id值”)或find_element(AppiumBy.ACCESSIBILITY_ID, “id值”)来查找。

# Android示例：定位登录按钮 login_button_android = driver.find_element(By.ID, “com.example.app:id/btn_login”) # iOS示例：定位同一个登录按钮 login_button_ios = driver.find_element(AppiumBy.ACCESSIBILITY_ID, “loginButton”)

为什么它是首选？因为ID通常由开发人员静态定义，在单次应用运行生命周期内基本不变，且定位速度最快，底层直接调用原生框架的查询接口，效率远高于其他基于遍历或坐标的策略。

注意事项与常见坑：

1. ID不是总有：很多元素，特别是容器视图、自定义控件或第三方库提供的组件，可能没有设置ID。这是最常见的情况，不能依赖。
2. ID不唯一：糟糕的代码规范可能导致同一个ID在同一个页面上出现多次，虽然不常见，但一旦发生就会导致定位到错误的元素。
3. 动态ID：有些框架或列表项（如RecyclerView、ListView的item）会生成包含索引或哈希值的动态ID，每次加载都可能变化，绝对不能用。
4. 平台差异：Android的resource-id和iOS的accessibilityIdentifier在概念和设置方式上不同，需要与开发团队约定规范，并在脚本中做平台适配。

提示：在项目初期，就应该推动开发团队为所有关键交互元素（按钮、输入框、关键文本）添加稳定的、语义化的测试ID。这是一项重要的测试左移实践，能极大降低后续的自动化维护成本。

2.2 通过XPath定位：强大的双刃剑

XPath是一种在XML文档中定位节点的语言，而App的UI层级结构（UIAutomator2 for Android, XCUITest for iOS）本质上就是一种XML树。因此，XPath功能极其强大，理论上可以定位到任何元素。

原理与实操：XPath通过路径表达式来选取节点。在Appium中，你可以使用绝对路径（从根节点开始）或相对路径。

# 绝对路径（极其脆弱，不推荐） # 假设一个非常深的层级 fragile_element = driver.find_element(By.XPATH, “/hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/.../android.widget.Button”) # 相对路径结合属性（推荐） # 定位文本为“登录”的按钮 login_by_text = driver.find_element(By.XPATH, “//*[@text=‘登录’]”) # 定位包含特定ID和类名的元素 specific_element = driver.find_element(By.XPATH, “//android.widget.Button[@resource-id=‘com.example:id/btn’ and @enabled=‘true’]”)

为什么它强大又危险？强大在于其灵活性。当元素没有ID，或者你需要根据复杂的逻辑关系（如兄弟节点、父节点、包含特定文本）来定位时，XPath几乎是唯一的选择。然而，它的危险性也源于此：

1. 极度脆弱：绝对路径对UI层级结构的变化零容错，改一个布局容器，路径就全失效了。即使是相对路径，如果依赖的索引（如[1]）或过于复杂的层级关系，也容易在UI调整后失效。
2. 性能开销大：XPath查询需要在整棵UI树中进行遍历和匹配，尤其复杂的XPath表达式，其执行效率远低于ID定位。在大型页面上频繁使用，会显著拖慢测试速度。
3. 平台兼容性细微差异：Android和iOS的UI树结构不同，写跨平台的XPath需要格外小心。

XPath最佳实践：

• 绝对禁止使用绝对路径。
• 优先使用属性组合：如//*[@resource-id=‘xxx’ and @text=‘yyy’]，比单属性更稳定。
• 善用函数：contains()、starts-with()可以应对文本或属性值部分动态变化的情况，但需谨慎，避免匹配到多个元素。
• 层级尽量浅：从离目标元素最近的、有稳定特征的父节点开始定位。

2.3 通过Accessibility ID定位：跨平台的优雅选择

AppiumBy.ACCESSIBILITY_ID定位器在Android上查找content-desc属性，在iOS上查找accessibilityIdentifier属性。它的设计初衷是为了无障碍功能，但恰好为自动化测试提供了一个良好的跨平台定位点。

原理与实操：开发者为方便视障用户，会为控件添加描述信息。这些信息也成为了稳定的定位锚点。

# 此方法在Android和iOS上均可使用，查找逻辑一致 search_box = driver.find_element(AppiumBy.ACCESSIBILITY_ID, “搜索框”) submit_button = driver.find_element(AppiumBy.ACCESSIBILITY_ID, “提交订单”)

为什么说它“优雅”？

1. 语义化：ACCESSIBILITY_ID通常是有意义的文本，如“搜索按钮”、“用户名输入框”，这使测试脚本更易读、易维护。
2. 跨平台性：使用同一定位器代码，底层会根据平台自动映射到正确的属性，减少了条件判断。
3. 相对稳定：这些描述信息通常不会因为UI样式调整而频繁变动。

注意事项：

• 依赖开发规范：同样需要推动开发人员为可交互元素添加合适的无障碍标识。如果应用本身不注重无障碍体验，此方法可用性会大打折扣。
• 可能不唯一：和ID一样，需要保证关键元素的唯一性。
• 并非所有元素都有：静态文本、装饰性图片等可能没有。

2.4 通过类名定位：粗粒度与列表操作的利器

By.CLASS_NAME通过元素的类名（如android.widget.Button、XCUIElementTypeButton）来定位。它通常不单独用于精准定位，因为一个页面上同类控件太多。

原理与实操：直接使用控件类型的全称进行查找。

# 查找当前页面所有按钮 all_buttons = driver.find_elements(By.CLASS_NAME, “android.widget.Button”) # 通常需要结合其他条件筛选 first_button = all_buttons[0] # 危险！顺序可能变

主要应用场景：

1. 查找元素集合：当你需要获取某一类控件的列表时，例如获取当前页面所有可点击的项。
2. 组合定位：作为XPath表达式的一部分，与其他属性结合使用，提高查询效率。例如//android.widget.Button[@text=‘确定’]就比//*[@text=‘确定’]更高效，因为前者限制了节点类型。
3. 动态列表操作：在遍历RecyclerView或TableView时，先通过类名找到所有item视图，再根据索引或其他属性操作特定项。

注意：直接通过find_elements获取列表后通过索引（如[0]）操作是非常不稳定的，因为UI顺序可能改变。应尽量结合文本、ID等属性进行二次筛选。

2.5 通过文本内容定位：直观但需谨慎

By.ANDROID_UIAUTOMATOR(Android) 和By.IOS_CLASS_CHAIN/By.IOS_PREDICATE(iOS) 可以方便地通过元素的文本属性进行定位，AppiumBy.ANDROID_UIAUTOMATOR的new UiSelector().text()或XPath的@text属性也常用。

原理与实操：

# Android - 使用UIAutomator2 (推荐) android_text_element = driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, ‘new UiSelector().text(“确定”)’) # Android/iOS - 使用XPath (通用但稍慢) text_element_xpath = driver.find_element(By.XPATH, ‘//*[@text=“确定”]’) # iOS - 使用Predicate (功能强大) ios_text_element = driver.find_element(AppiumBy.IOS_PREDICATE, ‘label == “确定”’)

为什么需谨慎？

1. 文本常变：这是最大的问题。按钮文本可能随业务状态改变（如“加入购物车”变“已添加”），列表项文本来自动态数据。依赖绝对文本的定位非常脆弱。
2. 多语言适配：如果你的应用支持多语言，测试脚本中的硬编码文本将无法在其他语言环境下运行。
3. 可能匹配多个：同一个文本可能在页面上出现多次，例如多个“提示”弹窗。

适用场景与技巧：

• 静态文本：用于确认页面标题、版权信息等几乎不变的文本元素，作为断言（Assert）的一部分非常合适。
• 部分匹配：使用contains、startsWith等函数进行模糊匹配，可以应对文本前缀固定、后缀动态的情况（如“订单号：123456”）。
• 结合其他属性：总是尝试将文本与其他更稳定的属性（如ID、类名）组合使用，增加唯一性。

2.6 通过坐标定位：最后的手段

通过绝对坐标（driver.tap([(x, y)])）或相对坐标（仅适用于W3C标准）进行点击。这是所有方法中最不推荐的一种。

为什么它是“最后的手段”？

1. 毫无容错性：屏幕分辨率、设备尺寸、应用布局的任何变化都会导致坐标失效。
2. 无法移植：在一台手机上录制的坐标，换一台不同尺寸的手机就无法使用。
3. 不符合测试哲学：自动化测试应该模拟用户交互，用户是通过识别UI元素来操作的，而不是记住像素点。坐标定位完全脱离了UI语义。

极少数可用场景：

• 测试某些无法通过常规方式定位的系统级控件或游戏画面（但游戏测试更推荐像Appium Game这样的专门插件）。
• 作为临时调试手段，快速验证某个屏幕区域是否可点击。
• 在万不得已且环境绝对可控（如固定设备、固定分辨率、UI绝对不变）的情况下，用于处理一些“疑难杂症”。

如果必须用，请务必：

• 使用相对坐标（如果支持）。
• 将坐标计算逻辑与设备屏幕信息绑定，实现简单的适配。
• 明确注释，并作为技术债务尽快寻找替代方案。

2.7 通过UIAutomator2 (Android) / Predicate, ClassChain (iOS) 进行高级定位

对于复杂场景，Appium提供了更强大的、与底层测试框架深度集成的定位方式。

Android UIAutomator2:UiSelectorAPI功能丰富，可以进行链式调用，实现复杂查询。

# 查找文本包含“商品”且可点击的元素 element = driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, ‘new UiSelector().textContains(“商品”).clickable(true)’) # 通过子元素定位父元素（需要结合JavaScript执行，此处是思路） # 先找到特征明显的子元素，再获取其父控件

iOS Predicate / ClassChain:NSPredicate语法非常强大，支持丰富的比较和逻辑运算。

# 查找label为“提交”且enabled的按钮 element = driver.find_element(AppiumBy.IOS_PREDICATE, ‘type == “XCUIElementTypeButton” AND label == “提交” AND enabled == true’) # ClassChain 类似于XPath，但语法更简洁，性能通常更好 element = driver.find_element(AppiumBy.IOS_CLASS_CHAIN, ‘**/XCUIElementTypeButton[`label == “提交”`]’)

这些高级定位器的价值在于：

• 表达能力强：可以在一行语句中组合多个条件，精准定位。
• 性能优化：特别是iOS ClassChain，其查询效率比复杂的XPath要高。
• 处理动态内容：可以方便地使用BEGINSWITH、CONTAINS、ENDSWITH等操作符处理动态文本。

2.8 定位策略选型心法总结

面对这么多方法，如何选择？我总结了一个决策流和优先级：

1. 第一优先级：唯一ID (resource-id/accessibilityIdentifier)。如果元素有，且唯一，无条件使用。这是构建稳定脚本的基石。
2. 第二优先级：语义化ID (ACCESSIBILITY_ID)。如果开发提供了良好的无障碍标识，这是跨平台脚本的优秀选择。
3. 第三优先级：属性组合定位。当没有唯一ID时，尝试使用XPath或UIAutomator2/Predicate，将类名、文本（部分匹配）、其他属性（如enabled,selected）组合起来，形成一个相对稳定的定位器。优先使用非文本属性。
4. 第四优先级：相对关系与层级定位。如果元素本身没有任何独特属性，可以考虑通过其相邻元素（兄弟节点）或父容器来定位。例如“找到位于‘用户名’输入框下方的那个按钮”。这需要你对UI结构有清晰了解。
5. 最后手段：坐标与图像识别。仅在上述所有方法都失效，且元素确实无法通过编程方式访问（如某些嵌入式WebView或游戏）时考虑。并立即向开发团队反馈，推动添加可访问性属性。

核心原则：稳定性 > 可读性 > 执行效率。一个每天需要花一小时修复的“快”脚本，远不如一个一周都不出错的“慢”脚本有价值。

3. 实战：构建健壮定位策略的完整流程

理解了各种武器，我们来看看如何在实际项目中运用它们，打造一套抗变化的自动化测试脚本。我将以一个典型的电商App“加入购物车->下单”流程为例，拆解每一步的定位思考。

3.1 第一步：元素侦察与属性分析

在编写任何定位代码之前，必须使用侦察工具仔细分析目标元素。Appium Desktop内置的Inspector或单独下载的Appium Inspector是你的主要工具。

操作流程：

1. 启动Inspector，连接你的测试设备和待测应用。
2. 点击或滑动到目标页面。
3. 在元素树中点击你想要定位的元素（如“加入购物车”按钮）。
4. 仔细查看右侧详情面板中的所有属性：resource-id,class,text,content-desc,bounds,enabled,clickable等。

分析要点：

• 寻找唯一标识：首先看resource-id或name(iOS)是否有值且是否唯一。
• 评估文本稳定性：text属性是“加入购物车”还是“Add to Cart”？它会不会在商品售罄后变成“已售罄”？如果是后者，就不能单独依赖文本。
• 查看组合特征：如果ID没有，文本会变，那就看有没有其他属性组合可以唯一确定它。例如，这个按钮的class是android.widget.Button，并且它的clickable是true，同时它位于某个特定ID的商品卡片容器内。这些信息都将成为你编写定位器的素材。
• 记录层级结构：注意目标元素的父节点、兄弟节点有什么特征。有时直接定位目标困难，但定位其父节点很容易，然后通过find_element在父节点下查找子元素，是更稳定的策略。

3.2 第二步：编写与验证定位器

根据侦察结果，在脚本中编写定位代码，并立即在交互窗口（如Inspector或REPL）中验证。

以“加入购物车”按钮为例，假设它没有ID：

方案A（依赖文本，脆弱）：

driver.find_element(By.XPATH, “//*[@text=‘加入购物车’]”).click()

风险：商品缺货时文本变为“补货中”，脚本失败。

方案B（组合定位，较稳定）：

# 假设该按钮在一个商品卡片内，卡片有ID ‘item_123’ # 先定位到商品卡片容器 item_card = driver.find_element(By.ID, “item_123”) # 在卡片容器内寻找“加入购物车”按钮 add_button = item_card.find_element(By.XPATH, “.//android.widget.Button[contains(@text, ‘购物车’)]”) add_button.click()

优势：将搜索范围缩小到特定商品卡片内，即使页面有其他“购物车”相关文本也不怕。使用contains部分匹配，对文本微调有一定容错。

方案C（使用UIAutomator2，更精准）：

selector = ‘new UiSelector().className(“android.widget.Button”).textContains(“购物车”).clickable(true)’ driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, selector).click()

验证：在Inspector的“Search for element”功能中，输入你编写的定位表达式（如XPath），点击“Find”，观察是否能唯一、准确地高亮目标元素。这是编写定位器时必须进行的步骤。

3.3 第三步：实现等待与重试机制

即使定位器写得再好，也可能因为网络延迟、页面渲染速度等原因，在脚本执行时元素尚未出现。因此，显式等待（Explicit Wait）是生产级脚本的标配。

不要用隐式等待（Implicitly Wait）或硬性等待（time.sleep）！前者会导致全局不可控的延迟，后者浪费执行时间且不可靠。

正确做法：使用WebDriverWait

from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 定义等待条件和超时时间 wait = WebDriverWait(driver, 10) # 最多等10秒 # 等待元素出现并可点击 add_to_cart_button = wait.until( EC.element_to_be_clickable( (AppiumBy.ACCESSIBILITY_ID, “addToCartButton”) # 或你的其他定位器 ) ) add_to_cart_button.click()

封装智能重试： 对于某些偶发性定位失败（如动画干扰），可以在定位逻辑外包裹一个重试机制。

import time from selenium.common.exceptions import NoSuchElementException, StaleElementReferenceException def find_element_with_retry(driver, locator, retries=3, delay=1): for i in range(retries): try: element = driver.find_element(*locator) return element except (NoSuchElementException, StaleElementReferenceException) as e: if i == retries - 1: raise e time.sleep(delay) return None # 使用 locator = (By.ID, “volatile_element”) element = find_element_with_retry(driver, locator)

3.4 第四步：设计页面对象模型 (Page Object Model, POM)

当脚本规模增长，直接在各处散落定位器将是维护的噩梦。POM设计模式将页面封装成类，页面的元素定位器和基本操作作为类的方法，实现业务逻辑与定位细节的分离。

基础POM示例：

# base_page.py class BasePage: def __init__(self, driver): self.driver = driver self.wait = WebDriverWait(driver, 10) # product_detail_page.py class ProductDetailPage(BasePage): # 定位器 ADD_TO_CART_BTN = (AppiumBy.ACCESSIBILITY_ID, “addToCartButton”) PRODUCT_TITLE = (By.ID, “productTitle”) PRICE_TEXT = (By.ID, “priceValue”) # 页面操作方法 def add_to_cart(self): add_btn = self.wait.until(EC.element_to_be_clickable(self.ADD_TO_CART_BTN)) add_btn.click() return CartPage(self.driver) # 通常返回下一个页面对象 def get_product_info(self): title = self.driver.find_element(*self.PRODUCT_TITLE).text price = self.driver.find_element(*self.PRICE_TEXT).text return {“title”: title, “price”: price} # test_case.py def test_add_to_cart(): driver = appium_driver product_page = ProductDetailPage(driver) product_page.add_to_cart() # ... 后续断言

POM的优势：

• 高可维护性：当“加入购物车”按钮的ID改变时，你只需要在一个地方（ProductDetailPage类中）修改定位器常量。
• 高可读性：测试用例读起来像自然语言，product_page.add_to_cart()，业务逻辑清晰。
• 低冗余：避免了重复的定位代码。

4. 疑难杂症排查与性能优化实录

在实际项目中，你会遇到各种光怪陆离的定位问题。下面是我总结的一些典型难题和解决思路。

4.1 动态内容与列表项定位

问题：商品列表、聊天记录、新闻流等，数据动态加载，列表项没有固定ID，且内容随时变化。

解决方案：

1. 不依赖绝对索引：永远不要用find_elements(...)[5]来定位第6个商品。
2. 使用相对定位或内容匹配：
   • 文本匹配：如果商品名称是动态的，但你知道你要找的商品包含特定关键词（如“小米手机”），可以使用contains(@text, ‘小米’)。
   • 先定位容器，再过滤：先获取整个列表的所有项，然后遍历，根据项内的子元素特征（如特定的价格区间、标签图标）来找到目标项。

   # 假设每个商品项是一个RelativeLayout，内部有一个TextView显示名称 all_items = driver.find_elements(By.CLASS_NAME, “android.widget.RelativeLayout”) target_item = None for item in all_items: try: # 在每个item内查找包含“小米”的商品名 name_element = item.find_element(By.ID, “itemName”) if “小米” in name_element.text: target_item = item break except NoSuchElementException: continue if target_item: target_item.click()

3. 使用UIAutomator2的childSelector或fromParent：在Android上可以构建更复杂的父子关系查询。

4.2 混合应用与WebView中的定位

问题：App内嵌了H5页面（WebView），标准Appium定位器全部失效。

解决方案：

1. 上下文（Context）切换：这是关键。Appium将原生部分和WebView部分视为不同的“上下文”。

   # 1. 获取所有可用上下文 contexts = driver.contexts # 例如：[‘NATIVE_APP’, ‘WEBVIEW_com.example.app’] # 2. 切换到WebView上下文 driver.switch_to.context(‘WEBVIEW_com.example.app’) # 3. 此时，你可以使用Selenium的定位方式定位Web元素（如By.CSS_SELECTOR, By.ID） web_element = driver.find_element(By.CSS_SELECTOR, “#webLoginBtn”) web_element.click() # 4. 操作完成后，切回原生上下文 driver.switch_to.context(‘NATIVE_APP’)

2. 启用WebView调试：需要开发人员在构建App时启用WebView的调试功能（setWebContentsDebuggingEnabled(true)）。
3. 定位器变化：在WebView上下文中，使用Chrome DevTools或浏览器开发者工具来审查元素，使用CSS选择器或XPath进行定位。

4.3 弹窗、权限框与系统组件

问题：系统级弹窗（如权限申请、日期选择器）或应用内弹窗，其元素不在应用本身的UI树内，或者突然出现打断流程。

解决方案：

1. 识别弹窗类型：使用driver.page_source快速输出当前XML，查看弹窗元素的属性。系统弹窗通常有特定的包名（如com.android.packageinstaller）。
2. 使用Activity识别：对于Android，可以监听当前Activity的变化来处理特定弹窗。
3. 封装通用处理函数：对于常见的“允许”、“拒绝”、“确定”按钮，可以写成通用函数，在需要时调用。

   def handle_android_permission(driver, permission_text=“允许”): try: # 尝试定位系统权限弹窗的按钮 selector = f‘new UiSelector().text(“{permission_text}”).className(“android.widget.Button”)’ btn = WebDriverWait(driver, 5).until( EC.element_to_be_clickable((AppiumBy.ANDROID_UIAUTOMATOR, selector)) ) btn.click() return True except TimeoutException: # 没有弹窗或不是预期弹窗 return False

4. 预期弹窗：在可能触发弹窗的操作后，主动等待并处理弹窗，再继续主流程。

4.4 定位器性能优化技巧

当页面元素非常多，或者定位表达式很复杂时，性能会成为问题。

1. 缩小搜索范围：这是最有效的优化。优先使用find_element在已找到的父元素下查找子元素，而不是每次都从根节点开始全局搜索。
2. 使用更高效的定位器：优先级：ID>ACCESSIBILITY_ID>CLASS_NAME(结合其他) >ANDROID_UIAUTOMATOR/IOS_PREDICATE>XPATH。复杂的XPath是性能杀手。
3. 避免过度使用find_elements：获取大量元素列表会消耗资源。只在必要时使用，并尽快缩小列表。
4. 缓存元素对象：对于在同一个测试用例中需要多次操作的元素，可以将其定位后存储在变量中重复使用，避免重复查找。但要注意StaleElementReferenceException（元素过期），当页面刷新后，旧的元素引用会失效。

4.5 常见错误与排查表

定位元素是Appium自动化测试中技术含量最高、最需要耐心和经验的部分。它没有银弹，需要你根据具体的应用特点、团队规范和业务场景，灵活组合运用多种策略。记住，一个好的定位器不是写出来就一劳永逸的，它需要随着应用的迭代而维护。因此，建立良好的沟通机制（与开发确认关键元素ID）、采用科学的设计模式（如POM）、编写易于维护的定位代码，其重要性不亚于定位技术本身。从今天起，扔掉那些脆弱的绝对路径和硬编码的文本吧，用心构建你的元素定位策略，你的自动化测试脚本才能真正成为值得信赖的守护者。