如何在银行系统中做批量测试~
Posted 程序员威子
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何在银行系统中做批量测试~相关的知识，希望对你有一定的参考价值。
导读
当前，在计算机主机的应用处理模式中，批量处理作为一种事后数据处理方式，一直是一种简单而又非常重要的处理方式，尤其是对于海量数据处理，批量方式就更能显示其高效的处理效果。随着批量交易变得越来越复杂，以及对批量处理时效性的要求，迫切需要有一种有效的、快速的批量作业测试方式，以实现对批量处理的自动化测试。
批量处理
批量处理是指将数据以按批处理的模式完成大量的数据访问、计算、分类、分析、汇总的过程，最终输出大量的营业分析报表，表现出数据访问量大，计算量大，流程复杂等特性。
一般而言，批量处理通过建立作业计划模板，以人工干预或系统自动调起程序的方式执行，模板中包含若干根据业务逻辑处理先后顺序进行排列的节点，节点可以调起对应的批量交易程序，对数据进行加工处理并输出结果。
目前银行大量数据处理都是以批量形式执行，涵盖了会计核算，对公业务，个人业务,信用卡业务,客户信息业务,数据处理业务等多个业务条线，涉及到账务处理，报表统计，数据处理消费等多个核心功能，如何有效地检查、验证和确保批量业务的正确性，成为银行测试部门的关键任务。
批量交易测试的共性关注点
尽管银行批量业务种类繁多，但其在测试过程中关注点基本有以下几个方面：
1、关注批量作业链配置，比如：配置模板正确性，调度计划是否符合预期，代理能否正常调起程序，负载均衡策略是否生效等。
2、批量程序逻辑加工正确性，包含加工逻辑是否正确，数据是否有遗漏，是否有重复，入库表结构，字段名，特殊字符，超长字符能否正常入库等。
3、程序本身语法及格式正确性，如是否包含明文密码，是否包含异常处理，日志定级是否正确，关键步骤是否有日志记录，程序语法是否规范，遇到特殊参数能否正确处理等。
4、性能效率是否符合要求，批量交易常常环环相扣，上游加工结果往往是下游加工的输入，因此要求批量脚本须在一定的时间内完成。
手工批量测试方式
基于以上测试点，手工进行测试的一般步骤为：根据需求设计测试用例，进行测试数据准备插入正反向测试数据，执行批量程序，查询数据库，根据预期结果编写检查语句核对生成数据。
但手工测试常常存在以下局限：
测试效率低。实际测试过程中需要申请各类权限而后连接加载机，连接数据库。以手工方式逐条重复操作，测试效率低，无法有效支持有刚性时间要求的回归测试
测试资产无法有效积累。测试过程中使用的SQL语句，编写的测试程序等无法结构化管理复用
批量测试对测试人员要求高。针对逻辑复杂，数据来源多，数据量大的批量程序，编写核对SQL语句或程序难度大
难以进行质量监控。批量项目协办众多，上下游逻辑耦合紧密，手工测试导致测试分布零散，无法进行有效监控
批量测试平台初探
针对以上问题我们团队开发了批量测试平台，实现了从数据准备->批量执行->结果校验的全流程自动化测试。
平台核心功能有：
1.通过批量平台串联整个测试流程，进行自动化测试，为回归测试提供支持。
2.将录入的测试资产管理起来，方便后续复用借鉴
3.通过预设的一系列检查规则：表结构检查、数据量检查、数据空值检查、数据合法性检查、数据正确性检查，降低了测试人员进行数据检查的门槛，同时支持数据库间，文件与数据库，文件间的大数据量对比。
4.将多期测试数据保存，可从项目、系统等多维度进行质量分析。
平台测试的基本流程：
基本流程
平台主要分为三大模块，配置管理、执行管理、统计分析，配置管理主要为录入基本信息，后续平台将利用这些信息连接数据库和加载机，接着录入系统信息和项目信息，这步是方便分别从系统及项目维度对测试资产进行分类。
配置数据库
执行管理是配置测试策略的核心，如何准备测试数据，执行批量程序的具体命令，配置执行结果的检查方法，这里我们预设了一些常见的检查规则，支持基本的结果检查，比如数据量进行对比，数据字段类型是否符合预期，某一字段是否在预期的范围内，两个表或表与文件的数据是否一致等。 通过这些预先定义良好的对比规则，降低了编写检查SQL语句的门槛，避免了繁复的人工检查过程。
配置测试文件
批次管理是对任务进行编排，在这里我们以任务作为执行的最小单元，一个批次下可以包含多个任务，因为在实际测试过程中，一个项目可能包含多个批量测试任务，这些测试任务的执行环境及系统各不相同但是都隶属于同一个项目，所以这里使用批次的概念编排多个任务。
批次管理
执行历史这里可以查看结果报告，我们将excel当中配置的各个sheet页在这里按条目一一对应，并且可以看到具体的执行日志，结果错误的语句，并抽取一定量的错误数据以供缺陷分析。
测试结果
统计分析模块目前还未完成开发，未来将根据使用情况，积累到足够数据后，针对数据采集情况采用不同报表和统计方式，以期能通过数据分析和报表呈现的方式对批量程序质量进行持续跟踪，进而提高测试质量。
总结
批量测试无前台页面，逻辑关系复杂，覆盖业务面众多，数据量大等特点，导致批量测试的难度很大。平台的产生纵然能解决自动化和降低部分检查难度，但其造数和测试的复杂性仍旧存在，导致平台配置仍然复杂。如荀子所言，“跬步不休，跛鳖千里；累积不缀，可成丘阜”，下一步的方向是将更多新技术与项目实际相结合，步步拆解其复杂性，进一步提高批量测试效率。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
mysql亿级数据数据库优化方案测试-银行交易流水记录的查询
带你征服编程和泡妞两座大山
对MySQL的性能和亿级数据的处理方法思考，以及分库分表到底该如何做，在什么场景比较合适？
比如银行交易流水记录的查询
限盐少许，上实际实验过程，以下是在实验的过程中做一些操作，以及踩过的一些坑，我觉得坑对于读者来讲是非常有用的。
首先：建立一个现金流量表，交易历史是各个金融体系下使用率最高，历史存留数据量最大的数据类型。现金流量表的数据搜索，可以根据时间范围，和个人，以及金额进行搜索。
-- 建立一张 现金流量表
DROP TABLE IF EXISTS `yun_cashflow`;
CREATE TABLE `yun_cashflow` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`userid` int(11) DEFAULT NULL,
`type` int(11) DEFAULT NULL COMMENT '1、入账，2提现',
`operatoruserid` int(11) DEFAULT NULL COMMENT '操作员ID',
`withdrawdepositid` bigint(20) DEFAULT NULL COMMENT '提现ID',
`money` double DEFAULT NULL COMMENT '钱数',
`runid` bigint(20) DEFAULT NULL COMMENT '工单ID',
`createtime` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=63 DEFAULT CHARSET=utf8;
然后开始造1个亿的数据进去。
-- 循环插入
drop PROCEDURE test_insert;
DELIMITER;;
CREATE PROCEDURE test_insert()
begin
declare num int;
set num=0;
while num < 10000 do
insert into yun_cashflow(userid,type,operatoruserid,withdrawdepositid,money) values(FLOOR(7 + (RAND() * 6))+FLOOR(22 + (RAND() * 9)),1,FLOOR(97 + (RAND()
* 6))+FLOOR(2 + (RAND() * 9)),FLOOR(17 + (RAND() * 6))+FLOOR(2 + (RAND() * 9)),FLOOR(5 + (RAND() * 6))+FLOOR(2 + (RAND() * 9)));
set num=num+1;
end while;
END;;
call test_insert();
坑一：
这个存储过程建立好了之后，发现插入数据特别的慢，一天一晚上也插入不到100万条数据，平均每秒40~60条数据，中间我停过几次，以为是随机函数的问题，都变成常数，但效果一样，还是很慢，当时让我对这个MySQL数据库感觉到悲观，毕竟Oracle用惯了，那插速是真的很快，不过功夫不负有心人，原来可以用另外一种写法造数据，速度很快，上代码。
INSERT INTO example
(example_id, name, value, other_value)
VALUES
(100, 'Name 1', 'Value 1', 'Other 1'),
(101, 'Name 2', 'Value 2', 'Other 2'),
(102, 'Name 3', 'Value 3', 'Other 3'),
(103, 'Name 4', 'Value 4', 'Other 4');
就是在循环里，用这种格式造很多数据，VALUES后面以,隔开，然后把数据写上去，我用Excel造了1万条数据，按照语句格式粘贴了出来，就变成每循环一次，就1万条数据，这样没多久1亿数据就造好了。
select count(*) from yun_cashflow
我还比较好奇，8个字段1亿条数据，到底占了多大的地方,通过以下语句找到数据的路径。
show global variables like "%datadir%";
通过查看文件，是7.78GB，看来如果字段不是很多，数据量大的话，其实不是什么问题，这其实作为架构师来讲，在估算机器配置硬盘冗余的时候，这是最简单直接粗暴的换算思路。
行了，表建完了，各种实验开始
首先，啥条件不加看看咋样。
呵呵了，Out of memory，看来这个查询是真往内存里整，内存整冒烟了，看来7.8G的数据是往内存里放，我内存没那么大导致的。
资金流水一般会按照时间进行查询，看看这速度到底怎样。
select * from yun_cashflow where createtime between '2018-10-23 09:06:58' and '2018-10-23 09:06:59'
我去，脑补一下，当你拿这支付宝查历史资金明细的时候，56条信息，103.489秒，也就是将近2分钟的查询速度，你会是怎样的体验。哦 哦，不对，这个还没加用条件，那下面单独试试某个用户不限时间范围的条件是怎样的。
select count(*) from yun_cashflow where userid=21
也是将近1分半的速度，那在试试金额的条件。
select count(*) from yun_cashflow where money<62 and userid=32
同样都是将近一分半的时间。
那把两个条件做下级联，看看效果会是怎样。
一样，也是将近1分半的时间。
小总结一：在不加索引的情况下，无论单独，还是联合条件查询，结果都是1分多钟不到2分钟。
好吧，那就加上索引试试，看看到底会有啥样奇迹发生。
给用户加索引
ALTER TABLE yun_cashflow ADD INDEX index_userid (userid)
`
给金额加索引
ALTER TABLE yun_cashflow ADD INDEX index_money (money)
给时间加索引
ALTER TABLE yun_cashflow ADD INDEX index_createtime (createtime)
小总结二： 建立索引的时间平均在1400秒左右，大概在23分钟左右。
索引都建立完了，在开始以前的条件查询，看看效果。
1、时间范围查询
select * from yun_cashflow where createtime between '2018-10-23 09:06:58' and '2018-10-23 09:06:59'
2、用户查询与钱的联合查询
3、用户查询与钱与时间三个条件的联合查询
select * from yun_cashflow where money<62 and userid=32 and createtime between '2018-10-22 09:06:58' and '2018-10-23 09:06:59'
小总结三：建立完索引后，这种级联性质的查询，速度基本都很快，数据量不大的情况下，基本不会超过一秒。
由于时间的范围返回是56条数据，数据量比较小，所以速度快可能与这个有关，那实验下条件多的数据效果会是什么样。
先试试加完索引, 金额条件的效果。
2千5百万的数据，返回时间为11.460秒。
加一个用户数量比较多的条件 UserID=21
返回1000多万的数据，用了6秒
在找一个用户数量比较少的userid=34
返回4000多条，用不到1秒。
小总结四：条件返回的数据统计量越多，速度就越慢，超过1000万就慢的离谱，1秒左右就是100万的量才行。
那。。。。。。。。。。。。咱们程序猿都知道，我们在做数据的时候，都要用到分页。分页一般会用到LIMIT,比如每页10行，第二页就是LIMIT 10,10，得试试在分页的时候，哪些页的情况下，会是什么样的效果呢?
limit在1千时候速度
limit在1百万时候速度
limit在1千万时候速度
小总结五：LIMIT 参数1，参数2 在随着参数1（开始索引）增大时候，这个速度就会越来越慢，如果要求1秒左右返回时候的速度是100万数据，在多在大就慢了，也就是，如果10条一页，当你到第10万页之后，就会越来越慢。如果到30万页之后，可能就会到不到一般系统的3秒要求了。
数据库都建上索引了，那我插数据速度有没有影响呢，那试试
也就是说100条数据插了将近5秒，平均每秒插20条。
小总结六：也就是说，按照这样的速度插入，并发量一但大的情况下，操作起来会很慢。所以在有索引的条件下插入数据，要么索引失效，要么插入会特别慢。
分库分表的思维，一个大表返回那么多数据慢，那我把它变成若干张表，然后每张表count(*)后，我统计累加一下，一合计，就是所有数据的查询结果的条数，然后就是到第多少页，我先算一下这页在哪个库，哪张表，在从那张表读不就完了。通过之前 的总结，100万数据返回为1秒，所以就一张表里放100万个数据，1亿的数据就100张表。
BEGIN
DECLARE `@i` int(11);
DECLARE `@createSql` VARCHAR(2560);
DECLARE `@createIndexSql1` VARCHAR(2560);
DECLARE `@createIndexSql2` VARCHAR(2560);
DECLARE `@createIndexSql3` VARCHAR(2560);
set `@i`=0;
WHILE `@i`< 100 DO
SET @createSql = CONCAT('CREATE TABLE IF NOT EXISTS yun_cashflow_',`@i`,'(
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`userid` int(11) DEFAULT NULL,
`type` int(11) DEFAULT NULL ,
`operatoruserid` int(11) DEFAULT NULL ,
`withdrawdepositid` bigint(20) DEFAULT NULL ,
`money` double DEFAULT NULL ,
`runid` bigint(20) DEFAULT NULL ,
`createtime` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
)'
);
prepare stmt from @createSql;
execute stmt;
-- 创建索引
set @createIndexSql1 = CONCAT('create index `t_money` on yun_cashflow_',`@i`,'(`money`);');
prepare stmt1 from @createIndexSql1;
execute stmt1;
set @createIndexSql2 = CONCAT('create index `t_userid` on yun_cashflow_',`@i`,'(`userid`);');
prepare stmt2 from @createIndexSql2;
execute stmt2;
SET `@i`= `@i`+1;
END WHILE;
END
表建完了，库里的效果是酱样的。
是不是很酷，这表分的，绝了，满库全是表。那还得往每张表里整100万的数据。这部分代码就不写了，可以参考前面的改，相信能把文章看到这的都是懂行的人，也是对这方面有一腚追求的人。
坑二：我高估了我的计算机的并行计算能力，当我启用100个线程同时玩我自己电脑的数据库连接的时候，到后期给我反馈的结果是这样的。
说白了，连接满了，超时，数据库都不给我返回值了，所以这种实验，不找100台机器，也别可一台机器去霍霍，因为如果能快，那个1个亿的大表，返回的也不会慢。这时候拼的就是计算能力了,都在一台机器上去做实验，会让你怀疑人生的。
以上是关于如何在银行系统中做批量测试~的主要内容，如果未能解决你的问题，请参考以下文章