本篇是針對今天一篇部落格的回答。原內容如下：
我本來是直接寫的回覆的，但是越寫越多，故記錄（部分黏貼）如下。
頻繁變動的原因1：
需求是源頭，專案變動的原因就是需求不明確，又或者是需求改動頻繁，那為什麼會出現這樣的問題？出現這樣的問題大多都是開發人員對需求把控不夠，剛開始計畫是只改動一點點，也有可能是覺得自己的**不改，兄弟方修改就行，後面等到測試過程中，測試人員提出bug，發現需要修改**，而且修改的範圍還很大。
討論方案：
其實出現這樣的問題本質上來說是因為沒有遵循測試應該盡早介入的原則。恕我直言，上述這種討論方案是沒有什麼可執行性的，屬於白討論了。應對之策：測試人員在接到專案時，先不急於開展測試工作，可以先與相對應的需求人員和開發人員溝通，可以從先從業務流程方面與需求人員、開發人員溝通，同時知曉開發人員修改思路，**設計結構等
但這個方法對測試人員要求極高，需要測試人員熟悉業務、熟悉場景設計、業務流程等，同時還需求測試人員對**有一定的了解，如果討論之前就知道整個**的設計框架會特別有幫助。
如果你能力夠，那頻繁改動**帶來的加班，你就不會遇到了。
如果你能力不夠，那能達到上面這種「要求極高」的程度，在客觀上就是不可能的，主觀上是沒有必要的。
對2的解釋：
開發量的評估是開發的活，測試沒有精力又當爹又當媽，又看開發**又精通業務又寫測試用例。這不是要求極高的事情，這是不合理的事情。你又看**又懂業務又寫測試用例，那你拿開發+產品經理+測試的工資嗎？你這不是高標準要求自己，你這屬於吃力不討好甚至就是浪費時間。
開發覺得你越權，我的**為什麼需要你review，再說開發的**誰給你的許可權去看的？再說好幾個開發的**你乙個人看，你幹了tl的活，那tl對你能有好眼色嗎，你拿tl的工資嗎？一直發現實錘問題還好說明你偉光大，如果一旦你誤報錯誤，威信會直線下降，開發一句「我除了正常開發還得給你個測試講**，你理解的還不對，你們測試真的沒事幹了嗎？」是啊，你個測試不誤正業啊。人家給你講**屬於幫你學習，而你測試的工作是挑**毛病指導開發改正，你這不是矛盾了嗎？再說開發的**那麼簡單嗎？吃力不討好。
產品經理覺得你在搞笑。產品經理從銷售運營等拿過來的需求，和人家都認真討論完了，然後你給挑毛病，不是扯呢嗎？你和銷售運營聊過了？你了解需求**嗎就開噴，還提意見，人家可能聽你的嗎？你知道這個按鈕是幹嘛的嗎就噴？還是那句，你屬於和產品經理學習的，然後你給挑毛病，矛盾啊！
說到架構就更不可能了，現在網際網路技術架構其實就那麼幾個，開發的就那麼幾個，你說要改，那你考慮到成本了嗎？你拿架構師的錢了？
我認為的應對之策：做自動化測試用例，宗旨是測試做好測試的分內之事。
首先系統是可以分層的，一般是介面測試（黑盒/白盒）——功能測試。而這兩類都可以做自動化。
介面測試的自動化做好了，分享給開發，開發拿過去就自測了，省了你一大堆時間，版本發布之前就能暴露一堆一堆的問題，包括邊界問題。就算是他沒有自測，你的測試也會節省很多時間，加班就他自己加了，他拿著你的用例就可以自己搞了。
頻繁變動的原因2：
因為是緊急上線的專案，測試時間都很短，那麼測試人員需要把大量的時間花測試功能上面，而不是將時間浪費在環境上面。在專案中遇到這樣一種情況：
當開發人員轉測的當天，測試人員和開發人員當天都會花費很多時間在除錯環境上面。測試環境和開發環境是相對獨立的環境，這也導致了有些配置不同的地方，開發人員在轉測郵件中需要明確列清本次專案需要修改的配置，那麼測試人員在配置環境的時候才能配置完善。
如果前面都做很好，那可以避免環境的bug，但由於某些原因，測試人員在測試過程中還是會遇到一些環境bug。
測試人員在測試過程中遇到bug時，
第一，先去看bug日誌；
第二，根據bug日誌定位bug錯誤的原因，是環境問題還是編碼問題，又或者其它問題；
第三，根據分析的結果，能解決的問題盡量自己解決，比如是操作不當某個配置未配；
第四，如果是編碼問題，則反饋給開發人員，提交bug，如果測試人員能定位出是什麼原因的導致的更好
討論方案：
在這裡並不提倡遇到某些bug，測試人員不懂，但使勁鑽研，這樣反而會影響效率，主要是解決環境類，介面類，因配置或操作而引起的非bug問題。這裡沒啥大問題，環境是運維+開發的事，再向後才是測試的事，當然測試環境測試需要負責也沒啥說的。同時不提倡測試人中一遇到bug不看不管，直接扔給開發人員解決，建議看bug日誌，分析bug出現的原因，以便下次遇到類似bug。
建議還是在測試之前就寫自動化用例，到時候手指點一點就ok了。
如果總出現比較大的環境崩潰問題，建議專門寫一套通用的自動化驗證環境用例，每次部署環境之後就執行一遍，也可以交給開發共用，這樣又省去了浪費測試的時間。
bug日誌測試是一定要看的，這對開發測試都有好處，遇到一些比較明顯的腦殘異常，及時指出，幾次之後開發自己就看了，畢竟影響他績效，幾次不說，開發還會感謝你。
軟體測試人員如何測試需求頻繁變動的專案
王豆豆最近一直在加班，天天都加班到九點多，專案大多是緊急上線，但其實每天的工作量並不算多，按理說應該在上班時間就能完成，但每天到了下班時間卻走不了，不得不留下來繼續做。留下來加班的原因無非二種 1，專案需要上線 2，測試任務沒有完成 測試任務沒有完成的情況比較少，常態是每天臨近下班的時候，開發要不就...
如何考核測試人員？
csdn論壇上，有人問如何考核測試人員，我回了幾個帖子，下面就是我回帖的內容，可以代表我對此事的一些看法。一 測試人員的工作評價比較的難辦，因為測試人員沒有具體的工作產品產出。測試人員一般做的也就是測試用例的編寫和測試缺陷的提交。而這些可以說都不是看技術，而且看職業道德。所以我更多的認為，測試人員最...
測試人員如何制定測試策略呢？
測試相較於其他工作的核心競爭力是什麼？在回答這個問題之前，想一下每個工作崗位的核心競爭力又是什麼呢？是不是可以遷移的呢？眾所周知，測試一向用來與開發作比較，那麼開發的核心競爭力是什麼呢？真的是開發能力嗎？如果是的話，為什麼很多具有豐富開發經驗的中年開發人員會面臨著中年危機呢？從這個角度看，開發的核心...