从单点验证到整机考验

分享一段文字，避免自己成为高知识低文化的工程师：

人生有很多的选择题，选择适合自己的，选择自己想做的，选择不会让自己后悔的。人生的舞台剧里，做自己人生的主角，演绎自己的人生，别为他人的眼光而活，更不要因畏惧现实而逃避。如果你有梦想的话，就要去捍卫它。那些一事无成的人想告诉你你也成不了大器。如果你有理想的话，就要去努力实现。没有信手拈来的幸福，也没有不劳而获的成功。把每一件简单的事做好就是不简单，把每一件平凡的事做好就是不平凡。专注当下的每一刻，用心做好每一件事，你就会离理想的生活越来越近。

功能测试和系统测试，说白了就是两件事：功能对不对 和系统稳不稳。

功能测试是验证每个功能点是否按规格书跑。系统测试呢，是把所有功能串起来，看整机能不能扛得住真实场景。我见过不少团队，功能测试跑得飞起，一到系统测试就崩------嗯，这里面的坑，我踩过不少。

功能测试用例设计：别漏了边界

功能测试用例设计，核心就四个字：等价类 + 边界值。

举个例子，一个电源模块的输出电压范围是3.0V～5.5V，步进0.1V。你不可能每个电压都测一遍，对吧？

有效等价类：3.0V～5.5V之间任意取几个点，比如3.3V、4.2V、5.0V
无效等价类：低于3.0V（比如2.9V）和高于5.5V（比如5.6V）
边界值：3.0V、3.1V、5.4V、5.5V------这些最容易出问题

我个人习惯：每个功能点至少写3个用例------正常值、边界值、异常值。别嫌多，我吃过亏。有一次一个I2C接口，正常通信没问题，但地址刚好在0x7F边界上，死活读不到数据。查了两天才发现是地址译码逻辑的边界处理有bug。

功能测试用例的模板，我一般这样写：

复制代码

用例编号：FT-001
测试模块：电源管理单元
测试项：输出电压精度
前置条件：输入电压12V，负载电阻10Ω
测试步骤：
  1. 设置目标电压为3.3V
  2. 用万用表测量输出端
  3. 记录实际电压值
预期结果：3.3V ± 1%（即3.267V～3.333V）
实际结果：3.298V
结论：通过

你想想看，如果每个功能点都这么写，后期回归测试会轻松很多。我建议用Excel或TestLink管理用例，方便追溯。

系统集成测试：把零件拼起来看

功能测试是测单个模块，系统集成测试是把所有模块拼在一起，看它们能不能好好相处。

我在项目中遇到过最典型的问题：接口时序不匹配。比如主控芯片的SPI时钟频率是10MHz，但外设只能跑到8MHz。单测时都没问题，一集成就丢数据。

系统集成测试的重点：

接口协议验证：I2C、SPI、UART、CAN等，用示波器抓波形，看时序是否满足双方规格
电源完整性：整机供电时，各模块的电压纹波、上电时序是否正常
信号完整性：高速信号（如DDR、USB）的眼图、抖动是否达标
中断与DMA：多个中断源同时触发时，系统会不会死锁

避坑指南 ：我曾经在一个项目中，两个模块共用同一个中断引脚，但中断触发方式一个是上升沿，一个是下降沿。单测都没问题，集成后一运行就随机死机。查了三天才发现是中断共享逻辑没处理好。所以，集成测试一定要覆盖并发场景。

压力测试：把系统往死里逼

压力测试，说白了就是让系统在极限条件下运行，看它会不会崩。

常见的压力测试场景：

测试类型	典型场景	监控指标
CPU满载	同时运行多个计算密集型任务	CPU温度、频率降频、任务响应时间
内存压力	反复申请和释放大块内存	内存泄漏、碎片化、OOM触发频率
IO压力	持续读写Flash/SD卡	读写速度、错误率、文件系统损坏
网络压力	大量数据包收发	丢包率、延迟、吞吐量
外设并发	所有外设同时工作	总线冲突、中断丢失、数据错乱

我建议压力测试要持续至少72小时。为什么？因为很多问题需要长时间才能暴露出来。比如内存泄漏，可能跑24小时才漏了几KB，但跑72小时就漏了几MB，系统就崩了。

注意：压力测试时一定要监控温度。我见过一个项目，压力测试跑了48小时没问题，但第49小时突然关机。查了半天，是散热设计余量不够，温度累积到临界点触发了过温保护。所以，压力测试时别忘了在关键芯片上贴热电偶。

长时间稳定性测试：跑它个七天七夜

长时间稳定性测试，和压力测试有点像，但侧重点不同。压力测试是「往死里逼」，稳定性测试是模拟真实场景，长时间运行。

比如一个智能家居网关，正常使用时CPU负载也就20%～30%。你不需要让它满载跑，但需要让它连续运行7天、14天甚至30天，看会不会出现：

看门狗误触发：系统明明正常，但看门狗超时复位了
时钟漂移：RTC时间越跑越偏
Flash磨损：频繁写入导致坏块增多
网络重连失败：WiFi断线后重连次数多了，连不上了

我个人习惯，长时间稳定性测试要记录关键日志：

复制代码

# 每10分钟记录一次系统状态
[2025-03-20 08:00:00] CPU: 32%, RAM: 45%, Temp: 42°C, WiFi: connected
[2025-03-20 08:10:00] CPU: 28%, RAM: 46%, Temp: 41°C, WiFi: connected
...
[2025-03-20 18:00:00] CPU: 35%, RAM: 48%, Temp: 43°C, WiFi: connected

如果某一天日志突然断了，或者某个指标出现异常，那就是问题点。

我的经验 ：长时间稳定性测试最容易发现的是资源泄漏 问题。比如每次网络重连都申请一个缓冲区，但释放逻辑有bug。跑一天没问题，跑一周内存就耗尽了。所以，我建议在测试脚本里加一个资源监控，自动记录内存、句柄、线程数的变化趋势。

测试报告怎么写？

测试做完了，报告得写清楚。我一般按这个结构来：

测试概述：测试对象、测试环境、测试时间
测试结果汇总：通过/失败/阻塞的用例数量
详细结果：每个用例的测试数据、截图、波形
问题清单：每个bug的严重等级、复现步骤、根因分析
结论与建议：是否通过测试，有哪些风险需要关注

举个例子，问题清单可以这样写：

复制代码

问题编号：BUG-024
严重等级：严重
模块：WiFi驱动
现象：连续重连50次后，第51次无法连接
复现步骤：
  1. 启动设备，连接WiFi
  2. 断开WiFi，等待5秒
  3. 重复步骤1-2共50次
  4. 第51次尝试连接，返回失败
根因分析：WiFi驱动中连接请求队列未及时清理，队列满后拒绝新请求
修复方案：增加队列清理机制，每次连接完成后释放队列项
验证结果：修复后连续重连200次，未再出现该问题

嗯，到这里，功能测试和系统测试的核心内容就讲完了。记住一句话：功能测试保下限，系统测试保上限。两者缺一不可。

最后一个小建议：测试用例不是写一次就完事了。产品迭代时，一定要回归测试。我见过太多团队，新功能加得爽，旧功能崩得惨。自动化回归测试，能救你的命。