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一方面支持测试运行对象本身的浏览、离线执行导出、表格导出和树表导出，另一方面又支持Live Reports、Documents和Wiki的PDF导出，以及Baseline和比较报告这类留档能力。把这两条线拆开，测试交付会清楚很多。

很多团队做Polarion历史项目处理时，最怕两种情况，一种是项目虽然停了，但页面还在被继续改动，另一种是为了腾空间或做整理，最后把历史数据、审批记录和追溯链一起弄散了。就公开资料来看，Polarion更稳妥的历史项目处理思路，不是简单“删掉”或“隐藏”，而是把基线留存、权限收紧和仓库级备份放到一起做，这样既能保留历史全貌，也方便后续审计、复盘和恢复。Polarion的资料明确提到可浏览和读取基线对比报告、可从基线浏览项目，并且基线是可搜索的；同时系统支持按角色、用户、项目和组建立多层级安全控制，项目数据底层又依托版本库保存历史。

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

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

很多团队在Polarion里做追溯时，真正麻烦的通常不是矩阵能不能看出来，而是导出去以后能不能继续用，链路断了以后能不能快速补齐。Siemens官方资料已经把这两件事的基础能力说得很明确，Polarion支持导出追溯报告到Microsoft Excel，到了2404版本，Traceability Matrix视图里的Microsoft Excel table导出还升级成了xlsx格式，单次可导出的列数空间也更宽一些。

Polarion测试用例怎么写，很多团队一开始都把重点放在“写得快”，结果真正执行时才发现步骤太粗、预期太虚、回归时同一个用例每个人理解都不一样。Polarion官方资料里，测试用例本身就是预定义的Work Item类型，字段、流程和表现形式又支持按项目配置；测试执行则通过Test Run来承接，并把执行结果和需求、缺陷一起纳入追踪。也就是说，写用例时不能只顾把流程记下来，还要考虑后面能不能稳定执行、复用和追溯。

Polarion真正适合多人协作的地方，不是把所有人都放进同一个文档里一起改，而是先把权限、对象类型和版本边界分开。西门子官方资料把它的协作能力放在几条主线上：一是100%浏览器访问与LiveDocs并发编辑，二是threaded discussions、notifications、alerts这类沟通机制，三是granular permission controls和workflow automation，四是baseline、branch与merge这套版本化手段。把这几层先搭清，后面的多人协作才不容易乱。

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

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

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

Polarion里“报表不对”这件事，很多时候并不是数据真的丢了，而是取数口径没有对齐。官方资料其实把几个最容易跑偏的地方都点出来了：同一份数据可能来自当前项目状态，也可能来自某个历史基线；同一个过滤条件可以存在于表格视图、树视图、Live Report小组件里；再往下还有Lucene查询、SQL查询、保存查询和查询文本逻辑的差别。只要这几层没有先对齐，报表数字就很容易一边是2，一边变成42。

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

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

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

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

很多团队刚把Polarion用起来时，缺陷提报最容易出现两个问题，一是条目建出来了，但后面没人接得住，二是严重度写了，却和优先级、影响范围混在一起，最后统计和排期都乱。Polarion本身把缺陷放在Work Item体系里管理，缺陷、测试、需求、变更都可以在同一套追溯关系里联动；同时它也明确支持按工作项类型配置字段、流程和界面，所以“怎么提”和“怎么定严重度”都不该只靠个人习惯，而要落到项目规则里。

Polarion这类系统里，很多人一提“审计”，第一反应就是去找一张日志表，但官方资料给出的思路其实更完整。Polarion的流程审计不是只看某条审批是否点过，而是把工作流规则、状态流转、电子签名、工件历史、活动流和历史时点报告放在一起看。Siemens官方产品页明确写到，Polarion的工作项和文档是通过可定义规则的工作流来推进的，并且自带完整审计轨迹、电子签名和安全控制；官方白皮书也强调，工作项和文档都保留历史，可显示谁在什么时候改了什么。