报表测试是一项重要的测试内容,因为面对的使用群体一般是公司高层或者用户中的重要群体。出现问题影响较大,所以必须仔细且谨慎对待。本文根据自己之前的测试经验,结合其它相关资料,做个简单的总结汇总,如有其它建议,可以留言或者私聊,期待沟通交流。
01 测试过程分解
针对报表测试,一般情况下,我们需要自己准备数据,来验证报表统计的准确性。由于系统的构成不一样,简单把报表测试过程分解为两个层次:数据收集汇总、数据统计展。文章源自玩技e族-https://www.playezu.com/179812.html
在做数据收集汇总验证时,我们需要了解数据从哪里来,如何汇总,数据入库的规则是什么,如何存放,在什么时间点进行汇总。把这些问题弄清楚了,才可以针对性的做测试策略,来验证数据入库的准确性。这步很重要,因为这个是报表测试的数据来源,如果这里的数据出错,后面的一切都没有意义。文章源自玩技e族-https://www.playezu.com/179812.html
针对数据统计展现,我们需要了解页面上展现的数据来源于库中的哪些表哪些字段,根据什么样的规则来统计。把所有需要展现的数据集对应清楚,这样才能有效的进行数据准备,验证前端的统计、展现是否有问题。可参考:模拟数据在实际场景中的应用文章源自玩技e族-https://www.playezu.com/179812.html
在实际的测试过程中,以上两个层次不要集中在一起去验证,以免链路过长,不好定位问题,最好分开来验证(可以由不同的人员并行测试),同时,在测试过程中,一定要保证数据的可控制性!!!在开发设计之初,我们就需要评估相关的测试数据制造时间,进行有针对性的准备。完成数据准备后,最好能够备份,以便在测试过程中随时还原数据,重现或者验证 BUG。文章源自玩技e族-https://www.playezu.com/179812.html
02 报表测试策略
数据汇总测试策略:文章源自玩技e族-https://www.playezu.com/179812.html
数据来源:文章源自玩技e族-https://www.playezu.com/179812.html
1.数据从哪些系统中收集。
2.通过什么方式进行收集 (定时任务接口筛选数据库同步)。文章源自玩技e族-https://www.playezu.com/179812.html
数据入库:文章源自玩技e族-https://www.playezu.com/179812.html
1.数据源库与目标库的对应关系。
2.了解相关库的基本操作 (MYSQLHADOOP)。文章源自玩技e族-https://www.playezu.com/179812.html
数据验证文章源自玩技e族-https://www.playezu.com/179812.html
1.明确数据入库的时间分片 (按日?月?年?时?分)。
2.核对两边的数据,可以抽样验证,重点关注临界的数据。
测试数据准备:
原始数据:
1.了解原始库的库表结构数据分类。
2.了解本次报表展现的边界规则,对应的准备测试数据。
3.通过一定的手段生成数据并固定测试数据。
展现数据:
1.数据覆盖所有分类。
2.数据量需要足够多。
3.需要包含所有边界值 (结合展现时的查询条件)。
4.数据中需要包含少量的非法数据,验证系统的容错性。
数据生成方式:
- 存储过程。
- 第三方工具 (DataFactary 等)。
- 通过业务生成数据 (并不推荐)。
- 相关业务接口生成数据。
页面数据展现测试
数据的来源:
来源于哪张表,哪个字段。
数据库中的数值与界面数据的对应.如数据库中性别的数据可能是 0 或 1,但界面显示为男或女,这个对应关系是否正确。
数据的范围:
是否只显示了报表设置的对应范围。
特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为 2006-9-27~2007-9-27,那么是否应该包含 9-27 这天。
数据的对应关系:
- 数据库中的字段是否与报表中的信息对应。
数据的格式:
1.小数位,千位符,四舍五入等是否与报表设置一致。
单位或税率转换是否正确。
组合显示的数据是否合理。
数据的排序:
1.排序方式是否与报表设置一致 (如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序)。
数据准确性:
对于各种分类统计,首先验证数据总量是否一致,其次验证各类数据的总和是否一致,特别注意四舍五入对数据的影响。
所登录的用户是否能查看到全量的数据,还是部分数据,部分数据的统计是否正确。
测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆.一般来说有类别划分的 (一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据。
页面 UI 测试:
报表的整体风格:
1.报表是否符合规定的或用户设置的格式。
报表标题:
报表的标题是否是正确的报表名称。
如报表中有嵌入的数据 (会跟随用户的选择而变化的).需要检查数据是否正确,如 XX 企业 9 月份财务报表,这个 9 月就是用户选择的;或者 XX 公司 2006-9-27~2007-9-27 的网站访问量,这个时间段也是用户选择的。
报表的页首与页尾:是否采用了一致的规则。
分页:当输出的内容多时,分页是否正确,翻页功能是否正确。
友好性:
1.数据或图表是否清晰,一目了然。
2.数据的展示符合用户的习惯。
3.需要特别提醒的数据 (如合计,异常数据) 是否突出显示。
4.复杂算法处,用户不明白或容易混淆处是否有注释。
5.一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等。
数据权限控制:
报表系统权限控制等级:比如:按钮级(权限不够某个按钮就不能用);菜单级(权限不够某个菜单就不能用);页面级(比如用 tab 方式展示页面,没有权限则某个页面就不展现)。
参与人员涉及到的权限:一般以角色区分,这里详细列出各个角色允许的权限,便于后继针对性检查。
数据权限:在条件选择区域,有些下拉框中应该不能显示用户权限范围外的数据.如普通文员在使用报表时,报表名称下拉框中是不可以显示管理者才能查看的报表的.注意这里一定要测试每个条目。
数据内容:报表中的内容不能显示用户本没有权限查看的数据。
报表输出:
报表在电脑上生成后,并不是报表的结束.报表一般都需要打印出来以做它用,如开会或者提交审批之类.所以报表的打印功能也是非常重要的.测试主要分成三部分:打印设置、打印预览、实际打印效果。
除了打印之外,用户有可能需要导出报表做进一步的分析或用于和其他报表的比较.所以也应该提供导出报表的功能.一般可以导出为 CSV,Excel,pdf,html,xml 格式.看公司需要了.这里主要要检查导出的报表默认属性是否为读写,然后导出的内容是否正确,与生成的报表相一致
报表性能:
用户在设置好条件后都希望不要等待报表太长时间,当然有时数据量大时等待时间长些也是合理的.但是在做报表的开发时或测试人员可以提出一些意思来提高报表的性能.可以走查开发的 SQL 代码、必要的时候可以通过视图来提高性能。
03 小结
报表测试相比于其它的日常功能测试,有它的特殊性,故需要有针对性的测试方案。它又区别于我们所说的大数据测试(一般的场景下数据量还达不到 “大数据” 的量级)。以上的总结希望可以做一些沉淀,也欢迎大家一起交流。
原文链接:https://mp.weixin.qq.com/s/MRuJ8vJZofZdSfvgb1FDCw
未知地区 1F
学习了,有没有好的测试工具啊,求分享厉害_^ 学到了,希望之后能致用学习了,就是没学明白
完成数据准备后,最好能够备份,以便在测试过程中随时还原数据,重现或者验证 BUG。
之前也有测试过报表,所以感觉这一步真的很重要,可以基于一个基础不断的补充,拓展,不过当时测试的对象相对固定,属于行业标准的报表,相当而言对于测试的目的也比较清晰,所以思考也会比较少了 非常有用的总结,一下子清晰多了,谢谢大佬感谢楼主的分享,帮我完善了测试的思路,最近正好需要测试报表近期在做财务对账系统的测试,看完文章还是有一些收获。
物料准备:提前规划好需要哪些数据,有些数据是 T+n 的,不提前准备会影响测试周期。
功能:1、源数据、目标数据、聚合数据,数据比对,除了当前测试系统,还可以跟其他系统的相同数据比对。2、各种各样的数据,这个是重点也是难点,不容易达成 100% 场景覆盖。3、规则核对,每个字段的取数来源、映射关系、计算规则。
性能:大量 mq 消息处理、查询性能。