現在在測試行業，對測試人員來講，最受困擾的問題之一就是測試的設計工作都做完了，結果需求又發生了變化，原來做的很多工作不得不重新開展，一方面測試的進度受到了影響，另一方面，也讓測試人員身心疲憊。我們是否分析過：這種現象產生的原因是什么？面對這樣的風險，我們采取怎樣的策略來應對，從而最好完成測試任務？歡迎大家討論交流！
回答：
我現在也是常為需要變更感覺頭疼。
1、需求變更后，首先要向需求人員及開發人員了解，為什么需求要做變更，了解客戶真正的需求。
2、其次，向開發人員了解本次需求變更，都改卻了哪些模塊。會影響到哪些模塊。
3、詢問開發進度
4、整理測試計劃及測試用例，確認哪些模塊應該重點測試。
5、展開下一步的測試工作。并確定測試時間。
6、通過本次需求變更，測試人員要總結經驗，盡量站在客戶的角度進行測試。在客戶沒有發現不能滿足需求時，測試人員先提出來。當然，需求人員及開發人員也要從中吸取教訓。
我相信，如果每一次都能從需求變更中吸取教訓，相信以后開發及測試出來的軟件質量會更好的。
回答：
這是一個常見的令人頭疼的問題。
如果可能，盡早與承擔該項目風險的人接觸，以便了解需求會怎樣改變，從而可以盡早地改變測試計劃和策略。
如果在對應用程序進行初始設計時多考慮一些適應性，那么以后在發生需求的改變時，就不需要再為改變做很多事情了。
好的代碼注釋和好的文檔有助于開發人員作出相應的改變。
只要有可能，就應使用快速原型 (rapid prototyping)，以幫助用戶確認他們的需求，從而減少變更。
在項目的時間表中應當留出余量，以應付可能出現的變更。
盡量把新的需求納入應用軟件的“下一版”，而把原始需求作為“第一版”。
通過談判，把易于實現的新的變更列入項目，而把難于實現的新需求列入該應用軟件的以后的版本。
要確保讓客戶和管理人員了解變更對進度表的影響、所帶來的風險、以及因變更所引起的大量資金消耗。
在應付改變時，應在為建立自動測試而作的努力和重新進行測試所做的努力之間取得平衡。
在設計自動測試劇本時，試圖使其有一些靈活性。
在對應用軟件進行自動測試時，要把注意力集中在看來不大會改變的部分。
對變更進行適當的風險分析，以減少回歸測試的要求。
在設計測試案例時要有一定的靈活性。做到這一點并不容易，所以要降低測試案例的詳細程度，或者只建立高級的通用型的測試計劃。
少注意詳細的測試計劃和測試案例，要把重點放在專門的測試 (ad hoc testing) 上。
PS
需求變更測試人員應怎樣進行有效的處理
每個公司，甚至每個項目都有可能有不同的方式來處理這個問題。
對于測試人員來說，最為重要的一點其實就是心理的適度調整。
誠然，需求的變更導致自己的很多工作都成了無用功，很多東西要從頭做起。
但是一定不要抱怨，因為那樣解決不了問題，事實就是事實。已經無法更改。需求方開發方任何一個都希望項目從立項一開始就按部就班的做下去，不會有任何的變化。沒有人喜歡需求的變化，但是計劃總是沒有變化快的。所以首先要調整的就是心態。要有積極地心態，全新的去面對新的需求。分析，設計，一切重來。
文章來源于領測軟件測試網 http://www.kjueaiud.com/