TESSY里头的需求追溯怎么去建，覆盖矩阵又要怎么去看，很多人在做嵌入式软件单元测试的时候，都会撞上这类事情。需求追溯这件事，倒不是把需求的编号往测试说明里头一抄就能完事的，它得要串起需求本身、测试对象、测试用例、运行出来的结果，还有报告里的证据这么一整条链子才行。TESSY本身是可以支持需求管理、支持你把需求导进来、让测试用例去引用需求，还能帮你做覆盖分析，再把报告给导出来，这些功能拿过来，正好能帮我们把单元测试的证据理得更清爽一些。

　　一、TESSY需求追溯怎么建立

　　想要在TESSY里面把需求追溯搭起来，重点其实就两个，一是先把需求的来源给弄明白，二是再让需求和测试内容之间形成一种稳稳当当的关系。不少项目追溯做得不好，倒不是因为工具不会用，更多时候是需求编号本身就乱七八糟的，版本也前后对不齐，再不然就是测试用例和需求之间的关系，连自己都解释不清楚。追溯这条链子要是开头就建乱了，那后面哪怕覆盖矩阵看上去填得满满当当，真拿到评审台上去，照样还是讲不明白。

　　1、整理需求基线

　　在开始建需求追溯之前，得先腾出手来把需求的基线给理一理，像需求的编号、叫法、版本，还有当前处在什么状态，这些都要一一去对清楚。而且系统需求、软件需求，还有单元级的需求，可别把它们都搅在一个层级里面用，要不然测试用例在挂接的时候，非常容易就挂错对象。那些已经作废掉的、还没确认下来的，或者根本就没有基线化的需求，最好先别急着往覆盖统计里头放。

　　通过【ReqIF文件】、【CSV文件】或【XML文件】导入需求后，需要检查需求ID、标题、描述和版本字段是否完整。

　　从TESSY这头来看，需求可以从需求管理工具或者文件里头导进来，常见的来源包括DOORS、Jama Connect、Visure、Polarion这些，也支持ReqIF、CSV、XML这些格式。导进来之后，一定得先对着需求列表核一遍，别把旧版本的需求也带进测试项目里来了。

　　在【测试对象】和【测试用例】中维护需求引用关系，让每条测试用例能对应到被验证的需求。

　　做关联的时候，颗粒度得稍微把握一下，别为了把覆盖率数字做得漂亮，就硬把一条测试用例往好几条需求上去挂，那样后面解释起来会很费劲。比较合适的做法，是让这条用例的输入、预期输出，还有判定条件，都能实实在在地撑得起它对应的那条需求。

　　2、执行测试并更新结果

　　需求追溯可不是把链接一建起来就算完事了，它还得跟测试跑出来的结果搁在同一个画面里去看。测试要是压根就没跑过、跑出个失败的结果，或者预期结果本身就写得不清不楚的，这些全都会把需求覆盖的结论给带歪掉。所以项目组在每一轮测试跑完之后，都得同步去更新一下执行状态，别让矩阵一直趴在那堆旧数据上不动。

　　二、TESSY需求覆盖矩阵怎么查看

　　TESSY里头的需求覆盖矩阵，主要就是拿来看哪些需求已经有测试在兜着了、测试到底跑了没、结果是通过还是没通过。看矩阵的时候，眼睛可别只盯着那个覆盖百分比，更要紧的是去留意哪些需求根本就没被覆盖，哪些虽然挂了用例但测试是失败的，还有哪些链接关系看上去就是硬凑的。矩阵真正的用处并不是图一个好看的百分比，而是能很快地把验证上还缺着的地方给揪出来。

　　1、查看覆盖状态

　　进入【requirements coverage view】后，可以查看需求、测试对象、测试用例和执行结果之间的对应关系。

　　这个视图拿来判断当前的需求是不是已经被测过，是很顺手的。测试人员拿它能很快地找出那些还没被覆盖的需求，做评审的人也能从上面一眼就看出来，需求和测试证据之间是不是有断点。

　　2、检查未覆盖需求

　　看到没被覆盖的需求，不一定全是漏测了，也有可能是这些需求处在的那个层级，本来就不太适合拿单元测试去兜。有些系统级的行为，可能放到集成测试或者系统测试里面去验，反倒更对路子。碰到这种情况，就得在报告里把原因给交代明白，别让矩阵上那些空着的地方干晾着。

　　3、检查失败项和未执行项

　　覆盖矩阵里头，要是看到已经挂了用例但测试失败的需求，就得优先去排查测试输入、桩函数、边界值、预期输出，还有判定条件这些地方。还没跑过的用例也得单独处理，因为它最多只能说明追溯关系搭上了，可根本不能证明需求已经被验证过去了。

　　4、导出覆盖报告

　　通过【测试报告】或【V&V矩阵】整理结果时，要保留需求ID、测试用例、执行状态、覆盖结论和异常说明。

　　报告不能只丢一个覆盖率出来就交差，它还得能讲清楚，那些关键需求到底是怎么一步一步给验证掉的。TESSY的相关资料里也提过，报告能把没被测试的需求、测试没执行的需求，还有测试失败的需求都给列出来，这些信息在评审和问题闭环的时候很有用。

　　三、TESSY需求追溯落地时要注意什么

　　TESSY的需求追溯和覆盖矩阵，说到底，最后是要攒出一套以后可以随时翻出来复查的验证证据。在实际项目里头，如果只是在评审前急急忙忙地集中补链接，就容易闹出需求、测试和结果三者之间对不上号的状况。更稳妥的办法，是在做测试设计的那个阶段，就同步把追溯关系给维护起来，等测试一跑完，就赶紧把矩阵和报告更新掉。

　　1、不要把追溯当成后补工作

　　需求这东西一旦有了变更，跟它挨着边的测试用例、预期结果和覆盖矩阵，全都要重新去查一遍。要不然的话，需求早就更新了，测试那头还在跑旧内容，矩阵看着挺满，实际上证据早就没用了。需求变更之后，最起码也要去确认一下，那些被牵连到的用例和已经跑出来的结果，是不是还能站得住。

　　2、保持链接关系可解释

　　需求追溯这个东西，可不是链接拖得越多越好。一条测试用例要是挂上了太多条需求，轮到评审的时候，解释起来反而更费劲。要让追溯清楚一点，每条链接最好都能回答这么一个问题：靠着这些测试输入和预期输出，到底凭啥能说这条需求已经被验证到了。

　　3、结合矩阵和报告使用

　　一般来说，覆盖矩阵适合拿来看总体的一个状态，测试报告更适合去查具体的证据。真正到了评审的时候，你可以先拿矩阵把需求覆盖的大致情况讲一下，然后再用测试日志、执行结果和报告，去细细地讲那些关键需求到底是怎么被验证通过的。这样把证据链串完整了，再去撑ASPICE或者ISO 26262那一类的检查，底气就会足很多。

　　总结

　　总体上讲，TESSY需求追溯的建立和覆盖矩阵的查看，关键并不是把需求编号往测试用例上一挂了事，而是要想办法把需求来源、测试对象、测试用例、执行结果，还有覆盖报告这些环节，全都串成一个闭环。建追溯的时候，得先确认好需求的基线，再去维护一套比较合理的测试链接；看覆盖矩阵的时候，重点就要放在那些没被覆盖的需求、失败的项、还没跑的项，还有各种异常的说明上。只有等到矩阵、报告和测试证据这几样东西能相互撑得住，TESSY里的需求追溯才算是真正有了评审的价值。