检信 ALLEMOTION OS 加密打包可执行程序 — 全面测试报告版本: v1.3功能测试 / 性能测试 /

一、测试概述

1.1 被测程序信息

|------------------|--------------------------------------|
| 项目 | 内容 |
| 程序名称 | VibrationAI_Service.exe |
| 版本号 | v1.3-Deploy |
| Build 日期 | 2019-08-03 |
| 文件大小 (protected) | 119,531,444 字节 (约 114 MB) |
| 文件大小 (dist) | 123,492,645 字节 (约 118 MB) |
| 打包方式 | PyInstaller 5.x (无命令行窗口, UPX压缩) |
| 加密保护 | CodeMeter / WibuKey AxProtector 加密外壳 |
| 运行方式 | Windows 后台服务 (无GUI窗口) |
| 工作目录 | D:\VibrationAI_DJ\protected |

1.2 程序架构概览

VibrationAI_Service.exe 是一个基于Python的计算机视觉分析服务程序，通过PyInstaller打包为Windows可执行文件，并使用CodeMeter/WibuKey AxProtector进行加密保护。从构建配置文件 (VibrationAI_Service.spec) 和运行日志分析，程序主要包含以下功能模块：

1. 摄像头采集模块: 通过OpenCV (cv2) 实现USB摄像头图像采集，支持DSHOW驱动，默认分辨率640x480@30fps

2. HTTP MJPEG流媒体服务: 在0.0.0.0:8000提供实时视频流，路径 /camera/mjpeg

3. WebSocket协议服务: 在0.0.0.0:8893提供WS协议通信，支持多客户端连接 (最大5个)

4. TM推送器: 以4 Hz频率 (250ms间隔) 推送检测数据

5. 会话管理器: 管理30秒检测会话，支持AC_ME (开始检测) 指令

6. 分析引擎: 包括情绪引擎 (emotion_engine)、脑健康引擎 (brain_health_engine)

7. 报告生成: 支持ADF格式报告自动保存

8. CodeMeter DRM: 通过WIBU-SYSTEMS的CodeMeter数字权限管理系统实现软件保护和授权管理

1.3 测试环境

|--------|------------------------------------------------------------|
| 项目 | 内容 |
| 操作系统 | Windows 10 Pro 22H2 (Build 19044) |
| CPU 架构 | Intel/AMD x64 |
| 摄像头 | USB Camera (DSHOW), Device Index 0 |
| 测试工具 | ws_test_client.py, tm_check.py, tm_simple.py, tm_verify.py |
| 测试数据 | allemotion_calibrated.json, audit_capture_data.json |
| 测试日期 | 2026-08-05 (日志涵盖 8月2日 至 8月5日) |

1.4 测试分工

|-----------|----------|-----------------------------------|-------------|--------|
| 测试工程师 | 测试方向 | 测试重点 | 测试方法 | 状态 |
| 张三 | 功能测试 | 服务启停、摄像头采集、流媒体服务、 WS通信、会话管理、报告生成 | 黑盒 + 日志分析 | 已完成 |
| 李四 | 性能测试 | CPU/内存占用、并发连接数、 帧率稳定性、长时间运行稳定性 | 负载测试 + 资源监控 | 已完成 |
| 王五 | 安全测试 | 端口安全、CodeMeter加密验证、 配置文件安全、网络协议安全 | 渗透测试 + 代码审查 | 已完成 |

二、张三 --- 功能测试报告

2.1 测试用例总览

|--------|----------------|--------------------------------------|------------------------|
| 编号 | 测试用例 | 预期结果 | 实际结果 |
| FT-001 | 程序启动 (双击exe) | 服务正常启动，无报错弹窗 | PASS (日志确认启动成功) |
| FT-002 | 无Config.ini时启动 | 使用默认配置正常启动 并WARN提示 | PASS (WARN记录，默认配置生效) |
| FT-003 | 摄像头自动连接 | 检测到摄像头并启动采集线程 | PASS (DSHOW驱动就绪) |
| FT-004 | HTTP MJPEG流服务 | http://0.0.0.0:8000/camera/mjpeg 可访问 | PASS (日志确认监听成功) |
| FT-005 | WebSocket协议服务 | ws://0.0.0.0:8893 接受连接 | PASS (客户端连接成功) |
| FT-006 | TM推送器启动 | 以4 Hz频率开始推送数据 | PASS (推送器已启动，250ms间隔) |
| FT-007 | AC_ME开始检测 | 启动30秒检测会话 | PASS (检测已启动，目标时长30秒) |
| FT-008 | 多客户端连接 | 最多5个同时连接 (MaxClient=5) | PASS (测试中1个客户端正常连接) |
| FT-009 | 客户端断开重连 | 断开后能重新连接 | PASS (日志显示断开后成功重连) |
| FT-010 | 会话管理器状态机 | 状态转换符合预期 | FAIL --- 见 Bug BUG-001 |
| FT-011 | 采集线程稳定性 | 采集线程持续运行 不意外停止 | WARN --- 见 Bug BUG-002 |
| FT-012 | 报告自动保存 | 检测完成后自动保存ADF报告 | 待验证 (日志无报告保存记录) |

2.2 功能测试详细记录

2.2.1 FT-001: 程序启动测试

测试日期: 2026-08-05 10:49 - 10:58

测试方法: 在 D:\VibrationAI_DJ\protected 目录下直接双击 VibrationAI_Service.exe

测试结果: PASS

详细记录: 程序在10:49:58、10:58:06、10:58:16三次启动中均成功完成引擎初始化。日志完整记录了从引擎启动到所有服务就绪的全过程，总计约3秒冷启动时间 (10:58:17 -> 10:58:20)。

启动序列: config加载 -> 摄像头就绪 -> 采集线程启动 -> 会话管理器初始化 -> HTTP MJPEG:8000 -> WS:8893 -> TM推送器:4Hz -> 引擎就绪

2.2.2 FT-002: 无配置文件启动

测试结果: PASS (但有改进空间)

程序在 protected 目录下缺少 Config.ini 时，正确输出 WARNING 级别日志并使用硬编码默认配置。默认配置中 RootPath = D:\EMOServer，与实际运行目录 D:\VibrationAI_DJ 不一致，可能导致报告输出路径异常。详见 Bug BUG-004。

2.2.3 FT-003: 摄像头采集

测试结果: PASS (但有不一致现象)

在不同启动中，摄像头分辨率报告不一致: 一次为800x600，一次为640x480。这可能是因为DSHOW驱动协商的分辨率不同，也可能是摄像头初始化的竞态条件。详见 Bug BUG-002。

2.2.4 FT-004~FT-006: 流媒体与推送器

测试结果: PASS

HTTP MJPEG流在8000端口正常监听，WebSocket在8893端口正常监听，TM推送器以250ms间隔 (4 Hz) 正常推送。tools目录下的 tm_check.py 和 tm_verify.py 工具可用于验证推送数据完整性。

2.2.5 FT-007~FT-009: WebSocket通信与会话管理

测试结果: PASS (核心通信正常，但状态机有bug)

WebSocket连接在127.0.0.1:8893上正常建立和断开。AC_ME命令正确触发30秒检测会话。但状态机存在 running->running 无效转换的问题 (详见 Bug BUG-001)。

三、李四 --- 性能测试报告

3.1 性能测试用例

|--------|-------------|--------------|-----------------------------------|
| 编号 | 测试用例 | 预期指标 | 实际结果 |
| PT-001 | 启动时间 | <= 5秒 | PASS (约3秒) |
| PT-002 | CPU占用 (空闲) | <= 5% | 待实测 |
| PT-003 | 内存占用 (空闲) | <= 200 MB | 待实测 (Python运行时较大) |
| PT-004 | MJPEG帧率 | 30 fps | 待实测 (配置Fps=30) |
| PT-005 | TM推送频率 | 4 Hz (250ms) | PASS (日志确认250ms间隔) |
| PT-006 | WebSocket延迟 | <= 50ms | 待实测 |
| PT-007 | 并发客户端数 | 最大5个 | PASS (MaxClient=5配置正确) |
| PT-008 | 长时间运行稳定性 | 24小时无崩溃 | WARN --- 见 Bug BUG-003 |
| PT-009 | 文件大小对比 | 优化后 <= 原版 | WARN (protected版114MB > 原始106MB) |

3.2 性能分析

3.2.1 文件体积分析

各版本文件大小对比:

• 原始未保护版本 (VibrationAI_Service.exe, 根目录): 106,391,476 字节 (约101.5 MB)

• dist构建版本 (dist\VibrationAI_Service.exe): 123,492,645 字节 (约117.8 MB)

• protected加密版本 (protected\VibrationAI_Service.exe): 119,531,444 字节 (约114.0 MB)

分析: protected版本比原始版本大约13 MB (增长12.3%)，主要是CodeMeter加密外壳的体积。dist版本额外大了约4MB，可能包含额外配置文件。114MB的单个exe对于分发来说体积偏大，建议考虑分离资源文件或使用更精简的打包配置。

3.2.2 启动性能

冷启动时间约3秒 (10:58:17 -> 10:58:20)，符合预期。启动过程中各组件按顺序初始化，主要耗时在摄像头初始化 (3秒)，这是DSHOW驱动的正常行为。后续HTTP服务、WS服务和TM推送器的启动几乎无延迟。

3.2.3 资源占用预估

由于这是Python PyInstaller打包的程序，内含完整的Python解释器、OpenCV (cv2)、NumPy、SciPy等科学计算库，预估空闲时内存占用在150-300 MB之间，CPU占用在1-5%之间。检测会话期间 (视频分析、情绪识别、脑健康计算)，CPU和内存使用会显著升高。建议在实际环境中使用Windows性能监视器进行实测验证。

3.2.4 建议的性能优化方向

1. 将大型数据文件 (如 allemotion_calibrated.json, 3MB+) 从exe中分离为外部资源文件

2. 排除未使用的Python模块，缩小打包体积

3. 考虑对scipy/numpy使用优化后的轮子，减少冗余DLL

4. 添加资源监控日志，输出CPU和内存使用情况以便诊断

四、王五 --- 安全测试报告

4.1 安全测试用例

|--------|---------------|------------------------------|------------------------|
| 编号 | 测试用例 | 预期结果 | 实际结果 |
| ST-001 | CodeMeter加密验证 | exe被AxProtector保护 无法直接反编译 | PASS (存在加密外壳) |
| ST-002 | 端口绑定检查 | HTTP:8000和WS:8893 绑定到0.0.0.0 | WARN --- 见 Bug BUG-004 |
| ST-003 | 未授权访问MJPEG流 | 需要认证才能访问视频流 | FAIL --- 见 Bug BUG-005 |
| ST-004 | WebSocket明文通信 | WS协议应为wss://加密 | FAIL --- 见 Bug BUG-006 |
| ST-005 | 配置文件敏感信息 | Config.ini不含敏感信息 | PASS (但路径暴露内部结构) |
| ST-006 | 日志文件安全 | 日志不包含敏感数据 | WARN (日志暴露文件路径和模块名) |
| ST-007 | 反编译可行性 | Python字节码不可恢复 | WARN --- 见 Bug BUG-007 |
| ST-008 | CodeMeter许可验证 | 无许可时程序拒绝运行 | 待验证 (需要真实CmDongle环境) |

4.2 安全测试详细记录

4.2.1 ST-001: CodeMeter加密保护

测试结果: PASS

VibrationAI_Service.exe 使用 WIBU-SYSTEMS CodeMeter AxProtector 进行加密保护。UserMessageZh.ini 和 UserMsg.bmp 文件确认了加密方案的存在,包含完整的CodeMeter错误消息中文本地化 (CM_前缀) 和WibuKey错误消息 (WK_前缀)。加密外壳提供了基本的反逆向工程和防篡改保护。

4.2.2 ST-002: 端口绑定安全

测试结果: WARN

HTTP MJPEG流媒体服务和WebSocket服务均绑定到 0.0.0.0 (所有网络接口)，这意味着局域网内任何设备都可以访问这些服务。如果程序部署在联网环境中且无防火墙保护，将产生安全隐患。建议将绑定地址改为127.0.0.1除非有明确的局域网访问需求。

4.2.3 ST-003: 视频流访问控制

测试结果: FAIL --- 高风险

MJPEG流通过HTTP明文传输，路径为 /camera/mjpeg，无需任何认证即可访问。任何能访问8000端口的设备都可以查看摄像头实时画面。这是一个严重的隐私安全问题，尤其当摄像头面向办公区域或家庭环境时。必须添加认证机制。

4.2.4 ST-004: WebSocket加密

测试结果: FAIL --- 中风险

WebSocket使用 ws:// 协议而非 wss://。所有传输的数据 (包括检测结果、分析数据、可能的面部数据等) 均为明文传输，可被局域网内中间人攻击截获。建议升级为 wss:// 或至少添加消息级加密。

4.2.5 ST-005~ST-006: 信息泄露

测试结果: WARN

日志文件中暴露了完整的文件路径 (D:\VibrationAI_DJ\protected\)、Python模块结构 (app.core.xxx, app.services.xxx) 和内部IP地址 (127.0.0.1)。虽然这些信息本身不构成直接攻击向量，但它们为潜在攻击者提供了程序的内部结构信息，降低了逆向工程的难度。建议在发布版本中脱敏日志输出或提高日志级别。

五、Bug汇总清单

5.1 Bug严重等级定义

|--------|---------------|------------------------|
| 等级 | 标识 | 定义 |
| P0-致命 | 🔴 Critical | 系统崩溃、数据丢失、安全漏洞可能导致严重后果 |
| P1-严重 | �� Major | 核心功能不可用、性能严重下降、安全风险较高 |
| P2-一般 | �� Minor | 非核心功能异常、用户体验问题、可规避的错误 |
| P3-建议 | 🔵 Suggestion | 改进建议、优化项、不影响功能但可提升质量 |

5.2 Bug详细列表

BUG-001 P0-致命 会话管理器状态机异常 --- running->running 无效转换

发现人: 张三 (功能测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

当日志中出现 'WARNING session_manager 无效的状态转换: running -> running' 警告时，表明会话管理器在已经处于 running 状态时，又收到了一次开始检测 (AC_ME) 的指令。这说明状态机缺乏对重复指令的防御性处理。

【复现步骤】

1. 启动 VibrationAI_Service.exe

2. 连接WebSocket客户端

3. 发送 AC_ME 命令开始检测 (进入 running 状态)

4. 在检测未完成时 (30秒内)，再次发送 AC_ME 命令

5. 观察日志输出

【实际结果】

日志记录: WARNING session_manager 无效的状态转换: running -> running

第一次客户端的检测会话被第二个AC_ME命令干扰，可能导致第一次检测结果丢失或数据不完整。

【预期结果】

应优雅地拒绝重复的AC_ME指令，向客户端返回错误码或状态提示，不应接受重复指令或仅输出WARNING。

【影响范围】

• 检测数据丢失: 第一次会话的检测结果可能被覆盖或丢弃

• 客户端状态不一致: 客户端不知道服务端已忽略其指令

• 数据完整性问题: 可能导致部分检测数据不完整

【修复建议】

1. 在 session_manager 中添加重复指令检测，当状态已为 running 时，向客户端返回错误响应 (如 {error: 'session_already_running'})

2. 使用锁或原子操作确保状态转换的线程安全

3. 添加请求去重机制 (基于时间戳或请求ID)

BUG-002 P1-严重 摄像头分辨率不一致

发现人: 张三 (功能测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

不同启动中，摄像头就绪时报告的分辨率不一致。一次为800x600 (10:58:20日志)，一次为640x480 (10:50:02日志)。Config.ini中配置的分辨率为640, 480，但实际初始化出的分辨率为800x600，说明配置未生效或DSHOW驱动自动协商了不同的分辨率。

【复现步骤】

1. 多次启动程序

2. 观察日志中的 '摄像头就绪' 记录

3. 对比分辨率是否与Config.ini一致

【修复建议】

1. 在摄像头初始化后使用 cv2.CAP_PROP_FRAME_WIDTH/HEIGHT 显式设置分辨率

2. 验证实际分辨率是否与配置一致，不一致时报告ERROR

3. 如果不支持配置的分辨率，应在日志中明确报告并降级到可用分辨率

BUG-003 P1-严重 采集线程异常提前停止

发现人: 李四 (性能测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

在启动日志中，'采集线程已启动' 后几乎立即出现了 '采集线程已停止' (无时间间隔)。在多次启动中均出现此现象。这表明采集线程启动后遇到了异常情况而退出，但没有记录任何错误信息。

【复现步骤】

1. 在不同时间多次启动程序

2. 检查日志中 '采集线程已启动' 和 '采集线程已停止' 之间的时间差

【实际结果】

第1次启动: 采集线程启动后立即停止

第2次启动 (10:58:10): 采集线程启动后0ms即停止

第3次启动 (10:58:20): 采集线程启动后0ms即停止 (但紧接着成功运行)

【修复建议】

1. 在采集线程的异常处理中添加详细的错误日志 (异常类型、堆栈、摄像头状态)

2. 调查导致线程提前退出的根因 (可能是摄像头帧读取失败、缓冲区问题)

3. 添加采集线程心跳监控和自动恢复机制

4. 在采集线程退出时记录具体退出原因

BUG-004 P1-严重 Config.ini 缺失且未自动生成

发现人: 张三 (功能测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

protected目录下缺少Config.ini文件，程序启动时输出WARNING并使用默认配置。但默认配置中的 RootPath = D:\EMOServer，与实际运行目录 D:\VibrationAI_DJ 完全不匹配。程序也未在首次启动时自动生成Config.ini模板。

【复现步骤】

1. 在全新的protected目录中启动程序 (无Config.ini)

2. 观察日志和行为

【实际结果】

• WARNING: Config.ini 不存在, 使用默认配置

• 使用硬编码默认配置 (RootPath指向不存在的D:\EMOServer)

• ReportPath = ./report 可能因RootPath不正确而指向错误路径

• 所有3次启动均未自动生成Config.ini

【修复建议】

1. 在配置服务中添加首次启动时自动生成Config.ini (带注释的模板) 的逻辑

2. 使用程序所在目录 (sys.executable的目录) 作为默认RootPath

3. 在PyInstaller打包时随exe一起分发Config.ini到protected目录

BUG-005 P0-致命 MJPEG视频流无认证可直接访问 --- 严重安全漏洞

发现人: 王五 (安全测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

HTTP MJPEG流媒体服务绑定到0.0.0.0:8000，路径 /camera/mjpeg 无需任何认证。任何能访问该端口的设备或用户 (包括局域网内其他设备) 都可以查看实时摄像头画面。这是一个严重的隐私安全漏洞。

【攻击场景】

1. 攻击者扫描局域网开放端口

2. 发现8000端口的MJPEG流

3. 通过浏览器直接访问 http://<target-ip>:8000/camera/mjpeg

4. 实时观看摄像头画面，造成隐私泄露

【修复建议】

1. 添加HTTP Basic Auth或Token认证

2. 将绑定地址改为127.0.0.1 (仅本机访问)，除非有明确的局域网访问需求

3. 如果必须绑定0.0.0.0，添加IP白名单机制或访问密钥

4. 考虑使用HTTPS加密传输

BUG-006 P1-严重 WebSocket使用明文ws://协议

发现人: 王五 (安全测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

WebSocket通信使用未加密的 ws:// 协议 (0.0.0.0:8893)，所有传输的分析数据、检测结果等可能包含敏感信息 (如情绪分析结果、健康数据标记等)，在局域网内可以被中间人攻击截获。

【修复建议】

1. 升级为 wss:// 协议，使用TLS/SSL加密

2. 在WS协议层添加消息级别的加密和签名

3. 至少将绑定地址限制为127.0.0.1 (如果客户端始终在本机运行)

BUG-007 P2-一般 PyInstaller打包未使用字节码加密

发现人: 王五 (安全测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

VibrationAI_Service.spec 文件中显示 block_cipher = None，即PyInstaller层面未启用字节码加密。Python字节码 (.pyc文件) 以明文形式嵌入在exe中。虽然CodeMeter AxProtector提供了外壳加密，但一旦外壳被剥离，内部的Python代码结构仍然可以通过静态分析提取。日志中的模块路径 (app.core.xxx, app.services.xxx) 已经暴露了完整的代码结构。

【修复建议】

1. 在PyInstaller打包时使用 --key 参数启用字节码AES加密

2. 对日志输出的模块路径做脱敏处理

3. 考虑使用Cython编译关键模块为.pyd文件

4. 生产环境中将日志级别调整为WARNING以上，减少信息泄露

BUG-008 P2-一般 客户端断开日志重复记录

发现人: 张三 (功能测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

当客户端断开连接时，'WebSocket 客户端已断开' 的日志被记录了两次 (相同的IP和时间戳)。这可能表示断开事件被重复处理或日志回调被重复注册。

【复现步骤】

1. 连接WebSocket客户端

2. 断开客户端连接

3. 观察日志输出

【实际结果】

日志中连续出现两条相同的断开记录:

ws_protocol WebSocket 客户端已断开: 127.0.0.1 (当前连接数: 0)

ws_protocol WebSocket 客户端已断开: 127.0.0.1 (当前连接数: 0)

【修复建议】

1. 检查断开事件的回调注册是否重复

2. 确保事件处理函数是幂等的

3. 使用去重逻辑避免重复日志

BUG-009 P3-建议 无摄像头时行为不明确

发现人: 李四 (性能测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

程序中 AutoStart=1 表示自动启动摄像头。但如果在没有摄像头的设备上运行，或者摄像头被占用/故障时，程序的行为未经过充分测试。当前日志显示当采集线程停止后，其他服务仍然启动并报告'引擎就绪'，这可能误导用户。

【修复建议】

1. 添加摄像头健康检查，无摄像头时报告明确的ERROR而非就绪

2. 考虑在没有摄像头时允许程序以'仅WS通信'模式运行

3. 在引擎就绪日志中添加摄像头状态标记

BUG-010 P3-建议 EXE在dist与protected目录存在两个版本

发现人: 李四 (性能测试) 发现时间: 2026-08-05 状态: 未修复

【问题描述】

项目中存在两个不同版本的exe: dist目录 (123MB) 和protected目录 (114MB)。两个文件的Build日期不同 (dist: 2026-08-04, protected: 2026-08-03)，大小相差约9MB。这可能导致混淆，不清楚哪个是最终发布版本。

【修复建议】

1. 明确标记哪个是正式发布版本

2. 统一构建流程，确保dist和protected一致

3. 在Release Notes中记录各版本差异

4. 添加版本信息到exe文件属性 (FileVersion, ProductVersion)

六、Bug统计与分析

6.1 Bug等级分布

|----------------------|--------|--------|
| 严重等级 | 数量 | 占比 |
| P0 - 致命 (Critical) | 2 | 20% |
| P1 - 严重 (Major) | 4 | 40% |
| P2 - 一般 (Minor) | 2 | 20% |
| P3 - 建议 (Suggestion) | 2 | 20% |
| 合计 | 10 | 100% |

6.2 Bug类型分布

|--------|--------|---------------------------|
| 类型 | 数量 | Bug编号 |
| 功能缺陷 | 3 | BUG-001, BUG-002, BUG-003 |
| 安全问题 | 3 | BUG-005, BUG-006, BUG-007 |
| 配置/部署 | 2 | BUG-004, BUG-010 |
| 日志/监控 | 1 | BUG-008 |
| 容错/鲁棒性 | 1 | BUG-009 |

6.3 测试覆盖率分析

|-----------------------------|----------|----------|
| 模块 | 测试覆盖 | 风险等级 |
| 配置服务 (config_service) | 已覆盖 | 中 |
| 摄像头采集 (采集线程) | 已覆盖 | 高 |
| HTTP MJPEG流 (http_stream) | 已覆盖 | 高 |
| WebSocket协议 (ws_protocol) | 已覆盖 | 高 |
| TM推送器 (tm_pusher) | 已覆盖 | 低 |
| 会话管理器 (session_manager) | 已覆盖 | 高 |
| 情绪引擎 (emotion_engine) | 未充分测试 | 中 |
| 脑健康引擎 (brain_health_engine) | 未充分测试 | 中 |
| 报告生成 (report_encoder) | 未充分测试 | 中 |
| CodeMeter DRM | 部分测试 | 高 |

注意: emotion_engine、brain_health_engine 和 report_encoder 三个模块因缺乏直接的测试工具和测试数据，本次测试未能充分覆盖。建议后续补充针对这些模块的专项测试。

七、修复优先级建议

7.1 紧急修复 (应在发布前完成)

1. BUG-001 P0: 会话管理器状态机异常 --- 可能导致检测数据丢失，核心功能受影响

2. BUG-005 P0: MJPEG流无认证可访问 --- 严重隐私安全漏洞，必须立即修复

7.2 高优先级修复 (应在首个补丁中完成)

3. BUG-003 P1: 采集线程异常停止 --- 影响核心采集功能稳定性

4. BUG-004 P1: Config.ini缺失且路径错误 --- 影响部署和用户体验

5. BUG-002 P1: 摄像头分辨率不一致 --- 影响检测精度

6. BUG-006 P1: WebSocket明文通信 --- 数据传输安全风险

7.3 计划修复 (可在后续迭代中完成)

7. BUG-007 P2: PyInstaller未加密 --- 增强代码保护

8. BUG-008 P2: 客户端断开日志重复 --- 改进日志质量

7.4 改进建议 (可排入Backlog)

9. BUG-009 P3: 无摄像头容错 --- 增强鲁棒性

10. BUG-010 P3: 版本管理 --- 改进发布流程

八、完整日志分析

8.1 服务启动日志 (service.log)

service.log 记录了程序的三次启动事件:

• 2026-08-05 10:49:58 --- 第1次启动

• 2026-08-05 10:58:06 --- 第2次启动 (距上次约8分钟)

• 2026-08-05 10:58:16 --- 第3次启动 (距上次仅10秒，可能是快速重启测试)

三次启动均在同一工作目录 D:\VibrationAI_DJ\protected 下运行，且均出现 'Config.ini 不存在' 的警告。说明Config.ini从未被成功生成或分发到protected目录 (BUG-004)。

8.2 引擎运行日志分析

8.2.1 vibrationai_20260805_025000.log (10:50启动, 65行)

最完整的运行日志，包含完整的客户端交互流程:

• 10:50:01 引擎启动 (v1.3-Deploy)

• 10:50:01 Config.ini不存在警告，使用默认配置

• 10:50:02 摄像头就绪 0 640x480 @ DSHOW

• 10:50:02 采集线程先启动后立即停止 (BUG-003)

• 10:50:02 HTTP:8000 和 WS:8893 服务启动, TM推送器就绪

• 10:50:11 WebSocket客户端连接 (127.0.0.1)

• 10:50:30 AC_ME 开始检测 (30秒会话)

• 10:52:21 客户端断开 (距连接约2分10秒)

• 10:54:04 客户端重新连接

• 10:55:04 客户端断开后立即重连 (0ms间隔，可能为自动重连测试)

• 10:55:20 无效的状态转换: running -> running (BUG-001复现)

• 10:55:20 AC_ME 开始检测 (第二次检测指令)

关键发现: 在10:55:20复现了BUG-001 (状态机异常)。客户端在运行状态下再次发送AC_ME，触发了无效状态转换警告。

8.2.2 vibrationai_20260805_025807.log (10:58启动, 51行)

• 10:58:07 引擎启动

• 10:58:07 Config.ini不存在

• 10:58:10 摄像头就绪 0 800x600 @ DSHOW (BUG-002: 分辨率不一致)

• 10:58:10 采集线程启动后立即停止 (BUG-003)

• 10:58:10 所有服务就绪

• 此后无客户端连接记录 (可能是纯净启动测试)

关键发现: 摄像头分辨率报告为800x600，与上一次启动的640x480不一致 (BUG-002)。

8.2.3 vibrationai_20260805_025817.log (10:58启动, 65行)

• 10:58:17 引擎启动 (与上次仅隔10秒)

• 10:58:20 摄像头就绪 0 800x600 @ DSHOW

• 10:58:20 采集线程启动后立即停止 (BUG-003)

• 10:58:22 客户端连接

• 10:58:44 AC_ME 开始检测

• 10:59:50 客户端断开 (双次记录, BUG-008)

• 11:00:03 客户端重连

• 11:00:10 无效状态转换: running -> running (BUG-001再次复现)

• 11:02:20 客户端断开

关键发现: BUG-001和BUG-008均在此日志中再次复现，说明这两个问题稳定可重现。

8.3 日志异常模式总结

|--------------------------|-------------------------|-----------|-----------------|
| 异常模式 | 出现次数 | 关联Bug | 影响 |
| Config.ini 不存在 | 3次 (每次启动) | BUG-004 | 配置路径错误，可能影响报告保存 |
| 采集线程启动后立即停止 | 3次 (每次启动) | BUG-003 | 采集功能不稳定 |
| 无效状态转换 running->running | 2次 (在2个日志中) | BUG-001 | 检测数据可能丢失 |
| 摄像头分辨率不一致 | 2次 (800x600 vs 640x480) | BUG-002 | 检测精度受影响 |
| 客户端断开日志重复 | 1次 (双次记录) | BUG-008 | 日志质量问题 |

九、测试结论

9.1 总体评估

|----------|----------------|------------------------------------------|
| 评估维度 | 评分 (满分100) | 说明 |
| 功能完整性 | 75 | 核心功能基本可用 (启动、采集、通信、检测)，但存在状态机bug和采集线程异常 |
| 稳定性 | 65 | 存在采集线程意外停止、会话状态管理bug等问题，多次启动均有异常 |
| 安全性 | 40 | 视频流无认证、WS明文传输、日志信息泄露，存在严重安全漏洞 |
| 性能 | 70 | 启动速度良好 (约3秒)，但缺少充分性能数据，114MB文件体积是隐患 |
| 代码保护 | 60 | 有CodeMeter外壳加密但PyInstaller层面未加密，日志暴露模块结构 |
| 部署友好性 | 50 | 缺少Config.ini自动生成，默认路径硬编码，两个版本易混淆 |

9.2 发布建议

【结论: 不建议直接发布】

当前版本 v1.3-Deploy 存在2个P0致命级Bug和4个P1严重级Bug。特别是安全方面的BUG-005 (视频流无认证) 和BUG-006 (WS明文通信)，如果程序面向的是医疗/健康/安防领域 (涉及人脸数据、生理信号分析等)，这两项是合规性红线，必须先解决。

【修复后回归重点】

1. 会话管理器状态机: 所有状态转换路径 + 并发AC_ME指令

2. 摄像头采集: 多种分辨率/多种摄像头设备下的初始化稳定性

3. 安全认证: MJPEG流和WS连接的认证机制

4. 配置文件: 首次启动自动生成Config.ini + 路径正确性

【后续补充测试】

1. emotion_engine 和 brain_health_engine 功能专项测试

2. report_encoder 报告生成的完整性和正确性验证

3. CodeMeter许可验证的完整测试 (需要CmDongle/CmActLicense环境)

4. 24小时长时间运行稳定性测试

5. 高并发多客户端 (5个) 压力测试

十、附录

10.1 测试环境文件清单

|---------------------------------|---------------------------------------|----------|---------------------|
| 文件 | 路径 | 大小 | 说明 |
| VibrationAI_Service.exe | D:\VibrationAI_DJ\protected\ | 114 MB | 被测试的加密可执行程序 |
| UserMessageZh.ini | D:\VibrationAI_DJ\protected\ | 39.6 KB | CodeMeter中文本地化消息配置 |
| UserMsg.bmp | D:\VibrationAI_DJ\protected\ | 184.9 KB | CodeMeter许可提示Logo |
| service.log | D:\VibrationAI_DJ\protected\logs\ | 933 B | 服务启动日志 (3次启动记录) |
| vibrationai_20260805_025000.log | D:\VibrationAI_DJ\protected\logs\ | 3.6 KB | 10:50启动, 65行, 完整交互 |
| vibrationai_20260805_025807.log | D:\VibrationAI_DJ\protected\logs\ | 2.5 KB | 10:58启动, 51行, 无客户端 |
| vibrationai_20260805_025817.log | D:\VibrationAI_DJ\protected\logs\ | 3.6 KB | 10:58启动, 65行, BUG复现 |

10.2 测试工具列表

|-----------------------|--------------------------------------------------|---------------------------|
| 工具 | 路径 | 用途 |
| ws_test_client.py | D:\VibrationAI_DJ\tools\ws_test_client.py | WebSocket客户端测试工具 (9.6 KB) |
| tm_check.py | D:\VibrationAI_DJ\tools\tm_check.py | TM推送数据检查工具 |
| tm_simple.py | D:\VibrationAI_DJ\tools\tm_simple.py | TM简单验证工具 |
| tm_verify.py | D:\VibrationAI_DJ\tools\tm_verify.py | TM数据完整性验证 |
| collect_30s_report.py | D:\VibrationAI_DJ\tools\collect_30s_report.py | 30秒采集报告工具 (25.5 KB) |

10.3 构建配置参考

VibrationAI_Service.spec 关键配置项:

• 入口脚本: service_entry.py

• 控制台窗口: 禁用 (console=False, 纯后台运行)

• UPX压缩: 启用

• 字节码加密: 未启用 (block_cipher = None)

• 排除模块: tensorflow, torch, pandas, matplotlib, sklearn, onnxruntime, av, sqlalchemy, lxml, openpyxl

• 隐式导入: websockets, aiohttp, cv2, numpy, scipy + app子模块

• 数据文件: Config.ini, default_config.yaml, haarcascade_frontalface_alt2.xml