2. 车载网络与协议栈基础
做协议栈测试，第一件事不是写代码，是搞清楚你测的东西到底该听谁的。说白了，标准就是裁判。你测出来的结果对不对，不是你自己说了算，是标准说了算。
我这些年踩过的坑，十有八九都是因为对标准理解不透。有一次，一个TCP选项的测试用例怎么都跑不过，折腾了两天，最后发现是RFC里一个勘误更新了我没注意到。嗯，从那以后，我养成了一个习惯：每次开始新项目，先把相关标准的版本号、勘误列表打印出来贴在工位上。
2.1 IETF RFC：互联网协议的基石
RFC（Request for Comments）是互联网工程任务组（IETF）发布的技术文档。别看名字叫“请求评论”，实际上它就是互联网协议的法定标准。从IP、TCP、UDP到HTTP、TLS，全都在RFC里定义。
核心要点：RFC不是一成不变的。它分为几个成熟度等级：
- Proposed Standard —— 提议标准，基本功能已达成共识，但可能还有改动
- Draft Standard —— 草案标准，至少有两个独立实现验证过
- Internet Standard —— 互联网标准，经过广泛验证，最稳定
- Best Current Practice (BCP) —— 最佳实践，告诉你该怎么用
- Informational / Experimental —— 仅供参考或实验，别拿它当测试依据
我个人习惯，做一致性测试时只认 Internet Standard 和 Draft Standard。Proposed Standard 我一般会加个备注，等它升上来了再正式纳入测试基线。
2.1.1 如何快速定位关键RFC
你可能会问：RFC成千上万，我怎么知道该看哪个？我分享一个自己的方法：
- 先找到该协议的 STD编号（STD = Standard）。比如TCP是STD 7，IP是STD 5。
- STD编号会指向一个或多个RFC。比如STD 7指向RFC 9293（TCP）。
- 检查这个RFC是否有 Obsoletes（废弃了哪个旧版）和 Updates（更新了哪个旧版）。
- 去 RFC Errata 页面看勘误。这一步很多人会漏掉。
小技巧：我常用 rfc-editor.org 的搜索功能，直接搜协议名+“standard”。比如搜“TCP standard”，第一个结果通常就是当前有效的标准RFC。
2.2 3GPP协议规范：移动通信的百科全书
如果说RFC是互联网协议的“宪法”，那3GPP规范就是移动通信的“百科全书”。从2G到5G，从无线接入到核心网，3GPP全包了。
3GPP的规范编号有规律，记住这个规律能省很多时间：
| 系列号 | 内容范围 | 我常用的场景 |
|---|---|---|
| 21系列 | 总体要求 | 看架构概览，快速入门 |
| 22系列 | 业务需求 | 理解功能为什么要这么设计 |
| 23系列 | 技术实现 | 核心网流程，比如注册、会话建立 |
| 24系列 | 信令协议（NAS） | 手机和网络之间的消息交互，测试重点 |
| 33系列 | 安全 | 加密、鉴权，一致性测试必看 |
| 36系列 | LTE无线接入 | 4G的物理层、MAC层、RRC层 |
| 38系列 | 5G无线接入 | NR的物理层、MAC层、RRC层 |
举个例子，你要测5G手机的注册流程。那就去翻 TS 24.501（5G NAS协议），里面把每条消息的每个信息元素（IE）都定义得清清楚楚。测试用例的预期结果，就得按这个来。
注意：3GPP规范版本号很重要。同一个规范，Rel-15和Rel-16可能差别很大。我建议测试基线锁定一个版本，比如Rel-17，然后只测这个版本要求的功能。别贪多，否则用例维护成本会失控。
2.3 IEEE 802系列标准：局域网与城域网
IEEE 802系列主要管的是物理层和数据链路层。你平时用的Wi-Fi（802.11）、以太网（802.3）、蓝牙（802.15.1），全都在这个系列里。
做协议栈测试，802系列里我打交道最多的是这几个：
- 802.3 —— 以太网。MAC地址格式、帧结构、流控（PAUSE帧），都是测试重点。
- 802.11 —— Wi-Fi。Beacon帧、关联流程、省电模式，每个都是坑。
- 802.1Q —— VLAN。Tag格式、优先级，交换机互通测试必测。
- 802.1X —— 端口访问控制。认证流程，跟RADIUS配合使用。
我记得有一次做Wi-Fi的省电模式测试，设备在休眠后怎么也唤不醒。查了三天，最后发现是802.11规范里一个TIM（Traffic Indication Map）的bit位顺序理解错了。从那以后，我每次看802.11的帧格式，都会拿笔画一遍bit顺序。
2.4 测试用例的合规性要求
标准看完了，怎么保证你写的测试用例是合规的？我总结了几条硬性要求：
- 可追溯性 —— 每个测试用例必须能追溯到具体的标准条款。我习惯在用例描述里直接写“依据RFC 9293 Section 3.8”或“依据TS 24.501 Clause 5.4.2”。
- 可重复性 —— 同样的环境、同样的步骤，每次跑结果必须一致。如果测试结果有随机性，必须在用例里注明概率分布。
- 可判定性 —— 测试结果只有三种：PASS、FAIL、INCONCLUSIVE。不能有“可能通过”“看起来没问题”这种模糊结论。
- 覆盖完整性 —— 标准里定义的每个必选功能（M）、每个条件必选功能（C），都必须有对应的测试用例。可选功能（O）可以酌情覆盖。
我的经验：合规性不是一次性能做完的。标准会更新，勘误会发布，你的测试基线也得跟着变。我建议每季度做一次标准差异分析，看看有没有新的RFC或3GPP版本发布，然后更新测试用例库。
2.5 知识体系总览
下面这张图是我自己整理的，把本章讲到的标准体系串了起来。你写测试用例时，可以拿它当导航图：
这张图从左到右，展示了三大标准体系如何汇聚到一致性测试用例库。底部的两个黄色说明框，是我建议你额外关注的两个维护动作。标准不是死的，你得跟着它动。
2.6 本章小结
做协议栈测试，标准就是你的“法律依据”。IETF RFC管互联网协议，3GPP规范管移动通信，IEEE 802系列管网域网。每个体系都有自己的编号规则、版本管理和合规要求。
我个人建议，刚开始接触一个新协议时，先花两天时间把相关标准通读一遍。别急着写用例。标准读透了，用例自然就出来了。读不透，后面返工的成本会高得多。
最后分享一个习惯：我每次写完一个测试用例，都会在用例末尾加一行注释，写上“Last reviewed: YYYY-MM-DD, RFC/3GPP version: x.x”。这样半年后回头看，一眼就知道这个用例是不是该更新了。