精华内容
下载资源
问答
  • 报表测试

    千次阅读 2015-10-14 15:30:07
    报表测试分为:报表界面测试、报表安全性、报表准确性、报表展示速度(也就是性能)。   数据准确性测试   报表测试的系统分为两类,一类是业务系统中,带有统计分析功能模块,该模块中包含分析报表,这个...

    报表测试分为:报表界面测试、报表安全性、报表准确性、报表展示速度(也就是性能)。

     

    数据准确性测试

     

    报表测试的系统分为两类,一类是业务系统中,带有统计分析功能模块,该模块中包含分析报表,这个系统的主体是业务系统,报表是为办理业务的而提供帮助的。比如说,应年检统计报表,某月应交罚款车辆统计报表,这样的报表数据准确与否,可通过增加、删减、修改相关业务或相关业务的参数,查看统计报表数据变化,检查数据准确性。

    另一类是系统只有统计功能,就是我说的数据仓库展现这类,它与业务系统分离,并且经过多层处理,比如数据仓库的数据,经过抽取,清洗,展现前会经过数据挖掘,数据再处理,有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂,当然检查出数据错误,修改定位也是很不容易的。

    对系统中的报表数据准确性测试方法较为灵活,

    ①系统中报表重叠的进行比对

    ②对子报表汇总与父报表比对,就是对月报表汇总与年报表比对,日报表汇总与月报表比对,这只是一个方面,可以从维度关系考虑,地域,行政级别、时间,个人等方面下手,进行汇总比对,

    ③这个方法如果延伸点呢,可以将报表间的业务逻辑关系作为比对依据。

     

    报表差错测试

     

    a       原始表使用错误:因为表比较多,又加上没有统一的数据关系对应表,很容易表使用错误,当然这应该是单元测试检查出来的错误。

    b       数据处理逻辑错误:这一点容易因为测试人员和开发人员对需求理解有偏差造成争执,所以在需求评审时,对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误,逻辑编写有偏差,边界值、特殊情况处理不当。

    c       数据权限:不同用户对数据有着不同的查看权限。这关系到数据的安全性。

    d        数据误差:数据的保留位数,数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

    e       由于字典表,数据错误,而造成的数据错误,如,根据性别统计,购买量,表中的男女颠倒,或者没有考虑性别缺失项,用了if else,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态,数据状态类似的字段,容易被忽略,测试应该考虑到。

    f       最后一项,当数据量相当大的时候,统计应该考虑,切割速度,也就是数据的完整性,由于数据切割的滞后,带来的数据不完整,而造成统计结果不完整。如统计昨天的销售情况,而昨天的数据并没有完全从业务系统数据到数据池,再者月底数据,由于最后一天的数据切割不完整而造成的正月统计数量不准确。

     

    报表的界面和输入输出测试

     

    界面分为输入界面和输出界面;统一的界面要求:美观、统一、易操作。输入界面要求是:

    1.输入项字段长度不允许超过字段长度;

    2.输入不符合字段要求的,不允许查询。如money类型,在输入汉字,字母、特殊字符等不允许查询,并有友好的操作提示。

    3.用户权限范围外的输入,不允许查询。如用户输入不是其权限范围内的客户号,不允许查询,并有友好的操作提示。
    4.对于选项,应不出现可选择的用户权限以外的选项。⑤对于汉字模糊查询,考虑不常见字,如“”即汉字因译码问题,造成的汉字存储出现乱码问题。

    输出界面要求:

    1.因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据,不能因为打印缺少了报表表格框

    2.报表排列方式可调,用户可按任意列升序或降序排列,或者,按某一关键列的一定规则排序

    3.报表标题明确,不能含糊误导用户

    4.报表内可关联查询的项,应能特殊显示,如鼠标有箭头变为手掌,子报表格式与父报表格式统一,数据统一。

    展开全文
  • 这个报表测试系列的总结,也是这个项目触发而来的。 在2月的最后一个星期,经历了半年的设计、开发、测试的报表系统进入了UAT阶段。我是这个基于OLAP技术报表系统的测试人员,从系统需求分析、设计,到后来的IT、ST...
  • 报表测试指导书报表测试指导书报表测试指导书报表测试指导书报表测试指导书报表测试指导书报表测试指导书报表测试指导书报表测试指导书
  • 报表测试用例设计中,测试数据是关键。正如Jackie在《进销存系统中的报表测试》中所言,如果希望更有效、更高质量地完成报表测试,就要重视并增加对于数据准备的关注。其实,测试数据也是为测试场景服务的,一个...
  • 软件测试中报表测试用例设计方法总结报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能)数据统计方面1、报表统计数据的正确性;2、报表统计数据的完整性;3、报表统计数据的合法性;比如,统计金额...
  • 功能测试_报表测试

    2021-01-21 20:17:33
    报表测试:界面,安全性,准确性,性能 数据统计方面 1、报表统计数据的正确性; 2、报表统计数据的完整性; 3、报表统计数据的合法性;比如,统计金额字段需求要求有“$”等;  报表格式 1、表头字段表示的正确...

    目录

    报表测试:

    一、页面测试:

    二、功能测试:

    三、权限测试:

    四、数据的正确性:

    五、报表性能测试:


    报表测试:

    页面测试、功能测试、报表权限测试、数据正确性测试、报表性能测试

    一、页面测试:

    界面检查:1、整体页面美观统一;2、输入框:长度、必输、输入格式等;

    报表格式

    1、报表字段表示的正确性完整性字体,字号,美观程度数据过长时要求折行还是缩小;

    3、报表的整体风格是否符合规定或用户设置的格式对齐,边界,间隔

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

    5、友好性:数据或图表是否清晰,数据的展示符合用户的习惯;需要特别提醒的数据(如合计,异常数据)是否突出显示;复杂算法处,用户不明白或容易混淆处是否有注释;

    6、数据的格式:小数位,千位符,四舍五入等是否与报表设置一致;单位或税率转换是否正确;

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

    报表的预览和印刷

    1、预览中的显示完整性;

    2、多页情况下,第2页的表头显示;

    3、能否实现需求要求的特定印刷情况;(比如,印刷使用指定的模板)

    4、预览后印刷;

    5、不预览,直接印刷

    6、需求规定各类打印机的测试;

    7、报表导出格式为CSV,Excel,pdf

    二、功能测试:

    1、查询功能正常;2、输入各条件组合查询;3、数据的查询范围测试

    三、权限测试:

    1、报表的条件定义:在条件选择区域,有些下拉框中应该不能显示用户权限范围外的数据。如普通文员在使用报表时,报表名称下拉框中是不可以显示管理者才能查看的报表的。有些以输入的文本框有级别的划分时,都应该要测试输入超越权限的数据的相应。

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

    四、数据的正确性:

    一般报表测试:主要业务系统的报表,报表是为业务的而提供帮助的。

    1、报表统计数据的正确性:数据的来源:来源于哪张表,哪个字段,数据库中的数值与界面数据的对应

    2、报表统计数据的完整性数据量与数据库是否一致、明细与合计的一致性

    3、系统处理出来的数据是否和手工计算的结果一致

    大数据BI报表:经过数据抽取清洗转换等再展现出来的报表

    从整个项目节约成本看,逐层测试效果是最好的。完全修改率也是最高的。

    首先建立测试数据模型,模拟所有应用表,建立简单易跟踪的数据用例,底层的数据表测试,通过SQL 语句和手工计算,对数据进行比对。对系统中的报表数据准确性测试方法较为灵活,

    ① 系统中报表重叠的进行比对

    ② 对子报表汇总与父报表比对,就是对月报表汇总与年报表比对,日报表汇总与月报表比对,这只是一个方面,可以从维度关系考虑,地域,行政级别、时间,个人等方面下手,进行汇总比对

    ③  使用SQL和手工计算进行比对。

    下为容易出错的情况

    ● 原始表使用错误:因为表比较多,又加上没有统一的数据关系对应表,很容易表使用错误。

    ● 数据处理逻辑错误:这一点容易因为测试人员和开发人员对需求理解有偏差造成争执,所以在需求评审时,对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误,逻辑编写有偏差,边界值、特殊情况处理不当。

    ● 数据权限:不同用户对数据有着不同的查看权限。这关系到数据的安全性。

    ● 数据误差:数据的保留位数,数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

    ● 由于字典表,数据错误,而造成的数据错误,如,根据性别统计,购买量,表中的男女颠倒,或者没有考虑性别缺失项,用了if else,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态,数据状态类似的字段,容易被忽略,测试应该考虑到。

    ● 最后一项,当数据量相当大的时候,统计应该考虑,切割速度,也就是数据的完整性,由于数据切割的滞后,带来的数据不完整,而造成统计结果不完整。如统计昨天的销售情况,而昨天的数据并没有完全从业务系统数据到数据池,再者月底数据,由于最后一天的数据切割不完整而造成的正月统计数量不准确。

    五、报表性能测试:

    1、通过抓包工具检查报表接口的响应时间、数据加载出来的时间。

    2、通过接口测试功能测试sql具体的响应时间。

    3、通过数据库执行计划测试sql的执行时间。

     

    展开全文
  • 实际ATM监控系统的报表测试,可以以本文介绍的六点为纲展开,但是又不可拘泥于这六点,而应根据实际项目的情况,调整相应的测试策略和测试方法,以便对系统进行更有效的测试  实际ATM监控系统的报表测试,可以以...
  • NCReport报表测试

    2014-06-10 17:52:48
    VS2010+QT4.8.5+NCReport报表测试程序
  • 财务报表测试题.doc

    2021-09-09 15:12:38
    财务报表测试题.doc
  • 本文适合有过MIS系统报表测试经验,或者有关进销存系统测试经验的朋友参考。报表功能的基本要求,就是通过查询/统计/分析,提供用户所需的准确的数据。如果无法实现这个  关键字:进销存报表软件测试  本文适合有过...
  • 如何做报表测试[1]

    2021-03-23 16:23:18
    如何做报表测试[1] 软件测试 报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/...
  • 如何做好报表测试

    千次阅读 多人点赞 2019-09-04 18:12:43
    所谓的报表,就是在已有数据的基础上,经过各种加工、汇总,而呈现出来的数据结果,而报表测试则是鉴定报表的正确性、完整性、安全性和使用质量的过程。不多说,直奔主题吧,下面就结合前人的经验...

    文章导读:

    在一个研发项目团队中,很多人(包括我)的第一印象都会觉得:测试比做产品、开发简单得多。在接触了测试近一年的我想说:在这个世界上,你想把任何一件事做好、做到极致都没那么容易。诚如:如何做好报表测试?

    正文:

    所谓的报表,就是在已有数据的基础上,经过各种加工、汇总,而呈现出来的数据结果,而报表测试则是鉴定报表的正确性、完整性、安全性和使用质量的过程。不多说,直奔主题吧,下面就结合前人的经验以及个人心得来说说如何做好报表测试:
    在这里插入图片描述

    首先,提高业务的熟悉程度

    和功能测试以及其他测试一样,报表测试也需要熟悉业务,不同的是报表测试要理解每个指标的算法、数据来源以及要明白具体的业务动作和指标之间的关系。

    熟悉业务是极为必要的,因为在设计测试用例前,你需要在需求文档中了解并确定以下的信息:

    1、指标的设计是否符合业务场景或真正的业务需求;

    2、统计指标是否需针对异常数据的情况,做异常处理;

    3、用户访问的频率、使用习惯等情况,以便后面做性能测试时的用例设计;

    4、需求提供者有无以往的手工数据或历史数据可以作为核对标准?如果有,最好请产品人员提供。

    熟悉业务后,就可以进行用例设计了。

    报表测试的六大用例设计点:

    一、数据的正确性

    对于用户来讲,使用报表就是希望通过报表快速简单地查到自已所需要的数据,所以测试报表最主要的内容就是验证数据的正确性:

    1、数据来源是否正确。针对产品提出的指标,确认和需求是否是同一个数据源。一般来说,数据源大致分为两类:一是本系统产生的数据;二是从第三方同步过来的数据,需要核对需求中需要的数据,本系统是否已经同步过来,同步是否符合要求。

    2、数据范围是否对应。是否只显示了报表设置的对应范围,并且考虑需求中是否包括统计区间的边界值。

    3、指标的特定条件是否满足。前提是要弄清楚,所测报表的指标中,是否有特定条件,这个特定条件是什么,报表数据是否满足该特定条件等。

    4、明细与合计是否一致。即报表的各部分明细值之和,是否和合计值一致。

    二、报表的权限控制

    考虑到数据的安全性,对报表进行权限控制是很有必要的。

    1、确定报表是否有针对不同用户角色,设置相应查看权限的需求;

    2、不同的用户角色,其查看权限是否正确;

    三、报表格式的显示

    特别是对外使用的报表,需要关注输出报表的显示格式是否符合客户需求:

    1、报表的标题或者表名是否正确;

    2、报表的整体显示格式是否符合客户提供的表样;

    3、数据显示格式或误差是否与需求保持一致,如小位数、百分号、单位、汇率等;

    4、报表页面的时间段是否用户选择的时间段;

    5、当输出的内容过多时,分页方式是否正确;翻页时,是否有与上页相同的样式,第2页输出是否正确;

    6、需要特别提醒的数据(一些异常数据)是否突出显示;有些指标计算方法特别或某些指标容易混淆的情况下,页面是否有加注释;

    四、报表功能的使用

    1、各个指标的组合筛选查询是否正常;

    2、输出功能,如导出PDF、excel等使用是否正常;

    3、打印设置、打印效果等是否正常;

    4、分页,或分布导出等是否如常;

    5、导常情况下的使用等。

    五、性能

    测试的前需要了解的信息:用户访问的频率、使用习惯、数据范围等。

    1、数据范围大小;

    2、筛选查询的响应时长;

    3、QPS(即每秒的响应请求数)。

    六、数据的有效性

    1、当数据源有实时数据入库时, 相关报表类的展示多久统计出来?

    2、是实时还是会有延缓?延缓多久?

    3、数据延缓对指标有何影响?

    报表测试的很大关注成分在于数据,那么,测试中对于数据的设计呢?

    报表测试三大数据设计点:

    一、有效数据

    有效数据,顾名思义,是指既符合前台业务规则,又符合统计规则的数据。它们会被统计进报表中,对报表的统计值会产生正面的影响。

    二、无效数据

    无效数据,属于统计规则以外的数据。此类数据,符合前台业务规则,但不符合报表统计规则,即对报表的统计值不会产生任何影响。

    三、异常数据

    异常数据,主要目的是用于检验报表系统对数据的容错能力。此类数据不符合前台业务规则,对报表的统计值会产生负面影响。最常见的场景是,统计值的分母为零。
    

    这类数据的设计,更多地应用于报表系统与业务系统分离的情况中。当报表系统与业务系统互相统一时,异常数据会受到前台业务规则的限制,即异常数据连出现的可能也没有;在报表系统和业务系统分离的情况下,异常数据就很有可能由于数据传输的不同步,造成短时间的出现,此时报表系统对于错误的处理机制就显得非常重要了。

    在这里插入图片描述
    除了针对以上3类数据的设计以外,我们在设计报表测试数据时,还需要注意以下几点:

    1、保证场景间测试数据的独立性

    这是为了保证数据可控而要注意的。如果一组数据的已经在某个场景被使用过了,就不应该再把这组数据应用到其他的场景中,否则一旦出现测试结果与预期结果不一致,就会提高查错的难度。况且保证数据的独立,可以更好地阐述缺陷,保留缺陷现场,等待开发人员来解决。

    2、数据的多样性

    多样性是指为同一个场景准备多组测试数据,因为凭借不同数据才能更好地接近真实,更容易发现问题。

    3、空报表

    所谓的空报表,就是指在报表查询条件下,没有相符的源数据,从而造成报表中的统计值为空。这样的测试,是为了确保报表的正确性,检查报表统计是否有张张冠李戴的现象。

    4、注意数值的设计

    这里所说的数值,是指统计值。

    例如,统计值是百分比时,我们需要覆盖最大值(100.00%)、最小值(0.00%)、中间值(如38.01%)、小数位检查(99.99%)。除了这些,我们还需要考虑负数、百分比超过100%、小数位的四舍五入等情况。

    5、不同报表间的对照

    同一组数据在不同报表中的表现应该是一致的。

    例如,在合同表中,合同总金额是1万元;然而在协议表中查询该合同所创建的协议总金额是1万5千元,那么,这意味着肯定是其中一份报表出现问题了。

    6、历史数据的设计

    历史维度也属于测试的一个重点。历史维度的测试,涉及到历史数据的设计。

    例如,OA中的,A君4月前在市场中心,5月起调到了营销中心,那么5月后A君的业绩是否仍计算在在市场中心?等等。

    总结:

    以上,关于报表测试的一些汇总。其实这大部分是一些测试前辈的经验了,刚踏上修炼之道的我实在不敢造次,但也知道:不管是一万小时定律,还是厚积薄发,当你把知识累积到一定程度的时候就会发现,原来,软件测试的世界也可以这么有意思。
    
    展开全文
  • 银行贷款报表测试模型,非常适用于中小企业贷款。
  • 润乾报表测试用的授权文件有效期到2019年2月,提供给各位报表开发人员试用,其余时间私聊;绝对可以使用 !,不懂得可以私聊。
  • 如何做报表测试[3]

    2021-03-23 16:23:21
    如何做报表测试[3] 软件测试 打印预览 实际打印效果 除了打印之外,用户有可能需要导出报表做进一步的分析或用于和其他报表的比较.所以也应该提供导出报表的功能.一般可以导出为CSV,Excel,pdf,html,xml格式.看...
  • 如何做报表测试[2]

    2021-03-23 16:23:19
    如何做报表测试[2] 软件测试 2.格式的正确 数据验证正确后,就需要看看报表的输出格式是否符合要求.可以从以下几方面来检查。 报表的整体风格:报表是否符合规定的或用户设置的格式。 报表标题:报表的标题是否...
  • C#-WinForm报表测试 WinForm中使用报表 开发平台Windows 8.1Visual Studio 2013Access罗斯文 2007.accdb 程序运行结果 新建C#工程 新建一个Windows窗体应用程序命名为WinForm报表测试 将主窗体name属性设置为...
  • 统计报表测试

    千次阅读 2016-02-03 10:58:57
    报表测试 报表功能的基本要求,就是通过查询/统计/分析,提供用户所需的准确的数据。如果无法实现这个基本功能,则报表完全失去意义。 对于用户来说,报表可以直接影响到他们的决策,例如可能因为报表对销售和库存...

    报表测试

    报表功能的基本要求,就是通过查询/统计/分析,提供用户所需的准确的数据。如果无法实现这个基本功能,则报表完全失去意义。

    对于用户来说,报表可以直接影响到他们的决策,例如可能因为报表对销售和库存情况反映的不准确,导致错误的大量进货;或者因为报表对应收应付金额计算的不准确,而导致企业对资金占用情况做出错误的估计,

    从而导致错误的决策,最终造成用户在经营上的损失。诸如此类,相信只要大家留心,还可以找出很多这样的例子。

    进销存系统中的报表多如牛毛,而且各种不同行业的进销存系统中的业务有区别,报表也有些区别,因此不太可能对各种报表逐个讲解,而主要是把一些报表测试的经验总结成了十几条可以在各种行业的报表测试中应用的“最佳实践”,来跟大家一起分享。希望下面的这十几条像一招招简单实用的“擒拿手”,可以供正在进行报表测试或者准备开始作报表测试的朋友随手拈来,见招拆招,轻松应对这项工作

     

    (1)       提高对业务的熟悉程度

    其实对任何一个软件进行测试,都必须要熟悉它的业务,包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改,通过对界面的浏览和探索性的操作,大概都可以弄明白它的业务流程和业务规则,因为这些内容比较直观,而且在不同的行业中也差不了太多。但是在报表中,是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项,它的算法或者说数据来源,恐怕是比较难看出来的——即使是很类似的一个数据项,在不同行业的实际业务中,它的算法和数据来源也可以能完全不同的。

    所以对于报表业务的熟悉,主要是两个方面:数据项的算法和数据来源,也就是说要明白一个数据项同具体的业务有什么关系,单据的增、删、改或者状态的变化,对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些,那么就无法验证报表中的数据是否准确,也无法通过报表去检查业务系统的正确与否。

    (2)       覆盖所有可能的查询统计方式,而不是以自己的使用习惯为准

    对于报表的使用者来说——一般是企业的中层或高层领导,他们对于报表的要求可能会是多方面的,例如在进销存系统中,可能需要按不同商品进行分类统计,也可能是按供应商分类统计,这些都是由用户在实际工作中的需要来决定的,所以假如一个报表提供了多种查询统计的方法,那么在测试时,只要时间充分,就应该覆盖这些所有可能被用到的查询统计方法,而不是以自己的使用习惯为测试的依据。

    (3)       使用或构造受控的数据环境

    数据对于报表测试来说是一个非常非常重要的问题。因为上面说到,报表的基本功能就是通过各种查询统计分析的方法,为用户提供准确的数据,帮助用户做出决策。那么那些用来进行测试的数据从哪里来呢?

    首先,应该保证准备足够多的有效的数据。前面一条也提到了,在实际测试报表时,应当尽可能的覆盖到报表所提供的各种查询统计方法,因此至少应该保证每一种查询统计方法都应该有对应的数据,得到的结果都不会是0,否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好,能保证全部覆盖,并且刚好够用就可以了,因为数据的准备和生成也是很花时间的。

    其次,要保证数据的可控。数据并不是随意生成的,如果使用通过自动化工具或者通过业务测试时随意的输入的数据来进行报表测试,一般来说是不太可能的。因为如果无法控制数据来源,那么即使知道报表中每个数据项的算法,也无法最终验证报表的查询统计结果是否正确。例如,系统的会有不同类型的单据,每种单据又会有不同的状态,某个报表的统计中,可能会涉及到多种类型和状态的单据,那么在准备数据时,就要充分考虑到这一点,准备各种不同的单据来满足测试的要求。又比如,如果整个系统中只有一个供应商,一个商品,那么测试按供应商分类统计或者按商品分类统计的报表时,意义也就不大了。

    所以如果希望高有效、更高质量的完成报表的测试,那么就要重视并增加对于数据准备工作的关注:用于验证报表功能的数据,一定是专门为报表准备的,并且是经过精心设计,要分析影响数据项算法的各种因素,以及每个因素可能出现的不同变化,这样才有可能覆盖各种查询统计方法;同时,才能保证无论使用哪个数据项的算法进行计算,其结果都是可以预知的——因为数据来源已经被我们控制了。

    特别是对于算法比较复杂,又提供了多种查询统计方式的报表,如果想完整的测试,就需要准备大量的数据。而如果想高效、高质量的完成这项功能,就一定要理解数据准备工作的重要性。

    经过精心设计的数据还有一个好处,就是当在进行业务功能的测试时,不再需要使用一些随意的数据,而是可以通过业务测试的过程,把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要,进行相应的操作。

    如果留心,你也会发现报表测试同其他业务功能测试的有个区别。业务功能(例如单据的新增、审核等)的测试用例设计,通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖;而对于报表功能,虽然没有太复杂的业务流程和规则,但是算法更加复杂,同时报表功能本身就是一种对数据的加工处理,因此会更偏重于对于各种数据来源和算法的遍历或覆盖,也就是要准备各种正常的、异常的数据,来验证报表是否取到的该取的数据、没有取不该取的数据,并且最后计算出了正确的结果。

    (4)       特征性数据的准备

    这又是一个同数据准备有关的问题,也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试,虽然大家各自使用的数据都是经过精心设计的,但是在实际进行报表测试时,还是很难保证其他人的数据不会对自己的测试结果产生影响,最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的,是可控的,但是现在掺杂了别人的数据,就需要花时间去区分这种“假”的错误和真的错误。

    有一个经验是可以借鉴的,就是在初期,团队内对数据的准备达成一直,使数据中的某一项具有特征性,例如分别使用不同的供应商,或者使用不同的商品。最后测试报表时,通过限定选取的数据来源,来保证相互之间尽可能的没有影响。

    (5)       做好数据环境的备份和维护

    虽然数据是经过精心准备的,但是难免在操作过程中因为误操作导致环境的变化,例如不小心把一张单据变成了另外一种状态,或者某个类型的单据多做了一张。对于这种情况,一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表来保存我们事先准备的数据,可以一个文件保存一个类型的单据,例如采购单、入库单、出库单等等,文件中的每张表用来保存不同状态的单据,例如已经审核过的入库单,没有审核过的入库单,全部入库的入库单和部分入库的入库单,等等。假如你一不小心,把一张本来准备入一半的入库单全入了,那也不要惊慌,去重新调整一下你的数据文档,在相应的类型相应的状态的单据列表中新增一张就行了。

    而如果想减少回归测试的工作量,那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础单据已经输入完成,但是还都没有开始审核或者出入库,那么可以备份一下,下次再测的时候可以直接在数据库中恢复这部分原始数据。

    (6)       在业务功能测试通过之后才开始

    这一点相信应该不难理解,如果业务功能本身存在缺陷,导致的数据不准,那么最后进行报表测试也就没有什么意义了。所以,应该在保证各项同报表有关的业务的功能测试通过之后,才开始考虑对报表进行测试。

    (7)       寻求开发人员的协助

    在报表测试中很常见的一个问题,是需求文档中可能没有定义报表的各个数据项的算法,这时候你需要找开发人员帮忙,向他们了解准确的算法和相应的公式。

    (8)       多个报表相互对照

    这是一项“高级”的报表测试技能,需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外,还能够进行横向的联系,知道不同报表之间存在的关系。例如,一个简单的例子,库存报表中,你可以看到商品的出入库情况,而在销售报表中,你可以看到商品的销售金额和销售成本金额,在应收应付报表中,你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间,是否存在一些关联呢?是否会存在一些可以相互验证的地方呢?这个问题,留给大家来思考 ^_^

    (9)       着重对那些算法复杂、与业务功能关联较多的报表的测试

    如果只是简单的把某个日期范围内的所有入库情况统计出来,可能不会出错;但是如果还要考虑按照供应商或商品汇总,同时要选取特定的类型或状态的单据,再进行一些响应的计算,恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样,越是复杂的业务,越有可能出错。

    (10)   留意四舍五入对报表数据的影响

    从这一条开始,后面的内容可以说也是一些在实际测试时要注意的事项。

    这也是一个常见的问题。在一般的进销存系统中,都会存在这种情况,无论小数点后保留几位,总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致,因为拆零引起的,例如10/30*30≠10;或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。

    (11)   留意进/存/销时使用不同单位对报表数据的影响

    例如采购时是5箱,每箱有100盒,而销售单位是盒,入库之后,可能会要求按照销售单位来统计,这时要注意开发人员是否会选择了错误的单位,把500盒弄成5盒。

    (12)   留意业务单据中存在多个日期字段时对报表数据的影响

    一般来说,一张单据上都会有多个日期字段,比如采购单就有采购日期、单据日期、审核日期,而入库单也会有单据日期、入库日期,诸如此类。那么在测试时,一定要留意,开发人员是否按照要求选择了正确的日期,包括日期选取的一致性——是否存在这边取采购日期,那边取审核日期的情况。

    (13)   留意是否存在遗漏的单据类型

    例如像出入库的报表,入库方向的,除了最主要的采购入库外,可能还会包括退货入库、盘盈入库、报溢入库;出库方向的,除了最常见的销售出库,还会包括盘亏出库、报损出库。那么在具体测试时,一定要准备充分这些相应类型的单据,并且要留意开发人员是否遗漏了相应的单据类型。

    (14)   留意不同状态的单据对报表数据的影响

    例如采购单,当采购单发出后,供应商会开始送货,可能第一批之送来了一半的商品,那么这时采购单的收货状态是“未完成” ;当供应商把商品送齐了以后,采购数量=收货数量,则采购单的收货状态变为“已完成”。那这时留意,开发人员在采购报表中,是包含所需要的状态的单据,还是只包含了一部分?

    (15)   留意那些被当做默认规则的因素

    有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面,这些规则不会体现在界面,也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以,一定要同开发人员反复确认,保证自己已经了解了同报表各数据项计算有关的各个因素。

    (16)   保证测试人员可以通过UI 找到自己所需的所有原始数据

    在进行系统测试时,无论是报表,还是一般的业务功能测试,都不要去直接通过SQL语句查询数据库中的内容,而是通过UI来输入,再通过UI体现处理的结果进行验证——因为这是系统测试,不是集成测试,将来用户是决不会去直接查数据库的。因此,如果需要对报表的结果进行验证,应该通过其他的功能模块,去查询业务单据,或者其他报表,根据UI体现的结果,来进行确认。

    (17)   检查大数据量对报表的影响

    报表测试也会涉及到性能测试,主要是在大数据量查询统计的测试。大数据量一是说原始数据多,二是被操作、计算的数据多,三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表,10万条数据和100万条数据时的响应时间将表现出巨大的差别。

    (18)   不要遗漏权限控制和访问安全性的测试

    这里说的权限控制不是谁可以访问某个模块,谁不可以访问某个模块,而且数据的计算也没有直接的关系,而是侧重于报表设计的测试。我们都知道不同的报表是设计给不同的人看的,例如出入库报表是给仓库管理人员看的,里面不会包含商品的价格,而只会包含数量;而财务报表中,只会包含采购、销售的金额,而不会包含数量,这样才能保证可以相互对照,不会出现营私舞弊的行为。那么在测试时,应当考虑报表是否泄漏了不该泄漏的信息。当然,这里对业务的熟悉程度就是更高的要求了。

    又如,不同的业务员只能看到同自己有关的业务,但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域,他们之间的销售情况是互相保密的。

    还有一种情况,系统的用户可能会为他的供应商提供一个专门的程序或者Web页面,供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况,一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况,如果某个商品由多个供应商同时提供,那么其中一个供应商应该只能看到他提供的那部分,而看不到其他供应商提供的同一商品的情况。当然,这种功能一般都是通过外网(internet)来访问的,所以也还要考虑相应的访问安全性测试,以免泄漏重要的商业信息。


    ================================================================================================


    ================================================================================================

    近日,看了陈雷的文章《进销存系统的报表测试http://www.51testing.com/html/6/1871.html ,自己也在这方面接触了两年的时间,颇有同感,他的经验总结得非常到位,在此,希望能作点补充,或者是以另一种角度来讨论!

    报表的重要性,大家都知道它有举足轻重的地位,特别是成本/利润类报表、月报、年报等,这里就废话少说了!所以,它对测试条件的要求、测试覆盖率的要求、测试深度的要求都非常高,而且不是一般的测试员和新手随便就能测试的,一定是对业务和相关的法规非常熟悉,最好能有实践经验的、较强分析能力、综合能力高的测试员来做!

    总结了报表在测试时需要关注的十大特性:
    一、 正确性
    报表的最低要求和基本特征就是它的正确性!
    1.报表格式的正确
    不同的报表有不同的格式,有些是行业内默认的,有些是明文规定的,还有自定义的,按照不同条件还可以分各种各样的,如:按照货品的仓库进出情况,分入库类报表、出库类报表和仓库类报表等;按照报表的类型,分图表,固定行列报表,分栏报表、交叉报表等等!因此,报表的格式不是随便增减的,一般包括表头、表体、表尾、以及附注等,测试时需要具体问题具体分析,根据需求提供的标准格式模板!
    2.报表内容的正确
    这是测试的重中之重,包括数据的算法、数据的来源、数据的对应关系、小数位问题、四舍五入问题、单位换算问题、税率换算问题、明细与合计是否一致、单据的类型/状态改变后对报表的影响等!

    二、 时段性
    这个很容易了解,没有那张报表在时空上的统计是漫无边际的,就算是“所有”或者“全部”,都是有它的时效!特别是财务类报表,有月报、季报、年报、甚至还有现金日记帐等,都表现出时段在报表中的必要。

    三、 条件性
    每个报表都是针对特定的条件而作出的输出,要想达到目的,是需要一定条件的。如:统计XX供应商XX业务员在XX时期采购XX商品的情况,在查询时就至少需要四个条件了!
    在测试查询条件时,通常采用正交的方法来增加它的测试覆盖率,但是要注意的是,测试数据的选取非常重要,我们都尽量模拟真实的、有代表性的、经过精心设计的数据!

    四、 可比性
    这在报表的分析和成效的判定上,显得尤其重要,通常报表的测试,不仅只是对单张报表的测试,还需要多张同时进行比较,多张可以是指同一时期不同类型的报表、不同时期同一类型的报表、不同类型与不同类型的报表(但它们之间必然存在某种关系的);还有什么同比的、类比的等!
    目的是找出它们之间的联系和区别,然后获得更深层次的某种规律或者业务流程的脉络。简单来说,就是从实践上升到理论!
    举个简单的例子:我们都知道财务报表的会计原则是“有借必有贷,借贷必相等”,因此,每个财务类报表都有借、贷两方;然而从销售收入报表、销售支出报表和销售利润表,显然得出:销售收入-销售支出=销售利润,这一条无人不晓的规律!

    五、 穿透性
    这个也很容易理解,大多数的报表都不是孤立的,例如:从汇总表可以穿透到明细表,从明细表又可以穿透到单据,从单据甚至可以穿透到具体的产品;虽然它们的层次深度可能不一样,但它们与某某之间有着奇妙的联系!
    在测试中,一定要理清它们之间的层次、顺序,这就需要对业务的理解和知识的积累!

    六、 隐蔽性
    这里不是指报表的数据或者结果隐蔽,而是指所统计的数据来源的隐蔽。例如:入库类的,除了正规的采购入库,还会有估价入库、退货入库、盘盈入库、报溢入库、拆卸入库(将**产品或者已经打包的产品,拆卸后将元素产品重新入库)等;出库类的,除了常见的销售出库,还会有采购退货、盘亏出库、报损出库、生产领用、**领用等。请注意的是,有些进销存系统还分有帐面库存数和实际库存数两种的!
    另一个陷阱:有些进销存系统的应收帐款是由正常的应收帐款加上预付转应收的部分组成的;同理,应付帐款是由正常的应付帐款加上预收转应付的部分组成!

    七、 时序性
    上面说了时段性,现在到说说时序性,顾名思义,就是指业务发生的时间顺序。在明细报表中,每项明细都应该有记录业务发生的时间,它的先后顺序很重要。
    举个简单的例子:某仓库库存量为100,三月份销售出库50,四月份采购入库也是50,如果将四月份的采购入库计入三月份的,虽然年仓库库存量还是100,没有变,但是对于月度库存量和季度库存量就影响大了!

    八、 安全性
    1.这个主要体现在报表的权限控制上。因为报表是针对不同的用户设计的,特别是敏感的数据,如个人资料、产品成本、商业信息等,这就需要加强访问权限的控制,有的是只读的,不能过滤条件或者修改其他的查询条件;有的根据用户等级来分配权限等!
    2. 通过用户角色和密码来控制:业务员只能看到自己的业绩报表
    3.通过用户角色的等级来控制:非财务主管不能打开销售收入利润表等

    九、 直观性
    报表的数据、结果清晰明了,页面简洁、排版合理,不能给用户产生模糊或者引起奇异的感觉;一般合计的部分或者关键字段都需要突出显示;有的报表需要图文并茂,选择最佳的报表类型。

    十、 打印
    仅仅测试通过查询得到的报表,是不足够的;通过屏幕看到报表的效果,也是不能全信的,需要持有怀疑的态度,把报表打印出来,重新检查是否适合所需的效果!

    包括:打印模板的设计、套打样式、自定义模板、打印调试、打印时间等方面。 

    展开全文
  • ERP报表测试的总结

    2015-06-25 09:21:11
    ERP报表测试的总结
  • 报表测试方法总结

    2017-02-04 09:27:07
    1.提高对业务的熟悉程度 和功能测试以及其他测试一样,报表测试也需要熟悉业务,包括业务流程、业务规则以及数据存储,不同点是报表测试要理解每个指标的算法、数据来源以及要明白具体的业务动作和指标之间的关系....
  • 测试用例方法报表都懂,就是没有测试用例模板,如何准备数据,想借鉴一下准备好数据的报表测试用例,万分感谢
  • bi报表测试

    千次阅读 2016-11-24 16:54:20
    大量的报表,在生成后,是怎样进行数据测试的呢? 你必须要保证每一项数据都是正确的,而且在多个有关联的报表间,你要能找到对应的数据,并且保证其一致,比如说,你在A报表里统计了兴庆区一室一厅房型的面积,...
  • 如何做报表测试

    2014-07-17 09:48:08
    报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给...
  • CrystalReport水晶报表测试代码集锦,非常全的代码。
  • 一、熟悉基本的业务框架:这一步的是报表测试的起始点和落脚点。业务框架主要包括业务流程和业务规则。 二、报表测试和一般的业务功能测试的区别。首先报表业务很难通过界面的浏览来看到其业务形式,而对报表的熟悉...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 90,875
精华内容 36,350
关键字:

报表测试