本篇是针对今天一篇博客的回答。原内容如下：
我本来是直接写的回复的，但是越写越多，故记录（部分黏贴）如下。
频繁变动的原因1：
需求是源头，项目变动的原因就是需求不明确，又或者是需求改动频繁，那为什么会出现这样的问题？出现这样的问题大多都是开发人员对需求把控不够，刚开始计划是只改动一点点，也有可能是觉得自己的代码不改，兄弟方修改就行，后面等到测试过程中，测试人员提出BUG，发现需要修改代码，而且修改的范围还很大。
讨论方案：
其实出现这样的问题本质上来说是因为没有遵循测试应该尽早介入的原则。应对之策：测试人员在接到项目时，先不急于开展测试工作，可以先与相对应的需求人员和开发人员沟通，可以从先从业务流程方面与需求人员、开发人员沟通，同时知晓开发人员修改思路，代码设计结构等但这个方法对测试人员要求极高，需要测试人员熟悉业务、熟悉场景设计、业务流程等，同时还需求测试人员对代码有一定的了解，如果讨论之前就知道整个代码的设计框架会特别有帮助。
恕我直言，上述这种讨论方案是没有什么可执行性的，属于白讨论了。
- 如果你能力够，那频繁改动代码带来的加班，你就不会遇到了。
- 如果你能力不够，那能达到上面这种“要求极高”的程度，在客观上就是不可能的，主观上是没有必要的。
对2的解释：
- 开发量的评估是开发的活，测试没有精力又当爹又当妈，又看开发代码又精通业务又写测试用例。这不是要求极高的事情，这是不合理的事情。你又看代码又懂业务又写测试用例，那你拿开发+产品经理+测试的工资吗？你这不是高标准要求自己，你这属于吃力不讨好甚至就是浪费时间。
- 开发觉得你越权，我的代码为什么需要你review，再说开发的代码谁给你的权限去看的？再说好几个开发的代码你一个人看，你干了TL的活，那TL对你能有好眼色吗，你拿TL的工资吗？一直发现实锤问题还好说明你伟光大，如果一旦你误报错误，威信会直线下降，开发一句“我除了正常开发还得给你个测试讲代码，你理解的还不对，你们测试真的没事干了吗？”是啊，你个测试不误正业啊。人家给你讲代码属于帮你学习，而你测试的工作是挑代码毛病指导开发改正，你这不是矛盾了吗？再说开发的代码那么简单吗？吃力不讨好。
- 产品经理觉得你在搞笑。产品经理从销售运营等拿过来的需求，和人家都认真讨论完了，然后你给挑毛病，不是扯呢吗？你和销售运营聊过了？你了解需求来源吗就开喷，还提意见，人家可能听你的吗？你知道这个按钮是干嘛的吗就喷？还是那句，你属于和产品经理学习的，然后你给挑毛病，矛盾啊！
- 说到架构就更不可能了，现在互联网技术架构其实就那么几个，开发的就那么几个，你说要改，那你考虑到成本了吗？你拿架构师的钱了？
我认为的应对之策：做自动化测试用例，宗旨是测试做好测试的分内之事。
- 首先系统是可以分层的，一般是接口测试（黑盒/白盒）——功能测试。而这两类都可以做自动化。
- 接口测试的自动化做好了，分享给开发，开发拿过去就自测了，省了你一大堆时间，版本发布之前就能暴露一堆一堆的问题，包括边界问题。就算是他没有自测，你的测试也会节省很多时间，加班就他自己加了，他拿着你的用例就可以自己搞了。
- 功能测试的自动化一般是比较扯的，尤其牵扯到APP的自动化。这也就是说测试人员学python的源动力，会python才能写好这部分自动化测试用例。多数是不如手指点点点的。测试自身对代码的学习应该从这里开始，而不是从看开发的代码开始。
频繁变动的原因2：
因为是紧急上线的项目，测试时间都很短，那么测试人员需要把大量的时间花测试功能上面，而不是将时间浪费在环境上面。在项目中遇到这样一种情况：当开发人员转测的当天，测试人员和开发人员当天都会花费很多时间在调试环境上面。测试环境和开发环境是相对独立的环境，这也导致了有些配置不同的地方，开发人员在转测邮件中需要明确列清本次项目需要修改的配置，那么测试人员在配置环境的时候才能配置完善。如果前面都做很好，那可以避免环境的bug，但由于某些原因，测试人员在测试过程中还是会遇到一些环境bug。测试人员在测试过程中遇到BUG时，第一，先去看BUG日志；第二，根据BUG日志定位BUG错误的原因，是环境问题还是编码问题，又或者其它问题；第三，根据分析的结果，能解决的问题尽量自己解决，比如是操作不当某个配置未配；第四，如果是编码问题，则反馈给开发人员，提交bug，如果测试人员能定位出是什么原因的导致的更好
讨论方案：
在这里并不提倡遇到某些bug，测试人员不懂，但使劲钻研，这样反而会影响效率，主要是解决环境类，接口类，因配置或操作而引起的非bug问题。同时不提倡测试人中一遇到bug不看不管，直接扔给开发人员解决，建议看bug日志，分析bug出现的原因，以便下次遇到类似bug。
这里没啥大问题，环境是运维+开发的事，再向后才是测试的事，当然测试环境测试需要负责也没啥说的。
建议还是在测试之前就写自动化用例，到时候手指点一点就OK了。
如果总出现比较大的环境崩溃问题，建议专门写一套通用的自动化验证环境用例，每次部署环境之后就执行一遍，也可以交给开发共用，这样又省去了浪费测试的时间。
bug日志测试是一定要看的，这对开发测试都有好处，遇到一些比较明显的脑残异常，及时指出，几次之后开发自己就看了，毕竟影响他绩效，几次不说，开发还会感谢你。
配置可以改成在线配置，在线更改，不用重启环境，让开发去研究去。