【IT168 技术文章】
实际ATM监控系统的报表测试，可以以本文介绍的六点为纲展开，但是又不可拘泥于这六点，而应根据实际项目的情况，调整相应的测试策略和测试方法，以便对系统进行更有效的测试。
ATM监控系统集SNA通信技术、TCP/IP通信技术、数据库技术、数据库远程同步技术、语音卡技术、报表技术等多种技术于一体，实现了基于银行分布式网络环境下的ATM集中管理。银行需要通过ATM监控系统将总行数据分发到各地市行的数据库，各地市行通过报表及时掌握本地区ATM机的整体状态信息、局部状态信息和交易信息。同时，银行高级管理人员通过系统灵活的报表来进行科学的决策分析。所以，从用户的使用频度来说，除了交易监控之外，接下来就是报表的使用了。由此可见，报表是很重要的一项功能。相对应的，报表内容的测试在整个ATM监控系统中也就显得很重要了。
虽然所有报表测试的总体目标都是相同的，即要求生成的报表的统计结果是正确的。但是因为银行业务的独特性，所以ATM监控系统的报表测试与一般信息管理系统的报表测试，在以下三方面有所不同。
● 信息类型不同
ATM监控系统要处理的信息有两类：一类是管理信息，主要用于将ATM的状态告知前置服务器，如OEX信息、RWT、RDT、RTT等交易；另一类是客户交易信息。而一般信息管理系统要处理的信息则主要是交易信息。
● 报表统计的原始数据不同
对于ATM监控系统，每天日切时，系统将根据历史（包括当日）的交易以及状态信息进行分析统计，产生新的分析统计记录。ATM监控系统的报表统计功能使用的原始数据就是这些每日产生的新的分析统计记录（笔者在这里称为：报表中间数据）。而一般信息管理系统的原始数据，则是通过系统执行交易或操作产生的报表统计的原始数据。
● 测试方法不同
因为报表统计的原始数据不同，所以两类系统的报表在测试方法上也有一定的区别。对于一般的信息管理系统，可以通过在相应功能界面进行数据的增、删、改操作，然后在报表界面执行生成报表操作，就可以验证报表数据的正确性。但是ATM监控系统无法简单通过前台界面的操作来验证报表数据的正确性。
本文是笔者在某省行ATM监控系统中，对超过三十个报表进行测试的经验总结。在本项目的报表测试过程中，笔者主要通过以下六个方面进行测试：功能测试、界面测试、数据正确性测试、单设备和多设备测试、权限和访问安全性测试、报表性能情况验证。
功能测试
功能测试主要是对报表的基本功能进行测试，如正常生成报表功能、二次查询、报表导出等正常功能外，还对报表统计日期合法性控制、没有数据情况下进行生成报表等异常控制的测试。报表功能测试的主要目标是：验证报表基本功能的正确性，为后续的数据正确性测试奠定基础。
报表的功能测试是整个报表测试的基础内容。同时，通过这部分测试，测试人员可以逐步了解报表模块的需求，提高业务的熟悉程度。因为这部分内容的测试方法和其他功能的测试没有太大区别，所以这里不再详细介绍。
界面测试
报表的界面测试，也可以算是功能测试的一部分，但是由于更侧重于界面内容的正确显示验证，所以笔者将它剥离出来作为单独的一项测试内容。
界面测试的主要目的是验证界面显示的内容是否正确，是否符合软件开发规范。避免出现如表格布局不合规范、打印的硬拷贝少了表格线、界面有多余字符之类的情况。在报表测试中，界面测试的主要内容包括：报表表头信息、报表整体界面、报表导出文件的界面显示、打印预览时的界面显示、打印出的硬拷贝内容的界面显示等。
数据正确性测试
报表功能的基本要求，就是通过统计分析操作，提供给用户所需的准确数据。如果无法实现这个基本要求，则报表会完全失去意义。所以，报表测试很重要的一个内容就是对报表数据进行正确性的测试，而这部分工作也最复杂。在本文提到的某省行ATM监控系统的报表测试中，笔者主要从以下五个方面进行报表数据正确性的测试。
1．多个报表相互对照
在交易类报表中，有一些报表取的原始数据是相同的，我们可以在假设这些报表取的数据库表的数据是正确的前提下，通过对比这些报表相同列的数据，进行报表结果是否取正确数据的验证。如：交易情况明细表、金融交易统计表、它行卡、发卡机构交易分析、盈利情况表，虽然这几张报表表单不一样，但是本行卡、它行卡的交易笔数、金额却应该是相同的。在测试时，我们通过对比这几张报表同一字段的数据，发现“金融交易统计报表”中，“改密”和“缴费”这两列取了错误的数据。
这种方法是在有假设的前提下进行的，所以具有一定的局限性。假如所有报表的同一列都取错了数据的话，那么这个方法就失效了。尽管如此，这个方法还是可以帮助我们在测试初期快速发现一些简单的数据错误缺陷。
2．修改数据库数据
部分报表的数据，由于数据的验证比较烦琐，可以通过修改数据库表对应字段数据的方式，来验证报表数据是否如预期设置生成报表。
在测试“厂商服务质量报告”时，为了验证报表是否只统计“接警操作员”和“修复操作员”为同一个人对应的故障数据，我们可以在数据库中修改某一故障记录对应的“修复操作员”的数据，将它修改为和“接警操作员”不一致的数据，然后进入系统，生成对应统计条件的报表数据，验证系统是否有将这条“修复操作员”和“接警操作员”不相同的故障记录也统计出来，通过这种方式来验证数据的正确性。
3．特征数据的准备
对于有特殊计算要求的报表，我们要准备相应的特征数据。在本系统中，每台设备在省行、分行等各级机构，分别设置了直接维护人员、监护人员、督办人员三个管理员。当ATM产生故障时，这些管理员要对这些故障进行响应和处理。为了统计管理员们及时响应故障、及时处理故障的情况，系统设计了响应及时率、处理及时率之类的及时率计算数据。对于这类报表数据正确性的验证，笔者使用边界值和等价类划分的测试用例设计方法，设计了及时率测试用例。具体举例如下。
处理及时率的计算方法是：将“故障修复时间”与“故障报警时间”的差值与配置文件中的“故障处理超时时间”进行对比。当差值小于或等于配置文件的设置，则说明处理及时；反之为处理超时。在实际测试时，笔者修改配置文件中的“故障处理超时时间”为10秒，然后修改某故障记录的“故障修复时间”与“故障报警时间”的差值分别等于9秒、10秒、11秒，然后执行报表生成操作，验证系统是否正确统计及时和超时的数据。
通过这个例子说明，在进行类似需要进行类比操作后才能得到的统计数据，可以考虑将测试用例设计方法融入测试设计中，设计特征数据来进行测试，避免测试的盲目性。
4．报表数据的正确性验证
ATM监控系统的报表统计的“原始数据”是通过后台程序在指定时间，对日常交易数据、管理数据进行统计、分析后生成的，所以在进行ATM监控系统的报表测试时，还需要对生成的报表中间数据的正确性进行测试。这部分测试的重点是，验证后台程序是否将符合条件的交易数据、管理数据生成报表中间数据，即验证报表中间数据的正确性。
例如，在进行生成故障报表数据的测试时，为了验证系统没有将“维护结果”为“尚未处理”的报警记录生成报表中间数据，但是“维护结果”为“成功”和“失败”的报警记录可以生成报表中间数据的功能。笔者特意设计了三笔不同“维护结果”（成功、失败、尚未处理）的报警记录，执行生成报表中间数据的脚本，然后到“故障统计分析”报表中，验证生成的报表数据是否正确（如果报表中间数据生成有误，这里得到的报表是错误的）。采用这种方式间接验证程序是否如预期的要求生成了正确的报表中间数据。
5．留意四舍五入对报表数据的影响
在生成的统计报表中，报表数据不可避免的会发生四舍五入的情况。对于普通比例列的计算，只需验证是否正确四舍五入即可。这里提到要留意四舍五入对报表数据的影响，主要是指四舍五入对于合计列的影响。如：对于合计列，要注意百分比的合计结果应为100%，合计列的数值要等于所有统计列之和。
单设备与多设备测试
为了验证程序在选择单设备和多设备时处理是否都正确，笔者特意对报表模块，在选择单设备和多设备的两种情况下分别进行测试。这部分测试，可以说是功能测试中的一项边界测试。由于测试目的明确，所以笔者将它单独出来说明。通过这部分测试，笔者发现了部分报表在单设备情况下，处理有误的缺陷。
权限和访问安全性测试
在报表测试中，除了功能测试、数据正确性测试外，我们不要遗漏权限控制和访问安全性的测试。为了验证报表在权限控制和访问安全性的控制，笔者使用不同机构的用户对报表模块的所有报表进行测试，验证权限控制，以及报表正确筛选数据的功能。指定机构级别的用户只能看到指定机构级别的数据和设备。例如：使用三级机构的用户登录系统，进入某个报表界面，即使是直接选中“省行”执行生成报表操作，也只能列出该机构所属设备对应的信息。
报表性能情况验证
虽然报表公认响应速度是很慢的。但是从用户接受度来说，也不可能出奇得慢，尤其是对于用户常用的报表。为了检查在大数据量情况下，报表的响应情况，笔者以省行用户登录系统，在一个月实际运行数据的情况下，对省行下的所有设备（1000多台）进行交易情况的统计。通过测试结果反映，对于交易情况统计这类常用报表，在数据量大的时候，响应速度过慢。通过这次测试结果给项目组敲了个警钟，项目经理组织人员对报表实现方式等进行了一系列的优化。如原来默认对所选机构，包括所属机构的全部设备进行统计，改为默认只对所选机构本级别下的设备进行统计。通过一系列的调整，优化了报表的性能。
如果要对报表进行更深入的性能测试，那么需要编写测试脚本或借助自动化测试工具进行测试。因为本项目的需求中，没有报表方面的性能需求，所以笔者没有对报表进行深入的性能测试。
