我们用Polarion做项目汇报、评审材料，或者搞审计资料的时候，这个报告模板不能只当成是“弄出一个好看的文件”，其实真正有用的报告模板，需要大家把需求、测试、缺陷，还有变更、评审、追溯关系这些数据，都按照固定的口径给整理出来，在Polarion里面有一个LiveReport功能，大家可以用它来做自定义的仪表盘和报告，里面的小组件也就是Widget，主要是用来把Polarion的数据按照不一样的格式给展示出来的。

在Polarion里做需求、测试、缺陷还有变更管理的时候，权限角色并不是简单给用户开个账号就可以的，要是角色分配不清楚，轻一点的情况是看不到字段、改不了状态，重一点的话，可能连项目的入口都找不到，所以在处理“Polarion权限角色怎么分配、Polarion权限角色导致看不到项目怎么办”这些问题时，需要把用户、用户组、全局角色、项目角色、空间权限以及工作项权限这些东西分开来看，因为Polarion支持用用户组把用户按业务角色组织起来，而且能把全局角色、项目角色关联到不同的项目里，这样就能减少因为给每个用户逐个配置权限而造成的混乱了。

在Polarion里进行项目管理的时候，仪表盘并不只是放几个图表，而是要把需求、缺陷、测试、变更、评审和版本进度这些东西堆在一起显示，在面对“Polarion仪表盘怎么配置、Polarion仪表盘数据不更新怎么办”这些问题时，得先弄明白看板是给谁看的，项目经理要看进度，需求负责人要看覆盖率，测试负责人要看执行结果，质量负责人要看风险和缺陷闭环，Polarion通常是用LiveReport和Widget来做自定义报表和仪表盘的，用不同的组件把项目数据塞进去。

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

我们在Polarion系统里面去管理那些缺陷的时候，是不可以单纯地把这些缺陷当成一张记录问题的表格来对待的；缺陷从最早的被发现，再到后面的确认、分派、修复，还有验证和最后的关闭，每一个步骤其实都应当被设置好清晰的状态，并且定好负责人、必填的空项以及流转的规矩；因为Polarion这个系统本来就是在一个网页里面去管理需求、开发还有测试这些东西的，所以缺陷的流程一般也会跟需求、测试用例还有测试的结果放在一起，组合成一个互相联系的体系。

在Polarion软件中进行测试管理的时候，测试人员不能仅仅把测试用例看作是一份简单的“测试步骤清单”，更重要的事情是，需要把测试用例、原始需求、测试计划、实际执行结果以及缺陷记录等内容都串联在同一条链路当中；由于建立了这种链路，管理层在后续工作中才能够清楚地了解到哪些需求已经设计了对应的测试，哪些需求目前还没有被测试覆盖，以及哪些测试的失败会直接对哪些需求产生波及；Polarion QA主要被用于测试用例的设计、测试活动的协调以及测试过程的跟踪，同时Polarion ALM也比较看重在统一的环境里面去把需求、开发和测试工作一起管起来。

在利用Polarion系统进行需求、任务、缺陷和测试用例的管理过程中，操作人员经常会被两个基础问题困扰，也就是怎么去配置工作项的类型，还有就是如果字段显示不全了该怎么处理，这两个情况其实是互相紧紧关联在一起的。若是系统管理人员没有把工作项类型设计好，那么各种字段就很容易出现混乱；反过来说，如果配置好的字段在界面上显现不出来，那么用户在后面进行数据筛选、关系追溯、项目评审以及查看报表时，都会受到很不好的影响。在Polarion系统里面，字段一般包括了系统自带的内置字段，还有用户自己定义的自定义字段，这些自定义字段通常是由系统通过字段ID来识别的，并且不论是在软件的操作界面上，还是在后期的接口调用里，它们都会按照字段的配置情况被投入使用。

在管理需求的流程中，很多团队其实并不是不会写那些需求，而是写完之后，大家往往没办法说清楚这个需求是从哪里来的，具体由谁去负责做出来，要用什么测试来验证，以及变动以后会影响到哪些别的部分，这正是Polarion需求追溯这个功能需要去解决的问。因为Polarion这个系统本身就是把需求、变动、测试这些东西放在一起管的，所以需求、测试用例还有变更请求这些系统里的条目之间就可以建立起连接，从而能够支持从头到尾的追溯。

在对需求管理平台进行迁移的时候，经常会碰到关于“Polarion需求文档如何导入，以及导入之后格式乱了怎么去整理”的问题，表面上看起来，这只是把Word、Excel或者旧系统里面的数据搬到Polarion里面去，但是实际上的困难在于，文档的结构能不能被系统给识别出来，标题的级别能不能变成需求的级别，还有正文、表格、图片和编号在导入之后是不是会发生变形，Polarion这个系统支持围绕Word文档来进行导入，并且可以配置需求的筛选规则，在集成的场景里面，系统也提供了导入Word文档从而创建Polarion Document的接口。

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