关键字: 进销存 报表 软件测试
本文适合有过MIS系统报表测试经验,或者有关进销存系统测试经验的朋友参考。
报表功能的基本要求,就是通过查询/统计/分析,提供用户所需的准确的数据。如果无法实现这个基本功能,则报表完全失去意义。
对于用户来说,报表可以直接影响到他们的决策,例如可能因为报表对销售和库存情况反映的不准确,导致错误的大量进货;或者因为报表对应收应付金额计算的不准确,而导致企业对资金占用情况做出错误的估计,
从而导致错误的决策,最终造成用户在经营上的损失。诸如此类,相信只要大家留心,还可以找出很多这样的例子。
进销存系统中的报表多如牛毛,而且各种不同行业的进销存系统中的业务有区别,报表也有些区别,因此不太可能对各种报表逐个讲解,而主要是把一些报表测试的经验总结成了十几条可以在各种行业的报表测试中应用的“最佳实践”,来跟大家一起分享。希望下面的这十几条像一招招简单实用的“擒拿手”,可以供正在进行报表测试或者准备开始作报表测试的朋友随手拈来,见招拆招,轻松应对这项工作。
<!--[if !supportLists]-->(1) 提高对业务的熟悉程度<!--[endif]-->
其实对任何一个软件进行测试,都必须要熟悉它的业务,包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改,通过对界面的浏览和探索性的操作,大概都可以弄明白它的业务流程和业务规则,因为这些内容比较直观,而且在不同的行业中也差不了太多。但是在报表中,是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项,它的算法或者说数据来源,恐怕是比较难看出来的——即使是很类似的一个数据项,在不同行业的实际业务中,它的算法和数据来源也可以能完全不同的。
所以对于报表业务的熟悉,主要是两个方面:数据项的算法和数据来源,也就是说要明白一个数据项同具体的业务有什么关系,单据的增、删、改或者状态的变化,对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些,那么就无法验证报表中的数据是否准确,也无法通过报表去检查业务系统的正确与否。
<!--[if !supportLists]-->(2) 覆盖所有可能的查询统计方式,而不是以自己的使用习惯为准<!--[endif]-->
对于报表的使用者来说——一般是企业的中层或高层领导,他们对于报表的要求可能会是多方面的,例如在进销存系统中,可能需要按不同商品进行分类统计,也可能是按供应商分类统计,这些都是由用户在实际工作中的需要来决定的,所以假如一个报表提供了多种查询统计的方法,那么在测试时,只要时间充分,就应该覆盖这些所有可能被用到的查询统计方法,而不是以自己的使用习惯为测试的依据。
<!--[if !supportLists]-->(3) 使用或构造受控的数据环境<!--[endif]-->
数据对于报表测试来说是一个非常非常重要的问题。因为上面说到,报表的基本功能就是通过各种查询统计分析的方法,为用户提供准确的数据,帮助用户做出决策。那么那些用来进行测试的数据从哪里来呢?
首先,应该保证准备足够多的有效的数据。前面一条也提到了,在实际测试报表时,应当尽可能的覆盖到报表所提供的各种查询统计方法,因此至少应该保证每一种查询统计方法都应该有对应的数据,得到的结果都不会是0,否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好,能保证全部覆盖,并且刚好够用就可以了,因为数据的准备和生成也是很花时间的。
其次,要保证数据的可控。数据并不是随意生成的,如果使用通过自动化工具或者通过业务测试时随意的输入的数据来进行报表测试,一般来说是不太可能的。因为如果无法控制数据来源,那么即使知道报表中每个数据项的算法,也无法最终验证报表的查询统计结果是否正确。例如,系统的会有不同类型的单据,每种单据又会有不同的状态,某个报表的统计中,可能会涉及到多种类型和状态的单据,那么在准备数据时,就要充分考虑到这一点,准备各种不同的单据来满足测试的要求。又比如,如果整个系统中只有一个供应商,一个商品,那么测试按供应商分类统计或者按商品分类统计的报表时,意义也就不大了。
原文转自:http://www.uml.org.cn/Test/200603073.htm