随着项目规模慢慢变大，在Polarion里打开项目、加载文档、查询工作项或者保存需求的时候，速度可能会一点点地降下来；很多人会问，为什么Polarion的加载速度变得这么慢，如果想做性能优化，又该先从哪些地方开始排查，这时不能只盯着服务器的内存看，因为读取、索引、权限、脚本和数据范围这些因素，都会影响到页面的响应时间，在排查的时候，先要判断究竟是所有用户都觉得慢，还是只有某个项目、某个页面或者某个账号才卡。

在需求整理的起步阶段，不少团队习惯先用Excel把编号、标题、描述、优先级和负责人这些内容收集起来，等到项目进入规范管理环节，再把这些整理好的数据迁入Polarion，那么Polarion怎么导入Excel里的需求，过程中一旦遇到字段映射错位又该怎么修正，操作时最好不要直接把整张表格原样上传，而是应该先花点时间把列的结构理顺，再通过导入向导去完成字段映射和预览工作，Polarion本身支持利用规则化的导入向导来识别Excel中的需求、测试用例等对象，然后把它们收进平台统一管理。

有时候，代码明明已经提交到SVN上面了，可在对应的需求页面里却完全找不到这次修改的记录，等到了版本审查的时候，就很难把某一条需求到底改过哪些文件给说清楚。要想搞明白Polarion怎么去关联SVN的提交，以及当提交记录在需求那边追溯不到时又该怎么处理，最核心的两件事，就是先把外部的SVN仓库接到Polarion里来，再让开发人员在每次提交时，都把正确的Work Item ID填在备注信息里面。Polarion本身是支持把外部Subversion仓库里的代码变更，跟相应的Work Item挂上钩的，这样一来，需求、任务和代码改动之间，就能形成一条可以往回追溯的链路。

在项目运行了较长时间之后，报表的内容往往需要跟着管理口径的变化做出调整。像负责人、版本、工作项类型、统计时段还有项目名称这些字段一旦改过，如果每次都去复制一份新页面，再靠手工修改里面的查询条件，那报表很快会变得又多又乱，后面维护起来就很不方便了。Polarion本身支持通过LiveReport页面、可视化组件和页面参数来制作能够动态变化的报表，也允许将报表导出成PDF格式，方便离线查阅或者拿去做评审材料，不用每次都打开系统去翻。

需求、缺陷和测试用例一旦进入评审环节，要是有些字段还允许随便改动，就很容易出现状态已经批准了，结果版本号、负责人或者风险说明却被误改的情况。要在Polarion里搞清楚怎么给字段设权限，以及为什么改完权限之后却没起作用，首先得把Work Item的字段权限和LiveDoc文档的字段权限区分开，然后再去确认这些配置是针对哪个项目、哪些角色和哪个流程阶段的。Polarion既可以让你把状态字段和自定义字段设成只读，也支持把它们完全隐藏起来，跟LiveDoc相关的那些配置，都放在Permission Management里面的Documents区域。

产品线运行久了之后，同一批法规要求、平台公共能力还有接口需求，往往会反复出现在好几个不同的项目里面；于是大家就会关心，在Polarion里面到底要怎么管理需求的复用，以及复用之后产生的版本差异又该怎样去区分，处理的时候绝不能只是简单地做一下复制粘贴，因为复制出来的文档在短期内看着是省了一些力气，可一旦原始的公共需求发生了修改，各个项目就很容易各改各的，慢慢就谁也说不清哪个版本是准的了。好就好在Polarion本身就支持需求的复用和分支管理，既可以共享那些公共的规格，又能够把每个产品独有的差异给保留下来，照着这个思路去梳理就会清晰很多。

需求文档定稿之后，如果只靠邮件去提醒负责人，漏掉的环节还是会很多，真要管住审批过程，就得在Polarion里面把一套稳当的审批流程搭起来。这里主要涉及两件事：一是文档审批怎么配置才比较合理，二是审批流该发的通知一直没有触发时，该怎么顺着链路往下查。把这两件事处理好，关键就是把文档状态、审批评审人员、签名要求还有各个节点的通知事件，都放进同一条流程里面去，让它们互相咬合。Polarion本身就可以通过LiveDocs来管理需求文档，也提供电子签名、审批记录和变更追踪这些能力，只不过不同版本的通知功能会有些差异，动手配置之前最好先摸清当前部署的到底是哪一个版本。

测试跑完以后，如果结果只是存在自动化工具、Excel文件或个人手里，那么需求追踪和版本审核就会连不上。想要搞明白在Polarion里怎么把测试结果写回去，或者同步失败时又该怎么排查，得先把三种情况分开来看：手工测试在线填、离线表格传回、自动化结果导入。Polarion这个平台，既允许在线做测试，也支持把测试用例导出成Excel再把结果传回来，另外还能接收xUnit格式的自动化测试结果。

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

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