JP6986536B2 - リーン生産法をシステムデリバリテストに適用するウェブベースのアプリケーションプラットフォーム - Google Patents

Description

本開示は、全般的に、システムデリバリテストに関し、特に本開示は、システムデリバリテストにリーン生産法を適用するウェブベースのアプリケーションに関する。

企業は、設計、テストされて顧客に展開されるソフトウェアシステムを提供することができる。そのようなプロセスを、集合的に、デリバリと呼ぶことができる（例えば顧客のランドスケープへのソフトウェアシステムのデリバリ）。ソフトウェアシステムのデリバリ、特にテストは、多大な時間およびリソースを必要とする。サードパーティベンダが、コンピュータ実装されるツールを提供しているが、テストアーティファクトおよびデータを管理する大規模の完全なソリューションスイートはない。例として、従来のツールは、本質的に、テストライフサイクルをカバーするように極めて一般的であるか、またはテストデリバリの特定のフェーズ（例えば自動化）をカバーするように極めて特定的であるかのいずれかである。結果として、種々のテストアクティビティ（例えばテストの設計、テストデータマネジメント、テストアーティファクトの作成および実行、ＫＰＩレポート）の対象範囲で、（例えば顧客により）ソフトウェアデリバリプロジェクトに対して体系的に展開されない、または標準のアセットとして展開されない、種々のツールが必要とされる。要するに、確実な統合を可能にし、且つ／またはソフトウェアシステムのデリバリを加速する適切なツールまたはツールのスイートがない。

本開示の実装は、全般的に、システムデリバリテストを対象とする。特に、本開示の実装は、システムデリバリテストに対してリーン生産法を適用し、テストアーティファクトを構築および実行するためのコンピュータ支援によるテスト設計および実行ツールを含む、ウェブベースのアプリケーションを対象とする。

一部の実装において、アクションは、データドライブテスト（ＤＤＴ：ｄａｔａ ｄｒｉｖｅ ｔｅｓｔ）プラットフォームによって、テストデータを含む１つ以上のコンピュータ可読ファイルを受信することであって、テストデータは、ベンダバックエンドシステムにより少なくとも部分的にホストされるソフトウェアシステムのテスト中に少なくとも１つのトランザクションを実行するためのデータを含み、ソフトウェアシステムは顧客の使用のために構成される、受信することと、ＤＤＴプラットフォームによって、ベンダバックエンドシステム上のソフトウェアシステムにより実行される１つ以上のテストシナリオを提供することであって、１つ以上のテストシナリオは、テストデータの少なくとも一部を使用してソフトウェアシステムによりトランザクションを実施するためのアクティビティのセットを含む、提供することと、ＤＤＴプラットフォームのテストハーネスを使用した１つ以上のテストシナリオの実行を、ＤＤＴプラットフォームのスケジューラによりスケジュールすることと、ＤＤＴプラットフォームによりベンダバックエンドシステムからテスト結果を受信することと、比較を出力として提供するために、テスト結果と予期される結果とをＤＤＴプラットフォームにより比較することと、を含む。この側面の他の実装は、対応するシステムと、装置と、方法のアクションを実行するように構成されコンピュータストレージデバイス上にエンコードされたコンピュータプログラムとを含む。

これらおよび他の実装はそれぞれ、次の特徴のうちの１つ以上を任意選択で含むことができる：１つ以上のテストシナリオの実行が、テストハーネスによって、テストデータの少なくとも一部を第１の形式から第２の形式に変換することと、変換されたテストデータの少なくとも一部を、１つ以上のアプリケーションプログラミングインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）を介してソフトウェアシステムに送信することと、を少なくとも部分的に含むこと、１つ以上のＡＰＩが、ベンダバックエンドシステムにより公開されること、テストハーネスが、テスト結果を受信し、テスト結果と予期される結果とを比較し、比較を提供すること、１つ以上のテストシナリオが、ＤＤＴプラットフォームのテスト設計アプリケーションに対するユーザ入力に基づき提供されること、少なくとも１つのテストシナリオが、ＤＤＴプラットフォームの中央リポジトリに格納されたテストアセットの再利用に部分的に基づくこと、１つ以上のテストシナリオの実行が、ベンダバックエンドシステムのデータベース内に格納された１つ以上のデータオブジェクトに影響を及ぼすこと、およびテスト結果の少なくとも一部が、１つ以上のデータオブジェクトに対する変更を含み、予期されるテスト結果の少なくとも一部が、１つ以上のデータオブジェクトに対する予期される変更を含むこと。

本開示は、１つ以上のプロセッサに結合され命令が格納されているコンピュータ可読ストレージ媒体も提供し、命令は、１つ以上のプロセッサによって実行されると１つ以上のプロセッサに、本願明細書において提供された方法の実装に従った動作を実行させる。

本開示はさらに、本願明細書において提供される方法を実装するシステムを提供する。システムは、１つ以上のプロセッサと、命令が格納され１つ以上のプロセッサに結合されているコンピュータ可読ストレージ媒体とを含み、命令は、１つ以上のプロセッサによって実行されると１つ以上のプロセッサに、本願明細書において提供される方法の実装に従った動作を実行させる。

当然のことながら、本開示に従った方法は、本願明細書に記載される側面および特徴の任意の組み合わせを含むことができる。つまり、本開示に従った方法は、本願明細書に具体的に記載される側面および特徴の組み合わせに限定されず、提供される側面および特徴の任意の組み合わせも含む。

本開示の１つ以上の実装の詳細は、添付の図面および以下の説明に記載される。本開示の他の特徴および利点は、本記載および図面ならびに特許請求の範囲から明らかになるであろう。

本開示の実装を実行することができる例示のシステムを示す。 本開示の実装に従った例示の概念アーキテクチャを示す。 本開示の実装に従った例示のモジュールアーキテクチャを示す。 本開示の実装において実行可能な例示のプロセスを示す。

本開示の実装は、全般的に、システムデリバリテストを対象とする。特に、本開示の実装は、システムデリバリテストにリーン生産法を適用する、ウェブベースのデータデリバリテスト（ＤＤＴ）プラットフォームを対象とする。一部の実装において、ＤＤＴプラットフォームは、テストアーティファクトを構築および実行するための、コンピュータ支援によるテスト設計および実行ツールを含む。一部の実装において、アクションは、データドライブテスト（ＤＤＴ）プラットフォームによって、テストデータを含む１つ以上のコンピュータ可読ファイルを受信することであって、テストデータは、ベンダバックエンドシステムにより少なくとも部分的にホストされるソフトウェアシステムのテスト中に少なくとも１つのトランザクションを実行するためのデータを含み、ソフトウェアシステムは顧客の使用のために構成される、受信することと、ＤＤＴプラットフォームによって、ベンダバックエンドシステム上のソフトウェアシステムにより実行される１つ以上のテストシナリオを提供することであって、１つ以上のテストシナリオは、テストデータの少なくとも一部を使用してソフトウェアシステムによりトランザクションを実施するためのアクティビティのセットを含む、提供することと、ＤＤＴプラットフォームのテストハーネスを使用した１つ以上のテストシナリオの実行を、ＤＤＴプラットフォームのスケジューラによりスケジュールすることと、ＤＤＴプラットフォームによりベンダバックエンドシステムからテスト結果を受信することと、比較を出力として提供するために、テスト結果と予期される結果とをＤＤＴプラットフォームにより比較することと、を含む。

図１は、本開示の実装を実行することができる例示のシステム１００を示す。例示のシステム１００は、コンピューティングデバイス１０２、バックエンドシステム１０８およびネットワーク１１０を含む。一部の例では、ネットワーク１１０は、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ワイドエリアネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、インターネットまたはそれらの組み合わせを含み、ウェブサイト、デバイス（例えばコンピューティングデバイス１０２）およびバックエンドシステム（例えばバックエンドシステム１０８）を接続する。一部の例において、ネットワーク１１０には、有線および／または無線の通信リンク上でアクセスできる。例として、スマートフォンなどのモバイルコンピューティングデバイスは、セルラネットワークを利用してネットワーク１１０にアクセスすることができる。

示されている例において、バックエンドシステム１０８は、少なくとも１つのサーバシステム１１２およびデータストア１１４（例えばデータベースおよび知識グラフ構造）を含む。一部の例において、少なくとも１つのサーバシステム１１２は、ユーザがコンピューティングデバイスを使用して相互作用できるコンピュータ実装された１つ以上のサービスをホストする。例として、サーバシステム１１２は、本開示の実装に従ったシステムデリバリテストのためにＤＤＴプラットフォームをホストすることができる。

一部の例において、コンピューティングデバイス１０２は、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、タブレットコンピュータ、携帯情報端末（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、携帯電話、ネットワークアプライアンス、カメラ、スマートフォン、拡張汎用パケット無線サービス（ＥＧＰＲＳ：ｅｎｈａｎｃｅｄ ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ）モバイル電話、メディアプレーヤ、ナビゲーションデバイス、電子メールデバイス、ゲーム機またはこれらのデバイスもしくは他のデータ処理デバイスの任意の２つ以上の適切な組み合わせなど、任意の適切なタイプのコンピューティングデバイスを含むことができる。

一部の実装において、バックエンドシステム１０８は、本開示の実装に従ったシステムデリバリテストのためにＤＤＴプラットフォームをホストする。本願明細書にさらに詳細に記載されるように、本開示のＤＤＴプラットフォームは、ユーザ１２０（例えばまたは複数のユーザ）が、顧客のためにソフトウェアシステムの構成をテストするためのシナリオを定義することを可能にする。例として、ソフトウェアシステムは、企業により提供可能であり、クライアント側（例えば客先）で統合されるコンポーネントおよびバックエンドシステム１１０上で実行されるコンポーネントを含むことができる。例として、バックエンドシステム１１０は、企業により運用可能であり、１つ以上のアプリケーションプログラミングインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅｓ）を介してアクセス可能なソフトウェアシステムのコンポーネントをホストすることができる。ソフトウェアシステムを提供する例示の企業には、ドイツ、ヴァルドルフのＳＡＰ ＳＥが含まれるが、限定はされない。例示のソフトウェアシステムには、エンタープライズリソースプラニング（ＥＲＰ：ｅｎｔｅｒｐｒｉｓｅ ｒｅｓｏｕｒｃｅ ｐｌａｎｎｉｎｇ）システムが含まれ得るが、限定はされない。なお、本開示の実装は、任意の企業の任意の適切なソフトウェアシステムを使用して実現できると考えられる。

一般に、本願明細書にさらに詳細に記載されるように、本開示のＤＤＴプラットフォームは、ソフトウェアシステムのテストデリバリおよびカスタマイズをサポートする。例として、ＤＤＴプラットフォームは、すべてのトランザクションおよびプロセスの統合を含むシステムテストをサポートする。一部の例において、ＤＤＴプラットフォームは、完全な統合テストおよび顧客のレガシーシステムとの通信をサポートする。本開示のＤＤＴプラットフォームは、データベース内のデータオブジェクトに直接影響するテストシナリオを実行して、統合が適切に実行するかどうか（例えばデータベース内でデータオブジェクトが適切に更新されたか）を観測する。つまり、従来のツールと比較して、本開示のＤＤＴプラットフォームは、より広範囲のテストを提供する。データオブジェクトに対する変更の影響は、数百のテーブルにわたって、さらに各モジュールにわたって発生する可能性があり、これを本開示のＤＤＴプラットフォームを使用して観測できる。

一般に、本願明細書にさらに詳細に記載されるように、ＤＤＴプラットフォームは、ユーザ（例えば客先で企業のソフトウェアシステムを統合するコンサルタント）が、（例えば、１つ以上のＡＰＩを介して、統合されるソフトウェアシステムを提供する企業のバックエンドシステム上で実行される、データに基づくテストケースを構築することを可能にする。一部の例において、シナリオは、ＡＰＩを介して実行される複数のテスト要素（例えばアクティビティ）を含む。一部の例において、アクティビティは、データベース内のデータオブジェクトに対して実行されるトランザクションのセットを含む。本願明細書にさらに詳細に記載されるように、テストシナリオは、（例えば夜間に）アクティビティを実行するＤＤＴプラットフォームのスケジューラにプッシュされる。同じく本願明細書にさらに詳細に記載されるように、ＤＤＴプラットフォームのハーネスは、テストファイルからデータを得て、データを適切な形式（例えばＪＳＯＮ）に変換し、テスト中のソフトウェアシステムにＡＰＩを介してデータを送信し、テストの結果を受信し、比較（例えば実際の結果対予期される結果）を提供する。一部の例において、結果は、予期しない何らかの変化を特定するための、データオブジェクトの比較（例えばフィールド対フィールド、テーブル対テーブル）を含む。

本開示の実装のコンテキストを提供すると、上記で導入されたとおり、企業が顧客にソフトウェアシステムを提供することができる。ソフトウェアシステムは、デリバリプロセスにおいて顧客に提供され得る。例示のデリバリプロセスは、計画、設計、構築、テストおよび展開フェーズを含むことができるが、限定はされない。従来のソフトウェアシステムデリバリは、１つ以上のデリバリツールを使用して実行され得る。例示のデリバリツールには、アプリケーション設計、モデリングおよび開発ツール（例えばＩＢＭ Ｒａｔｉｏｎａｌ Ｓｏｆｔｗａｒｅスイート）、アプリケーションライフサイクルマネジメント（ＡＬＭ：ａｐｐｌｉｃａｔｉｏｎ ｌｉｆｅｃｙｃｌｅ ｍａｎａｇｅｍｅｎｔ）ツール（例えばＭｉｃｒｏｆｏｃｕｓ ＡＬＭスイート）およびテストマネジメントツール（例えばＸＲＡＹを使うＪＩＲＡ）が含まれ得る。他の例示のツールには、テストスクリプティングツール（例えばＭｉｃｒｏｆｏｃｕｓ ＵＦＴ、Ｗｏｒｋｓｏｆｔ Ｃｅｒｔｉｆｙ、Ｔｏｓｃａ Ｔｒｉｃｅｎｔｒｉｓ）が含まれ得るが、限定はされない。

テストデータマネジメントのために、サードパーティベンダがソフトウェアシステムのツールを提供している。しかしながら、テストアーティファクトおよびデータを管理する大規模の完全なソリューションスイートを提供するベンダはない。このような従来のツールは、本質的に、テストライフサイクルをカバーするように極めて一般的であるか、またはテストデリバリの特定のフェーズ（例えば自動化）をカバーするように極めて特定的であるかのいずれかである。結果として、種々のテストアクティビティ（例えばテストの設計、テストデータマネジメント、テストアーティファクトの作成および実行、ＫＰＩレポート）の対象範囲で、（例えば顧客により）ソフトウェアデリバリプロジェクトに対して体系的に展開されない、または標準のアセットとして展開されない、種々のツールが必要とされる。従来のテストスイートおよびスタック使用量テストの対象範囲のランドスケープは、確実な統合を可能にし且つ／またはソフトウェアシステムのデリバリを加速する適切なツールまたはツールのスイートがないことを示す。

ソフトウェアシステムのテスト方法を提供することができる。一部の例において、テスト準備は、構築フェーズにおいて開始され、ソフトウェアシステムの使用のケースのドキュメンテーションを提供することを含むことができる。このテスト準備は、ＡＬＭツールおよび／または他のアプリケーション（例えばＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ）によって集約／管理できる。一部の例において、ユーザ（例えばコンサルタント）は、ソフトウェアシステムの予期される挙動（予期される結果）に対して種々のアクション（テストステップ）の文字記述（テストケース）を提供する。

一部の例において、テスト準備は、テストケースにより消費される特定のデータの準備を含む。テストデータは、本番データおよび／もしくは移行データのサブセットを含むことができ、さらに／または（例えばユーザにより生成される）テストデータを含むことができる。テストデータの準備（例えば構築フェーズ中またはその後に実行される場合）は、データに適用されるソフトウェアシステムの各モジュールにわたる構成およびルールを深く理解していることを必要とするので、複雑である場合もある。結果として、アプリケーションテスタは、テスト用に特定目的のデータを作成するために、ソフトウェアシステムを完全に理解している必要がある。さらに、テスト準備アクティビティは時間がかかり、本番に展開されるソフトウェアシステムの品質を損なわずに簡潔にすることは難しい。

本願明細書にさらに詳細に記載されるように、前述の事項に鑑み、本開示の実装は、シフトレフト自動化（例えばより早期の段階のテスト）、継続的なテスト、データ指向型のテストおよび複数のプロジェクトにわたるテストアーティファクトの再利用という特質を含むＤＤＴプラットフォームを提供する。本開示のＤＤＴプラットフォームは、供給されるソフトウェアシステムをテストするためにシフトレフト手法をとり、ユーザ（例えば設計者）が構成ドキュメンテーションを作成しながらテストコンテンツをシームレスに構築することを可能にするテストツールを提供する。本開示のＤＤＴプラットフォームは、テストプロセスの産業化を加速するためにテストアーティファクトの共有も可能にする。さらに、データモデル主導の手法が提供され、データモデルは、ユーザ間で共有可能である。ソフトウェアシステムを提供する企業のＡＰＩを活用することにより、テストの自動化が実現される。一部の実装において、ソフトウェアシステムの供給されたコンポーネントに対して継続的なテストが提供される。ＤＤＴプラットフォームは、テストアーティファクトの設計のための、顧客およびプロジェクト特有のプラットフォームと説明することができる。ＤＤＴプラットフォームは、プロジェクト毎に一度、セキュアな形でインスタンス化され、プロジェクト上で、またはクラウドベースのインフラストラクチャにおいて、ホスト可能である。

ソフトウェアシステムの顧客への統合の当初に、ＤＤＴプラットフォームが顧客に対してプロビジョニングされる（例えばプロジェクトの開始時）。一部の例において、ＤＤＴプラットフォームでの使用が開始され、テストコンテンツがユーザ（例えば設計者）により作成される。ユーザは、ＤＤＴプラットフォームを使用して、反復型の共有モードでテストのセットを準備および実行することができ、各アクティビティに対してテストデータを作成することができる。一部の例において、ユーザによりセットされた各アクティビティについて、テストアクティビティが、テストパッケージに基づきセットされる種々のアクションおよび使用されるアドホックコンポーネント（例えば手動、自動（オート）、ロボット）によって提供される。

オートモデルの場合、関連性のあるデータセットを準備するためにデータテンプレートを作成できる（例えばＭＳ Ｅｘｃｅｌを使用）。１つ以上のデータオブジェクト（例えばクライアント、材料、販売注文）が、テストパッケージに基づいて作成される。一部の例において、ユーザは、複数のテストパッケージをリンクして、テスト環境に対してこのテストパッケージを実行することができる。テストの結果がＤＤＴプラットフォームの１つ以上のユーザインターフェース（ＵＩ：ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）に表示される。一部の例において、複数のユーザが、同じシナリオを使用して共同でシナリオを充実させることができる。一部の例において、テストインスタンスに対して実行されたシナリオの結果が、全体的な構成における任意の変動を特定するために検討される。一部の実装において、ユーザは、テストデータの類型および性質を理解するために、テストアクティビティの詳細にアクセスすることができる。手動モデルの場合、ユーザは、シナリオに対してテストケースを準備して実行し、ＤＤＴプラットフォーム上の結果を更新することができる。

一部の実装において、プロジェクトの終わりに、ＤＤＴプラットフォームは、特定の顧客について撤去される。テストメトリクスを使用してフィードバックループが提供され、テストメタデータが収集され（例えば顧客および／またはプロジェクトの機密情報がないもの）、中央リポジトリに格納される。一部の例において、メトリクスおよびメタデータは、将来のテスト準備および実行を調整して、ＤＤＴプラットフォームが推奨を提供することを可能にするために使用できる。

一部の実装において、本願明細書にさらに詳細に記載されるように、ＤＤＴプラットフォームのコンポーネントは、セキュアプロジェクトデータベース、テスト設計アプリケーション、テストエンジン、スケジューラコンソール、プロジェクト管理コンソールおよびデリバリビューアを含む。一部の例において、セキュアプロジェクトデータベースは、テストアーティファクト情報、メトリクスおよびその他プロジェクト関係のテストアーティファクトを格納する。一部の例において、テスト設計アプリケーションは、テストアクティビティを実行するためにユーザにより使用される。一部の例において、テストエンジンは、エンタープライズＡＰＩを管理する。一部の例において、スケジューラコンソールは、自動のテストタスクを実行する。一部の例において、プロジェクト管理コンソールは、ＤＤＴプラットフォームの動作のための参照データへのアクセスをプロビジョニングし、それを管理するために使用される。一部の例において、デリバリビューアは、顧客が設計の進捗を閲覧し、検証することを可能にする。

一部の実装において、ＤＤＴプラットフォームは、テストアーティファクトを格納する中央アセットリポジトリ（ＣＡＲ：ｃｅｎｔｒａｌ ａｓｓｅｔ ｒｅｐｏｓｉｔｏｒｙ）を含む。一部の例において、ＣＡＲは、サニタイズされたアセットの中央リポジトリと連携する。一部の例において、ＣＡＲは、設計の変形、テストアーティファクトのインスタンス化（例えば様々な次元（産業、機能、ロケールなど）別の各プロセスのテストアクティビティ、パッケージ、シナリオ））を格納しており、検索可能である。ＣＡＲは、それを使用して自己のプロジェクトで再利用可能な設計を発見することができる内部の人員により検索可能である。

本開示の実装に従って、ＣＡＲは、複数の使用ケースをサポートする。例示の使用ケースは、プロジェクト準備ワークフロー、アセット取り込みワークフローならびにアセット共有および伝播を含むが、限定はされない。一部の例において、プロジェクト準備ワークフローは、客先にて供給される製作物のスコープに対応する既存のアセットの選択を含む。一部の例において、アセット取り込みワークフローは、完了したプロジェクトからのアセットの取り込み（既存のベースラインと比較した、差分の生成およびマージ）、アセットカストディアンによる新たなアセットの承認および内部のユーザに対するアセットのパブリッシュを含む。一部の例において、アセットの共有および伝播は、他のプロジェクトでの再利用および検索メカニズムを介したアセットの発見のためにユーザ間でアセットの共有をすることを含む。

一部の実装において、テストアーティファクト設計アプリケーションは、供給されるソフトウェアシステムの設計および構成の一貫性を検証するために使用されるテストアーティファクトを構築および実行するためにプロジェクトコンサルタントにより使用される。一部の例において、オブジェクトデータが、設計される各アクティビティ、プロセスおよびシナリオに対して作成される。一部の実装において、プロジェクトマネージャアプリケーションは、プロジェクトコンサルタントおよびプロジェクトマネージャによって、タスクおよび問題を管理し、プロジェクトの進捗に関するレポートを実行し、プロジェクト全体のスコープの設定（リリースの定義など）を管理し、プロジェクトの要件に対するステータスおよびワークフローを設定するために使用される。一部の実装において、プロジェクト管理者アプリケーションは、初期のアセットベースを取り込み、プロジェクトの最後にアセットをエクスポートし、ユーザアクセスを管理し、データベースのバックアップ／復元を実行することにより、プロジェクトのライフサイクルにおいてＤＤＴプラットフォームをサポートする。

本開示の実装に従って、統合データモデル（ＵＤＭ：ｕｎｉｆｉｅｄ ｄａｔａ ｍｏｄｅｌ）が提供される。より具体的には、テストアーティファクトは、ＵＤＭでＣＡＲおよびプロジェクトデータベースに格納される。テストアーティファクトに対し加えられる変更は、他のすべてのテストアーティファクトにおいて反映され、すべての要素をバージョニングできる。ＵＤＭは柔軟であり、デリバリ手法に対する将来の変更と、種々のタイプのソフトウェアシステムに順応するための拡張とを可能にする。

図２は、本開示の実装に従った例示の概念アーキテクチャ２００を示す。例示の概念アーキテクチャ２００は、ソフトウェアシステムを顧客に供給するためにバックエンドシステム２０４と相互作用するＤＤＴプラットフォーム２０２を含む。一部の例において、バックエンドシステム２０４は、顧客に供給されるソフトウェアシステムをホストする。図２の例において、ＤＤＴプラットフォーム２０２は、ユーザ２０８（例えばコンサルタント）がコンピューティングデバイス２１０を使用して相互作用するプロジェクトサーバ２０６を含む。プロジェクトサーバ２０６は、スケジューラ２１２およびテストハーネス２１４を含む。示されている例では、バックエンドシステム２０４は、企業バックエンド２２０、１つ以上のユーザエクスペリエンス（ＵＸ：ｕｓｅｒ ｅｘｐｅｒｉｅｎｃｅ）アプリケーション２２２および１つ以上のＧＵＩ２２４を含む。

一部の実装において、ユーザ２０８（例えば企業のソフトウェアシステムを顧客に供給するコンサルタント）が、テストデータに基づく１つ以上のテストケース２３０を構築する。一部の例において、テストケースはコンピュータ可読ファイル（例えばＭＳ Ｅｘｃｅｌファイル）として提供される。一部の例において、テストケースは、ＤＤＴアプリケーションを使用して、企業のＡＰＩ（例えばＳＡＰ ＳＥにより提供されるビジネスＡＰＩ（ＢＡＰＩ：ｂｕｓｉｎｅｓｓ ＡＰＩ））にリンクされる。一部の例において、企業側アクティビティとＡＰＩとの間のマッピングが、ＤＤＴデータベースに格納される。ユーザは、設定がバックエンドシステム２０４においてセットされるとき、機能テストシナリオに基づきＡＰＩをリンクする。一部の例において、リンクは、変数および定数のバインドを使用して実現される。１つ以上のテストシナリオインターフェース２３２が提供され、これを介してユーザはリンクを実行することができる。

一部の実装において、１つ以上のシナリオの実行がスケジュールされる。例として、スケジューラ２１２は、シナリオの実行をスケジュールする。一部の例において、シナリオは、臨時に、または毎日、実行するようにスケジュール可能である。テストハーネス２１４は、リクエストサービス（例えばＡＰＩ＋ＪＳＯＮ）を実行する。テストケースおよびシナリオは、バックエンドシステム２０４上で実行され、テスト結果が出力として提供される。より具体的には、テストハーネス２１４は、テスト結果（例えばデータ、ログファイル）をバックエンドシステム２０４から受信する。一部の例において、予期される結果（例えばＪＳＯＮで提供される）が実際の結果（例えばＪＳＯＮで提供される）と比較され、比較出力が提供される。一部の例において、比較出力は、（例えばＭＳ Ｅｘｃｅｌシート（単数または複数）として）インターフェース２３２に表示される。

図３は、本開示の実装に従った例示のモジュールアーキテクチャ３００を示す。例示のモジュールアーキテクチャ３００は、ＤＤＴアプリケーション３０２、中央テストアセットリポジトリ３０４、中央閲覧アプリケーション３０６、テスト設計アプリケーション３０８、テストパッケージ構築モジュール３１０、テストシナリオ構築モジュール３１２、シナリオ実行モジュール３１４、中央管理アプリケーション３１６、プロジェクトマネジメントアプリケーション３１８およびプロジェクト管理アプリケーション３２０を含む。一部の例において、ＤＤＴアプリケーション３０２はプロジェクトデータベースを含み、中央テストアセットリポジトリ３０４は中央データベースを含む。一部の実装において、本願明細書にさらに詳細に記載されるように、ＤＤＴアプリケーション３０２は、顧客に供給されるソフトウェアシステムにおいてテストパッケージおよびテストシナリオを実行する。

一部の実装において、ユーザ（例えば設計コンサルタント）は、中央閲覧アプリケーション３０６およびテスト設計アプリケーション３０８と相互作用して、本開示のＤＤＴプラットフォームを使用してテストパッケージおよびテストシナリオを構築および実行する。一部の例において、ユーザは、テストパッケージ構築モジュール３１０、テストシナリオ構築モジュール３１２、シナリオ実行モジュール３１４と相互作用して、テスト設計アプリケーション３０８を介してテストパッケージおよびテストシナリオを構築および実行する。

一部の実装において、ユーザ（例えば中央管理者）は、中央管理アプリケーション３１６を介してＤＤＴプラットフォームと相互作用する。一部の実装において、ユーザ（例えばプロジェクトマネージャ、品質保証（ＱＡ：ｑｕａｌｉｔｙ ａｓｓｕｒａｎｃｅ））は、プロジェクトマネジメントアプリケーション３１８を介してＤＤＴプラットフォームと相互作用する。一部の実装において、ユーザ（例えばプロジェクト管理者）は、プロジェクト管理アプリケーション３１８を介してＤＤＴプラットフォームと相互作用する。

本開示の実装に従って、テスト設計アプリケーション３０８は、アクティビティのテストに使用されるコンポーネント（単数または複数）をユーザが設計することを可能にする。例示のＵＩは、テストアクティビティ定義インターフェースおよびテストパッケージ定義インターフェースを含むが、限定はされない。一部の例において、テストアクティビティ定義インターフェースは、ユーザが、アクティビティ記述と整合したテストアクティビティを定義することを可能にする。一部の例において、テストアクティビティ定義インターフェースは、ユーザが、アクティビティのテストの適切な対象範囲を設定するために、使用されるテストアーティファクト（製作物のパッケージ）の性質およびタイプを選択することを可能にする。一部の例において、テストパッケージ定義インターフェースは、ユーザが、外部ドキュメント（例えばＭＳ Ｅｘｃｅｌスプレッドシート）から、テストケースに基づいて構造化されたいくつかのデータを準備して読み込むことを可能にする。

一部の実装において、テストコンテンツの作成に関して、ユーザはウェブブラウザを開いて、ＤＤＴプラットフォーム（例えばテスト設計アプリケーション３０８）にアクセスする。ユーザは、テストアクティビティの記述を提供して、カバーするテストケースに対応しテストされるソフトウェアシステムの構成に関係するテストパッケージを作成することができる。一部の例において、テストケースは、障害メッセージをテストするために（例えば意図的にエラーをトリガする）エラーテストケースを含むことができる。一部の例において、テストアクティビティインターフェースが表示され、記述されたアクティビティに関するユーザ入力を受信する。例として、テストアクティビティインターフェースは、テストアクティビティの記述を示す。一部の例において、ユーザは、テストアクティビティインターフェースを介して、実行されるテスト（例えばテストパッケージ）のタイプを選択することができる。ユーザは、アクションのタイプ（例えばＡＵＴＯ、ＲＯＢＯＴ、ＭＡＮＵＡＬ）を選択することができる。

一部の実装において、ＡＵＴＯオプションは、ソフトウェアシステムを提供する企業のＡＰＩを介してテストケースを実行するために選択できる。アクティビティに対応するＡＰＩを選択できる。一部の例において、アクティビティのために使用できる既存のＡＰＩがない場合、ＡＰＩを、トランザクション、ならびにＡＰＩをコールするＪＳＯＮコールの形式で作成できる。一部の例において、リスト（例えばドロップダウンリスト）の中のＡＰＩを容易に区別するために、ＡＰＩの名前は、アクティビティに対応する。一般に、すべてのＡＰＩは、データモデルの中の個々のアクティビティに関連する。

一部の実装において、ユーザは、スプレッドシート（例えばＭＳ Ｅｘｃｅｌ）またはテンプレートを使用して、テストケースを作成する。一部の例において、複数のテストケースが提供され、ともにテストパッケージにまとめられる。一部の例において、複数のテストパッケージを提供できる。スプレッドシートを例として使用すると、変数とされるフィールドを特定できる。テストパッケージファイルは、保存し、必要に応じて後に変更を加えることができる。一部の例において、テストパッケージは、ファイルが保存されると自動的に作成される。

一部の実装において、テストシナリオ構築モジュール３１２（テストシナリオアプリケーションとも呼ばれる）は、ユーザがアクティビティのテストに使用されるシナリオを構築することを可能にする。例示のインターフェースは、テストシナリオ階層ブラウザ、テストシナリオ定義インターフェースおよびテストシナリオステップ定義インターフェースを含むが、限定はされない。一部の例において、テストシナリオ階層ブラウザは、ユーザが、階層（ビジネス階層）に基づき作成されたテストシナリオを操作（例えば編集）することを可能にする。一部の例において、ユーザは、現在のリポジトリ（例えば中央テストアセットリポジトリ３０４）からのシナリオを編集、閲覧、作成および／または削除することができる。一部の例において、テストシナリオ定義インターフェースは、各ユーザがテストシナリオの要素を共同した形で操作（例えば編集）することを可能にする。例として、ユーザは、すべてのテストシナリオの間使用される共通変数を構築し、テストシナリオに基づき実行される種々のテストステップを選択し、さらに／またはシナリオがその中で実行されるセションおよび環境を定義することができる。一部の例において、テストシナリオステップ定義インターフェースは、ユーザが、各シナリオステップに対して使用されることになるコンテキスト要素を操作（例えば編集）することを可能にする。例として、ユーザは、動的テストデータ（例えば前のテストステップから作成されたデータ）に変数を代入し、テストシナリオステップのための変数に定数を代入し、さらに／または出力ファイルから予期される結果を管理することができる。

テストシナリオの作成に関して、テストシナリオディレクトリを、ＤＤＴプラットフォームの（例えばユーザがテストシナリオ構築アプリケーションと相互作用するのに用いる）ウェブブラウザから選択できる。一部の例において、テストシナリオディレクトリは、（例えば階層的なビジネス構造により編成された）複数のテストシナリオを表示する。ユーザは、シナリオを編集、コピー、閲覧、削除および／または作成することができる。一部の例において、オブジェクトブラウザから初期のシナリオを作成するために、シナリオが作成される階層内のポジションが選択され、作成オプションが選択されて作成が開始される。一部の例において、テストシナリオの作成は、テストシナリオの記述を入力すること、添付物を提供すること、および定数を作成することを含む。一部の実装において、テストシナリオは、オートもしくは手動、オートおよびロボット、またはフルロボットとすることができる。一部の例において、外部データがテストシナリオにおいて必要とされる場合、他のユーザにリクエスト可能である。一部の例において、他のユーザは、テストパッケージにアクセスして、テストパッケージにおいて、ステップを追加し、さらに／または特定のデータを作成することができる。一部の例において、アクティビティの中のテストパッケージは、それらを変更することなくテストケースを見るために閲覧可能である。テストパッケージの中の提案されるケースが適切でなければ、更新をリクエストでき、別のテストパッケージを作成でき、またはテストパッケージに変更を加えることができる。一部の実装において、予期される結果を定義するために１つ以上の値をバインドできる。

一部の実装において、オートテストシナリオの作成に関して、シナリオの第１のステップを手動で入力できる。一部の例において、テストアクティビティで使用可能なデータを含むアクティビティにテストパッケージにおいてオートタイプが付加された、テストパッケージがあるかどうかを予め判断できる。一部の例において、ＵＩ要素（例えば＋ボタン）を選択して、テストシナリオステップを作成することができる。アクティビティおよびテストパッケージを選択できる。それに応答して、テスト名およびテストケースを表示できる。一部の例において、ＵＩ要素（例えば＞アイコン）を選択して、ステップの作成を検証することができる。テストシナリオが作成され、さらにこれを編集できる。一部の例において、テストシナリオの編集は、テストシナリオの中にディレクトリを作成することを含むことができ、これは、テストシナリオの中のステップのリストを提供する。一部の例において、ディレクトリはテストシナリオブラウザにおいて見ることができる。一方、シナリオステップを移動／削除するためにステップを選択でき、前のステップおよび／または後のステップの任意の制約が示される（例えば色または任意の適切なグラフィック処理により視覚的に強調される）。このようにして、矛盾を回避することができる。

一部の実装において、テストシナリオの編集中、シナリオ編集メニューからの環境変数を用いてステップを実行でき、出力が提供される。一部の例において、入力ファイルから提供された変数が表示される。一部の例において、変数出力エリアならびに出力閲覧、予期される結果編集および予期される結果保存のインターフェース要素は、当初、グレーアウトされている。変数に定数が代入される場合、シナリオに対して提案される定数のリストの中の定数の名前を含むリストから定数を選択できる。別のテストパッケージから値が選択される場合、チェーンインターフェース要素を選択でき、これにより、メニューが表示され、そこから利用可能な変数を、またはテストステップ、テストケースおよび変数名別の変数を選択できる。一部の実装において、出力変数を作成するために、出力ファイルのテーブル、列および場合によってはデータに対する特定のフィルタの参照のための名前が提供される。すべての変数が作成されてバインドされた後、変更が保存される。テストシナリオが、再び表示されることが可能であり、入力ファイル、出力ファイルおよび比較ファイルを示す。一部の例において、出力ファイルが適切であれば、予期される結果ファイルとして保存できる。

一部の実装において、オートシナリオステップに関して、オートシナリオステップは、テストシナリオ設計ＵＩから実行できる。このようにして、渡されるパラメータおよび値を、正確さについて確認できる。一部の例において、オートシナリオステップの実行は、スケジューラに、リクエストを、スケジューラにおいてハーネステストを実行するためのすべての情報とともに送る。実行の戻りの値は、送り返されて、メッセージ（例えば成功、接続エラー、エラーＡＰＩ）とともにシナリオステップ行に表示される。一部の例において、実行時に、セッション名の選択がリクエストされ、さらにリクエストを実行するための環境／クライアントパラメータの選択がリクエストされる。セッションの実行は、セッション読み込み／調査ＵＩで見ることができる。

一部の実装において、スケジューラがそのセッションを終えると、ハーネステストの戻りコードを（例えば成功または失敗のアイコンの形で）見ることができるようになる。一部の例において、エラーまたは成功メッセージを表示するために、戻りコード（例えばアイコン）を選択（またはその上をホバリング）できる。一部の例において、ステップが編集され、出力ファイルが表示されることが可能である。出力ファイルは、予期される結果として保存できる。

一部の実装において、オートテストシナリオの実行に関して、シナリオ全部を実行できる（例えば、すべて実行オプションを選択）。このケースにおいて、シナリオステップおよびそれらのコンテキスト（例えば定数、入力変数、出力変数、入力ファイル、予期される結果）のすべてが、ハーネステストに対する実行のスケジューラに送られる。既存のセッションが選択されていない場合、セッション名の入力フィールドならびに環境の入力フィールド、および実行クライアントが表示される。この情報を用いて、スケジューラはセッションを実行することができる。スケジューラがセッションを終えると、ハーネステストの戻りコードを（例えば成功または失敗のアイコンの形で）見ることができるようになる。その上にマウスポインタを置くと、エラーまたは成功メッセージを読み取ることができなければならない。一部の例において、エラーまたは成功メッセージを表示するために、戻りコード（例えばアイコン）を選択（またはその上をホバリング）できる。一部の例において、ステップが編集され、出力ファイルが表示されることが可能である。出力ファイルは、予期される結果として保存できる。

一部の実装において、セッションを、実行結果の戻りが表示されるセッション名、実行日、ユーザ名により（例えばセッション読み込みアイコンを選択することによって）選択できる。一部の例において、現在のセッションを選択できる。

一部の実装において、自動のテストを周期的に（例えば毎日）実行できる。一部の例において、これは、スケジューラにより直接、実行される。一部の例において、シナリオの実行のタスクおよび制約（前、後）が、スケジューリングの準備を任されたオペレータと共有される。シナリオは、新たなセッション（シナリオの全体のコンテキストを含む）に基づき体系的に実行される。各シナリオステップは、ＡＰＩ処理のためのテストハーネスを呼び出す。一部の例において、シナリオ実行の結果は、セッションの検索（例えば「セッション＜日付＞」、実行日、オペレータのユーザ）によって提供できる。

一部の実装において、プロジェクト管理アプリケーション３２０は、ＤＴＤアプリケーション３０２のクライアントインスタンスを維持することを担当するユーザにより使用される。一部の例において、プロジェクト管理アプリケーション３２０は、クライアントプロジェクトの立ち上げ時、設計中およびプロジェクト終結時の、ＤＤＴプラットフォームのライフサイクルをサポートする。一部の例において、プロジェクト立ち上げ時、テストアーティファクトのセット（例えばテストシナリオ、テストパッケージ、入力ファイル、出力ファイル）がＤＤＴプロジェクトインスタンスにインポートされる。プロジェクトの間、中央リポジトリからの追加のアセットを、必要に応じてＤＤＴプラットフォームに追加できる。一部の例において、プロジェクトの終わりに、アセットを、収集のために処理されるようエクスポートできる。プロジェクト実行中、タスクに関連するプロジェクトイベントのライブストリーム、およびプロジェクトで完了される問題が、（例えばリアルタイムまたは準リアルタイムで中央サーバに送られる。このようにして、再利用可能である可能性があるアセットを特定できる。

一部の実装において、バックアップおよび復元機能性が提供される。一部の例において、バックアップおよび復元機能性は、ハードウェア障害またはユーザによる間違った操作が原因でインスタンスが破損したケースにおいて、ＤＤＴプラットフォームの現在の状態を保存する。一部の実装において、ユーザ、ユーザグループおよびセキュリティを管理するための機能性が提供される。一部の例において、インスタンスに対するアクセスが、ＤＤＴプラットフォームに対するユーザ、グループおよびアクセス権を定義するプロジェクト管理者により定義される。

一部の実装において、プロジェクトマネジメントアプリケーション３１８は、ユーザが、テストアクティビティ中にタスクおよび問題を管理することを可能にする。一部の例において、タスクマネジメント機能性は、各ユーザが、ＤＤＴプラットフォームにおいて完了する必要がある設計タスクに対応するタスクのリストを得ることを可能にする。ユーザは、各設計タスクを完了するのに伴い、マネジメントチームに最新情報を提供し続けるために、ワークフローの中のタスクのステータスまたはポジションを更新することができる。問題マネジメント機能性は、各ユーザが、設計中に提起されたプロジェクトの問題を文書に記録するための問題マネジメントツールを得ることを可能にする。ユーザは、このツールを使用して、問題を更新し、それらが解決されるのに伴い問題を最終的にクローズすることができる。レポート機能性は、未解決の問題、残っているタスク、取り組み、およびプロジェクトの現在の健全性のダッシュボードに関する情報を提供するプロジェクトレポートのセットを提供する。

一部の実装において、中央閲覧アプリケーション３０６は、ユーザが、中央テストアセットリポジトリ３０４の中のアセットを検索すること、およびプロジェクトに関する関心のある特定のトピックを追うことを可能にする。一部の例において、ユーザは、その用途のために、中央テストアセットリポジトリ３０４において、参照用の実装または実装の変形を検索することができる。一部の例において、ユーザは、関心のあるトピック（例えば業界、機能分野）にサブスクライブすることができる。このようにして、プロジェクトが進行するのに伴い、ユーザは、最近開発された関連性のある製作物について知らせを（例えばリアルタイムで）受けることができる。一部の例において、トピックにサブスクライブするために、ユーザは、中央閲覧アプリケーション３０６と相互作用して、サブスクライブしたい通知のタイプを選ぶことができる。プロジェクトが完了されるのに伴い、通知が中央サーバにパブリッシュされ、それらが自動的にユーザのトピックストリームに追加される。一部の例において、トピックストリームは、ユーザのトピックサブスクリプションならびに他の関連データに基づきユーザに対して自動的に生成される。トピックストリームは、世界中でアクティブなプロジェクトから、それらがユーザに関連し得る様々なタスクおよび問題を完了するのに伴い、イベントのストリームとして提供できる。

一部の実装において、ユーザはアセットを検索することができる。一部の例において、ユーザは、中央テストアセットリポジトリ３０４にあるアセットを発見するために検索画面にアクセスすることができる。一部の例において、検索画面は、関連するアセットを検索しデータの階層ビューを閲覧するために使用できる、テキスト検索機能性を含む。一部の実装において、検索およびユーザ解析を、例として、サブスクライブされるトピック、検索のテキストならびに高需要のアセットに関してレポートするために生成できる。

一部の実装において、中央管理アプリケーション３１６は、ユーザ（例えば中央管理者）が中央閲覧アプリケーション３０６を制御することを可能にする。一部の例において、中央管理アプリケーション３１６は、ユーザが、プロジェクトアセットを実装し、新たなプロジェクトのためのテスト開始パックをエクスポートし、中央マネジメントレポートを実施することを可能にする。プロジェクトアセットの実装に関して、中央管理アプリケーション３１６は、特定のワークフローを用いるプロジェクトテストアセットエクスポートの取り込みを可能にする。一部の例において、この機能性は、インポートされたテストアセットのどれが変化したか、および中央テストアセットリポジトリ３０４と比較してどのような種類の変化があるかを判断するために、既存の中央リポジトリと差分マージを実行する。このようにして、ユーザは、例として、既存のテストアセットへのマージまたは新たな変形の作成のいずれかを検証することができる。

一部の実装において、新たなプロジェクトが開始すると、プロジェクトのスコープに合致するテストアセットを選択するために中央管理アプリケーション３１６を使用できる。さらに、テストアセットを、ＤＤＴプラットフォームのプロジェクトインスタンスに取り込むためにエクスポートできる。一部の実装において、プロジェクトが実行されるとき、プロジェクト実行中の（例えばリアルタイムでの）プロジェクトパフォーマンスフィードバックがあり、これは中央で格納およびレポートされる。（タスクおよび問題に対する）取り組み、およびプロジェクトの進捗に関する情報がレポートされ、各地理的単位および各プロジェクトにわたり比較されることが可能である。

図４は、本開示の実装において実行可能な例示のプロセス４００を示す。一部の例において、例示のプロセス４００は、１つ以上のコンピューティングデバイス（例えば図１のバックエンドシステム１０８）により実行される１つ以上のコンピュータ実行可能プログラムを使用して提供される。

テストデータが受信される（４０２）。例として、図２および図３を参照して上述されたように、ユーザ（例えば企業のソフトウェアシステムを顧客に供給するコンサルタント）が、テストデータに基づく１つ以上のテストケースを構築する。一部の例において、テストケースは、テストデータを含むコンピュータ可読ファイル（例えばＭＳ Ｅｘｃｅｌファイル）として提供される。一部の例において、テストデータは、テスト実行中に、テスト中のソフトウェアシステムのデータベース内のデータオブジェクトを作成および／または修正するために使用されるデータを含む。テストシナリオが提供される（４０４）。例として、本願明細書に記載されるように、テストシナリオは、ＡＰＩを介して実行される複数のテスト要素（例えばアクティビティ）を含む。一部の例において、アクティビティは、データベース内のデータオブジェクトに対して実行されるトランザクションのセットを含む。例示のトランザクションは、データベース内のデータおよび／またはデータオブジェクトを作成、変更および／または削除することを含むことができるが、限定はされない。本願明細書に図３を参照して記載されるように、テストシナリオは、ＤＤＴプラットフォームのテストシナリオ構築モジュールを介して提供でき、このモジュールは、アクティビティのテストのために使用されるシナリオをユーザが構築することを可能にする。統合が適切に実行するかどうか（例えばデータベース内でデータオブジェクトが適切に更新されたか）を観測するために、テストシナリオは、実行されると、データベース内のデータオブジェクトに直接影響する。

テストの実行がスケジュールされる（４０６）。例として、本願明細書に記載されるように、ＤＤＴプラットフォームのスケジュールがテストシナリオの実行をスケジュールする。一部の例において、スケジューラは、特定の時間（例えば夜間）に実行するようにテストシナリオの実行をスケジュールする。一部の例において、複数のテストシナリオが実行されてもよく、スケジューラは、あらゆる競合を回避するように実行をスケジュールする。テストがハーネスによって実行される（４０８）。例として、本願明細書に記載されるように、ハーネスは、テストファイルからデータを得て、データを適切な形式（例えばＪＳＯＮ）に変換し、テスト中のソフトウェアシステムに１つ以上のＡＰＩを介してデータを送る。

テストの結果が受信される（４１０）。例として、本願明細書に記載されているように、ハーネスは、テスト中のソフトウェアシステムから出力ファイルを受信する。一部の例において、テスト結果（例えばデータ、ログファイル）が、バックエンドシステムにおいて発生する実際の結果（例えばデータベースの中のデータオブジェクトに対する変更）として提供される。比較が提供される（４１２）。例として、ハーネスは、予期される結果および受信された実際の結果に基づく比較を提供する。一部の例において、予期される結果（例えばＪＳＯＮで提供される）が実際の結果（例えばＪＳＯＮで提供される）と比較され、比較出力が提供される。一部の例において、比較出力は、（例えばＭＳ Ｅｘｃｅｌシート（単数または複数）として）インターフェースに表示される。

本明細書に記載された実装およびすべての機能動作は、デジタル電子回路構成において、またはこの明細書で開示された構造およびその構造上の等価物を含むコンピュータソフトウェア、ファームウェアもしくはハードウェアにおいて、またはそれらのうちの１つ以上の組み合わせにおいて実現され得る。実装は、１つ以上のコンピュータプログラム製品として、すなわちデータ処理装置により実行されるよう、またはデータ処理装置の動作を制御するようコンピュータ可読媒体上にエンコードされた、コンピュータプログラム命令の１つ以上のモジュールとして実現されてもよい。コンピュータ可読媒体は、機械可読ストレージデバイス、機械可読ストレージ基板、メモリデバイス、機械可読伝播信号をもたらす物質の構成またはそれらのうちの１つ以上の組み合わせとされてもよい。「コンピューティングシステム」という用語は、データを処理するすべての装置、デバイスおよび機械を含み、例として、プログラマブルプロセッサ、コンピュータまたは複数のプロセッサもしくはコンピュータを含む。装置は、ハードウェアに加えて、プロセッサファームウェア、プロトコルスタック、データベースマネジメントシステム、オペレーティングシステムまたはそれらのうちの１つ以上の組み合わせなどを構成する、対象のコンピュータプログラム（例えばコード）の実行環境を作り出すコードを含んでもよい。伝播信号とは、適切な受信機装置に送信される情報をエンコードするために生成される人工的に生成された信号（例えば機械生成された電気信号、光信号または電磁信号）である。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプトまたはコードとしても知られる）は、コンパイル型またはインタープリタ型言語を含む任意の適切な形態のプログラミング言語で書かれてもよく、スタンドアロンプログラムとして、またはモジュール、コンポーネント、サブルーチンもしくはコンピューティング環境での使用に適した他のユニットとしてを含め、任意の適切な形態で展開されてもよい。コンピュータプログラムは、必ずしもファイルシステム内のファイルに対応するとは限らない。プログラムは、他のプログラムもしくはデータを保持するファイルの一部（例えば、マークアップ言語ドキュメントに格納される１つ以上のスクリプト）、対象のプログラム専用の単一ファイルまたは複数の連携ファイル（例えば１つ以上のモジュール、サブプログラムもしくはコードの一部を格納する複数ファイル）に格納されてもよい。コンピュータプログラムは、１つのコンピュータ上または１つの場所に位置するか、もしくは複数の場所に分散し通信ネットワークにより相互接続された、複数のコンピュータ上で実行されるように展開されてもよい。

本明細書に記載されたプロセスおよび論理フローは、入力データに作用し出力を生成することにより機能を実行する１つ以上のコンピュータプログラムを実行する、１つ以上のプログラマブルプロセッサにより実行されてもよい。プロセスおよび論理フローは、専用論理回路構成（例えばＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：特定用途向け集積回路））によっても実行でき、装置は専用論理回路構成としても実装できる。

コンピュータプログラムの実行に適したプロセッサは、例として、汎用および専用両方のマイクロプロセッサならびに任意の適切な種類のデジタルコンピュータの任意の１つ以上のプロセッサを含む。一般に、プロセッサは、読み取り専用メモリもしくはランダムアクセスメモリまたは両方から命令およびデータを受信する。コンピュータの構成要素は、命令を実行するプロセッサ、ならびに命令およびデータを格納する１つ以上のメモリデバイスを含むことができる。一般に、コンピュータはさらに、データを格納する１つ以上の大容量ストレージデバイス（例えば磁気、光磁気ディスクもしくは光ディスク）を含むか、またはそれからデータを受信するよう、もしくはそれにデータを転送するよう動作可能に結合されるか、またはその両方である。なお、コンピュータはそのようなデバイスを有する必要はない。さらに、コンピュータは、別のデバイス（例えばモバイル電話、携帯情報端末（ＰＤＡ）、モバイルオーディオプレーヤ、衛星航法システム（ＧＰＳ：Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信機）に組み込まれてもよい。コンピュータプログラム命令およびデータを格納するのに適したコンピュータ可読媒体は、あらゆる形態の不揮発性メモリ、媒体およびメモリデバイスを含み、例として、半導体メモリデバイス（例えばＥＰＲＯＭ、ＥＥＰＲＯＭおよびフラッシュメモリデバイス）、磁気ディスク（例えば内蔵ハードディスクまたはリムーバブルディスク）、光磁気ディスクならびにＣＤ ＲＯＭおよびＤＶＤ−ＲＯＭディスクなどが含まれる。プロセッサおよびメモリは、専用論理回路構成により補完されてもよく、またはそれに組み込まれてもよい。

ユーザとの相互作用を提供するために、情報をユーザに表示するディスプレイデバイス（例えばＣＲＴ（ｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ：陰極線管）、ＬＣＤ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ：液晶ディスプレイ）、ＬＥＤ（ｌｉｇｈｔ−ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ：発光ダイオード）モニタ、ならびにユーザがコンピュータに入力を提供できるキーボードおよびポインティングデバイス（例えばマウスまたはトラックボール）を有するコンピュータ上で、実装が実現されてもよい。他の種類のデバイスが、同じくユーザとの相互作用を提供するために使用されてもよい。例として、ユーザに提供されるフィードバックは、任意の適切な形態の感覚フィードバック（例えば視覚フィードバック、聴覚フィードバックまたは触覚フィードバック）であってもよく、ユーザからの入力は、音響、発話または触覚入力を含め、任意の適切な形態で受信されてもよい。

実装は、バックエンドコンポーネントを含むコンピューティングシステム（例えばデータサーバとして）、またはミドルウェアコンポーネントを含むコンピューティングシステム（例えばアプリケーションサーバ）、またはフロントエンドコンポーネントを含むコンピューティングシステム（例えばユーザが実装と相互作用するのに用いることができるグラフィカルユーザインターフェースもしくはウェブブラウザを有するクライアントコンピュータ）、またはそのようなバックエンドコンポーネント、ミドルウェアコンポーネントもしくはフロントエンドコンポーネント１つ以上の任意の適切な組み合わせにおいて実現されてもよい。システムのコンポーネントは、任意の適切な形態または媒体のデジタルデータ通信（例えば通信ネットワーク）により相互接続されてもよい。通信ネットワークの例は、ローカルエリアネットワーク（「ＬＡＮ」）、およびワイドエリアネットワーク（「ＷＡＮ」）（例えばインターネット）を含む。

コンピューティングシステムは、クライアントおよびサーバを含んでもよい。クライアントおよびサーバは、一般に、互いに遠隔にあり、典型的には通信ネットワークを介して相互作用する。クライアントおよびサーバの関係は、個々のコンピュータ上で実行され相互にクライアント−サーバ関係を有するコンピュータプログラムにより生じる。

本明細書は多数の詳述を含むが、これらは、本開示の範囲または特許請求の範囲に対する限定として解釈されるべきではなく、むしろ特定の実装に特有の特徴の記載として解釈されるべきである。別々の実装との関連で本明細書に記載されている特定の特徴はさらに、単一の実装に組み合わせて実装されることも可能である。逆に、単一の実装との関連で記載されている様々な特徴はさらに、複数の実装において別々に、または任意の適切な一部組み合わせにおいて実装されてもよい。さらに、各特徴は、特定の組み合わせで動作するよう上述されていることもあり、当初そのように請求されていることもあるが、場合によっては、請求されている組み合わせの特徴１つ以上が、その組み合わせから削除されることが可能であり、請求されている組み合わせは、一部組み合わせまたは一部組み合わせの変形物を対象とし得る。

同じく、各動作は図面内に特定の順序で示されているが、これは、望ましい結果を達成するために、当該の動作が示されている特定の順序でもしくは順番に実行されること、または示されているすべての動作が実行されることを要求するものと理解されてはならない。特定の状況では、マルチタスクおよび並列処理が有利なこともある。さらに、上述の実装における様々なシステムコンポーネントの分離は、すべての実装においてそのような分離を要求するものと理解されてはならず、当然のことながら、記載されているプログラムコンポーネントおよびシステムは、一般に、単一ソフトウェア製品にともに統合されても、または複数のソフトウェア製品にパッケージ化されてもよい。

いくつかの実装が記載された。しかし、当然のことながら、本開示の意図および範囲から逸脱することなく、様々な変更が加えられ得る。例えば、ステップが並べ替え、追加または削除された、上記で示されたフローの種々の形態が使用されてもよい。よって、他の実装は、添付の特許請求の範囲に記載の範囲内にある。

Claims (24)

1. 供給されるソフトウェアシステムのテストのために１つ以上のプロセッサにより実行される、コンピュータに実装された方法であって、前記方法は、
   第１のサーバシステムで実行するデータドライブテスト（ＤＤＴ）プラットフォームによって、テストデータを含む１つ以上のコンピュータ可読ファイルを受信するステップであって、前記テストデータは、顧客のセットにおける各顧客に対して構成可能でありかつ第２のサーバシステムで実行するベンダバックエンドシステムにより少なくとも部分的にホストされるソフトウェアシステムをテスト中に、少なくとも１つのトランザクションを実行するための、前記顧客のセットのうちの第１の顧客に特有のデータを含む、前記受信するステップと、
   前記ＤＤＴプラットフォームによって、前記ベンダバックエンドシステム上の前記ソフトウェアシステムにより実行される１つ以上のテストシナリオを提供するステップであって、前記１つ以上のテストシナリオは、前記第１の顧客に特有のものであり、前記テストデータの少なくとも一部を使用して前記ソフトウェアシステムによりトランザクションを実施するためのアクティビティのセットを含む、前記提供するステップと、
   前記ＤＤＴプラットフォームのテストハーネスを使用した前記１つ以上のテストシナリオの実行を、前記ＤＤＴプラットフォームのスケジューラによりスケジュールするステップであって、前記１つ以上のテストシナリオの実行は、前記第１の顧客に対して構成されている前記ソフトウェアシステムによってなされるものであり、前記スケジューラは、前記１つ以上のテストシナリオを実行させるために前記テストハーネスと通信し、個々のテストシナリオに対する前記アクティビティのセットのうちの各アクティビティの前記ソフトウェアシステムによる実行のために、アクティビティに特有のコールを前記テストハーネスから前記第２のサーバシステムに提供する、前記スケジュールするステップと、
   前記ＤＤＴプラットフォームの前記テストハーネスにより、前記ベンダバックエンドシステムからテスト結果を受信するステップと、
   比較を出力として提供するために、前記テスト結果と予期される結果とを前記ＤＤＴプラットフォームの前記テストハーネスにより比較するステップと、
   を含む、方法。
2. 前記１つ以上のテストシナリオの実行は、前記テストハーネスによって、
   前記テストデータの少なくとも一部を第１の形式から第２の形式に変換するステップと、
   変換されたテストデータの少なくとも一部を、１つ以上のアプリケーションプログラミングインターフェース（ＡＰＩ）を介して前記ソフトウェアシステムに送信するステップと、
   を少なくとも部分的に含む、請求項１に記載の方法。
3. 前記１つ以上のＡＰＩは、前記ベンダバックエンドシステムにより公開される、請求項２に記載の方法。
4. 前記テストハーネスは、前記テスト結果を受信し、前記テスト結果と前記予期される結果とを比較し、前記比較を提供する、請求項１に記載の方法。
5. 前記１つ以上のテストシナリオは、前記ＤＤＴプラットフォームのテスト設計アプリケーションに対するユーザ入力に基づき提供される、請求項１に記載の方法。
6. 少なくとも１つのテストシナリオは、前記ＤＤＴプラットフォームの中央リポジトリに格納されたテストアセットの再利用に部分的に基づく、請求項５に記載の方法。
7. 前記１つ以上のテストシナリオの実行は、前記ベンダバックエンドシステムのデータベース内に格納された１つ以上のデータオブジェクトに影響を及ぼす、請求項１に記載の方法。
8. 前記テスト結果の少なくとも一部は、前記１つ以上のデータオブジェクトに対する変更を含み、前記予期されるテスト結果の少なくとも一部は、前記１つ以上のデータオブジェクトに対する予期される変更を含む、請求項７に記載の方法。
9. １つ以上のプロセッサに結合され、命令を格納された非一時的コンピュータ可読ストレージ媒体であって、前記命令は、前記１つ以上のプロセッサにより実行されると、供給されるソフトウェアシステムのテストのための動作を前記１つ以上のプロセッサに実行させ、前記動作は、
   第１のサーバシステムで実行するデータドライブテスト（ＤＤＴ）プラットフォームによって、テストデータを含む１つ以上のコンピュータ可読ファイルを受信することであって、前記テストデータは、顧客のセットにおける各顧客に対して構成可能でありかつ第２のサーバシステムで実行するベンダバックエンドシステムにより少なくとも部分的にホストされるソフトウェアシステムをテスト中に、少なくとも１つのトランザクションを実行するための、前記顧客のセットのうちの第１の顧客に特有のデータを含む、前記受信することと、
   前記ＤＤＴプラットフォームによって、前記ベンダバックエンドシステム上の前記ソフトウェアシステムにより実行される１つ以上のテストシナリオを提供することであって、前記１つ以上のテストシナリオは、前記第１の顧客に特有のものであり、前記テストデータの少なくとも一部を使用して前記ソフトウェアシステムによりトランザクションを実施するためのアクティビティのセットを含む、前記提供することと、
   前記ＤＤＴプラットフォームのテストハーネスを使用した前記１つ以上のテストシナリオの実行を、前記ＤＤＴプラットフォームのスケジューラによりスケジュールすることであって、前記１つ以上のテストシナリオの実行は、前記第１の顧客に対して構成されている前記ソフトウェアシステムによってなされるものであり、前記スケジューラは、前記１つ以上のテストシナリオを実行させるために前記テストハーネスと通信し、個々のテストシナリオに対する前記アクティビティのセットのうちの各アクティビティの前記ソフトウェアシステムによる実行のために、アクティビティに特有のコールを前記テストハーネスから前記第２のサーバシステムに提供する、前記スケジュールすることと、
   前記ＤＤＴプラットフォームの前記テストハーネスにより前記ベンダバックエンドシステムからテスト結果を受信することと、
   比較を出力として提供するために、前記テスト結果と予期される結果とを前記ＤＤＴプラットフォームの前記テストハーネスにより比較することと、
   を含む、コンピュータ可読ストレージ媒体。
10. 前記１つ以上のテストシナリオの実行は、前記テストハーネスによって、
    前記テストデータの少なくとも一部を第１の形式から第２の形式に変換することと、
    変換されたテストデータの少なくとも一部を、１つ以上のアプリケーションプログラミングインターフェース（ＡＰＩ）を介して前記ソフトウェアシステムに送信することと、
    を少なくとも部分的に含む、請求項９に記載のコンピュータ可読ストレージ媒体。
11. 前記１つ以上のＡＰＩは、前記ベンダバックエンドシステムにより公開される、請求項１０に記載のコンピュータ可読ストレージ媒体。
12. 前記テストハーネスは、前記テスト結果を受信し、前記テスト結果と前記予期される結果とを比較し、前記比較を提供する、請求項９に記載のコンピュータ可読ストレージ媒体。
13. 前記１つ以上のテストシナリオは、前記ＤＤＴプラットフォームのテスト設計アプリケーションに対するユーザ入力に基づき提供される、請求項９に記載のコンピュータ可読ストレージ媒体。
14. 少なくとも１つのテストシナリオは、前記ＤＤＴプラットフォームの中央リポジトリに格納されたテストアセットの再利用に部分的に基づく、請求項１３に記載のコンピュータ可読ストレージ媒体。
15. 前記１つ以上のテストシナリオの実行は、前記ベンダバックエンドシステムのデータベース内に格納された１つ以上のデータオブジェクトに影響を及ぼす、請求項９に記載のコンピュータ可読ストレージ媒体。
16. 前記テスト結果の少なくとも一部は、前記１つ以上のデータオブジェクトに対する変更を含み、前記予期されるテスト結果の少なくとも一部は、前記１つ以上のデータオブジェクトに対する予期される変更を含む、請求項１５に記載のコンピュータ可読ストレージ媒体。
17. １つ以上のプロセッサと、
    前記１つ以上のプロセッサに結合され、命令を格納されたコンピュータ可読ストレージデバイスと、
    を含むシステムであって、前記命令は、前記１つ以上のプロセッサにより実行されると、供給されるソフトウェアシステムのテストのための動作を前記１つ以上のプロセッサに実行させ、前記動作は、
    第１のサーバシステムで実行するデータドライブテスト（ＤＤＴ）プラットフォームによって、テストデータを含む１つ以上のコンピュータ可読ファイルを受信することであって、前記テストデータは、顧客のセットにおける各顧客に対して構成可能でありかつ第２のサーバシステムで実行するベンダバックエンドシステムにより少なくとも部分的にホストされるソフトウェアシステムをテスト中に、少なくとも１つのトランザクションを実行するための、前記顧客のセットのうちの第１の顧客に特有のデータを含む、前記受信することと、
    前記ＤＤＴプラットフォームによって、前記ベンダバックエンドシステム上の前記ソフトウェアシステムにより実行される１つ以上のテストシナリオを提供することであって、前記１つ以上のテストシナリオは、前記第１の顧客に特有のものであり、前記テストデータの少なくとも一部を使用して前記ソフトウェアシステムによりトランザクションを実施するためのアクティビティのセットを含む、前記提供することと、
    前記ＤＤＴプラットフォームのテストハーネスを使用した前記１つ以上のテストシナリオの実行を、前記ＤＤＴプラットフォームのスケジューラによりスケジュールすることであって、前記１つ以上のテストシナリオの実行は、前記第１の顧客に対して構成されている前記ソフトウェアシステムによってなされるものであり、前記スケジューラは、前記１つ以上のテストシナリオを実行させるために前記テストハーネスと通信し、個々のテストシナリオに対する前記アクティビティのセットのうちの各アクティビティの前記ソフトウェアシステムによる実行のために、アクティビティに特有のコールを前記テストハーネスから前記第２のサーバシステムに提供する、前記スケジュールすることと、
    前記ＤＤＴプラットフォームの前記テストハーネスにより前記ベンダバックエンドシステムからテスト結果を受信することと、
    比較を出力として提供するために、前記テスト結果と予期される結果とを前記ＤＤＴプラットフォームの前記テストハーネスにより比較することと、
    を含む、システム。
18. 前記１つ以上のテストシナリオの実行は、前記テストハーネスによって、
    前記テストデータの少なくとも一部を第１の形式から第２の形式に変換することと、
    変換されたテストデータの少なくとも一部を、１つ以上のアプリケーションプログラミングインターフェース（ＡＰＩ）を介して前記ソフトウェアシステムに送信することと、
    を少なくとも部分的に含む、請求項１７に記載のシステム。
19. 前記１つ以上のＡＰＩは、前記ベンダバックエンドシステムにより公開される、請求項１８に記載のシステム。
20. 前記テストハーネスは、前記テスト結果を受信し、前記テスト結果と前記予期される結果とを比較し、前記比較を提供する、請求項１７に記載のシステム。
21. 前記１つ以上のテストシナリオは、前記ＤＤＴプラットフォームのテスト設計アプリケーションに対するユーザ入力に基づき提供される、請求項１７に記載のシステム。
22. 少なくとも１つのテストシナリオは、前記ＤＤＴプラットフォームの中央リポジトリに格納されたテストアセットの再利用に部分的に基づく、請求項２１に記載のシステム。
23. 前記１つ以上のテストシナリオの実行は、前記ベンダバックエンドシステムのデータベース内に格納された１つ以上のデータオブジェクトに影響を及ぼす、請求項１７に記載のシステム。
24. 前記テスト結果の少なくとも一部は、前記１つ以上のデータオブジェクトに対する変更を含み、前記予期されるテスト結果の少なくとも一部は、前記１つ以上のデータオブジェクトに対する予期される変更を含む、請求項２３に記載のシステム。

Images