@appium/mcp-documentation 1.0.2 → 1.0.4

package/src/resources/submodules/appium/packages/appium/docs/zh/guides/tls.md

@@ -0,0 +1,43 @@
+---
+hide:
+  - toc
+
+title: SSL/TLS/SPDY Support
+---
+
+Appium 2.2 introduces the option to start the Appium server with SSL/TLS support.
+
+## Command Line Arguments
+
+In order to enable secure connections to the server, you need to provide the following command
+line arguments:
+
+```bash
+appium server --ssl-cert-path=/path/to/cert.pem --ssl-key-path=/path/to/key.pem
+```
+
+Both arguments must be provided and should contain paths to a valid
+[X509 PEM](https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/)
+certificate and its corresponding private key.
+
+After the server is started use the `https` protocol and a client supporting SSL/TLS or
+[SPDY](https://en.wikipedia.org/wiki/SPDY) to communicate to it.
+
+### Supported Features
+
+Once a secure server socket is established it supports the following protocols:
+`['h2', 'spdy/3.1', 'spdy/3', 'spdy/2', 'http/1.1', 'http/1.0']`. See
+[the SPDY node module documentation](https://www.npmjs.com/package/spdy) to get more details about
+its features. All insecure client connections will be rejected by the server.
+
+### Self-Signed Certificates
+
+Use the following command in order to generate a self-signed certificate/key pair:
+
+```bash
+openssl req -nodes -new -x509 -keyout key.pem -out cert.pem -subj "/C=US/ST=State/L=City/O=company/OU=Com/CN=www.testserver.local"
+```
+
+Feel free to change the value of `-subj` in the command above with your matching details. The server
+should work just fine with a self-signed certificate, although you need to take care about a proper
+client setup, e.g. make sure it does not reject unauthorized certificates.

package/src/resources/submodules/appium/packages/appium/docs/zh/index.md

@@ -0,0 +1,54 @@
+---
+hide:
+  - 导航栏
+  - toc
+
+title: 欢迎使用
+---
+
+<style>
+  .md-typeset h1,
+  .appium-sponsor-thanks {
+    display: none;
+  }</style>
+
+<div style="text-align: center">
+  <img src="assets/images/appium-logo-horiz.png" style="max-width: 400px;" />
+</div>
+
+欢迎来到 Appium 文档！ Appium是一个开源项目和相关软件生态系统，旨在促进多种应用平台的用户界面自动化，包括移动端（iOS、Android、Tizen）、浏览器端（Chrome、Firefox、Safari）、桌面端（macOS、Windows）、电视端（Roku、tvOS、Android TV、三星）等！
+
+<div style="text-align: center; margin-top: 2rem; font-style: italic;">
+  Appium 非常感谢主要合作伙伴的支持！ (了解更多关于我们的赞助计划和贡献者补偿计划信息请<a
+  href="https://github.com/appium/appium/blob/master/GOVERNANCE.md#sponsorship">点击此处</a>)  
+<div class="homepageSponsors">
+    <div class="homepageSponsor">
+      <a href="https://www.browserstack.com/browserstack-appium?utm_campaigncode=701OW00000AoUTQYA3&utm_medium=partnered&utm_source=appium">
+        <img src="assets/images/sponsor-logo-browserstack-dark.png#only-dark" style="width: 220px;" />
+        <img src="assets/images/sponsor-logo-browserstack-light.png#only-light" style="width: 220px;" />
+      </a>
+    </div>
+    <div class="homepageSponsor">
+      <a href="https://www.testmuai.com">
+        <img src="assets/images/sponsor-logo-testmuai-dark.png#only-dark" style="width: 220px;" />
+        <img src="assets/images/sponsor-logo-testmuai-light.png#only-light" style="width: 220px;" />
+      </a>
+    </div>
+  </div>
+</div>
+
+## 探索文档
+
+<div class="grid cards" markdown>
+
+- 查看 [**简介**](./intro/index.md) 以确保您理解关键概念
+- 通过 [**快速开始**](./quickstart/index.md) 来设置并运行一个基本的 Android 测试
+- 访问 [**生态系统**](./ecosystem/index.md) 页面，获取您可能想要使用的驱动程序、客户端和插件列表
+- 访问 [**Reference**](./reference/index.md) 页面获取Appium CLI 和支持的端点信息
+- 阅读不同版本的 [**指南**](./guides/migrating-2-to-3.md)，了解各版本的说明、提示和技巧
+- 查看各种第三方 [**资源**](./resources/index.md) 以探索网络上的 Appium
+- 要创建自己的 Appium 扩展，请参阅 [**开发者**](./developing/index.md) 文档
+- 有关对 Appium 的贡献，请查阅 [**贡献**](./contributing/index.md) 页面
+- 查看 [**Appium博客**](./blog/index.md) ，了解项目中的新内容
+
+</div>

package/src/resources/submodules/appium/packages/appium/docs/zh/intro/appium.md

@@ -0,0 +1,91 @@
+---
+title: Appium 如何工作？
+---
+
+正如主页所述，Appium 是一个开源项目和相关软件生态系统，旨在促进多种应用平台的 UI 自动化。 随着 Appium 2 的发布，Appium 具有以下主要目标：[^1]
+
+- 在跨平台标准 API 下提供特定于平台的自动化功能
+- 允许从任何编程语言轻松访问此 API
+- 提供工具以便社区方便地开发 Appium 扩展
+
+[^1]: 为实现这些主要目标，我们还遵循一套次要目标或方法原则，我们也鼓励 Appium 扩展开发者遵循这些原则：
+
+    - 尽可能依赖（并贡献于）开源技术
+    - 尽可能依赖给定平台的供应商提供的工具
+    - 尽可能依赖不修改应用就能实现自动化（最好不要要求用户构建额外的 SDK 或软件，从而在测试版本和生产版本之间引入差异）的自动化工具
+    - 尽可能依赖现有标准而不是创建新标准
+
+所以，以您了解的任何应用平台为例，如 iOS 或 Android。 Appium 希望开发者测试人员能够为该平台编写 UI 自动化代码，根据单一的统一 API。 根据 Appium 的目标，我们有很多问题需要回答以使其全部工作：
+
+- “单一统一”的 API 应该是什么？
+- 我们如何将此 API 映射到特定平台的自动化行为？
+- 我们如何使此 API 通过多种流行编程语言访问？
+
+这里还有另一个更大的问题，鉴于除了 iOS 和 Android 之外还有更多应用平台：
+
+- 我们如何为_所有_平台启用自动化？
+
+探索 Appium 对这些问题的答案可能不是学习 Appium 是什么的最快方式，但它肯定是一个好方法！ 所以让我们深入了解。
+
+## Appium 的 API 选择
+
+Appium 非常幸运地继承了一个在 UI 自动化领域长期领先的技术，即 [Selenium](https://selenium.dev)。 Selenium 项目的目标是支持 Web 浏览器的 UI 自动化，因此我们可以将其视为占据 Appium 目标子集的一部分。 在此过程中，Selenium（以及后来合并的另一个名为 WebDriver 的项目）开发了一个相对稳定的浏览器自动化 API。
+
+多年来，Selenium 与各种 Web 浏览器供应商和 [W3C](https://w3.org) 标准小组合作，将其 API 转变为官方 Web 浏览器标准，称为 [WebDriver 规范](https://w3c.github.io/webdriver/)。
+所有主要浏览器现在都实现了符合 WebDriver 规范的自动化功能，而无需 Selenium 团队维护任何执行实际自动化的软件；标准获胜！
+
+Appium 的最初目标是为移动应用（iOS 和 Android）开发自动化标准。 我们本可以发明一些新的东西，但为了团结力量并保持标准的标准化，我们决定采用 WebDriver 规范作为 Appium 的 API。[^2] 虽然网站和移动原生应用的用户交互并不完全相同（一旦我们开始考虑例如由简单遥控器控制的电视平台，差异会更大），但事实是大多数软件 UI 都非常相似。 这意味着 WebDriver 规范提供了自动化 API 原语（查找元素、与元素交互、加载页面或屏幕等） 这些原语或多或少映射到任何平台。
+
+[^2]: 从技术上讲，当 Appium 首次编写时，我们处理的是比 WebDriver 规范更古老的东西，称为 JSON Wire Protocol。 从那时起，Appium 继续与 W3C 规范一起演化，并完全符合 W3C 规范。
+
+当然，Appium 希望支持用户交互从 Web 到移动或 Web 到电视确实不同的情况，因此 Appium 还利用 WebDriver 规范的内置_可扩展性_。 结果是，无论您想要自动化哪个平台，当您使用 Appium 时，您将使用标准 WebDriver 规范，但有两个注意事项：
+
+- 我们可能无法在给定平台上支持特定的 WebDriver API 命令，因此某些命令可能不受支持（例如，在原生移动应用自动化世界中，获取或设置 cookie 是不可能的）。
+- 我们可能支持超出 WebDriver API 命令列表的自动化行为，尽管任何此类命令将是有效的、符合规范的 WebDriver API 扩展。
+
+您实际上如何_使用_ WebDriver API，特别是 Appium 的背景下？ 我们将在下面的[部分](#universal-programming-language-access)中介绍 Appium 如何提供通用编程语言访问。 您现在只需要知道 Appium 通过实现 WebDriver 协议来引入通用 UI 自动化接口。
+
+## 平台自动化行为
+
+下一个问题是，Appium 如何将此协议映射到广泛平台的自动化行为？ 严格来说，Appium 没有！ 它将此责任留给一种称为 Appium _驱动程序_ 的软件模块。 您可以阅读整个[驱动程序](./drivers.md)的介绍，所以我们现在不会深入细节。
+
+目前重要的是要理解驱动程序有点像 Appium 的可插拔模块，它赋予 Appium 自动化特定平台（或平台集，取决于驱动程序的目标）的能力。 最终，驱动程序的责任只是实现代表 WebDriver 协议的 Appium 内部接口。 它如何实现此接口完全取决于驱动程序，基于其在特定平台上实现自动化的策略。 通常，在细节上具有更多复杂性和难度，驱动程序通过依赖特定于平台的自动化技术来实现这一点。 例如，Apple 维护一种称为 [XCUITest](https://developer.apple.com/documentation/xctest/user_interface_tests) 的 iOS 自动化技术。 支持 iOS 应用自动化的 Appium 驱动程序称为 [XCUITest 驱动程序](https://github.com/appium/appium-xcuitest-driver)，因为它最终所做的是将 WebDriver 协议转换为 XCUITest 库调用。
+
+驱动程序是独立、可插拔模块的原因之一是它们彼此完全不同。 构建和使用不同平台的驱动程序的工具和要求完全不同。 因此，Appium 让您只使用您自动化任务所需的驱动程序。 选择驱动程序并安装它们以便与您的 Appium 实例一起使用非常重要，以至于 Appium 有自己的 [CLI 来管理驱动程序](../reference/cli/extensions.md)。
+
+因此，为了回答我们最初的问题，Appium 为给定平台提供自动化功能访问的方式是 Appium 团队（或任何人[^3]）为该平台编写一个_驱动程序_，实现 WebDriver 协议的尽可能多或少的部分。 然后，任何使用 Appium 的人都可以安装驱动程序。
+
+[^3]: 您可以构建和分享自己的驱动程序！ 查看[构建驱动程序](../developing/build-drivers.md)以了解更多关于如何在 Node.js 中开发可与 Appium 一起使用的驱动程序的信息。
+
+## 通用编程语言访问
+
+但使用 Appium 意味着什么，或者看起来像什么？ 由于 Appium 最终是一个 Node.js 程序，它_可以_看起来像将 Appium 及其驱动程序作为库导入到您自己的 Node.js 程序中。 但这不会满足 Appium 的目标，即为使用任何流行编程语言的人提供自动化功能。
+
+幸运的是，Appium 继承 Selenium 的遗产意味着我们从一开始就有了这个问题的解决方案。 您看，WebDriver 规范实际上是一个基于 HTTP 的协议，这意味着它被设计为通过网络而不是单个程序的内存使用。
+
+这种“客户端-服务器”架构的主要好处之一是，它允许自动化实现者（执行自动化的事物，在这种情况下是“服务器”）与自动化运行者（定义应该做什么自动化、以什么步骤等的事物，在这种情况下是“客户端”）完全不同。 基本上，所有“困难的东西”（弄清楚如何在给定平台上实现自动化）可以在服务器的一个地方处理，“瘦”客户端库可以在任何编程语言中编写，这些库只需以适合语言的方式编码对服务器的 HTTP 请求。 换句话说，假设存在高级 HTTP 库，只需在该语言中编写基本的 HTTP 客户端，就可以相对容易地将基本的 Appium / WebDriver 功能引入新的编程语言。
+
+这里有几个重要的点供 Appium 用户了解：
+
+- Appium 是一个_HTTP 服务器_。 只要您想使用它进行自动化，它必须在某台计算机上作为进程运行。 它必须在网络上可访问，以方便您想要运行自动化的任何计算机访问（无论是同一台机器还是世界另一端的机器）。
+- 除非您想编写原始 HTTP 调用或使用 cURL，否则请使用您选择的语言的 [Appium 客户端](clients.md)进行自动化。 每个客户端的目标是将 WebDriver 协议封装，以便您不必担心协议本身，而是可以使用感觉适合您语言的对象和方法。
+- Appium 服务器和 Appium 客户端_不需要_在同一台计算机上运行。 您只需能够通过某个网络从客户端向服务器发送 HTTP 请求。
+  这大大促进了云提供商对 Appium 的使用，因为他们可以托管 Appium 服务器以及任何相关驱动程序和设备，您只需将客户端脚本指向他们的安全端点。
+
+当然，这一切都不是关于“测试”本身，只是出于自动化目的使用 Appium 及其客户端库。 如果您想出于“测试”目的进行自动化，您可能希望利用测试运行器、测试框架等的帮助，这些都不需要与 Appium 相关；Appium“通用可访问性”的好处之一是它与您发现最适合您情况的任何工具集配合良好。
+
+## Appium 的巨大范围
+
+Appium 的愿景（在单一 API 下自动化一切）是巨大的！ 当然，比开源项目的核心维护者团队大得多。 那么 Appium 如何希望实现这一目标？ 基本上，通过授权社区在 Appium 之上作为_平台_开发功能。 这就是我们所谓的 Appium“生态系统”。
+
+Appium 团队确实自己维护了一些驱动程序（例如，我们之前讨论的 XCUITest 驱动程序）。 但它无法拥有特定于平台的专业知识或维护许多不同平台的驱动程序的能力。 但我们所做的，特别是从 Appium 2 开始，是提供工具来授权社区加入我们的愿景：
+
+- 任何人都可以通过创建一个符合适当约定并实现 WebDriver 协议的任何（子|超）集的 Node.js 模块来创建驱动程序。 创建驱动程序通常涉及最少的代码，因为 WebDriver 协议细节被抽象化，许多帮助库可用---这些库为 Appium 团队自己的驱动程序提供动力。
+- 使用 Appium 驱动程序 CLI 与他人分享驱动程序很容易。 没有中央权威。
+  任何人都可以公开或私下分享驱动程序，免费或收费。 驱动程序可以是开源或闭源的（尽管我们欣赏开源！）。
+
+Appium 作为开发平台的愿景超越了对所有应用平台自动化支持。 作为一个流行的自动化工具，有许多机会将 Appium 与各种其他工具和服务集成。 此外，Appium 有许多功能想法，要么作为核心服务器，要么在其各种驱动程序中的化身，核心团队没有足够的时间构建。 因此，Appium 2 发布了一个插件系统，使任何人都可以构建和分享改变 Appium 工作方式的模块！
+
+就像驱动程序可以通过 Appium 驱动程序 CLI 轻松分享和消费一样，插件可以通过[插件 CLI](../reference/cli/extensions.md)发布和消费。 插件可以做各种事情，例如添加 Appium 根据模板图像查找和与屏幕区域交互的能力（例如[图像插件](https://github.com/appium/appium/tree/master/packages/images-plugin)）。 插件几乎没有限制，所以您可能也对学习如何在 Node.js 中[构建插件](../developing/build-plugins.md)以与 Appium 一起使用感兴趣。
+
+所以这就是 Appium：一个可扩展的、潜在一切的 UI 自动化通用接口！ 继续阅读一些具体的介绍文档以获取更多细节，或查看各种指南以深入了解 Appium 的一些更一般概念和功能。

package/src/resources/submodules/appium/packages/appium/docs/zh/intro/clients.md

@@ -0,0 +1,100 @@
+---
+hide:
+  - toc
+
+title: Appium 客户端简介
+---
+
+出于[概述](./appium.md)中讨论的所有原因，Appium 基于 [W3C WebDriver 规范](https://w3c.github.io/webdriver/)。 这意味着 Appium 实现了客户端-服务器架构。 服务器（由 Appium 本身以及您用于自动化的任何驱动程序或插件组成）连接到测试设备，并实际负责在这些设备上实现自动化。 客户端（由_您_驱动，Appium 测试作者）负责通过网络向服务器发送命令，并接收来自服务器的响应。 这些响应可用于判断自动化命令是否成功，或可能包含您查询的关于应用程序状态的信息。 本文档是对客户端方面的概念性介绍。
+
+!!! info
+
+```
+有关服务器端的信息（即 Appium 如何实际控制设备？），请查看我们的 [Appium 驱动程序简介](./drivers.md)。要跳转到 Appium 客户端库链接列表，请查看[客户端列表](../ecosystem/clients.md)。
+```
+
+有哪些自动化命令可用？ 那取决于您在任何给定会话中使用的特定驱动程序和插件。 一组标准命令可能包括以下内容：
+
+- 查找元素
+- 点击元素
+- 获取页面源代码
+- 截取屏幕截图
+
+如果您查看 WebDriver 规范中的这些命令，您会注意到它们不是以任何特定编程语言定义的。 它们不是 Java 命令、JavaScript 命令或 Python 命令。 相反，它们形成了可以通过_任何_编程语言访问的 HTTP API（ 如果您愿意，您可以只使用 cURL）。
+
+例如，`查找元素`命令对应于发送到 HTTP 端点 `/session/:sessionid/element` 的 HTTP `POST` 请求（其中`:sessionid` 是服务器在之前 `创建会话` 调用中生成的唯一会话 ID 的占位符）。
+
+此信息主要对开发与 WebDriver 规范一起工作的技术的人有用。 它对试图编写 Appium 或 Selenium 测试的人不是特别有用。 当您编写 Appium 测试时，您希望使用您熟悉的编程语言。 幸运的是，存在一组 [Appium 客户端库](../ecosystem/clients.md)[^1]，它们负责向 Appium 服务器发起HTTP 的请求。 它们为特定编程语言公开了一组“原生”命令，以便对测试作者来说，它就像您在编写 Python、JavaScript 或 Java。
+
+以下是使用 Appium 客户端在五种不同编程语言中实现相同的 Appium 命令集的示例（注意，这不是包含所有导入的工作示例代码；请参阅每个客户端库的设置和命令参考说明）：
+
+\=== "JavaScript (Webdriver.io)"
+
+````
+```js
+const element = await driver.$('//*[@text="Foo"]');
+await element.click();
+console.log(await element.getText())
+console.log(await driver.getPageSource())
+```
+````
+
+\=== "Java"
+
+````
+```java
+WebElement element = driver.findElement(By.Xpath("//*[@text='Foo']"))
+element.click()
+System.out.println(element.getText())
+System.out.println(driver.getPageSource())
+```
+````
+
+\=== "Python"
+
+````
+```py
+element = driver.find_element(by=By.XPATH, value='//*[@text="Foo"]')
+element.click()
+print(element.text)
+print(driver.page_source)
+```
+````
+
+\=== "Ruby"
+
+````
+```rb
+element = driver.find_element :xpath, '//*[@text="Foo"]'
+element.click
+puts element.text
+puts driver.page_source
+```
+````
+
+\=== "C#"
+
+````
+```dotnet
+AppiumElement element = driver.FindElement(MobileBy.AccessibilityId("Views"));   
+element.click();
+System.Console.WriteLine(element.Text);
+System.Console.WriteLine(driver.PageSource);
+```
+````
+
+尽管这些脚本使用不同的编程语言,但它们在底层做的事情是相同的:
+
+1. 调用 `Find Element`,使用 `using` 参数值为 `xpath`,以及 `value` 参数表达用于查找元素的 XPath 查询。 (如果你对这些术语感到困惑,可以参考 Appium 或 Selenium 的入门介绍)
+2. 使用在上一次调用中找到的元素 ID 调用 `Click Element`。
+3. 使用同一元素的 ID 调用 `Get Element Text`,并将其打印到控制台。
+4. 调用 `Get Page Source` 来检索页面/应用程序源代码并将其打印到控制台。
+
+在选择或使用客户端之前，需要记住的另一件事是每个客户端都是独立维护的。 仅仅因为某个功能在一个客户端中可用,并不意味着它在另一个客户端中也可用(尽管所有客户端至少支持标准的 W3C 协议以及任何常见的 Appium 扩展)。 仅仅因为一个客户端有一套很好的辅助函数，并不意味着另一个客户端也会有。 有些客户端更新非常频繁，而其他客户端则不然! 因此,在考虑选择一个库时，首要考虑的是你想使用的语言，第二个考虑因素是该库的功能完善程度和维护情况!
+
+要学习如何使用 Appium 客户端，请访问该客户端的主页以了解更多信息。 在许多情况下，特定语言的 Appium 客户端是在该语言的 _Selenium_ 客户端之上构建的，因此某些 Appium 客户端可能只记录 Appium 客户端在 Selenium 客户端基础上添加的功能。 也就是说，要获得完整的参考，你可能需要访问 Appium 客户端文档以及 Selenium 客户端文档。
+
+这就是你需要了解的关于 Appium 客户端的全部内容！ 前往 [客户端](../ecosystem/clients.md) 页面查看当前的客户端列表。
+
+[^1]: 这些库也被称为"客户端"、"客户端库"或"客户端绑定"。
+    它们的意思都是一样的!

package/src/resources/submodules/appium/packages/appium/docs/zh/intro/drivers.md

@@ -0,0 +1,101 @@
+---
+title: Appium 驱动程序介绍
+---
+
+正如[概览](./appium.md)所阐明的那样，"驱动程序"基本上是 Appium 对"我们如何支持多个不相关平台的自动化？"这一问题的答案。 在本文档中，我们将更详细地了解驱动程序的工作原理。 驱动程序工作的具体细节对你来说可能并不那么重要，除非你打算编写自己的驱动程序或为现有驱动程序做贡献（我们希望你这样做！）。
+
+了解更多驱动程序工作原理的主要好处是，了解典型的复杂性或典型的驱动程序架构将有助于你在测试中遇到问题时进行调试。
+
+## 接口实现
+
+在最基本的层面上，驱动程序只是扩展了 Appium 中包含的一个特殊类的 Node.js 类，这个类叫做 `BaseDriver`。 你可以用以下非常简单的几行代码就拥有一个非常接近"可工作"的驱动程序：
+
+```js
+import BaseDriver from '@appium/base-driver'
+
+class MyNewDriver extends BaseDriver {
+}
+```
+
+这个空驱动程序不会_做_任何事情，但你可以将它打包成一个 Node.js 模块，在模块的清单文件（`package.json`）中添加一些与 Appium 相关的字段，然后使用 `appium driver install` 安装它。
+
+因此，从技术角度来看，Appium 驱动程序只是一些继承自其他 Appium 代码的代码。 就是这样！ 现在，继承自 `BaseDriver` 实际上给了我们很多东西，因为 `BaseDriver` 本质上是整个 WebDriver 协议的封装。 所以驱动程序要做一些有用的事情，只需要_实现_名称与其 WebDriver 协议等效的 Node.js 方法。
+
+假设我想用这个空驱动程序做点什么；首先我必须决定要实现哪个 WebDriver 命令。 对于我们的例子，让我们选择[Navigate To](https://w3c.github.io/webdriver/#navigate-to) WebDriver 命令。 暂时不考虑当这个命令执行时我想让驱动程序_做_什么。 要告诉 Appium 驱动程序可以处理这个命令，我们所要做的就是在驱动程序类中定义一个像这样的方法：[^1]
+
+```js
+async setUrl(url) {
+    // do whatever we want here
+}
+```
+
+[^1]: 你可能会注意到 `setUrl` 看起来与 `Navigate To` 完全不同，那么我们怎么知道使用它而不是其他随机字符串呢？ 其实，Appium 的 WebDriver 协议到方法名的映射是在 `@appium/base-driver` 包中的一个特殊文件中定义的，叫做 [routes.js](https://github.com/appium/appium/blob/master/packages/base-driver/lib/protocol/routes.js)。
+    所以如果你正在编写驱动程序，这就是你要去找出要使用什么方法名和期望什么参数的地方。 或者你可以查看任何主要 Appium 驱动程序的源代码！
+
+就是这样！ 我们如何实际实现该命令完全取决于我们自己，并取决于我们想要支持的平台。 以下是针对不同平台的此命令的一些不同示例实现：
+
+- 浏览器：执行一些 JavaScript 来设置 `window.location.href`
+- iOS 应用：使用深度链接启动应用
+- Android 应用：使用深度链接启动应用
+- React 应用：加载特定路由
+- Unity：转到指定场景
+
+因此，你可以看到，不同平台上驱动程序实现相同 WebDriver 命令的方式可能存在很大差异。[^2] 然而，_相同_的是它们表达可以处理协议命令的方式。
+
+[^2]: 当然，我们希望保持语义尽可能相似，但在 iOS 的世界里，例如，通过深度链接（具有特殊应用特定方案的 URL）启动应用是我们最接近导航到 Web URL 的方式。
+
+我们之所以如此详细地讨论（顺便说一下，你不需要记住这些），是因为重要的是要强调一点，Appium 驱动程序本质上不是任何特定的东西，只是一些可以处理 WebDriver 协议命令的 JS 代码。 从那里去哪里取决于你，驱动程序作者！
+
+## 自动化映射
+
+但_通常_驱动程序作者想要做的是为给定的平台提供自动化行为，这些行为在语义上与浏览器的 WebDriver 规范实现非常相似。 当你想查找一个元素时，你应该得到一个 UI 元素的引用。 当你想点击或轻触该元素时，产生的行为应该与人点击或轻触该元素相同。 等等。
+
+因此，驱动程序作者面临的真正挑战不是如何使用 WebDriver 协议（因为 `BaseDriver` 为你封装了所有这些），而是如何在目标平台上实现实际的自动化。 每个驱动程序都依赖于自己的一套底层技术。 正如[概览](index.md)中提到的，iOS 驱动程序使用 Apple 的一项名为 [XCUITest](https://developer.apple.com/documentation/xctest/xcuielement) 的技术。 这些底层自动化技术通常都有自己专有或特殊的 API。 编写驱动程序就是将 WebDriver 协议映射到这个底层 API 的任务（有时是一组不同的底层 API——例如，UiAutomator2 驱动程序不仅依赖于 Google 的 [UiAutomator2](https://developer.android.com/training/testing/other-components/ui-automator) 技术，还依赖于只能通过 [ADB](https://developer.android.com/tools/adb) 获得的功能，以及只能通过辅助应用内的 Android SDK 获得的功能）。 将所有这些整合到一个单一、可用的 WebDriver 接口中，是驱动程序开发这项非常有用（但极具挑战性）的艺术！
+
+## 多层架构
+
+在实践中，这通常会导致相当复杂的架构。 让我们再次以 iOS 为例。
+XCUITest 框架（Appium 驱动程序使用的框架）期望调用它的代码用 Objective-C 或 Swift 编写。 此外，XCUITest 代码只能在由 Xcode（以及直接或间接的 Xcode 命令行工具）触发的特殊模式下运行。 换句话说，没有直接的方法从 Node.js 函数实现（如上面的 `setUrl()`）到 XCUITest API 调用。
+
+XCUITest 驱动程序作者所做的是将驱动程序分成两部分：一部分用 Node.js 编写（这部分被整合到 Appium 中并最初处理 WebDriver 命令），另一部分用 Objective-C 编写（这部分实际在 iOS 设备上运行并进行 XCUITest API 调用）。 这使得与 XCUITest 的接口成为可能，但引入了两部分之间协调的新问题。
+
+驱动程序作者本可以选择许多非常不同的策略来建模 Node.js 端和 Objective-C 端之间的通信，但最终决定使用……
+WebDriver 协议！ 没错，XCUITest 驱动程序的 Objective-C 端本身就是一个 WebDriver 实现，称为 [WebDriverAgent](https://github.com/appium/webdriveragent)。[^3]
+
+[^3]: 因此，理论上你可以将你的 WebDriver 客户端直接指向 WebDriverAgent 并完全绕过 Appium。 然而，这通常不方便，原因如下：
+
+- Appium XCUITest 驱动程序会为你构建和管理 WebDriverAgent，这可能很麻烦并涉及使用 Xcode。
+- XCUITest 驱动程序做的事情远不止 WebDriverAgent 所能做的，例如使用模拟器或设备、安装应用等。
+
+这个故事的寓意是，由于我们试图解决的问题的性质，驱动程序架构可能会变得相当复杂和多层。 这也意味着，如果你在特定测试中遇到问题，有时很难判断这一系列技术中的哪个环节出了问题。 再以 XCUITest 为例，我们同时使用以下一组技术：
+
+- 你的测试代码（使用其编程语言）- 由你拥有
+- Appium 客户端库 - 由 Appium 拥有
+- Selenium 客户端库 - 由 Selenium 拥有
+- 网络（本地或互联网）
+- Appium 服务器 - 由 Appium 拥有
+- Appium XCUITest 驱动程序 - 由 Appium 拥有
+- WebDriverAgent - 由 Appium 拥有
+- Xcode - 由 Apple 拥有
+- XCUITest - 由 Apple 拥有
+- iOS 本身 - 由 Apple 拥有
+- macOS（运行 Xcode 和 iOS 模拟器的地方）- 由 Apple 拥有
+
+这是一个相当深的技术栈！
+
+## 代理模式
+
+还有一个关于驱动程序的重要架构方面需要了解。 可以再次用 XCUITest 驱动程序来举例说明。 回想一下我们刚才讨论的 XCUITest 驱动程序的两个"部分"是如何都使用 WebDriver 协议的——Node.js 部分直接连接到 Appium 的 WebDriver 服务器，而 Objective-C 部分（WebDriverAgent）本身就是一个 WebDriver 实现。
+
+这为 Appium 在某些情况下走捷径开辟了可能性。
+让我们想象一下 XCUITest 驱动程序需要实现 `Click Element` 命令。 这个实现的内部代码看起来就像是获取适当的参数并构造一个到 WebDriverAgent 服务器的 HTTP 请求。 在这种情况下，我们基本上只是在重建客户端对 Appium 服务器的原始调用！[^4] 所以实际上没有必要编写一个函数来实现 `Click Element` 命令。 相反，XCUITest 驱动程序可以让 Appium 知道这个命令应该直接代理到其他 WebDriver 服务器。
+
+[^4]: 这不是_完全_相同的调用，因为 Appium 服务器和 WebDriverAgent 服务器会生成不同的会话 ID，但这些差异会被透明地处理。
+
+如果你不熟悉"代理"的概念，在这种情况下，它只是意味着 XCUITest 驱动程序根本不会参与处理该命令。 相反，它只会在协议级别被重新打包并转发到 WebDriverAgent，WebDriverAgent 的响应同样会直接传回客户端，而不会有任何 XCUITest 驱动程序代码看到或修改它。
+
+这种架构模式为选择在各处使用 WebDriver 协议而不是构建定制协议的驱动程序作者提供了一个很好的额外好处。 这也意味着 Appium 可以非常轻松地为任何其他现有的 WebDriver 实现创建包装驱动程序。 例如，如果你查看 [Appium Safari 驱动程序](https://github.com/appium/appium-safari-driver)代码，你会发现它基本上没有实现任何标准命令，因为所有这些命令都直接代理到底层的 SafariDriver 进程。
+
+了解这种代理机制有时在幕后发生是很重要的，因为如果你曾经深入研究一些开源驱动程序代码试图找出命令的实现位置，你可能会惊讶地发现 Node.js 驱动程序代码本身根本没有任何实现！ 在这种情况下，你需要找出命令被代理到哪里，以便你可以在那里查找相应的实现。
+
+好了，对于这个非常详细的驱动程序介绍来说，这就足够了！

package/src/resources/submodules/appium/packages/appium/docs/zh/intro/history.md

@@ -0,0 +1,72 @@
+---
+title: Appium 项目历史
+---
+
+Appium 自 2012 年以来以某种形式存在。 它由不同的个人和组织指导，甚至用 3 种不同的编程语言实现过！ 欢迎了解关于 Appium 如何发展到今天这个样子的更多信息……
+
+## 早期灵感
+
+[Dan Cuellar](https://twitter.com/thedancuellar) 在 2011 年担任 Zoosk 的测试经理时遇到了一个问题。 iOS 产品的测试通过时间变得越来越长，难以控制。 减少测试是一个选择，但会带来额外的风险，特别是在通过 iOS App Store 审核流程获得补丁需要几天时间的情况下。 他回想起自己在网站上工作的日子，意识到自动化是答案。
+
+Dan 调查了现有的工具格局，却发现它们都有重大缺陷。 Apple 提供的工具 UIAutomation 要求测试必须用 JavaScript 编写，并且不允许实时调试或解释。 它还必须在 Xcode 的性能分析工具 Instruments 中执行。 其他第三方工具使用私有 API，并要求将 SDK 和 HTTP 服务器嵌入到应用程序中。 这看起来非常不可取。
+
+对现有选项不满意，Dan 向他的经理要求一些额外的时间，看看他能否找到更好的方法。 他花了 2 周时间探索和试验，看看是否有办法使用 Apple 批准的技术来自动化 iOS 应用程序。 他尝试的第一个实现使用 AppleScript 通过 OS X 辅助功能 API 向 Mac UI 元素发送消息。 这在一定程度上有效，但永远无法在真实设备上工作，更不用说其他缺点了。
+
+所以他想，如果我能让 UIAutomation 框架像解释器一样实时运行会怎样？ 他研究了一下，确定他所需要做的就是找到一种方法在 UIAutomation JavaScript 程序中接收、执行和回复命令。 使用 Apple 提供的用于执行 shell 命令的实用程序，他能够 `cat` 顺序排列的文本文件来接收命令，`eval()` 输出以执行它们，并用 `python` 将它们写回磁盘。 然后他用 C# 准备了实现 Selenium 样式语法的代码来编写顺序排列的 JavaScript 命令。
+iOSAuto 诞生了。
+
+## 2012 年 Selenium 大会
+
+Dan 被选中在 2012 年伦敦 Selenium 大会上就一个完全不同的主题发表演讲。 作为他演讲的一部分，他展示了使用 Selenium 语法的 iOS 自动化，以演示编写平台无关的测试，这些测试使用具有通用接口的独立平台特定页面对象。 令他惊讶的是，酷炫的测试架构让 iOS 测试像 WebDriver 测试一样运行。 有几个人建议他稍后在会议上做一个闪电演讲来解释它是如何工作的。
+
+在会议的第二天，Dan 走上舞台做闪电演讲。  Jason Huggins，Selenium 的共同创建者，主持了闪电演讲。  Dan 在加载演示文稿时遇到了技术困难，Jason 几乎不得不继续下一个闪电演讲。  在最后一刻，屏幕亮了，Dan 开始了他的演讲。 他解释了他的实现细节和工作原理，恳求贡献者，五分钟后就结束了。 观众礼貌地鼓掌，他离开了舞台。
+
+## 电话响起
+
+Selenium 大会四个月后，Jason 打电话给 Dan。 Jason 一直在 Sauce Labs 为客户开发 iOS 测试支持。  Jason 记得 Dan 的闪电演讲，认为这个项目可能对 Jason 的工作有用，但 Dan 的源代码没有公开。 Jason 要求 Dan 见面。  那周晚些时候，Dan 在旧金山的一家酒吧见到了 Jason，并向他展示了 iOS Auto 的源代码。
+
+作为一个长期的开源倡导者，Jason 鼓励 Dan 在开源许可下发布他的代码。  8 月，Dan 在 GitHub 上发布了 [C# 的源代码](https://github.com/penguinho/appium-old/commit/3ab56d3a5601897b2790b5256351f9b5af3f9e90)。 Jason 鼓励 Dan 更改语言以使项目对潜在贡献者更具吸引力。 Dan 上传了 [Python 的新版本]](https://github.com/penguinho/appium-old/commit/9b891207be0957bf209a77242750da17d3eb8eda)。
+9 月，Jason 添加了一个 Web 服务器并开始通过 HTTP 实现 [WebDriver 协议](https://github.com/hugs/appium-old/commit/ae8fe4578640d9af9137d0546190fa29317d1499)，使 iOS Auto 可以从任何语言的任何 Selenium WebDriver 客户端库编写脚本。
+
+## 移动测试峰会
+
+Jason 决定该项目应该在 11 月的[移动测试峰会](https://twitter.com/mobtestsummit)上展示，但建议项目首先改个新名字。 人们提出了许多想法，他们最终选定了 AppleCart。 一天后，当 Jason 浏览 Apple 关于版权和商标的一些指导时，他注意到在 Apple 会保护其商标的名称示例部分下，第一个例子是"AppleCart"。 他打电话给 Dan 并告知了情况，他们集思广益了一会儿，然后 Jason 中了大奖。 Appium…… 应用程序的 Selenium。
+
+## Sauce Labs 和 Node.js
+
+2013 年 1 月，也就是移动测试峰会后不久，Sauce Labs 决定全力支持 Appium 并提供更多开发人员力量。 创建了一个工作组来评估当前状态以及如何最好地推进该项目。
+该团队包括 Jonathan Lipps（现任项目负责人），他们决定 Appium 需要重生，并最终选择 Node.js 作为使用的框架。 Node 以快速高效的 Web 服务器后端而闻名，而归根结底，Appium 只是一个高度专业化的 Web 服务器。 还决定将 JavaScript 作为一种语言足够易于访问，使得 Appium 能够发展成为一个比其他选项更大的开源开发者社区。
+
+仅仅几天之内，团队就利用 Appium 的现有工作，创建了一个与之前 Python 版本功能相当的新版本 Appium。 为 Appium 的基本架构奠定了基础，从那时起我们一直在成功地构建它。 在这次冲刺开始几周后，Jonathan Lipps 被正式指定为项目负责人，他开始制定战略，如何让更多来自社区的人参与 Appium 的开发。
+
+## Appium 走向世界
+
+最终，Jonathan 决定在会议和聚会上让尽可能多的开发者了解 Appium 是吸引用户和贡献的最佳方式。
+Appium 的新版本在 [2013 年谷歌测试自动化大会](https://www.youtube.com/watch?v=1J0aXDbjiUE)上首次亮相。 2013 年晚些时候，Appium 在美国各地以及英国、波兰、葡萄牙和澳大利亚的会议和聚会上展示。 值得注意的是，Jonathan 让 Appium [作为乐队中的乐器表演](https://www.youtube.com/watch?v=zsbNVkayYRQ)，Dan Cuellar 为 Selenium 大会制作了一个有趣的 [Appium 视频集锦](https://www.youtube.com/watch?v=xkzrEn0v0II)。
+
+在所有这些演讲和会议期间，项目继续发展。 2013 年初，我们发布了 Android 和 Selendroid 支持，使 Appium 成为第一个真正的跨平台自动化框架。 该项目还继续吸引用户和贡献者，到 2013 年底，我们已经有超过 1,000 次提交。
+
+## 通往 Appium 1.0 之路
+
+Appium 开始显著增长和成熟。 2014 年 5 月，我们发布了 Appium 1.0，这是 Appium 发展的一个里程碑。
+Appium 获得了[各种](https://www.prnewswire.com/news-releases/black-duck-announces-black-duck-open-source-rookies-of-the-year-winners-242383341.html)[奖项](https://www.infoworld.com/article/2241247/164642-bossie-awards-2014-the-best-open-source-application-development-tools.html)，并成为最受欢迎的开源跨平台移动自动化框架。 稳定性得到改善，错误得到优先处理和修复，功能得到添加。 Sauce Labs 增加了捐赠给 Appium 工作的开发者数量，但整个社区继续参与指导项目并为其做出贡献，项目治理继续在公开的邮件列表和 GitHub 的问题跟踪器上进行。
+
+## Appium 扩大
+
+最终，很明显 Appium 代码库没有针对大型分布式团队的兼职贡献者进行优化。 作为提交者团队，我们借此机会从头开始重写 Appium，使用更现代的 JavaScript 语言版本，并重做 Appium 的架构，使用户或第三方开发者可以轻松构建自己的 Appium"驱动程序"。 我们希望新贡献者更容易熟悉 Appium 代码库，并看到核心团队以外的团队为 Appium 添加对新平台的支持。 这一愿景已经开始实现，微软和 Youi.tv 等团体分别为 Windows 桌面应用程序自动化和 Youi.tv 应用程序自动化向 Appium 添加了驱动程序。
+
+## Appium 献给人民
+
+2016 年底，Sauce Labs 将 Appium 作为一个项目捐赠给 [JS 基金会](https://js.foundation)，以便向世界证明 Sauce 承诺 Appium 保持开源。 JS 基金会是一个非营利性开源管理组织，负责持有开源项目的版权，并确保它们在社区中拥有长久和成功的任期。 由于我们转移到非营利基金会，我们希望新贡献者的大门会更加敞开，无论是作为个人还是代表现在对 Appium 前进有兴趣的众多公司之一。
+
+最终，JS 基金会并入了 [OpenJS 基金会](https://openjsf.org)，Appium 成为该基金会的影响力项目。
+
+## Appium 2.0
+
+Appium 2 于 2023 年发布，引入了一个全新的架构，将重点从一体化项目转移到作为生态系统的 Appium。 这为任何人开发和共享自己的 Appium 扩展（驱动程序和插件）开辟了可能性，为远超 iOS 和 Android 的平台的自动化相关开发打开了一个充满可能性的世界！ 因此，创建了许多第三方扩展，例如用于 Flutter 和 Windows 的新驱动程序、用于模拟 API 和管理设备农场的插件、基于 Rust 和 Swift 的新 Appium 客户端等等。
+
+大约在这个时候，我们还启动了 Appium 的赞助计划，吸引了各种大小赞助商。 这使我们能够回馈 Appium 社区，为贡献者在项目上的志愿工作提供补偿。
+
+## Appium 3.0
+
+2025 年看到了 Appium 3 的发布。 这次更新比 Appium 2 小得多，只包括一些行为变化，而是专注于删除已弃用的代码并更新对更现代生态系统的兼容性。 尽管如此，这种缩小的范围也是意料之中的：自 Appium 2 以来，主要功能开发工作已转移到各个驱动程序和插件，其中许多在 Appium 2 时代经历了多次重大更新。

package/src/resources/submodules/appium/packages/appium/docs/zh/intro/index.md

@@ -0,0 +1,36 @@
+---
+hide:
+  - toc
+
+title: Appium 概览
+---
+
+如主页所述，Appium 旨在支持_多个不同平台_（移动端、Web、桌面等）的 UI 自动化。 不仅如此，它还旨在支持用_不同语言_（JS、Java、Python 等）编写的自动化代码。 将所有这些功能整合到一个程序中是一项非常艰巨的任务，甚至可以说是不可能完成的任务！
+
+为了实现这一目标，Appium 实际上被分为四个部分：
+
+<div class="grid cards" markdown>
+
+- :material-image-filter-center-focus-strong: **Appium 核心** - 定义核心 API
+- :material-car: **驱动程序** - 实现与特定平台的连接
+- :octicons-code-16: **客户端库** - 用特定语言实现 Appium 的 API
+- :fontawesome-solid-plug: **插件** - 改变或扩展 Appium 的核心功能
+
+</div>
+
+因此，要开始使用 Appium 进行自动化，你需要：
+
+- 安装 Appium 本身
+- 为你的目标平台安装驱动程序
+- 为你的目标编程语言安装客户端库
+- （可选）安装一个或多个插件
+
+这些就是基础知识！ 如果你已经准备好开始，请继续阅读[快速入门](../quickstart/index.md)！
+
+如果你想了解更多关于其工作原理的详细信息，请参阅以下页面的背景材料：
+
+- [Appium 核心](./appium.md)
+- [Appium 驱动程序](./drivers.md)
+- [Appium 客户端](./clients.md)
+
+最后，要了解 Appium 的起源，请查看 [Appium 项目历史](./history.md)。

package/src/resources/submodules/appium/packages/appium/docs/zh/quickstart/index.md

@@ -0,0 +1,23 @@
+---
+hide:
+  - toc
+
+title: 入门指南
+---
+
+让我们开始使用Appium！ 为了成功使用此快速入门，建议您首先阅读[介绍](../intro/index.md)，以便了解运行Appium和编写Appium脚本的概念。
+
+此快速入门的基本计划如下：
+
+1. 安装Appium
+2. 安装Appium驱动程序及其依赖项
+   - 本指南提供了[UiAutomator2 驱动程序](https://github.com/appium/appium-uiautomator2-driver) 的说明
+3. 在您选择的语言中安装Appium客户端库
+   - 本指南包含JavaScript、Python、Java、Ruby和.NET的选项
+4. 使用示例应用程序编写并运行简单的Appium自动化脚本
+
+### 系统需求
+
+在开始之前，请确保您的系统满足运行Appium服务器的[要求](../quickstart/requirements.md)。 其他要求将在安装UiAutomator2驱动程序时讨论。 本指南还假设您在平台上具有基本的命令行熟练度，例如能够运行命令、设置和持久化环境变量等...
+
+现在您准备开始了！ 前往安装[Appium](./install.md)。

package/src/resources/submodules/appium/packages/appium/docs/zh/quickstart/install.md

@@ -0,0 +1,47 @@
+---
+hide:
+  - toc
+
+title: 安装Appium
+---
+
+!!! 信息
+
+```
+安装前，请确保检查 [系统要求] (./requirements.md)。
+```
+
+Appium 可以使用 "npm" 在全局安装：
+
+```bash
+npm install -g appium
+```
+
+!!! 备注
+
+```
+目前不支持其他软件包管理。
+```
+
+## 启动Appium
+
+Appium 可以使用 [命令行](../reference/cli/index.md) 启动：
+
+```
+appium
+```
+
+这会启动Appium服务器进程，该进程加载所有已安装的Appium驱动程序，并开始等待来自客户端连接（如测试自动化脚本）的新会话请求。
+由于服务器进程独立于其客户端，因此必须在尝试启动新会话之前明确启动它。
+
+当服务器启动时，控制台日志将列出客户端可以用来连接到此服务器的所有有效URL：
+
+```
+[Appium] You can provide the following URLs in your client code to connect to this server:
+[Appium] 	http://127.0.0.1:4723/ (only accessible from the same host)
+(... any other URLs ...)
+```
+
+一旦客户端请求新会话，Appium服务器进程将开始记录此会话的所有详细信息，直到其终止。 请记住这一点——如果您遇到Appium测试的问题，您可以随时检查服务器日志以获取更多详细信息。
+
+接下来是什么？ 即使Appium已安装并运行，它也不捆绑任何驱动程序，这意味着它还不能自动化任何东西。 因此，我们将为Android设置自动化——继续[安装UiAutomator2驱动程序](./uiauto2-driver.md)。

package/src/resources/submodules/appium/packages/appium/docs/zh/quickstart/next-steps.md

@@ -0,0 +1,19 @@
+---
+hide:
+  - toc
+
+title: 下一步
+---
+
+现在您已成功为Android自动化设置了系统并运行了一个简单的测试，您将希望继续探索此文档。 特别是，这些是适合初学者的优秀指南和参考资料： 特别是，这些是适合初学者的优秀指南和参考资料：
+
+- [生态系统](../ecosystem/index.md) 页面：浏览可用的驱动程序、客户端、插件和工具
+- [管理Appium驱动程序和插件](../guides/managing-exts.md)
+- [功能](../guides/caps.md)
+- [设置](../guides/settings.md)
+
+您还会发现[Appium Inspector](https://github.com/appium/appium-inspector)是编写Appium测试不可或缺的工具，因为它允许对应用进行视觉检查，并帮助您发现测试脚本中使用的元素定位器。
+
+您还可以利用众多可用的在线Appium课程之一。
+
+祝您好运，玩得开心！

package/src/resources/submodules/appium/packages/appium/docs/zh/quickstart/requirements.md

@@ -0,0 +1,21 @@
+---
+hide:
+  - toc
+
+title: 系统要求
+---
+
+Appium 服务器的基本要求如下：
+
+- macOS、Linux 或 Windows 操作系统
+- [Node.js](https://nodejs.org) 版本在 [SemVer](https://semver.org) 范围 `^20.19.0 || ^22.12.0 || >=24.0.0`
+  - 推荐使用 LTS 版本
+- [`npm`](https://npmjs.com) 版本 `>=10`（`npm` 通常与 Node.js 捆绑，但可以独立升级）
+
+Appium 本身相对轻量，没有显著的磁盘空间或 RAM 要求。 即使在资源受限的环境如 Raspberry Pi 中，只要有 Node.js 就可以运行。
+
+### 驱动程序要求
+
+用于自动化特定平台的驱动程序可能有其他要求。 请参考该平台的 [Appium 驱动程序](../ecosystem/drivers.md) 文档以获取其他依赖项。 普遍的情况是，给定平台的 Appium 驱动程序需要安装该平台的开发者工具链和 SDK。
+
+为了帮助处理驱动程序要求，每个（官方）驱动程序都附带 Appium Doctor 工具，它允许验证是否已设置所有要求。 了解如何使用此工具的更多信息，请参阅 [命令行使用文档](../reference/cli/extensions.md#doctor)。