这种方法是在有假设的前提下进行的,所以具有一定的局限性。假如所有报表的同一列都取错了数据的话,那么这个方法就失效了。尽管如此,这个方法还是可以帮助我们在测试初期快速发现一些简单的数据错误缺陷。
2.修改数据库数据
部分报表的数据,由于数据的验证比较烦琐,可以通过修改数据库表对应字段数据的方式,来验证报表数据是否如预期设置生成报表。
在测试“厂商服务质量报告”时,为了验证报表是否只统计“接警操作员”和“修复操作员”为同一个人对应的故障数据,我们可以在数据库中修改某一故障记录对应的“修复操作员”的数据,将它修改为和“接警操作员”不一致的数据,然后进入系统,生成对应统计条件的报表数据,验证系统是否有将这条“修复操作员”和“接警操作员”不相同的故障记录也统计出来,通过这种方式来验证数据的正确性。
3.特征数据的准备
对于有特殊计算要求的报表,我们要准备相应的特征数据。在本系统中,每台设备在省行、分行等各级机构,分别设置了直接维护人员、监护人员、督办人员三个管理员。当ATM产生故障时,这些管理员要对这些故障进行响应和处理。为了统计管理员们及时响应故障、及时处理故障的情况,系统设计了响应及时率、处理及时率之类的及时率计算数据。对于这类报表数据正确性的验证,笔者使用边界值和等价类划分的测试用例设计方法,设计了及时率测试用例。具体举例如下。
处理及时率的计算方法是:将“故障修复时间”与“故障报警时间”的差值与配置文件中的“故障处理超时时间”进行对比。当差值小于或等于配置文件的设置,则说明处理及时;反之为处理超时。在实际测试时,笔者修改配置文件中的“故障处理超时时间”为10秒,然后修改某故障记录的 “故障修复时间”与“故障报警时间”的差值分别等于9秒、10秒、11秒,然后执行报表生成操作,验证系统是否正确统计及时和超时的数据。
通过这个例子说明,在进行类似需要进行类比操作后才能得到的统计数据,可以考虑将测试用例设计方法融入测试设计中,设计特征数据来进行测试,避免测试的盲目性。
4.报表数据的正确性验证
ATM监控系统的报表统计的“原始数据”是通过后台程序在指定时间,对日常交易数据、管理数据进行统计、分析后生成的,所以在进行ATM监控系统的报表测试时,还需要对生成的报表中间数据的正确性进行测试。这部分测试的重点是,验证后台程序是否将符合条件的交易数据、管理数据生成报表中间数据,即验证报表中间数据的正确性。
例如,在进行生成故障报表数据的测试时,为了验证系统没有将“维护结果”为“尚未处理”的报警记录生成报表中间数据,但是 “维护结果”为“成功”和“失败”的报警记录可以生成报表中间数据的功能。笔者特意设计了三笔不同“维护结果”(成功、失败、尚未处理)的报警记录,执行生成报表中间数据的脚本,然后到“故障统计分析”报表中,验证生成的报表数据是否正确(如果报表中间数据生成有误,这里得到的报表是错误的)。采用这种方式间接验证程序是否如预期的要求生成了正确的报表中间数据。
5.留意四舍五入对报表数据的影响
在生成的统计报表中,报表数据不可避免的会发生四舍五入的情况。对于普通比例列的计算,只需验证是否正确四舍五入即可。这里提到要留意四舍五入对报表数据的影响,主要是指四舍五入对于合计列的影响。如:对于合计列,要注意百分比的合计结果应为100%,合计列的数值要等于所有统计列之和。
单设备与多设备测试
为了验证程序在选择单设备和多设备时处理是否都正确,笔者特意对报表模块,在选择单设备和多设备的两种情况下分别进行测试。这部分测试,可以说是功能测试中的一项边界测试。由于测试目的明确,所以笔者将它单独出来说明。通过这部分测试,笔者发现了部分报表在单设备情况下,处理有误的缺陷。
权限和访问安全性测试
在报表测试中,除了功能测试、数据正确性测试外,我们不要遗漏权限控制和访问安全性的测试。为了验证报表在权限控制和访问安全性的控制,笔者使用不同机构的用户对报表模块的所有报表进行测试,验证权限控制,以及报表正确筛选数据的功能。指定机构级别的用户只能看到指定机构级别的数据和设备。例如:使用三级机构的用户登录系统,进入某个报表界面,即使是直接选中“省行”执行生成报表操作,也只能列出该机构所属设备对应的信息。
原文转自:http://www.uml.org.cn/Test/200801312.asp