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

　　一、Polarion报表数据不对

　　先不要急着改查询语句，第一步要先判断你看的到底是不是同一时点的数据。Polarion官方明确说过，Time Machine里的报表只包含当时那个历史时点有效的数据；后续版本说明又补充，系统会用baseline views先过滤历史Lucene原始结果，只保留该基线里真实存在的对象。所以当前页和基线页数字不同，很多时候不是报表错，而是时点不同。

　　1、先核是不是当前数据和基线数据混看了

　　项目基线、文档基线、Time Machine报表，本来就不是看“现在”的数据。尤其文档基线从19.2开始已经能在历史里单独过滤出来，拿它去和当前Live Report对数，结果不一样很正常。

　　2、再核是不是不同入口各自带了自己的过滤条件

　　官方博客已经演示过，表格视图里的过滤条件可以复制到Live Report的表格和饼图小组件里使用。反过来说，如果你没有复制同一条查询，而是在不同入口各写一遍，就很容易一个带过滤、一个没带过滤。

　　3、保存查询的作用域也要核

　　Polarion的查询可以保存成全局、项目级和用户级。查询名看起来一样，不代表引用的是同一条，尤其2410以后还支持层级化保存查询，查询之间可以互相引用。报表口径不一致时，这一层必须翻出来核。

　　4、逻辑运算一改，结果会直接跳档

　　Siemens官方示例里，同一组条件从AND改成OR，结果数量就从很少一下放大很多。这类问题在visual query builder转成文本后最常见，所以看到数据异常放大时，先查AND、OR、NOT，不要先怀疑数据库。

　　5、复杂条件如果硬用Lucene，结果和预期可能本来就不会一致

　　官方技术文章说得很直白，某些joined query在Lucene里做不到，Work Items表里的Query Builder也不能完成这类查询；像跨文档未链接项、刚更新项这类场景，官方给的就是SQL方案。也就是说，查询工具选错了，报表口径从起点就偏了。

　　二、Polarion过滤条件与口径怎么核对

　　核对过滤条件，最稳的顺序不是直接盯数字，而是先把查询文本统一，再去看时点、作用域和查询类型。官方已经给了很好用的办法，就是先把可视化过滤器转成文本，再把这段文本复制到你要核对的另一个表格、树视图或Live Report小组件里。这样做最大的价值，不是省事，而是把“我以为一样”变成“实际上就是同一条查询”。

　　1、先把可视化过滤器转成文本

　　先用Convert to Text，把表格里正在生效的过滤条件转成文本。只看筛选器气泡和界面标签，很多隐含条件根本看不全。

　　2、把同一段文本复制到另一个报表入口

　　官方明确演示过，复制同一条文本查询到Live Report的Table Block里，回车生效后再保存页面。核对口径时，最怕两边是“差不多”的查询，而不是同一条查询。

　　3、再核查询到底是Lucene还是SQL

　　如果报表要做跨对象关联、跨文档反查、按更新时间筛选，先确认是不是该改成SQL。官方已经明确指出，有些需求Lucene做不到，硬写只会让结果失真或者性能很差。

　　4、再核查询是不是引用了保存查询

　　2410以后，保存查询可以层级引用其他保存查询，便于管理员集中维护。好处是统一，风险是你以为改了一条，实际下面还套着别的片段。所以核口径时，不只要看当前文本，还要看它有没有引用上层保存查询。

　　5、最后核报表所处时间视角

　　如果查询本身没问题，还要回头看这个报表是在当前项目状态下跑，还是在Time Machine或某个baseline下跑。官方对历史查询的处理逻辑很明确，历史视图会经过baseline过滤，因此它和当前项目看见的对象集合本来就可能不同。

　　三、Polarion报表口径为什么总会跑偏

　　说到底，Polarion报表口径最容易跑偏，不在于工具不够强，而在于同一个团队往往把时点、入口、查询语言和保存查询混着用。官方这些年不断加强保存查询复用、历史基线过滤和复杂查询能力，本质上也是在帮团队把这几层分清。

　　1、先定时点

　　当前态、项目基线、文档基线、Time Machine，四者不能混着对数。

　　2、再定入口

　　表格、树视图、Live Report小组件，都可能各自带查询，必须统一成同一条文本。

　　3、再定语言

　　普通筛选先用Lucene，跨对象关联和复杂统计再上SQL，不要混用后再问为什么数字不一样。

　　4、最后定责任口径

　　全局、项目级、用户级保存查询最好由管理员集中收口，层级保存查询启用后更要统一维护，不然同名报表也会越跑越散。

　　总结

　　Polarion报表数据不对，先别急着怀疑系统，先核是不是把当前数据和基线数据混看了，是不是不同入口各自带了过滤条件，是不是Lucene和SQL用反了。Polarion过滤条件与口径怎么核对，最稳的动作就是先转文本，再复制同一条查询到另一处，接着核保存查询作用域和历史时点。把这几层按顺序对齐以后，大多数“报表不对”的问题，最后都会落回到口径不一致，而不是数据真的错了。