針對 SAP 集成應用軟件的測試自動化

針對 SAP 集成應用軟件的測試自動化

作者: 未知    來源: 網絡轉載

        在假設您需要可以像配置并定制 SAP 全景那樣迅速地配置并定制的測試解決方案的情況下，隨著環境的變更，SAP 集成應用程序允許您快速地配置并定制業務流程。在本文中，我們將向您展示如何使用 IBM® Rational® Functional Tester 工具集和來自 IBM Ready-for-Rational 合伙人，Arsin，的工具。Arsin 的 QA Mapper、Effecta Validation Engine，和 Arsin Support 及升級工具包允許您開發面向 SAP 全景的可復用的、可重復的，并且很容易維護的 SAP Test Automation 回歸庫，包括定制的應用程序和進入或輸出（Inbound/Outbound）接口。

我們將討論：

        結構化的 SAP 測試方法
        SAP 當前的測試自動化范型及其挑戰
        用于 SAP 測試自動化的新解決方案的需求
        與 IBM Rational Functional Tester（RFT）集成的 Arsin Packaged Test Automation for SAP 如何幫助解決這些難題。
        我們將分析 QA Mapper、Effecta validation Engine 和 Arsin Support 及升級工具包，連同 RFT 的功能，從而收集測試需求、定義并構建測試用例、構建測試規程，并執行和分析報告。使用 RFT 和 Arsin 的工具能讓您大大地擴展測試范圍，較大地壓縮測試進度，并減少測試成本。

結構化的 SAP 測試方法

        涉及了超過 45000 個表，超過 100000 個字段，以及它們之間上百萬的關系，SAP 實現提出了一些 QA 領域最引人興趣且最困難的挑戰。網絡密集的系統是極度集成的，并且一般與企業中的每個業務流程都相連。要處理這樣一個極廣大的系統，QA 工程師必須謹慎地處理 SAP 應用程序。

        利用十多年來為無數行業中的大型客戶基礎測試 SAP 系統的經驗，我們已經開發了測試成熟度評估及改進框架，以提出一種有組織的，結構化的 SAP 測試方法。該框架有三種方法，它們提供過程改進、知識管理和測試自動化，如下所示：

        過程改進。過程改進處理當前測試成熟度模型的評估，并且開發計劃來將測試成熟度模型提高到下一層，并實現它。擁有標準化的模板、定義良好的過程、清楚的協議，并且沒瓶頸的成熟的測試過程為完整的且全面測試過的 SAP 系統做準備。通過將當前的測試成熟度模型與行業標準進行比較，并且識別差距并著重于它們，可以改進測試成熟度。
        知識管理。知識管理處理隨時收集的 QA 知識的制度化。傳統的 SAP 系統測試依賴于 SAP 系統的功能及技術顧問，了解關于主題的專家經驗，從而處理各種各樣的實例。在此階段，為關鍵的業務流程構建測試工件庫，用于回歸。以下的測試工件被編制為：
        測試需求
        測試用例
        測試規程
        測試自動化。在知識管理階段，當在回歸庫中編制了測試工件之后，就準備好將它們自動化。然而，在將它們自動化之前，對這些測試工件進行自動化可行性，自動化所需的工作、業務流程使用的頻率，及業務的壽命的分析。在決定利用 Arsin 的 QA Mapper 作為測試工件存儲庫進行自動化之后，就利用 RFT 開發執行組件，并且利用 Arsin 的 Effecta Validation Engine 配置驗證組件來自動地執行它們。
        本討論的其余部分著重于結構化的 SAP 測試方法的測試自動化方面。我們相信 RFT 結合 Arsin 的 QA Mapper 和 Effecta Validation Engine 令 SAP 測試徹底、全面、簡單，且節省成本。

SAP 實現中測試自動化的重要性

        SAP 全景在不斷地變更，這是由于對來自 SAP 的 SAP 模塊的變更、客戶公司中的業務流程變更、對系統環境的變更、對與 SAP 連接的應用程序的變更，以及許多規章法令。

        圖 1 例舉了在 SAP 環境中不斷運轉的相關性。

圖 1：SAP 環境中的相關性

        為了跟上這些變更，必須對 SAP 系統進行徹底地測試。對于每個變更，都有需要確保穩定性而執行的測試用例的回歸庫。當手動執行時，每個測試需要時間和努力，比較起來，執行自動的測試需要非常少的時間和努力。自動化還幫助讓大多數測試資產可復用。

        當前的 SAP 測試解決方案及其局限性

        如今，市場上的現有 SAP 測試模型初步地使用自動化，涉及以下方面：

驗證：在大多數情況下，可用的 GUI 工具用于將測試執行自動化，這只占總測試工作的大約 25%。驗證占該工作的 75% 以上，而且利用 GUI 測試自動化工具去除數據是很困難的。通過基于測試自動化工具的特定級別的驗證是可能的，然而，撰寫該驗證的腳本要花費很長時間，并且任何的變更都需要在首次實現之后的許多編碼工作。

        數據管理：傳統上，用于測試的數據是在電子表格中獲取并維護的。通過該數據進行搜索和排序是困難的，因為是維護跨用戶和位置的數據一致性。這種困難在隨著要維護的大量測試數據的增加而增加。此外，SAP 元數據與其相應的測試數據之間不存在智能的聯系。

        管理變更：對 SAP 實現的變更發生在重新配置或添加定制構建的組件（程序）的過程中。在這些情況下，需要定期地變更用于自動的測試執行的腳本，這是很困難的。此外，當將 GUI 工具用于自動化時，需要經常地重做 75% 的工作，從而跟上對 SAP 系統的變更。

處理這些局限性

        上面介紹的局限性需要可以處理這些問題的新解決方案。我們提供了包含以下組件的解決方案：

Arsin QA Mapper
Arsin Effecta Validation Engine
IBM Rational Functional Tester
        如圖 2 所示，解決方案的主要組件是 QA Mapper（測試工件存儲庫）、RFT（自動地執行測試用例的引擎），及 Effecta （自動驗證引擎）。用于 SAP 程序和事務的元數據作為執行組件（Execution Component）存儲在 QA Mapper，RFT 讀取它們來執行事務。RFT 推動執行組件用使用來自 QA Mapper 的元數據的包裝腳本來執行測試用例。當執行測試用例時，該腳本拿出與測試用例相連接的測試規程，并執行組件或事務。對于驗證，關鍵的信息，例如銷售訂單數或交付數，被傳遞給 Effecta 驗證引擎，然后拿出與那些來自 SAP 數據庫的鍵相應的實際值，然后將它們與期望結果進行比較。

        圖 2：Arsin SAP 測試解決方案的主要組件

        圖 2 中展示的解決方案處理了早期模型所帶來的局限性?，F在我們將詳細地分析此解決方案。

測試數據管理

        在 QA Mapper 產品中，測試數據是在關系數據庫中進行管理的，這使得跨多用戶的搜索、排序，和一致性維護都很容易。QA Mapper 還根據可能復用的數據集對數據進行維護。這些數據集是分別創建的，以便可以在各種測試用例中復用它們。QA Mapper 能夠創建可以通過基于 web 的接口簡單地維護的具體工程的且安全的測試數據集。此外，輸入測試數據的創建是通過對來自在測系統的主數據的自動導入來加速的。

管理變更

        該解決方案提供了不需要任何腳本變更的完全可定制且可配置的組件。使用實際數據之上的包裝腳本和元數據意味著，對于屏幕上任意的附加的字段，只有元數據需要添加到數據庫中。該特性節省了許多時間和工作量。

驗證

        Arsin 的驗證測試引擎，稱為 Effecta（參見右邊圖 2），推動了 QA 團隊需要執行的每個測試用例的自動化的驗證。驗證令差不多 75% 的測試工作在手工場景下進行。通過 Effecta 的自動化減少了這一時間，并且生成了關于哪些驗證失敗了的詳細報告，因而簡化了失敗情況下的調試過程。該工具還生成審計可追蹤、可重復，且可伸縮的 QA 測試結果。

業務對象的配置和定制

        將驗證自動化的規程涉及業務對象及驗證組件的創建。業務對象是在 SAP 中的事務中使用或受到影響的所有表，以及這些表通過字段建立的關系的聚集。它構成了可以確定來自一個表的哪些字段與另一個表中的字段相關聯的連接平臺。業務對象是容易配置且可擴展的。當事務必須具有新功能或包含新表時，可以通過添加必需的表和新的關系來擴展基本的業務對象，如圖 3 所示。

         

        圖 3：通過添加必需的表和新的關系來擴展基本的業務對象。

驗證組件的創建、配置，及定制

        驗證組件是規則的集合，這些規則參考了必須被驗證，從而確保 SAP 系統的穩定性和一致性的字段。驗證組件使用業務對象來構成關聯底層的 SAP 表的平臺。這些組件中的驗證規則將表字段中的數據與來自不同數據源的預期數據進行比較，包括表字段和不變值。

        驗證組件通過配置進行維護，并且不涉及任何腳本。定制涉及變更規則，它們是選擇要驗證的表字段，以及選擇對于每個字段的預期源的操作。

        在完成驗證時，Effecta 引擎提供詳細的報告，如圖 4 所示，它精確地指出哪些字段沒有遵守驗證規則。這有助于故障跟蹤和修復。

        圖 4：精確地指出哪些字段沒有遵守驗證規則的詳細報告。

進入或輸出接口驗證

        除了為 SAP 中的事務提供驗證以外，Effecta 還提供進入和輸出接口驗證。這些接口中的傳輸通常是 Intermediate Documents（IDocs）、文本文件，等等的格式。當要驗證它們時，Effecta 從它們中析取數據并根據 SAP 中的表和字段驗證它們。

產品支持及支持包驗證

        當在升級過程中測試產品支持及支持包時，有兩個場景：一個是進行變更之前的場景，一個是變更之后的場景。在這些情況下的測試的目標是確保由于變更，系統仍舊穩定。

        在這些情況下，當執行事務時，更新表，創建文檔及 IDoc。在變更前后要對這些文檔、表，及字段進行比較。對于一個事務，例如銷售訂單的創建，可能有十五個表，以及將要在每個表中進行比較的十到十五個之間的字段。手工比較這些需要相當多的時間和努力。Effecta 擁有自動的工具來比較表、IDoc 和文檔，這有力地減少了這些情況下的時間和工作。這些工具還向測試人員提供描述結果的詳細報告。

        Arsin 目前正致力于為 Oracle 和 Sterling 平臺構建 Effecta 驗證引擎。

結束語

        在 SAP 測試中使用自動化的好處有很多。測試自動化增加了測試覆蓋面，從而減少了循環時間，并且在開發周期早期進行有效的故障檢測。由于測試自動化為復用性而設計，所以消除了日常的任務，并且減少了所有權的總成本。測試自動化更精確且更一致，并且是標準化的特性報告，能夠跨 QA 環境進行清晰的測試分析。測試自動化可以通過最小的努力進行部署。

原文轉自：http://www.kjueaiud.com