王豆豆最近一直在加班，天天都加班到九点多，项目大多是紧急上线，但其实每天的工作量并不算多，按理说应该在上班时间就能完成，但每天到了下班时间却走不了，不得不留下来继续做。
留下来加班的原因无非二种：1，项目需要上线；2，测试任务没有完成
测试任务没有完成的情况比较少，常态是每天临近下班的时候，开发要不就在这个时候转测，要不就是临时有一个小功能修改完要上线，又或者是紧急安排了一个需求会议，又或者是联测等。
什么是紧急项目呢？
紧急项目是那类上线时间很紧急的项目，比如今天转测，就要求今天或明天就能上线的项目，这类项目就是属于紧急上线的项目，这类项目有一个特点就是需求不明确；测试时间短。
测试人员基本都是临到转测时，才知道有这样一个测试需求，但又因为从接到这个类测试任务之时到上线的时间间隔都很短。
正是因为该类项目的特点，这类项目测试结果没有保障，基本都是测试完主要流程，就匆匆上线了。还有一类项目是这类项目的加强版，是紧急项目的同时需求不断变动。
王豆豆最近做了几个这类的项目，从接到项目的同时才知道测试功能和上线时间。
接到这类项目基本不会编写测试计划，测试用例等文档，接到项目就开始理解需求，与开发沟通改动范围和测试范围，然后开始测试，如果是运气比较好的时候，还没开始测试就能发现以前的结构设计不对，需要改；运气不好的时候，基本都已经测试完成了，才发现需求设计不对，需要重新修改。
有时改动范围不大，可能是表的数据修改了几个字段，有时改动范围大，是整体的流程都有所变化。
对于测试人员来说根本没有什么改动范围不大之说，就是只改了表的几个存储字段值，也需要回归以前所有的功能。
如果你觉得上面的项目已经很难了，那还有更倒霉的，测试人员明明是加班加点测试出来的项目，临到上线的却说此功能或者此版本不上了，当然这些对测试人员来说都是常态。
正是因为这些事情在无形之中给测试人员增加测试时间，增加测试难度，导致测试人员对自己测试的结果不放心。
那如果是你碰到这类项目，应该会怎么做呢？欢迎大家留言探讨。
下面王豆豆针对做完这几个的项目后与组内成员讨论之后的应对之策：
需求
需求是源头，项目变动的原因就是需求不明确，又或者是需求改动频繁，那为什么会出现这样的问题？
出现这样的问题大多都是开发人员对需求把控不够，刚开始计划是只改动一点点，也有可能是觉得自己的代码不改，兄弟方修改就行，后面等到测试过程中，测试人员提出BUG，发现需要修改代码，而且修改的范围还很大。
其实出现这样的问题本质上来说是因为没有遵循测试应该尽早介入的原则。
应对之策：测试人员在接到项目时，先不急于开展测试工作，可以先与相对应的需求人员和开发人员沟通，可以从先从业务流程方面与需求人员、开发人员沟通，同时知晓开发人员修改思路，代码设计结构等
这不仅是测试人员在了解需求，同时也能起开发人员反思自己的代码设计，如果是设计方面的问题，大多能在此时发现，不会出现测试到一半时才发现，浪费了测试时间。
但这个方法对测试人员要求极高，需要测试人员熟悉业务、熟悉场景设计、业务流程等，同时还需求测试人员对代码有一定的了解，如果讨论之前就知道整个代码的设计框架会特别有帮助。
bug定位与分析
因为是紧急上线的项目，测试时间都很短，那么测试人员需要把大量的时间花测试功能上面，而不是将时间浪费在环境上面。
在项目中遇到这样一种情况：
当开发人员转测的当天，测试人员和开发人员当天都会花费很多时间在调试环境上面。测试环境和开发环境是相对独立的环境，这也导致了有些配置不同的地方，开发人员在转测邮件中需要明确列清本次项目需要修改的配置，那么测试人员在配置环境的时候才能配置完善。
如果前面都做很好，那可以避免环境的bug，但由于某些原因，测试人员在测试过程中还是会遇到一些环境bug。
测试人员在测试过程中遇到BUG时，
第一，先去看BUG日志；
第二，根据BUG日志定位BUG错误的原因，是环境问题还是编码问题，又或者其它问题；
第三，根据分析的结果，能解决的问题尽量自己解决，比如是操作不当某个配置未配；
第四，如果是编码问题，则反馈给开发人员，提交bug，如果测试人员能定位出是什么原因的导致的更好
在这里并不提倡遇到某些bug，测试人员不懂，但使劲钻研，这样反而会影响效率，主要是解决环境类，接口类，因配置或操作而引起的非bug问题。
同时不提倡测试人中一遇到bug不看不管，直接扔给开发人员解决，建议看bug日志，分析bug出现的原因，以便下次遇到类似bug。
下面是王豆豆与群里小伙伴们一起讨论需求变动频繁，各自的所面临的困难与解决方案：
欢迎关注微信公众号：资深Tester，了解更多的测试好文。。。