ALM Soft系统内的基线版本，主要功能就是把特定阶段的需求、测试用例、缺陷或者版本资料进行固定；在项目向前推进的过程中，需求会发生更改，测试用例需要补充，缺陷状态也会变化，如果团队不建立基线，后期管理人员就很难说清某个版本当时到底包含哪些具体内容；当基线建立清楚以后，项目团队可以拿它作为评审的依据，大家也可以在需求变更后进行差异对比，从而判断出哪些内容被新增、修改或者删除了。

一、ALM Soft基线版本怎么建立

在建立基线之前，项目人员要先确认这次要冻结哪些具体内容；这些内容可以是一个需求目录，也可以是一个版本下面的全部需求、测试用例和缺陷记录。

　　1、先确定基线范围

　不要一上来就把整个项目全部打进基线里面，因为范围太大的话，后面人员查看和对比都会很不方便；一般情况下，员工可以按照版本节点来做，比如建立“V1.0需求评审基线”、“V1.0测试用例基线”或者“发布前缺陷基线”。

　　2、检查条目状态是否稳定

　　基线并不是临时草稿的备份，负责人最好在内容相对稳定后再进行建立；比如需求条目已经由团队完成了评审，测试用例已经被确认可以执行，缺陷状态也完成了一次整理，在这些时候建立基线才有实际意义；如果大量的条目还处在草稿、待补充或者待确认的状态，那么员工建出来的基线也很难作为后续对比的依据。

　　3、填写基线名称和说明

　　在创建基线的时候，系统操作人员填写的名称要能让人看出版本、范围和时间，例如命名为“V1.0需求评审基线”或者“V1.1测试准备基线”；在说明栏里面，填写人可以写清楚本次基线包含了哪些模块、对应哪次迭代以及由谁进行了确认；大家不要只写“基线1”或者“正式版”这种模糊的名字，时间一长，项目成员很难判断它具体对应哪一次评审或者交付。

　　二、ALM Soft基线版本变更记录怎么追踪

　　1、查看基线对比结果

　　需求或者测试内容发生调整以后，测试人员或者开发人员可以把当前版本和历史基线进行对比；大家要重点查看新增条目、删除条目、字段修改和状态变化；比如某条需求的标题虽然没变，但是它的描述、优先级或者验收条件被改动了，这也要被算作重要变化；大家光看条目数量是不够的，字段内容才是人员判断变更影响的关键。

　　2、追踪变更来源和处理人

　　对于变更记录，管理人员不能只看“改了什么”，还要看“谁改的、什么时候改的、为什么改”；如果ALM Soft软件里面有操作日志、历史记录或者审计记录，用户应该结合这些信息来查看修改人、修改时间以及修改的字段；需求变更最好还能关联到变更申请或者评审记录，不然到了版本验收的时候，很容易出现没人说得清原因的情况。

　　3、检查变更影响范围

　　一条需求被改动以后，可能会对测试用例、缺陷、开发任务和发布说明都产生影响；在追踪变更的时候，人员不能只停留在需求条目本身，还要看它关联的测试用例是否需要同步修改，已经执行的测试结果是不是还有效，相关的缺陷是否需要重新验证；基线对比只是让人员发现变化，而影响分析才是后续处理的重点工作。

　　三、ALM Soft基线版本管理要注意什么

　　1、不要频繁建立无效基线

　　基线并不是每天随手保存一次的普通备份；如果系统里的基线太多，而且命名不清楚，后面的人员反而会更难找到需要的内容；比较合适的做法，是团队在需求评审通过、测试准备完成、版本发布前或者重大变更确认后去建立基线；每一个基线，都应该去对应一个清楚的项目节点。

　　2、基线建立后不要随意覆盖

　　已经被作为评审或者发布依据的基线，操作人员最好不要随意去修改或者覆盖；如果大家发现基线内容有问题，可以建立一个新的修订基线，并在说明里面写清楚修改原因；这样后面的人在查看历史版本时，能看到内容的演变过程，而不是只看到一个被反复改过的最终结果。

　　3、把基线和评审流程结合起来

　　基线如果单独存在，它的价值是很有限的；更好的做法，是团队把它和需求评审、测试评审以及发布评审结合在一起；比如人员在评审前先整理好条目，评审通过后再建立基线，后续的变更再通过记录来进行追踪；这样项目成员能明确知道，哪个版本是已经确认过的，哪个内容是属于后续的变更。

　　总结

　　ALM Soft基线版本在建立时，人员先要确定范围，再检查条目状态，最后填写清楚基线的名称和说明；在变更记录追踪时，大家要通过基线对比去查看新增、删除、修改和状态变化，同时结合操作日志、处理人和关联关系来判断影响范围；团队在进行基线管理时，不要只把它当作存档功能来用，它更像是项目过程中的一个确认点；如果能用好它，需求变更、测试调整和版本交付都会变得更容易被追溯。