在需求评审结束之后，还是可能发生字段被修改、有新的条目加入，或者某些内容被删除的情况。要了解在Polarion里面怎么对基线进行对比，以及基线之间的差异又该怎么导出来，关键的地方就在于，先把某个阶段的版本固定成一版基准，然后去拿同一份在线文档在两个不同时间点的状态来做比较。较早的时候Polarion已经能够支持项目级别的基线了，而到了ALM 19.2这个版本，它又新增了文档基线，专门用来保存单独一份LiveDoc在某个节点上的快照。

　　一、Polarion怎么做基线比较

　　做基线比较以前，得先想好这次要对比的，到底是单独一份需求文档，还是整个项目里的所有内容。如果只是核对单份文档的改动，那优先去用文档基线会比较方便；要是为了整个版本的评审，或者想把某个阶段的状态固定下来留个档，就可以把项目基线或者集合基线结合起来用。

　　1、先去创建一条文档基线

　　把你要处理的那份在线文档给打开，然后在文档操作的那个菜单里找到跟基线有关的入口，在里面就可以新建一条文档基线了。建的时候，记得填上名称和简单的说明，像“V1.2需求评审通过”或者“V1.2测试启动”这种，不要把名字只写成baseline1，要不然隔了几个月以后，自己都不知道这条基线当初是用来干嘛的了。

　　2、到历史记录里面去查看

　　打开目标文档以后，点进它的历史记录页面，在那里可以看到以前每一次修订的记录，还有那些已经被保存下来的文档基线。按照Polarion官方的介绍，在文档历史这个界面里，是能够单独把文档基线给筛出来的，同时它也会把包含了这份文档的那些项目基线一块儿显示出来。

　　3、挑出想要对比的两个版本

　　在历史记录里头，把那个旧基线和当前最新的文档选中，或者也可以挑出两个不同阶段的基线，然后去点一下比较的功能。等比较页面一出来，新加入的内容、被删掉的部分，还有哪里被修改过，都会用不同的标记突出显示出来。Polarion本身是比较早就支持文档比较了，后面在LiveDoc Compare的加载性能上也一直在做优化。

　　4、用集合来统一管理多个文档

　　如果某一次评审会同时牵涉到系统需求、软件需求，还有测试规格书等好几份文档，那就可以把这些相关的文档修订版都放进一个集合里面去。集合这东西能把文档的修订版，还有基线的组合给存下来，而且还可以继续在它的基础上建一条集合基线，这样就能很方便地把那个阶段的所有文档快照都固定住。

　　二、Polarion基线差异怎么导出

　　差异到底要怎么导出来，主要还是看你拿它去干什么。如果是为了开评审会，需要在会上给大家看哪些地方被改动过，那就优先把那个比较页面给导出来；要是为了整理变更台账，那就再单独补上一份表格形式的记录。

　　1、先把包含差异的比较页面给打开

　　当你在历史记录里选好了要比较的基线之后，系统就会进到文档比较的视图里面去，这个时候先确认一下，页面上是不是已经把新增的、删除的，还有被修改过的内容，都用对应的标记给标出来了。在导出之前，最好随便在里面抽几条变化比较大的需求，确认一下比较的对象没有弄错。

　　2、把比较结果导出成PDF文件留下来

　　在比较页面里头，可以用它自带的导出PDF功能，把这份带着差异标记的结果给保存下来。按照Polarion官方发布说明里的说法，文档比较这个功能是支持导出成PDF的，而且那些用来标出差异的高亮效果，也会一起进到导出来的文件里面去。

　　3、如果需要表格形式，就去导出工作项

　　有时候，团队是需要把需求的编号、标题、当前的状态、负责人，还有修改的说明这些东西，整整齐齐地理成一份台账的。这个时候就可以进到工作项的表格视图里面，先把这一次评审所涉及到的那些条目给筛出来，然后再用导出功能把它们输出成Excel表格。Polarion官方的功能说明里也提到，表格是支持只把手工选中的那些工作项给导出去的，这样就能很方便地控制导出范围的大小。

　　4、把这次比较的两头是什么都给写清楚

　　不管最后导出来的是PDF文件还是Excel表格，给它们起名字的时候，最好把项目的名字、文档的名字、旧基线是哪一版、新基线是哪一版，还有导出的日期，这些信息都加到文件名里面去。另外，在文件本身的内容里头，也要记得写明白这次比较的范围，免得后面拿错了版本，又得回头来翻。

　　三、Polarion基线差异导出后怎么检查

　　差异文件被顺利地导出来了以后，还不能算完事，最好再找时间做一次复核。有可能页面看起来已经被好好地导出了，但这里面全部的修改，可不一定都已经正式地进了变更流程。

　　1、查一下新增和删除的那些条目是否都有记录

　　那些被新加上去的需求，要确认一下它们有没有写清楚来源、谁来负责，还有打算用什么方式去验证；而如果有哪些需求被整个删掉了，那也一定要在记录里写明删除的原因，不能光是在比较页面里面看到一条删除线就算交代过去了。

　　2、看看条目之间的链接关系还是不是对的

　　一旦需求本身的内容被改动了，就要去顺带着看一眼它跟上游、下游之间那些追踪关系，看看是不是还连得通。如果在管理的时候有用到集合，那还可以顺便检查一下，在这个集合内部，从文档到工作项之间的那些链接，是不是还都指向着正确的版本。

　　3、把那些关键阶段的基线给保留下来

　　像需求冻结、测试启动、发布确认这些重要的时间节点，每个节点留下一条基线就够用了。不要把基线建得太密集，要不然等到后面真要去比较的时候，会增加不少工作量，而且也不利于快速地找到某两个阶段之间的差异到底在哪里。

　　4、团队里面最好统一一下命名的规则

　　大家应该提前约好，基线起名字的时候用什么格式，说明信息要填到什么程度，还有导出来的文件叫什么。这样的话，那些负责评审的人一打开文件，就能直接看得出来这回比较的是哪个阶段跟哪个阶段，不用再重新登回系统里去一条一条地确认。

　　总结

　　所以，简单地讲，要想在Polarion里面对基线做比较，再把基线之间的差异导出，通常的步骤就是先建好文档基线，然后进到历史记录里面挑出你要比的两个版本，点一下比较，最后把差异页面用PDF的方式给导出来。如果同时涉及到好多份在线文档，还可以借助集合基线来把各个阶段的快照都管起来；要是需要整理变更台账，就再单独把工作项的表格导出一次就好。只有把这些基线文件、差异结果，还有变更的原因都一起保留好，需求所经历过的那些改动才能真正变成一条条能追查到底的记录。