我們使用Microsoft Test Manager來測試應用程序。我們最初爲每個我們想測試的應用程序創建了Test Plans。因此，我們的測試計劃有這樣的結構：每次迭代創建新的測試計劃或編輯現有的？
應用程序A
應用B
應用程序C
現在，在每次迭代中，我們得到新版本進行測試。因此，我們是否應該保持相同的測試計劃並編輯它們適當的字段（使用中的，迭代，配置， ...）還是爲每個迭代創建新的更好？是這樣的：
應用A - 迭代1
應用A - 迭代2
應用B - 迭代1
應用B - 迭代2
應用程序C - 迭代1
應用程序C - 迭代2
是否有意義爲每個新版本創建一個新的測試計劃？
通常爲特徵創建測試計劃。並在功能（功能規格）發生變化時相應更新。但這是理想的世界。
從這裏我可以告訴你「正在使用，迭代，配置......」，你正在談論測試報告而不是計劃。爲什麼不製作帶有測試計劃的文檔？並且例如單獨的
例如在這個文檔中你將更新（添加一行）的配置，構建，用於測試的環境？
考慮到定義和測試計劃的一小解決方法：
的測試計劃過程和計劃本身作爲車輛與項目團隊的其他成員，測試人員，同事，經理溝通和其他利益相關者這種溝通使測試計劃能夠影響項目團隊和項目團隊影響測試計劃，特別是在組織範圍的測試策略和動機領域;測試範圍，測試目標和關鍵領域;項目和產品風險，資源考慮和約束;以及被測物品的可測性。您可以通過發送一個或兩個測試計劃草案並通過審查會議來完成此溝通。這樣的草案將包括許多筆記，如下：
[待定：詹妮弗：請告訴我什麼計劃是爲測試項目發佈到測試實驗室每個系統測試執行週期？]
[戴夫 - 請讓我知道哪個版本的測試工具將用於先前增量的迴歸測試。]
當您記錄這些問題的答案時，測試計劃將成爲以前的討論和測試人員與項目團隊的其他成員之間的協議。測試計劃還可以幫助我們管理變化。在項目的早期階段，當我們收集更多信息時，我們修改了我們的計劃。隨着項目的發展和情況的變化，我們會調整我們的計劃。書面測試計劃爲我們提供了衡量此類修訂和變化的基準。此外，在主要里程碑更新計劃有助於保持測試與項目需求保持一致。在我們進行測試時，我們會根據結果對我們的計劃進行最終調整。您可能沒有時間或精力在每次出現差異時更新您的測試計劃，因爲有些項目可能非常動態。在第6章[Black，2001]中，我們描述了一個簡單的方法來記錄可以使用數據庫或電子表格實現的測試計劃中的差異。您可以將這些更改記錄作爲測試狀態報告的一部分或作爲項目結束測試摘要的一部分納入定期測試計劃更新（c）ISTQB Foundation book
我建議您更新您現有的測試計劃，以便可以看到在整個應用程序開發生命週期中所做的任何修改或更正。