数据报表类（BI）项目测试应该如何去啃？

　　测试工作是一项十分枯燥的工作，与之相对的测试人员必须有足够的耐心、绝对的细心等素质才能完美的完成这项工作。

　　从最初的瀑布模式，到如今风靡的敏捷，Devops等；从最初的最后一道关卡到渗透至各个流程，再到一名人员身兼数职（Devops），测试人员的人员素质要求越来越高，各类新兴产业的层出不穷，人工智能、大数据、区块链等的兴起，只能说没两把刷子能吃这口饭的时间是不会长的，因此，惊涛骇浪下，仍需默默前行！

　　BI，（Business Intelligence）这个名词应该都不会陌生，BI商业智能，它是一套完整的解决方案，用来将企业中现有的数据进行有效的整合，快速准确地提供报表并提出决策依据，帮助企业做出明智的业务经营决策。（百度百科）说白了就是一系列数据资源的整合（具体模式不谈），那么面对该类的项目应该如何去测试？测试时需要注意的问题。

　　

　　首先分析该类项目的特点：数据！报表！绝对是该类项目的主题。围绕这两个主题应该如何去拓展思维，思路呢？整合了一些博客资源，输出该篇随笔。

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

　　

1． 源数据的来源

源数据，即保存在报表数据库中的数据。源数据的来源，大致可分两大类：

A． 由业务系统生成

报表数据库中的数据是由前台业务系统插入的。报表系统和业务系统是关联着的，甚至它们根本就在使用同一个数据库。如此一来，前台的操作即直接反应在报表的统计值上。在这种情况下，我们测试用例的设计，重点放在影响报表统计值的前台业务场景的设计上。

例如，某点播系统中的点播率报表，其报表统计值有效点播次数的源数据，就是点播业务所关联的点播数据库表。在测试用例设计中，我们重点考察不同场景的点播对报表统计值的影响。而场景的设计除了考虑前台业务规则外，更重要的是考虑报表的统计规则。如例子中，有效点播次数的统计规则是，视频购买后1分钟内的重复点播不计入有效点播次数中。这样一来，场景的设计就不能只是点播一次和点播多次这么简单。

B． 来源于第三方数据库

有些报表系统与业务系统是分隔的，各自独立的。这样的设计，更多地出现在大型系统中。如此设计，既可以确保业务系统和报表系统各自的性能，又可以提高报表系统的扩展能力，即使用一个报表系统对不同业务系统的数据进行整合和分析。当然这个设计也有不足之处，即报表的实时性。

在这种情况下，测试用例设计的重点应该放在报表数据库源数据的设计上，重点考察第三方数据到报表数据库传递的正确性，源数据的完整性，以及不同业务源数据的相互影响。

2． 报表的算法

算法，是指源数据演变成统计值的过程。报表的算法应详细清晰地记录在Functional Specification中。根据算法的复杂程度，我将报表划分为三大类：

A． 罗列式

罗列式报表是将源数据根据规则进行罗列，不涉及任何计算，如话费清单、销售清单等。对于此类报表，测试的重点在于：

• 罗列项的完整性，即FS中所规定的源数据的属性项是否列举完整；
• 列举数据的正确性和完整性；
• 数据属性变动对报表的影响，如，修改客户地址后，报表是否能正确地显示客户的最新地址；

B． 统计式。

统计式报表是指，统计值是由单个源数据简单的加或平均得来的报表。此类报表，我们可以采用增量的方法来测试。

例如，前面所举的有效点播次数统计值。应用增量测试方法，就是在执行不同的场景后，检查报表的统计值是否在原来的基础上有对应的增减。

使用增量的方法来测试报表，既可以避免复杂的数据设计，又可以提高测试效率。但是增量测试方法的使用范围比较狭窄，对所测试的统计值要求不能太复杂。

C． 算法式

算法式报表是指，统计值是由一个或多个源数据根据一定的公式得来的报表。此类报表中的统计值，涉及到多表数据，多业务流程，是报表测试的难点。

在设计此类报表的测试用例时，建议理清以下两点：

• 统计值所关联的源数据；
• 源数据关联的业务规则；特别注意，源数据受多个业务规则共同影响的情况。

数据测试

1． 有效数据

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

2． 无效数据

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

3． 异常数据

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

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

注意点：

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

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

2． 数据的多样性

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

3． 不要忘了空报表

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

4． 注意数值的设计

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

5． 不同报表间的对照

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

6． 注意历史数据的设计

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

7． 测试数据的备份

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

3：权限

报表系统的权限控制包含功能点和数据两方面的权限控制。

功能点权限控制，是指登录用户对某一功能点有无访问权限的控制；

数据权限控制，是指登录用户对数据的访问范围的控制。

4：UI设计

 

1． 善用颜色

我在写平时的email或者交付测试报告的时候，经常被老板提醒颜色的使用。在同一个页面中，最好不要出现多于3种颜色。因为本来颜色的使用是为了突出重点，然而如果过多地使用颜色，就等于到处都是重点，最后的结果就是没有重点。因此善于使用颜色也是UI设计的关键。

¨         使用颜色区分报表的类别

这样做是为了方便用户区分报表。例如，把红色加粗字体应用于销售类报表名，把蓝色加粗字体应用于出勤类报表。那么用户以后看见红色标题的页面就知道是销售类；蓝色标题的页面就知道是出勤类了。

¨         应用颜色区分阈值数据

如，对于销售类报表，Manager们关心的是没有达到销售指标的区域。如果报表中对没有达到指标的数据均以红色字体呈现，那么Manager一打开页面一眼就可以从众多的数据中看到他最关心的部分，大大提高了阅读报表效率。

2．  统一格式

一般报表分为两大部分，表头(Head)和表体(Body)。表头，一般放置报表名称以及查询条件；表体，由表格形式的报表组成，可以为一个也可以为多个(子报表)。在统一格式方面，我们需要注意的地方有：

¨         字体

不同的地方应使用不同的标准，如，表头中的报表名称，表体中的统计值的字体和大小应该不一样；然而不同的报表的报表名称应使用一种字体和大小。

¨         表格

定义最小单元格，而报表中只能使用最小单元格的整数倍作为表格的大小。例如，UI标准定义最小单元格为(长X宽)=1cm X 0.5cm；如果遇到某单元格中需要填写的值长度为1.3cm时，此时对应单元格应该为2 cm X 0.5cm。这个有利于导出格式的一致性。

¨         单位

不同的统计值使用的单位是不一样的。不管单位是什么，我们都应该放置于一个统一的地方。例如，可以统一标注在报表的某个地方，写着(Unit：￥)；或者是直接填入统计值中，如￥ 3.00。

¨         术语

使用行业术语，增加报表的专业性。

3．  导出和打印格式

一般报表的使用者，会更多地应用导出功能导出成别的格式，或者是直接打印出来查看。此时，我们就需要检查报表导出后格式有没有变形。打印时，报表会不会因为分页打印而造成报表内容缺失，或者不易被查看。