[ 你說我說 ] 如何應對轉測試以后的需求變更？

MILY: 宋體; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; mso-bidi-font-family: Arial; mso-font-kerning: 0pt">上文提到的測試執行分層是Waterfall開發模式的典型測試模式，這個模型很完美，但它是基于這樣一個重要的假設：項目的需求變化不多或者說需求很穩定。產品由開發轉測試后，當需求更改較多或者新需求不斷涌現的時候，很多問題也隨之而來，尤其對于大型的項目而言，問題較為突出，解決辦法可絕不是紙上談兵那么簡單。

問題主要表現為：

1）            需求的變化，測試人員不知曉；

2）            測試人員知曉需求變化的時間滯后，例如在回歸問題單時才知道；

3）            由于版本間歇期短，測試沒有人力和時間投入對新增修改需求的測試分析和設計上，基本上很難像對待老需求一樣，開展詳細的測試分析設計；

4）            對變化需求與老特性的交互上分析不夠或者根本沒有展開繼承性分析；

5）            新增修改需求打亂了原有的測試規劃，甚至包括對測試特性的劃分原則，相應的測試結果分析、測試需求跟蹤等都不到位；

6）            測試策略的更新不及時；

7）            產品轉測試后，開發一般時間也很緊張，單元測試等做不到位，結果會遺留很多本應該在UT/IT階段發現的問題到系統測試階段。

本人想到的可能的解決辦法（其實做起來很困難）：

1）            從源頭抓起，測試人員和開發人員一起在第一時間得知需求的變更；

2）            提前做好新需求的測試規劃，包括測試設計和測試執行規劃，并且在設計中要考慮新需求對老需求的影響；

3）            做好需求跟蹤：對每個需求的測試相關屬性（測試用例、測試執行記錄等）都進行跟蹤。

歡迎討論。