王豆豆最近一直在加班，天天都加班到九點多，項目大多是緊急上線，但其實每天的工作量並不算多，按理說應該在上班時間就能完成，但每天到了下班時間卻走不了，不得不留下來繼續做。
留下來加班的原因無非二種：1，項目需要上線；2，測試任務沒有完成
測試任務沒有完成的情況比較少，常態是每天臨近下班的時候，開發要不就在這個時候轉測，要不就是臨時有一個小功能修改完要上線，又或者是緊急安排了一個需求會議，又或者是聯測等。
什么是緊急項目呢？
緊急項目是那類上線時間很緊急的項目，比如今天轉測，就要求今天或明天就能上線的項目，這類項目就是屬於緊急上線的項目，這類項目有一個特點就是需求不明確；測試時間短。
測試人員基本都是臨到轉測時，才知道有這樣一個測試需求，但又因為從接到這個類測試任務之時到上線的時間間隔都很短。
正是因為該類項目的特點，這類項目測試結果沒有保障，基本都是測試完主要流程，就匆匆上線了。還有一類項目是這類項目的加強版，是緊急項目的同時需求不斷變動。
王豆豆最近做了幾個這類的項目，從接到項目的同時才知道測試功能和上線時間。
接到這類項目基本不會編寫測試計划，測試用例等文檔，接到項目就開始理解需求，與開發溝通改動范圍和測試范圍，然后開始測試，如果是運氣比較好的時候，還沒開始測試就能發現以前的結構設計不對，需要改；運氣不好的時候，基本都已經測試完成了，才發現需求設計不對，需要重新修改。
有時改動范圍不大，可能是表的數據修改了幾個字段，有時改動范圍大，是整體的流程都有所變化。
對於測試人員來說根本沒有什么改動范圍不大之說，就是只改了表的幾個存儲字段值，也需要回歸以前所有的功能。
如果你覺得上面的項目已經很難了，那還有更倒霉的，測試人員明明是加班加點測試出來的項目，臨到上線的卻說此功能或者此版本不上了，當然這些對測試人員來說都是常態。
正是因為這些事情在無形之中給測試人員增加測試時間，增加測試難度，導致測試人員對自己測試的結果不放心。
那如果是你碰到這類項目，應該會怎么做呢？歡迎大家留言探討。
下面王豆豆針對做完這幾個的項目后與組內成員討論之后的應對之策：
需求
需求是源頭，項目變動的原因就是需求不明確，又或者是需求改動頻繁，那為什么會出現這樣的問題？
出現這樣的問題大多都是開發人員對需求把控不夠，剛開始計划是只改動一點點，也有可能是覺得自己的代碼不改，兄弟方修改就行，后面等到測試過程中，測試人員提出BUG，發現需要修改代碼，而且修改的范圍還很大。
其實出現這樣的問題本質上來說是因為沒有遵循測試應該盡早介入的原則。
應對之策：測試人員在接到項目時，先不急於開展測試工作，可以先與相對應的需求人員和開發人員溝通，可以從先從業務流程方面與需求人員、開發人員溝通，同時知曉開發人員修改思路，代碼設計結構等
這不僅是測試人員在了解需求，同時也能起開發人員反思自己的代碼設計，如果是設計方面的問題，大多能在此時發現，不會出現測試到一半時才發現，浪費了測試時間。
但這個方法對測試人員要求極高，需要測試人員熟悉業務、熟悉場景設計、業務流程等，同時還需求測試人員對代碼有一定的了解，如果討論之前就知道整個代碼的設計框架會特別有幫助。
bug定位與分析
因為是緊急上線的項目，測試時間都很短，那么測試人員需要把大量的時間花測試功能上面，而不是將時間浪費在環境上面。
在項目中遇到這樣一種情況：
當開發人員轉測的當天，測試人員和開發人員當天都會花費很多時間在調試環境上面。測試環境和開發環境是相對獨立的環境，這也導致了有些配置不同的地方，開發人員在轉測郵件中需要明確列清本次項目需要修改的配置，那么測試人員在配置環境的時候才能配置完善。
如果前面都做很好，那可以避免環境的bug，但由於某些原因，測試人員在測試過程中還是會遇到一些環境bug。
測試人員在測試過程中遇到BUG時，
第一，先去看BUG日志；
第二，根據BUG日志定位BUG錯誤的原因，是環境問題還是編碼問題，又或者其它問題；
第三，根據分析的結果，能解決的問題盡量自己解決，比如是操作不當某個配置未配；
第四，如果是編碼問題，則反饋給開發人員，提交bug，如果測試人員能定位出是什么原因的導致的更好
在這里並不提倡遇到某些bug，測試人員不懂，但使勁鑽研，這樣反而會影響效率，主要是解決環境類，接口類，因配置或操作而引起的非bug問題。
同時不提倡測試人中一遇到bug不看不管，直接扔給開發人員解決，建議看bug日志，分析bug出現的原因，以便下次遇到類似bug。
下面是王豆豆與群里小伙伴們一起討論需求變動頻繁，各自的所面臨的困難與解決方案：
歡迎關注微信公眾號：資深Tester，了解更多的測試好文。。。