尧图网站建设 
gRPC 测试与构建工具链完全指南从 run_tests 到跨语言互操作与性能基准【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc本指南系统讲解 gRPCC 核心仓库中 tools/run_tests 目录下的测试与构建工具链以 Python 脚本作为统一入口实现跨平台一致的构建、单元测试、跨语言互操作测试、性能基准测试与制品打包任务。读完本文你将掌握run_tests.py、run_interop_tests.py、run_performance_tests.py与task_runner.py四类脚本的核心用法、关键参数语义以及它们与仓库内源码、测试描述文档之间的对应关系。Overview为什么用 Python 脚本作为测试入口tools/run_tests/README.md开篇即点明了设计动机该目录包含一系列用于构建并运行测试的脚本而所有测试都以 Python 脚本作为入口其好处是无论你使用何种平台Linux/macOS/Windows都能用同一条命令行完成测试任务。这避免了为每个平台编写一套 shell 脚本的维护成本。从源码看这个约定在 run_tests.py 中体现为脚本启动后立即将工作目录切换到仓库根目录_ROOT os.path.abspath(os.path.join(os.path.dirname(sys.argv[0]), ../..)) os.chdir(_ROOT)因此所有命令都应当从 gRPC 仓库根目录执行脚本内部路径均以仓库根为基准。Unit testsrun_tests.py构建并运行单元测试基本用法与示例run_tests.py 负责「构建指定语言的 gRPC 并运行单元测试」。README 给出的标准示例是tools/run_tests/run_tests.py -l python -c dbg含义为针对python语言以dbgdebug构建配置编译 gRPC 并运行其单元测试。运行tools/run_tests/run_tests.py --help可查看全部参数说明。两个高频选项--use_docker构建一个包含指定语言全部依赖prerequisites的 Docker 容器并在该容器内运行测试提供环境隔离避免污染宿主机--build_only只执行构建不运行测试适合快速验证编译结果或为后续测试预热产物。从源码看支持的构建配置与语言脚本内部通过_CONFIGS字典定义了可用的构建配置命令行用-c/--config选择默认optargp.add_argument( -c, --config, choicessorted(_CONFIGS.keys()), defaultopt )_LANGUAGES字典则列出了脚本支持的语言run_tests.py从中可以看到它不仅支持运行时语言还支持静态检查任务c/cC 核心库与 C 封装php8、python、ruby、csharp、objcsanity基于sanity_tests.yaml的仓库一致性检查clang-tidy基于clang_tidy_tests.yaml的静态代码分析。_MSBUILD_CONFIGrun_tests.py将dbg/opt/gcov映射到 MSBuild 的 Debug/Release 配置说明在 Windows 平台上同样能通过统一的命令行参数驱动构建。更多实用参数源自源码解析在 run_tests.py 起的 argparse 定义中还包含以下常用选项-n/--runs_per_test每个测试运行次数默认1可设为inf使所有测试无限循环运行与-f聚焦特定测试配合可用于排查偶发失败-r/--regex与--regex_exclude按正则表达式筛选/排除要运行的测试-j/--jobs并行任务数默认取multiprocessing.cpu_count()-p/--sample_percent只随机运行指定百分比的测试如50.0用于快速抽样验证-S/--stop_on_failure遇到失败立即停止--arch指定default/x86/x64/arm64架构--compiler选择编译器default/gcc/clang/...--iomgr_platform选择native/gevent/asyncioI/O 平台Python 异步场景常用-x/--xml_report输出 JUnit 兼容 XML 报告--report_suite_name与--report_multi_target可定制报告格式--max_time设定整体测试运行的最长时间秒--bq_result_table将结果上传至 BigQuery 结果表便于跨版本追踪回归。关于并行度run_tests.py 还做了平台差异化限制Windows 上最多并行 64 个任务其余平台最多 1024防止过度并行导致资源耗尽。使用注意缺少 Python 模块若报错ImportError: No module named httplib2之类说明缺少某些 Python 依赖按报错信息安装对应模块后重试即可测试可能偶发失败flakyREADME 提示部分测试存在 flaky 现象可参考仓库 Issues 中已知的 flakes脚本也提供了--allow_flakes选项允许对失败测试自动重跑重试最多 5 次后仍失败才判定失败耗时完整单元测试套件通常需要数分钟以上请预留足够时间。Interop testsrun_interop_tests.py跨语言互操作测试功能定位run_interop_tests.py 用于运行跨平台、跨语言的互操作测试验证不同语言实现C、Python、Java、Go、C#、Node 等之间的 gRPC 协议兼容性。互操作测试的具体场景与用例语义由 doc/interop-test-descriptions.md 定义测试脚本与描述文档一一对应。README 特别说明该脚本还支持针对 grpc-java 与 grpc-go 运行互操作测试前提是这两个仓库的源码已 checkout 到 grpc 仓库旁边即作为同级目录存在。标准示例README 给出的示例原文注释为 C# 客户端 C 服务器tools/run_tests/run_interop_tests.py -l python -s c --use_docker参数语义-l/--language要运行的客户端语言可多个默认all注意 README 注释中的 C# 与命令中 python 的差异实际以命令行参数为准-s/--server服务器语言可让服务器在独立 Docker 镜像中自动启动--use_docker所有互操作测试在 Docker 下运行提供隔离并免去安装依赖。关键参数源自源码在 run_interop_tests.py 附近的 argparse 定义中--override_server以servernameHOST:PORT形式显式指定外部服务器例如csharplocalhost:50000--cloud_to_prod/--cloud_to_prod_auth运行面向 gRPC 生产环境的云端测试--prod_servers选择云端生产服务器默认default--service_account_key_file/--default_service_account部分 auth 互操作测试所需的 GCE 服务账号凭据-t/--travis、-v/--verboseCI 友好输出与详细日志--manual_run手动运行模式。脚本默认服务器端口为_DEFAULT_SERVER_PORT 8080run_interop_tests.py并对压缩相关用例做了平台跳过处理_SKIP_COMPRESSION见第 47-57 行——某些语言实现不支持压缩流时自动跳过对应用例避免误报失败。常见问题README 提示使用 Docker 运行互操作测试时若出现no space left on device说明 Docker 镜像文件所在磁盘空间不足请将 Docker 数据目录迁移到有足够空间的路径。Performance benchmarksrun_performance_tests.py与基准测试框架现状脚本已废弃README 明确说明tools/run_tests/run_performance_tests.py已弃用deprecated请参阅 tools/run_tests/performance/README.md 获取最新方案。该文档提供了两条路径推荐使用 gRPC OSS benchmarks 框架基于 GKE 的 LoadTest 体系CI 脚本见 tools/internal_ci/linux/grpc_e2e_performance_gke.sh专家手动方式本地/远程手工启动 driver 与 worker 进行低层实验。场景生成与统计performance/scenario_config_exporter.py 可将基准场景导出为文件并统计。连续运行通常使用scalable类别例如$ ./tools/run_tests/performance/scenario_config_exporter.py --count_scenarios --categoryscalable输出会按语言列出 C、python_asyncio、java、go、node、csharp、dotnet、python、ruby、php8 等客户端/服务器组合的场景数量。跨语言场景中客户端或服务器语言与场景语言不一致时才单独标注。LoadTest 配置生成performance/loadtest_config.py 基于模板生成 multipart YAML 格式的 LoadTest 配置每个配置内嵌一个场景核心参数包括-l/--language基准测试语言可重复-t/--template模板文件须包含场景所需语言的 client/server-s/--substitution形如keyvalue的替换键如client_poolworkers-8core、big_query_table...、timeout_seconds3600-p/--prefix与-u/--uniquifier_element控制测试名称的唯一性名称由 prefix、uuid、日期与运行序号拼接--category场景类别默认allCI 常用scalable--allow_client_language/--allow_server_language允许跨语言场景中的客户端/服务器语言典型为c--instances_per_client每个测试生成多个客户端实例--runs_per_test每个测试重复运行 n 次-o/--output输出文件默认流式输出到 stdout。生成后的配置可通过kubectl apply -f loadtest_config.yaml提交到运行 LoadTest controller 的集群。生成的每个 LoadTest 会带language、prefix标签以及scenario、uniquifier注解便于按前缀选择本次运行产生的资源。辅助脚本还包括合并多个 YAML 的 loadtest_concat_yaml.py、生成示例配置的 loadtest_examples.sh、以及从既有配置生成模板的 loadtest_template.py其--inject_client_pool、--inject_big_query_table、--inject_timeout_seconds等选项可将关键字段替换为${key}以便复用模板。手动基准测试专家方式如需底层实验例如对服务器做 profiling可在本地按以下步骤进行运行仓库根下的 linux_performance_worker_init.sh 完成 worker 机器初始化performance/README.md 中列出的前置条件对 C-core 封装语言C、Python、C#、Node、Ruby从仓库根执行$ tools/run_tests/performance/build_performance.sh $ tools/run_tests/performance/run_worker_language.sh每种语言对应一个run_worker_*.sh脚本如 run_worker_csharp.sh、run_worker_python_asyncio.sh 3. 通过QPS_WORKERS环境变量指定逗号分隔的host:port列表drivertest/cpp/qps/qps_json_driver.cc会把列表中的前num_servers个作为 benchmark server其余作为客户端$ export QPS_WORKERShost1:10000,host2:10000,host3:10000 $ bins/opt/qps_json_driver --scenario_jsonscenario_config场景 JSON 由 scenario_config.py 生成。另有QPS_WORKER_CHANNEL_CONNECT_TIMEOUT秒整数可配置客户端等待 benchmark server 就绪的超时时间——若服务器启动较慢建议同时调大场景配置中的warmup_seconds。Artifacts Packagestask_runner.py按标签执行构建/分发任务功能定位tools/run_tests/task_runner.py 是一个基于标签label的通用任务框架仓库用其构建二进制制品artifacts与分发包distrib packages并对其进行测试。从源码看任务集合来自三个模块task_runner.py_TARGETS [] _TARGETS artifact_targets.targets() # 二进制制品 _TARGETS distribtest_targets.targets() # 分发包测试 _TARGETS package_targets.targets() # 包构建_create_build_map()第 33-50 行同时建立「任务名 → 任务」与「标签 → 任务」两张映射且要求任务名与标签名互不冲突从而支持通过任务名或任意标签选择任务。示例与参数README 给出的示例tools/run_tests/task_runner.py -f python artifact linux x64该命令会选择带python、artifact、linux、x64全部标签的任务执行。常用参数源自 task_runner.py-b/--build任务名或标签可多个默认all指定要执行的目标-f/--filter以 AND 语义过滤——目标必须同时具备所有指定标签-e/--exclude排除具备任一指定标签的目标-j/--jobs并行任务数-x/--xml_reportJUnit 兼容 XML 报告文件名默认report_taskrunner_sponge_log.xml--dry_run只打印将要执行的命令而不真正执行便于调试任务选择逻辑--inner_jobs透传给每个目标内部的并行构建任务数。这种「标签驱动」设计非常适合 CI把同一批任务用linux、x64、artifact等标签打散配合-f/-e即可灵活编排发布流水线而无需改动任务定义本身。小结tools/run_tests是 gRPC 仓库测试与发布体系的统一入口脚本用途典型命令run_tests.py构建并运行单元测试tools/run_tests/run_tests.py -l python -c dbgrun_interop_tests.py跨语言互操作测试tools/run_tests/run_interop_tests.py -l python -s c --use_dockerrun_performance_tests.py性能基准已弃用见 performance/README.md—task_runner.py按标签执行制品构建与分发测试tools/run_tests/task_runner.py -f python artifact linux x64全部命令均以 Python 为入口、从仓库根目录执行保证跨平台一致性互操作测试的场景语义可对照 doc/interop-test-descriptions.md 深入阅读性能基准的最新方案则统一收敛到 tools/run_tests/performance 下的 GKE 框架文档中。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gRPC 测试与构建工具链完全指南：从 run_tests 到跨语言互操作与性能基准
gRPC 测试与构建工具链完全指南从 run_tests 到跨语言互操作与性能基准【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc本指南系统讲解 gRPCC 核心仓库中 tools/run_tests 目录下的测试与构建工具链以 Python 脚本作为统一入口实现跨平台一致的构建、单元测试、跨语言互操作测试、性能基准测试与制品打包任务。读完本文你将掌握run_tests.py、run_interop_tests.py、run_performance_tests.py与task_runner.py四类脚本的核心用法、关键参数语义以及它们与仓库内源码、测试描述文档之间的对应关系。Overview为什么用 Python 脚本作为测试入口tools/run_tests/README.md开篇即点明了设计动机该目录包含一系列用于构建并运行测试的脚本而所有测试都以 Python 脚本作为入口其好处是无论你使用何种平台Linux/macOS/Windows都能用同一条命令行完成测试任务。这避免了为每个平台编写一套 shell 脚本的维护成本。从源码看这个约定在 run_tests.py 中体现为脚本启动后立即将工作目录切换到仓库根目录_ROOT os.path.abspath(os.path.join(os.path.dirname(sys.argv[0]), ../..)) os.chdir(_ROOT)因此所有命令都应当从 gRPC 仓库根目录执行脚本内部路径均以仓库根为基准。Unit testsrun_tests.py构建并运行单元测试基本用法与示例run_tests.py 负责「构建指定语言的 gRPC 并运行单元测试」。README 给出的标准示例是tools/run_tests/run_tests.py -l python -c dbg含义为针对python语言以dbgdebug构建配置编译 gRPC 并运行其单元测试。运行tools/run_tests/run_tests.py --help可查看全部参数说明。两个高频选项--use_docker构建一个包含指定语言全部依赖prerequisites的 Docker 容器并在该容器内运行测试提供环境隔离避免污染宿主机--build_only只执行构建不运行测试适合快速验证编译结果或为后续测试预热产物。从源码看支持的构建配置与语言脚本内部通过_CONFIGS字典定义了可用的构建配置命令行用-c/--config选择默认optargp.add_argument( -c, --config, choicessorted(_CONFIGS.keys()), defaultopt )_LANGUAGES字典则列出了脚本支持的语言run_tests.py从中可以看到它不仅支持运行时语言还支持静态检查任务c/cC 核心库与 C 封装php8、python、ruby、csharp、objcsanity基于sanity_tests.yaml的仓库一致性检查clang-tidy基于clang_tidy_tests.yaml的静态代码分析。_MSBUILD_CONFIGrun_tests.py将dbg/opt/gcov映射到 MSBuild 的 Debug/Release 配置说明在 Windows 平台上同样能通过统一的命令行参数驱动构建。更多实用参数源自源码解析在 run_tests.py 起的 argparse 定义中还包含以下常用选项-n/--runs_per_test每个测试运行次数默认1可设为inf使所有测试无限循环运行与-f聚焦特定测试配合可用于排查偶发失败-r/--regex与--regex_exclude按正则表达式筛选/排除要运行的测试-j/--jobs并行任务数默认取multiprocessing.cpu_count()-p/--sample_percent只随机运行指定百分比的测试如50.0用于快速抽样验证-S/--stop_on_failure遇到失败立即停止--arch指定default/x86/x64/arm64架构--compiler选择编译器default/gcc/clang/...--iomgr_platform选择native/gevent/asyncioI/O 平台Python 异步场景常用-x/--xml_report输出 JUnit 兼容 XML 报告--report_suite_name与--report_multi_target可定制报告格式--max_time设定整体测试运行的最长时间秒--bq_result_table将结果上传至 BigQuery 结果表便于跨版本追踪回归。关于并行度run_tests.py 还做了平台差异化限制Windows 上最多并行 64 个任务其余平台最多 1024防止过度并行导致资源耗尽。使用注意缺少 Python 模块若报错ImportError: No module named httplib2之类说明缺少某些 Python 依赖按报错信息安装对应模块后重试即可测试可能偶发失败flakyREADME 提示部分测试存在 flaky 现象可参考仓库 Issues 中已知的 flakes脚本也提供了--allow_flakes选项允许对失败测试自动重跑重试最多 5 次后仍失败才判定失败耗时完整单元测试套件通常需要数分钟以上请预留足够时间。Interop testsrun_interop_tests.py跨语言互操作测试功能定位run_interop_tests.py 用于运行跨平台、跨语言的互操作测试验证不同语言实现C、Python、Java、Go、C#、Node 等之间的 gRPC 协议兼容性。互操作测试的具体场景与用例语义由 doc/interop-test-descriptions.md 定义测试脚本与描述文档一一对应。README 特别说明该脚本还支持针对 grpc-java 与 grpc-go 运行互操作测试前提是这两个仓库的源码已 checkout 到 grpc 仓库旁边即作为同级目录存在。标准示例README 给出的示例原文注释为 C# 客户端 C 服务器tools/run_tests/run_interop_tests.py -l python -s c --use_docker参数语义-l/--language要运行的客户端语言可多个默认all注意 README 注释中的 C# 与命令中 python 的差异实际以命令行参数为准-s/--server服务器语言可让服务器在独立 Docker 镜像中自动启动--use_docker所有互操作测试在 Docker 下运行提供隔离并免去安装依赖。关键参数源自源码在 run_interop_tests.py 附近的 argparse 定义中--override_server以servernameHOST:PORT形式显式指定外部服务器例如csharplocalhost:50000--cloud_to_prod/--cloud_to_prod_auth运行面向 gRPC 生产环境的云端测试--prod_servers选择云端生产服务器默认default--service_account_key_file/--default_service_account部分 auth 互操作测试所需的 GCE 服务账号凭据-t/--travis、-v/--verboseCI 友好输出与详细日志--manual_run手动运行模式。脚本默认服务器端口为_DEFAULT_SERVER_PORT 8080run_interop_tests.py并对压缩相关用例做了平台跳过处理_SKIP_COMPRESSION见第 47-57 行——某些语言实现不支持压缩流时自动跳过对应用例避免误报失败。常见问题README 提示使用 Docker 运行互操作测试时若出现no space left on device说明 Docker 镜像文件所在磁盘空间不足请将 Docker 数据目录迁移到有足够空间的路径。Performance benchmarksrun_performance_tests.py与基准测试框架现状脚本已废弃README 明确说明tools/run_tests/run_performance_tests.py已弃用deprecated请参阅 tools/run_tests/performance/README.md 获取最新方案。该文档提供了两条路径推荐使用 gRPC OSS benchmarks 框架基于 GKE 的 LoadTest 体系CI 脚本见 tools/internal_ci/linux/grpc_e2e_performance_gke.sh专家手动方式本地/远程手工启动 driver 与 worker 进行低层实验。场景生成与统计performance/scenario_config_exporter.py 可将基准场景导出为文件并统计。连续运行通常使用scalable类别例如$ ./tools/run_tests/performance/scenario_config_exporter.py --count_scenarios --categoryscalable输出会按语言列出 C、python_asyncio、java、go、node、csharp、dotnet、python、ruby、php8 等客户端/服务器组合的场景数量。跨语言场景中客户端或服务器语言与场景语言不一致时才单独标注。LoadTest 配置生成performance/loadtest_config.py 基于模板生成 multipart YAML 格式的 LoadTest 配置每个配置内嵌一个场景核心参数包括-l/--language基准测试语言可重复-t/--template模板文件须包含场景所需语言的 client/server-s/--substitution形如keyvalue的替换键如client_poolworkers-8core、big_query_table...、timeout_seconds3600-p/--prefix与-u/--uniquifier_element控制测试名称的唯一性名称由 prefix、uuid、日期与运行序号拼接--category场景类别默认allCI 常用scalable--allow_client_language/--allow_server_language允许跨语言场景中的客户端/服务器语言典型为c--instances_per_client每个测试生成多个客户端实例--runs_per_test每个测试重复运行 n 次-o/--output输出文件默认流式输出到 stdout。生成后的配置可通过kubectl apply -f loadtest_config.yaml提交到运行 LoadTest controller 的集群。生成的每个 LoadTest 会带language、prefix标签以及scenario、uniquifier注解便于按前缀选择本次运行产生的资源。辅助脚本还包括合并多个 YAML 的 loadtest_concat_yaml.py、生成示例配置的 loadtest_examples.sh、以及从既有配置生成模板的 loadtest_template.py其--inject_client_pool、--inject_big_query_table、--inject_timeout_seconds等选项可将关键字段替换为${key}以便复用模板。手动基准测试专家方式如需底层实验例如对服务器做 profiling可在本地按以下步骤进行运行仓库根下的 linux_performance_worker_init.sh 完成 worker 机器初始化performance/README.md 中列出的前置条件对 C-core 封装语言C、Python、C#、Node、Ruby从仓库根执行$ tools/run_tests/performance/build_performance.sh $ tools/run_tests/performance/run_worker_language.sh每种语言对应一个run_worker_*.sh脚本如 run_worker_csharp.sh、run_worker_python_asyncio.sh 3. 通过QPS_WORKERS环境变量指定逗号分隔的host:port列表drivertest/cpp/qps/qps_json_driver.cc会把列表中的前num_servers个作为 benchmark server其余作为客户端$ export QPS_WORKERShost1:10000,host2:10000,host3:10000 $ bins/opt/qps_json_driver --scenario_jsonscenario_config场景 JSON 由 scenario_config.py 生成。另有QPS_WORKER_CHANNEL_CONNECT_TIMEOUT秒整数可配置客户端等待 benchmark server 就绪的超时时间——若服务器启动较慢建议同时调大场景配置中的warmup_seconds。Artifacts Packagestask_runner.py按标签执行构建/分发任务功能定位tools/run_tests/task_runner.py 是一个基于标签label的通用任务框架仓库用其构建二进制制品artifacts与分发包distrib packages并对其进行测试。从源码看任务集合来自三个模块task_runner.py_TARGETS [] _TARGETS artifact_targets.targets() # 二进制制品 _TARGETS distribtest_targets.targets() # 分发包测试 _TARGETS package_targets.targets() # 包构建_create_build_map()第 33-50 行同时建立「任务名 → 任务」与「标签 → 任务」两张映射且要求任务名与标签名互不冲突从而支持通过任务名或任意标签选择任务。示例与参数README 给出的示例tools/run_tests/task_runner.py -f python artifact linux x64该命令会选择带python、artifact、linux、x64全部标签的任务执行。常用参数源自 task_runner.py-b/--build任务名或标签可多个默认all指定要执行的目标-f/--filter以 AND 语义过滤——目标必须同时具备所有指定标签-e/--exclude排除具备任一指定标签的目标-j/--jobs并行任务数-x/--xml_reportJUnit 兼容 XML 报告文件名默认report_taskrunner_sponge_log.xml--dry_run只打印将要执行的命令而不真正执行便于调试任务选择逻辑--inner_jobs透传给每个目标内部的并行构建任务数。这种「标签驱动」设计非常适合 CI把同一批任务用linux、x64、artifact等标签打散配合-f/-e即可灵活编排发布流水线而无需改动任务定义本身。小结tools/run_tests是 gRPC 仓库测试与发布体系的统一入口脚本用途典型命令run_tests.py构建并运行单元测试tools/run_tests/run_tests.py -l python -c dbgrun_interop_tests.py跨语言互操作测试tools/run_tests/run_interop_tests.py -l python -s c --use_dockerrun_performance_tests.py性能基准已弃用见 performance/README.md—task_runner.py按标签执行制品构建与分发测试tools/run_tests/task_runner.py -f python artifact linux x64全部命令均以 Python 为入口、从仓库根目录执行保证跨平台一致性互操作测试的场景语义可对照 doc/interop-test-descriptions.md 深入阅读性能基准的最新方案则统一收敛到 tools/run_tests/performance 下的 GKE 框架文档中。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考