• 1
  • 1
分享

一、测试过程拆解

针对BI报表测试,一般情况下,我们需要自己准备数据,来验证报表统计的准确性。由于系统的构成不一样,简单把报表测试过程分解为两个层次:数据收集汇总、数据统计展。

在做数据收集汇总验证时,我们需要了解数据从哪里来,如何汇总,数据入库的规则是什么,如何存放,在什么时间点进行汇总。把这些问题弄清楚了,才可以针对性的做测试策略,来验证数据入库的准确性。这步很重要,因为这个是报表测试的数据来源,如果这里的数据出错,后面的一切都没有意义。

针对数据统计展现,我们需要了解页面上展现的数据来源于库中的哪些表哪些字段,根据什么样的规则来统计。把所有需要展现的数据集对应清楚,这样才能有效的进行数据准备,验证前端的统计、展现是否有问题。可参考:模拟数据在实际场景中的应用

在实际的测试过程中,以上两个层次不要集中在一起去验证,以免链路过长,不好定位问题,最好分开来验证(可以由不同的人员并行测试),同时,在测试过程中,一定要保证数据的可控制性!在开发设计之初,我们就需要评估相关的测试数据制造时间,进行有针对性的准备。完成数据准备后,最好能够备份,以便在测试过程中随时还原数据,重现或者验证BUG。

二、BI报表测试策略

1、数据汇总测试策略

数据来源:

  • 数据从哪些系统中收集。

  • 通过什么方式进行收集(定时任务\接口筛选\数据库同步)。

数据入库:

  • 数据源库与目标库的对应关系。

  • 了解相关库的基本操作(MYSQL\HADOOP)。

数据验证:

  • 明确数据入库的时间分片(按日?月?年?时?分)。

  • 核对两边的数据,可以抽样验证,重点关注临界的数据。

2、测试数据准备

原始数据:

  • 了解原始库的库表结构、数据分类。

  • 了解本次报表展现的边界规则,对应的准备测试数据。

  • 通过一定的手段生成数据并固定测试数据。

展现数据:

  • 数据覆盖所有分类。

  • 数据量需要足够多。

  • 需要包含所有边界值(结合展现时的查询条件)。

  • 数据中需要包含少量的非法数据,验证系统的容错性。

数据生成方式:

  • 存储过程。

  • 第三方工具(DataFactary等)。

  • 通过业务生成数据(并不推荐)。

  • 相关业务接口生成数据。

3、页面数据展现测试

数据的来源:

  1. 来源于哪张表,哪个字段。

  2. 数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确。

数据的范围:

  1. 是否只显示了报表设置的对应范围。

  2. 特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为2021-6-1~2022-6-1,那么是否应该包含6-1这天。

数据的对应关系:

  1. 数据库中的字段是否与报表中的信息对应。

数据的格式:

  1. 小数位,千位符,四舍五入等是否与报表设置一致。

  2. 单位或税率转换是否正确。

  3. 组合显示的数据是否合理。

数据的排序:

  1. 排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序)。

数据准确性:

  1. 对于各种分类统计,首先验证数据总量是否一致,其次验证各类数据的总和是否一致,特别注意四舍五入对数据的影响。

  2. 所登录的用户是否能查看到全量的数据,还是部分数据,部分数据的统计是否正确。

测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆.一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据。

4、页面UI测试

报表的整体风格:

  1. 报表是否符合规定的或用户设置的格式。

报表标题:

  1. 报表的标题是否是正确的报表名称。

  2. 如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业6月份财务报表,这个6月就是用户选择的;或者XX公司2021-6-1~2022-6-1的网站访问量,这个时间段也是用户选择的。

  3. 报表的页首与页尾:是否采用了一致的规则。

  4. 分页:当输出的内容多时,分页是否正确,翻页功能是否正确。

友好性:

  1. 数据或图表是否清晰,一目了然。

  2. 数据的展示符合用户的习惯。

  3. 需要特别提醒的数据(如合计,异常数据)是否突出显示。

  4. 复杂算法处,用户不明白或容易混淆处是否有注释。

  5. 一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等。

5、数据权限控制

报表系统权限控制等级:比如:按钮级(权限不够某个按钮就不能用);菜单级(权限不够某个菜单就不能用);页面级(比如用tab方式展示页面,没有权限则某个页面就不展现)。

参与人员涉及到的权限:一般以角色区分,这里详细列出各个角色允许的权限,便于后继针对性检查。

数据权限:在条件选择区域,有些下拉框中应该不能显示用户权限范围外的数据.如普通人员在使用报表时,报表名称下拉框中是不可以显示管理者才能查看的报表的.注意这里一定要测试每个条目。

数据内容:报表中的内容不能显示用户本没有权限查看的数据。

6、报表输出

报表在电脑上生成后,并不是报表的结束.报表一般都需要打印出来以做它用,如开会或者提交审批之类.所以报表的打印功能也是非常重要的.测试主要分成三部分:打印设置、打印预览、实际打印效果。

除了打印之外,用户有可能需要导出报表做进一步的分析或用于和其他报表的比较.所以也应该提供导出报表的功能.一般可以导出为CSV,Excel,pdf,html,xml格式.看公司需要了.这里主要要检查导出的报表默认属性是否为读写,然后导出的内容是否正确,与生成的报表相一致。

7、报表性能

用户在设置好条件后都希望不要等待报表太长时间,当然有时数据量大时等待时间长些也是合理的.但是在做报表的开发时或测试人员可以提出一些意思来提高报表的性能.可以走查开发的SQL代码、必要的时候可以通过视图来提高性能。


作者:好好先生

原文链接:https://blog.csdn.net/weixin_44275820/article/details/125477568

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 当前的风气是,谈测试,必言“接口”。其实接口并不神秘,当今的应用中无处不是“接口”,从本篇开始让我来谈一些关于接口的浅薄认识。1、一个简单的接口(demo.php)<?php     // 文件名称demo.php     // 告诉浏览器返回为json类型     header('Content-Type:application/json; charset=utf-8');     ...
            3 4 1510
            分享
          • top命令用法top命令经常用来监控linux的系统状况,是常用的性能分析工具,能够实时显示系统中各个进程的资源占用情况。top的使用方式 top [-d number] | top [-bnp]参数解释:-d:number代表秒数,表示top命令显示的页面更新一次的间隔。默认是5秒。 -b:以批次的方式执行top。 -n:与-b配合使用,表示需要进行几次top命令的输出结果。 -p:指定特定的pid进程号进行观察。在top命令显示的页面还可以输入以下按键执行相应的功能(注意大小写区分的):?:显示在top当中可以输入的命令 P:以CPU的使用资源排序显示 M:以内存的使用资源排序显示 N:以...
            0 0 1230
            分享
          • 今天公司的门锁设备可能需要压力测试,提供的接口API接口需要压力测试。一、postman准备其实也没有什么好准备的,唯一就是有些变量不能写死了,需要随机一个,然后再请求。{{}}包裹的都是要随机的参数,前面headers的设置今天就不讲了,要知道的可以看之前的文章。然后这块因为随机东阿u是有规则的,所以还是一样直接在Pre-requestScript这个Tab里写postman.clearGlobalVariable("permissionBegin"); postman.clearGlobalVariable("permissionEnd"); pos...
            15 16 1897
            分享
          •   测试工程师在入行时,都会接触到一个名词——测试用例,都知道测试用例是干什么用的,提到设计测试用例的方法,大部分测试工程师都会侃侃而谈:等价类法、边界值法、判定表法、正交分解法……这些方法说起来都如数家珍,但是似乎在实际工作中,应用起来还不是那么得心应手,甚至还会有测试用例覆盖度不足的问题。  每当遇到这样的问题时,测试工程师多少都会有些无奈。测试用例写的已经尽可能详细了,但是评审时候,参与评审的角色,要么是因为用例太繁复而草草浏览一下,要么是说完后面忘了前面。而测试工程师的思路从思维导图转化为测试用例的时候,也往往达不到测试用例最初的目的——哪怕让小白来遵照执行,也应该可以看得懂。  那么...
            1 1 1065
            分享
          •   这节,我们再思考下,如果我们每条用例,都去一步一步,先元素定位,然后写操作,然后写各种方法。那这个代码量是不是就有点偏多了。另外也不方便维护,比如哪天APP的某个元素定位迭代修改了,还得一个一个去改对应用例的逻辑。  所以,我们这边引入了PO设计模式。  将uiautomator2方法,元素定位,页面操作,测试用例全部分离。  这样可以大大减少我们代码量,更为方便的维护我们的测试用例。  PO模式  页面对象模型(PO)是一种设计模式,用来管理维护一组页面元素的对象库。在PO下,应用程序的每一个页面都有一个对应的Page类。每一个Page类维护着该页面的元素集和操作这些元素的方法。以上对p...
            0 0 1103
            分享
      • 51testing软件测试圈微信