Polarion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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