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

八戒你干嘛

本来打算今天把项目提测的任务测完，结果基本一天都在搞测试环境，加班还在搞环境，最后不得不先放弃，直接在开发环境上测试，真的是心塞塞!
缘起

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

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

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

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

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

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

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

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

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

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

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

草帽路飞UU

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

草帽路飞UU

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