BPEL単体テストのための テストケース生成手法の提案と実現 Design and Implementation of Test Case Generation Tool for BPEL Unit Testing おはようございます。 井上研究室のChoyです。 本日は「BPEL単体テストのためのテストケース生成手法の提案と実現」について発表いたします。 宜しくお願いします。 井上研究室 博士前期課程２年 Choy Kho Yee

概要 背景 提案手法 実験 BPELによるサービスの記述とそのテスト方法 テスト対象の入出力データの型情報と依存関係を利用して、一貫性をもつテストデータを生成 テストデータを用いてテストケースを構築 実験 提案手法を実装したシステムを実際に運用してもらい、評価実験を行った 本日はまず研究の背景であるBPELによるサービスの記述とそのテスト方法を説明します。 つぎに、テスト支援を目的として提案したテストケース生成手法について説明します。 提案手法では、テスト対象の入出力データの型情報と依存関係を利用して、一貫性を持つテストデータを生成します。 そして、生成されたテストデータを用いてテストケースを構成します。 最後に、提案手法を実装したシステムを実際に運用してもらい、評価実験を行いました。 その結果についても報告いたします。 CS専攻 修士論文発表会 2008/02/15

SOAとBPEL サービス指向アーキテクチャ（SOA）とは、ネットワーク上の「サービス」をメッセージ通信で呼び出すアーキテクチャ 一般的にXMLメッセージを利用 ウェブサービスビジネスプロセス実行言語(BPEL)とは、サービス合成のために設計されたXMLベースの言語 WSDL、XML Schema、XPathを利用 BPELで書かれたプログラムはBPELプロセスという 本研究の背景には、SOAとBPELがあります。 サービス指向アーキテクチャ（SOA）とは、ネットワーク上の「サービス」をメッセージ通信で呼び出すことによって、ソフトウェアシステムを構築する開発手法です。 一般的に、XMLメッセージを通信に利用します。 一方、ウェブサービスビジネスプロセス実行言語（BPEL）は、これらのサービスを合成するために設計されたXMLベースの言語です。 BPELは、WSDLやXML Schema、XPathなどの既存XML技術を利用します。 また、BPELで書かれたプログラムはBPELプロセスといいます。 CS専攻 修士論文発表会 2008/02/15

BPELプロセスの例 XMLデータ通信 パートナー サービス BPELプロセス クライアント オペレーション GeoInfo <request> <search>tropical island</search> </request> <query> <keyword>tropical island</keyword> </query> GeoInfo <response> <result>Hawaii</result> <result>Bali</result> </response> クライアント オペレーション <query> <from>Japan</from> <to>Hawaii</to> </query> Currency Exchange <response> <result>…</result> </response> ここでBPELプロセスの例を示します。 BPELプロセスはクライアントからXMLデータを受け取り、必要に応じてパートナーサービスが提供するオペレーションを呼び出します。 この例では、BPELプロセスはクライアントから検索キーワードを受け取り、それをGeoInfoサービスへ転送して、キーワードに関連する地名を検索します。 次に、結果として受け取った地名をCurrencyExchangeサービスへ転送し、為替レートを取得します。 最後に、結果を整理してクライアントに返します。 <query> <from>Japan</from> <to>Bali</to> </query> CS専攻 修士論文発表会 2008/02/15

BPELプロセスの単体テスト パートナー サービス BPELプロセス クライアント GeoInfo CS専攻 修士論文発表会 <request> <search>tropical island</search> </request> <query> <keyword>tropical island</keyword> </query> GeoInfo <response> <result>Hawaii</result> <result>Bali</result> </response> クライアント <query> <from>Japan</from> <to>Hawaii</to> </query> Currency Exchange <response> <result>…</result> </response> BPELプロセスの単体テストでは、クライアントおよび各パートナーはBPELプロセスの単体テストフレームワークによって仮に立ち上げられます。 <query> <from>Japan</from> <to>Bali</to> </query> CS専攻 修士論文発表会 2008/02/15

BPELプロセスの単体テスト BPELUnit BPELプロセスの単体テストフレームワーク 代理クライアント BPELUnit BPELプロセスの単体テストフレームワーク P. Mayer, D. Lübke, Towards a BPEL unit testing framework. TAV-WEB’06, July 17, 2006. 代理パートナーサービス GeoInfo BPELプロセスは、これらの代理クライアントと代理サービスと通信を行い、代理クライアントと代理サービスはBPELプロセスからの出力を検証します。 この単体テストの仕組みはBPELUnitとして実装されました。 Currency Exchange CS専攻 修士論文発表会 2008/02/15

BPELUnitのテストケース作成 依存関係を満たしたテストデータを 一貫性を持つテストデータという 依存 検証 検証 検証 検証 テストパス XML 依存 検証 XML 検証 XML 検証 XML 検証 BPELUnitのテストケースを作成するために、2つのステップが必要です。 まず、そのテストケースの中に、テストしたいBPELプロセスのパスを決定し、そのパス上に呼び出されるサービスをきめます。 次に、クライアントと各サービスがテスト対象に送信するXMLデータと、テスト対象からの出力を検証するための検証式を作成します。 これからは、このXMLデータと検証式のことをまとめてテストデータといいます。 テストデータ間には依存関係が存在します。 たとえば、このXMLデータに入っている情報がここに出てくるという前提があれば、ここの検証式でその値が正しくでてきているかを検証します。 ここで、依存関係を満たしたテストデータのことを、一貫性を持つテストデータといいます。 依存関係を満たしたテストデータを 一貫性を持つテストデータという CS専攻 修士論文発表会 2008/02/15

BPELUnit TestSuite Editor BPELUnitの付属ツールBPELUnit TestSuite Editorでは、開発者は送信データや検証式を手入力で行わなければなりません。 検証式の指定 送信データ入力 CS専攻 修士論文発表会 2008/02/15

研究の動機と目的 一貫性をもつテストデータを作成するのが困難 サービスが送受信するXMLデータの構造が複雑 既存ツールは、テストデータの作成を支援していない 一貫性をもつテストデータの作成を中心に、テストケース作成を支援するツールの提案および実装 しかし、サービスが送受信するXMLデータの構造が一般的に複雑であり、既存ツールでは、テストデータの作成を一切支援していませんので、一貫性を持つテストデータを作成するのが困難です。 したがって、本研究では、一貫性を持つテストデータの作成を中心に、テストケース作成を支援するツールの提案および実装を目的としました。 CS専攻 修士論文発表会 2008/02/15

着目点 BPELはサービスの合成を目的に設計されたため、高度なデータ処理機能がない[1] BPELでは、データ処理にXPathを標準に採用している 従って、BPELの入出力データ間での関係は 簡単なXPath式で記述できると考えられる 一貫性をもつテストデータを作成するために、本研究ではBPELのデータ処理機能に着目しました。 設計目的のため、BPELプロセスの主な働きはサービスの合成なので、BPELには高度なデータ処理機能はありません。 また、BPELでは、データ処理のためにXpath式を標準に採用しています。 従って、BPELの入出力データ間での関係は簡単なXpath式で記述できるのではないかと考えました。 [1] F.Leymann, D.Roller, S.Thatte, Goals of the BPEL4WS Specification. CS専攻 修士論文発表会 2008/02/15

XPath式 XML文書から情報を抽出するための式 XML文書を木として扱い、経路で要素を特定 関数によって真偽値、ノード、ノードの集合を返す XML文書 XPath式 結果 /response/result[1]/text() “Hawaii” count(/response/result) 2 /response/result 2つのresultノード <response> <result>Hawaii</result> <result>Bali</result> </response> XPath式とは、XML文書から情報を抽出するための式です。 たとえば、このXML文書に対して、これらのXPath式を適用すると、それぞれに対してこのような結果が返されます。 CS専攻 修士論文発表会 2008/02/15

提案手法 開発者は、テスト対象のプロセスが呼び出すパートナーサービスのオペレーション集合を指定する 開発者は、これらのオペレーションの入出力間での依存関係をXPath式を用いて指定する システムは、データ間での依存関係に基づき必要なデータを生成する 独立入力 – XMLスキーマに従ってランダムに生成 依存入力 – XPath式に従って生成 依存出力 – XPath式に従って検証式を生成 独立出力 – 開発者が明示的に指定した値で検証式を生成 システムは、生成されたテストデータを用いてテストケースを構築する 提案手法では、この4つのステップでテストケースを作成します。 まず、開発者は、テスト対象のプロセスが呼び出すパートナーサービスのoperation集合を指定します。 つぎに、開発者がこれらのoperationの入出力間での依存関係をXPath式を用いて指定します。 開発者が行う作業はこれで終わります。 それから、システムがデータ間での依存関係に基づき必要なデータを生成します。 まず、テスト対象への独立な入力について、XMLデータをXMLスキーマにしたがってランダムに生成します。 ほかのデータにオゾンする入力と出力について、Xpath式に従ってデータと検証式を生成します。 しかし、独立な出力については、開発者が明示的に指定した値で検証式を生成します。 最後に、システムが生成されたテストデータを用いて、テストケースを構築します。 CS専攻 修士論文発表会 2008/02/15

データ依存の種類 /request/search = /query/keyword 代入 多重度 /response/resultの数 <search>tropical island</search> </request> <query> <keyword>tropical island</keyword> </query> GeoInfo <response> <result>Hawaii</result> <result>Bali</result> </response> <query> <from>Japan</from> <to>Hawaii</to> </query> Currency Exchange /response/resultの数 = count(/response/result) 本研究で対象とするデータ依存の種類を、例をとおして説明します。 代入とは、依存元の値は、ほかのデータに依存し、指定されたXPath式の演算結果の値、または、固定値であるような依存です。 たとえば、GeoInfoの検索キーワードは最初にプロセスに入力されたキーワードと同じです。 そして、多重度とは、依存元の発生回数は、ほかのデータに依存し、指定されたXPath式の演算結果の値、または、固定値であるような依存です。 ただし、依存元として、XMLデータだけではなく、Operationも指定できます。 <query> <from>Japan</from> <to>Bali</to> </query> オペレーションの呼出回数 = count(/response/result) <response> <result>…</result> </response> CS専攻 修士論文発表会 2008/02/15

システム構成 BPEL Data Dependency Editor BPEL Data Dependency Description XMLデータの型情報 データ依存情報 BPEL Data Dependency Editor Eclipseのプラグインとして実装 開発者にデータ依存を定義するGUIを提供 BPEL Data Dependency Description データ依存を記述したXML文書 Test Case Generator テストデータとテストケースを生成 提案手法を次の3つの部分に分けて実装しました。 BPEL Data Dependency Editor は Eclipse のプラグインとして実装され、開発者にデータ依存を定義するGUIを提供します。 定義したデータ依存は BPEL Data Dependency Description という XML 文書に記録されます。 Test Case Generator は、BPEL Data Dependency Description ファイルに記述されたデータ依存情報と、各サービスの WSDL ファイルから取得できる XML データの型情報に基づき、テストデータとテストケースを生成します。 CS専攻 修士論文発表会 2008/02/15

BPEL Data Dependency Editor テストケース関連 オペレーション 集合の一覧 XMLデータ 構造の表示 Xpath式挿入 データ依存 記述・追加 これが BPEL Data Dependency Editor のメイン画面です。 開発者が、テストケースに関連するoperation集合を一覧から選択すると、それぞれのoperationが送受信するXMLデータの構造が画面の右側にツリーとして表示されます。 このツリーの上で右クリックやダブルクリックをすれば対象ノードに対応するXPath式が自動的に挿入されます。 開発者はデータ依存の種類やほかのパラメータを設定してから、データ依存を実際に追加します。 追加されたデータ依存の一覧は画面の下に表示されます。 追加された データ依存一覧 CS専攻 修士論文発表会 2008/02/15

テストデータの生成 データ依存テーブルを利用して生成できるデータから順に 生成していく （1回目呼出の）データ依存テーブル データ格納用テーブル ID データ 依存先IDの集合 1 BPEL IN [ ] 2 BPEL OUT [4] 3 GeoInfo IN [1] 4 GeoInfo OUT 5 Currency IN 6 Currency OUT データ 1回目呼出用 2回目呼出用 (1) BPEL IN (2) BPEL OUT (3) GeoInfo IN (4) GeoInfo OUT (5) Currency IN (6) Currency OUT XMLデータ XMLデータ XMLデータ XMLデータ XMLデータ XMLデータ XMLデータ XMLデータ XMLデータ XMLデータ 次に、テストデータの生成について説明します。 テストデータはデータ依存テーブルを利用して生成します。 データ依存テーブルには、データの内部IDと依存先IDの集合が記録されています。 さきほどの例では、3番のGeoInfo の入力は1番のBPELプロセスの入力に依存しています。 テストデータは依存先のデータがそろっているものから生成します。 全てのデータが生成された時点で、テストデータの生成プロセスが終了します。 ただし、この例では、CurrencyExchangeのoperationが2回呼び出されるため、そのためのデータも必要となります。 このデータもさきほどと同じように生成されます。 XMLデータ XMLデータ CS専攻 修士論文発表会 2008/02/15

テストケースの生成 生成されたテストデータを用いてテストケースを 作成していく データ格納用テーブル データ 1回目呼出用 2回目呼出用 (1) BPEL IN (2) BPEL OUT (3) GeoInfo IN (4) GeoInfo OUT (5) Currency IN (6) Currency OUT XML XMLデータ XMLデータ XMLデータ XMLデータ XMLデータ XMLデータ XML XMLデータ XMLデータ XMLデータ XMLデータ XML 検証 XMLデータ XMLデータ 最後に、生成されたテストデータを用いて、テストケースを作成します。 テストケースのひな形に対して、Operationの呼出回数に配慮しながらデータを埋めていきます。 生成されたテストデータを用いてテストケースを 作成していく CS専攻 修士論文発表会 2008/02/15

適用実験の概要 対象：BPEL初心者の大学院生（M1）4名 利用ツール 手順 評価点 BPELUnit TestSuite Editor（従来ツール） BPEL Data Dependency Editor（提案ツール） 手順 予め決められた順番で2つのBPELプロセスのためのテストケースを異なるツールで作成してもらう 評価点 テストケースの性質 一般的な間違い 提案手法の有効性を評価するために、適用実験を行いました。 実験に協力してくれたのは、BPEL初心者の大学院生4名です。 そして、テストケースの作成に利用したツールは、従来ツールである BPELUnit TestSuite Editor と、提案手法を実装した BPEL Data Dependency Editor です。 被験者は、予め決められた順番で2つのサンプルBPELプロセスのためのテストケースをそれぞれ異なるツールで作成しました。 今回の実験を通して、作成されたテストケースの性質およびよくされる間違いについて考察しました。 CS専攻 修士論文発表会 2008/02/15

実験結果：性質 検証式の数の比較では、提案手法で作成した方が多い ⇒ XMLデータ構造の表示が有効 CS専攻 修士論文発表会 作成したテストケースに対して、記述した検証式の数を比較してみたところ、全てのテストケースにおいて、同じぐらいの時間で、提案手法で作成した検証式の方が多いことがわかりました。 これは、XMLデータ構造をツリーとして開発者に表示したためだと思います。 CS専攻 修士論文発表会 2008/02/15

実験結果：間違いの種類 BPELUnit TestSuite Editor BPEL Data Dependency Editor XML namespace関連 wsdl:p:element 必要なnamespaceの入れ忘れ 不必要なnamespaceの記述 無し XPath関連 途中要素の書き忘れ e.g. /a/b/c → /a/c スペルミス 構文上の間違い データ関連 サービスAがサービスBのデータを送信 必要なデータ依存の欠如 また、作成したテストケースから犯しやすい間違いを整理してみました。 その結果、BPELUnit TestSuite Editor では、XML namespaceやXPath 関連の間違い、そして送信データ関連の間違いが多かったです。 一方、提案手法では、それらの間違いはほぼ存在しません。 その代わりに、手法について十分に理解していないため生じた間違いが目立ちます。 この結果から、提案手法を十分に理解するために少し時間がかかるかもしれませんが、実装をさらに改良すれば従来ツールの問題を解決できることが十分期待できます。 CS専攻 修士論文発表会 2008/02/15

まとめと今後の課題 まとめ 今後の課題 BPELプロセスの単体テストを支援するために、テストケースを生成する手法を提案及び実装した 評価実験では、送受信データの間違いが従来ツールより減少 今後の課題 手法とユーザインターフェイスの改良 BPEL開発者での評価実験 最後に、まとめます。 本研究では、BPELプロセスの単体テストを支援するために、テストケースを生成する手法の提案及び実装を行いました。 また、手法の有効性を評価するために適用実験を行い、データの作成間違いが防げることを確認しました。 今後の課題として、実験結果に基づき手法とツールのGUIを改良することと、BPEL熟練者での適用実験を行うことが考えられます。 ありがとうございました。 CS専攻 修士論文発表会 2008/02/15