需求和测试用例都已录入，追踪矩阵里却仍有空白，未必是关联没有保存。链接角色、查询范围和查看的版本不同，都可能影响显示。Polarion通过工作项之间的结构化链接建立追踪，核对时既要检查记录本身，也要检查矩阵的统计条件。把需求编号写进用例描述，通常不能代替这种关联。

工作项换了负责人、状态也更新了，相关人员却没有收到邮件。排查前先记下工作项编号、操作时间和预期收件人，再确认规则监听的事件与接收对象。下面以工作项邮件通知为例，介绍项目规则的设置方法和检查顺序。

Polarion可以把Excel里的需求、测试用例、缺陷等数据导入项目，并转换成对应的Work Item。已有需求表迁移到Polarion时，比较容易出问题的是字段对应关系，比如Excel里的“需求名称”被写进Description，优先级导入到错误枚举项，或者自定义字段整列为空。处理这类问题时，先把Excel表头、Work Item类型和目标字段整理清楚，再在导入向导里逐列确认映射，能省掉导入后批量返工。

Polarion工作流决定工作项能够从哪个状态进入哪个状态，也决定谁可以执行、需要补齐哪些字段以及是否必须签名。配置出现偏差后，用户可能看不到流转动作，或者点击后提示条件不满足。处理“Polarion工作流怎么配置Polarion工作项状态无法流转是什么原因”时，应先确认工作项类型与工作流匹配，再检查动作、角色、字段和条件。

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

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

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

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

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

很多团队在Polarion里做测试管理，真正卡住的往往不是不会建测试用例，而是测试计划、测试执行和周期节奏没有接起来。Polarion官方对Test Run的定义很清楚，它不是一张简单的执行清单，而是一个由Test Run Template创建出来的系统对象，用来定义本次要执行的测试集、测试环境、构建版本和执行结果，所以测试计划建得顺不顺，后面整个测试周期都会受影响。