Polarion

步骤里有失败项，测试运行却显示已经结束；用例这次执行通过了，工作项状态仍停在审核中。看到这些情况，先别急着改结果。Polarion里的步骤判定、测试记录结果和测试运行状态分别记录不同内容，用例工作项还有自己的流程。需要查清页面显示的是哪一项，再判断数据有没有写错，以及项目规则是否真正限制了状态转换。

修改需求后，历史记录里的内容看着不对，先记下需求编号，再确认自己打开的是哪个版本。Polarion会记录单条需求工作项的修改，也会记录承载需求的LiveDoc修订版；文档基线和项目基线则对应不同的保存范围。一位同事查看工作项最新内容，另一位打开上次交付的基线，两人看到的文字可能不同。

Polarion项目仪表板一般通过LiveReport Page和Widget组合展示项目进度、需求状态、缺陷数量、测试执行情况等数据。仪表板页面本身只是展示载体，真正决定组件显示结果的是查询范围、筛选条件、页面参数和当前用户权限。遇到Work Item已经修改，仪表板里的数字或列表却没变化时，可以先检查组件到底在查哪些数据，再判断是页面配置没有更新，还是当前账号读取不到对应对象。

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

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

评审后改了几条需求，再比较两份基线，正文修改能看到，状态变化却没有出现；另一个条目明明还在文档里，比较时又像被删掉了。遇到这类情况，先保留两侧的修订号。基线名称、文档路径、过滤条件和显示选项都需要核对，单凭差异页上的红绿标记，还不足以判断某项修改是否进入了基线。

在Polarion中执行一批测试用例，通常要先创建测试运行（Test Run）。创建后如果只有部分用例找不到执行入口，先记下这些用例的编号：它们可能没有进入本次运行，也可能关联了不同的文档版本。下面按创建、排查和复查的顺序操作。界面名称以所用版本为准。

Polarion的LiveDoc把普通文档编辑和Work Item管理放在同一个页面里，可以直接维护需求、测试用例、缺陷以及它们之间的关联。创建文档后，Work Item显示多少内容并不是固定的，文档自己的展示配置、当前过滤条件、用户权限和Work Item状态都会影响页面结果。遇到标题能看到但字段缺失，或者某些Work Item整条不见时，要先分清是展示配置问题，还是对象已经被过滤、移除或权限限制。

Polarion需求基线用于固定某个阶段的需求状态，便于后续审查、变更控制和版本交付。处理“Polarion需求基线怎么创建Polarion需求基线之间的差异如何比较”时，要先确定基线范围和创建时点，再比较新增、删除、属性修改及关联变化，不能只看文档正文有没有改动。

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

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

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

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

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

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

给工作项加了“待评审”状态，用户却找不到提交入口；负责人已经填写，系统仍提示条件不满足。这类问题往往需要回到具体动作检查。Polarion如何配置工作项状态转换Polarion工作流条件设置后状态无法流转如何排查，可以围绕一条实际路径展开：由开发人员把“处理中”的工作项提交到“待评审”，提交前必须填写负责人，并满足项目规定的检查条件。

在Polarion里，工作项明明存在，列表里却找不到，可以先从查询范围和筛选条件查起。下面以配置一条查询为例，再用已知编号的工作项核对遗漏原因。操作时以当前版本的界面标签为准；项目自定义字段的名称可能与示例不同。

Polarion可以把Work Item的读取、修改、删除等权限分配给不同角色，也能继续细化到具体字段。比如需求进入评审后，只允许负责人修改责任人字段，其他成员只能查看；需求进入批准状态后，标题、描述和某些自定义字段也可以锁住。字段权限已经配置，用户却还能编辑时，通常要检查角色继承、项目级与全局级配置、字段修改权限以及Read-only Fields是否真正作用到当前Work Item。

需求与测试用例没有稳定关联时，很难确认哪些需求已经验证，哪些仍缺少覆盖。处理“Polarion测试用例怎么关联需求Polarion需求与测试用例追溯不完整如何检查”时，应先统一链接角色和方向，再检查查询范围、版本关系与数据权限。

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