(原创)数据存储-Part 1 -浅谈

2020-06-22 00:00:00 数据 数据库 测试 系统 验证

谈论起存储,不等不说存储的目的是保存数据,以备后续之需,如何使用存储的数据,我们后面再慢慢说,所以,我们还是先谈数据存储。

谈论数据,大家马上就会想到大数据,这个太热门了。数据作为IT系统中基础的原料,不论在传统行业还是互联网行业,都要以数据作为基点,然后开展各种各样的业务活动。整个数据的生命周期由创建数据、查看数据、修改数据、删除数据四个步骤。站在测试的角度,保证数据在进入被测系统前是正确的(入口),经过被测系统处理后,出来的数据是符合预期的(出口),不论是功能测试还是E2E测试,都是遵循这样的目标和准则。输入和输出的数据是否符合预期,完全取决于概要需求和详细需求的定义;后通过报文验证(xml/json)、数据库数值验证和日志报文验证来完成,当然,这些步骤完全是可以通过自动化方式来完成。总之,符合业务需要的数据,就是正确的数据。

那么数据初保存在哪里?从哪里来?追溯本源,数据肯定是从某个设备输入到系统中的,微信、微博、短信、网站、手机App应用等等。数据初保存在TXT、Excel、Access这样的文件或者系统中,这里特别要指出的是Excel应用,千万不要小看它的功能和潜力,当我们去解决数据存储和展现的问题时候,有时候重要的不是工具,而是想法和思维方式。所以,早很多财务系统数据、OA系统数据、进销存系统数据都保存在Excel应用上,后面才慢慢往Access系统上迁移,可以说Access是Excel的升级版。这2个系统简单、易用、易维护,只是需要简单SQL技能,系统能快速响应。缺点也是很明显,当碰到数据量巨大时候;需满足几百人、几千人同时访问的时候;需要访问控制的时候,它的短板显露无疑,系统响应速度倍减、容量无法扩大等等。这是我们所说的数据存储代产品,但是,我必须说Excel仍然在我们测试领域占有一席之地,能够快速完成数据创建/修改/复制/导入等功能,还有带有分隔符的TXT和CSV文件,也是同样的重要,方便测试快,简单的制造数据。

来到数据存储的第二代系统,商业版的关系型数据库,微软SQL Server、甲骨文Oracle、IBM DB2、Sybase,四大巨头,在当时的年代,完全占领了几乎全部市场份额。这些数据库,可以说是Access的升级版本,也是关系型数据库,能提供更大的数据存储能力、更快的响应时间、更好的图形化界面和命令行工具,极大的方便开发和测试人员的工作。对于测试人员来说,有三大挑战,(1)数据库的安装和卸载,在Windows系统下,数据库的安装原来只需要一张光盘,随着新产品不断迭代,后面逐步向6张,甚至更多光盘的方向发展,感觉特别的夸张;当时都是安装单机版,安装条件受到各种约束,OS系统的各种包,其它软件冲突等等,一旦安装或者卸载失败,整个人就不好了,弄不好,OS都需要重装,如果碰到紧急的发布,时间压力巨大,想死的心都有了。到了后面Norton Ghost系统出来后,终于实现了一次安装、终身使用,测试环境的运维工作得到了极大的减轻,这样的感觉,做过的同学有没有?(2)当数据库从本地运行转移到Intranet的服务器上运行后,数据库响应速度,就是我们需要考虑的了因素之一了;其次,服务器的硬盘容量和内存大小,测试的也需要持续关注,可以看到这个时候,测试的运维工作,除了数据库本身,已经覆盖到服务器的CPU负载、硬盘容量和内存大小,随着环境的变化,测试必须跟上技术和业务发展的需要。(3)后一个难点,就是SQL语言了,对于测试的要求,除了基本的数据库安装、卸载、服务器硬件性能监控,发展到写SQL语句了,终于有点“技术”含量的事情了,涉及代码了,多表/跨库/嵌套查询,走一个,能写越复杂的SQL语句,在当时情况下,代表你的测试水平越高,测试上位的明显标志之一啊!SQL语句的编写,多表嵌套查询,直到2017年的面试,我还是会被问到,可以想象,SQL语句的编写水平是多么的重要啊,大家一定不能轻视。多说一句,现在对于SQL语言掌握的要求,在互联网发展到今天,对于系统响应速度的要求极高的情况下,跨库的查询、嵌套查询基本在代码上线前,直接被DBA给枪毙了;多表的查询,能避免就尽量避免了(在大厂,基本也是被DBA枪毙),否则,系统响应的速度还是慢得跟乌龟一样。但是,话又说回来,银行、保险和税务三个行业,可能多表/跨库/嵌套查询的操作还是很多,这是它们系统本来就是这样设计的,但是,系统升级和优化还是需要相当长的一段时间,才能有明显的改善。

来到数据存储的第三代系统,互联网/移动互联网时代,随着对于系统速度近乎畸形的追求和去IOE化的浪潮到来,数据量的增长已经远远的超过了第二个时代,原来的数据库让人感觉比较庞大、比较臃肿、不够灵活、价格也居高不下。这时候,MySQL出现,解决了大部分的问题,小巧,轻便,便宜是它的优势,很多大的互联网公司逐渐先把非核心业务迁移到这上面,然后在通过基于这个数据库,进行封装,开发出定制化的数据库,适合存放核心业务数据。由于MySQL还是基于关系型数据库的基础,只要会原来上文说的4种数据库,在使用和运维上,对于测试的要求并没有啥特别变化,但是,特别显著的变化还是安装和卸载,简单了很多,毕竟软件本身的大小有限,现在MySQL已经有一个分支了,就是MariaDB,也是基本功能跟MySQL没有太大的区别。如果说,只是MySQL一个方面的变化,其实,不能算是巨大,也可以看出,技术的更新和迭代,一定是在原来的基础上进行自我进化,不是翻天覆地,一代皇帝,一朝臣情况,所以,测试对于基础知识的掌握是多么的重要。另外一个方面,就是缓存技术的大量使用,对应的数据库就是Redis/MemCache/Pika等系统不断涌现,一方面是对于访问速度不断提高的场景下,热/冷数据等等概念提出来,用大量Key/Value的形式表示和存储数据,缩短系统响应和处理数据时间。有些业务场景下,需要MySQL和Redis两个数据库的协作,才能满足业务需求,例如:Redis存储数据内容为ID和timestamp,应用拿到timestamp后,到MySQL去寻找对应数据信息,可能是订单的处理状态、商品库存多少、商品种类多少等等信息。这个时候,对于测试来说,除了掌握标准的验证MySQL验证脚本:

ODBC Driver:SQL Server/Oracle/DB2/Sybase/MySQL

DB Connection:DB IP:Port + UN:PW + db name +db type ()+charset

DB Statement:select ordername, oderstatus, timestamp from db

DB Resultset:输出结果和预期结果比较

DB Disconnection:DB IP:Port + UN:PW + db name +db type ()+charset

对于Redis的验证,一般是通过XML或Json报文来验证,这样更方便和不易受到底层数据库变化的影响。对于测试来说,除了SQL语言的编写能力,通过Xpath方式验证结果,也是非常重用。这里也要再次强调一点,对于报文验证,由于跟缓存数据库结合紧密,一般会有两种方式,一种是全文对比,另外一种是部分内容对比,对于全文对比,很容易受到节点的顺序不一致影响,导致报文对比失败,造成测试结果误判;如果采用部分内容对比,通过xpath的方式,自动化脚本误判的机率大大降低。从此可见,验证的方式,从原来单一的方式,变成了file comparison 和 data comparison集合的方式,也是目前很多测试验证的标配方式之一。

下一篇文章继续谈论第四代数据存储……

相关文章