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

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

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

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

  一切源于真实
  数据快照取得之后,云梯还需要打通各类权限,以模拟线上的用户和组,同时又不能让这些用户和组无意中访问到线上,干扰了正常的生产作业。因此Namenode和Jobtracker上的用户组配置被完整的拷贝到了测试集群,但是对密码都做了修改,只保留了一个账号用于补充数据所需。测试集群所有机器都修改了/etc/hosts列表,将namenode和jobtracker地址指向了测试集群的这两个角色,测试作业所在的gateway无需任何改变就将作业跑进了测试集群。这期间也出过一次不大不小的故障,部分作业因部署的gateway疏忽修改而跑到了线上,好在密码不对,所有操作都被线上集群拒绝了。这样的双重保障最终确保了测试与线上之间的安全隔离,两者互不干扰。
  除了确保数据的真实性之外,我们也同样完整的复制了调度系统“天网”,在光锐团队的大力配合下,完整的业务线作业最终成功执行。天网遵从下面四个条件调度任务作业:
  1.节点的运行日志为空
  2.节点存在运行失败日志
  3.所有依赖的父节点已运行完毕,且状态为运行成功
  4.该节点没有被人为设置成不执行(有些作业因为受环境限制不得不停止调度)
  因此我们可以通过清空日志来重新调度我们需要执行的业务线作业。由于测试集群性能比不上线上,因此调度作业的先后顺序会由于执行时间不同而与线上相比发生变化,有些依赖关系上的bug也在本次模拟回归中暴露了出来。
  为了真实的模拟跨机房全过程,云梯测试在业务线仿真回归中,同样仿真了跨机房全过程,可以说业务线测试集群的参与人员是跨机房项目真正的先锋部队。业务方项目的测试人员是第一批真正感受跨机房的群体。从众多客户端到云梯客户端的统一,从过去直连Namenode到启用viewfs通过zookeeper选择Namenode,从单一Namenode到federation版本的Namenode一切为二,从Datanode向一个Namenode汇报到向多个Namenode汇报,从两个Namenode在同一机房到其中一个Namenode迁移到新机房,从数据的不跨到跨机房,从副机房的副本的增加到主机房副本减少,从主副机房的数据独立到crossnode启用,业务线仿真回归集群紧密跟随着跨机房复杂而又零碎的脚步前行,确保每一次修改上线都经过了周密的验证,盖上了由云梯测试以及众多业务方项目测试团队确认的权威“质检章”。
  流程图
  为了更直观的说明业务线仿真回归的全部设计过程,我抽象了如下图所示的流程图,取复杂的多业务线回归集群为例:
  整个过程中,云梯测试团队处于一个组织者的角色,Owner了整个项目的顺次执行,同时成为了测试集群的运维和技术支持,保障了业务方项目组测试人员可以顺畅执行各自负责的部分。同时还参与到了具体业务中,帮助业务方调查问题,甚至应业务方要求搭建了一些微型云梯集群供其执行一些非常特殊的测试。
  如今跨机房项目成功上线后,回忆起那段与业务方团队浴血奋战的峥嵘岁月,虽然艰苦繁忙,但是也收获良多,这种非常难得的大型业务线仿真回归实践,更是让我站在了一个比较高的层面上得以一窥云梯这个数据海洋的洋流全貌。
  正确性验证
  BI业务线是一个相对来说,输入输出以及执行脚本都比较单一的以hive为基础的仿真回归测试。既然是测试就必然需要做正确性验证,我们在这个过程中,沿用以前花香设计的对比脚本的思想,全新制作了全量对比工具。在BI线执行中,我们在gateway上的hive安装了一个hook,将所有新生成的表和数据同时生成一份到我们指定的位置(这个hook也用在多业务测试集群中)。在使用老版本hadoop测试完毕后,我们将自己设定的输出路径改名保存,然后重新部署新版本再次执行BI业务线回归。这样就获得了新老两次输出结果。和BI业务方讨论出需要执行全量对比的重要表列表后,全量对比自动化脚本就会生成两张与原始表schema完全相同的新表,然后将新老两次输出的路径作为location赋值给这两张新表。再利用hive sql对这两张表执行全量对比(具体sql因涉及安全不便透露分析)。
  对于其他业务项目来说,一般各自团队都有验证正确性的方案,在这次跨机房业务仿真回归中可说是八仙过海各显神通。但占据极大比例的hive相关作业都是通过上述方式进行的正确性验证。
  除了结果的正确性,执行过程的正确性和完备性也是需要进行验证的,这主要由审核各类执行日志来进行判断。此外,由于涉及客户端的统一化,因此兼容性测试的执行过程正确性尤其被关注。在跨机房项目的后期,稳定性测试的7*24小时连续不间断高负荷运作过程中,也不断需要对结果和执行过程的正确性做校准。本身,正确性验证由于全量对比造成的高负载也被作为稳定性测试的一部分被不断重复执行。至于性能和指标数据的正确性则由监控系统来保证,跨机房项目不仅需要集群内的监控,还需要多机房间的网络监控,以及主机房节点与副机房节点之间数据传输的监控,在有针对性的部署了多套监控体系后,我们甚至可以通过不同的监控系统来对同一个关注指标进行证伪性质的正确性判断。
32/3<123>
《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号