Polarion

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

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

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

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

Polarion怎么对接Jira，很多团队一开始就急着做字段映射，结果后面不是权限不通，就是同步范围失控。更稳的顺序其实很明确，先确认你用的是Polarion自带的Jira Connector，再到管理端建立连接，最后才去做同步对、字段映射和执行策略。西门子官方公开资料已经说明，Polarion Connector for Atlassian JIRA是随Polarion一起提供的，支持Jira Issues与Polarion Work Items双向同步，而且连接与互操作是在平台管理界面的【Connectors】主题下直接配置的，不是另外装一套完全独立的中间件。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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