测试环境管理:测试环境该填坑了

发表于:2019-7-22 11:06  作者:侯峥   来源:51Testing软件测试网原创

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 测试管理

  随着公司业务的拓展和需求的增多,对于测试环境的要求也在越来越高。单一的测试环境已经满足不了现有的发展势头,扩展测试环境的规模,加强测试环境的管理已经成为摆在测试人员面前的重要问题。以当前的业务拓展形势和需求迭代频率,单一的测试环境以及配置策略不足以支撑完成测试任务,测试环境的实例数量层级和策略配置复杂度都需要想生产环境靠拢,以便完全模拟生产环境,及早暴露程序编码中出现的问题,但是这种环境又并不完全等同于灰度测试环境。
  一、测试环境方面经常遇到哪些问题?
  对于测试管理人员来讲,通常会遇到以下问题:
  1、测试人员误操作,“rm -r *”删除测试实例
  2、测试实例不够用需要扩充实例数量
  3、虚拟机空间告警
  4、部署操作机械频繁,需要规范及自动化操作
  5、测试实例乱用,需要规范定义实例用途
  对于以上的问题,有些问题可以提前规避,有些问题需要事后处理。无论处理方式是怎样的最终的目标都是解决问题,减小损失。这些问题的处理方式可以从技术上入手,也可以从工作流程上规范。
  二、测试环境的问题会造成那些影响?
  1)测试人员误操作,“rm -r *”删除测试实例
  对于误删这个问题,为大家多熟知的就是生产环境的删库跑路。实际上,误删现象在测试环境上也多有出现,只不过是影响范围没有生产环境误删那么的严重,在比较之下,大家对于测试环境误删的事件就没有那么的重视。但是,实际上,由于测试环境误删所引发的蝴蝶效应也是很严重的。
  蝴蝶效应是什么?这里就不必多说了。简单讲讲测试环境误删可能引起的问题。前不久,同事在测试环境执行“rm -r *”操作,删除了一台测试虚拟机上的全部实例,恰巧同事删除的是与其他厂商共用的测试环境,这个环境平时大多用于和对接厂商联调测试和客户演示用的。尽管误操作发生后,及时采取了补救,但是其他厂商和客户还是受到的影响。恢复环境的当天,收到了很多询问的电话。恢复环境一共花费了一天的时间,在这一天里联调的测试任务全部中断停滞,同时还要统一对外的解释口径。还好同事的账号只有本公司的权限,否则如果是删除了所有厂商的服务实例,恐怕再多的解释也掩盖不了问题。
  2)测试实例不够用需要扩充实例数量
  对于测试任务的增加,需要增添测试实例,用于保证需求如期上线。这个问题在公司业务扩张的时候最容易出现。也是体现出了业务部门与技术部门的规划沟通不足。最近一段时间,需求的任务量加重,详细了解之后,才知道是业务部门增加了3个业务线条,需要对应的增加系统应用中的功能。但是对此技术部门并不知道,直到需求任务提出时,才意识到测试实例支撑能力不足,现有的测试实例支撑已经近饱和状态,再加上新增业务线条的需求马上捉襟见肘。
  为了应对这个问题,临时搭建了几个测试实例,用于支撑新业务线条的需求功能测试。但是临时搭建的测试实例也存在一些问题,比如:与之前的测试环境规划有略微的出处,需要后期重复构建;新搭建的测试实例的策略可能有遗漏、测试数据不全,导致测试时任务中断。
  3)虚拟机空间告警
  我们公司是为某电信运营商提供技术服务和支持。我们项目组的支撑业务系统是经营分析系统,系统的数据源传输,数据源处理,系统应用是由多个厂商共同协作处理。这种情况就使得我们需要一个共用的环境,这个环境用于测试联调、功能演示。在这种情况下,这个测试环境的总管理就需要甲方公司主理。因此,测试环境使用的健康情况就成为了甲方考核公司的一项指标。
  由于需求版本的增加,提测版本的迭代,测试环境中的日志和备份内容也在增多。经过累积达到一定的数量会导致虚拟机空间不足。虚拟机空间不足会影响测试实例的性能,有些经验不足的测试、开发人员不能够快速的定位问题,更重要的是会影响甲方公司对于本公司的考核成绩。
  4)部署操作机械频繁,需要规范及自动化操作
  公司部署服务是由测试人员在开发人员提测后,自行打包,再把打好的包部署到测试环境实例上,测试环境实例都是tomcat实例。由于测试人员打的版本包里的配置文件是开发本地的地址,如果直接部署的话,测试实例启动会报错,需要替换配置文件后重启服务。这些操作看似简单,但是如果操作不熟练或者不了解部署原理的,会很耽误工作时间。如果部署阶段出现问题,会致使花费大量的时间排查环境方面的问题。
  备份是常听到的词。部署新的版本前,需要备份正在使用的版本,保证版本升级失败的版本回退操作。但是不同的人员的操作习惯和风格不一,这就使得测试环境的备份内容大相径庭,找不到规律。如果需要其他同事来恢复版本,在没有人员指导协作的情况下,不太容易找到需要恢复的版本。这样也不利于测试环境空间的高效使用,在清理空间时,也不能贸然清理。
  5)测试实例乱用,需要规范定义实例用途
  在测试的过程中,有部分的bug是由数据问题导致的。这些bug并不是程序的缺陷,是垃圾数据导致的程序报错,实际生产环境并不会出现这样的数据。那么这些垃圾数据是如何产生的呢?敏捷开发是当下使用最广泛的开发模式,他的特点在于功能的小版本迭代,不需要等功能都开发完再提测,减少了测试的等待时间。但是对于程序来讲,按照功能点提测产生的数据就有可能成为下一个版本提测功能的垃圾数据,如果环境数据控制的不严格,会出现很多由数据导致的问题阻碍测试进行。排查这类问题花费的时间也占用了测试的总时间。
  对于对外提供联调能力或者演示用途的测试环境,如果遇到由于垃圾数据导致的问题,客户或者其他厂商会直接定义为延误工作进度,他们并不清楚造成系统问题的原因。从客户或者其他厂商的视角,他们只关心系统能不能使用,并不关心造成系统不能使用的原因,如果遇到问题会直接记录考核。
  三、针对测试环境问题的解决方案
  针对测试环境问题的解决方法可以从技术上、规范上两个方面入手,但是倾向技术方案解决为主,规范方案解决为辅,减少人工干预以及认为操作带来的失误。
  在测试环境内容误删方面,预防实例被删以便快速恢复实例,测试环境安装dump定期备份测试环境内容。
  在测试环境空间告警方面,定期清理,创建crontab删除历史分支及日志文件。
  在员工操作方面,编写部署脚本、生成测试数据脚本。脚本里定义备份方式以及备份路径,减少个人倾向,简化操作流程。


         ......
查看更多精彩内容,请点击下载:

版权声明:本文出自《51测试天地》第五十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

【福利】填问卷 送2019精选测试大礼包+接口测试实战课程!

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道