问答 让开发在测试环境上进行冒烟自测,可好?

小敏 · 2017年08月11日 · 最后由 WILL 回复于 2017年08月30日 · 2437 次阅读

本来打算今天把项目提测的任务测完,结果基本一天都在搞测试环境,加班还在搞环境,最后不得不先放弃,直接在开发环境上测试,真的是心塞塞,下面这个表情特别能代表我此刻的心情!

缘起

项目刚开始的时候因为时间比较赶,测试环境上只部署了项目服务,后面连的数据库和 redis 还是开发环境的,因为造数据需要花费一定的时间。现在项目没那么忙了,这次项目提测,就想把测试环境的数据库和 redis 用起来,然后就开始了一天的踩坑之路!

1、这次项目迭代需要新建数据库表,开发之前只在开发环境数据库建了表,然后测试环境还需要再提工单给运维建表,可能是周五大家都比较忙,催了蛮久运维才把工单审批下来

2、项目需要开放对外接口给支付宝回调,开发环境在刚开始的时候就申请了外网 ip 可以供支付宝回调。我之前不知道,是咨询了开发才知道需要提运维工单,然后我就开始提工单给运维申请测试环境的外网 ip,催了运维,运维告诉我外网 ip 已经用完了,没有资源了,让我咨询 *** 同事,然后我去咨询 xxx 同事,他在开会,等了好久,然后他说他手上的外网 ip 都在用,没有空闲的。最后想了解决方法,就是在申请了外网 ip 的开发机上再部署了一套测试环境的代码,把配置中的回调地址改成测试服务在开发机上的地址,专门用来给支付宝回调一个接口用。
然而试了很久依然没用,然后又去问开发,说可能是有 ip 白名单限制,又跑过去问这个项目最开始的开发(已经换去别的项目),才知道需要申请端口的防火墙,然后就提工单去申请了防火墙。结果,工单提示,需要老大和信息安全部门审批,然而他们都已经下班了!

3、此处还省略了各种开发环境和测试环境配置不一致导致的问题!😂 😂 😂

此时,我的内心是崩溃的,看着一堆测试任务,只能又跑去开发环境上测!虽然内心安慰自己,好歹学到了一些东西,但还是不禁反思,为什么不在一开始遇到复杂问题的时候就跑去开发环境上测,这样可以节省很多时间去做其他事情!!

没在开发环境上测试的原因

我分析了一下,没在开发环境上测试的原因主要有几点:
1、就是上面提到的,现在项目没以前那么忙了,想把测试环境的数据库和 redis 都用起来
2、测试环境上部署了统计代码覆盖率的服务,觉得这个是测试服务,不应该部署在开发环境上
3、觉得环境运维也是测试必备的一项技能吧
4、开发环境毕竟是开发的,不好意思在上面随便倒腾,有测试环境的话就可以随便倒腾了
4、心里总觉得测试环境跟开发环境就应该分开,这样就可以在测试环境上随便折腾了……

让开发在测试环境上进行冒烟自测,可好?

正好今天下午我们测试组开了个 “促进开发自测 “” 的讨论会,会上提到了可以让开会在测试环境上进行冒烟自测的想法,引起大家的一致认同,大家纷纷说自己在项目测试中经常因为环境、配置等问题,花费很多的时间。我由于今天一天的踩坑经历,对这个想法也是不能更认同!

确实每次提测,多多少少都会有各种环境、配置导致的问题,虽然能增加测试人员对环境、配置项的了解,但是还是感觉有时候这个时间的花费性价比不是很高。

让开发在测试环境上自测,可以减少很多因为配置的问题导致的时间开销,能够让我们把时间更多地花在测试上,但是这样的话开发需要运维两套环境,势必会增加他们的工作量,不知道大家在项目测试过程中,是否经常遇到开发、测试环境配置不一致导致的问题?遇到的话又是怎么来解决的?

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 24 条回复 时间 点赞
恒温 回复

测试在开发环境上做测试的话,是不是也可以啊?

恒温 回复

环境问题是阻碍生产力最大的坑,这点真的是深有同感,不知道在这方面前辈有没有什么经验可以传授一下!!

小敏 回复

解决不了。。

深有同感,我就是经常因为各种环境配置的问题一路踩坑,这么被坑过来的😂 😂 😂 ~~~

Karen 回复

是啊是啊,感觉后面要尽量控制一下花在环境上的时间,尽量找一些替代的方法,不能耽搁了正常工作 😅 😅 😅

看开点吧。。。填坑多了,就不是坑了。。。
领导会跟开发说 XXX 你去把测试环境配一下么?你找他们能帮你看看问题,真能解决问题就感谢吧。。。
” 正好今天下午我们测试组开了个 “促进开发自测 “” 的讨论会,会上提到了可以让开发在测试环境上进行冒烟自测的想法 “
这个有执行的可能性么?。。。哎,都是套路。。。
个人觉得测试运维融合是趋势,多配点环境也没什么坏处。

我理解 qa 在测试环境上部署一次也是对发布步骤的一个梳理,如果只是开发边开发边改环境配置,不能保证上线步骤不出纰漏

嘎哈 回复

恩,环境运维能力是 qa 的必备能力之一,但如果经常出现因为开发、测试环境配置问题导致的各种问题,花费的时间成本就太大了~~~

小敏 #10 · 2017年08月14日 Author
magicyang 回复

目前有一些项目在尝试,如果能跟开发磨合得好,能实现的话,还是能节省不少时间~~~

关键是,你觉得在开发环境冒烟有什么不可以的呢?除了死规范?

小敏 #12 · 2017年08月14日 Author
槽神 回复

就是文章里说的痛点,开发不能及时跟测试同步配置的修改,导致测试和开发环境的配置经常不一致,常常花费很多时间去分析错误原因!

稳定运行了快 1 年的系统,到目前为止,新人进入首次在测试环境走流程,还是需要几乎整整两天的时间还不能完全走完,测试服务各种报错,知道只是一种怎么样的体验嘛。。。😹

小敏 #14 · 2017年08月14日 Author
shadow 回复

非常能够理解!!前期的环境的踩坑就当是给自己增添技能吧~~~

小敏 回复

冒烟测试,就不要想着 e2e 全部测完了,挑重点独立测,测接口验后端等,配置没那么突出的重要吧

小敏 回复

我觉得不可以啊,有些配置啊,数据库表,脚本啊,开发随便改了你都不知道(或者忘记告诉你了),到时候上线就会发现少这个配置,少这个脚本等等,前面不把问题解决掉,集中到后面到上线就会爆发出各种问题,所以我觉得最好测试和开发环境分离,提测的时候将所有的脚本、数据库、配置都完整的提供,最好从流程上来保证不发生这些问题。
最后总结一句,环境问题其实归根结底还是流程问题,这是我比较大的体悟。😀 另外楼主可以试试使用 docker

小敏 #17 · 2017年08月16日 Author
回复

确实是流程问题,后面要督促开发,每次的配置变更需要详细记录下来,这样测试才能少踩一些坑!
我们环境基本上都用的 docker,还是很方便哒~~

尽快使用容器吧,加上配置管理,解决各种环境问题。

超级大坑好不好

让开发在测试环境上完成冒烟测试,通过后再提测。测试人员再执行一轮冒烟测试,以冒烟测试对接,保证开发确实执行了冒烟才让提测。

我们这边的解决方案,去年大会上讲的 warship:http://m.imooc.com/video/12550

小敏 #22 · 2017年08月30日 Author
terrychow 回复

感谢感谢!

小敏 #23 · 2017年08月30日 Author
果冻 回复

我们测试环境都是用 docker,但配置管理还有待完善~~

看起来是为了提高效率,紧密配合,实际上是偷懒。
这个环境还干别的用吗?如果不干别的,那就相当于只给开发用,如果环境配置什么的都有数的话,比没有强吧。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册