音视频音频处理嵌入式物联网语音【免费下载链接】esp-adfEspressif Advanced Development Framework for Multimedia Applications项目地址https://gitcode.com/gh_mirrors/es/esp-adf点击查看免费下载本文是 esp-adf 中esp_service组件框架级测试与仿真工具链components/esp_service/test_apps的完整实战指南。test_apps承担着与使用示例互补的使命示例components/esp_service/examples/mock_services只演示如何使用六个 mock 服务而真正压测框架本身service manager、MCP JSON-RPC、四种传输通道、PC 仿真的代码全部集中在这里。读完本文你将掌握如何在真机上跑 Unity 单元测试与传输通道冒烟测试、如何用 Python 客户端脚本从工作站驱动开发板验证 HTTP/SSE/WS/UART 四种 MCP 传输以及如何在 PC 上通过 FreeRTOS POSIX 移植构建出五个独立的仿真与测试可执行程序。框架级测试的定位与设计思想esp_service是一个将设备能力抽象为可注册服务、并通过 MCPModel Context ProtocolJSON-RPC 暴露为可调用工具的框架。其测试策略分两层使用级验证由 components/esp_service/examples/mock_services/README.md 对应的示例工程演示框架级验证由本test_apps承载覆盖 service manager、MCP JSON-RPC 协议、各传输通道以及 PC 仿真环境。一个关键设计是mock 服务即取即用六个 mock 服务button_service、cloud_service、led_service、ota_service、player_service、wifi_service位于 components/esp_service/examples/mock_services/components通过EXTRA_COMPONENT_DIRS直接被 test_apps 消费示例与测试因此天然保持同步——任何对 mock 服务的修改会同时作用于两边。这一点在设备端工程 components/esp_service/test_apps/CMakeLists.txt 中可以看到明确实现set(EXTRA_COMPONENT_DIRS ${_ESP_SERVICE_ROOT} ${_MOCK_COMPS} )PC 侧工程同样复用同一份 mock 服务源码EXAMPLE_COMPS_DIR指向../../examples/mock_services/components并刻意将纯服务逻辑example_services与MCP 适配层example_services_mcp拆分为两个静态库以便某个测试场景可以完全不链接 cJSON 与 MCP 代码验证零 MCP 依赖的纯函数调用路径。目录结构解析components/esp_service/test_apps/ ├── CMakeLists.txt # IDF 设备端工程EXTRA_COMPONENT_DIRS 引入 mock 服务 ├── sdkconfig.defaults # 设备端默认配置传输开、冒烟测试关 ├── sdkconfig.ci # CI 注入 WiFi 凭据 ├── pytest_esp_service_test_apps.py ├── main/ # IDF 设备端运行器Unity 可选传输冒烟 │ ├── app_main.c │ ├── ut_esp_service_core.c │ ├── ut_service_manager.c │ ├── ut_*_transport.c # 由 Kconfig 门控见 CMakeLists.txt │ ├── ut_transport_lifecycle_test.c │ ├── ut_transport_smoke_helpers.h │ ├── Kconfig.projbuild │ └── CMakeLists.txt ├── scripts/ # PC 端 MCP JSON-RPC 客户端对真机 │ ├── README.md │ ├── test_mcp_http.py # 纯 HTTP POST /mcp │ ├── test_mcp_sse.py # HTTPSSE配合 ESP_SVC_TEST_SSE_HOLD_AFTER_SMOKE │ ├── test_mcp_ws.py # WebSocket配合 ESP_SVC_TEST_WS_HOLD_AFTER_SMOKE │ └── test_mcp_uart.py # UART配合 ESP_SVC_TEST_UART_HOLD_AFTER_SMOKE └── pc/ # PC / 主机端运行器FreeRTOS POSIX 移植原生 CMake ├── CMakeLists.txt ├── FreeRTOSConfig.h ├── service_sim_example.c ├── sim_support.{c,h} ├── service_tool_dispatch_test.c ├── service_integration_test.c ├── service_coverage_test.c ├── mcp_http_server.c ├── svc_helpers.h ├── host_http_transport.{c,h} ├── embedded_files.c # JSON schema 数据块 └── compat/ # IDF → POSIX 垫片esp_err.h、esp_log.h、esp_timer.h 等设备端各测试文件的编译由 components/esp_service/test_apps/main/CMakeLists.txt 按 Kconfig 开关逐个追加if(CONFIG_ESP_SVC_TEST_ENABLE_LIFECYCLE_STRESS) list(APPEND srcs ut_transport_lifecycle_test.c) endif() if(CONFIG_ESP_SVC_TEST_ENABLE_HTTP_TRANSPORT) list(APPEND srcs ut_http_transport.c) endif() # ... SSE / WS / UART 同理基础测试ut_esp_service_core.c、ut_service_manager.c始终编译传输相关测试则完全由 Kconfig 门控保证默认镜像只跑无网络依赖的纯框架测试。设备端IDF测试构建与运行构建命令cd components/esp_service/test_apps idf.py set-target esp32s3 idf.py menuconfig # 设置 Wi-Fi在 ESP Service test_apps Configuration 下开关传输 idf.py build flash monitor默认配置解读[sdkconfig.defaults](https://link.gitcode.com/i/48294e905fe5334e2e13abf5698805d4)的默认策略是MCP 网络传输全部启用但所有设备端冒烟测试全部关闭CONFIG_ESP_MAIN_TASK_STACK_SIZE4096 CONFIG_FREERTOS_HZ1000 # 四种 MCP 传输通道全部编译进固件 CONFIG_ESP_MCP_ENABLEy CONFIG_ESP_MCP_TRANSPORT_HTTPy CONFIG_ESP_MCP_TRANSPORT_SSEy CONFIG_ESP_MCP_TRANSPORT_WSy CONFIG_ESP_MCP_TRANSPORT_UARTy # 默认只开生命周期压力测试其余冒烟测试默认关闭 CONFIG_ESP_SVC_TEST_ENABLE_LIFECYCLE_STRESSy # CONFIG_ESP_SVC_TEST_ENABLE_HTTP_TRANSPORT is not set # CONFIG_ESP_SVC_TEST_ENABLE_SSE_TRANSPORT is not set # CONFIG_ESP_SVC_TEST_ENABLE_WS_TRANSPORT is not set # CONFIG_ESP_SVC_TEST_ENABLE_UART_TRANSPORT is not set # 控制台走 UART0CP2102 / ttyUSB0 CONFIG_ESP_CONSOLE_UART_DEFAULTy # WebSocket 依赖 HTTP 服务器支持 CONFIG_HTTPD_WS_SUPPORTy CONFIG_UNITY_ENABLE_64BITy因此在默认配置下固件只运行带[esp_service]标签的 Unity 测试ut_esp_service_coreut_service_managerMCP 使用桩传输无需网络即可完成。需要 SSE/WS/UART 冒烟或生命周期压力测试时再在 menuconfig 中打开ESP_MCP_TRANSPORT_*与ESP_SVC_TEST_ENABLE_*。注意HTTP / SSE / WS 三种传输冒烟测试同一时间只应启用一种。CI 场景中WiFi 凭据由 sdkconfig.ci 从环境变量注入CONFIG_ESP_SVC_TEST_WIFI_SSID${CI_WIFI_SSID} CONFIG_ESP_SVC_TEST_WIFI_PASSWORD${CI_WIFI_PASSWORD}自动化集成由 pytest_esp_service_test_apps.py 完成——它对 esp32s3 目标依次断言串口输出中的ESP Service - test_apps与TEST_APPS RUN COMPLETE两个标记pytest.mark.generic idf_parametrize(target, [esp32s3], indirect[target]) def test_esp_service_test_apps(dut: IdfDut) - None: dut.expect(rESP Service - test_apps, timeout60) dut.expect(rTEST_APPS RUN COMPLETE, timeout600)设备端运行流程app_mainmain/app_main.c 的执行顺序清晰地呈现了测试层级调用esp_service_ut_core_force_link()与esp_service_ut_manager_force_link()防止--gc-sections丢弃TEST_CASE的构造函数注册UNITY_BEGIN()后通过unity_run_tests_by_tag([esp_service], false)运行所有带该标签的 Unity 用例依次执行 Kconfig 门控的集成演示生命周期压力 → UART → WS → SSE → HTTP 冒烟测试打印TEST_APPS RUN COMPLETE收尾。Kconfig 测试开关全景[main/Kconfig.projbuild](https://link.gitcode.com/i/6f7b655583ea882f8f7e8aac9ba9cd27)定义了ESP Service test_apps Configuration菜单下表汇总全部选项含默认值与依赖关系Kconfig 选项类型默认值依赖说明ESP_SVC_TEST_WIFI_SSIDstringmyssid—传输冒烟测试使用的 STA SSIDESP_SVC_TEST_WIFI_PASSWORDstringmypassword—STA 的 WPA/WPA2 密码ESP_SVC_TEST_ENABLE_LIFECYCLE_STRESSboolyESP_MCP_ENABLE反复执行 create/start/stop/destroy 生命周期压力测试ESP_SVC_TEST_LIFECYCLE_STRESS_CYCLESint100上者每个传输的循环次数范围 1~1000ESP_SVC_TEST_ENABLE_HTTP_TRANSPORTboolnESP_MCP_TRANSPORT_HTTPHTTP POST 传输冒烟UnityESP_SVC_TEST_ENABLE_SSE_TRANSPORTboolnESP_MCP_TRANSPORT_SSEHTTPSSE 传输冒烟MCP 推荐ESP_SVC_TEST_SSE_HOLD_AFTER_SMOKEboolnESP_SVC_TEST_ENABLE_SSE_TRANSPORT冒烟后保持 SSE MCP 服务器存活供 PC 脚本连接ESP_SVC_TEST_ENABLE_WS_TRANSPORTboolnESP_MCP_TRANSPORT_WSWebSocket 传输冒烟ESP_SVC_TEST_WS_HOLD_AFTER_SMOKEboolnESP_SVC_TEST_ENABLE_WS_TRANSPORT冒烟后保持 WS MCP 服务器存活ESP_SVC_TEST_ENABLE_UART_TRANSPORTboolnESP_MCP_TRANSPORT_UARTUART 传输冒烟ESP_SVC_TEST_UART_HOLD_AFTER_SMOKEboolnESP_SVC_TEST_ENABLE_UART_TRANSPORT冒烟后保持 UART MCP 服务器存活ESP_SVC_TEST_UART_TX_PINint43ESP_SVC_TEST_ENABLE_UART_TRANSPORTUART TX GPIOESP32-S3 UART0 默认ESP_SVC_TEST_UART_RX_PINint44ESP_SVC_TEST_ENABLE_UART_TRANSPORTUART RX GPIOESP_SVC_TEST_UART_BAUD_RATEint115200ESP_SVC_TEST_ENABLE_UART_TRANSPORTUART 波特率几个值得注意的细节SSE 端点布局GET /mcp/sse建立事件流POST /mcp/messages?sessionIdid发送请求MCP 2024-11-05 风格WS 默认端点ws://ip:8081/mcp且 WS 传输依赖CONFIG_HTTPD_WS_SUPPORTyUART 默认引脚ESP32-S3 UART0 的 GPIO43/44115200 波特率生命周期压力测试在设备端刻意不测 STDIO 传输ESP 控制台 VFS 后端是非阻塞的会让 STDIO 读任务在循环间忙转从而触发任务看门狗STDIO 的端到端覆盖由 PC 侧通过阻塞管道完成见 main/ut_transport_lifecycle_test.c 的注释说明。设备端 Unity 测试内容ut_esp_service_core.c[esp_service][core] 组聚焦 components/esp_service/include/esp_service.h 的公开 API 边界NULL/非法参数拒绝esp_service_init(NULL, ...)、esp_service_deinit(NULL)、各种get_*输出指针为 NULL 时均返回ESP_ERR_INVALID_ARG完整生命周期INITIALIZED → RUNNING → INITIALIZED验证get_state/get_name/get_user_data/is_running状态机非法转移未初始化时start返回ESP_ERR_INVALID_STATE事件 APIpublish_event拒绝 service 为 NULL 或 event_id 为 0state_to_str输出RUNNING等字符串未知事件 ID 返回ESP_ERR_NOT_FOUNDon_init失败传播esp_service_init将on_init回调返回的错误码如ESP_ERR_INVALID_CRC直接透传给调用者并完成清理。ut_service_manager.c[esp_service][manager] 组使用内存桩传输esp_service_mcp_trans_init 自定义ESP_SERVICE_MCP_TRANS_CUSTOMops因此不依赖 STDIO/UART/WiFi 即可验证 manager 与 MCP 服务器逻辑esp_service_manager_create/register/find_by_name的 NULL 参数拒绝空注册表下clone_tools返回 OK 且计数为 0invoke_tool对未知工具返回ESP_ERR_NOT_FOUNDMCP 服务器创建时 tool_provider 或 transport 为 NULL 均被拒绝端到端协议验证注册player_service带player_service_mcp_schema()工具描述与player_service_tool_invoke后向桩传输上的 MCP 服务器发送{jsonrpc:2.0,id:1,method:tools/list}断言响应 JSON 中含player_service_set_volume发送tools/call调用player_service_get_volume断言响应含result与音量值33。ut_transport_lifecycle_test.c对启用的非 WiFi 传输UART反复执行 create→start→stop→destroy在每批前后采样堆使用量以暴露累积泄漏专门防护读任务关闭路径、传输资源泄漏与 MCP 服务器跨传输状态跟踪三类回归。SSE/HTTP/WS 的生命周期压力则内嵌在对应ut_*_transport.c中在 WiFi 就绪后执行。PC 端脚本从工作站驱动真机固件启动后SSE/WS/UART 需要同时打开对应的 hold after smoke 选项以获得长驻服务器即可从工作站驱动开发板。务必在test_apps/目录下执行保证 Python 导入与路径可预测cd components/esp_service/test_apps python3 scripts/test_mcp_http.py device-ip python3 scripts/test_mcp_sse.py device-ip [http-port] python3 scripts/test_mcp_ws.py device-ip [port] python3 scripts/test_mcp_uart.py serial-port [baud]实例python3 scripts/test_mcp_http.py 192.168.1.100 python3 scripts/test_mcp_sse.py 192.168.1.100 8080 python3 scripts/test_mcp_ws.py 192.168.1.100 8081 python3 scripts/test_mcp_uart.py /dev/ttyUSB0 115200Python 依赖pip install requestsHTTP 客户端、pip install websocketsWS 客户端、pip install pyserialUART 客户端。各脚本的测试策略test_mcp_http.py对http://ip:8080/mcp发起 18 项顺序测试——tools/list枚举工具、调用 playerplay/set_volume 75/get_volume/get_status、LEDblink 1000ms/get_state/set_brightness 80、WiFiget_status/get_ssid/get_rssi/reconnect 到GuestNetwork后复查 SSID、OTAget_version/check_update/get_progress最后覆盖错误路径invalid_tool_name、invalid/methodtest_mcp_sse.py按 MCP 2024-11-05 风格实现最小 SSE 会话——GET /mcp/sse建立流读取强制的endpoint事件随后通过POST /mcp/messages?sessionId...发送 JSON-RPC 并在 SSE 流上读取匹配的message事件固件需ESP_SVC_TEST_ENABLE_SSE_TRANSPORTESP_SVC_TEST_SSE_HOLD_AFTER_SMOKEtest_mcp_ws.py基于websockets的异步客户端验证持久连接、JSON-RPC 2.0 协议、工具枚举/调用、错误处理与多客户端并发test_mcp_uart.py基于pyserial的行式协议客户端——每行一条 JSON-RPC 请求\n结尾每行一条响应。内置 8 组功能测试串口连接、工具枚举、工具调用player/LED 全套、多请求、错误处理非法工具名、非法方法、畸形 JSON{broken json!!!、缺 method 字段、10 连发吞吐输出平均耗时与 req/s、JSON-RPC 合规响应含jsonrpc与匹配的id、断线重连。脚本还会打印硬件接线提示ESP32-S3 UART0 的 GPIO43(TX)/GPIO44(RX) 直连 USB 转串口芯片也可用ESP_SVC_TEST_UART_TX_PIN/RX_PIN改引脚。PC主机端仿真在开发机上跑 FreeRTOSPC 侧是一个独立的原生 CMake 工程基于FreeRTOS POSIX 移植GCC_POSIX portV11.2.0拉起完整的 FreeRTOS 调度器、真实 TCP 套接字与多个服务实例因此这些程序属于集成/场景测试而非 Unity 单元测试。cd components/esp_service/test_apps/pc cmake -S . -B build -G Ninja cmake --build build构建脚本pc/CMakeLists.txt通过 FetchContent 拉取 FreeRTOS-Kernel 与 cJSON并做了一件精巧的事为 IDF 风格的#include freertos/FreeRTOS.h带前缀生成符号链接包装目录同时用 pc/compat 下的esp_err.h、esp_log.h、esp_timer.h垫片把 IDF 依赖映射到 POSIX 环境从而让esp_service核心代码几乎原样在 PC 上编译。CMake 工程产出五个可执行程序二进制角色service_sim_example常驻多服务事件总线仿真service_sim_example.csim_glue.csim_profile.csim_traffic.c。在light/normal/heavy三档 profile 下运行 10–30 s注入 burst/bulk 流量并打印 PASS/FAIL 判定。可用SIM_SCENARIOheavy SIM_SEED1 ./build/service_sim_example覆盖service_tool_dispatch_test聚焦测试esp_service_manager_register/find_by_name/find_by_category/invoke_tool/unregister不涉及 MCP 服务器/传输service_integration_test端到端直接 C APIMode A、工具分发Mode B、MCP-over-HTTPMode C并发驱动同一批服务实例约 12 sservice_coverage_test全覆盖/边界/压力/多线程套件。14 个区块约 370 条断言覆盖 NULL/非法状态路径、完整事件总线与服务核心状态机、service manager 容量上限、多 FreeRTOS 任务并发发布/订阅、队列模式投递与invoke_tool并发分发mcp_http_server常驻 MCP HTTP 服务器。注册 player/led/ota/wifi 服务在http://127.0.0.1:${MCP_PORT:-9876}/mcp暴露工具。可配合 tools/mcp_llm_bridge 或curl使用service_sim_example多服务事件拓扑仿真该程序pc/service_sim_example.c构建了一个五服务 监控订阅者的完整事件拓扑Button随机 PROVISION/PLAY/VOL_UP/VOL_DOWN/MODE、WiFi随机 scan/connect/disconnect 并对按钮事件作出反应、OTA响应 WiFiGOT_IP并执行同步升级流、Player随机动作并对 button/wifi/ota 反应、LED事件驱动指示器。sim_support.h定义了流量整形器burst/bulk 事件参数、运行 profilesim_runtime_profile_t时长、按钮次数、WiFi 轮数、OTA 上限、player 动作数、判定阈值与跨服务订阅装配函数sim_setup_subscriptions运行时可用SIM_SEED环境变量固定随机种子保证可复现。service_tool_dispatch_test无 MCP 的本地分发该程序pc/service_tool_dispatch_test.c演示了 manager 的纯本地能力六个演示步骤即为完整的 API 速查start_all批量启动所有已注册服务find_by_name按名查找player命中、nonexistent返回ESP_ERR_NOT_FOUNDfind_by_category枚举同类别服务player 与 led 同属device类别用于演示异构服务枚举invoke_tool按工具名本地调用——player_service_play、player_service_set_volume {volume:75}、player_service_get_status、led_service_blink {period_ms:200}、led_service_get_stateunregister运行时动态摘除服务先esp_service_stop再unregister直接 C API 与工具分发共存led_service_on()、player_service_play()与 invoke_tool 可同时作用于同一实例。值得注意该测试工程刻意设置为auto_start_services false并只链接example_services_mcpesp_servicecjson不链接任何 MCP 传输——用链接层保证本地分发不依赖网络协议。service_coverage_test16 段全覆盖套件pc/service_coverage_test.c 通过自研的微型断言宏TEST_BEGIN/TEST_END/EXPECT/EXPECT_EQ组织为 16 个独立区块S1–S16覆盖面远超设备端 Unity 用例S1–S3adf_event_hub的边界/NULL 覆盖、功能覆盖sub/pub/unsub/queue/cb/ANY_ID、统计与 payload 所有权/释放S4–S6服务核心边界、完整状态机迁移与非法转移、事件 APIpublish/subscribe/last_errorS7–S9manager 边界、功能覆盖register/find/invoke、容量上限max_servicesS10–S12多线程压力——多发布者 回调订阅者、多发布者 队列订阅者、并发invoke_tool分发S13快速 create/start/stop/destroy 生命周期压力S14大动态 payload 由 hub 释放的压力测试S15错误路径——on_start失败会发出new_stateERROR的STATE_CHANGEDpublish_event在提前返回非法参数/无 hub时调用release_cb保证调用方永不泄漏S16UAF 回归——一个任务持续 unregister/re-register 服务的同时另一任务并发invoke_tool。service_integration_test三种交互模式共存pc/service_integration_test.c 模拟真实嵌入式设备的四服务并发场景player/led/button/wifi MCP HTTP 服务器用三个 FreeRTOS 任务同时走三条路径Mode A直接 C API延迟敏感的设备内逻辑、Mode B经esp_service_manager_invoke_tool的本地工具分发无网络、无 JSON-RPC 帧、Mode C远程 AI Agent 经 HTTPPOST /mcp发送tools/call。事件驱动层则由 button_service 的按键事件PLAY/VOL_UP/VOL_DOWN/MODE与 wifi_service 的连接事件CONNECTING/CONNECTED/GOT_IP/DISCONNECTED驱动 player 与 LED。程序内置统计计数器直接调用/分发调用/MCP 调用/事件回调运行约 12 sTEST_DURATION_MS 12000后校验结果传--llm参数则测试结束后保持 HTTP 服务器存活供外部 LLM bridgemcp_bridge.py交互式或批处理接入。mcp_http_server可联调 LLM 的常驻服务器pc/mcp_http_server.c 是一个运行时目标而非自包含测试创建 managerauto_start_services true注册 player类别audio、leddisplay、otasystem、wifinetwork四个 mock 服务随后通过svc_mcp_http_start(mgr, port, ...)在MCP_PORT环境变量指定的端口默认 9876上提供http://127.0.0.1:port/mcp服务。程序持续运行直到收到 SIGINT/SIGTERM对外暴露如wifi_service_get_status/get_ssid/get_rssi/reconnect、OTA 版本/升级等工具配合 tools/mcp_llm_bridge 可让 LLM 直接调用这些设备能力。相关资源使用示例本测试框架的配套工程components/esp_service/examples/mock_services组件 READMEcomponents/esp_service/README.mdmcp_http_server的 LLM bridgetools/mcp_llm_bridge/README.mdPC 客户端脚本说明components/esp_service/test_apps/scripts/README.md小结esp_service的 test_apps 呈现了一条完整的框架级验证链路设备端用 Unity 验证 API 边界与状态机不依赖网络用 Kconfig 门控的传输冒烟与生命周期压力测试验证四种 MCP 通道的真实可用性PC 端用 FreeRTOS POSIX 移植把同一份框架代码搬到开发机以五个可执行程序覆盖纯函数调用、本地工具分发、MCP-over-HTTP、全覆盖压力与多模式集成最后由 Python 客户端脚本把真机与工作站串成端到端闭环。这套示例即用、测试即证的架构让esp_service的服务抽象、MCP 协议实现与传输层可以在最小成本下获得持续的回归保障。赞分享音视频音频处理嵌入式物联网语音【免费下载链接】esp-adfEspressif Advanced Development Framework for Multimedia Applications项目地址https://gitcode.com/gh_mirrors/es/esp-adf点击查看免费下载相关推荐深入 Encore 端到端测试框架从 encore run 到多语言客户端生成的全链路验证实战深入 Encore 端到端测试框架从 encore run 到多语言客户端生成的全链路验证实战 本指南以 Encore 开源仓库中的 e2e tests/RE后端开发工具云原生微服务Hypothesis测试框架与RequestsHTTP客户端测试实践Hypothesis测试框架与RequestsHTTP客户端测试实践 在软件开发中HTTP客户端的测试往往面临诸多挑战如边界条件处理、异常情况模拟等。Hy测试开发工具vLLM-Omni测试与验证端到端测试框架使用指南vLLM Omni作为高效的多模态模型推理框架其端到端测试框架为开发者和用户提供了全面的验证保障。本指南将详细介绍vLLM Omni测试框架的使用方法和最佳实人工智能大模型模型推理服务多模态语音音频媒体生成本地部署上一篇如何在资源受限的MCU上实现高效JPEG解码终极轻量级解决方案深度解析下一篇IPyFlow 使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考