2．修改数据库数据
部分报表的数据，由于数据的验证比较烦琐，可以通过修改数据库表对应字段数据的方式，来验证报表数据是否如预期设置生成报表。
在测试“厂商服务质量报告”时，为了验证报表是否只统计“接警操作员”和“修复操作员”为同一个人对应的故障数据，我们可以在数据库中修改某一故障记录对应的“修复操作员”的数据，将它修改为和“接警操作员”不一致的数据，然后进入系统，生成对应统计条件的报表数据，验证系统是否有将这条“修复操作员”和“接警操作员”不相同的故障记录也统计出来，通过这种方式来验证数据的正确性。
3．特征数据的准备
对于有特殊计算要求的报表，我们要准备相应的特征数据。在本系统中，每台设备在省行、分行等各级机构，分别设置了直接维护人员、监护人员、督办人员三个管理员。当ATM产生故障时，这些管理员要对这些故障进行响应和处理。为了统计管理员们及时响应故障、及时处理故障的情况，系统设计了响应及时率、处理及时率之类的及时率计算数据。对于这类报表数据正确性的验证，笔者使用边界值和等价类划分的测试用例设计方法，设计了及时率测试用例。具体举例如下。
处理及时率的计算方法是：将“故障修复时间”与“故障报警时间”的差值与配置文件中的“故障处理超时时间”进行对比。当差值小于或等于配置文件的设置，则说明处理及时；反之为处理超时。在实际测试时，笔者修改配置文件中的“故障处理超时时间”为10秒，然后修改某故障记录的“故障修复时间”与“故障报警时间”的差值分别等于9秒、10秒、11秒，然后执行报表生成操作，验证系统是否正确统计及时和超时的数据。
通过这个例子说明，在进行类似需要进行类比操作后才能得到的统计数据，可以考虑将测试用例设计方法融入测试设计中，设计特征数据来进行测试，避免测试的盲目性。
4．报表数据的正确性验证
ATM监控系统的报表统计的“原始数据”是通过后台程序在指定时间，对日常交易数据、管理数据进行统计、分析后生成的，所以在进行ATM监控系统的报表测试时，还需要对生成的报表中间数据的正确性进行测试。这部分测试的重点是，验证后台程序是否将符合条件的交易数据、管理数据生成报表中间数据，即验证报表中间数据的正确性。
例如，在进行生成故障报表数据的测试时，为了验证系统没有将“维护结果”为“尚未处理”的报警记录生成报表中间数据，但是“维护结果”为“成功”和“失败”的报警记录可以生成报表中间数据的功能。笔者特意设计了三笔不同“维护结果”（成功、失败、尚未处理）的报警记录，执行生成报表中间数据的脚本，然后到“故障统计分析”报表中，验证生成的报表数据是否正确（如果报表中间数据生成有误，这里得到的报表是错误的）。采用这种方式间接验证程序是否如预期的要求生成了正确的报表中间数据。
5．留意四舍五入对报表数据的影响
在生成的统计报表中，报表数据不可避免的会发生四舍五入的情况。对于普通比例列的计算，只需验证是否正确四舍五入即可。这里提到要留意四舍五入对报表数据的影响，主要是指四舍五入对于合计列的影响。如：对于合计列，要注意百分比的合计结果应为100%，合计列的数值要等于所有统计列之和。
单设备与多设备测试
为了验证程序在选择单设备和多设备时处理是否都正确，笔者特意对报表模块，在选择单设备和多设备的两种情况下分别进行测试。这部分测试，可以说是功能测试中的一项边界测试。由于测试目的明确，所以笔者将它单独出来说明。通过这部分测试，笔者发现了部分报表在单设备情况下，处理有误的缺陷。
权限和访问安全性测试
在报表测试中，除了功能测试、数据正确性测试外，我们不要遗漏权限控制和访问安全性的测试。为了验证报表在权限控制和访问安全性的控制，笔者使用不同机构的用户对报表模块的所有报表进行测试，验证权限控制，以及报表正确筛选数据的功能。指定机构级别的用户只能看到指定机构级别的数据和设备。例如：使用三级机构的用户登录系统，进入某个报表界面，即使是直接选中“省行”执行生成报表操作，也只能列出该机构所属设备对应的信息。
报表性能情况验证
虽然报表公认响应速度是很慢的。但是从用户接受度来说，也不可能出奇得慢，尤其是对于用户常用的报表。为了检查在大数据量情况下，报表的响应情况，笔者以省行用户登录系统，在一个月实际运行数据的情况下，对省行下的所有设备（1000多台）进行交易情况的统计。通过测试结果反映，对于交易情况统计这类常用报表，在数据量大的时候，响应速度过慢。通过这次测试结果给项目组敲了个警钟，项目经理组织人员对报表实现方式等进行了一系列的优化。如原来默认对所选机构，包括所属机构的全部设备进行统计，改为默认只对所选机构本级别下的设备进行统计。通过一系列的调整，优化了报表的性能。
如果要对报表进行更深入的性能测试，那么需要编写测试脚本或借助自动化测试工具进行测试。因为本项目的需求中，没有报表方面的性能需求，所以笔者没有对报表进行深入的性能测试。
