4、测试执行与数据采集：自动化测试执行、手动测试执行、数据采集规范、日志与截图管理
大家好，我是老张。在量产测试这个行当里摸爬滚打了十几年，今天咱们来聊聊测试执行和数据采集。说实话，很多新人觉得这步就是“跑跑脚本、截截图”，没什么技术含量。但我要告诉你，量产测试的成败，往往就卡在这看似简单的环节上。
为什么这么说？你想想看，一个产品从设计到量产，测试执行是真正“见真章”的时候。自动化脚本跑得再快，数据采得再全，如果执行不规范、日志管理混乱，那根因分析就是无源之水。我见过太多项目，因为截图命名不规范，导致问题复现时找不到对应版本，最后只能重新测试——这浪费的可都是真金白银。
4.1 自动化测试执行：别让脚本“裸奔”
自动化测试，说白了就是用脚本代替人工去重复执行。但很多团队有个误区：脚本写好了，往服务器上一挂，就等着收报告。嗯，这里要注意——自动化测试执行，最怕的就是“黑盒运行”。
我个人习惯，在自动化执行前，一定要做三件事：
- 环境预检：检查测试设备是否在线、固件版本是否匹配、测试夹具是否正常。我曾经有一次，自动化脚本跑了整整一夜，第二天一看，所有结果都是FAIL——原因是测试座的一根探针松了。白白浪费了8个小时。
- 脚本版本锁定：每次执行前，记录脚本的Git commit ID。别小看这一步，量产测试中脚本迭代很快，有时候改了一行代码，测试结果就天差地别。没有版本锁定，你根本不知道问题出在脚本还是产品上。
- 异常中断处理：自动化执行过程中，难免会遇到设备掉线、网络超时、电源异常等情况。我建议在脚本中加入“断点续测”机制——也就是记录当前执行到的测试项，下次启动时从中断处继续，而不是从头再来。
# 一个简单的断点续测示例（Python伪代码）
def run_tests(test_list):
checkpoint = load_checkpoint() # 从文件读取上次执行到的位置
for i, test in enumerate(test_list):
if i < checkpoint:
continue # 跳过已执行的测试项
result = execute_test(test)
save_checkpoint(i) # 每执行完一项就保存进度
if not result:
log_error(test, "测试失败")
# 这里可以决定是继续还是停止
4.2 手动测试执行：人不是机器，但要有机器的严谨
手动测试，听起来很“原始”，但在量产测试中依然不可或缺。特别是对于新产品导入（NPI）阶段，很多异常情况是自动化脚本覆盖不到的。手动测试的核心，不是“人肉执行”，而是标准化操作流程。
我对手动测试执行的要求，可以用四个字概括：“步步留痕”。具体来说：
- 操作步骤必须可复现：每个测试步骤都要有明确的编号和描述。比如“按下电源键3秒”，不能写成“按一下电源键”——3秒和1秒的结果可能完全不同。
- 异常情况必须记录：手动测试中，如果发现预期之外的现象（比如指示灯闪烁频率不对、声音异常等），一定要记录下来。这些“异常”往往是根因分析的突破口。
- 测试顺序不能乱：有些测试项之间有依赖关系，比如先测电压再测电流。如果顺序搞反了，测试结果可能无效。我建议在测试工单上明确标注“前置条件”。
| 测试项 | 操作步骤 | 预期结果 | 实际结果 | 备注 |
|---|---|---|---|---|
| 上电测试 | 连接电源适配器，等待5秒 | 电源指示灯常亮绿色 | 指示灯闪烁红色 | 异常：电压不稳？ |
| 按键测试 | 按下“音量+”键3次 | 屏幕显示音量增加3格 | 显示增加2格 | 异常：按键接触不良？ |
4.3 数据采集规范：没有规矩，不成方圆
数据采集，是测试执行和根因分析之间的桥梁。很多团队在数据采集上吃了大亏——数据采了一大堆，但格式混乱、命名随意，分析时根本没法用。我个人习惯，数据采集必须遵循“三统一”原则：
- 命名统一：测试数据文件的命名，必须包含“产品型号_测试项_日期_版本号”。比如“P100_VoltageTest_20250315_V1.2.csv”。这样一看就知道是什么数据、什么时候测的、哪个版本。
- 格式统一：所有测试数据，尽量使用CSV或JSON格式。Excel虽然方便，但不同版本的Excel兼容性差，而且容易被人为修改。CSV是纯文本，谁都能读。
- 存储统一：数据要集中存储，不能散落在各个测试员的电脑里。我建议搭建一个简单的文件服务器或使用云存储，按“项目/测试批次/测试项”的目录结构存放。
# 数据文件命名示例
# 产品型号：P100
# 测试项：VoltageTest
# 日期：20250315
# 版本号：V1.2
# 文件名：P100_VoltageTest_20250315_V1.2.csv
# CSV文件内容示例
Timestamp, TestItem, Result, Value, Unit
2025-03-15 10:00:01, Voltage_3V3, PASS, 3.31, V
2025-03-15 10:00:02, Voltage_5V0, PASS, 5.02, V
2025-03-15 10:00:03, Voltage_12V, FAIL, 11.85, V
4.4 日志与截图管理：让问题“有图有真相”
日志和截图，是测试执行中最直接的“证据”。但很多团队对日志和截图的管理，可以用“一团糟”来形容。日志文件堆得到处都是，截图命名全是“截图1.png”、“截图2.png”——你想想看，一个月后谁还记得这张截图对应哪个测试项？
我建议，日志和截图的管理要遵循以下规范：
- 日志分级：日志要区分INFO、WARN、ERROR等级别。量产测试中，ERROR级别的日志必须单独提取出来，方便快速定位问题。INFO日志可以保留，但不要和ERROR混在一起。
- 截图自动命名：截图时，程序自动生成文件名，包含“测试项_时间戳_结果”。比如“VoltageTest_20250315_100001_FAIL.png”。这样一看就知道是哪个测试项、什么时间、结果如何。
- 日志与截图关联：在日志中记录截图的文件名。比如在ERROR日志中，加上一行“Screenshot: VoltageTest_20250315_100001_FAIL.png”。这样分析问题时，可以快速找到对应的截图。
# 日志与截图关联示例
[2025-03-15 10:00:03] [ERROR] Voltage_12V test FAIL, value=11.85V, expected=12.0V±0.1V
[2025-03-15 10:00:03] [INFO] Screenshot saved: VoltageTest_20250315_100001_FAIL.png
[2025-03-15 10:00:03] [INFO] Log file: VoltageTest_20250315_100001.log
知识体系总览
说了这么多，咱们来梳理一下本章的核心逻辑。下面这张图，是我自己总结的“测试执行与数据采集”知识体系，希望能帮你建立全局视角。
这张图把咱们今天讲的内容串起来了。你看，自动化执行和手动执行是“两条腿”，数据采集和日志管理是“记录仪”。四条腿的桌子才稳当，缺了任何一条，根因分析都站不住脚。
好了，这一章就到这里。记住：测试执行不是终点，而是根因分析的起点。数据采得规范，问题才能查得明白。咱们下一章见。