首页
学习
活动
专区
圈层
工具
发布
50 篇文章
1
Ubuntu环境使用TPC-DS工具生成测试数据
2
cookie机制及其原理
3
网络测试,带宽测试,流量测试
4
使Edge浏览器打开仅支持IE兼容模式的网站
5
【Linux】挂载硬盘、镜像文件、rpm软件包管理器、yum软件包管理器、软件安装jdk、tomcat、mysql
6
【Spring Boot 项目创建】002-代码关联 Git 远程仓库
7
用ChatGPT生成测试数据
8
手机APP测试(测试点、测试流程、功能测试)
9
web前端好帮手 - Jest单元测试工具
10
用ChatGPT生成测试数据
11
Redis 精简笔记
12
一句话就能提Bug,这个自动提交Bug Skill 太好用了
13
从0到1做出可复用的 iOS 自动化测试 Skill,附真机演示效果
14
大厂测开面试都在问AI,这个实战项目直接帮你准备好了
15
OpenClaw 拿什么吃掉测试岗?
16
一篇理清Prompt,Skill,MCP之间的区别
17
AI 测试必备:推荐一款能让自动化失败脚本「自己修好」的 AI skill!
18
【Selenium 自学系列】(一)看源码分析交互原理
19
什么是CI/CD
20
这到底是前端还是后端Bug
21
详解接口测试(2)- HTTP接口用例设计与测试方法(拿B站练手)
22
比羊了个羊还火的ChatGPT,玩法全攻略讲解
23
爱心代码文字升级版
24
自动打包、装机、生成用例、真机回归,AI 测试流水线终于跑通了
25
AI生成注册用户测试用例
26
AI驱动的测试报告分析:从数据中挖掘测试洞察
27
WEB功能测试说明
28
APP功能测试要点
29
不输ChatGPT,kimi秒画流程图
30
聊天功能如何测试?
31
订单支付功能测试
32
app功能测试--需要测试哪些要点
33
【软件测试】使用QTP进行功能测试
34
TestZeus Hercules:功能测试写 Gherkin,让 AI Agent 去跑冒烟流程
35
非功能需求的测试
36
【功能篇】如何测试报表?
37
VFP AI 插件(ver:20251007)测试报告
38
VFP AI 插件使用指南(三)
39
「 支付功能 」的测试思路
40
研发、测试提效攻略:利用Apipost AI 6 大核心功能实现接口测试全流程
41
功能测试之app测试要点提取与分析
42
网站测试中短信发送功能测试点
43
常用功能的测试用例
44
20行代码,用Python实现异常测试用例
45
新梦想干货——软件测试中的43个功能测试点(下)
46
《打造你的 AI 知识库:用 Skill 实现项目文档的自动生成与维护》
47
Apifox和Apipost:2025 API工具巅峰对决
48
接口测试--apipost接口断言详解
49
ApiPost自动化测试基础之:如何使用测试校验(测试用例)?
50
教你用 Node.js 模拟自动发送邮件验证码
清单首页测试文章详情

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

前言

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

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

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表格:

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

下一篇
举报
领券