FTR（Functional Test Runner）是 Kibana 的旧版端到端功能测试框架，测试基于 mocha 的 describe/it 并使用 @kbn/expect，由配置文件驱动 Kibana 与 Elasticsearch 服务器、服务、页面对象和安全角色。
用途：维护现有 FTR 测试并规划迁移。每个测试文件导出接收 FtrProviderContext 的 provider 函数，可用 getService、getPageObjects、loadTestFile。
配置：定义 testFiles、kbnTestServer.serverArgs、esTestCluster.serverArgs、security.roles、services、pageObjects、apps、suiteTags、uiSettings、screenshots 等；常通过 readConfigFile 继承基础配置，典型链为叶子配置 > 解决方案基础 > 平台基础 > @kbn/test-suites-src 基础。
核心服务：testSubjects（按 data-test-subj 交互）、find、browser、retry、esArchiver、kibanaServer、es、supertest、security、deployment。由于缺少自动等待，retry.try、retry.waitFor、retry.tryForTime 被大量使用。页面对象封装页面交互，经 getPageObjects 获取。
数据加载：esArchiver 加载/卸载 ES 索引归档（mappings.json 与 data.json.gz），kibanaServer.importExport 加载/卸载已保存对象，uiSettings.replace 会清空后设置、update 为合并。
标签与 CI：this.tags 与 suiteTags.include/exclude 控制运行环境；配置须列入 .buildkite/ftr-manifests/ftr_*_configs.yml 才会在 CI 运行。
本地运行：node scripts/functional_tests --config <path>；也可分别用 functional_tests_server 与 functional_test_runner，后者支持 --grep。
限制与陷阱：同一 describe 内 it 共享浏览器状态并依赖执行顺序；索引文件的共享 before/after 会作用于所有加载套件；配置继承链可能带来意外；existOrFail 实为断言；retry.try 可能掩盖不稳定；UI 式准备较慢且脆弱，建议用 API 准备；归档路径相对 esArchiver.baseDirectory 解析；标签仅在配置排除时生效。