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

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

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

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

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

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

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

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

思路特别赞，我也要去学习实践一下。
之前写过自动化测试用例，也持续集成过，自动化用例良好的维护性确实特别重要，不然一旦换人接手项目，很快就会被搁置。要设计维护性很高的自动化测试代码，对测试人员自身的要求也挺高的！！

文中的思路应该是把真实数据拷下来，用作 mock 数据吧？不需要自己进行加解密吧？

都是杭研哒，大侠是游戏部门的，所以可能没太接触过

建议提早准备简历，然后去大公司面试面试，就算面不上，但在面试过程中可以找到自身的不足点，然后在工作中进行有针对性地锻炼。

还是建议去大公司工作一下，体验一下相对来说比较正规的工作流程，而且身边优秀的同事会让你无形中学到很多很多东西。

我在做的项目中也有涉及支付环节，支付宝的支付流程应该是和 APPLE, GOOGLE 一样的逻辑。
但我们在异常测试时只覆盖了 “验证支付结果有效性” 时服务不可用的情况，没有考虑到 “支付成功的收据多次回调” 这些情况。
我当时测试时，是用支付宝真实支付的，开发将测试环境的商品价格都改成很低。当时的思路是直接 mock 支付宝回调的数据，但因为数据加解密流程太复杂，放弃了。没有想到文中对第三方支付进行整体 mock 的方法。
感谢分享，下次可以借鉴文中的做法 。

mock 在服务端测试中还是蛮常用到的，可以模拟接口的返回值

不同项目情况不同吧，我之前负责的项目人比较少，一般远程 debug 之前在群里跟其他同事说一声就好，同时需要使用环境的情况比较少

倪子分析得透彻！

如果出现的问题只在特定环境出现时必须用远程调试（如某问题在测试环境必现，但在开发环境 ok），一般情况下在本地直接调试也是可以的，但还需要本地起 tomcat 服务，相对来说会比较麻烦一些。

每个主管风格确实会有所不同，在保证工作效率的基础上，抽出一定量时间学习，对工作也会有很好的促进作用的

嗯，继续努力

偶遇倪子

楼主的经历也是我所期盼的，应该要多像你学习，多思考。

嗯，多总结，让路走得更清晰一些。

不好意思，之前一直没看到。微信：songyamins