2、需求分析与评审：如何阅读TCU系统需求规范、需求可测试性分析、需求评审流程与 checklist

好，咱们进入第二个章节。说实话，很多测试工程师一上来就闷头写用例，结果测到一半发现需求根本不对——这种事我见过太多次了。所以今天咱们聊聊需求分析与评审。说白了，这是整个测试工作的地基。地基没打好，后面盖的楼再漂亮也得塌。

2.1 如何阅读TCU系统需求规范

拿到一份TCU系统需求规范，你第一反应是什么？我个人的习惯是，先别急着逐字逐句读。先翻目录，看结构。一份好的需求规范，通常包含以下几个核心部分：

• 功能需求：比如换挡策略、扭矩管理、故障诊断
• 性能需求：换挡时间、响应延迟、精度要求
• 接口需求：CAN/LIN信号定义、传感器/执行器接口
• 安全需求：ASIL等级、安全机制、故障响应
• 诊断需求：DTC定义、故障确认/恢复条件

嗯，这里要注意。很多需求规范写得像天书，尤其是那些从客户那边直接翻译过来的。我遇到过一份需求，里面写着「变速箱应在适当条件下执行换挡」——你想想看，什么叫「适当条件」？这种需求，你根本没法测。

我建议你读需求时，手里拿支笔。每读一条，就问自己三个问题：

1. 这条需求到底想让我测什么？
2. 我能不能设计出至少一个测试用例来验证它？
3. 如果测不过，我能不能明确判断是软件bug还是需求本身有问题？

举个例子。需求里写「当车速超过30km/h时，禁止挂入R挡」。这条就很好——车速阈值明确，动作明确，结果明确。但如果是「在适当情况下，系统应优先考虑驾驶舒适性」——嗯，这种需求我一般会直接标红，要求需求方给出量化定义。

2.2 需求可测试性分析

可测试性分析，说白了就是判断一条需求能不能被验证。我见过太多项目，需求写得天花乱坠，一到测试阶段全傻眼。为什么会这样？因为写需求的人根本没想过怎么测。

我个人把需求的可测试性分成三个等级：

等级	描述	例子
可测试	有明确的输入、条件、预期输出	「当油温>120°C时，激活降扭请求」
部分可测试	需要进一步分解或补充条件	「换挡过程应平顺」——需要定义平顺的量化指标
不可测试	无法设计测试用例	「系统应具有优秀的可靠性」——什么叫优秀？

做可测试性分析时，我习惯用下面这个checklist快速过一遍：

• 输入条件是否明确？（比如车速、油温、挡位信号）
• 触发条件是否可模拟？（比如故障注入、边界条件）
• 预期结果是否可观测？（比如CAN信号、诊断码、物理动作）
• 时间约束是否可测量？（比如换挡时间、响应延迟）
• 是否存在主观判断？（比如「舒适」「平顺」「合理」）

你想想看，如果一条需求在这五个问题上都答不上来，那它基本就是废的。我建议你在需求评审时，直接拿这个checklist一条条过，效率会高很多。

2.3 需求评审流程与checklist

需求评审不是走过场。我参加过太多评审会，大家坐在一起，翻翻文档，说几句「没问题」，然后就散了。结果呢？后面测试阶段发现需求漏洞，改起来成本翻十倍。

一个正经的需求评审流程，我建议分三步走：

第一步：预审（个人审查）

评审会之前，每个人先自己看一遍需求。我一般会花2-3小时，把需求规范从头到尾过一遍，把有疑问的地方标出来。这一步很重要——别指望在会上现场读需求，那根本来不及思考。

第二步：评审会（集体讨论）

会上不要逐条读需求，那太浪费时间。直接聚焦有争议的地方。我习惯的做法是：每个人先提出自己标红的问题，然后逐条讨论。讨论的重点不是「对不对」，而是「能不能测」。

第三步：跟踪闭环

评审会开完，一定要有action item。谁负责修改？什么时候改完？改完之后谁来确认？没有闭环的评审，等于没评。

下面是我个人一直在用的需求评审checklist，分享给你：

检查项	说明	通过标准
完整性	是否覆盖所有功能场景？	无遗漏的功能或边界条件
一致性	需求之间是否有矛盾？	无逻辑冲突或重复定义
可测试性	每条需求是否能设计测试用例？	至少一个明确的测试场景
无歧义	描述是否清晰、无主观词汇？	无「适当」「合理」「可能」等模糊词
可追溯	是否关联到更高层需求或系统需求？	有明确的追溯关系
可行性	在当前硬件/软件架构下是否可实现？	无技术不可行的需求

嗯，最后说一句。需求评审不是测试团队单方面的事。我建议你把开发、系统、甚至客户都拉进来。我曾经在一个项目里，因为一条需求的理解偏差，测试和开发吵了三天。后来把客户请来一问，人家根本不是那个意思。所以，评审会上多拉几个人，没坏处。

好，这一章就到这儿。下一章咱们聊聊测试策略设计——怎么从需求出发，搭出一套完整的测试框架。到时候我会拿一个真实的TCU项目案例来讲，保证干货满满。