报表如何测试？

报表测试根据项目的定义有大有小，有时只是作为软件的一部分进行测试，有时整个项目都是测试各种报表。但无论如何，报表的作用始终是将系统已存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户，以便用户进一步做数据分析和数据统计。

软件中的报表实现一般分为定义报表所需数据（一般可以通过选择或手工输入条件来缩小数据范围）和定义报表格式2部分。报表格式除了如国家个行业标准中规定的报表使用固定格式，大多是根据企业或用户需要定制报表。所以：

1、做报表测试要注意以下几个方面：

1.1数据的准确性

用户使用报表就是期望通过一个简单方便的平台能快速的查找到他所需要的数据.所以在测试报表时首先就要检查报表中的数据是不是用户需要的数据,如果没有加工的数据,是否保持了原貌; 加工过的数据查看加工的结构是否和手工加工的结果一致.简言之,需要测试以下内容.

数据的来源：来源于哪张表,哪个字段,数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确.

数据的范围：是否只显示了报表设置的对应范围；特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为2006-9-27~2007-9-27,那么是否应该包含9-27这天.

数据的对应关系：数据库中的字段是否与报表中的信息对应

数据的格式：小数位,千位符,四舍五入等是否与报表设置一致；单位或税率转换是否正确；组合显示的数据是否合理

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

流水号：如报表有使用流水号,流水号的生成和格式是否正确.取消操作是否会生成流水号.

明细与合计的一致性：各部分明细或小节是否与最后总和一致

其他：

测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.

有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆..一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据.

1.2格式的正确

数据验证正确后,就需要看看报表的输出格式是否符合要求.可以从以下几方面来检查.

报表的整体风格：报表是否符合规定的或用户设置的格式

报表标题：报表的标题是否是正确的报表名称；如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的; 或者XX公司2006-9-27~2007-9-27的网站访问量,这个时间段也是用户选择的.

公司的一些标志：如logo,名称,地址之类的是否正确

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

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

友好性：数据或图表是否清晰,一目了然,数据的展示符合用户的习惯；需要特别提醒的数据(如合计,异常数据)是否突出显示；复杂算法处,用户不明白或容易混淆处是否有注释；一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等

1.3权限的控制

对于有权限控制的系统，报表当然也应该和用户所具有的权限相一致。需要从两方面校验权限的控制。

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

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

1.4报表的输出

报表在电脑上生成后，并不是报表的结束。报表一般都需要打印出来他用，如开会或者提交审批之类。所以报表的打印功能也是非常重要的。测试主要分成三部分：

● 打印设置

● 打印预览

● 实际打印效果

除了打印之外，用户有可能需要导出报表做进一步的分析或用于和其他报表的比较。所以也应该提供导出报表的功能。一般可以导出为CSV,Excel,pdf,html,xml格式。

2、报表的测试主要分为以下几个方面：

界面，安全性，准确性，展示速度（性能）。

2.1数据统计方面

报表统计数据的正确性；

数据准确性测试，带有报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为办理业务的而提供帮助的。

比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。

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

报表统计数据的完整性；

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

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

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

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

③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。呵呵，这要看测试人员的需求了解深度个人能力了。插几句不想干的话，做测试工作总让我保持快乐状态，前两天我的一个同事说，公司里一直没有人喜欢做测试工作，这个工作太枯燥。嘿嘿，我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥，编程其实不也是重复嘛，人每天谁不重复昨天的事啊，吃饭，吃这个动作重复一生，有谁觉得麻烦枯燥啦？

④使用SQL和手工计算进行比对。以上是差错方式，接下来讲一下查什么错？哪些地方容易出错

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

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

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

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

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

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

报表统计数据的合法性；比如，统计金额字段需求要求有“$”等；

2.2报表格式

表头字段表示的正确性；

表头字段表示的完整性；

表头字段表示的字体，字号，美观程度；

各统计字段的显示是否满足需求；比如：数据过长时要求折行还是缩小；

页眉和页角的表示；

2.3报表的预览和印刷

预览中的显示完整性；

多页情况下，第2页的表头显示；

能否实现需求要求的特定印刷情况；（比如，印刷使用指定的模板）

预览后印刷；

不预览，直接印刷

需求规定各类打印机的测试；

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

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

输入界面要求是：

①输入项字段长度不允许超过字段长度；

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

③用户 权限范围外的输入，不允许查询。如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。

对于选项，应不出现可选择的用户权限以外的选项。

对于汉字模糊查询，考虑不常见字，如“?”即汉字因译码问题，造成的汉字存储出现乱码问题。

输出界面要求：

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

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

③报表标题明确，不能含糊误导用户

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

3、测试数据的准备

在报表测试用例设计中，测试数据是关键。正如Jackie在《进销存系统中的报表测试》中所言，如果希望更有效、更高质量地完成报表测试，就要重视并增加对于数据准备的关注。其实，测试数据也是为测试场景服务的，一个或者一组的测试数据往往是为了验证在某个测试场景下报表是否能正确的展现统计值。归根结底，测试场景的设计才是关键的关键。在之前的报表分析后，测试用例的基本框架已经完成。接下来我们需要在这个框架上，细化和补充场景设计，然后通过场景，设计出对应的测试数据。

对于测试数据的设计，我将其粗略地分为3大类：

3.1有效数据

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

3.2无效数据

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

3.3异常数据

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

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

除了针对以上3类数据的设计以外，我们在设计报表测试数据时，还需要注意以下几点：

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

这是为了保证数据可控而要注意的。如果同一条或者同一组测试数据被使用到多个报表统计值的检查中时，一旦出现测试结果与预期结果不一致，就会提高查错的难度。况且保证数据的独立，可以更好地阐述defect，保留defect现场，等待开发人员来解决。

3.5数据的多样性

多样性是指为场景而准备的多组测试数据。因为凭借不同数据才能更接近真实，更容易发现问题。此前我就碰到过类似的情况：在测试一份报表中，我发现同一个统计值，一月份的是正确的，三月份的却是错误的。正常情况下，使用同样的程序计算只有两种结果，要不两者都对，要不两者都错。怎么会出现一对一错呢？后来开发人员经过检查，发现还是计算程序中存在的问题。而出现一对一错是因为一月份与三月份的数据使用了不同组的测试数据，而正好一月份的数据，在错误的计算程序中也能计算出正确的值。由此说明，报表的测试是需要多组测试数据支持的，否则defect就会从我们眼皮底下溜走了。

3.6不要忘了空报表

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

3.7注意数值的设计

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

3.8不同报表间的对照

同一组数据在不同报表中的表现应该是一致的。例如，在销售总额报表中，营业点A的一月份总计是1万元；然而在营业点A的销售清单却只能查看到9000元的销售数据。那么，这意味着肯定是其中一份报表出现问题了。

3.9注意历史数据的设计

在基于OLAP技术设计的报表系统中，历史维度也属于测试的一个重点。历史维度的测试，涉及到历史数据的设计。例如，销售员A在2011年1月份，服务于营业点A，那么他的销售业绩就应该计算到营业点A中；然而到了2月份销售员A调到了营业点B，那么他2月份以后的销售业绩就应该计算到营业点B 中。报表是否能正确地将销售员A在不同时间的销售业绩计算到对应的营业点中，就需要我们设计一批针对销售员A的销售源数据来检查。

3.10测试数据的备份

与一般的系统测试相同，报表的测试也需要经历多个版本。此外，报表测试数据的量很大，起码是业务测试数据的3倍以上。因此，数据的备份就非常必要了。我使用过数据库备份文件、SQL语句、CSV或excel格式3种方式来备份数据。通过比较，我推荐大家采用CSV或者excel格式来保存数据。因为在不同版本的测试中，我们很难避免数据库结构或者数据表字段的变化。如果采用数据库备份文件，一旦数据库发生了一点变化，就导致这个备份无法使用；SQL语句可以避免这样的问题，但保存在SQL语句中的测试数据不直观，且不方便修改。因此，CSV或excel格式使用起来更简单，而且很多数据库 都提供批量导入CSV或者excel文件的功能。

总结：验证报表，主要是验证SQL。所以很多时候报表数据不对，基本是开发SQL逻辑写得有问题导致。

点击屏幕右上方分享给好友

让阅读分享成为一种习惯