在进行功能安全测试、嵌入式软件测试，或者是在代码合规交付的时候，C/C++test需求追溯怎么建立，还有C/C++test需求追溯关系断开怎么修复，这些都是经常会遇到的头疼问题。需求追溯这件事情，并不是说只要在报告里面简单地贴上一个需求编号就可以的，而是需要测试人员把需求、测试用例、测试的结果、代码覆盖率、实现文件，还有静态分析出来的结果，把这些信息全部串联起来；通过使用Parasoft DTP这个工具，测试人员可以把ALM或者RMS系统里面的需求，和测试用例、实现文件、静态分析里不合规的地方、代码评审等质量数据，把它们紧密地建立起追溯的关系；在这个过程里面，C/C++test这个工具主要负责把测试、覆盖率和分析的数据产生出来，然后再把这些结果送到DTP里面去进行统一的展示。

　　一、C/C++test需求追溯的建立步骤

　　要想把需求追溯建立起来，测试人员一般要先确定好需求的来源，然后再去做好测试的关联，最后把测试的结果上报上去。如果在前期的阶段里面，测试人员没有把需求的ID和测试用例绑定在一起，那么到了后面的阶段，哪怕扫描和测试全部都跑完了，大家在DTP系统里面也只能看到测试的结果，这样子很难形成真正的需求覆盖关系。

　　1、首先需要确认需求的来源以及DTP的项目

　　测试人员要把需求管理系统里面的需求先准备妥当，这些系统比如有IBM DOORS Next、Jama Connect、Codebeamer、Polarion，或者用Excel、CSV这种表格形式的需求来源也是可以的；C/C++test本身虽然可以参与到需求追溯的工作里，但是在中间的环节中，通常需要借助于DTP把ALM或RMS里的需求、测试的结果，还有覆盖率的数据给组织起来；在Parasoft现有的功能里面，需求可以从ALM工具里获取，也可以从Excel或CSV文件里获取，而且它们能和测试用例、执行的结果建立起双向的追溯关系。

　　2、需要在测试用例里面写进去需求的标识

　　需求和测试之间，必须要有一个固定不变的标识。比较常用的一个做法，就是在测试文件或者测试用例的注释里面，把需求的ID写进去。在执行完测试之后，C/C++test就会把测试结果带上过滤器和构建ID，一起发送到DTP里面，最后再由DTP根据这些拿到的信息去进行处理和展示。

　　3、执行测试并且把结果上传上去

　　当测试的关联关系写好之后，测试人员接下来还要真正地去运行测试，并且把结果上传。如果只在代码里写了req，但是由于疏忽没有去跑单元测试、没有把覆盖率生成出来、也没有把结果发给DTP，那么这个追溯的链条依然是不完整的；C/C++test的追溯工作，一般都需要配合DTP的数据收集功能来开展，在测试场景发生变化的时候，测试人员还需要把DTP报告的功能启用，把任务、需求、缺陷和测试关联好，并且在测试执行的时候要把代码覆盖率的开关打开。

　　二、C/C++test需求追溯关系断开的原因分析

　　追溯关系要是断开了，这并不一定就是C/C++test扫描失败造成的。很多时候测试的结果明明还在，代码覆盖率也存在，但是需求、测试、结果这三者之间的“钥匙”却对不上了；这个所谓的钥匙，有可能是需求的ID，也有可能是DTP的项目、过滤器、构建ID、测试的名称，或者是ALM的连接配置。

　　1、需求的ID或者是测试的注释发生了改变

　　最容易碰到的问题，就是需求的ID被人改动了。比如在ALM系统里面，它原来叫做REQ-1024，但是后来因为迁移了需求库，它变成了SYS-REQ-1024，结果测试代码里面却还写着以前的旧ID；这样一来，DTP在处理数据的时候就找不到对应的需求，追溯的关系自然而然就断开了。

　　2、DTP的项目、过滤器或者是构建ID对不上

　　做追溯不能只单单依靠需求的ID。DTP还需要按照项目、过滤器、构建等信息来把结果组织好；在Polarion的集成说明里面也有提到过，DTP会去寻找那些和过滤器Id以及构建Id相匹配的测试结果，然后再把这些结果同步到外面的系统里去。如果CI流水线里面换了构建ID的生成规则，或者DTP的过滤器指向了另外一个项目的范围，就会导致数据虽然已经上传了，但是在当前的追溯报表里就是看不到。

　　3、ALM或RMS的连接出了问题，或者同步的配置有异常

　　需求的追溯还要依赖于外部的需求系统。如果ALM的令牌失效了、项目的映射关系变了，或者需求类型的过滤条件被动过了，DTP就没有办法拿到最新的需求；DTP能做需求追溯的一个大前提，就是测试人员已经把外部ALM或RMS的连接配置好了，而且外部的系统里面确实存在对应的需求或者工作项。

　　三、C/C++test需求追溯关系断开后的修复办法

　　在修复追溯关系的时候，不建议测试人员一上来就把所有的测试都重新做一遍。大家应当先去判断一下，到底是需求没有进到DTP里、测试没有带上需求ID、结果没有上传成功，还是报表里面的筛选条件选错了；这几类问题虽然表面上看起来差不多，但是解决的办法是不一样的。

　　1、首先需要核对需求那一端是否处于正常状态

　　测试人员要先在DTP或者需求视图里面，确认一下需求到底在不在，它的ID和测试代码里写的是不是一样的。如果需求系统里面已经改了号，那么测试人员就要把测试代码里的req统一进行更新；不要在一部分的测试里写旧的ID，在另一部分里又写新的ID，这样搞的话，后面出来的追溯矩阵会变得非常混乱。

　　2、接着检查测试用例里面的关联是否还存在

　　需求端确认没有问题之后，测试人员再去查看测试文件。这里要重点检查req和test这两个注释，看看它们是不是还在正确的测试用例上面挂着；平时的测试重构、文件搬家、批量格式化代码，或者自动生成测试更新这些操作，都很容易把这些注释给弄丢。

3、最后检查结果的上传情况以及报表的筛选条件

　　要是测试和需求两边看下来都没问题，测试人员就要看看执行的结果有没有成功进到DTP系统里。在命令行里面，测试人员要确认-publish、DTP的地址、项目的名字、构建ID，还有过滤器相关的设置是不是全都是正确的；等运行结束之后，先去看看DTP的Test Explorer或者对应的测试结果页面，确认测试的数据确实已经进来了，接下来再去查看需求追溯的报表。C/C++test在和DTP配合使用的时候，测试人员可以通过DTP的仪表板、报表和可视化组件，把这些追溯信息都查看清楚。

　　总结

　　要把C/C++test需求追溯成功建立起来，关键的地方就在于三步：首先要让DTP能够顺利拿到ALM或RMS里面的需求，接着在测试用例里通过写上固定不变的需求ID把关联搭起来，最后去执行测试、把覆盖率采集到，并把结果上传给DTP；这样折腾完，才能形成从需求到测试、从测试到结果、从结果到覆盖率和代码的闭环。