第二章：需求分析与测试策略

如何读懂SRS（软件需求规格书）

说实话，很多测试工程师拿到SRS的第一反应就是——直接翻到功能列表，开始写用例。我当年也这么干过，结果呢？漏测了，被开发怼回来重测。

SRS这东西，说白了就是开发、测试、产品三方之间的“合同”。你连合同都没读懂，怎么去验收？我个人习惯，拿到一份SRS，先看三遍：

1. 第一遍：通读。了解系统是干什么的，有哪些模块，输入输出是什么。
2. 第二遍：精读。逐条分析每个需求，特别是“边界条件”和“异常处理”。
3. 第三遍：挑刺。站在测试角度，找SRS里的模糊点、矛盾点、遗漏点。

举个例子，我在项目中遇到过一份SRS，写着“当车速超过120km/h时，系统发出报警”。听起来很清晰对吧？但仔细一想：报警持续多久？报警声音多大？如果车速降到120以下又升上来，还报不报警？这些SRS里都没写。嗯，这就是典型的“需求不完整”。

需求可测试性分析

什么叫可测试性？说白了就是：这个需求，你能不能设计出明确的测试用例来验证它。

我经常跟团队说一句话：“一个不可测试的需求，等于没有需求。”你想想看，如果需求写的是“系统响应要快”，你怎么测？多快算快？1秒？100毫秒？没有量化指标，测试就没法做。

可测试性分析，我一般从这几个维度入手：

维度	问题	示例
明确性	需求是否量化？	“响应时间≤200ms” ✅ vs “响应要快” ❌
可观测性	结果能否被观察到？	报警灯是否点亮，CAN报文是否发出
可控制性	输入条件能否被控制？	车速、温度、电压等能否模拟
可判定性	通过/失败标准是否清晰？	“报警声压级≥85dB” ✅ vs “声音要响” ❌

我曾经遇到过一个需求：“系统在极端环境下应正常工作”。这怎么测？什么叫极端环境？温度？湿度？海拔？后来我拉着开发一起讨论，把“极端环境”拆解成了：-40℃~85℃温度范围、10%~95%湿度范围、海拔0~5000米。你看，这样就能测了。

测试策略制定方法

测试策略，说白了就是回答三个问题：测什么？怎么测？测多少？

我个人的经验是，测试策略不能一刀切。不同模块、不同功能，风险等级不一样，测试深度自然也不一样。我常用的方法是“风险导向测试策略”：

1. 安全相关功能（如AEB、ESC）：必须全覆盖，包括正常、异常、边界、故障注入。这部分我建议做100%的测试覆盖。
2. 核心功能（如空调控制、导航）：主要路径全覆盖，异常路径抽样。覆盖度做到80%以上。
3. 辅助功能（如氛围灯、语音提示）：正常路径覆盖，异常路径选做。覆盖度60%左右。
4. 体验类功能（如UI动画、音效）：以主观评价为主，自动化为辅。

举个例子，我在做某个ADAS项目时，AEB功能我花了60%的测试时间，而氛围灯功能只花了5%。有人问我为什么？我说：AEB失效可能出人命，氛围灯坏了最多被吐槽。这就是风险导向。

测试优先级划分

优先级划分，我习惯用“四象限法”。横轴是“功能重要性”，纵轴是“失效影响程度”：

象限	特征	优先级	示例
第一象限	重要+影响大	P0（最高）	制动系统、转向系统
第二象限	重要+影响小	P1	仪表显示、报警提示
第三象限	不重要+影响大	P1	娱乐系统死机（影响体验但不影响安全）
第四象限	不重要+影响小	P2	主题切换、壁纸设置

你可能会问：为什么“不重要+影响大”也是P1？嗯，这里要注意。娱乐系统死机虽然不影响安全，但用户感知极强。你想想看，车主刚提车，中控屏就卡死了，他第一反应就是“这车质量不行”。所以这类问题，优先级也不能低。

我建议的测试执行顺序是：P0 → P1 → P2。P0的用例必须在第一轮测试中全部执行，P1的用例在第二轮执行，P2的用例如果时间不够可以放到回归测试。

最后说一句，优先级不是一成不变的。项目不同阶段，优先级要动态调整。比如项目初期，P0用例优先；到了回归测试阶段，P1和P2的用例也要提上来，防止回归引入新问题。

好了，这一章就聊到这儿。下一章我们讲讲测试用例设计的具体方法，包括等价类、边界值、场景法这些经典技术。到时候我会结合汽车电子的实际案例，给你讲讲怎么把这些方法用活。