51Testing软件测试论坛

标题: [转]:进销存系统中的报表测试(二) [打印本页]

作者: 平平淡淡才是真    时间: 2007-5-31 16:48
标题: [转]:进销存系统中的报表测试(二)
(11) 留意进/存/销时使用不同单位对报表数据的影响

例如采购时是5箱,每箱有100盒,而销售单位是盒,入库之后,可能会要求按照销售单位来统计,这时要注意开发人员是否会选择了错误的单位,把500盒弄成5盒。

(12) 留意业务单据中存在多个日期字段时对报表数据的影响

一般来说,一张单据上都会有多个日期字段,比如采购单就有采购日期、单据日期、审核日期,而入库单也会有单据日期、入库日期,诸如此类。那么在测试时,一定要留意,开发人员是否按照要求选择了正确的日期,包括日期选取的一致性——是否存在这边取采购日期,那边取审核日期的情况。

13) 留意是否存在遗漏的单据类型

例如像出入库的报表,入库方向的,除了最主要的采购入库外,可能还会包括退货入库、盘盈入库、报溢入库;出库方向的,除了最常见的销售出库,还会包括盘亏出库、报损出库。那么在具体测试时,一定要准备充分这些相应类型的单据,并且要留意开发人员是否遗漏了相应的单据类型。

14) 留意不同状态的单据对报表数据的影响

例如采购单,当采购单发出后,供应商会开始送货,可能第一批之送来了一半的商品,那么这时采购单的收货状态是“未完成” ;当供应商把商品送齐了以后,采购数量=收货数量,则采购单的收货状态变为“已完成”。那这时留意,开发人员在采购报表中,是包含所需要的状态的单据,还是只包含了一部分?

15) 留意那些被当做默认规则的因素

有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面,这些规则不会体现在界面,也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以,一定要同开发人员反复确认,保证自己已经了解了同报表各数据项计算有关的各个因素。

16) 保证测试人员可以通过UI 找到自己所需的所有原始数据

在进行系统测试时,无论是报表,还是一般的业务功能测试,都不要去直接通过SQL语句查询数据库中的内容,而是通过UI来输入,再通过UI体现处理的结果进行验证——因为这是系统测试,不是集成测试,将来用户是决不会去直接查数据库的。因此,如果需要对报表的结果进行验证,应该通过其他的功能模块,去查询业务单据,或者其他报表,根据UI体现的结果,来进行确认。

17) 检查大数据量对报表的影响

报表测试也会涉及到性能测试,主要是在大数据量查询统计的测试。大数据量一是说原始数据多,二是被操作、计算的数据多,三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表,10万条数据和100万条数据时的响应时间将表现出巨大的差别。

18) 不要遗漏权限控制和访问安全性的测试

这里说的权限控制不是谁可以访问某个模块,谁不可以访问某个模块,而且数据的计算也没有直接的关系,而是侧重于报表设计的测试。我们都知道不同的报表是设计给不同的人看的,例如出入库报表是给仓库管理人员看的,里面不会包含商品的价格,而只会包含数量;而财务报表中,只会包含采购、销售的金额,而不会包含数量,这样才能保证可以相互对照,不会出现营私舞弊的行为。那么在测试时,应当考虑报表是否泄漏了不该泄漏的信息。当然,这里对业务的熟悉程度就是更高的要求了。

又如,不同的业务员只能看到同自己有关的业务,但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域,他们之间的销售情况是互相保密的。

还有一种情况,系统的用户可能会为他的供应商提供一个专门的程序或者Web页面,供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况,一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况,如果某个商品由多个供应商同时提供,那么其中一个供应商应该只能看到他提供的那部分,而看不到其他供应商提供的同一商品的情况。当然,这种功能一般都是通过外网(internet)来访问的,所以也还要考虑相应的访问安全性测试,以免泄
作者: lele218    时间: 2007-9-6 10:49
up up up




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2