当项目进入测试、验收和发布这些环节之后，要是还单靠一份任务清单，其实很难看出来那些关键的时间点是不是已经偏离了原来的计划，所以关于在ALM Soft里面怎么去设置里程碑，以及里程碑要是延期了又该怎么发出预警，就需要把截止日期、交付内容的范围，还有各项关键指标的门限值摆在一起去配置；里程碑跟一般的普通任务不一样，它更像是摆在发布时间线上的一个个检查站，专门用来判断像代码冻结、集成测试收尾、版本正式发布这样的节点，是不是真的满足了可以往下一个阶段走进去的条件。

当测试用例进入了执行这个环节以后，项目组里头最让人悬心的状况，往往就集中在两点上：第一点是任务虽然已经分派下去了，但到底哪些人还没有真正动手去做，完全没人能说得清楚；第二点则是跑出来的各种测试结果散落在不同的地方，有的记在电子表格里，有的留在聊天记录里，还有的夹杂在一大堆截图后面，等到版本评审需要汇总数据的时候，只能临时去到处拼凑，既费功夫又特别容易出错。

项目一旦到了测试环节或者要对外交付的阶段，跟发布有关的记录就不能只留一个干巴巴的版本号了事。ALM Soft这类工具里的发布记录，到底该怎么去维护，后续又要怎样往回查某个发布版本的信息，这个过程里面最重要的事情，是把每一次发布到底纳入了哪些内容、涉及哪些需求、修了哪些缺陷、测试的结果是什么样的，以及最后交出去的那些东西，全都串在同一条链条上。不同的部署版本中，菜单的叫法也许会有一些出入，所以下面我就按照比较常见的ALM发布管理流程来把这些理清楚。很多这一类的平台，都会用Release和Cycle来组织发布的批次，同时它也支持把需求、测试集合和缺陷直接挂到对应的版本下面去。

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

需求评审结束之后，如果还是允许所有人随时去改动的话，后面就很难说得清楚哪些内容是已经确认好的，哪些又是后来新增或者调整过的。要把ALM Soft里面的需求基线管理好，以及基线变更的时候怎么留下可靠的痕迹，关键的一点，就是把“单条需求的版本记录”和“某个阶段的整体快照”这两种东西分开来处理。不同ALM平台的菜单名称会有些差别，下面就以OpenText ALM里常见的操作逻辑来举例。OpenText ALM的Requirements模块可以持续去管理和跟踪需求，基线的作用则是保存某一个时间点上的项目内容。

这里按OpenText ALM也就是OpenText Application Quality Management来写。官方当前文档给出的口径很明确，ALM和Jira的同步是通过Connect来做，Connect可以同步Stories、Requirements、Tasks这一类资产；ALM这一侧的AQM连接器支持Requirements、Defects、Tests以及自定义字段。也就是说，真正落地时不是在ALM里单独开一个Jira开关，而是先准备Connect，再分别定义ALM和Jira两端的数据源与连接。

很多团队在用ALM提缺陷时，问题往往不在“有没有提”，而在“提得能不能直接流转”。OpenText ALM的【Defects】模块本身就是用来创建和跟踪缺陷的，既支持在缺陷模块里新建，也支持在测试执行过程中直接提交；如果缺陷是在测试集运行时提交，系统还会自动把这条缺陷和对应的运行、发布与周期信息关联起来。

很多团队把ALM用起来以后，最先乱掉的往往不是执行本身，而是Test Plan和Test Lab的边界没有先定清。按OpenText ALM当前官方说明，Test Plan的职责是按功能拆出测试主题、测试用例、步骤和配置，并建立需求覆盖；Test Lab的职责则是把已经设计好的测试按版本、周期和目标拉进测试集执行，同一个测试被加入测试集后，会以test instance的形式存在。先把这两层分开，后面目录、批量执行和结果回看才不容易打架。

很多团队在ALM里把需求、史诗、功能、用户故事都堆进一个层级里，表面上看是“信息都在一起了”，实际一到排期、拆分、追踪测试覆盖，就会发现上下层语义混了。以OpenText ALM Octane和ValueEdge的工作模型来看，需求模块和Backlog模块本来就是两套不同视角：需求模块更适合沉淀正式需求和长期结构，Backlog模块更适合承接史诗、功能和用户故事这类交付项。Requirements模块本身支持文件夹和需求文档的树状层级，Backlog模块则明确是Epic在上、Feature在中、User Story在下的交付层关系。

这里按OpenText ALM的需求模块来写。官方帮助里把这套逻辑讲得很清楚：需求先放在Requirements模块的树形结构里管理，再通过需求类型、系统字段、自定义字段、发布周期和覆盖关系把后续测试与交付串起来。也就是说，ALM里的需求管理不是先堆字段，而是先定树、再定类型、最后定规则。