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

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

谈论数据，大家马上就会想到大数据，这个太热门了。数据作为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集合的方式，也是目前很多测试验证的标配方式之一。

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