测试 SayIt 的长时间连续转写稳定性，重点不是单次识别准不准，而是看它在数小时持续运行时是否出现内存增长、延迟劣化、结果漂移和不可自动恢复的异常。这类测试需要先定义“连续”的形态，再按固定流程跑足时长，记录可复现的指标，最后给出通过/不通过的判断。
如果只是拿一段几分钟音频重复播放，测不出连续转写稳定性。真正有效的做法是：构造接近真实使用的长音频或流式输入，连续运行至少 1 到 2 小时，逐段记录转写延迟、内存变化、时间戳偏移和错误码，并验证断流后能否自动恢复。判断标准应基于你自己的业务容忍度，而不是一个固定数值。
一、先确定连续转写的形态
连续转写至少有两种常见形态：一段超长音频文件一次性转写，以及实时音频流持续转写。两者的稳定性风险不同。长音频文件主要看切分和拼接是否正确，实时流则要看网络中断、缓冲区和重连逻辑。开始测试前，先明确你要验证的是哪一种，否则结果无法对照到实际使用场景。
| 形态 | 主要风险 | 测试重点 |
|---|---|---|
| 单文件长音频 | 内存占用、后段漂移 | 整段文件转写，检查分段结果是否连续 |
| 实时音频流 | 断流、延迟累积、自动重连 | 持续推送音频，模拟网络抖动和中断 |
二、准备稳定性测试样本
测试样本不能只用一段干净语音循环播放。建议构造一段 30 分钟以上的混合音频，包含连续语句、句间静音、背景噪声和多人对话片段。如果无法拿到真实录音，可以用多段短音频拼接，但不要在拼接处插入过长的静音，否则会掩盖边界处理问题。音频格式和采样率要与你实际使用保持一致。准备好后，先跑一次短样本确认接入正常，再开始长跑。
三、运行测试：记录哪些指标
长时间稳定性测试要记录以下四类信息：资源占用、识别延迟、错误与重试、结果质量。建议每 10 秒记录一次内存和 CPU，每次转写返回后记录延迟和错误码，每隔一段时间人工抽查转写结果是否出现乱序或重复。不要只记录服务端是否崩溃，很多稳定性问题表现为识别结果逐渐偏离原始音频。
| 指标 | 记录方式 | 异常信号 |
|---|---|---|
| 内存/CPU | 定时采样 | 持续上升不回落 |
| 转写延迟 | 每次调用计时 | 延迟随时间明显增大 |
| 错误码 | 捕获异常和返回码 | 同一种错误反复出现 |
| 结果质量 | 人工抽查或关键词命中 | 时间戳错位、文字跳段 |
四、一个简单的测试循环骨架
以下伪代码用于实时流长测，也可以改造成单文件循环。核心是让时间可控、错误可追踪、资源可采。你需要将 transcribe() 替换为实际接入 SayIt 的方式。
# 伪代码：按实际接入方式调整
import time, json, traceback
def log_metrics(tag, data):
# 写入本地 CSV 或日志系统
print(json.dumps({'tag': tag, 'time': time.time(), **data}))
def run_stability_test(audio_source, duration_minutes):
start = time.time()
errors = 0
while time.time() - start < duration_minutes * 60:
try:
chunk = audio_source.read_chunk()
if not chunk:
break
t0 = time.time()
result = transcribe(chunk) # 替换为 SayIt 接入方式
latency = time.time() - t0
log_metrics('ok', {'latency_s': latency, 'text_len': len(result.get('text', ''))})
# 定期打印内存占用，例如通过 psutil
except Exception as e:
errors += 1
log_metrics('error', {'msg': str(e), 'traceback': traceback.format_exc()})
time.sleep(2) # 等恢复
print('done', {'errors': errors})这段脚本会持续读音频块，调用转写函数，记录延迟和异常。建议不要把它直接用于线上，只作为本地长测控制台。运行时长和音频源通过参数传入。
五、如何判断结果与边界
稳定性测试没有万能阈值。先根据业务容忍度设定失败条件，例如：内存增长超过基线一定幅度且不回落，或 30 分钟内出现多次同一错误码，或转写延迟持续大于业务可接受时间。测试结束后，至少要跑一次短样本，确认没有出现永久性漂移。要注意，测试环境与真实环境不同，样本噪声和网络条件都需要贴近上线环境，否则结果只对当前环境成立。