本文章是由機器翻譯。

Visual Studio 2012

進行測試以便持續開發

Larry Brader
艾倫 · 卡梅倫遺囑

 

Web 應用程式通常更新或延長每隔幾周 （或甚至幾天） 中轉移的業務需求和客戶回函的反應。若要支援持續發展，開發週期的每個方面必須更有效率、 更輕量比更多傳統的發展進程。例如，它是即使最小的更改需要一切都要重新測試軟體的性質。但重複一套完整的手動測試每隔幾天是不可能的。這意味著測試最終必須自動，即使他們開始為手動的探索。在這篇文章中我們展示如何 Microsoft Visual Studio 2012 支援可持續發展環境中測試。

DevOps 週期

當軟體部署和運行時，幾個軟體專案將走到盡頭。從利益攸關者獲得回饋，改善或擴展計畫，和最終獲釋，隨即在週期再次啟動一個新的版本。此過程中，稱為 DevOps，週期所示圖 1。

圖 1 連續開發週期

在傳統的軟體專案中，每個週期可以年。第一個版本通常是豐富的功能，在 DVD 上提供並安裝在使用者的本地電腦上。與之相反的是，現代 Web 應用程式中，第一個版本可能很小，但釋放擴展及改善每隔幾周 （或甚至幾天）。

例如，一個社交網站的管理者可能一周，其間他們監控客戶是如何使用它嘗試一個新的功能。在試行期結束，他們調整功能的工作原理詳細的資訊。

在此更快速的週期中，很重要的開發團隊想作為整個進程的 DevOps 週期。特別是，他們需要使週期中的每個活動更加有效，刪除任何妨礙周圍迴圈進度的路障。

在測試過程中，我們在這裡討論改進，旨在減少需要通過 DevOps 迴圈週期的時間。特別是，這些新的工具和技術旨在減少測試這種迴圈在傳統上造成的瓶頸。

DevOps Cycle 中測試

測試的關鍵作用是演示實施使用者故事和其他要求。手動運行該應用程式，並行使每個故事只是作為最終使用者將最有效的方法來執行此操作。經驗豐富的測試儀適用于各種策略，揭露的 bug，並探討所有變種和邊緣例的應用程式的行為。

當應用代碼更改時，它是審慎的做法是重新測試可能取決於它的一切。軟體中的依賴關係通常形成複雜編織，bug 眾所周知轉似乎無關的更新焦點的功能。出於此原因，傳統的開發團隊不喜歡改變的任何元件都已編寫和測試。如上所述，稍作改變的要求完全重新測試，因此如果您手動測試的一切，這需要大量的精力和資源。

與此相反，在短週期中持續發展的內在需要軟體的每個部分應經常重新審議，其功能是改善和擴展。它將無法手動重新測試每一項功能每隔幾天。短週期需要替換手動測試的程式碼的自動的測試。很快，並且只要你喜歡，您可以運行編碼的測試。

應連續開發團隊他們的所有測試的都代碼，並放棄完全手動測試嗎？有時有人建議這種做法，但在實踐中，有一個高效的妥協，工程，如下所示。

手動測試新的和大幅更改的故事。當每個測試通過一貫，創建自動的版本的那個故事的測試。因此，儘管測試總人數逐漸增加，隨著該產品的擴展，手動測試的負載保持不變因為手動測試是你只為相對較新的功能做的事情。

事實上，編碼的測試，在一個典型的可持續發展專案中的大部分都與應用程式代碼編寫和測試軟體，而不是測試整個應用程式的行為內單個元件的單元測試。單元測試是一個強大的工具，更新基本代碼時保持穩定。

圖 2 顯示從手動逐漸過渡到隨著時間推移，並擴展單元測試和應用程式代碼的自動測試。圖中是一種理想的照片 ； 在實踐中，大多數隊伍自動化只有一定比例的手動測試。Visual Studio 2012 （和其它版本） 還提供部分自動化，可以用來加快速度的測試，而無需編寫代碼。

隨著時間的推移，圖 2 理想過渡到手動從自動測試案例

在 Visual Studio 2012 年測試

讓我們看看如何測試由 Visual Studio 2012 和其相關聯的產品，Visual Studio 團隊基礎伺服器 (TFS) 和 Microsoft 測試管理器 （MTM) 支援。

如果您的專業測試整個應用程式，你會更感興趣的 MTM 所提供的支援。如果您是開發人員，您可能需要在 Visual Studio 2012 年自動化測試支援更大的興趣。然而，不斷發展，我們需要這兩個角色，更密切的關係，有些參賽隊完全免除這種區分。因此，Visual Studio 2012 工具旨在集成的測試、 不同風格和他們支援廣泛的測試做法，通過不斷發展更多傳統的方法。

自動測試與 Visual Studio 2012

自動化測試包括測試通過書面或生成程式碼定義的所有類型。您在 Visual Studio 2012 年，那裡你最初運行它們用於調試創建自動化的測試。

當測試 — — 與它測試的應用程式代碼 — — 是正確的您在測試中，應用程式代碼和檢查。從原始程式碼儲存庫，它生成服務由拾並定期運行您的團隊組建定義。

單元測試和集成測試單元測試是一個最有效的方法維持無 bug 的基本代碼通過在應用程式中的連續變化。

單元測試是一種測試方法、 類或較大的元件，您的應用程式中其他部分、 外部系統和資源的分離的方法。在實踐中，開發人員通常編寫集成測試 — — 那就是，在單元測試，但這可能取決於外部資料庫、 Web 網站或其他資源以類似的方式編寫的測試。不管怎樣，這些測試使用相同的工具和基礎設施。

在 Visual Studio 到 2012 年，您可以編寫使用任何一種的幾個測試框架，例如 NUnit，xUnit 和預設的 VSTest 的測試。當你有編碼的任何這些框架中的測試時，您只需打開測試資源管理器視窗，並選擇運行所有。在視窗中概述的測試結果。

背景測試是有效地在後臺運行您的測試，每次您生成解決方案的選項。第一次執行您的更改而受影響的測試。這意味著當您工作時，您可以經常看到哪些測試是通過或失敗。

隔離單位通過使用正版正貨 True 單元測試是指下測試單位斷開，它所依賴的代碼。這有很多好處。如果您單位正在開發，或在同一時間更新它所依賴的其他單位，您可以測試它而無需等待別人來完成。如果您調整應用程式使用此單元，以不同的方式，或在不同的應用程式中，這些測試和它一起去，並不需要更改。

Visual Studio 2012 提供了兩種機制，統稱為假貨，為一個單位斷開及其依賴項。從您的單位對其邊界以外的方法的調用可以由您提供的代碼小件處理。例如，您可以定義截獲對任何外部的方法，如 DateTime.Now 的調用的墊片。因為它總是從農心接收相同的應答，您的設備將在每次調用時演示相同的行為。您還可以定義存根，所提供的預留位置中沒有已載入的程式集的方法的實現。

性能和負載測試 Visual Studio 2012 最終提供的性能和應力測試特定的測試設施。應用程式可以檢測和驅動，以便衡量其指定負載下的性能。Web 應用程式可以驅動與類比多個使用者的多個請求。

編碼的使用者介面測試編碼的使用者介面測試讓您運行您的應用程式，並生成驅動它的 ui 介面的代碼。Visual Studio 2012 包括專門的工具，用於創建和編輯編碼的使用者介面測試，還可以編輯和添加到代碼自己。例如，您可能會創建一個簡單的過程，要買東西的 Web 網站，然後編輯代碼，以添加一個迴圈，買了很多專案。

編碼的使用者介面測試程式尤其有用，凡有驗證或其他 UI 中的邏輯 — — 在 Web 頁中，例如。作為使用者介面的單元測試或整個應用程式的集成測試，您可以使用它們。

手動測試與 Microsoft 測試經理

手動測試可以探索計畫內或計畫外。您執行手動測試 MTM 的説明。您的應用程式已從簽入代碼生成的版本通常執行的測試。

通常情況下，手動測試連結到使用者的故事 （或產品積壓專案或其他要求），並測試的結果顯示在專案儀表板上的報告中。這意味著，每個­一個可以快速查看哪些故事已被成功地實施。

探索性測試探索性測試只是意味著運行應用程式，可以試試看。然而，你為什麼需要 MTM，以説明您運行它？

MTM 可以記錄你的行動、 評論和截圖，而你的工作。如果您決定要創建一個 bug 報告，所有此類資訊會自動添加到它，使它不必要為您要添加如何重現 bug 的精確描述。圖 3 顯示 MTM 探索性測試視窗旁邊正在測試的 Web 應用程式的示例。

圖 3 錄製螢幕截圖和探索性測試視窗中做筆記

MTM 還可以檢測應用程式本身，都在用戶端和伺服器上，可以用來調試該應用程式的記錄的事件資料。此資料將自動附加到您的錯誤報表。

當該 bug 固定的時你要重複步驟你花在探索來驗證此修補程式。為解決這一問題，您可以從探索性會議，在其中您包括有關步驟生成測試案例。

計畫的測試案例的測試的測試案例是您定義為一系列的測試人員應執行的步驟的手動測試。圖 4 顯示在一個測試案例中定義的步驟。

圖 4 在一個測試案例中定義的步驟和預期的結果

測試案例提供澄清的使用者所需要的好方法。在短跑運動開始時，當你正在討論故事或需求與使用者和其他利益攸關者，您可以使用步驟作為一個精確的使用者將能夠在 sprint 年底做例子。每個測試案例是的要求，只是一個實例，所以每一項要求是通常與多個測試案例相關聯。例如，如果要求是為了能夠買冰激淩，一個測試案例將詳細介紹的步驟來購買一種特別的風味。您將創建另一個測試案例來描述購買香料的混合物。應與利益攸關者討論的指導原則："時您可以成功地執行這些測試案例，然後我們會考慮的故事將實施。

TFS，在這些故事或要求和測試案例由代表的工作項。您可以將它們連結一起這樣一項規定的進度可以跟蹤測試的結果。

當您運行一個測試案例時，這些步驟將顯示在螢幕的一側。運行應用程式時，您檢查關閉的每一步。結束時，您檢查是否通過了測試已關閉或失敗。

正如與探索性測試，您的操作，評論，螢幕截圖和應用程式資料記錄以便您可以非常迅速地創建一個詳細的 bug 報告。

他們説明任何人可靠、 重複測試，即使他們不熟悉應用程式的使用步驟一大優勢。當測試重複的時您可以確信是否通過或失敗，這並不只是因為從最後一次以不同的方式運行測試。

您還可以從探索會話生成一個計畫的測試案例。這樣有助於確保您始終運行測試使用相同的操作。

自動化手動測試

自動化您手動測試相當一部分，必須儘量減少測試 DevOps 週期中所需的時間。Visual Studio 2012 支援這種自動化，在幾個方面。

錄音/播放半自動化可以重新運行測試案例。運行測試時的第二次和其後時間，MTM 重播的擊鍵和您使用第一次運行的手勢。你要做的就是驗證您看到的結果符合步驟中詳細說明的期望。

播放使手動測試更快、 更可靠。它還使它可能分配各同事們可能不完全熟悉應用程式的測試負載。

即使您不完全自動化測試，快速、 可靠的重播有助於減少週期時間的 DevOps。此功能不需要 Visual Studio 2012 年安裝，並不涉及編寫的代碼。

生成編碼使用者介面測試你可以從手動測試案例記錄運行生成完全自動編碼的使用者介面測試。生成的代碼將執行相同的操作，則手動測試。通過在 Visual Studio 2012 年使用一個特殊的編輯器，您還可以擴展測試以驗證結果並歸納它以不同的輸入資料的重複測試。圖 5 顯示了特殊的編輯器。

圖 5 編輯 UI 操作在 Visual Studio 2012 年

連結到測試方法的測試案例可以將一個測試案例連結到任何測試方法中，即使它還沒有被從您的測試回合生成。將報告運行測試的結果，因為如果您曾運行手動步驟。通常您會將測試案例，連結到集成測試的執行操作手動測試相同，但直接，磁碟機的業務邏輯，而不是使用使用者介面。

這種方法具有 UI 佈局的變化不失效測試的好處。當開發團隊已經創建了一個合適的集成測試，這也非常有用。

實驗室管理

當您測試應用程式時，您需要的第一件事是一台機器上運行它。事實上，大多數應用程式今天需要多台機器。一個現實的測試環境，您可能，例如，需要所有在單獨的電腦上安裝一個 Web 服務器、 資料庫伺服器和用戶端瀏覽器。圖 6 說明了這樣一個環境。

圖 6 樣本的實驗室環境測試式銷售網站

除了基本的安裝，您也要安裝可以收集的前面"探索性測試"一節中提到的事件資料的代理。

在 MTM 命名實驗室中心功能使所有這一切都簡單明瞭。勞顧會中心允許您定義實驗室環境。在實驗室環境是一套將作為一組用於測試目的的機器。

除了處理分配的機器 （因此意外地不能使用一種別人的測試回合的機器），實驗室中心還安裝了必要的測試劑。勞顧會中心提供一個地方你可以快速登錄到的任何環境中電腦的主控台。

勞顧會中心也是好的創建和管理虛擬機器 (Vm)。您可以創建一個虛擬的環境、 安裝相關的平臺軟體，然後將存儲庫副本，每當您想要測試您的應用程式，您可以使用。你要做的就是 reinstantiate 清潔環境的副本並安裝新版本的應用程式的元件。您還可以自動進行此部署過程。

使用實驗室中心 — — 和，特別，利用其設施與虛擬機器 — — 可以顯著地減少相比更傳統的方法去維護一個實驗室的實驗室設置時間。勞顧會中心是減少每個 DevOps 週期中所花的時間的重大貢獻。

自動化測試 TFS

自動化的測試最初開發者的電腦上執行 Visual Studio 2012 年。該代碼有後尚未簽入到的源存儲庫中，有很多種方法可以通過生成服務運行測試的集成代碼。

定期生成生成服務編譯代碼並運行測試。您可以創建組建定義，以指定要運行的測試，並可以指定他們應在何時運行。例如，您可能連續的基礎上運行的測試的一套核心並每晚運行更廣泛的集。

生成的結果可查看 Visual Studio 2012 年，也可從您的專案 TFS Web 服務。電子郵件可以通知您的故障。

實驗室部署如我們先前所述，您可以指定一組的實驗室機器到測試通過使用實驗室中心。通過定義一個實驗室生成，可以自動執行此過程。您生成觸發時 — — 例如，當檢查代碼中，或在一天的特定時間 — — 生成開始通過編譯的所有應用程式並測試代碼。如果此操作成功，則分配實驗室環境，並且如果它是一個虛擬的環境，它可以設置回到新鮮的狀態。您的應用程式元件然後部署到正確的機器，並從他們那裡驅動應用程式指定的客戶機上安裝測試。

這些測試可以是任何種類的自動化的測試，但通常您使用這種類型的生成執行大型集成測試或測試整個應用程式。

如果您的測試連結以測試案例時，結果將記錄針對相關的使用者故事或要求，並顯示在專案進展報告。

報告

TFS 提供了大量的圖表和表格，顯示一個專案的進度。單獨或專案儀表板，您可以查看它們。幾個測試的相關報告中。

例如，使用者的故事測試狀態報表，說明了圖 7，當前的短跑顯示您正在處理的故事的清單。除了執行的每個故事的發展工作，圖表顯示成功或失敗的相關測試。如果故障未在運行測試時發現的由此產生的錯誤報表還連結到要求。

圖 7 使用者故事測試狀態報表

在圖表上的結果來自于最新運行手動測試和自動化的測試回合。

試驗計畫的進展報告，說明在圖 8，顯示為當前衝刺創建多少測試案例和已運行多少。

圖 8 測試計劃進度報告，是百米衝刺

有的隊想在每一次衝刺，開始時創建測試案例，作為團隊的目標。所有的測試都應為綠色末尾的衝刺。

Visual Studio 2012 和持續發展

現在，您有一些熟悉 Visual Studio 2012 年測試功能，從對整個應用程式手動測試的單元測試的範圍。

DevOps 迴圈意見發展作為只是一人一半的一個過程，它還包含操作的回饋。根據上下文，DevOps 週期將長期或短期。如果您正在開發一個核電站，希望你去周圍迴圈非常緩慢。如果您正在運行的 Web 應用程式，您可能會圍繞著它去每隔幾天。慢速和快速週期都同樣有效和適當的不同類型的系統。兩者都將納入測試不同程度的需求。如果快速迴圈的持續發展是適合您的專案，它是重要的是要減少在迴圈中執行每個操作所需的時間。你也許還在專案中工作時更加慎重的步伐使少角色的開發人員和測試儀比之間的區別。

在 Visual Studio 2012 年可用的工具可以大大減少測試您的應用程式所需的時間量。這裡有幾點需要記住：

• 潔淨實驗室環境可以將設置快速和自動，特別是通過使用虛擬機器。利用實驗中心的優勢。
• 記錄操作期間探索性和計畫測試可讓您創建 bug 報告快速、 可靠地，減少一個 bug 將會消失，當有人試圖重現它的機會。
• 您可以實現從手動測試逐漸過渡到自動化測試。自動化的測試處理大部分的迴歸測試，而手動測試側重于新的和更新的故事。
  • 從探索性測試中，您可以生成可重複執行手動測試用例。
  • 您可以記錄測試回合和回快速而可靠地玩耍。
  • 您可以從測試回合生成編碼的使用者介面測試。或者，您可以將連結分別編碼的集成測試，測試案例。

圖 9 顯示從探索性測試的自動化測試的進展。

圖 9 測試進度

• 測試案例可説明您精確地描述你的使用者故事。您可以使用您的利益相關者寫的步驟，減少任何故事所做的事情的誤解。
• 測試連結到的要求 （或使用者故事或產品積壓專案） 所以你可以看到全面的報告上多遠已實施使用者的需要 — — 不只是在做他們的工作，但在他們是否成功。測試為在每次衝刺的開發團隊提供了目標。
• 測試案例和要求可以連結到演示圖板 PowerPoint、 需求文檔或統一模組化語言模型中。當您在分鏡腳本中進行更改時，您可以跟蹤到測試必要的更改。
• 試驗計畫的連結在一起測試案例、 代碼、 要求、 測試環境和測試設定和團隊專案。如果團隊花費幾個月才返回以提高產品在別的東西上工作，它很容易重建一切所需的測試。

我們給你的視覺工作室 2012年如何配合 DevOps 週期概述。現在，您應瞭解為什麼你需要到測試了簡化的方法和工具 Visual Studio 2012 提供的旨在説明您實現這一目標。如果你想要更多的資訊，閱讀"測試的連續傳遞與視覺工作室 2012 RC"在 MSDN 庫中 bit.ly/KHdOq4。它是深入的指南，Visual Studio 2012 提供的測試基礎設施的各個方面。在相關文章包括"驗證代碼的使用單元測試" bit.ly/dz5U3m 和"測試應用程式"在 bit.ly/NbJ01v。

Larry Brader 一 直是微軟模式高級測試儀 & 在過去幾年的實踐團隊。在此之前，他曾擔任開發人員和測試人員對軍事和醫療技術。

Alan Cameron Wills  是在微軟開發司程式設計的作家。在以前的生活中他已經開發人員、 軟體架構師和開發方法中的一名顧問。

由於下面的技術專家，檢討這篇文章：Howie Hilliker, Katrina Lyon-Smith, Peter Provost 和 Rohit Sharma