在協助兩個不同的健康保險提供商進行功能測試自動化部署時，我發現了來自EDI數據的挑戰所具有的一些共性：

1. 大多數EDI工作流程都是從實際的文件刪除開始的。模擬該文件刪除具有挑戰性。
2. 單個交換可以是方言，版本和消息類型的組合。生成符合該特定架構的消息可能很乏味。
3. 使用數據驅動EDI消息是必要的。它可能變得過于復雜，尤其是在管理層次結構和數據類型時。

在這篇文章中，我將深入探討測試人員在使用EDI時面臨的挑戰，以及如何開始使用自動化測試解決這些挑戰。

電子數據交換（EDI）

首先，讓我們回到基礎。 EDI是一種消息格式標準，用于在業務實體之間傳達業務信息。過去，企業通常使用紙張進行交易（例如，訂購單，發票或在醫療保健行業，例如報名表），這非常復雜且容易出錯：

為了改進流程，EDI旨在標準化通信并進行“無紙化交換”：

不幸的是，盡管EDI通過允許公司以電子方式而不是紙質方式發送信息來改進了流程，但EDI也帶來了自身的挑戰。最近，我已經能夠使用我們的軟件測試工具來幫助人們解決這些問題，并且很高興與您分享該解決方案。

在EDI測試期間（輕松！）管理數據

在這些最新的醫療保健部署中，我正在與使用HIPAA標準消息定義來生成834文件作為請求和響應的組織一起工作。這些有效載荷是固定長度的，并且可能非常復雜。

對于這兩個團隊，他們都需要發送和接收文件以進行測試。由于他們沒有辦法將實際的EDI消息發送到系統中，因此必須使用物理文件。他們將收到一封包含該文件定義的電子郵件，將該文件放到exchange文件夾中，然后手動驗證返回的結果。數據是預先創建的，并以適當的格式放入文件中，但是修改起來并不容易。將適當的數據輸入系統并使用相同的數據源進行驗證是極其困難的。

改善EDI工作流程

在這些部署中，我將Parasoft SOAtest和Virtualize添加到他們的工作流程中，它們通過消息包可以提供可以實時生成的此類定義的庫。這樣，兩個團隊都能夠生成必要的消息，并且（更重要的是）數據驅動請求和響應。（這是在發送請求并最終驗證響應時。） 

使用SOAtest和Virtualize，我們還改善了它們處理分層EDI的方式。數據存儲庫無縫處理分層數據，這使它們可以創建非常易于交互的數據結構，該結構可用于請求和驗證。我想象任何使用EDI和File數據源的人都會立即理解為什么這對我的客戶如此令人興奮。

因此，現在讓我們逐步解決為解決這一難題而建立的工作流程，您也可以做到。

操作方法如下：使用SOAtest和Virtualize可以更輕松地處理EDI消息

我們從包含的834文件EDI消息模式開始。

使用SOAtest可以更輕松地使用EDI，因為SOAtest包含內置的這些消息的庫，您只需從下拉列表中選擇消息Dialect，Version和Type。您的有效負載會立即顯示出來，并準備驅動數據。接下來，我可以為默認消息填寫一些值。這些可能是我知道不會更改的數據值。

然后，我可以直接從編輯器中立即為有效負載創建一個層次數據源，而無需擔心將響應元素映射到有效負載，因為這都是自動完成的。這將為我生成一個易于使用的數據源。

創建該數據源后，就可以像添加電子表格一樣輕松地添加，刪除和更改數據。數據在Virtualize的瘦客戶端界面中表示-這是測試數據管理器中數據編輯器的外觀：

一切就在這里：無縫的工作流程將您帶到EDI定義到直觀的數據源。

對于我最近的部署，這一直是一個很大的麻煩，它使團隊能夠獲得他們傳統上難以解決的驗證部分。他們可以輕松地將新用例添加到數據源中，并從中進行驗證。

另外，我們能夠使用http直接將調用發送到系統中，但是通過將輸出轉換為文件，將表單放置在適當的文件夾中以及設置文件偵聽器來接收響應，從而模擬了實際的文件刪除。

自動化EDI文件處理

那里有。當您要處理復雜的消息格式或協議時，擁有一個功能強大的測試工具為您服務而不是不利于您，將會產生巨大的變化。當我們部署Parasoft SOAtest＆Virtualize時，它可以避免使用復雜，遺留或不常見的用例而產生的猜測，并且您使用EDI消息創建的所有測試用例和模擬服務都可以無縫地適合您現有的測試設計范例，從而為您節省了成本。大量的時間。

使用EDI還是其他行業特定的消息格式？獲得有關涉及EDIFACT，HL7，HIPAA，X12和其他消息格式的測試交易的關鍵見解。