需求数量慢慢多起来以后，如果还是一条一条地点开去改工作项，很容易就把时间全花在重复操作上了。其实像状态的切换、负责人的调整、版本信息的更新、优先级的变动，还有标签的补充这一类修改，完全可以借助Polarion里面的批量操作功能来集中处理，不用在每个条目上反复做同样的动作。

　　一、Polarion里面怎么批量修改工作项

　　在做批量操作之前，比较重要的一步是先用查询条件把范围收窄，不要直接在完整的项目列表里去做大批量的改动。特别是状态、负责人和版本这几个字段，万一不小心把范围之外的工作项也一块改掉了，后面想要回查哪些是被误伤的，会非常麻烦。

　　1、先筛选出要处理的目标工作项

　　进入项目对应的【Work Items】页面，借助页面上方的查询栏或者筛选器，把工作项的类型、当前的状态、负责人、所在的版本，还有标签这些维度都限定好，让列表只显示这一次想要处理的那一批条目。在筛选结果出来以后，别急着马上动手，先随手抽查几条，确认列表里面没有混进其他模块的数据，也没有把历史版本里那些已经关闭的旧条目给带进来，确认范围没错再往下走。

　　2、用批量编辑功能统一改同一个值

　　在筛选好的列表里面，把真正需要修改的那些工作项前面的复选框勾上，然后去工具栏里找到【Bulk Edit】或者名称类似的批量修改入口。在这个界面里，选择这一次打算调整哪个字段，再填上一个统一的目标值就可以了，比如把一批新发现的缺陷全部分配给同一位负责人，或者把同一轮迭代产生的需求统一归到某个版本号下面。这种方式特别适合处理那种多条工作项要写入完全相同的属性值的情况，操作简单而且不容易漏。

　　3、在表格视图里连续编辑不同的内容

　　有些时候，每条工作项虽然都需要改，但需要改成的新值并不是一模一样的，比如每条工作项的负责人都不相同，或者各自的优先级、计划版本和自定义字段要单独填写。这种情况下，可以把界面切换到表格视图，打开可编辑模式，直接在表格里像操作Excel那样逐行去修改对应的单元格，全部改完之后再一次性保存。Polarion的功能矩阵里面也明确写了，支持在表格界面里进行批量编辑，并且能够一次保存多条工作项的修改，效率比一条一条点开去改要高得多。

　　4、保存之前再做一次抽查

　　在把批量修改的结果正式保存下去之前，至少还是要扫一眼即将被修改的工作项数量对不对、选的字段名称有没有看串行、要填的新值是不是准确。特别是状态这一类字段，如果改错了范围，可能会一下子触发一大堆工作流、通知，或者还有一些审批条件也会被同时激活，波及面会比较大。一旦发现之前筛选的范围不太对，就先取消当前的操作，重新回到筛选那一步再调整一遍，比事后去修补要省心。

　　二、Polarion工作项的批改记录要怎么追踪

　　在Polarion里把工作项改完之后，不能光看当前页面显示出来的结果就觉得没事了。到了项目评审、需求变更评审或者质量复盘这些场合，经常还要跟别人说明：这一条在上次修改之前状态是什么、当时是谁执行了这次修改、又是出于什么原因才把它改掉的。这些信息都要依赖系统的历史记录来支撑，而不是凭印象去解释。

　　1、查看单条工作项的修改历史

　　随便打开一条被修改过的工作项，进到【History】或者跟历史记录相关的区域，就能看到每一项字段在什么时间、被哪个人从什么旧值改成了什么新值。如果修改涉及到了状态、负责人、描述内容或者跟其他条目的关联关系，一般建议优先从这里开始核对，因为信息比较详细，改了什么一目了然。

　　2、用Time Machine回看过去某个时间点的状态

　　要是需要了解的不止是一条工作项，而是想知道在某个特定时间点上整个项目到底处于一种什么状态，那就需要用到Time Machine这个功能。在Polarion的产品说明里也提到了，Time Machine可以去浏览、搜索，甚至生成项目在历史某个时间点的状态报告，在做批量修改的前后对比时，这个功能可以帮忙还原出修改之前整个项目列表的模样，不用依赖事先手工导出的备份。

　　3、把批量修改前后的数据拿出来对比一下

　　如果是涉及大量工作项的批量操作，比较有效的一个做法，是在动手修改之前先把筛选出来的列表导出一次，等到修改完成之后再去把同样的范围导出一次，然后把两份表格放在一块儿，对比每条记录的ID、状态、负责人、版本和更新时间这几列。这样一来，哪些改对了、哪些漏掉了、哪些不小心被重复改了好几次，这些情况很快就能看出来，比自己凭记忆去回想可靠得多。

　　三、批量修改之后怎样减少追踪上的遗漏

　　批量修改确实能省下不少时间，但反过来看，它也有一个副作用，就是一旦改错了，错误会一次性扩散到很多条工作项上面，修复起来非常费劲。所以在项目里用这个功能的时候，最好还是提前定下几条简单的操作规范，让效率和安全之间能有一个平衡。

　　1、对重要字段采取分批处理的策略

　　状态、审批结果，还有版本这几个比较敏感的字段，不太适合一口气改上百条。比较稳当的做法是先挑出几条工作项来试一下，等确认了工作流、通知结果和审批流程这些连锁反应都正常以后，再把范围扩大到剩下的条目上。这样就算试的那几条出了问题，影响面也小得多，调整起来不费劲。

　　2、把修改的原因写进评论里面

　　每一轮批量操作结束以后，尽量在相关的工作项或者变更记录的评论栏里补上一段简短的说明，写清楚这次是因为什么原因才做的批量修改，影响的范围大概有多大，对应的是哪一项任务或者哪一次变更。Polarion本身强调通过审计轨迹来记录变更过程，把修改的前因后果顺便记在评论里，后面的人在看历史记录的时候，就不需要到处去问当时为什么要这么改了，审查起来也方便很多。

　　3、把这次用的筛选条件保留下来

　　在每一次开始做批量修改之前，顺手把刚才用来筛选目标工作项的那组查询条件保存下来，给它取一个好认的名字。这样后面如果发现数据不太对劲，需要重新打开同一批工作项回查的时候，直接把保存好的条件调出来就行，不用靠着记忆再去手工拼一遍筛选条件，效率高不说，还不会因为筛选范围不一致而导致前后结果对不上。

　　总结

　　关于Polarion里怎么批量修改工作项，以及批量改完之后的记录该怎么追踪，整体操作的顺序可以简单归纳成：先用查询条件把范围筛准了，再按照具体情况选择批量编辑或者表格编辑去修改字段，保存之前抽出几条来检查一下数量和内容是不是对的；修改完成以后，通过单条工作项的修改历史、Time Machine工具，还有修改前后的两份导出表格，来追踪变更记录。