当项目进入测试阶段以后，缺陷的数量往往会一天比一天多。如果只在一个单独的缺陷列表里面记录这些问题的内容，却没有把每一条缺陷和它对应的需求、测试用例、执行的记录连在一起，那么到了后面就很难判断某一条需求是不是已经被完整地验证过、还有没有遗漏的地方。ALM这类管理平台，通常是支持把一条缺陷跟需求、测试、测试集、执行实例，甚至跟其他相关的缺陷都关联起来的。下面会围绕着ALM里面比较常见的缺陷管理界面进行说明，不过具体的按钮名称可能会因为软件版本、或者企业做过一些定制化的字段设置，在细节上稍微有出入。

　　一、缺陷关联应该怎么建立起来

　　建立缺陷关联，常用的入口一般有两个。一个是从需求页面那里，直接去新建一条缺陷；另一个是给已经存在的缺陷，去补充它跟需求之间的关系。在项目刚刚发现问题的时候，比较建议的做法是从当前正在操作的那个测试对象那里进去，这样做能够减少把缺陷关联到错误需求上的情况。

　　1、直接在需求页面上新建一条关联的缺陷

　　先进入【Requirements】这个模块，在需求树的结构里面，用鼠标选中那一条目标需求，然后打开它下面那个【Linked Defects】的标签页。在这个页面里，点击【Add and Link Defect】这个按钮，接着在弹出的表单里面，把缺陷的标题填好，把严重程度选好，指定一下由谁负责，再把问题是怎么复现出来的步骤写清楚，必要时把截图或附件也添上，然后保存这一条缺陷。这样新建出来的缺陷，就会直接挂到当前这条需求下面，关联关系也同时建立好了。按照官方帮助里面的说明，Linked Defects这个标签页不但支持新建一条缺陷，并且同时把它关联起来，也支持去关联一条已经存在的缺陷。

　　2、把原来就有的缺陷关联到需求上

　　如果某条缺陷已经在【Defects】这个模块里面被创建过了，那就不要再为了关联关系而去新建一条重复的单子。可以先回到目标需求那里，在【Linked Defects】这个标签页里面，去点击【Link Existing Defect】这个按钮，然后按照缺陷的ID去搜索，或者从弹出的列表里直接把现有的那条缺陷选出来。等确认好关联关系以后，最好再打开那条缺陷的详情页面，核对一下它挂载的需求编号，跟缺陷里面描述的内容是不是真的能对应得上，防止关联错了对象。

　　3、从缺陷这一边反向去建立关系

　　在有些版本里面，是支持在缺陷的详情界面里，找到【Link Entities】这种功能入口，然后去选择需要被关联的需求的。这个入口比较适合这样一种场景：测试人员先把手头的缺陷提交上去，之后再由需求的负责人来补充它跟需求之间的关系。Web Runner相关的帮助资料里面也提到了，缺陷页面可以通过Link Entities这个功能，去关联其他的缺陷，或者是关联需求。

　　二、缺陷跟需求的关联要怎么去检查

　　在把关联关系建好之后，不能仅仅在缺陷的页面上粗略地看到有一行链接，就觉得万事大吉了。还要再去确认一下需求、测试，还有执行出来的结果，这几样东西之间是不是真的能够串得起来，形成一条完整的追溯链条。

　　1、从需求树里面去检查已关联的缺陷

　　先回到【Requirements】这个模块，在需求树里选中那一条目标需求，再把下面【Linked Defects】这个标签页打开。在这个页面里面，去检查每一条关联缺陷的ID、当前的状态、严重程度、由谁负责，还有最后更新的时间是不是正常。当需求发生变更的时候，就可以借助这些缺陷的关联关系，比较快速地判断出来，哪些已经发现的问题、哪些测试、还有哪些具体的人会受到这次变更的影响。官方的帮助文档里，也把缺陷关联当作是需求合规检查，以及测试可追溯性的一部分。

　　2、通过筛选的功能去查找漏掉的项目

　　在需求这个模块里面，把【Filter】这个筛选功能打开，按照缺陷之间的关系去筛选需求。可以重点去找那些没有关联任何缺陷的高风险需求，或者反过来，查看那些已经关联了好几个还没关闭的缺陷的需求，看看是不是有集中的问题暴露。ALM的筛选器支持按照直接关联缺陷，或者间接关联缺陷这两种方式，去把需求过滤出来，在集中检查的时候会比较方便。

　　3、生成一份关联关系的报告

　　如果到了要做评审，或者阶段汇报的时候，可以用项目报告功能里面的【Requirements with Linked Defects】这种预置的报告。这类报告会把当前需求视图里面的那些需求，以及它们各自对应挂载的缺陷，一起拉出来列成清单，比较适合用来集中检查有没有什么地方该关联的却遗漏了、有没有重复关联的情况，以及有哪些缺陷是挂在那里长期没有关闭的。

　　三、缺陷关联容易出现哪些方面的问题

　　关联关系如果建立得过于随意，到了项目后期，数据就会变得越来越乱，追溯的时候理不清头绪。尤其是在好几个人一起协作的项目里面，最好是提前把填写的口径和规则统一一下，大家按同一套标准来执行。

　　1、不要把同一个缺陷在不同的地方重复新建很多次

　　当同一个底层的问题，出现在了不同的测试步骤、或者不同的页面上的时候，优先去关联那一条已经存在的缺陷，而不要在每个页面都重新去新建一条。否则，同一种问题被拆散成了好几条独立的单子，各自的缺陷状态、修复的版本，还有回归测试的结果就会分散在不同的地方，后面要拼起来看全貌就非常费劲了。

　　2、注意把直接关联和间接关联区分开来

　　缺陷可以直接挂载在需求上面，也有可能通过测试、执行的实例，又或者是运行的步骤，间接地跟需求产生关联。在检查的时候，要看清楚这条链接的来源到底是什么。直接链接通常更适合用来表示，这个需求本身确实存在风险；而间接链接则更适合用来说明，是某一次测试执行的动作发现了这个问题，侧重点是不一样的。

　　3、不要依赖历史的版本去自动保存这些关系

　　ALM里面实体的版本控制功能，它保存的是每一个单独实体的历史快照，而需求的覆盖率、追踪的关系，还有缺陷的链接这些东西，并不会跟着被完整保存在旧版本当中。所以在需求基线建立之前、发布节点到来之前，以及每一次重要变更发生之前，要单独地把关联报告导出来，或者建立一份基线，把这些关系固定下来。

　　总结

　　ALM里面软缺陷的关联要怎么建立，以及缺陷跟需求的关联要怎么去检查，整个操作的顺序可以简单概括为：先进入需求页面下的【Linked Defects】，选择是新建一条关联缺陷，还是去关联一条已经存在的缺陷；然后再通过需求树、筛选器，还有关联报告，去检查拿到的结果。在项目进行的过程当中，要尽量减少重复建单的情况，把直接关联和间接关联分开对待，并且在重要的节点上，把报告或者基线保留下来。这样一来，需求、测试还有缺陷这三块内容，才能形成一条完整的可追溯链路，后期评审和排查问题的时候也才有据可查。