测试脚本也好，需求也好，一直在变化，如何在变化之后，还能保证追溯的正确性？质量经理需要保证此处的覆盖度是完全的，并且也需要向ASPICE评审老师提供证据。而此处追溯性证据的出示，也是ASPICE评审最耗时的地方之一。ASPICE评审最耗时的地方有哪些，详见 《如何既满足ASPICE要求，又减少开发过程文档》。有没有什么好的方案能解决这个问题？既省时、又准确，还能保证追溯性的建立。Afqednc
是否一定要建立自动化测试用例和需求之间建立追溯性？
这个话题在不同团队内部，应该都经过了反复讨论。一般来说，测试工程师倾向于不去建立这样的追溯性关系。对于他们来说，自动化测试用例的生成过程，就是他们基于对需求的研究，一条条写下来的，他们天然认为测试用例和需求是对应的，再要花时间去建立这种追溯关系多此一举。况且，软件出了问题再改不就行了吗？即使所有需求都关联了测试用例，也无法确保测试用例不会遗漏，因为一条需求可能对应多个测试分支，而关联性无法保证所有分支都被发掘出来了。那为什么不等着软件出问题之后，再去解决呢？
这种想法显然不对，在开发早期发现越多问题，付出的改动成本就越小。但如果为了追求这种早期的覆盖度，而需要付出巨大的精力，这又不得不让我们怀疑，是否可以把这个工作负荷，放到问题出现之后了。
这种巨大的精力来自哪里？不同于手动测试用例，自动化测试用例是由脚本语言来编写的，脚本不同于excel一行一行的，方便建立条目化的对应关系，相反，他们难以与需求之间建立准确的对应关系。由于自动化测试脚本的更新速度很快，而需求也可能产生变化，需求产生变化之后，更新追溯性关系的重任，必然落到测试工程师头上。这是一份相当繁琐且乏味的工作，对于自动化测试工程师来讲，会有巨大的时间压力，特别是当项目比较紧张的时候。
可是，如果站在需求工程师或者项目经理的角度来说，如果无法看到测试用例和需求之间的覆盖度数据，心里会没底。如果需求文档是从甲方客户而来，这种担忧更加明显。甲方客户一般无法知晓乙方的测试用例生成过程和测试执行过程，所以更加需要需求的测试用例覆盖度数据这一“心理安慰剂”（这大概也是ASPICE提出这一要求的原因吧）。
所以，这个问题就变成了是提前做，还是往后放？是在早期就尽可能地建立追溯性关联关系，确保需求没有被遗漏考虑；还是在问题被发现之后，再去debug，更进一步补充测试用例？
我们认为前者有价值，但如果需要付出巨大的劳动和精力去执行，那么投资回报率很低，可能效果还不如后者。那么是否有可能，在不付出那么多精力的情况下，能达到前者的目的？
如何建立自动化测试用例和需求之间的追溯性？
1、在自动化测试用例的注释中，标注对应的需求编号或名称，确保测试用例和需求之间建立了追溯性。
标注需求名称是万万不行的，因为后续很难通过识别需求名称，去确定每一条需求是否被覆盖，从而算出需求覆盖度。
标注需求编号的前提是，需求要有全局唯一的编号。这句话说起来很简单，但很多团队往往做不到。有些团队使用word管理需求，需求没有编号，只有章节号。而章节号会随着章节的增减而自动变化，很快，对应关系便陷入混乱，不可自拔。
有些团队使用excel管理需求，需求编号是根据团队内部的某些规则自己定义的，先不说只要是有人参与的编号就一定会有重名、遗漏的情况出现，就说维护这一套编号的规则，就需要全员讨论、全员正确执行，可能还要出个专门的配置管理员定期审查，显然这不是一套划算的方案。标注需求编号是对的，但前提一定是，需求要有正确的、唯一的编号。
2、获得需求和测试用例之间的矩阵表
手动把上述需求编号和测试用例编号摘出来，做成一张矩阵表。这当然是个方法，但前提是测试用例要有全局唯一的编号。但测试用例是用脚本来维护的，脚本中不会自动生成编号，又回到了上面的困局：人为对测试用例进行编号。缺点参照上面，容易出错，且需要一个配置管理员不时就拉着测试工程师审查一下。测试工程师还不得mmp。
想办法给某一条测试用例，自动赋予全局唯一的编号，并且自动生成上述矩阵表，这是更高效的解题方法。
3、维护矩阵表的正确性
如果是手动获取的矩阵表，当然得手动维护，这时候工作量就大了。
测试用例新增了：需要新增测试用例编号（查一下配置表，找到正确的编号规则，确认目前编到多少号了……），需要对应需求编号（找一下对应的需求）；
测试用例删除了：需要删除无用的测试用例编号，且此编号最好以后都别用了，以免引起混乱，还得确保此处更新，全局更新，如果文件是线下的，譬如这份excel存在多个人的电脑里，这基本就是新的灾难的开始。
想办法确保上述矩阵表能自动更新，当测试用例脚本中不管是新增测试用例，还是删除测试用例，都能自动更新上述表格。且表格应该是基于测试计划的角度来出具的。即这次测试计划测试了多少需求，每一条需求是否对应了测试用例，每一条测试用例是否测试通过，是否发现bug，bug是否解决，按照这样的顺序来出具矩阵表。
按照上面的思路，我们开发的MappingSpace也提供了一个方案，用于管理需求和测试用例，并且自动化地建立它们之间的追溯性。详见下图：
罗宇超，云体科技创始人，软件质量工程师，工具链工程师。
责编：Ricardo
最前沿的电子设计资讯
