自动化测试—业务线仿真回归流程剖析

发表于:2013-11-27 11:14

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:凡提    来源:51Testing软件测试网采编

  引言
  Hadoop集群的计算和数据处理能力随着集群规模的增长逐渐形成了一个弥漫天际的浩翰空间,处于其中的各种数据应用、采集作业、数据分析、数据挖掘,以及前沿的机器学习、人工智能等都如同空间中的一朵朵云彩,此消彼长。Hadoop集群根据业务提起的请求按需动态分配计算资源、数据空间,虽然业务的需求是复杂多变的,但是对于大规模的Hadoop集群来说,整体的计算能力需求则始终是平滑的。这正是云计算的特点,而为了应对这样一个动态的计算资源,仅仅通过前几弹描述的一些含有相当强烈针对性的测试作业来模拟真实状况显然是远不够完备的。
  因此,我们需要对每一个新发布的Hadoop版本进行真实的业务线作业仿真模拟回归。这种仿真回归可以最大限度的验证发布版的每个功能点是否正确可靠,检查在新版本下集群的稳定性、数据的正确性和完备性,以及运行周期是否出现变化,是否引发了新的计算热点或出现数据倾斜。本身仿真模拟回归也一直是发现bug最多的一项测试活动,通过业务线仿真回归验证的新版本,就像盖了最后一道质检认证章,能给予用户、运维和开发团队更好的上线信心。
  常态化回归
  业务线的回归按照规模大小来分,可以分为常态化回归和定制化回归。常态化回归一般用于小版本发布前的集成测试,作为测试周期的一部分,需要快速、简洁的定位出常规问题。因此这种类型的回归规模一般都不大,选取的业务作业往往具有广泛的代表性。此类业务作业所需的数据可以自行创建,用非真实的随机数据模拟填充业务数据,但作业内容可以是直接抽取线上的真实执行过程来模拟。业务完成后,通过自动化工具将新生结果与基线结果进行全量对比。
  我们在云梯的测试中,有一个早期引入的业务线回归环境,数据和作业都比较陈旧,但是在广度覆盖面上是比较充分的,基本覆盖了广告线、搜索线和BI线三大模块。业务回归由调度系统、执行gateway和结果对比三个部分组成,执行过程中收集指标信息,判断任务执行过程的正确性,以及判断对比结果是否出现偏差。早期这个业务线都是手动执行各步骤,然后人工分析监控指标数据和对比结果,过程冗长易出错,后来有了第三弹提及的DST系统后,通过自动化工具将各步骤顺次串联执行,终于实现了业务回归一键自动化。测试人员只要坐在页面前点点鼠标,等待一段时间后看一下结果就可以了。
  当然,业务线的引入和各模块的部署安装以及各步骤的理顺并非一蹴而就的事情,其间复杂度是很高的,这也是在跨机房项目之前一直沿用这个比较老的业务线做常态化回归的原因。也正是因为跨机房项目的复杂性导致沿用近两年的老数据和老作业逐渐不具备广泛的代表性,借此契机我得以了解了整个业务线仿真回归的设计过程。下面将就此进行介绍。
  数据快照
  既然要跑真实的业务线作业,那么就少不了需要从线上集群导入脱敏后数据(后文会提及从安全角度如何做脱敏)。显然,实现海量数据的全量模拟回归是不现实的,因为这将需要建立一个和线上集群同等规模的测试集群来做这件事情,耗费成本巨大,更体现不了测试团队在这个过程中的技术价值。当然灰度发布是一个可行的方案,但这种方式要求线上集群必须停止一段时间的对外服务或者腾出部分空间和计算资源,专门用来对新版本进行验证,对于24小时不间断且基本处于满负荷状态的云梯来说,是没法提供这样的机会来做灰度发布的。
  既然不能导入全量数据,也不能通过灰度发布来模拟业务线回归,那么就只能通过导入某一天的数据来实现我们的测试目标了。于是我们在启动新的业务线设计流程后,立即开始将最近的一天数据导入到测试集群。之所以取最近的一天,是因为一般说来为了提高空间的利用率,节约存储资源,数据在结果表生成之后最快3天左右就会出现大规模的合并和删除,导致旧的原始数据出现缺漏。因此这个快照不仅要取最近的一天,还要争分夺秒的从线上拖拽到测试集群,以防止时间过长后数据被合并或删除(后面会谈一下原始数据已经缺失后怎么办)。
  数据快照的取得需要从audit日志中进行分析,看前一天晚上生产作业都访问了哪些数据,好在HDFS的这些信息都是导入到hive中的,可以通过sql语句快速查询整理出这个列表,刘顺提供了这个列表,我们循惯例称呼为“刘顺列表”,这和跨机房之后的刘顺列表还是有点类似的。顺带说一下,顺哥一直是各种列表的产生源,因为执着所以专业。
  这个列表并非完整的,在后面我们的实际调试过程中,不断发现某些作业需求的数据有缺失,因此需要动态的补充数据。跨机房项目中,我们启动了两个集群做业务线的仿真测试,其中一个用于固定的BI线回归,提取了2013年5月19日的数据快照,执行作业也是固定不变的,因此数据的补充是一个短暂的过程,短时间调试后,这条业务线就可以正常的工作了。而另一个集群,则汇合了几乎所有应用云梯的项目组提交各自的作业在其中进行模拟回归,这个集群更合乎线上的真实状况,用户不断提交各自的真实业务作业到云梯上进行测试,因此数据也需要经常动态补充,为此,我们这边在dst上快速开发一个页面提供给用户提交各自所需的数据文件路径,我们拿到这个信息后,就会尽快进行数据补充。开始都是人工通过distcp来拖拽数据,后来也快速迭代了自动化工具,配合简单的人肉甄别(感谢慧觉的不懈努力)实现了几乎无缝的数据补缺工作。这个集群的数据量从早期不到600TB,一直补缺增长到了1.2PB,前后一个多月的大规模业务回归模拟中,通过这个集群发现并解决了很多云梯跨机房产品的问题,其价值不可估量。
  除了HDFS上的数据快照,还需要获取业务线的meta数据快照,这包括2013年5月19日当天的hive元数据信息,以及作业执行脚本等等。这些meta数据,在线上也是日新月异的,好在量并不大,在业务方的配合下,我们快速搭建了一台gateway用于BI线业务回归。而另一个多项目组配合的集群则也是模拟线上的真实情况,几乎每个项目组都单独配置了一个gateway,最终配置了16台gateway。
31/3123>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • langtaosha
    2013-12-25 11:47:49

    怎么可以这么霸气!!!太佩服了!!!
    作者的能力让人高山仰止!!!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号