报表测试主要分为：报表界面测试、报表安全性、报表准确性、报表展示速度（也就是性能）。
数据准确性测试
报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为办理业务的而提供帮助的。比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。
另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。
对系统中的报表数据准确性测试方法较为灵活，
①系统中报表重叠的进行比对
②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对，
③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。
报表差错测试
Ø 原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。
Ø 数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。
Ø 数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。
Ø 数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。
Ø 由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了if else,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。
Ø 最后一项，当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。
报表的界面和输入输出测试
界面分为输入界面和输出界面；统一的界面要求：美观、统一、易操作。输入界面要求是：
①输入项字段长度不允许超过字段长度；
②输入不符合字段要求的，不允许查询。如money类型，在输入汉字，字母、特殊字符等不允许查询，并有友好的操作提示。
③用户权限范围外的输入，不允许查询。如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。
④对于选项，应不出现可选择的用户权限以外的选项。⑤对于汉字模糊查询，考虑不常见字，如“�”即汉字因译码问题，造成的汉字存储出现乱码问题。
输出界面要求：
①因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据，不能因为打印缺少了报表表格框
②报表排列方式可调，用户可按任意列升序或降序排列，或者，按某一关键列的一定规则排序
③报表标题明确，不能含糊误导用户
④报表内可关联查询的项，应能特殊显示，如鼠标有箭头变为手掌，子报表格式与父报表格式统一，数据统一。
一、报表测试系列之报表分析
1． 源数据的来源
源数据，即保存在报表数据库中的数据。源数据的来源，大致可分两大类：
A． 由业务系统生成
报表数据库中的数据是由前台业务系统插入的。报表系统和业务系统是关联着的，甚至它们根本就在使用同一个数据库。如此一来，前台的操作即直接反应在报表的统计值上。在这种情况下，我们测试用例的设计，重点放在影响报表统计值的前台业务场景的设计上。
例如，某点播系统中的点播率报表，其报表统计值有效点播次数的源数据，就是点播业务所关联的点播数据库表。在测试用例设计中，我们重点考察不同场景的点播对报表统计值的影响。而场景的设计除了考虑前台业务规则外，更重要的是考虑报表的统计规则。如例子中，有效点播次数的统计规则是，视频购买后1分钟内的重复点播不计入有效点播次数中。这样一来，场景的设计就不能只是点播一次和点播多次这么简单。
B． 来源于第三方数据库
有些报表系统与业务系统是分隔的，各自独立的。这样的设计，更多地出现在大型系统中。如此设计，既可以确保业务系统和报表系统各自的性能，又可以提高报表系统的扩展能力，即使用一个报表系统对不同业务系统的数据进行整合和分析。当然这个设计也有不足之处，即报表的实时性。
在这种情况下，测试用例设计的重点应该放在报表数据库源数据的设计上，重点考察第三方数据到报表数据库传递的正确性，源数据的完整性，以及不同业务源数据的相互影响。
2． 报表的算法
算法，是指源数据演变成统计值的过程。报表的算法应详细清晰地记录在Functional Specification中。根据算法的复杂程度，我将报表划分为三大类：
A． 罗列式
罗列式报表是将源数据根据规则进行罗列，不涉及任何计算，如话费清单、销售清单等。对于此类报表，测试的重点在于：
- 罗列项的完整性，即FS中所规定的源数据的属性项是否列举完整；
- 列举数据的正确性和完整性；
- 数据属性变动对报表的影响，如，修改客户地址后，报表是否能正确地显示客户的最新地址；
B． 统计式。
统计式报表是指，统计值是由单个源数据简单的加或平均得来的报表。此类报表，我们可以采用增量的方法来测试。
例如，前面所举的有效点播次数统计值。应用增量测试方法，就是在执行不同的场景后，检查报表的统计值是否在原来的基础上有对应的增减。
使用增量的方法来测试报表，既可以避免复杂的数据设计，又可以提高测试效率。但是增量测试方法的使用范围比较狭窄，对所测试的统计值要求不能太复杂。
C． 算法式
算法式报表是指，统计值是由一个或多个源数据根据一定的公式得来的报表。此类报表中的统计值，涉及到多表数据，多业务流程，是报表测试的难点。
在设计此类报表的测试用例时，建议理清以下两点：
- 统计值所关联的源数据；
- 源数据关联的业务规则；特别注意，源数据受多个业务规则共同影响的情况。
二、报表测试系列之测试数据设计
对于测试数据的设计，我将其粗略地分为3大类：
1． 有效数据
有效数据，顾名思义，是指既符合前台业务规则，又符合统计规则的数据。它们会被统计进报表中，对报表的统计值会产生正面的影响。
2． 无效数据
无效数据，属于统计规则以外的数据。此类数据，符合前台业务规则，但不符合报表统计规则，即对报表的统计值不会产生任何影响。
3． 异常数据
异常数据，主要目的是用于检验报表系统对数据的容错能力。此类数据不符合前台业务规则，对报表的统计值会产生负面影响。最常见的场景是，统计值的分母为零。
这类数据的设计，更多地应用于报表系统与业务系统分离的情况中。当报表系统与业务系统互相统一时，异常数据会受到前台业务规则的限制，即异常数据连出现的可能也没有；在报表系统和业务系统分离的情况下，异常数据就很有可能由于数据传输的不同步，造成短时间的出现，此时报表系统对于错误的处理机制就显得非常重要了。
除了针对以上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文件的功能。
三、报表测试系列之基于OLAP的报表测试
OLAP (On-Line Analysis Processing)，联机分析处理，是一种用于组织大型商务数据库和支持商务智能的技术。
1． 了解系统架构
根据黑盒测试方法的原则，不管报表系统内部采用的是什么技术，我们只需要定义好Input/Output就能测试出系统是否正确运行。然而，这对于基于OLAP技术开发的系统，远不足够。了解报表系统架构，是指我们需要去了解系统的组件、每个组件的职能、组件之间的联系、数据流的走向。当有了清晰明确的概念后，我们才可以明确测试用例需要涵盖的范围；当遇到Defect时，就更容易追踪问题的根源了。
系统架构一般在FS中有概述，在ADS中有详细描述。对于测试人员而言，除了认真阅读这些文档外，还要在ADS的Review Meeting中仔细地听，并多发问。请不要认为自己的问题对于设计人员而言是简单而没有意义的。相反，你的发问，可以使设计人员反复地去思考设计。他解释的过程，也是理顺思路的过程。经得起推敲的设计，才是合理的设计。
2． 维度缺失测试
基于OLAP技术的系统，一般包含有两大组件Data Ware和Cube。Data Ware就相当于一个数据仓库，用来储存生成报表的源数据；Cube就是那个多维度的数据集，我们可以把它想象成一个魔方，每一条棱都是一个维度，而中间的方格就是维度切片下的各个数据。那么让我们想象一下，如果魔方没有了棱会如何呢？这个就是我们这里所说的维度缺失测试。
维度缺失，指的是事实数据找不到与之对应的维度值。这也属于异常数据的一种。例如，Data Ware中有营业点A的销售数据，然而维度中却没有营业点A的定义，那么这条销售数据应该放置在Cube的哪个地方呢？是暂时不处理，等待维度补全后再重新填入Cube；还是使用推断成员的技术，自动补充缺失维度呢？这是设计时需要确定，也是测试时需要关注的问题。
3． 测试点的选取
|
产品 |
区域 |
营业 |
Jan-11 |
Feb-11 |
Mar-11 |
Apr-11 |
Total |
|
Iphone |
大中华 |
中国大陆 |
10 |
10 |
10 |
10 |
40 |
|
港澳 |
10 |
10 |
10 |
10 |
40 |
||
|
Subtotal |
20 |
20 |
20 |
20 |
80 |
||
|
美洲 |
美国 |
15 |
15 |
15 |
15 |
60 |
|
|
加拿大 |
15 |
15 |
15 |
15 |
60 |
||
|
Subtotal |
30 |
30 |
30 |
30 |
120 |
||
|
Subtotal |
50 |
50 |
50 |
50 |
200 |
||
|
Ipad |
欧洲 |
英国 |
20 |
20 |
20 |
20 |
80 |
|
法国 |
20 |
20 |
20 |
20 |
80 |
||
|
Subtotal |
40 |
40 |
40 |
40 |
160 |
||
|
美洲 |
美国 |
25 |
25 |
25 |
25 |
100 |
|
|
加拿大 |
25 |
25 |
25 |
25 |
100 |
||
|
Subtotal |
50 |
50 |
50 |
50 |
200 |
||
|
Subtotal |
90 |
90 |
90 |
90 |
360 |
||
|
Total |
140 |
140 |
140 |
140 |
560 |
||
基于OLAP技术的报表系统中，我们选取数据测试点的原则：
n 维度的统计值
原因在于报表中每一行所应用的Measure都是一样的，所以说只要一行中的一个算对了，整一行都会算对。如上表所示，底色为黄色的统计值我们都需要验证。
n Total值
Total值的测试主要是应用在统计值不是简单的求和的情况下。如，百分比，或者需要应用公式的统计值。这些Total值不是简单的将所有维度值进行相加，而是需要从源数据中重新抽取数据应用公式计算而来的。
四、报表测试系列之权限控制
报表系统的权限控制包含功能点和数据两方面的权限控制。功能点权限控制，是指登录用户对某一功能点有无访问权限的控制；数据权限控制，是指登录用户对数据的访问范围的控制。本文将对数据权限控制的测试进行详细的介绍。
首先，我们假设有销售业绩报表系统中预设有5个权限控制点：
n All ---- 可以查看所有数据
n Product Manager ---- 可以查看所管理产品的所有数据
n Center Manager ---- 可以查看所管辖区域的所有数据
n Team Lead ---- 可以查看所管理营业点的所有数据
n Sales ---- 可以查看自身的所有数据
其次，我们需要测试的其中一份报表是
|
产品 |
区域 |
营业点 |
Jan-11 |
Feb-11 |
Mar-11 |
Apr-11 |
Total |
|
Iphone |
大中华 |
中国大陆 |
10 |
10 |
10 |
10 |
40 |
|
港澳 |
10 |
10 |
10 |
10 |
40 |
||
|
Subtotal |
20 |
20 |
20 |
20 |
80 |
||
|
美洲 |
美国 |
15 |
15 |
15 |
15 |
60 |
|
|
加拿大 |
15 |
15 |
15 |
15 |
60 |
||
|
Subtotal |
30 |
30 |
30 |
30 |
120 |
||
|
Subtotal |
50 |
50 |
50 |
50 |
200 |
||
|
Ipad |
欧洲 |
英国 |
20 |
20 |
20 |
20 |
80 |
|
法国 |
20 |
20 |
20 |
20 |
80 |
||
|
Subtotal |
40 |
40 |
40 |
40 |
160 |
||
|
美洲 |
美国 |
25 |
25 |
25 |
25 |
100 |
|
|
加拿大 |
25 |
25 |
25 |
25 |
100 |
||
|
Subtotal |
50 |
50 |
50 |
50 |
200 |
||
|
Subtotal |
90 |
90 |
90 |
90 |
360 |
||
|
Total |
140 |
140 |
140 |
140 |
560 |
||
表1
我们在设计测试用例和设计测试数据时，可以考虑从以下切入点设计：
1． 权限控制点与报表筛选信息粒度一致
这种情况适用于测试All、Product Manager、Center Manager、Team Lead权限。在这种情况下，我们可以用筛选信息来检查数据权限的控制。
¨ 对于拥有All权限的用户而言，他所能查看的应该是全部数据组合起来的报表，如，表1
¨ 对于拥有Product Manager权限的用户而言，他的权限点与报表中筛选信息“产品”相重合，因此他能查看的是某一产品的数据组合，如，表1黄色区域
¨ 对于拥有Center Manger权限的用户而言，他的权限点与报表中筛选信息“区域”相重合，因此他能查看到的是某一区域的数据组合，如，表2
|
产品 |
区域 |
营业点 |
Jan-11 |
Feb-11 |
Mar-11 |
Apr-11 |
Total |
|
Iphone |
美洲 |
美国 |
15 |
15 |
15 |
15 |
60 |
|
加拿大 |
15 |
15 |
15 |
15 |
60 |
||
|
Subtotal |
30 |
30 |
30 |
30 |
120 |
||
|
Ipad |
美洲 |
美国 |
25 |
25 |
25 |
25 |
100 |
|
加拿大 |
25 |
25 |
25 |
25 |
100 |
||
|
Subtotal |
50 |
50 |
50 |
50 |
200 |
||
|
Total |
80 |
80 |
80 |
80 |
320 |
||
表2
¨ 对于拥有Team Lead权限的用户而言，他的权限点与报表中筛选信息“营业点”相重合，因此他能查看到的是某一营业点的数据组合，如，表2黄色区域
2． 权限控制点与报表筛选信息粒度不一致
这种情况适用于测试Sales权限。Sales权限比报表中最小粒度的“营业点”还要小。因此，在准备这个测试用例的数据时，我们需要为同一个营业点准备不同Sales的源数据，也需要为同一个Sales在不同营业点准备源数据。
对于以上两种情况，拥有Sales权限的不同用户，可能查看到以下几种报表
¨ Sales A，仅服务于一个产品一个营业点
|
产品 |
区域 |
营业点 |
Jan-11 |
Feb-11 |
Mar-11 |
Apr-11 |
Total |
|
Iphone |
美洲 |
美国 |
10 |
5 |
2 |
1 |
18 |
¨ Sales B，服务于一个产品的多个营业点
|
产品 |
区域 |
营业点 |
Jan-11 |
Feb-11 |
Mar-11 |
Apr-11 |
Total |
|
Iphone |
美洲 |
美国 |
3 |
4 |
0 |
2 |
9 |
|
加拿大 |
0 |
5 |
4 |
3 |
12 |
||
|
Total |
3 |
9 |
4 |
5 |
21 |
¨ Sales C，服务于多个产品多个营业点
|
产品 |
区域 |
营业点 |
Jan-11 |
Feb-11 |
Mar-11 |
Apr-11 |
Total |
|
Iphone |
美洲 |
美国 |
0 |
1 |
2 |
1 |
4 |
|
加拿大 |
0 |
0 |
6 |
3 |
9 |
||
|
Subtotal |
0 |
1 |
8 |
4 |
13 |
||
|
Ipad |
美洲 |
美国 |
0 |
0 |
0 |
0 |
0 |
|
加拿大 |
0 |
0.75 |
2.5 |
4 |
7.25 |
||
|
Subtotal |
0 |
0.75 |
2.5 |
4 |
7.25 |
||
|
Total |
0 |
1.75 |
10.5 |
8 |
20.25 |
||
五、报表测试系列之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． 导出和打印格式
一般报表的使用者，会更多地应用导出功能导出成别的格式，或者是直接打印出来查看。此时，我们就需要检查报表导出后格式有没有变形。打印时，报表会不会因为分页打印而造成报表内容缺失，或者不易被查看。