.NET Interop: 自動化的接受度測試與 IronRuby

發行項
10/09/2015

本文章是由機器翻譯。

.NET Interop

自動化的接受度測試與 IronRuby

Ben Hall

可從 MSDN 程式庫的程式碼下載
瀏覽線上的程式碼

本文將告訴您：

什麼接受度測試？
自動化的接受度測試
實作的接受度測試

本文將使用下列技術：
IronRuby

內容

什麼接受度測試？
自動化的接受度測試
故事
案例
實作接受度測試
RSpec 案例 Runner 與 C# 物件互動
接受度測試 UI
向前移動

當客戶需求可以正確地傳達而不必浪費時間實作不完整或不正確功能在一天的幾乎每個開發人員 dreams。如果我們無法手動清楚、可讀規格給客戶，並要求他們如果這會符合其功能之需求之後，我們可以執行完全相同規格，不驗證我們的實作針對這些需求的任何額外工作，不是很棒嗎？

這個層級的客戶和開發人員之間的通訊可以成功完成使用接受度測試和可執行檔規格的概念。藉由利用驅動程式開發 (BDD) 的行為，我們可以開始更有效地溝通需求。

我的文件，在 2 月 2009 MSDN Magazine (" 使用者入門使用 IronRuby 及 RSpec，第一部「)，我介紹您 IronRuby，並示範如何它可讓您與.NET 相容程式碼 (例如 C# 交互操作使用動態的拼音語言。在本文中，我將介紹您概念的接受度測試。由我的上一個文件中所介紹在概念上建置，我將示範如何可以是接受度測試自動化使用 IronRuby] 和 [RSpec 來確認.NET 應用程式中，並建立系統的可執行檔的規格。

什麼接受度測試？

接受度測試已經與許多不同的定義產生關聯。我，接受度測試是其他驗證在開發系統會符合客戶的需求的資訊和關於減少我們的程式碼中的錯誤數目少。換句話說，接受度測試會是不需測試程式碼，但需建置哪些客戶或企業希望。聽起來明顯，但缺乏的接受度測試和類似缺乏對需求的瞭解許多專案失敗的主要原因。

接受度測試只能支援在的客戶或在至少一個 Proxy 的客戶以協助定義準則。有人推動接受準則，您沒有任何項目可以確認軟體正確的因此很難確認您正在建置正確的軟體。客戶一起的開發小組的所有成員應該來一起定義系統的測試「案例」描述系統必須執行，並將如何它必須做的數個方面。

例如，如果我們所開發的 e-開始系統、的接受度測試可能會根據購物車的互動。典型的案例可能，「如果是空的購物車和我新增產品 123，然後項目計數應增加 1 並會小計應該 $20 」。這會提供瞭解客戶預期行為的購物車的方式，並提供一些步驟，以確認實作。隨著系統增加，您必須驗證系統和功能集的不同部分的多個案例。

但，撰寫案例時的重要的考量都是使用語言。語言應反映出如何企業瞭解的問題不如何開發人員會執行解決方案。測試所描述的實際實作 — 」當我按一下按鈕 [送出]，標籤 ' [確認變更」 — 然後這會將較少的值提供給客戶，並取決於如何您實際實作系統。如果在實際的實作的變更，但商務需求仍然保持相同，然後此相依性會需要額外的維護成本為小組必須更新相關的測試。

使用清除的需求和傳遞的準則，請建立測試，您的軟體會代表符合客戶的期望大更好的機會。不過，仍然包括人手動確認符合需求] 和 [應用程式如預期般的運作方式。這是自動化的接受度測試的概念進來的位置。取代的檔案共用上的過期文件中，需求而定，的需求會定義為範例和案例、已簽入原始檔控制項，實作的成品以及可以在任何時候，確認是否會實作任何需求，且運作正常執行。您可以採用相同的方法，撰寫在的測試但或試算表中的測試實例管理軟體，請撰寫它們的而不是您撰寫它們直接在程式碼中

自動化的接受度測試

接受度測試可協助驗證要建立應用的程式的客戶需要而自動化這些案例可以讓您不斷地驗證在整個開發程序實作，並使用它們做為您的迴歸測試套件的一部分以確保未來的變更不違反存在的需求。

不過，有客戶相關撰寫尤其是自動化測試的測試，引進了一些潛在的問題。一般來說，客戶，是 nontechnical，並傾向於畏離開實際開發的軟體。與技術小組的共同作業，客戶可以提供輸入和軟體測試人員時的範例或開發人員可以快速程式碼案例和可執行檔的規格。此外，案例必須清除在企業內的任何人。您可以利用 IronRuby 來改善測試，但是如何執行這項工作在練習的可讀性？

若要說明如何這個處理序可能可用於在實際專案，我將示範實作一個周圍價格的計算系統的使用者故事。一個簡單的範例但希望它會示範的相關步驟。接受度測試的方式，您可以方法的問題，是架構，而且有許多變種及解譯。不過，這應該提供您可讓您向前移並算出的詳細說明為您的技術工作的基本概念。

這個範例隨附的一個「紅色，綠色，重整」我在本機使用者群組所提供的簡報。之後，出席者的其中一個要求我建議在他如何有效地無法單元測試確保所有價格計算，包括各種不同的選項和新增到封裝，被正確地都計算其應用程式。這個範例是一個完全示範其中接受度測試是非常有用。藉由在本文] 和 [價格和您預期會發生的案例，您可以確信系統正常運作。

這些驗證也會很有用的同時開發小組和客戶來示範系統的運作方式] 和 [各種例外狀況的其他範例文件來源。如果客戶認為，會價格不正確的然後小組可以參考到可執行檔規格客戶的核准，做為已完成工作的辨識項。

而不需要這些測試，在位置，價格，規則會可能中加以定義大型 Word 文件，嘗試將說明系統如何處理不同的價格設定 – 原本就已中斷連線從系統所開發的文件。這就是為何我相信自動化的接受度測試。

故事

開發使用接受度測試的目標與價格計算系統時, 第一個階段是讓每個人都在房間內定義在本文。客戶會定義他們想要與鼓勵小組的技術性的成員。使用 BDD，本文先前所述您要使用設定格式定義大綱，以支援一致的語言的小組和是客戶的需要特別的成員之間。請指定下列格式，您會填入詳細資料與客戶的說明：

為 [角色] 我想要 [功能] 讓 [結果]。

一個立即的錯誤是通常位在的 Story 中實作詳細資料包括啟動。例如：

以系統的管理員身分我希望在 Default.aspx 中，框格檢視中顯示的價格，以便我可以提供他們的成本。

Story 必須只在特定的商務條款中描述問題，並操縱清除的詳細技術資訊。改良的範例可能是這：

以銷售系統管理員，我想，我可以將它們提供與成本進行識別客戶的價格。

不時遵循格式，它提供一些非常鬆散的資訊，並它不提供實作一個起始點。會更好的範例所示：

以銷售系統管理員，我要能夠檢視價格的產品 x，我可以提供客戶，以根據其需求的正確成本。

本文提供更詳細的說明與更多有關哪些客戶預期會發生和他們確實想要的內容。結果很更加有用我們實作系統時。

要記住撰寫文章和功能時的一個重要事實是保留它們，盡焦點。會讓您更更容易建立案例，、寫入的測試，以及實作完成的程式碼。在某些系統，故事可能解決一項功能為基礎。

案例

即使有一個的故事您仍然需要您的預期發生的更多資訊。案例很這非常有用。案例只是指出則輸出應該是這個指定特定內容，如果有發生種情況。目標是提供的故事的實作應該如何運作在不同的情況下一個更具體的範例。這會進行通訊的小組，期望，並提供驗證步驟。

指定，時，然後 (GWT) 語法升級 Dan 北邊的就是要使用建議的語法：

指定 [內容]，當發生問題 [時]，然後在 [結果]。

一個範例的案例可能如下：

Product X 的不支援的案例：單一使用者授權

Product X，指定使用者要求單一時使用者授權和這不包含支援，則價格應是 250 美元。

使用「並且」可以用來連接多個內容或結果，讓您讓多個案例的意義，並提供所發生狀況的相關資訊。

在理想的情況下，應該有許多案例以解決任何模稜兩可，做為在可執行檔的規格，並提供足夠的初始的工作，以啟動的資訊。請注意，這些案例都不是固定重要的。工作會繼續進行，並獲得更多的知識庫」，您可能需要回到現有的案例相關的問題的客戶，或建立其他的案例，以取得「知識庫」為基礎。

撰寫案例時，有要牢記在心的幾件事。類似新聞，案例應該被著重在其中一個範例。主要原因，是可讀性。如果案例執行太多，然後核心訊息會遺失。

實作接受度測試

一旦您具有本文和案例清楚、瞭解格式下, 一個階段就是自動化本文及案例。這可讓他們在追蹤進度，並在攔截迴歸錯誤的開發期間執行。時，我將交談的 RSpec，基本處理序就可以傳輸到任何的 BDD Framework。如需安裝 IronRuby 及 RSpec 的詳細資訊，請參閱我之前提到的文章 (英文)。

如果您依照撰寫您的報導的前一個範例，然後您將會發現，案例 Runner 在 RSpec 很自然。將純文字的空白檔案內在此檔案稱為 pricing_scenarios_for_product_x，您只複製案例與本文至檔案以下列格式：

Story: Pricing for New Product X
  As a sales administrator, I want to be able to view
  prices for product x so that I can provide customers
  with an accurate cost for their requirements. 
Scenario: Single User License for Product X without support
  Given Product X
  When user requests a 1 user license
  And this does not include support
  Then the price should be $250

現在這我們的接受度準則的基礎的表單，以及將用於驗證應用程式時。不過，若要啟用，做為可執行檔的規格中,，您會必須執行一些拼音程式碼。 IronRuby 會是一個簡單的環境，啟動寫入及執行程式碼。直接使用..rb 副檔名建立檔案，並開始撰寫 RSpec 測試中。

在第一個步驟是參考.RSpec Framework。這是透過需要指示詞。藉由包含下列兩行，您可以啟動使用 RSpec 的故事 Runner：

require 'rubygems'
require 'spec/story'

現在，您可以定義步驟。一個步驟是一個在案例中使用 GWT 的格式。 RSpec，與步驟與程式碼中的方法相關聯。每個步驟都應該與執行只有一個工作相關聯。例如，指定的步驟用於設定物件，在 [時然後通常是在判斷提示 (Assertion) 和驗證發生的地方。

RSpec 的所有步驟都需要包裝在區塊呼叫 steps_for。括弧內是該組步驟識別項：

steps_for(:product_x) do
  #Steps go here
end

每個在本文中的步驟，直接與這個案例中某一行。例如，RSpec 程式碼的「指定產品 X"的行，會對應到下列的步驟方法中：

Given("Product $productName at $price") do |productName, price|
   pending "Need to complete implementation for accessing C# object"
 end

RSpec 會讓您可以在您的步驟中使用預留位置，預留位置值設定為變數進行步驟，執行字串操作。在這種情況下 ProductName 和價格將會儲存在的變數可讓您重複使用相同步驟，多個不同的產品和基底的價格。

您可以遵循相同的方法的時與然後的步驟執行：

  When("user requests a $amount user license") do |amount|
    pending "Need to complete implementation for accessing C# object"
  end
  When("this does not include support") do
    pending "Need to complete implementation for accessing C# object"
  end
  Then("the price should be $price") do |price|
    pending "Need to complete implementation for accessing C# object"
  End

第二個步驟中您不需要預留位置因為它永遠都是相同的動作因此區塊沒有參數。當您執行測試時，RSpec 會呼叫正確方法正確的順序根據案例，取代所定義的值。

最後，您需要提供您在第一次建立本文檔案路徑。這是另一個稱為 with_steps_for，提供識別項定義步驟時，使用的區塊。主體會呼叫使用的路徑和名稱，檔案儲存在案例的執行的方法：

with_steps_for(:product_x) do
  run File.dirname(__FILE__) + "/pricing_scenarios_for_product_x"
end

若要執行測試，執行 IronRuby 命令列工具 (ir) 當做參數傳遞拼音檔案：

>ir pricing_scenarios_for_product_x_story.rb

撰寫步驟，時您會發現我已呼叫暫止方法。這是表示有仍以完成功能所需工作。結果當我執行測試時，輸出將狀態的所有暫止的工作 (請參閱 [圖 1 )。這是為了方便讀者閱讀和瞭解發生了事好 — 您要在最後一個項目為執行步驟以傳遞，因為沒有任何實作。

[圖 1 顯示暫止的方法

Running 1 scenarios
Story: Pricing for New Product X
 As a sales administrator, I want to be able to view prices for product x, 
 so that I can provide customers with an accurate cost for their requirements.
 Scenario: Single User License for Product X without support
  Given Product X at 250 (PENDING)
  When user orders a 1 user license (PENDING)
  And this does not include support (PENDING)
  Then the price should be 250 (PENDING)
1 scenarios: 0 succeeded, 0 failed, 1 pending
Pending Steps:
1. Pricing for New Product X (Single User License for Product X without support): Product $productName at $price
2. Pricing for New Product X (Single User License for Product X without support): user orders a $amount user license
3. Pricing for New Product X (Single User License for Product X without support): this does not include support
4. Pricing for New Product X (Single User License for Product X without support): the price should be $price

RSpec 案例 Runner 與 C# 物件互動

這時候，故事、案例和步驟位於的位置。不過，我們尚未實作任何與我們的系統進行互動的程式碼。我先前的文件中我會著重在如何使用 RSpec 規格 Framework 提供的 [我的 C# 物件工作的方式，並確認實作的隔離單位範例。這的篇文章我們正在查閱如何使用 RSpec 的故事 Runner 接受測試，專注於驗證完成的應用程式堆疊而非獨立的區塊。

在第一個工作是參考 C# 的組件。 IronRuby 保留為 True，拼音的語言建構，並的結果參考 C# 程式庫參考拼音的程式庫相同：

require File.dirname(__FILE__) + 
  '/CSharpAssembly/CSharpAssembly/bin/Debug/CSharpAssembly.dll'

現在我們可以開始撰寫我們的案例，我們在前一個區段中定義的主體。要傳遞的案例，我們需要實作函式來計算訂單的總價格。在指定的區塊中, 您可以初始化物件所需的案例。我們的案例，唯一需要進行初始化的物件會在此時是產品物件。物件，建構函式會需要在的產品名稱] 和 [價格。兩者都是從方法參數，依次被取得從本身的案例中取得：

  Given("Product $productName at $price") do |productName, price|
    @product = CSharpNamespace::Product.new(productName, price.to_i)
  end

一旦我們擁有初始的物件，我們需要設定這些物件可測試的主旨的變數的狀態，；這發生在當區塊。在我們的實例，我們狀態使用者已排序的特定數目的授權，且我們的步驟需要反映這，並設定適當的物件狀態：

  When("user orders a $amount user license") do |amount|
    @order = CSharpNamespace::Order.new(@product)
    @order.NumberOfLicenses = amount.to_i
  end

最後，我們來到一部分，我們實際上驗證上述動作正常運作。在我們再的封鎖，我們定義我們期望和判斷提示。

這裡，我們要的順序，我們建立，，確認小計不會符合項目，我們在我們的案例中所定義的價格。應該延伸方法由動態建立 RSpec 讓我們來驗證事實上我們的陳述式的所有物件上；如果它不是 true，則會引發例外狀況：

  Then("the price should be $price") do |price|
    @order.Subtotal.should == price.to_i
  end

我們現在可以執行故事，使用下列命令：

>ir pricing_scenarios_for_product_x_story.rb

執行每個案例、 RSpec 會輸出 [新聞] 和 [到主的控台的案例，如果其中一個步驟失敗時, 它將會反白顯示特定的問題，並且表示在結束的總：

Running 1 scenarios
Story: Pricing for New Product X
  As a sales administrator, I want to be able to view prices for product x, 
  so that I can provide customers with an accurate cost for their requirements.

  Scenario: Single User License for Product X without support

    Given Product X at 250
    When user orders a 1 user license
    And this does not include support
    Then the price should be 250 (FAILED)

1 scenarios: 0 succeeded, 1 failed, 0 pending

如果一切順利，運作下列應該出現在命令列上，然後：

Running 1 scenarios
Story: Pricing for New Product X
 As a sales administrator, I want to be able to view prices for product x, 
 so that I can provide customers with an accurate cost for their requirements.
 Scenario: Single User License for Product X without support
  Given Product X at 250
  When user orders a 1 user license
  And this does not include support
  Then the price should be 250
1 scenarios: 1 succeeded, 0 failed, 0 pending

此時，我們可以開始建立其他的而更複雜的案例，包含更多的商務邏輯。例如，可能要包含在的價格折扣與尋找像這樣的案例：

Scenario: Single User License for Product X with 20% discount 
and includes 2 years unlimited premium support.
   Given Product X
   When user requests a 1 user license
   And including 2 years support
   And support length is unlimited
   And support type is premium
   And with 20% discount
   Then the price should be $800

如先前提及這些案例就會使用使其容易閱讀，不只是客戶，但任何人都商務的商業術語。

接受度測試 UI

在我的範例，著重商務邏輯和網域物件以測試是否邏輯運作順利，接受度測試。但如何與應用程式的使用者互動的呢？這些接受度測試應該有要確認是否正確，從使用者的觀點的邏輯，而使用者的觀點是 UI。

個人，我認為接受度測試應該專注於應用程式邏輯] 和 [重要區段程式碼，以決定要執行。如果您的應用程式好 decoupling 和邏輯和 UI 程式碼好分離，這應該讓測試更容易實作。如果您正在測試在這個層級，測試 UI 不會影響的變更。

專心測試應該只在邏輯，這並不代表您不應該有任何的接受度測試周圍 UI 中。我喜歡將一組煙霧測試目標，核心「快樂路徑」的 UI。它們著重於應用程式，使用者最有可能使用的大部分的值從最少量的測試目標的部分。如果您嘗試以涵蓋所有可能的路徑和在的 UI 的使用，而且如果 UI 變更 (例如，移動至不同的對話方塊的選項) 時，然後您必須變更所有的測試。

例如，如果您已測試的電子商務網站，UI，快樂的路徑將以選取的項目，將它加入至您的購物車、簽出，請參閱購買的確認。如果這種情況下失敗，您希望儘快知道。

對於某些，依賴應用程式的複雜度和存留期 (Lifetime)，您可以有更多的接受度測試 UI，以確保您具有更多的信心，在 UI 層上執行。成功測試 UI 是一個複雜的主題不過，我沒有空間以這裡涵蓋。我建議您閱讀我部落格張貼在專案上測試 WPF 的白色和測試 Web 應用程式的 WatiN. 此外，James McCaffrey 已寫入上 Windows PowerShell 的 UI 自動化在 12 月) 2007 中發行的 MSDN Magazine .

向前移動

這時候，您就可以準備開始將 IronRuby 使用您的接受度測試。此處的資訊應該取得您開始，但您應該牢記的事項。

一個的可能問題是 IronRuby 不是供生產使用還中。雖然您可以今天使用，會繼續開發和 IronRuby 和 RSpec 的。這表示修正錯誤，也可能的重大變更。也有問題的 RSpec 的執行速度。不過，值得評估問題是否超過您取得在簡化您的測試優點。

有些人可能會保留的另一個問題與相關內容切換。一般來說，人喜歡以相同的語言撰寫測試和實際執行程式碼。我通常同意，您正在進行大量的參數，在每天的單元測試時您可能不想使用 IronRuby 和 RSpec。不過，接受度測試，數量內容切換需要是更低。如此一來我認為您可以調整，則內容，以利用可讀性」和「更自然的方式撰寫案例與驗證，因為它們會提供開發小組和客戶的龐大的優點的切換。

在結束，整合接受度測試到開發處理程序，可以是 Load 正為開發組織的步驟。利用技術 (例如新聞和案例客戶導向的詞彙定義功能，加上可讀取 (但) 自動化的接受度測試，就可以建立更受信任的合作關係，與您的客戶，並將持續提供更穩定和可靠的軟體。

在英國的 C# 開發 / 軟體測試人員與一個強式的熱情，軟體開發 Ben Hall 。他會愛上撰寫程式碼。 Ben 在紅色的閘道軟體測試工程師並且樂於探索種，包括手動和自動測試，專注於測試不同類型的應用程式最好的方法的測試軟體。 Ben 會是 C# MVP，並維護在部落格 Blog.BenHall.Me.uk

其他資源