前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【功能篇】如何测试报表?

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

作者头像
张树臣
发布2019-07-31 12:36:06
2.1K0
发布2019-07-31 12:36:06
举报

前言

报表测试是我们测试人员都会经历的,报表涉及的测试点很多,比如上下游数据的比对、权限、性能、安全、接口、内容展示等等,且由于报表是用户最关心最常用的模块,所以如何保证报表的测试质量就显得尤为重要了。

笔者对于报表测试的经验不多,谨希望通过本文给大家分享笔者的浅薄经验,期望能给读者一点启发。

1 背景

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

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

2 需求分析

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

  • 查询条件:项目、时间控件、两个按钮、三个时间段
  • 查询结果:日期、单楼盘查询结果、全部楼盘查询结果、合计行、片区小计行、....二级页面、三级页面...
  • 结果导出。

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

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

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的值。

3 测试执行

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

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

想了一下,小萨做了一张excel表格:

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-06-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 软件测试经验与教训 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
腾讯云 BI
腾讯云 BI(Business Intelligence,BI)提供从数据源接入、数据建模到数据可视化分析全流程的BI能力,帮助经营者快速获取决策数据依据。系统采用敏捷自助式设计,使用者仅需通过简单拖拽即可完成原本复杂的报表开发过程,并支持报表的分享、推送等企业协作场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档