迴歸測試和部署策略

Question

我想就部署策略提供一些建議。如果一個開發團隊創建了一個廣泛的框架，並且許多（20-30）個應用程序都使用它，並且業務至少每隔30天就會有一次應用程序更新，那麼最佳的部署策略是什麼？

的原因，我問的是，似乎有很多的垃圾（和風險）使用每月部署的變化，如果90％的應用程序不會改變的敏捷方法。我的意思是這個框架可以在一個月內改變，一些應用程序也可以改變。由於框架發生了變化，所有應用程序都應該進行迴歸測試。例如，如果有10個應用程序在一年中根本沒有變化，那麼這10個應用程序每個月都會進行迴歸測試，因爲它們沒有任何功能更改或修復程序。他們不得不進行測試，因爲業務每個月都在進行更新。

，那就是參與......如果一個任務關鍵型應用程序部署的風險，這需要幾個星期，和多個部門，進行測試，這是不現實的期望有不斷迴歸測試此應用程序？

一種選擇是使任何框架更新向後兼容。雖然這意味着應用程序不需要更改其代碼，但仍然需要測試，因爲底層框架已更改。所涉及的風險很大;一個不斷變化的框架（並且部署這個框架）意味着關鍵任務應用程序永遠不會只是長時間享受相同的代碼庫。

這些應用程序共享同一個數據庫，因此需要進行不斷的測試。我瞭解TDD和自動化測試，但目前尚不存在。

有什麼建議嗎？

Answer 1

背後的框架的想法是，它應該是「緩慢移動的代碼」。您不應該像其支持的應用程序那樣經常更改框架。嘗試在較慢的開發週期中獲得框架：或許每三個或六個月發佈一次。

我的猜測是，你還在制定一些在這個框架的架構決定的。如果您認爲框架變化真的需要這種動態變化，那麼可以經常更改框架的哪些部分，並嘗試將它們重構爲需要它們的應用程序。

敏捷並不一定意味着一切無限變化。您的架構師可以在框架的構成上劃定界限，並且避免人們輕易調整它，以便適用於可能的應用程序快捷方式。它可能需要幾次迭代才能讓它穩定下來，但在此之後它應該更穩定。

Answer 2

以下是我能想到的一些提示： 1.將框架分解爲獨立部分，以便更改一個部分只需運行一小部分測試用例。 2.使用測試用例優先技術。也就是說，您只會重新運行由某種策略選擇的應用程序的一小部分測試池。額外的分支和ART通常比其他分支更好。他們需要知道每個測試用例的分支覆蓋信息。 3.不經常更新框架。如果應用程序不需要更改，則表示可以不更改它。所以我想這些應用程序可以使用舊版本的框架。您可以每3個月更新一次這些應用程序的框架。

Answer 3

迴歸測試是一種生活方式。在發佈之前，您需要對每個應用程序進行迴歸測試。但是，由於時間和金錢通常不是無限的，因此您應該將測試重點放在變化最大的區域。識別這些區域的快速和骯髒的方法是計算在給定業務區域中更改的代碼行數;說「會計」或「用戶管理」。那些應該首先進行最多的測試以及任何您認定爲「關鍵任務」的領域。

現在我知道更改的代碼行不一定是衡量更改的最佳方式。如果您有明確的變更請求，則通過查看變更請求的數量和複雜性來評估這些熱點實際上更好。但不是每個人都有這種奢侈。

當你在談論改變框架時，你可能不需要測試所有使用它的代碼。如果你正在談論像DAL這樣的改變，無論如何這基本上就是一切。你只需要測試一個足夠大的代碼樣本，以便相當舒適的變化是可靠的。再次，從「關鍵任務」地區和受影響最嚴重的地區開始。

我覺得將項目分成3個不同的代碼流很有幫助;開發，QA和生產。開發對所有變化都是開放的，QA是功能鎖定的，而且生產是代碼鎖定的（就像鎖定它一樣）。如果您按月發佈產品，您可能希望在發佈前至少1個月從開發代碼分發QA版本。然後，你花這個月接受測試新的變化和迴歸測試你可以做的一切。您可能需要在發佈之前的一週左右完成測試，以便應用程序可以進行分階段執行，並且可以幹幾次安裝。你不會得到迴歸測試所有東西，所以有一個策略可以將補丁發佈到Production。不要忘記將這些補丁重新合併到QA和開發代碼流中。

自動化迴歸測試將是一件非常棒的事情;理論上。在實踐中，最終花費更多時間更新測試代碼，然後您將手動運行測試腳本。此外，你可以聘請兩個或三個測試猴子，以一個非常好的測試腳本開發者的價格。悲傷但真實。

Answer 4

除非您有（單元）測試覆蓋率，否則我不會將其稱爲敏捷方法。敏捷的關鍵原則之一是，您擁有強大的單元測試，爲頻繁重構和新功能開發提供安全網。你的情況有很多風險。每個月部署20到30個應用程序，其中大多數應用程序不會爲其用戶添加任何新業務價值; 2）沒有測試就沒有資格成爲我書中的一個好主意。我是敏捷的堅定信徒。但是你不能挑選和選擇那些方便的部分。

如果業務應用程序沒有改變，我不會發布它只是爲了在新的框架中編譯。想象一下，每當框架發生變化時，每個.NET應用程序都需要重新發布。閱讀你的問題，我想知道普通數據庫是否在推動這一需求。如果您的框架正在隔離架構，並且您發現在架構更改時需要重新構建應用程序，那麼您首先需要解決該問題。查看重構數據庫，作者：Scott Ambler提供了一些提示。

另一方面，集成測試和單元測試存在很大差異。你的迴歸測試是集成測試。在這個級別自動化非常困難。我認爲測試中發生的突破是關於編寫高度可測試的代碼，使得單元測試越來越多的代碼庫成爲可能。