理想的WEB测试环境是什么样的?

发表于:2019-2-21 15:45

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

 作者:leon-ready    来源:知乎

  前言
  测试环境往往是影响测试效率的关键性因素之一,尤其是在大规模项目中,涉及到多分支并行测试和多项目同时存在的场景,不合理的测试环境可能会严重拖慢项目进度。
  每个公司都有自己的测试环境,也都有自己的问题,今天我就想结合个人工作经历,聊一下关于测试环境的问题。
  注:下面的方案都默认在当前主流的前后端分离的场景下,对于还未前后端分离的应用,我理解的一般也还不需要关心此问题。
  理想状态
  我心目中理想的测试环境其实很简单,满足几个条件即可:
  · 易于连接,即进入测试环境的步骤很简单。
  · 支持水平扩展,即可以支持同项目在不同的测试环境上面并行测试的场景。
  · 高仿真,即尽量保证测试的代码与线上代码一致。
  · 隔离性,即不同的项目互相之间不影响。
  基于dns的测试环境
  实现方式
  基于dns修改的测试环境是最为常见的一种方案。这种场景下,我们进入测试环境的手段为修改本机的dns指向,将正常访问到线上服务器的域名指向测试环境的机器。
  本机的dns指向最为简单的修改方式即为修改 hosts 文件。
  Hosts是一个没有扩展名的系统文件,可以用记事本等工具打开,其作用就是将一些常用的网址域名与其对应的IP地址建立一个关联“数据库”,当用户在浏览器中输入一个需要登录的网址时,系统会首先自动从Hosts文件中寻找对应的IP地址,一旦找到,系统会立即打开对应网页,如果没有找到,则系统会再将网址提交DNS域名解析服务器进行IP地址的解析。
  比如:我们需要测试线上访问为 www.example.com 的页面,基于目前的主流方案,其中页面中的静态资源(js/css/img)线上分布在cdn上如,cdn.example.com ,后端接口部署在 api.example.com 下,假设我们的测试环境将资源和服务都部署在内网 10.0.0.1 的上面,我们测试的时候只需要修改本机器的hosts的文件:
  10.0.0.1 www.example.com #html地址
  10.0.0.1 cdn.example.com #js css地址
  10.0.0.1 api.example.com #接口地址
  然后打开浏览器访问,即可抵达测试环境。(另外也有修改本地dns服务的方案也可实现,原理类似,在此不做赘述。)
  优缺点
  基于dns的测试方案具有以下优势:
  · 灵活性高。几乎可以解决任意情况,无论你需要测试的 web 站点使用了多少域名,理论上都可以通过配置 host 的方案来指向你的测试机器。而且每个测试人员在测试环境之间可以随意组合,比如静态资源和后端服务部署在不同的机器,不同的后端服务部署在不同的机器,都可以搞定。
  · 水平拓展性强。部署一套新的测试环境唯一的工作就是修改一下host文件中的ip地址即可。
  · 高仿真。因为我们是从dns层面修改请求的指向,所以在代码层面没有任何侵入,也就是说,你的代码中线上请求地址为:http://api.example.com/api/test ,在测试环境中也是请求同样的地址,我们无需为了适配测试环境修改任何代码,从而保证了测试结果的可靠性。
  说完优势,我们看下上述方案的缺点是什么?
  配置不便。体验主要体现在对host的管理上,这里面有几个问题:
  · 系统host为文本文件,没有版本控制,对于多环境切换非常不友好。为了解决这种问题,诞生出不少修改host的工具,比如 swtichhosts ,帮助管理host。
  · 实效性差。对于有一定工作经历的同学来说,都知道修改hosts文件并不能实时生效,因为系统层面和浏览器层面为了提升访问速度,都会对dns解析做一定的缓存,也就是说,你突然将 www.example.com 的指向修改为另外一个地址,刷新浏览器并不能马上生效,经常需要重启浏览器,体验极差。
  · 干扰性强。对于host依赖较多的项目,由于上面说的诸多问题,我们有很多时候都在怀疑自己到底在哪个环境,是否切换host成功,是否host生效等等都是问题,从而导致了很多时间浪费在排查host上面。
  注:对于host的连接性问题,我也曾花过很多时间寻找解决方案,最终研发了一个能解决上述所有问题的工具: multiple-host liyangready/multiple-host,它通过沙箱机制,解决了host缓存问题,还可以支持同时打开多个host环境,在此安利一波,哈哈
  如果仅仅是连接性问题,可以通过工具搞定。今天就不会有这篇文章的存在了,在实践了很久之后,我发现了更多其他问题。
  · 移动端web页面测试麻烦。随着移动时代的到来,移动端的web页面越来越多,同样面临着测试问题。然而手机上面的hosts配置无法轻易修改,尤其是ios系统下面。对于这些移动设备,往往需要配置一层代理,将手机的网络代理指向自己的电脑,然后在本机的代理软件中修改 dns 指向,比如大家常用的 fiddler、charles等,还存在证书配置等等问题,增加了操作步骤和成本。
  · 多人协作管理困难。对于大型项目,往往参与人数众多,涉及到的系统众多,通过配置host文件的方案,经常发生多方同步不到位的情况。另外,涉及人员还可能有很多非技术人员,修改host的方案对于他们来说完全是负担。尤其是多套测试环境和多个域名的场景,通过本机文件来控制会引发很多管理难题。
  基于约定的测试环境
  实现方式
  基于host的测试环境是自由配置方案,基于约定的测试环境是集中式管理方案。这类方案主要思路是为测试网站提供一个单独的测试域名,比如 http://www.example.com对应有一个 http://www.example.test.com,同时将http://www.example.test.com 在内网通过统一的dns指向测试环境。
  优缺点
  集中和自由的矛盾其实就真实的反应在两种方案上面。
  优势:
  解决了多人协作管理难题。集中管理最大的好处显而易见,无需任何其他配置,测试人员直接打开对应的测试地址即可,对非技术人员来说,没有理解成本。
  解决了绑定host带来的所有问题。显而易见,上述所有绑host过程中可能带来的问题都不复存在。
  缺点:
  改造成本高。对于集中式配置,目的就是为了去除个人配置的成本,意味着web站点下面所有的域名都需要支持该种方式访问。对于大型企业来说,这样的域名可能成百上千个,需要有对应的自动化体系实现,成本较高。
  移动端访问路径变化。如上所述,http://www.example.com 在测试环境下面的访问路径变成了 http://www.example.test.com,在pc时代没有太大的问题,然而在移动端,h5的路径很多都是客户端写死的线上地址,还有很多运营页面的地址是运营配置,打开的链接并不受我们控制,无法方便的将 http://www.example.com切换为http://www.example.test.com。
  代码侵入。除了访问地址发生变化,接口和静态资源都发生了变化,我们的代码中需要判断在不同的环境调用不同的接口地址,如 http://api.example.com or http://api.example.test.com,以及静态资源等所有涉及到域名的地方,甚至包括后端返回的链接地址,这样不仅需要在代码中判断不同的环境,还对测试的仿真性造成了一定的影响,稍不注意,可能会触发线上代码访问测试环境地址的惨案。
  水平扩展能力弱。在host方案中,我们提到其水扩展能力很强,但是在集中式配置中,相应的,水平扩展能力就非常弱了。因为http://www.example.test.com统一指向了 10.0.0.1,此时如果同一个项目同时需要两套测试环境,问题就比较棘手了,只能在中心再另起一个域名如 http://www.example.test1.com,相比如host方案中自行水平拓展的能力来说,此方案的拓展能力完全受限于中心的配置。
  灵活性差。在host方案中,我们提到过,对于不同的域名指向,我们可以随时通过切换host配置来自由组合,然而在集中式配置方案中,假设前端同时依赖两个后端在不同域名的测试环境中,比如api1在http://api1.example.test.com,api2在http://api2.example.test1.com中,前端无法自动的判断环境,往往只能手动改代码重新发布,不仅效率低下,还非常容易带来问题。
  理想方案
  在上面我阐述了个人对于『基于host的测试环境方案』和『基于约定的测试环境方案』的看法。然而似乎都各有优缺点,很不理想,那么,如何结合二者的优点,实现一套真正便利的测试环境方案呢?
  自由配置+集中约定
  其实我们就是想要约定式方案中的不需测试人员配置打开即用的测试环境,又需要一定程度上可以类似host方案中可以自行控制访问路径,于是我们可以考虑:
  提供多套测试环境,如 http://www.example.test.com, www.example.test1.com... ,数目由项目可能存在并行最大分支数决定,一般情况下肯定不会超过5个。
  发布可自行选择需要的环境,同时可以下发配置文件,配置文件控制改项目需要访问的测试环境路径。
  对于服务端来说,启动时下发配置再正常不过,不需赘述。
  前端由于其动态性,没有启动过程,早期想要无侵入的下发配置是一件比较麻烦的事情。然而在前端编译流盛行的今天,事情有了转机,我们只需要将前端打包过程挪到服务端,同时在打包时注入环境配置即可,如用webpack defineplugin,可以轻松注入运行时的变量。这样即使是前端需要对应多套不同域名的后端环境,也可以通过配置解决。
  客户端在测试包时也可通过配置决定需要打开h5页面的地址。
  支持多人协作的host管理工具
  其实对于host方案,问题集中在host管理问题,也并非不可取,假设我们能够在现有的host工具上,实现一套可共享和多人协作的host工具,同时能够实现快速绑定移动端host的功能,那么这套方案在发布流程上的改造成本会小很多。
  结论
  我心目中最理想的测试环境为:自由配置+集中约定。它可以实现不需要任何处理的情况下,打开即能连上,而且又能够通过配置下发的方式保留一定的灵活性。

      上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号