這里我不想討論需求為什么變化那么快，為什么會允許這樣隨意地變更。因為許多公司的現狀就是如此，讓他們形成配置管理的意識，不是一天兩天能解決的事�；蛘哂行┢髽I，雖然知道配置管理的重要性，但是真正到了要落實的時候，就把原本訂的配置管理流程束之高閣了。
在需求變化頻繁的情況下，作為測試人員，最重要的就是要搞清楚以下幾點：
1.哪些需求發生了變化
2.這些需求變化后，對測試工作會產生哪些影響。包括會不會影響測試用例，如果影響，會對哪些用例產生影響。當發生較大改動時，還要明確是不是影響到了測試方案，甚至是測試計劃？
3.明確這些變化，會對自己的工作進度產生多大的影響。當發現自己的大部分用例都受到影響，需要修改時，應該第一時間向上級反映情況。由他定奪解決方案，而不是自作主張，或是一聲不響。
關于如何確定哪些需求發生了變化，最好的工具當然是需求跟蹤矩陣了。需求跟蹤矩陣是從開發和測試兩條線，同時進行跟蹤的。但是，要實現需求跟蹤矩陣，可不是容易的事情。尤其對于需求變化頻繁的公司來說，基本可以斷定他們是沒有配置管理的。那么需求跟蹤矩陣就根本沒有實現的可能。但是，公司沒有，不代表我們自己沒有。
公司的測試任務分配，一般都是按照子系統或者是模塊來分的。比如TesterA測試子系統A，TesterB測試子系統B。那么這時，我們完全可以只針對自己測試的子系統，完成需求跟蹤矩陣。我們只需要自己維護測試線的需求跟蹤，至于開發線，那可是管不著了。但是這里還是有點問題。我們一般理解的需求跟蹤矩陣，是將SRS分成子SRS，然后針對每個子SRS，建立跟蹤關系。但是忽略了各個子SRS之間的關聯關系。要想把各個子SRS劃分得沒有一點聯系，那是不太可能得。如果有兩個子SRS，稱為SRS1和SRS2，你測試的是SRS1相關模塊，而SRS2相關模塊是別人測的。當SRS1相關開發人員告訴你需求已變更后，你分析后得知影響到了SRS2，那么你必須和測試SRS2相關模塊的測試人員及時溝通。你能保證做到這點，但是對方未必會在SRS2發生變化時，及時通知你SRS1受影響的部分。這時你需要事先和測試組的其他人員充分溝通，讓他們及時通知可能會影響到你的變更。如果他們不及時通知，你就完全有推卸責任的理由了。對于開發人員也是一樣，他們擅自改了程序，不通知變更SRS，或者不及時通知變更，你也完全有理由推卸責任了。
我們的目標肯定是要把測試工作做好，而不是自己沒有責任就好了。當建立了自己的需求跟蹤矩陣以后，就可以快速定位變更部分，而且目前企業沒有配置管理的理念，所以可以及時變更你的用例，方案，甚至是計劃。當發現受變更影響的部分非常多時，應該及時通知上級，讓他們了解情況，并做出決策。
總結一下的：需求變化快，測試工作需要重新寫用例，方案，甚至計劃。這時遇到問題：
1.得不到及時通知
解決方案：沒有辦法，只能事先和開發人員以及測試組內部人員事前聲明，不及時通知的部分，一概不付責任
2.不知道需求變化后，對哪些工作產生了影響
解決方案：公司沒有配置管理，沒有需求跟蹤，那么就建立自己的小的需求跟蹤。只跟蹤測試線。把自己的工作做好，并及時通知其他受影響的測試人員。
3.發現自己大部分用例，方案，甚至計劃要重新修改，而沒有充足時間
解決方案：及時通知上級，讓他給解決方案，而不是自己苦干。
文章來源于領測軟件測試網 http://www.kjueaiud.com/