【功能篇】如何测试报表？

前言：

有朋友来咨询应用系统中的报表模块怎么测试，笔者的报表测试经验也不算多，谨希望通过本文给大家分享笔者的浅薄经验，期望能给读者一点启发。

背景：

今日，小萨接到一个地产类销售系统的报表测试任务。该系统是地产公司用于管理旗下楼盘的销售全流程的一套系统，涵盖楼盘及房间信息、认筹、认购、签约、付款、售后服务等一系列流程。小萨接到的第一项任务是测试“销售一票到底台账”，界面如下：

领导告诉小萨：“小萨，你今天把这张报表测试一下，下班前给结果，我明天要用。”

需求分析

小萨接到任务后，开始观察这个报表，按照从张老师那里学到的思路，先将界面元素拆分出来：

• 查询条件：项目、时间控件、两个按钮、三个时间段

• 查询结果：日期、单楼盘查询结果、全部楼盘查询结果、合计行、片区小计行、....二级页面、三级页面...

• 结果导出。

界面元素拆分完了，接下来就是整理测试思路。在上面的各项元素中，查询条件、结果导出这两项都是各系统通用的，不需要深究。但查询结果怎么验证它是否正确呢？

回想起张老师的一句话：程序归根究底是对数据的处理，而数据的处理无非是增删查改四个手段。所以测试软件的时候也要按照增删查改的思路来测试。结合这一点，小萨的测试思路是：

1、增、删、改数据源，然后查看本表变化

2、链接正确性

3、本表的数据和数据源是否一致

接下来要做的就是找到该系统的需求文档，然后进行需求分析了。

可问了项目组同事之后才发现，这个项目因为赶工期，没有任何资料，并且目前也没有人能完整清晰的了解所有逻辑。好吧，那只能一点点去问了。

在经过跟开发同事一顿balabala之后，大概了解了需求，虽然还有很多需求点没有问到，但迫于项目时间，小萨决定先着手开始测试。

考虑到测试完之后要给领导汇报，所以小萨在找bug的同时，脑海里也在想一个问题：领导安排的任务不清晰，如果完整测试这个模块，一天的时间是不够的，那么自己得先给任务界定范围然后排出优先级。

在确定测试范围时，小萨又遇到一个问题，即这张表中有32列、93行，若要保证每个数据都没有问题，那么仅首页就要验证32*93=2976个单元格的数据，再加上还需要验证二三级页面，那么起码要看数万个单元格数据，这个工作量即使缩减到百分之一，也不是在一天内能完成的。

这意味着，只能采用抽查的方式进行测试。那么要抽查哪些数据呢？抽查的原则又是什么呢？

一番考虑之后，小萨把测试范围缩小为：

1、一级报表测试前三行的数据，即所有大区项目的总计数据、某区域下项目的合计数据以及单个项目的数据，共计3*32=96个单元格的数据。

2、各级表之间链接的正确性，比如点击某个楼盘的“交房户数”，展开的页面是否展示且只展示了这个楼盘的信息；

3、各级表之间的数据一致性，比如某个楼盘在一级表的“交房户数”是100，在二级表中是否也是100条记录；

4、一级表的数据跟数据源的数据是否一致，比如某个楼盘在本表中的“交房户数”是100，这个数据跟[销售流程-交房管理模块]下该项目在指定时间段内的交房户数是否一致；

5、表中各列的数据是否正确取值，比如“审批状态”一列是否错误的取了“审批状态”对应的ID的值。

测试范围缩小后，小萨心里明白这样做带来的最大隐患就是部分楼盘的数据可能存在错误但测试不能覆盖，二三级表单的逻辑以及导出等附加功能不能细测。

接下来的工作，就是了解上面提到的96个单元格的逻辑。

可由于今天大家都忙于上线的工作，没有人有足够多的时间来告诉小萨这么多的逻辑。不得已，小萨进一步缩小测试范围，即在96个单元格中先测试有超链接的单元格，共21列，21*3=63个单元格。

最终确定，今天的测试范围为：

1、一级报表前三行数据中带超链接的数据，共计3*21=63个单元格的数据，且由于单项目查询和全部项目查询采用了不同的逻辑，所以实际有63*2=126个单元格需要测试；

2、各级表之间链接的正确性，比如点击某个楼盘的“交房户数”，展开的页面是否展示且只展示了这个楼盘的信息；

3、各级表之间的数据一致性，比如某个楼盘在一级表的“交房户数”是100，在二级表中是否也是100条记录；

4、一级表的数据跟数据源的数据是否一致，比如某个楼盘在本表中的“交房户数”是100，这个数据跟[销售流程-交房管理模块]下该项目在指定时间段内的交房户数是否一致；

5、表中各列的数据是否正确取值，比如“审批状态”一列是否错误的取了“审批状态”对应的ID的值。

测试执行

考虑到工作完成以后需要让跟领导汇报结果，即需要让领导知道自己测试了哪些内容，哪些地方没有测试，所以小萨在测试报告的word中把上文中的测试范围罗列了出来。

在开始测试之后，小萨又发现一个问题，即虽然把测试范围罗列的“很清晰”了，但对测试执行的指导力度还不够。小萨心里想，虽然没有时间写用例，但有没有办法把上面的测试范围分析转化成类似用例的形式呢？ 执行通过了可以有一个类似于“测试通过”的状态作为标记，这样自己执行起来就更清楚了，也可以避免遗漏。

想了一下，小萨做了一张excel表格：

做完表之后，小萨考虑到因为主要执行的是超链接的验证，关于计算公式方面的验证需要后面再测试，所以又将“测试结果”拆分成了“链接”和“逻辑”两列，如图。

后期计划：

• bug验证

• 常见的bug类型

• 报表效率优化思路-测试人员须知的。

• 海博测试的那个项目改动上。即bug回归时候的坑