軟體測試人員如何測試需求頻繁變動的專案

王豆豆最近一直在加班，天天都加班到九點多，專案大多是緊急上線，但其實每天的工作量並不算多，按理說應該在上班時間就能完成，但每天到了下班時間卻走不了，不得不留下來繼續做。

留下來加班的原因無非二種：1，專案需要上線；2，測試任務沒有完成

測試任務沒有完成的情況比較少，常態是每天臨近下班的時候，開發要不就在這個時候轉測，要不就是臨時有乙個小功能修改完要上線，又或者是緊急安排了乙個需求會議，又或者是聯測等。

什麼是緊急專案呢？

緊急專案是那類上線時間很緊急的專案，比如今天轉測，就要求今天或明天就能上線的專案，這類專案就是屬於緊急上線的專案，這類專案有乙個特點就是需求不明確；測試時間短。

測試人員基本都是臨到轉測時，才知道有這樣乙個測試需求，但又因為從接到這個類測試任務之時到上線的時間間隔都很短。

正是因為該類專案的特點，這類專案測試結果沒有保障，基本都是測試完主要流程，就匆匆上線了。還有一類專案是這類專案的加強版，是緊急專案的同時需求不斷變動。

王豆豆最近做了幾個這類的專案，從接到專案的同時才知道測試功能和上線時間。

接到這類專案基本不會編寫測試計畫，測試用例等文件，接到專案就開始理解需求，與開發溝通改動範圍和測試範圍，然後開始測試，如果是運氣比較好的時候，還沒開始測試就能發現以前的結構設計不對，需要改；運氣不好的時候，基本都已經測試完成了，才發現需求設計不對，需要重新修改。

有時改動範圍不大，可能是表的資料修改了幾個字段，有時改動範圍大，是整體的流程都有所變化。

對於測試人員來說根本沒有什麼改動範圍不大之說，就是只改了表的幾個儲存字段值，也需要回歸以前所有的功能。

如果你覺得上面的專案已經很難了，那還有更倒霉的，測試人員明明是加班加點測試出來的專案，臨到上線的卻說此功能或者此版本不上了，當然這些對測試人員來說都是常態。

正是因為這些事情在無形之中給測試人員增加測試時間，增加測試難度，導致測試人員對自己測試的結果不放心。

下面王豆豆針對做完這幾個的專案後與組內成員討論之後的應對之策：

需求是源頭，專案變動的原因就是需求不明確，又或者是需求改動頻繁，那為什麼會出現這樣的問題？

出現這樣的問題大多都是開發人員對需求把控不夠，剛開始計畫是只改動一點點，也有可能是覺得自己的**不改，兄弟方修改就行，後面等到測試過程中，測試人員提出bug，發現需要修改**，而且修改的範圍還很大。

其實出現這樣的問題本質上來說是因為沒有遵循測試應該盡早介入的原則。

應對之策：測試人員在接到專案時，先不急於開展測試工作，可以先與相對應的需求人員和開發人員溝通，可以從先從業務流程方面與需求人員、開發人員溝通，同時知曉開發人員修改思路，**設計結構等

這不僅是測試人員在了解需求，同時也能起開發人員反思自己的**設計，如果是設計方面的問題，大多能在此時發現，不會出現測試到一半時才發現，浪費了測試時間。

但這個方法對測試人員要求極高，需要測試人員熟悉業務、熟悉場景設計、業務流程等，同時還需求測試人員對**有一定的了解，如果討論之前就知道整個**的設計框架會特別有幫助。

因為是緊急上線的專案，測試時間都很短，那麼測試人員需要把大量的時間花測試功能上面，而不是將時間浪費在環境上面。

在專案中遇到這樣一種情況：

當開發人員轉測的當天，測試人員和開發人員當天都會花費很多時間在除錯環境上面。測試環境和開發環境是相對獨立的環境，這也導致了有些配置不同的地方，開發人員在轉測郵件中需要明確列清本次專案需要修改的配置，那麼測試人員在配置環境的時候才能配置完善。

如果前面都做很好，那可以避免環境的bug，但由於某些原因，測試人員在測試過程中還是會遇到一些環境bug。

測試人員在測試過程中遇到bug時，

第一，先去看bug日誌；

第二，根據bug日誌定位bug錯誤的原因，是環境問題還是編碼問題，又或者其它問題；

第三，根據分析的結果，能解決的問題盡量自己解決，比如是操作不當某個配置未配；

第四，如果是編碼問題，則反饋給開發人員，提交bug，如果測試人員能定位出是什麼原因的導致的更好

在這裡並不提倡遇到某些bug，測試人員不懂，但使勁鑽研，這樣反而會影響效率，主要是解決環境類，介面類，因配置或操作而引起的非bug問題。

同時不提倡測試人中一遇到bug不看不管，直接扔給開發人員解決，建議看bug日誌，分析bug出現的原因，以便下次遇到類似bug。

下面是王豆豆與群裡小夥伴們一起討論需求變動頻繁，各自的所面臨的困難與解決方案：