现在很多项目都把需求、测试还有缺陷放进了Polarion系统里，在这种情况下，团队成员之间就不能再用嘴头说或者发个邮件去随便确认改动了。当我们在处理“Polarion变更请求怎么提交、Polarion变更影响范围怎么分析”这些事情的时候，负责人和操作员不应该觉得只要把变更单子填完就没事了，大家主要的任务是让这个变更从最开始提出来、进行分析、找人审批，再到后面去执行和验证，每一个步骤在系统里都能让别人查得到痕迹。Polarion这个软件是专门用来管复杂系统生命周期的，它能够把需求、开发还有测试这些不同的对象都塞进同一个环境里去管理，这也是项目管理中实现变更闭环的一个基础条件。

　　一、Polarion变更请求怎么提交

　　项目成员在提交变更请求之前，第一步需要去确认这个改动到底算不算“必须要走流程的变更”。如果说操作员只是想去修改一个错别字，或者是稍微调整一句说明的话，那么大家通常通过文档修订的功能就可以弄好了；但是如果这个改动会影响到需求的实际内容、验收的标准、测试的范围，又或者是版本的计划和交付的承诺，这时候提交人就必须在系统里提交正式的变更请求了。

　　1、创建变更请求工作项

　　用户可以在具体的工作项目中，去新建一个叫做【Change Request】或者类似名字的工作项。要是大家发现项目的模板里面没有提供这个类型，那就要先让系统管理员去后台配置好工作项的类型、里面的字段、状态的流转还有相关的权限。这里建议大家不要把变更请求和那些普通的任务混在一块用，因为普通任务通常只是让人去关注“接下来要做点什么”，而变更请求

　　2、填写变更请求字段

　　变更请求里面需要填写的字段，一般都会包含【变更原因】、【变更内容】、【提出人】、【影响版本】、【优先级】、【紧急程度】、【关联需求】、【关联缺陷】、【期望完成时间】和【风险说明】这些东西。

字段的条数倒不一定说非要越多越好，但是里面的变更原因、变更内容以及受影响的对象，提交人是必须要写清楚的。

　　3、关联受影响对象

　　大家在提交变更请求的时候，最好在界面上直接去关联好那些相关的需求、测试用例、缺陷、任务或者文档的章节。因为Polarion里面的工作项之间，是可以通过建立链接关系来拼成一条追溯链条的，以后大家去做影响分析还有覆盖率检查的时候，全都要靠这些链接关系来建立基础。

　　二、Polarion变更影响范围怎么分析

　　变更影响分析最核心的逻辑，就是分析员要从某一个修改的点作为起点，顺着系统里的追溯关系，去看看它到底会连累到哪些上游的来源、下游的需求、测试用例、缺陷、任务还有版本。大家在分析的时候，视线不能只盯着当前这一条需求看，还要顺着把整条链路都看一遍才可以。

　　1、从关联需求开始分析

　　分析人员要先在系统里找到这个变更请求所关联的具体需求，然后去检查这一条需求的上游来源和它拆解出来的下游内容。举个例子来说，某一个系统需求要是变了，可能就会让好几个软件需求都受到影响；而一个软件需求如果变了，又可能会让设计项、开发任务和测试用例都跟着发生变化。

　　2、检查测试覆盖影响

　　需求既然已经发生了改变，那么测试人员一般也得跟着去检查测试用例。大家要去看看原来的测试用例还能不能用来验证新的需求，还要想想是不是需要再去多写一些异常的场景、边界的场景、兼容的场景或者是回归测试的范围。在这个时候，测试员可以通过Polarion里面的追溯矩阵和测试报告，去检查需求在实现阶段和验证阶段的覆盖情况。

　　3、查看父子关系和横向关联

　　影响的范围往往不只包括了下游的对象，它连上游和横向的对象也是包括在内的。比方说，某一个软件需求发生了变化，可能反过来就会让系统需求的描述也得跟着改；一个缺陷的修复方案要是变了，可能就会让旁边相邻的模块也受到牵连；或者一个接口的字段要是改了，可能就会让其他依赖这个接口的功能都出问题。

　　三、变更请求提交后怎么闭环跟踪

　　把变更请求提交上去仅仅只是一个开始。后续真正重要的事情，其实是大家有没有对这个变更进行评审、有没有安排人去执行、测试有没有去验证，以及最后有没有在系统里留下一个明确的结论。很多项目的变更最后之所以会陷入失控的状态，并不是因为项目组没有填变更单子，而是因为变更单子提交了之后，根本就没人去管、去维护了。

　　1、配置变更状态流

　　常见的变更状态一般可以设置成【New】、【Under Analysis】、【Approved】、【Rejected】、【In Progress】、【Implemented】、【Verified】还有【Closed】。

这个流程可以根据团队自己的实际情况去进行简化，但是大家在配置的时候，至少得把“待分析、已批准、执行中、已验证、已关闭”这几个关键的节点给区分出来。

　　2、明确审批和责任人

　　变更请求交上去之后，一般需要让产品负责人、需求人员、开发人员、测试人员或者项目负责人一起过来参与评审。那些比较小的变更，可以交由模块的负责人直接审批就行了；但是如果是特别大的变更，那就必须得拿到项目级别上去进行评审。至于这个变更到底算大算小，大家可以根据它的影响范围、风险的等级、版本的计划还有对客户的承诺来综合判断。

　　3、验证后再关闭

　　等到变更全部执行完了之后，操作人员不要马上就去点关闭。大家要先去检查一下关联的需求有没有更新好、测试用例有没有调整过来、相关的缺陷有没有处理掉，以及测试执行的结果到底有没有通过。如果这个地方还牵扯到文档的发布，大家还要去确认一下版本说明、基线或者交付的资料是不是也都同步更新了。

　　总结

　　大家在Polarion里提交变更请求的时候，要把变更的原因、具体的内容、受影响的版本还有关联的对象都写得很清楚，千万不要只提交上去一条含含糊糊的任务。在分析变更影响的范围时，分析员要从关联的需求开始找起，顺着那条追溯关系去挨个检查上游的来源、下游的需求、测试用例、缺陷、任务以及版本的波及情况。只有把这些工作都做好了，变更才不再只是口头上的“稍微改一下需求”，而是能够在系统里形成一条完整的、能够让人去追溯和复查的管理链路。