所以如果希望高有效、更高质量的完成报表的测试,那么就要重视并增加对于数据准备工作的关注:用于验证报表功能的数据,一定是专门为报表准备的,并且是经过精心设计,要分析影响数据项算法的各种因素,以及每个因素可能出现的不同变化,这样才有可能覆盖各种查询统计方法;同时,才能保证无论使用哪个数据项的算法进行计算,其结果都是可以预知的——因为数据来源已经被我们控制了。
特别是对于算法比较复杂,又提供了多种查询统计方式的报表,如果想完整的测试,就需要准备大量的数据。而如果想高效、高质量的完成这项功能,就一定要理解数据准备工作的重要性。
经过精心设计的数据还有一个好处,就是当在进行业务功能的测试时,不再需要使用一些随意的数据,而是可以通过业务测试的过程,把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要,进行相应的操作。
如果留心,你也会发现报表测试同其他业务功能测试的有个区别。业务功能(例如单据的新增、审核等)的测试用例设计,通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖;而对于报表功能,虽然没有太复杂的业务流程和规则,但是算法更加复杂,同时报表功能本身就是一种对数据的加工处理,因此会更偏重于对于各种数据来源和算法的遍历或覆盖,也就是要准备各种正常的、异常的数据,来验证报表是否取到的该取的数据、没有取不该取的数据,并且最后计算出了正确的结果。
<!--[if !supportLists]-->(4) 特征性数据的准备<!--[endif]-->
这又是一个同数据准备有关的问题,也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试,虽然大家各自使用的数据都是经过精心设计的,但是在实际进行报表测试时,还是很难保证其他人的数据不会对自己的测试结果产生影响,最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的,是可控的,但是现在掺杂了别人的数据,就需要花时间去区分这种“假”的错误和真的错误。
有一个经验是可以借鉴的,就是在初期,团队内对数据的准备达成一直,使数据中的某一项具有特征性,例如分别使用不同的供应商,或者使用不同的商品。最后测试报表时,通过限定选取的数据来源,来保证相互之间尽可能的没有影响。
<!--[if !supportLists]-->(5) 做好数据环境的备份和维护<!--[endif]-->
虽然数据是经过精心准备的,但是难免在操作过程中因为误操作导致环境的变化,例如不小心把一张单据变成了另外一种状态,或者某个类型的单据多做了一张。对于这种情况,一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表来保存我们事先准备的数据,可以一个文件保存一个类型的单据,例如采购单、入库单、出库单等等,文件中的每张表用来保存不同状态的单据,例如已经审核过的入库单,没有审核过的入库单,全部入库的入库单和部分入库的入库单,等等。假如你一不小心,把一张本来准备入一半的入库单全入了,那也不要惊慌,去重新调整一下你的数据文档,在相应的类型相应的状态的单据列表中新增一张就行了。
而如果想减少回归测试的工作量,那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础单据已经输入完成,但是还都没有开始审核或者出入库,那么可以备份一下,下次再测的时候可以直接在数据库中恢复这部分原始数据。
<!--[if !supportLists]-->(6) 在业务功能测试通过之后才开始<!--[endif]-->
这一点相信应该不难理解,如果业务功能本身存在缺陷,导致的数据不准,那么最后进行报表测试也就没有什么意义了。所以,应该在保证各项同报表有关的业务的功能测试通过之后,才开始考虑对报表进行测试。
<!--[if !supportLists]-->(7) 寻求开发人员的协助<!--[endif]-->
在报表测试中很常见的一个问题,是需求文档中可能没有定义报表的各个数据项的算法,这时候你需要找开发人员帮忙,向他们了解准确的算法和相应的公式。
<!--[if !supportLists]-->(8) 多个报表相互对照<!--[endif]-->
这是一项“高级”的报表测试技能,需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外,还能够进行横向的联系,知道不同报表之间存在的关系。例如,一个简单的例子,库存报表中,你可以看到商品的出入库情况,而在销售报表中,你可以看到商品的销售金额和销售成本金额,在应收应付报表中,你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间,是否存在一些关联呢?是否会存在一些可以相互验证的地方呢?这个问题,留给大家来思考 ^_^
原文转自:http://www.uml.org.cn/Test/200603073.htm