User Defined Variables

在这个控件中，定义你所需要的参数，如

在对应的需要使用参数的位置，使用${host}替代。

应用场景：

当测试环境变化时，我们只需要修改一处的IP就可以让脚本马上应用于另外一个环境的测试，而不需要逐个脚本进行修改。

之前的文章讲述的都是如何测试报表的正确性。其实，除了报表的正确性，我们还需要关注报表的UI测试。所谓UI测试，并不单指根据UI标准对报表进行检查，还需要我们站在用户的角度去考量报表的易用性。

除了保证计算的正确性，我们还需要让报表变得更专业。变得专业，指报表应符合行业的标准，且考虑用户的使用，报表应变得更易懂，重点更突出。UI设计是变专业的关键。试想一下，如果一份报表字体不统一，大小不一致，颜色使用混乱，即使报表的计算值再具有参考价值，也无法让用户满意。因此，在设计和测试中，我们应该多重视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．  导出和打印格式

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

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

对于测试数据的设计，我将其粗略地分为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． 测试数据的备份

正如Jackie在《进销存系统中的报表测试》中所言，在报表中，我们很难直观地通过某个数据项，看到它的算法和数据源。在报表测试用例设计中，第一步就是分析报表的数据源和算法。

不同业务报表之间的区别是很大的，特别是在不同行业之间。在分析报表前，首先，我们要提高对业务的熟悉程度。对于某些系统，如计费系统等统计精度较高的系统，我们甚至需要达到精通的程度。那么，是不是报表的分析就全无规律可循呢？不是的。下面将介绍我在分析报表时惯常使用的几个切入点，希望对大家有一定的启发。

1． 源数据的来源

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

A． 由业务系统生成

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

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

B． 来源于第三方数据库

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

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

2． 报表的算法

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

A． 罗列式

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

·         罗列项的完整性，即FS中所规定的源数据的属性项是否列举完整；

·         列举数据的正确性和完整性；

·         数据属性变动对报表的影响，如，修改客户地址后，报表是否能正确地显示客户的最新地址；

B． 统计式。

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

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

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

C． 算法式

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

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

·          统计值所关联的源数据；

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

    在报表分析过程中，大家除了可以参考我上面的几个切入点外，还可以使用小组brainstorm的方式，来列出尽可能多的测试要点。然后再将要点梳理，这样，报表测试用例的基本框架也就形成了。框架形成后，接下来我们就需要基于框架对测试用例进行细化和补充。

序言

报表功能的基本要求，是通过查询/统计/分析，来提供用户所需的准确数据。因此，在报表测试中，统计准确性测试是报表测试的关键。如果报表所呈现的数据是错误的，即使它制作得再精美，也失去了本来的意义。如何对报表的准确性进行测试，是本系列文章的主旨。

在此特别感谢，Jackie陈雷不断督促我做总结分析，并且给予我很多启发；Echo嘉宇帮我润色语句，增加可读性。

正文

1． 报表系列之报表分析

2． 报表系列之测试数据设计

3． 报表系列之基于OLAP的报表测试

4． 报表系列之权限控制

5． 报表系列之UI设计

6． 报表系列之性能测试