JP2007535723A - 複合ソフトウエアシステムを実施して検証するための自動多次元追跡可能性行列を含む試験ツール - Google Patents

Abstract

【課題】複合ソフトウエアシステムのための試験ツールを提供する。
【解決手段】本発明は、複数の相互に関連するシステムコンポーネントと複数の相互に関連するシステムコンポーネントの性能を試験するための一組の試験シナリオとを有する複合ソフトウエアシステムの試験のための試験ツールに関する。試験ツールは、相互に関連するシステムコンポーネント間のリンケージを判断するための「自動多次元追跡可能性行列」システム、相互に関連するシステムコンポーネントの１つ又はそれよりも多くにおける変更を識別するための手段、「自動多次元追跡可能性行列」を適用するための手段、変更によって影響を受ける場合がある相互に関連するシステムコンポーネントに関連した試験シナリオの全て又はその部分集合を実行するための手段、及び実行された試験シナリオの結果を評価するための手段を含む。
【選択図】図１Ａ

Description

本発明は、複合ソフトウエアシステムのための試験ツール及び試験ツールの態様に関する。この非仮出願は、２００３年１１月４日申請の米国特許出願出願番号第６０／５１７，６３１号に対する優先権を請求するものである。

「エンタープライズ・リソース・プラニング（ＥＲＰ）」ソフトウエアシステムは、多くの現代ビジネスの運営で非常に重要な役割を果たし、広範な複合ソフトウエアシステムを含んでいる。例としては、「ＳＡＰ ＡＧ」（ウォールドルフ、ドイツ）のソフトウエアシステム、特に「ＳＡＰ Ｒ／３」（ＳＡＰによって提供される標準ビジネスソフトウエア）に基づくもののような統合システム、及び企業規模の統合のための多層クライアント／サーバシステムを特徴とする関連システムが含まれる。ＥＲＰソフトウエアシステムの他の例には、「ＰｅｏｐｌｅＳｏｆｔ Ｉｎｃ．」（プレサントン、カリフォルニア）の製品、例えばその「企業人的資本管理」システム、Ｏｒａｃｌｅ（レッドウッド・ショアズ、カリフォルニア）の製品、例えばその「Ｏｒａｃｌｅ企業マネージャ」、「ＳＳＡ Ｇｌｏｂａｌ」（シカゴ、イリノイ）の製品、例えばその「ＳＳＡ ＥＲＰ（ＬＮ）」システム及び関連ソフトウエア、及びＳｉｅｂｅｌ（サン・マテオ、カリフォルニア）の製品、例えばその「ＣＲＭ ＯｎＤｅｍａｎｄ」顧客関係管理システム及び他のＳｉｅｂｅｌソフトウエアが含まれる。このようなシステムは、相互に関連した数百又は数千のモジュールを含む場合がある。複合ソフトウエアシステムを実施する際には、多くの場合に、外部供給業者からのソフトウエアを会社又は他のエンティティの既存システムと組み合わせるために多数のソフトウエアモジュールのカスタムプログラミングを必要とする。システムの実施中又は実施後にコンポーネントがいずれかの方法で修正される時には、ユーザ又は様々なソフトウエアモジュールの供給業者のいずれかにより、統合されたシステムが望み通りの性能を有することを確かめるために広範囲の試験が必要である。過去には、変更が行われた時にどの試験を繰り返す必要があるかを判断するために、統合システムのコンポーネント間の複雑な関係を手作業で追跡するために大量の人的労力が費やされてきた。多数のエラーがこの過程で起こり、多くの場合に、全体システムにおける不必要な試験又は欠陥の見逃しをもたらす可能性がある。統合システムを試験するための従来の方法の非効率性のために何百万ドルも失われている。

ＥＲＰソフトウエアシステム及び他の複合ソフトウエアシステムの実施及び統合は、多くの場合に、１つ又はそれよりも多くの供給業者からの新しいソフトウエアモジュールを既存の「レガシー」システム（外部供給業者から複合システムを導入する前に存在して機能していた企業システム）に統合する段階を伴い、新及び旧システムにデータを通信して共有させるためにインタフェースのカスタムプログラミングを必要とする場合がある。例えば、販売又は在庫管理ソフトウエアのようなシステムを実行するためのレガシーシステムは、情報を外部供給業者のプログラムに伝える必要があるであろう。これは、レガシーシステムからの情報を複合システムで使用するために翻訳するためのカスタムインタフェースプログラム（例えば、翻訳ソフトウエア）を準備する段階を必要とする場合がある。インタフェースモジュール、業者供給ソフトウエアモジュール、及び他のソフトウエアモジュールと結合したソフトウエアシステムが、複合ソフトウエアシステムにうまく統合されるためには、コンポーネントが意図した通りに機能することを確かめるための広範囲な統合試験が必要である。しかし、全ての必要なデータが、提供されたデータに依存する場合がある全てのモジュールに対して適正な形式で提供されることを保証するために、インタフェースモジュールを通じて提供されたデータを使用するあらゆるモジュールに試験が必要な場合もあるので、単にインタフェースモジュールだけを試験することでは不適切であろう。複合ソフトウエアシステム内の様々なモジュール間の関係が完全に理解されていない場合、試験を行うオペレータは、多すぎるテストケースを実行するか、新しい又は更新されたインタフェースによって影響を受けていない複合ソフトウエアシステムの要素を試験するか、又は影響を受けた１つ又はそれよりも多くのモジュールの作動を検証するのに必要な適正なテストケースを実行し損なう場合がある。

残念ながら、広範囲な試験に対する必要性は、個々のソフトウエアモジュールが更新される時にも引き続き存在する。すなわち、段階的導入中の複合システムの作動を検証するのに必要な膨大な量の試験に加えて、供給業者からの多数のソフトウエアモジュールのいずれかが更新されて、更新されたモジュール及びそれに依存するモジュールに行われる付加的な試験を必要とする場合がある。更新が既存の処理を変更しないこと（すなわち、前に機能していたシステムが予想されるように依然として機能すること）を保証するための試験の処理は、多くの場合に「回帰試験」と呼ばれる。複合ソフトウエアシステムのどの態様が１つ又はそれよりも多くのソフトウエアモジュールの変更によって影響を受けるか（又は、プログラムのどの態様がコードの１つ又はそれよりも多くの部分の変更によって影響を受けるか）を判断する処理は、「インパクト解析」又は時には「変化解析」として公知である。これらの分野での過去の開発における代表的な仕事は、カリフォルニア州ロスアラミトスのＳｈａｗｎ Ａ．Ｂｏｈｎｅｒ及びＲｏｂｅｒｔ Ｓ．Ａｒｎｏｌｄ編「ソフトウエア変化インパクト解析」、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｐｒｅｓｓ，１９９６年である。特に関連する章は、第３章「インパクト解析のための自動化サポート」、第４章「依存関係解析手法」、第５章「追跡可能性手法」、及び第７章「インパクト判断技術」を含む。

ソフトウエア試験のいくつかの態様を自動化するための様々なツールが公知である。例えば、「Ｓｉｅｂｅｌ ７」システム（顧客関係管理ソフトウエア）の統合及び実施は、Ｅｍｐｉｒｉｘ（ボールダー、コロラド）からのツールを使用して支援されるといわれている。これは、２００３年１０月７日付けのｈｔｔｐ：／／ｗｗｗ．ｅｍｐｉｒｉｘ．ｃｏｍ／ＮＲ／Ｅｍｐｉｒｉｘ／ＮＣＲｅｓｏｕｒｃｅｓ／ｗｐ ｗｔｍ ｔｅｓｔｉｎｇ ｅｓｓｅｎｔｉａｌｓ ｆｏｒ ｓｉｅｂｅｌ ７ ｄｅｐｌｏｙｍｅｎｔｓ．ｐｄｆからダウンロードされるＤａｎ Ｋｏｌａｓｋｉ著「有効なウェブアプリケーション試験処理の実施」という名称のホワイトペーパーに説明されている。このシステムのためのソフトウエア試験の原理はまた、２００３年１０月７日付けのｈｔｔｐ：／／ｗｗｗ．ｅｍｐｉｒｉｘ．ｃｏｍ／ＮＲ／Ｅｍｐｉｒｉｘ／ＮＣＲｅｓｏｕｒｃｅｓ／ｗｐ ｗｔｍ ｔｅｓｔｉｎｇ ｅｓｓｅｎｔｉａｌｓ ｆｏｒ ｓｉｅｂｅｌ ７ ｄｅｐｌｏｙｍｅｎｔｓ．ｐｄｆからダウンロードされるＤａｎ Ｋｏｌａｓｋｉ著「「Ｓｉｅｂｅｌ ７」配備のための試験要項」という名称のホワイトペーパーに開示されている。一般的に、自動試験のための代表的なツールは、ユーザアクションを模擬するスクリプトを作成するための捕捉及び再生ツール、及び自動的に実行されたスクリプトに応じてソフトウエアのアクションを観察することができる試験ツールを含む。

ソフトウエア試験のために使用される１つのツールは、ｈｔｔｐ：／／ｗｗｗ．ｒａｔｉｏｎａｌ．ｃｏｍ／ｔｒｙｉｔ／ｒｅｑｐｒｏ／ｓｅｅｉｔ．ｊｓｐで入手可能なデモンストレーションを備えたＩＢＭのＲｅｑｕｉｓｉｔｅＰｒｏである。他のツールは、例えば、「Ｍｅｒｃｕｒｙ Ｉｎｔｅｒａｃｔｉｖｅ」（マウンテン・ビュー、カリフォルニア）による、例えば「Ｍｅｒｃｕｒｙ Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｔｅｓｔｉｎｇ（登録商標）」（例えば、２００４年１０月７日付けで閲覧されるｈｔｔｐ：／／ｉｔｒｅｓｅａｒｃｈ．ｆｏｒｂｅｓ．ｃｏｍ／ｄｅｔａｉｌ／ＲＥＳ／１０９２０７２５８６ ６３７．ｈｔｍｌを参照されたい）又は「Ｍｅｒｃｕｒｙ Ｔｅｓｔ Ｄｉｒｅｃｔｏｒ（登録商標）」、「Ｓｅｇｕｅ Ｓｏｆｔｗａｒｅ、Ｉｎｃ．」（レキシントン、マサチューセッツ）による、２００４年１０月７日付けで閲覧されるｈｔｔｐ：／／ｗｗｗ．ｓｅｑｕｅ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｆｕｎｃｔｉｏｎａｌ−ｒｅｇｒｅｓｓｉｏｎａｌ−ｔｅｓｔｉｎｇ／ｓｉｌｋｔｅｓｔ．ａｓｐに説明されている回帰及び機能試験のための「Ｓｉｌｋ Ｔｅｓｔ（登録商標）」ソフトウエア、及び「Ｅｍｐｉｒｉｘ Ｉｎｃ．」（ウォルサム、マサチューセッツ）による、「ウェブ」アプリケーションのための自動的な機能及び回帰試験を提供するために使用され、かつ訪れた「ウェブ」ページ毎にオブジェクトを記録してオブジェクトを確認するために自動的にテストケースを挿入するといわれている「ｅ−Ｔｅｓｔｅｒ（登録商標）」ソフトウエアとして市販されている。

自動回帰試験のためのツールの別の例は、本明細書と矛盾しない範囲で本明細書において引用により組み込まれている、２００２年７月３０日にＭｕｍｆｏｒｄ他に付与された「自動的に作成されたログを使用する自動試験の実行」という名称の米国特許第６，４２７，０００号に説明されている。Ｍｕｍｆｏｒｄ他の特許は、サービスアプリケーションの新しいリリース毎に新しい試験アプリケーションを作成する必要がないように、自動的に作成されたログを使用してサービスアプリケーションに自動試験を行うシステムを開示しているといわれている。Ｍｕｍｆｏｒｄ他は、サービスアプリケーションの処理を妨害することなく実行された全てのデータ及び処理を考慮することによるサービスアプリケーションの試験法を更に提供している。「自動回帰試験器（ＡＲＴ）」は、サービスアプリケーションの最初のバージョンの実行によって作成されたデータを捕捉して記録する。このデータは、第１試験ログに記録される。そのサービスアプリケーションの新しい又は移植バージョンが開発された時に、第１試験ログは、ＡＲＴによって使用されて、呼び出し側及びユーザ入力を含むサービスアプリケーションの作動環境をエミュレートする出力を作成する。サービスアプリケーションの新規／移植バージョンの処理は、第２試験ログに捕捉されて記録される。ＡＲＴは、次に第２試験ログを第１試験ログと比較し、データのどのような相違も報告する。このような相違は、サービスアプリケーションの新規／移植バージョンのバグを示すことがある。

別の自動ツールは、矛盾しない範囲で本明細書において引用により組み込まれている、２００４年２月１７日にＳｔｏｖａｌ他に付与された「ワークステーションソフトウエアの自動回帰試験」という名称の米国特許第６，６９４，５０９号に説明されている。Ｓｔｏｖａｌの特許は、アプリケーションプログラムを回帰試験するのに使用するための試験スクリプトのライブラリを維持する方法及び手段を開示している。より具体的には、アプリケーションプログラムのための実行可能なコードを編集するために使用されるソースディレクトリツリーの鏡像である試験ディレクトリツリーが維持される。試験ディレクトリツリーは、同じディレクトリツリー内の対応するエントリから編集された実行可能なコードを回帰試験するのに使用されることになる試験スクリプトを示している。また、本明細書と矛盾しない範囲で本明細書において引用により組み込まれている、Ｃｏｈｅｎ及びＶｏｌｌｅｒｓにより２００４年５月５日公開の「ソフトウエア回帰試験の自動記録及び再生」という名称の米国特許公開番号ＵＳ２００４００８８６０２Ａ１も参照されたい。

ＳＡＰシステムの実施に対しては、１つの一般的に使用されるツールは、「コンピュータ支援ソフトウエアエンジニアリング（ＣＡＳＥ）」ツールのカテゴリに入る「コンピュータ支援試験ツール（ＣＡＴＴ）」である。ＣＡＴＴは、ＳＡＰの「ＡＢＡＰ開発ワークベンチ」に統合される。ＣＡＴＴにより、ＳＡＰソフトウエアと共に機能するものは、正確に定められた入力（バッチ入力）に基づいて試験フローを自動化することができる。試験がＣＡＴＴによって実行された後に、「Ｒ／３システム」は、保存されて様々な試験結果の文書化の基礎として機能する実行ログを自動的に作成することができる。試験結果は、次に、システムの品質を評価するために調べることができる。ＣＡＴＴは、本発明の実行を支援するためのツールとして使用することができる。例えば、それを使用してキーストロークを捕捉してデータを挿入し、個人に手動でトランザクションの実行及びデータの記入をさせる代わりにテストケースを自動で実行することができる。ＳＡＰのためのＣＡＴＴの使用は、Ｇｅｒｈａｒｄ Ｏｂｅｒｎｉｅｄｅｒｍａｉｅｒ及びＭａｒｃｕｓ Ｇｅｉｓｓ著「ＳＡＰのＲ／３システムの試験法：コンピュータ支援試験ツールの使用」、英国ハーローのＪａｓｏｎ Ｍ．Ｍｉｓｋｕｌｙ翻訳、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，２０００年で詳しく説明されている（特に、２８〜２１３ページを参照されたい）。

自動ソフトウエア試験のための一般的原理は、ｈｔｔｐ：／／ｗｗｗ．ｓｑａ−ｔｅｓｔ．ｃｏｍ／ｍｅｔｈｏｄ．ｈｔｍｌで「Ａｕｔｏｍａｔｅｄ Ｔｅｓｔｉｎｇ Ｓｐｅｃｉａｌｉｓｔｓ」（ロサンゼルス、カリフォルニア）の「ウェブ」ページ上で説明されている。そこに説明されているのは、スクリプト開発方法論を使用して全てのテストケースをその最も基本的なタスクまで低減する「機能的分解法」である。ユーザ定義機能、ビジネス機能スクリプト、及び「サブルーチン」又は「ユーティリティ」スクリプトは、互いに独立してこれらのタスクを実行する。自動試験スクリプトは、入力及び予想される結果の検証の両方を提供するためにデータファイルを使用してビジネス機能に対して書き込むことができる。構造化又はモジュール式設計を使用する階層アーキテクチャが用いられる。同じく説明されているのは、機能性を含む試験処理全体がデータ駆動式である「試験計画駆動」方法である。試験計画は、自動試験の処理を制御するために事前に書き込まれた「ユーティリティ」スクリプトが使用する特定のフォーマットで準備される。２００３年１０月７日付けで閲覧されるｈｔｔｐ：／／ｗｗｗ．ｓｑａ−ｔｅｓｔ．ｃｏｍ／ｔｏｏｌｋｉｔ．ｈｔｍｌに説明されている「ＷｉｎＲｕｎｎｅｒ（登録商標）」のための「ＡＴＳ Ｔｏｏｌｋｉｔ」を含む混成方法論を使用することもできる。

ソフトウエア試験のための指針は、一般的に、Ｃ．Ｋａｎｅｒ、Ｊ．Ｆａｌｋ、及びＨ．Ｑ．Ｎｇｕｙｅｎ著「コンピュータソフトウエアの試験法」（ニューヨーク：Ｗｉｌｅｙ Ｃｏｍｐｕｔｅｒ Ｐｕｂｌｉｓｈｉｎｇ、１９９９年）に説明されている。自動回帰試験は、ページ１９１〜１９７に説明されている。自動ソフトウエア試験の原理も、Ｅｌｆｒｉｅｄｅ Ｄｕｓｔｉｎ、Ｊｅｆｆ Ｒａｓｈｋａ、及びＪｏｈｎ Ｐａｕｌ著「自動ソフトウエア試験法」（ボストン：Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、１９９９年、ページ２９３及び２９５〜３０６）に詳しく説明されている。

１つのソフトウエアセグメントの変化の他方のソフトウエアセグメントへの影響として知られているインパクト解析が公知である。インパクト解析の最近の進歩は、Ａ．Ｏｒｓｏ、Ｔ．Ａｐｉｗａｔｔａｎａｐｏｎｇ及びＭ．Ｊ．Ｈａｒｒｏｌｄ著「インパクト解析及び回帰試験のためのフィールドデータの利用」、ＥＳＥＣ／ＦＳＥ’０３（ソフトウエアエンジニアリング財団：ソフトウエアエンジニアリング財団での第１０回「ＡＣＭ ＳＩＧＳＯＦＴ」国際シンポジウムと共に開催された第９回ヨーロッパソフトウエアエンジニアリング会議紀要）、２００３年９月１日〜５日、ヘルシンキ、フィンランド、ＡＣＭ（米国計算機学会）発行、ニューヨーク、２００３年、ページ１２８−１３７によって説明されている（ｈｔｔｐ：／／ｄｏｉ．ａｃｍ．ｏｒｇ／１０．１１４５／９４００７１．９４００８９を参照されたい）。インパクト解析に関する背景情報は、本明細書において引用により組み込まれている、Ｓｈａｗｎ Ａ．Ｂｏｈｎｅｒ及びＲｏｂｅｒｔ Ｓ．Ａｒｎｏｌｄ著「入門ソフトウエア変化インパクト解析」、ソフトウエア変化インパクト解析（ロスアラミトス、カリフォルニア：ＩＥＥＥコンピュータ学会出版、１９９６年、ページ１〜２６）によって提供されている。Ｂｏｈｎｅｒ及びＲｏｂｅｒｔは、仕様から完成プログラムまでのソフトウエアプロジェクトの全ての態様を含むソフトウエアライフサイクルオブジェクト（ＳＬＯ）に言及しており、また、ソフトウエアの変更を行う影響を説明している。彼らは、ソフトウエア設計上の変更が、要件及び仕様の変更、設計トレードオフ、インタフェース変更、性能問題、プロトタイプからのフィードバックなどのような多くの目的に対して必要になる可能性がある点に注目している。プログラムそれ自体の変更は、バグ修正、アルゴリズム調節、データ構造修正、パラメータ変更などの結果とすることができる。このような変更を扱う場合、システムの他のコンポーネントに対するその変更の影響及びソフトウエアに対する要件及び目的への影響を解析する必要性が存在する。公知のツールの中で、Ｂｏｈｎｅｒ及びＡｒｎｏｌｄは、「Ｃで開発された大きなシステムに見られる複雑な相互関係を理解することを助ける」ためにウエストフロリダ大学のＮｏｒｍａｎ Ｗｉｌｄｅによって開発された「依存関係解析ツールセット」を挙げている。彼らはまた、米国空軍によって開発されたインパクト解析ツールである「Ａｌｉｃｉａ」も説明している。

同じく当業技術で公知のものは、ソフトウエアの目的をサポートするために使用されるソフトウエアモジュールや文書などの追跡の方法として公知の追跡可能性行列の概念である。従来の作業では、追跡可能性行列は、一般的に手作業で作成され、複数レベルの依存関係及びコンポーネント間の複雑な相互関係に関する詳細な情報を包含していなかった。むしろ、公知の追跡可能性行列は、ソフトウエア要件又は仕様とソフトウエアモジュールとの間の基本的関係の表面的な一次（単一レベル）の展望を表している。

一般的に、「エンタープライズ・リソース・プラニング」システムのような複合ソフトウエアシステムの作動を検証する試験ソフトウエアモジュールの困難性は、組織内の最も困難でコストのかかる人的資源集中型活動の１つを容易に表すことができる。この結果、試験ソフトウエアモジュールの処理を改良し、このような処理を合理化する方法に対する必要性が存在する。冗長な試験の低減及び不必要な試験実行の排除が望ましいが、それらは現在利用可能ではない。

「モジュール性−関係解析」を構成する必要性の従来の認識にも関わらず、過去の努力は、このような解析を処理するための手作業的手法が支配してきたように見える。「追跡可能性行列」を利用する回帰試験のための自動ツールは、既知であるようには見えず、回帰試験に含む必要があるテストケースを識別するためのソフトウエアモジュール間の関係の「ロードマップ」を自動的に作成する既知のツールがあるようにも見えない。

手動又はコンピュータベースの要件追跡ツールは、ソフトウエアの目標をその目標を供給するモジュールと関連付けるために存在するが、これらのツールは、一般的に、複合ソフトウエアシステムのモジュール又は他のコンポーネント間の複数レベルの依存関係に関する詳細な情報を提供しない。実際に、多くのツールが、個々のソフトウエアプログラムの解析を支援し又は複合ソフトウエアシステムの試験の様々な態様を自動化するために開発されてきたが（例えば、ＳＡＰの実施を支援するのに使用されるＣＡＴＴツール）、試験を更に効率良くするために、及び、特にレガシーコンポーネントを含む複数の供給業者からのソフトウエアを統合すべきである時に複合ソフトウエアシステムの実施に関連した問題の多くを解決するために、複合ソフトウエアシステムのための改良された自動ツールに対する必要性が依然として存在する。

他の場合には、自動ソフトウエア試験のためのテストケース及びスクリプトの使用が、時には従来の追跡可能性行列と共に提案されてきたが、どのテストケースを所定のソフトウエア修正に応じて実行する必要があるかを効率良く選択する機能が一般的に欠けていた。ソフトウエアモジュールとテストケースとの間の複雑な相互関係を自動的に識別することを可能にし、オペレータがテストケースのどの部分が再試験を必要とするかに関するより効率的な判断を行うことを可能にする改良型自動ソフトウエアツールに対する必要性が存在する。また、１つ又はそれよりも多くのソフトウエアモジュール又は他のシステムコンポーネントの変更の後の適正な試験に必要なテストケースをより効率良く選択するために、影響を受けたテストケース間の関係の自動ロードマップを提供する「追跡可能性行列」内のデータを利用することができるソフトウエア試験を支援するためのツールに対する必要性も存在する。

米国特許出願出願番号第６０／５１７，６３１号 米国特許第６，４２７，０００号 米国特許第６，６９４，５０９号 ＵＳ２００４００８８６０２Ａ１ 米国特許第６，２１６，１０９号 米国特許第６，６０１，２３３号 米国特許第５，７５８，０６２号 米国特許第５，７８１，７２０号 米国特許第６，０６１，６４３号 米国特許第６，１９２，１０８号 米国特許第５，９５３，５１９号 ＵＳ２００１００４９５９４Ａ１ 米国特許第６，３０１，７０１号 米国特許公開２００４００６８７１４ 米国特許第６，８０１，８１８号 ＵＳ２００３００９３４７８Ａ１ ＷＯ９７／１２３１１ ＵＳ２００４０１０３３９６Ａ１ Ｓｈａｗｎ Ａ．Ｂｏｈｎｅｒ及びＲｏｂｅｒｔ Ｓ．Ａｒｎｏｌｄ編「ソフトウエア変化インパクト解析」、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｐｒｅｓｓ，１９９６年 Ｄａｎ Ｋｏｌａｓｋｉ著「有効なウェブアプリケーション試験処理の実施」、ホワイトペーパー、ｈｔｔｐ：／／ｗｗｗ．ｅｍｐｉｒｉｘ．ｃｏｍ／ＮＲ／Ｅｍｐｉｒｉｘ／ＮＣＲｅｓｏｕｒｃｅｓ／ｗｐ ｗｔｍ ｔｅｓｔｉｎｇ ｅｓｓｅｎｔｉａｌｓ ｆｏｒ ｓｉｅｂｅｌ ７ ｄｅｖｅｌｏｐｍｅｎｔｓ．ｐｄｆ、２００３年１０月７日 Ｄａｎ Ｋｏｌａｓｋｉ著「「Ｓｉｅｂｅｌ ７」配備のための試験要項」、ホワイトペーパー、ｈｔｔｐ：／／ｗｗｗ．ｅｍｐｉｒｉｘ．ｃｏｍ／ＮＲ／Ｅｍｐｉｒｉｘ／ＮＣＲｅｓｏｕｒｃｅｓ／ｗｐ ｗｔｍ ｔｅｓｔｉｎｇ ｅｓｓｅｎｔｉａｌｓ ｆｏｒ ｓｉｅｂｅｌ ７ ｄｅｐｌｏｙｍｅｎｔｓ．ｐｄｆ、２００３年１０月７日 Ｇｅｒｈａｒｄ Ｏｂｅｒｎｉｅｄｅｒｍａｉｅｒ及びＭａｒｃｕｓ Ｇｅｉｓｓ著「ＳＡＰのＲ／３システムの試験法：コンピュータ支援試験ツールの使用」、Ｊａｓｏｎ Ｍ．Ｍｉｓｋｕｌｙ翻訳、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，２０００年 ｈｔｔｐ：／／ｗｗｗ．ｓｑａ−ｔｅｓｔ．ｃｏｍ／ｍｅｔｈｏｄ．ｈｔｍｌ、Ａｕｔｏｍａｔｅｄ Ｔｅｓｔｉｎｇ Ｓｐｅｃｉａｌｉｓｔｓ、ロサンゼルス、カリフォルニア 「ＷｉｎＲｕｎｎｅｒ（登録商標）」のための「ＡＴＳ Ｔｏｏｌｋｉｔ」、ｈｔｔｐ：／／ｗｗｗ．ｓｑａ−ｔｅｓｔ．ｃｏｍ／ｔｏｏｌｋｉｔ．ｈｔｍｌ、２００３年１０月７日 Ｃ．Ｋａｎｅｒ、Ｊ．Ｆａｌｋ、及びＨ．Ｑ．Ｎｇｕｙｅｎ著「コンピュータソフトウエアの試験法」（ニューヨーク：Ｗｉｌｅｙ Ｃｏｍｐｕｔｅｒ Ｐｕｂｌｉｓｈｉｎｇ、１９９９年） Ｅｌｆｒｉｅｄｅ Ｄｕｓｔｉｎ、Ｊｅｆｆ Ｒａｓｈｋａ、及びＪｏｈｎ Ｐａｕｌ著「自動ソフトウエア試験法」（ボストン：Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、１９９９年、ページ２９３及び２９５〜３０６） Ａ．Ｏｒｓｏ、Ｔ．Ａｐｉｗａｔｔａｎａｐｏｎｇ及びＭ．Ｊ．Ｈａｒｒｏｌｄ著「インパクト解析及び回帰試験のためのフィールドデータの利用」、ＥＳＥＣ／ＦＳＥ’０３、２００３年９月１日〜５日、ヘルシンキ、フィンランド、ＡＣＭ（米国計算機学会）発行、ニューヨーク、２００３年、ページ１２８−１３７ Ｓｈａｗｎ Ａ．Ｂｏｈｎｅｒ及びＲｏｂｅｒｔ Ｓ．Ａｒｎｏｌｄ著「入門ソフトウエア変化インパクト解析」、ソフトウエア変化インパクト解析（ロスアラミトス、カリフォルニア：ＩＥＥＥコンピュータ学会出版、１９９６年、ページ１〜２６） Ｄｕｓｔｉｎ他著「自動ソフトウエア試験」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、ボストン、１９９９年、７６−８９ページ及び４１７−４７３ページ 「ＰｅｏｐｌｅＳｏｆｔ企業の全所有権経験」、ホワイトペーパー、２００４年１０月、「ＰｅｏｐｌｅＳｏｆｔ、Ｉｎｃ．」（プレサントン、カリフォルニア） Ｎｏｒｂｅｒｔ Ｗｅｌｔｉ著「ＥＲＰプロジェクトの実際の管理」、「ＳＡＰ Ｒ３」の成功した実施例：Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂ Ｃｏ．、１９９９年（ＩＳＢＮ：０２０１３９８２４９） Ｂｒａｄｌｅｙ Ｄ．Ｈｉｑｕｅｔ、Ｋｅｌｌｅｙ−Ｌｅｖｅｙ、Ａｓｓｏｃｉａｔｅｓ、及びＡｎｔｈｏｎｙ Ｆ．Ｋｅｌｌｙ著「Ｓａｐを理解するための管理者のガイド」、「ＳＡＰ Ｒ／３」実施ガイド：Ｍａｃｍｉｌｌａｎ Ｔｅｃｈｎｉｃａｌ Ｐｕｂｌｉｓｈｉｎｇ、１９９８年（ＩＳＢＮ：１５７８７００６３９） Ｇｅｒｈａｒｄ Ｋｅｌｌｅｒ及びＴｈｏｍａｓ Ｔｅｕｆｅｌ著「反復処理プロトタイピング」、「ＳＡＰ Ｒ／３」処理志向実施例：Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂ Ｃｏ．、１９９８年（ＩＳＢＮ：０２０１９２４７０６） Ｇｅｒｈａｒｄ Ｏｂｅｒｎｉｅｄｅｒｍａｉｅｒ及びＭａｒｃｕｓ Ｇｅｉｓｓ著、Ｊａｓｏｎ Ｍ．Ｍｉｓｋｕｌｙ翻訳「コンピュータ支援試験ツールの使用」、「ＳＡＰ Ｒ／３」システムの試験：Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、２０００年（特に２８−２１３ページ） Ｇｒａｎｔ Ｎｏｒｒｉｓ他著「管理者のための包括的ガイド」、ＳＡＰ：Ｊｏｈｎ Ｗｉｌｅｙ ａｎｄ Ｓｏｎｓ、１９９８年（ＩＳＢＮ：０４７１２４９９２０） Ｂ．Ｙｅａｇｅｒ著「ＭｅａｄのＥＲＰシステムは「Ｂｅｓｔ ｏｆ Ｂｒｅｅｄ」ソフトウエアを統合する」、ＰＩＭＡの「Ｎｏｒｔｈ Ａｍｅｒｉｃａｎ Ｐａｐｅｒｍａｋｅｒ」、第８２巻、第４号、２０００年４月、３６ページ Ｏ．Ｗｉｅｓｅｒ著「処理制御システム及びラボラトリ情報システムの論理チェーンへの統合」、Ａｕｔｏｍａｔｉｓｉｅｒｕｎｇｓｔｅｃｈｎｉｓｃｈｅ Ｐｒａｘｉｓ、第３９巻、第２号、１９９７年２月、２６−２８ページ Ｄｕｓｔｉｎ他、３０５−３０６、４２４−４２６ページ Ｄｕｓｔｉｎ他、２０６−２１１ページ Ｋ．Ｂ．Ｇａｌｌａｇｈｅｒ及びＪ．Ｒ．Ｌｙｌｅ著「ソフトウエアメンテナンスにおけるプログラムスライシングの使用」、Ｓｈａｗｎ Ａ．Ｂｏｈｎｅｒ及びＲｏｂｅｒｔ Ｓ．Ａｒｎｏｌｄ編「ソフトウエア変化インパクト解析」（ロスアラミトス、カリフォルニア、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｐｒｅｓｓ、１９９６年、３１９−３２９ページ Ｓｈａｗｎ Ａ．Ｂｏｈｎｅｒ著「デザイン革命のためのソフトウエア変化インパクト解析」、ソフトウエア変化インパクト解析、６７−８１ページ Ｂｏｈｎｅｒ及びＡｒｎｏｌｄ著「入門ソフトウエア変化インパクト解析」、ソフトウエア変化インパクト解析、１−２６ページ（特に１５ページ） Ｄ．Ｅ．Ｐｅｒｒｙ著「Ｉｎｓｃａｐｅ環境」、ソフトウエア工学のための国際会議紀要（ロスアラミトス、カリフォルニア、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｐｒｅｓｓ、１９８９年）

「自動多次元追跡可能性行列」を含む自動ソフトウエア追跡及び試験ツールは、複合ソフトウエアシステムの様々なコンポーネント間の複雑な関係を追跡し、複合ソフトウエアシステムの統合及びその後に修正に必要な回帰試験を支援するために開発されてきた。「自動多次元追跡可能性行列」は、テストケース（複合ソフトウエアシステムの１つ又はそれよりも多くのソフトウエアコンポーネントの挙動を試験するための一連の特定のトランザクションを伴う所定のシナリオ）及び／又は複合ソフトウエアシステムの個々のコンポーネント間の関係情報を記憶するために使用される。コンポーネントが修正される場合、「自動多次元追跡可能性行列」（場合によっては本明細書で「追跡可能性行列」と呼ばれるか又は一部の図では「Ｔ．Ｍ．」のように略される）内の情報が次にアクセスされ、複合ソフトウエアシステムの機能を効率的に試験するために実行する必要のある場合があるテストケースのリストを自動的に作成する。（必要に応じて、更に別の自動スクリーニング処理によるか又はオペレータの判断に基づいて、列挙されたテストケースのより小さな部分集合が作成される場合がある。）本発明の自動ツールは、製造工程、供給チェーン内の製品、販売などに関する情報のようなリアルタイムの情報を取得する機能を提供するＳＡＰベースシステム及び自動データ収集（ＡＤＣ）システムのようなＥＲＰシステムを実施及び更新するのに特に有用である。分散型制御システム、電気通信システム、財務解析システム、物流システム、インテリジェント製造システムなどを含む他の複合ソフトウエアシステムを処理することもできる。

自動ツールはまた、複合ソフトウエアシステムの様々なコンポーネントに関連した文書化に関する情報を提供し、修正されたコンポーネント並びにあらゆる関連のコンポーネントの文書化が検討を必要とすると考えられる時を示して、複合ソフトウエアシステムの１つ又はそれよりも多くのコンポーネントの改訂後にそれが最新であることを保証することができる。
本発明の試験システムは、複合ソフトウエアシステムコンポーネント間のリンケージを自動的に判断して追跡する段階と、どのテストケースが更に別の試験を必要とするかを示すためのレポートを自動的に生成する段階と、前の作業からのどのテストケースがシステムへの修正によって影響を受けたかを識別する段階と、内部要件又は法的要件の遵守を保証するために変更の監査を可能にして（文書を作成して）、同時に法的分野に対しても同様にこのようなサポートを提供する段階とを含む様々な特徴を含むことができる。更に、自動ツールは、テストケースが実行された時に予想される結果と実際の結果の間の相違を自動的に検出し、任意的に、相違を補正するためにどのモジュールが改訂を必要とすると考えられるかを自動的に識別するように構成することができる。

一実施形態では、本発明の自動試験ツールは、複数の相互に関連するシステムコンポーネントを有する複合ソフトウエアシステムの合理化された試験のための試験ツールと、複数の相互に関連するシステムコンポーネントの性能を試験するための一組の試験シナリオとして説明することができ、この試験ツールは、ａ）依存関係及び従属関係の１つ又はそれよりも多くのチェーンを通じて１つ又はそれよりも多くのコンポーネントの所定の選択にリンクした相互に関連するシステムコンポーネントの部分集合を特定するようになった、相互に関連するシステムコンポーネント間のリンケージを判断するための「自動多次元追跡可能性行列」システム、ｂ）システムコンポーネントの１つ又はそれよりも多くの変更を識別するための手段、ｃ）システムコンポーネントの１つ又はそれよりも多くの変更の識別に応じて、相互に関連するコンポーネントのどれが変更によって影響を受けると考えられるかを判断するために「自動多次元追跡可能性行列」を適用するための手段、ｄ）変更によって影響を受けると考えられる相互に関連するコンポーネントに関連した試験シナリオの全て又はその部分集合を自動的に実行するための手段、及びｅ）実行された試験シナリオの結果を評価するための手段を含む。

試験ツールでは、システムコンポーネントの１つ又はそれよりも多くの変更を識別するための手段は、自動化することができるか又は部分的に自動化することができ、また、実行可能ファイル（例えばバイナリコードコンパレータ、又は作成日付、ファイルサイズ、チェックサムスコア、タイムスタンプパラメータなどを調べるソフトウエア）の変更を検出するか又はデータセット、スクリプト、データベース記録、及び文書修正日付などの同様の又は他の変更を検出するファイルスキャナのような電子ツールを含むことができる。このような目的のためのプログラムは、当業技術で公知である。システムコンポーネントの１つ又はそれよりも多くの変更を識別するための手段はまた、変更に関する情報の手動入力段階を含むことができる。

試験ツールでは、実行された試験シナリオの結果を評価するための手段は、出力情報と変更の前に試験シナリオから作成された以前の出力情報との手動比較、又はその目的のための公知のコンピュータプログラムを使用したファイルの自動又は半自動比較を含むことができる。実行された試験シナリオの結果を評価するための手段は、出力情報と、変更（例えば、ベースラインに対する変更）の前に試験シナリオから作成された以前の出力情報とのコンピュータ実行比較を含むことができる。

試験ツールは、「ＳＡＰ Ｒ／３」の実施に適応させることができ、更に、選択されたスクリプトを自動的に実行するために「コンピュータ支援試験ツール」の使用を含むことができる。この試験ツールでは、複合ソフトウエアシステムは、少なくとも１人の他の当事者によって書かれて少なくとも１つの他の供給業者を通して供給されたレガシーソフトウエアに接続する少なくとも１つの供給業者からのソフトウエアを含むことができる。この試験ツールでは、複合ソフトウエアシステムは、ＥＲＰシステムとすることができる。この試験ツールは、「管理エンティティ」との電子通信を含む、ソフトウエアとこのソフトウエアに関連した文書との変更を監査するための手段を更に含むことができる。

別の実施形態では、本発明は、複合ソフトウエアシステムの統合試験又はシステム試験の少なくとも一方に対して、対応するソフトウエアコンポーネントを試験するための関連のテストケースの実行を案内するようになった試験スクリプトの本体から試験スクリプトの部分集合を自動的に選択するための試験ツールとして説明することができる。この実施形態では、試験ツールは、ａ）テストケース間のリンケージを形成するための「自動多次元追跡可能性行列」システム、ｂ）テストケース間のリンケージに関する情報を受信するためのグラフィカルユーザインタフェースであって、この情報がグラフィカルユーザインタフェースによって「自動多次元追跡可能性行列」システムに供給されるようなグラフィカルユーザインタフェース、ｃ）「自動多次元追跡可能性行列」システム内の情報に基づいて自動的に判断されるテストケース間の親−子関係を複数のレベルで図式的に表示するための手段、ｄ）複合ソフトウエアシステムのテストケースの１つ又はそれよりも多くの変更に応じて、複合ソフトウエアシステムの複数のコンポーネントの試験のためのテストケースの部分集合を選択するための手段、ｅ）テストケースのこの部分集合に関連した試験スクリプトを実行するための手段、及びｆ）実行された試験スクリプトによって作成された出力に基づいて、複合ソフトウエアシステムのステータスを評価するための手段を含む。

別の実施形態では、試験ツールは、複数の相互に関連するプログラムを有する複合システムソフトウエアシステムの試験での効率の改善のためのグラフィカルユーザインタフェースと、複数の相互に関連するプログラムの性能を試験するための一組のテストケースとを含み、グラフィカルユーザインタフェースは、ａ）依存関係の３つ又はそれよりも多いレベルにわたるリンケージを表示するようになった、複数の相互に関連するプログラムの選択された部分間のリンケージに関して「自動多次元追跡可能性行列」から出力情報を表示するための手段であって、この出力情報が１）選択されたプログラムに対する依存関係及び従属関係のリスト、及び２）選択されたプログラムを呼び出すことができるテストケースのリストのうちの少なくとも一方を含むような手段、ｂ）複数の相互に関連するプログラムの選択された部分間のリンケージに関して「自動多次元追跡可能性行列」から入力情報を受信するための手段、及びｃ）入力及び出力情報をグラフィカルユーザインタフェースから「自動多次元追跡可能性行列」をホストする少なくとも１つのサーバに通すための通信手段を含む。

別の実施形態では、本発明は、複数のソフトウエアコンポーネントを含む複合ソフトウエアシステムの性能の効率的な試験のためのテストケースの本体からのテストケースの部分集合を自動的に選択する方法を実行するためにコンピュータシステムを制御するための命令を収容するコンピュータ可読媒体を含む。各テストケースは、複合ソフトウエアシステム内の少なくとも１つのソフトウエアコンポーネントに関連しており、各テストケースはまた、テストケースのための複合ソフトウエアシステムによって実行される一連の命令を提供するスクリプトに関連している。本方法は、ａ）テストケースに対する依存関係及び従属関係に関する入力情報を受信するためにグラフィカルユーザインタフェースを表示する段階、ｂ）この入力情報を「自動多次元追跡可能性行列」に関連したデータベースに記憶する段階、ｃ）ソフトウエアコンポーネントの１つ又はそれよりも多くが変更されたことを示す変更通知を受信する段階、ｄ）変更されたソフトウエアコンポーネントの１つ又はそれよりも多くへ以前に形成したリンケージによってテストケースのどれがリンクされるかを判断するために「自動多次元追跡可能性行列」を適用する段階、ｅ）変更されたソフトウエアコンポーネントの１つ又はそれよりも多くにどのテストケースがリンクされるかを示すための情報を表示する段階、ｆ）自動的に又はユーザ選択に応じて、段階（ｅ）からリンクしたテストケースの全て又はその部分集合を選択する段階、ｇ）段階（ｆ）から選択されたリンクしたテストケースに関連したスクリプトを実行する段階、及びｈ）実行された試験スクリプトに対して予想される結果と後で比較するために、実行された試験スクリプトの結果を記憶する段階を含むことができる。
コンピュータ可読媒体は、１つ又はそれよりも多くのサーバ、ハードディスク、ＣＤ−ＲＯＭ、テープドライブ、磁気媒体、及び光媒体など、並びにコンピュータ命令を収容することができる信号及び波動関数を含むことができる。

別の実施形態では、本発明は、１つ又はそれよりも多くの供給業者によって提供される複数の統合されたソフトウエアモジュールを含む複合ソフトウエアシステムのための更新されたソフトウエアモジュールをユーザが試験する方法を含む。本方法は、ａ）供給業者から第１ソフトウエアモジュールのためのソフトウエア更新を受信する段階、ｂ）ＥＲＰシステムに更新された第１ソフトウエアモジュールを供給するために、サーバ上にソフトウエア更新をインストールする段階、ｃ）性能が更新第１ソフトウエアモジュールにリンクした複数のソフトウエアモジュールからのソフトウエアモジュールのリスト、又は性能が更新第１ソフトウエアモジュールにリンクしたソフトウエアモジュールに関連したテストケースのリストを自動的に作成するために「自動多次元追跡可能性行列」を適用する段階、ｄ）段階（ｃ）のリストの部分集合を選択し、関連の試験スクリプトを実行する段階、及びｅ）複合ソフトウエアシステムが適正に機能しているかを判断するために、実行された試験スクリプトの結果を評価する段階を含むことができる。

本発明の試験ツールは、デバッグするか又はそうでなければ問題を識別するか又は解決することを支援するために、あらゆる他の公知のソフトウエア試験ツールと統合させることができる。例えば、Ｄｕｓｔｉｎ他著「自動ソフトウエア試験」（ボストン：Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、１９９９年、７６−８９ページ及び４１７−４７３ページ、本明細書において引用により組み込まれている）は、ビジュアルモデリング、文法チェッカー、メモリ漏れ検出ツール、実行時エラー検出ツール、ソースコード試験ツール、静的及び動的アナライザ、未試験コードを識別するためのメトリクスツール、ＧＵＩ試験ツール、シミュレーションツール、ネットワーク試験ツール、及び負荷／性能試験ツールなどを含むソフトウエア試験の様々な段階で使用される多くの他のツールを説明している。

本発明はまた、搬送波に組み込まれたコンピュータデータ信号に関する。コンピュータデータ信号は、複合ソフトウエアシステム内の複数のソフトウエアモジュールの少なくとも１つと、複合ソフトウエアシステム内の相互に関連するソフトウエアモジュールの回帰試験のための複数のコンピュータ実装テストケースとの間の従属関係及び依存関係を定める情報を含む。コンピュータデータ信号はまた、従属関係及び依存関係に関する情報を図式的に伝達するためのコンピュータシステムのための命令を含むことができ、個々のテストケース又はソフトウエアモジュールは、互いに対するそれらの関係を示す方式で表され、表示された情報は、どの他のテストケース又はソフトウエアモジュールが変更によって影響を受ける場合があるかを示すことができる。情報は、グラフィックユーザインタフェースを使用して図式的に伝達される。更に、コンピュータデータ信号は、グラフィカルユーザインタフェースに対するユーザアクションに関連した所定のユーザアクションに応じて、選択された個々のテストケース又はソフトウエアモジュールに関する付加的な情報を表示するための命令を含むことができる。更に、コンピュータデータ信号は、次の試験のためにグラフィカルユーザインタフェース上に伝達された情報からテストケース又はソフトウエアモジュールを電子的に選択するための手段を提供する命令を含むことができる。

コンピュータデータ信号は、入力データセット、関連のテストケース、及び確認された出力結果の所定の集合からのベースライン情報を更に含むことができる。コンピュータデータ信号はまた、選択されたテストケース又はソフトウエアモジュールの手動又は自動実行を開始するための命令、及び実行されたテストケース又はソフトウエアモジュールからの出力結果を電子的に記憶するための命令を含むことができる。それとは別に、コンピュータデータ信号は、出力結果をベースライン情報と比較するための命令を含むことができる。コンピュータデータ信号は、出力結果とベースライン情報との間の相違を自動的に識別するための命令、及び相違を是正するための１つ又はそれよりも多くの推奨されるアクションを自動的に識別するための命令を含むことができる。付加的な態様では、コンピュータデータ信号は、出力結果とベースライン情報との間の日付特定の相違を除去するための命令を含むことができる。コンピュータデータ信号は、相違の原因を識別するためにコンピュータ化されたデバッグツールを実行するための命令を含むことができる。

付加的な態様では、コンピュータデータ信号は、複数の人間テスターに関する情報と、次の試験のためにグラフィカルユーザインタフェース上に伝達された情報からのテストケース又はソフトウエアモジュールのユーザの選択に応じてテスターの１人又はそれよりも多くによる試験作業をスケジューリングするための命令とを含むことができる。更に、コンピュータデータ信号は、複合ソフトウエアシステムの複数のソフトウエアモジュールの少なくとも１つと複数のコンピュータ実装テストケースとの間の従属関係及び依存関係を定める情報をユーザに修正させるための命令を含むことができる。コンピュータデータ信号は、試験行動及びソフトウエア修正を説明する情報が「管理エンティティ」に提供されるように「管理エンティティ」と通信するための命令を含むことができ、更に、ソフトウエアモジュールの変更を行う前に「管理エンティティ」に関連したエージェントからの許可をユーザが取得するように要求する命令を含むことができ、許可の取得はまた、「管理エンティティ」と共に記録される。

本発明の更に別の態様では、コンピュータデータ信号は、選択されたテストケース又はソフトウエアモジュールの１つ又はそれよりも多くの自動実行のための命令を含むことができる。複合ソフトウエアシステムは、２つ又はそれよりも多くの供給業者によって提供される、１００を超えるソフトウエアモジュールを含むことができる。これとは別に、複合ソフトウエアシステムは、３つ又はそれよりも多くの供給業者によって提供される、５００を超えるソフトウエアモジュールを含むことができる。複合ソフトウエアシステムは、２つ又はそれよりも多くの供給業者からの２つ又はそれよりも多くの個別のコンピュータオペレーティングシステムとのインタフェースを含むことができ、この個別オペレーティングシステムは、２つ又はそれよりも多くのサーバ上にある。複合ソフトウエアシステムは、ＳＡＰソフトウエアを含むことができる。更に、従属関係及び依存関係に関して図式的に伝達される情報は、階層形式で供給することができる。従属関係及び依存関係に関する図式的に伝達される情報は、フォルダアイコン、文書アイコン、「プラス」記号の付いたアイコン、「マイナス」記号の付いたアイコン、ページアイコン、及び矢印アイコンのうちの少なくとも１つを含む階層形式で供給することができる。図式的に伝達される情報は、選択されたテストケース又はソフトウエアモジュールに関する付加的な情報を提供するためのハイパーリンクを更に含むことができる。

定義
以下の語を本明細書での使用を明確にするために簡潔に定義する。更に詳しい説明は、本発明の以下の説明の中で提供する。
本明細書で使用される時の「自動捕捉」は、トランザクション自体内で試験の性能をモニタすることによってトランザクションのためのテストケースの作成を容易にするコンポーネントを意味する。すなわち、自動捕捉は、試験オペレータの挙動を観察し、同じ挙動を実行するか又は再現するテストケースを作成する。
本明細書で使用される時の「自動比較」は、２つの試験レポートを比較して、そこから差のレポートを生成するコンポーネントを意味する。差のレポートで作成された出力のフィルタリング又はカスタム化を可能にする付加的な機能も、自動比較コンポーネント内に含められる。
本明細書で使用される時の「クライアントサーバ」は、サーバコンピュータによってサービスが実行されることをクライアントコンピュータが要求する２つのソフトウエア処理間の関係を説明するものである。サーバコンピュータは、サーバを実行し、次に結果をクライアントに送信して戻す。クライアント及びサーバシステムは、単一機械上で作動することができるが、一般的には、クライアントサーバ作動は、ネットワークを通じて結合された別々のコンピュータを伴う。

本明細書で使用される時の「複合ソフトウエアシステム」は、ユーザによって実行される場合に統合が必要な複数の相互に関連するモジュールを含むあらゆるソフトウエアシステムを意味する。複合ソフトウエアシステムは、一般的に、供給業者からのモジュールと他の供給業者からの１つ又はそれよりも多くのレガシーシステムとを加えたもの、又は、企業内部で開発されたシステム、及び／又は、１つ又はそれよりも多くの供給業者からの商用ソフトウエア及びユーザによって準備されたカスタム化ソフトウエアのような２つ又はそれよりも多くの供給元からのアプリケーションソフトウエア（「Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）」及び「Ｌｉｎｕｘ（登録商標）」などのような基本オペレーティングシステムソフトウエアを含まない）の組合せのような２つ又はそれよりも多くの供給元からのモジュールを含む。一例として、複合ソフトウエアシステムは、約５０又はそれよりも多い、１００又はそれよりも多い、５００又はそれよりも多い、１０００又はそれよりも多い、又は３０００又はそれよりも多くのソフトウエアモジュールのような、約２０又はそれよりも多くの個別のソフトウエアモジュールを含むことができる。同じく一例として、複合ソフトウエアシステムは、２つ又はそれよりも多くの供給業者、３つ又はそれよりも多くの供給業者、５つ又はそれよりも多くの供給業者、又は１０又はそれよりも多くの供給業者によって提供される商用ソフトウエアを含むことができる。複合ソフトウエアシステムは、２つ又はそれよりも多くの言語、３つ又はそれよりも多くの言語、又は４つ又はそれよりも多くの言語のようなあらゆる数の異なるコンピュータ言語（例えば、ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、Ｃ＋＋、ＰＡＳＣＡＬ、「Ｖｉｓｕａｌ Ｂａｓｉｃ ６」、アセンブリコード、ＸＭＬ、Ｊａｖａｓｃｒｉｐｔ、その他）で書かれたソフトウエアモジュールを含むことができる。複合ソフトウエアシステムのための編集されたコードは、約５０メガバイト又はそれよりも多い、１００メガバイト又はそれよりも多い、３００メガバイト又はそれよりも多い、又は５００メガバイト又はそれよりも多いような、少なくとも約１０メガバイトの総ファイルサイズを有することができる。モジュールは、ＥＲＰシステムを含む特定のビジネス機能、インタフェースソフトウエア、電気通信ソフトウエア、報告ソフトウエア、財務ソフトウエアなどを実行するソフトウエアを含むことができる。例示的なＥＲＰシステムは、ＳＡＰ（ニュートン・スクエア、ペンシルベニア）、「ＪＤ Ｅｄｗａｒｄｓ」（デンバー、コロラド）、Ｍａｎｕｇｉｓｔｉｃｓ（ロックビル、メリーランド）、「Ｓｉｅｂｅｌ Ｓｙｓｔｅｍｓ」（サンマテオ、カリフォルニア）、又は「ＲＯＩ Ｓｙｓｔｅｍｓ」（具体的には、ミネソタ州ミネアポリス所在の「ＲＯＩ Ｓｙｓｔｅｍｓ」の「Ｍａｎａｇｅ ２０００」システム）、並びに特注システムのような供給者によって販売されるものを含む。

本明細書で使用される時の「制御試験レポート」は、正確な又は好ましい結果を含むテストケースの試験レポートのバージョンを意味する。本発明では、回帰試験が実行された時に、このようなテストケースから生じたレポートは、制御試験レポートとして形成された出力と比較される。
本明細書で使用される時の「データマーカ」は、トランザクションの完全な試験で使用するためのボリュームテストデータを作成するために試験オペレータによって定められた規則を用いるコンポーネントを意味する。
本明細書で使用される時の「依存関係」は、イベント又はデータ要件のシーケンスが原因で別のテストケースに先行するテストケースを意味する。

本明細書で使用される時の「設計仕様」は、システムが構築される方法を文書化する仕様を意味する。これは、一般的に、システム又はコンポーネント構造、アルゴリズム、制御論理、データ構造、データセット［ファイル］使用情報、入力／出力フォーマット、インタフェース記述などを含む。
本明細書で使用される時の「差のレポート」は、自動比較処理から作成された出力を意味する。このような差のレポートは、比較処理中に呼び出されたあらゆるフィルタを含む自動試験レポート間の差を列挙する。
本明細書で使用される時の「回帰試験」は、それが試験するコンポーネントを徹底的に用いて、解析された時にコンポーネント又はトランザクションの正しさを検証する出力を生成する繰返し可能な試験を意味する。

本明細書で使用される時の「スクリプト」は、テストケースで実行されるトランザクションのセット、及び実際の結果と比較するための予想される結果のリストのフォーマット化された書かれた説明である。スクリプトは、一般的に各テストケースに関連付けられ、「テストケースカタログメンテナンス形式」（以下に説明する）を通じて表示することができ、又は「テストケースカタログメンテナンス形式」からのリンク又は他の手段からアクセス可能にすることができる。スクリプトで実行するためのトランザクションに対する命令は、どのトランザクションを実行するかを人間オペレータに知らせるために記述的用語で書き込むことができ、又はこの命令は、トランザクションを自動的に実行するためのコンピュータ命令を含むか又はそれにアクセス可能であり、又はコンピュータ実行及び人間実行命令のあらゆる組合せを含むことができる。コンピュータ命令は、「Ｊａｖａ Ｓｃｒｉｐｔ」、「Ｖｉｓｕａｌ Ｂａｓｉｃ」コード、Ｐａｓｃａｌ、Ｆｏｒｔｒａｎ、Ｃ＋＋、及びあらゆる公知のマクロ言語などのようなあらゆる形式とすることができる。一実施形態では、スクリプトは、特定のテストケースのための「テストケースカタログメンテナンス形式」のグラフィカルユーザインタフェースディスプレイからアクセス可能な「Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ」文書又はテキストファイルのようなテキストベースの文書を含むか又はそれから構成される。

本明細書で使用される時の「テンプレート」は、要求された情報を記録するために示唆されたフォーマットを意味する。
本明細書で使用される時の「試験インシデントレポート」は、更なる調査を必要とする試験中に起こるあらゆるイベントを報告する文書を意味する。一部の文献は、代替表現の「偏差形式」を使用する。
本明細書で使用される時の「試験計画」は、意図した試験活動の範囲、手法、リソース、及びスケジュールを特定する文書化を意味する。これは、試験項目、試験される特徴、試験タスク、担当、要求されるリソース、及び臨時の計画を必要とするあらゆる危険性を識別するものである。試験計画は、例えば、本明細書に矛盾しない範囲で本明細書において引用により組み込まれている、２００１年４月１０日にＺｗｅｂｅｎ他に付与された「統合生産量及び在庫計画のためのスケジューリングに対する特定の用途を有する反復的修復最適化」という名称の米国特許第６，２１６，１０９号に説明されているツールを含むプロジェクト計画ツール及びスケジューリングツールの助けによって構成することができる。

本明細書で使用される時の「試験」は、一般的に、特定条件の下で複合ソフトウエアシステムのシステム又はコンポーネントを作動し、結果を観察又は記録し、かつシステム又はコンポーネントの何らかの態様の評価を記録する処理を意味する。このような試験は、協働する複数のコンポーネントの性能の統合試験、又はサブシステム間の協調性を検査するための複合ソフトウエアシステム全体のシステム試験に関連する可能性がある。試験は、ソフトウエア開発又はメンテナンス中に生じた以前に機能していたモジュール又はシステムのエラーを検査するための回帰試験を含むことができる。単に一例として、他の試験タイプは以下のものを含むことができる。
・「統合試験」−（１）システムがその受け入れ基準を満たしているか否かを判断してシステムを受け入れるか否かを顧客が判断することができるようにするために行われる試験。（２）システムがその指定された要件を満たすかを検証するために統合ハードウエア及びソフトウエアシステムを試験する処理。
・「負荷試験」−負荷試験もまた、作業負荷が高くてリソースが低いと考えられる場合にシステムストレス中のシステム性能を調べるために行うことができる。負荷試験（ストレス試験と呼ばれることもある）は、本発明の範囲に入ると考えることができる。様々なモジュールの機能を試験する間に、スクリプトを供給して高負荷を模擬するためにシステムの多くの特徴を実行することができる。例えば、自動化ツールは、多数の仮想ユーザを作成し、大量の問合せ及び多数のトランザクションセットなどを作成することができる。
・「ユニット試験」−（１）植字上、構文上、及び論理上のエラー、その設計の正しい実施、及びその要件の充足に関するモジュールの試験。（２）１つのソフトウエア要素に対して設計の実施を検証するために行われる試験。

本明細書で使用される時の「テストケース」は、規定された出力のセットを作成するコンポーネント又はトランザクションに対する規定された入力のセットを意味する。一般的に、テストケースは、入力を規定する文書化、予想される結果、及び試験項目の実行条件のセットを含む。テストケースは、１つ又はそれよりも多くのソフトウエアモジュールを収容する１つ又はそれよりも多くのトランザクションの所定の集合として見ることができる。これは、複合ソフトウエアシステムの実際の使用を模擬するために、テストケーススクリプトで規定された所定の順序で実行される一連のトランザクションを収容することができる。実行される各トランザクションは、より大きなテストケース（親ケース）内のアクションのより複雑なシーケンスを表すために互いに一続きにすることができる個々のテストケースによって表示することができる。多くの実施形態では、テストケースが実行される場合、検出されたエラーは、ソフトウエア内又は相互に関連するシステム内の調べられているあらゆるコンポーネント内で修復を必要とする区域を指している。

本明細書で使用される時の「試験レポート」は、テストケースの実行から作成された出力を意味する。
本明細書で使用される時の「テストケース特性」は、テストケースの開発及びユニット試験を支援するために使用されるテストケースに関する情報（データ及びリソース割当てのような）を意味する。この特性は、テストケースのカタログのコンポーネントを構築することを支援するための第１レベル計画として見ることができる。
本明細書で使用される時の「追跡可能性」は、開発処理の２つ又はそれよりも多くの製品、特に、互いに前任者−後継者又は主人−家来関係を有する製品間に確立することができる関係の程度、例えば、所定のソフトウエアコンポーネントの要件及び設計が適合する程度を意味する。（多くの従来技術の文献では、「追跡可能性」は、ソフトウエアモジュールの機能をソフトウエアによって満たされる目的又は要件にトレースすることを意味し、言い換えると、ソフトウエアの存在に対する理由を確立するという別の意味で使用されることが多いことに注意されたい。）

本明細書で使用される時の「トランザクション」は、特定のタスク又は機能、一般的に単一ソフトウエアモジュールのようなソフトウエアのユニットによって実行されるビジネスアクションを行うための基本的な実行可能ブロックである。一般的には、トランザクションは、より大きなビジネス処理内の段階である。
本明細書で使用される時の「従属関係」は、イベント又はデータ要件のシーケンスが原因でテストケースに続くテストケースを意味する。従って、従属関係は、依存関係の逆として考えることができる。言い換えると、第１ケースが第２ケースに対する依存関係であり、第１ケースが第２ケースに先行することを意味する場合、第２ケースは、第１ケースに対する従属関係である。

本明細書で使用される時の「作業ストリーム」は、ビジネス処理のサブ処理である。例えば、１つのＥＲＰシステムでは、「在庫管理（ＩＭ）」は、購入される材料及びサービスに対する必要性を識別し、次に、可能な最も効率的な方法でそれらの材料を調達し、受け取り、配備し、供給元に支払うビジネス処理「支払い請求（ＲＴＣ）」のサブ処理である。ＲＴＣ内の「作業ストリーム」は、例えば、「調達」、「在庫管理」、及び「買掛金」を含むことができる。

特に本発明の範囲内で開発されたＳＡＰシステムの関連では、以下のようないくつかの付加的な頭字語及び用語を用いることができる。
・ＢＣＤ（ビジネス構成設計）−ビジネス処理に固有の独特な構成を捕捉するために使用される設計仕様文書。標準的な構成が変更又はカスタマイズされる場合、ＢＣＤ入力が必要である。これは、標準的なＳＡＰトランザクションのための設計青写真が維持されることを保証する。
・ＢＰＤ（ビジネス処理設計）−ビジネス処理のユーザ要件を捕捉するための文書。この文書は、ハイレベル機能の必要性、ビジネス処理コメント、最良実施例、及びシステムの意図された使用の全体的結論を含む。
・ＢＰＦ（ビジネス処理フロー）−ＢＰＤで説明されるビジネス処理の図解又はフロー。
・ＢＰＰ（ビジネス処理手順）−ＳＡＰ又は他の複合ソフトウエアシステムのトランザクションの要件に対する機能的な仕様である。使用されるトランザクションの機能を識別し、トランザクションの流れ、各フィールドの定義、それが必要なのか、任意的なのかなど、及び一般的なコメントを段階毎に含む。
・「ビジネス処理」−ビジネス処理は、機能的なビジネスエリア（「ビジネス処理チーム」と呼ばれる）によって組織されたサブ処理のエンド・ツー・エンドの論理的分類である。
・ＣＳＶ（コンピュータシステム検証）−コンピュータシステム仕様がユーザの必要性及び意図された使用に合っていること、及び全ての要件を一貫して満たすことができることの検査及び客観的証拠の提供による確認。
・電子署名−個人の手書き署名の認可された均等物として個人によって実行され、使用され、又は認可されたあらゆる記号又は一連の記号のコンピュータデータ編集。
・ＦＲＩＣＥ（形式レポートインタフェース変換拡張）−ＳＡＰのような複合ソフトウエアシステムへのカスタム拡張（すなわち、社内で開発されたモジュール）の機能及び設計仕様の両方を捕捉する文書のセットから構成される。
・「追跡可能性行列レポート」（「ＣＳＶファクトブック」によって要求されるような）−２つ又はそれよりも多くの製品間の関係を記録する行列、例えば、所定のソフトウエアコンポーネントの要件及び設計間の関係を記録する行列。
・「検証ファクトブック」−アプリケーションがその意図された使用を満たすことを明らかにする「ソフトウエア開発ライフサイクル」から保持された記録の編集。
本発明は、本発明の以下の詳細説明、及び同じ数字が同じ要素を表す添付図面を参照することによってより十分に理解され、更に別の利点が明らかになるであろう。図面は、単に代表的なものであり、特許請求の範囲を制限するものではない。

本発明の開示は、本発明の「実施形態」という用語又は他の類似の用語によって個々に又はまとめて参照される場合もある様々なコンポーネント、要素、構造、構成、配置、及び他の特徴を用いて表されることになる。開示される本発明の様々な形態がその様々な特徴及び実施形態の１つ又はそれよりも多くを組み込むことができること、及びこのような特徴及び実施形態がそのあらゆる望ましい作動的な組合せで用いることができることが考えられている。
本開示で用いられる場合、用語「含む」、「含んでいる」、及びその基本用語「含む」からの他の派生語は、あらゆる説明された特徴、要素、完全体、段階、又はコンポーネントの存在を特定する非限定的用語であることが意図されており、１つ又はそれよりも多くの他の特徴、要素、完全体、段階、コンポーネント、又はその群の存在又は追加を排除しないものとすることにも注意すべきである。

本発明は、修正された後の複合ソフトウエアシステムを試験するためのテストケースの効率的な組合せを選択する方法に関する問題を解決することに関する。更に、本発明は、モジュール、テストケース、支持する試料、ビジネス文書、プロジェクトに関する文書、及びテスターと試験スケジュールのような統合ソフトウエアシステムの様々なコンポーネント間の関係を自動的に追跡する問題を解決する。更に、本発明は、複合ソフトウエアシステムの開発に対する改良又は複合ソフトウエアシステムの改良を監督して導くための改良型コンピュータツール及び自動化ツールを提供する問題を解決する。

本発明の自動ツールは、通常は所定の作動が予想される結果を生じること、及び修正されたコンポーネントに関係したコンポーネントがこれに応じて適切に検討されるか又は修正されることを保証するために、複合ソフトウエアシステムのコンポーネントの作動を試験するために設計された一組のテストケースと共に使用される。複合ソフトウエアシステムの試験は、一般的に、複合ソフトウエアシステムの実際の出力と比較される既知の予想される結果を有する所定のテストケースを実行することによって行われる。テストケースは、１つ又はそれよりも多くのソフトウエアモジュールを収容する１つ又はそれよりも多くのトランザクションを含み、また、複合ソフトウエアシステムの実際の使用を模擬するためにテストケーススクリプトで規定された所定の順序で実行される一連のトランザクションを収容することができる。実行される各トランザクションは、より大きなテストケース（親ケース）内のアクションのより複雑なシーケンスを表すために共にまとめられる個々のテストケースによって表すことができる。例えば、購入システムを試験することに向けられたテストケースは、トランザクションとして以下の段階を含むことができる。
・供給業者データベースの新しい供給業者の新しい記録の作成、
・新しい供給業者によって提供された標準製品の新しい記録の作成、
・新しい供給業者の製品の購入要求の作成、
・製品の購入に関係する税情報の作成、及び
・新しい供給業者への購入注文の発行。
これらの段階の一部は、付加的な供給元から付加的な作動又は要求入力を呼び出すことができる。上述の段階のいずれか又は全ては、自動的に実行された段階の予想される結果が、テストケースの実際の結果が比較されるテストケースの予想される出力である場合、開始要求に応じて自動的に起こるように設計することができる。

複数の統合ソフトウエアモジュール及び一般的に２つ又はそれよりも多くの供給元からのソフトウエアモジュールが共に作動することができるようにするための複数のインタフェースを含む複合ソフトウエアシステムでは、１つ又はそれよりも多くのモジュールが変更された後のソフトウエアの試験は、多数のテストケース（例えば、数千）の実行を要求することができる。各テストケースは、特定の機能を試験するために、１つ又はそれよりも多くのソフトウエアモジュールを実行する。テストケースのスクリプトは、実行されるトランザクション、要求される入力、及び作成を予想される結果を定める文書である。実際の結果は、次に、複合ソフトウエアシステムの試験された部分が適切に作動していることを保証するために、予想される結果と比較される。ソフトウエアモジュールが修正又は開発される場合、本発明のツールによってどの他のテストケースが修正によって影響を受けるかを示すリストが作成され、従って、再実行が必要なのはどの付加的なテストケースかを示している。

自動ツールの核心は、このような複合ソフトウエアシステムの全てのコンポーネント間の関係を説明する「自動多次元追跡可能性行列」の概念である。「自動多次元追跡可能性行列」は、複合ソフトウエアシステムのソフトウエアコンポーネントと任意的な他のコンポーネントの間のリンケージのコンピュータベースの表示である。一実施形態では、「自動多次元追跡可能性行列」の関係情報は、テストケースに対して入力された依存関係及び従属関係情報から専ら又は主として得られる。関連の実施形態では、「追跡可能性行列」はまた、テストケースを実施する時に実行されるトランザクションでアクセスされる個々のソフトウエアコンポーネントに関する情報を含むことができ、それによって「追跡可能性行列」は、テストケース間の又はソフトウエアモジュールとテストケースの間の関係を判断するために使用することができる。別の実施形態では、「自動多次元追跡可能性行列」は、テストケース間並びに複合ソフトウエアシステムの個々のコンポーネント間の関係に関する情報を含み、「追跡可能性行列」は、それによってソフトウエアモジュールとテストケースとの間、又はテストケースとの間、又は個々のソフトウエアモジュールとの間の関係を判断するために使用することができる。

一実施形態では、「自動多次元追跡可能性行列」は、電子カタログでテストケース（及び関連の文書）を管理するための単一のソースを供給し、また、テストケース依存関係の相互関係を示すための解析ツールとして機能する。更に、「自動多次元追跡可能性行列」は、インパクト解析及び生産サポートを支援する共通の観点から複合ソフトウエアシステムを複数のユーザが理解することができるようにするために使用される。

他の実施形態では、「自動多次元追跡可能性行列」はまた、以下の付加的な目的のいずれか又は全てを達成するために使用することができる。
・詳細なレベルでテストケースの実行を管理して計画するために作業ストリームのツールを提供し、同時に作業間ストリームプロジェクト作業計画をサポートする。
・全ての作業ストリームにわたって試験サイクルの進行を測定するための一貫したツールを提供する。
・再使用可能な試験情報を維持する。
・サポーティングビジネス及び技術文書を容易にアクセス可能にする。
・要求される「検証ファクトブック」報告（例えば、「検証ファクトブック」要件を満たすための「追跡可能性行列レポート」をサポートするために使用される）を満たすためにＣＳＶ関連情報を捕捉する。
・検討又は変更を必要とする関連のビジネス要件文書を提供することによって変更管理処理をサポートする。

テストケースは、「追跡可能性行列」の少なくとも一部を定める情報を提供する「テストケースカタログ」を使用して組織される。「追跡可能性行列」がテストケース間の関係だけを定めるものとする時に、「テストケースカタログ」の関係情報は、実質的に「追跡可能性行列」を定めるが、付加的な関係情報が同様に含まれる（例えば、個々のコンポーネントに関する関係）。「テストケースカタログリスト」は、全テストケース又はテストケースの選択された部分集合を表示するグラフィカルユーザインタフェースで提供される。テストケースは、リスト、クラスター、一連の名前の付いたアイコン、又は他のフォーマットとして表示される。リストが表示される場合、リストは、テストケースの名前又はテストケース記述子のアルファベット順に従って表示されるか、又はリスティングは、修正の日付、関連のプロジェクト、部門、所有者又はテストケースを修正した最後の個人の識別などのようなテストケースに関した他のフィールドに従って順序付けられる。「テストケースカタログリスト」の表示は、ワードプロセッサ又はスプレッドシートからの表示を含む「ウェブ」ページ又は他の電子フォーマット上に表示される。「テストケースカタログリスト」は、あらゆる選択されたケースに関連した詳細な情報への迅速なリンク又はその表示を提供するのが好ましい。例えば、「テストケースカタログリスト」のテストケースに関連したテストケースの名前又は他の表示を一回クリックすると、選択されたテストケースの詳細な情報が新しいウィンドウ又は「テストケースカタログリスト」を前に保持していた同じウィンドウに表示される。一実施形態では、テストケースの詳細な情報は、「テストケースカタログリスト」の既存の表示に挿入される。

「自動多次元追跡可能性行列」は、テストケースとソフトウエアコンポーネント又はトランザクション、及び任意的に文書のような関連のコンポーネントのステータスのような複合ソフトウエアシステムの様々なコンポーネント間の関係に関する結合した情報である。「自動多次元追跡可能性行列」は、例えば、システムが適切に作動していることを保証するために複合ソフトウエアシステムの１つ又はそれよりも多くのコンポーネントの変更に応じてどのテストケースを実施しなければならないかを判断するために、自動的にアクセスされる方法でコンポーネントの関係を説明するコンピュータ可読媒体上のツールである。「自動多次元追跡可能性行列」を定める結合された関係情報は、特に、以下に説明する「テストケースカタログメンテナンス形式」を使用してテストケースの各々に対して入力される各テストケース又はソフトウエアモジュールに関する従属関係及び依存関係情報を含む。「自動多次元追跡可能性行列」は、複合ソフトウエアシステムのテストケースと他のコンポーネントの間の関係のデータベースとして記憶されるか、又は関連する各ソフトウエアモジュール又は他のコンポーネントに関する従属関係及び依存関係が、モジュールの１つ又はそれよりも多くにおける変更に対して影響を受けたコンポーネントの自動リスティングをサポートするように定義されるという条件で、あらゆる他の電子形式でこのような情報を含むことができる。

テストケースに関する情報は、必要な場合にテストケースに関する情報を受信し、次に「自動多次元追跡可能性行列」を更新するためにこの情報を使用するために「ウェブ」ベースの形式又は他の電子文書とすることができる「テストケースカタログメンテナンス形式」で入力することができる。「テストケースメンテナンス形式」は、あらゆる単一のテストケースに関する情報を受信して表示するための手段を提供する。一実施形態では、「テストケースカタログメンテナンス形式」は、以下のようなフィールドを含むことができる。
・テストケース記述子（タイトル、ＩＤナンバー、短い説明、目的、コメント、複合のレベルのインジケータなど）、
・テストケースのためのトランザクション−テストケースが実行される場合に呼び出される一連のイベントの説明、
・従属関係リスト−所定のテストケースに続くテストケースのリスト、
・依存関係リスト−所定のテストケースに先行するテストケースのリスト、及び
・テストケース配信可能なもの−テストケースの実行をサポートするビジネス要件文書のリスト。

従属関係及び依存関係が追跡される方法の簡単な例として、仮説ＥＲＰシステムからの５つのテストケースの部分集合が、「自動多次元追跡可能性行列」での依存関係及び従属関係テストケースデータの入力の関連で調べられる。
図１Ａは、アイデンティティフィールド１１１、１２１、１３１、１４１、及び１５１のそれぞれにテストケースアイデンティティＺ−ＺＺ−９９９−０１からＺ−ＺＺ−９９９−０５を有するテストケースのセット（それぞれ１１０、１２０、１３０、１４０、及び１５０）に関係した情報を提供する「自動多次元追跡可能性行列」の記録１００の図式的な表示である。テストケースは、様々なトランザクション、すなわち、共にビジネス処理を表すことができる（１）「マスターデータ設定」１１２、（２）「直接調達」１２２、（３）「間接調達」１３２、（４）「受け取り」１４２、及び（５）「請求」１５２を示している。各テストケースは、固有の目的を有するが、それらを適切に試験するために実行の順序を設定すべきである。図１Ａで示すように、テストケースは、最初に依存関係フィールド（１１３、１２３、１３３、１４３、及び１５３）又は従属関係フィールド（１１４、１２４、１３４、１４４、及び１５４）のそれぞれの依存関係又は従属関係を持たないように切り離される、言い換えると、それらの間にシーケンスが設定されていない５つの個々のテストケースが存在する。各テストケースは、ケースアイデンティティ（それぞれ１１１、１２１、１３１、１４１、及び１５１）、タイトル（１１２、１２２、１３２、１４２、及び１５２）、いずれかの他のテストケースからの依存関係がない場合は単に「開始」又はその均等物とすることができる依存関係フィールド（１１３、１２３、１３３、１４３、及び１５３）、及び他のケースがそれに対して従属関係でない場合は単に「終了」又はその均等物とすることができる従属関係フィールド（１１４、１２４、１３４、１４４、及び１５４）を示すボックスで表示される。これは、各記録がいずれかの依存関係又は従属関係が設定される前に「自動多次元追跡可能性行列」に現れる方法である。全テストケースシーケンスは、定められた開始及び終了を持たなければならず、テストケースシーケンスがＥＲＰのためのものなので、理論的には全テストケースが１つのシーケンスに関連付けられると予想される。

実際には、あらゆる従属関係と対応する依存関係の間に示す関係は、従属関係又は依存関係、又は両方の組合せに関連したフィールドにデータを入力することによって設定される。例えば、「マスターデータ設定」１１０（ケースＺ−ＺＺ−９９９−０１）とその２つの後継者ケース、すなわち、ケースＺ−ＺＺ−９９９−０２（１２０）とケースＺ−ＺＺ−９９９−０３（１３０）の間の関係は、「直接調達」（ケースＺ−ＺＺ−９９９−０２）（１２０）と「間接調達」（ケースＺ−ＺＺ−９９９−０３）（１３０）の両方が「マスターデータ設定」（ケースＺ−ＺＺ−９９９−０１）（１１０）に従わなければならないことを通知し、次に、後継者ケース、すなわち、ケースＺ−ＺＺ−９９９−０２（１２０）及びＺ−ＺＺ−９９９−０３（１３０）のための記録の依存関係フィールド１２３及び１３３に「Ｚ−ＺＺ−９９９−０１」（又は、そのケースを示すコード）を入力することによって設定されたことになる。代替的に、「マスターデータ設定」１１０（ケースＺ−ＺＺ−９９９−０１）を考えるオペレータは、「直接調達」１２０又は「間接調達」１３０のいずれかが「マスターデータ設定」に関連したデータによって必要とされるものに従って続くことができることを通知することができる。従って、オペレータは、次に「マスターデータ設定」の従属関係フィールド１１４に入力を行うことができ、「マスターデータ設定」が従属関係としてテストケースＺ−ＺＺ−９９９−０２及びケースＺ−ＺＺ−９９９−０３の両方を有することを示す情報を入力する。後者の２つのテストケースの依存関係フィールドは、次に自動的に更新されて、それらがケースＺ−ＺＺ−９９９−０１に共に依存していることを示している。

図１Ｂは、「マスターデータ設定」１１０（Ｚ−ＺＺ−９９９−０１）のテストケースが「直接調達」１２０（Ｚ−ＺＺ−９９９−０２）及び「間接調達」１３０（Ｚ−ＺＺ−９９９−０２）に先行すべきであることを示す入力に応じて（上述の「作業ストリーム」定義を参照されたい）、及び「請求」１５０（Ｚ−ＺＺ−９９９−０５）のテストケースが「受け取り」１４０（Ｚ−ＺＺ−９９９−０４）後に実行されるということを示す入力されたデータに応じて、図１Ａからの「自動多次元追跡可能性行列」の記録１００が変更される方法を示している。線及び矢印は、「自動多次元追跡可能性行列」の記録１００の依存関係フィールド（１１３、１２３、１３３、１４３、及び１５３）と従属関係フィールド（１１４、１２４、１３４、１４４、及び１５４）の記録によって設定される関係を視覚的に示すための流れ図の技術の一般的な方式で描かれている。従って、テストケースＺ−ＺＺ−９９９−０１（１１０）からの２つの依存関係の追加は、依存関係を示す矢印によってケースＺ−ＺＺ−９９９−０２（１２）及びＺ−ＺＺ−９９９−０３（１３０）をケースＺ−ＺＺ−９９９−０１（１１０）に繋ぐ線１６０の追加で示している。Ｚ−ＺＺ−９９９−０２（１２０）及びＺ−ＺＺ−９９９−０３（１３０）の両方のための依存関係フィールド１２３及び１３３は、それらが依存するケースとしてケースＺ−ＺＺ−９９９−０１（１１０）を列挙している。ケースＺ−ＺＺ−９９９−０１（１１０）のための従属関係フィールド１１４は、このケースが従属関係としてケースＺ−ＺＺ−９９９−０２（１２０）とＺ−ＺＺ−９９９−０３（１３０）とを有することを示している。図１Ｂは、ケースＺ−ＺＺ−９９９−０４（１４０）とケースＺ−ＺＺ−９９９−０５（１５０）との間の新しい関係を表す線１６４を示しており、ここで、後者は、前者に対して従属関係にある。ケースＺ−ＺＺ−９９９−０４（１４０）の従属関係フィールド１４４は、ケースＺ−ＺＺ−９９９−０５（１５０）を列挙しており、ケースＺ−ＺＺ−９９９−０５（１５０）の依存関係フィールド１５３は、ケースＺ−ＺＺ−９９９−０４（１４０）を列挙している。「自動多次元追跡可能性行列」の記録１００へのデータ入力のこの段階では、テストケース１６６及び１６８の２つの別々のストリングが存在する。

本発明の追跡可能性行列ソフトウエアは、常に逆の関係を構築することによって依存関係と従属関係の間の整合性を維持している。従って、依存関係又は従属関係のいずれかの全てのエントリに対して元のエントリをミラーリングする第２の関係が構築される。第２のテストケースの依存関係フィールドに第１のテストケースの番号を入力することで、第２テストケース番号の第１テストケースの従属関係フィールドへの自動入力がもたらされる。この特徴は、従属関係及び依存関係データの内部の一貫性を提供し、整合性が「自動多次元追跡可能性行列」の相互に関連するテストケースデータで維持されることを保証する。

図１Ｃは、第１テストケース１１０（Ｚ−ＺＺ−９９９−０１）から最終テストケース１５０（Ｚ−ＺＺ−９９９−０５）への整合性のチェーンの完成を示し、これは、ここではテストケースＺ−ＺＺ−９９９−０４（１４０）をその従属関係フィールド１２４及び１３４にそれぞれ列挙しているテストケースＺ−ＺＺ−９９９−０２（１２０）及びＺ−ＺＺ−９９９−０３（１３０）に対して従属関係にあるとしてのテストケースＺ−ＺＺ−９９９−０４（１４０）と間の線１６２で示す関係の確立によって図１Ｂとは異なっている。

「自動多次元追跡可能性行列」ソフトウエアツールは、一般的に複数の関連したコンポーネントを含む。１つのコンポーネントは、テストケースに関する情報を見るためのグラフィカルユーザインタフェースを提供する「テストケースカタログ」とすることができる。「テストケース計画」ツールもまた、「自動多次元追跡可能性行列」ソフトウエアツールに組み込むことができる。トランザクション／プログラム追跡可能性を提供する「ＣＳＶ管理」は、「自動多次元追跡可能性行列」ソフトウエアツールに直接組み込むことのできる別の特徴である。テストケース間の関係の視覚的な表示を提供するための「解析ロードマップ」（以下に説明する）は、「自動多次元追跡可能性行列」ソフトウエアツールに組み込まれる別の要素である。これらのコンポーネントは、以下で更に詳しく説明され、そこでは、本発明の実施形態からのスクリーンショットに対して「ＳＡＰ Ｒ／３」を含む複合ソフトウエアシステムの試験のためのカスタマイズされたツールの関連で説明されるが、類似のツールを多数の複合ソフトウエアシステムに対して適用することができることを理解すべきである。カスタマイズされたツールは、「全てのリソース及び統合システムを利用する処理最適化」を表す「ＰＯＬＡＲＩＳ」ツールと以下で呼ばれる。

図２は、品質を保証するために試験する必要がある機能をアドレス指定する全テストケース１７６の包括的なリストである「テストケースカタログリスト」１７４を特徴とする対話式ページ１７２を示す自動ツールの一実施形態（ＰＯＬＡＲＩＳ）の「イントラネット」ページのスクリーンショット１７０である。ケースは、図のようにケース番号１７８によって列挙されている。図示の実施形態では、カテゴリフィールド１８０も表示され、ケース記述１８２も示されている。画面の左側のリンク１８４は、新しいケースを作成する機能又は既存のケースに新しい特徴又はトランザクションを追加することができる機能へのアクセスを提供するか、又は使用可能なトランザクションのリストを提供する。テキストボックスは、特定のケース又は特徴への迅速なアクセスを提供する。

テストケースの部分集合１８６及び１８８は、必要な場合に表示することができる。例えば、ドロップダウンボックス１９０により、オペレータは、テストケースに関連した作業ストリームに従って表示されたケースにフィルタを掛けることができる。フィルタは、全てのケースを再度表示させるために解除することができる。
テストケースは、一般的にプロジェクトの開発段階中に定義されて作成され、設計によって規定される機能性を反映すべきである。一般的に、テストケースは、その機能がビジネスによって除かれた場合にのみカタログから取り除かれることになる。

図３は、「ＰＯＬＡＲＩＳ」ツールでの「テストケースカタログメンテナンス形式」１９２のスクリーンショット１７０を示している。テストケースのためのカタログフィールドは、ケース番号のフィールド１７８、試験スクリプトのファイルネーム１９６、複雑性１９８（ケースがどのくらい複雑であるかを示すレベル）、ケースの記述２００、ケースの目的２０２、コメント２０４などを含む「ケースカタログ」１９４というレベルの付いたテーブル領域内で定義される。「隔離レベル」フィールド２０６は、複合ソフトウエアシステムのどの態様がテストケースの実行中にアクセス可能であるかに関する情報を提供する。例えば、入力された値は、全ＳＡＰトランザクションが使用可能であること、又はカスタマイズされた「会社」機能が使用可能であること、又は規制が課せられていないことを示すことができる。

ケース依存関係及び従属関係の情報は、「ケース依存関係」２０８又は「ケース従属関係」２１０それぞれをオペレータがクリックした時に現れるテーブル（今は隠れている）で提供される。トランザクションコード２１２と配信可能リファレンス２１４のテーブルも、今は表示されていないが提供される。配信可能リファレンス２１４は、テストケースが接続されるビジネス処理に関する情報を含むことができる。例えば、フィールドは、前に定められたようなＢＰＰ、ＢＰＤ、ＢＰＦ、又はＢＣＤのいずれかを識別する固有に割り当てられた配信可能コードを含むことができる。

図示された例でのテストケース複雑性フィールド１９８は、以下の定義に基づいてＨ（高）、Ｍ（中）、及びＬ（低）から選択された値を有することができる。
（Ｈ）高＝複合ビジネス処理や複合のカスタマイズされたプログラム（例えば、ＦＲＩＣＥ）のために難度が高いと考えられ、実行するのに必要な一連のトランザクションが５つ又はそれよりも多く、又は適正に試験するのに必要な試験データ変形の数が１０よりも多い。
（Ｍ）中＝難度が平均であると考えられるか又は処理が公知であり、実行するトランザクションが５よりも多く、適切に試験するためのデータの試験変形が１０よりも少ない。
（Ｌ）低＝処理が簡単明瞭で公知であり、実行するトランザクションが１から２であり、３つ又はそれよりも少ない試験変形が適切に試験されることになる。

「テストケースカタログメンテナンス形式」１９２は、この場合のように、テストケースに関して必要とされるあらゆる情報を提供するようになっている。スクリプトを実行する方法の詳細又はスクリプトに関係した他の情報に対して実際のテストケーススクリプトを開くために、試験スクリプトファイルネームフィールドの隣に「ＧＯ」ボタンがある。「配信可能リファレンス」エリア２１４の下のフィールド（図示せず）は、このテストケースをサポートするビジネス要件文書を表示するために「ＧＯ」ボタンを有し、トランザクションコードエリア（図示せず）の各トランザクションのそばに「ＧＯ」ボタンがあり、これは、トランザクション／プログラム周辺の詳細な情報まで誘導する。（代替的に、フィールドに関連したボタンがクリックされた時に起こるアクションを一意的に識別するために、「ＧＯ」ボタンの単一の様式の代わりに、固有のアイコン又は識別子を使用することができる。）
テストケース番号１７８の隣の流れ図アイコン２１８は、以下に説明する関連のテストケースの「解析ロードマップ」を作成するためにクリックされる。

図４は、「テストケース特性リスト」２２２のスクリーンショットである。「自動多次元追跡可能性行列」ソフトウエアツールのこの部分は、テストケース１７８のサポート計画を支援することができる。このツールによってサポートされるテストケース計画には多くの場合に２つの主な目的がある。
１．開発又は拡張のために試験計画を調整する場合に対するリソースと時間を管理するために、作業ストリームの詳細なテストケースレベルタスクを提供すること。
２．ステータスに対して終了した作業のテストケースレベルの詳細を提供すること。

「テストケース特性リスト」２２２は、試験の現在の範囲に対してサイクル番号２３０を割り当てられた全試験サイクルの完全なリスト、及び使用可能なテストケース１７８を提供する。終了した状態での特定のサイクルは、ツール管理者の指示で保存されるか又は削除される。サイクルは、様々な目的のために（例えば、ＡＰの新しいバージョンを実行するため、新しいプロジェクトの結果を試験するため、他のソフトウエア又はハードウエアシステムでの更新を処理するためなど）実行されるテストケースの特定の反復又は群を示している。様々な目的のための試験のサイクルは、時間の計画された期間に対応することができ、また特定の試験環境又はテスターの群を示すことができる。また、テストケース１７８の記述１８２も表示される。論理削除インジケータ２３２は、テストケースの物理的な削除なしにサイクルからテストケースを取り除くための任意選択肢（「Ｙ」に設定した場合）を提供する。これは、例えば、テストケースが古くなったか又は他の理由のために使用してはならない場合に望ましい。

フィルタリング領域２２４は、特定のサイクル、作業ストリーム、及び論理的に削除されたテストケースを分離するために使用可能なフィルタ任意選択肢を提供する。使用される選択基準の組合せに応じて、適切な検査ボックスをクリックすべきである。
ここでもまた、テストケース番号１７８は、その特性の特定の詳細に進むためのジャンプ機能として作用する。また、特定のサイクル及びケースが分っていて適切な領域２２６及び１８８に入力される場合、テストケース特性への直接アクセスが可能である。

図５は、テストケース特性２３８に情報を提供する「ケース特性メンテナンス形式」２３６のスクリーンショット１７０を示している。この画面上のフィールドは、テストケース１７８の詳しい構築及び実行を計画し、割当て及び推定を行うために使用される。管理者は、全体的なプロジェクトの進行を測るために完了インジケータを使用することができる。
テストケースネームの隣の「ＧＯ」ボタンは、試験カタログ情報に直接ジャンプすることができる。テストケース番号フィールドの左側の解析アイコンは、「解析ロードマップ」（以下に説明する）を作成する。
日付フィールドの隣の「…」ボタンは、左ボタンをクリックした時に選択日付のためのポップアップカレンダーを示すものである。
「テストケース特性」画面１７２上の全情報は、プロジェクトスケジュールのベースライン値（試験アクションの計画に関係した情報）を除いて作業ストリームによって修正可能である。これらのフィールドは表示されるが、これらのフィールドへの入力は阻止される。ツール管理者は、これらのフィールド全体で制御を維持する。

図６は、「トランザクションメンテナンス形式」２４０のスクリーンショット１７０を示し、複合ソフトウエアシステムの特定のトランザクション２４２又はソフトウエアモジュールに関する情報を提供する。各トランザクションは、トランザクションコード２４４、トランザクションタイプ２４８（例えば、ＳＡＰ、カスタムなど）、組織の所有者などを割り当てられる。トランザクションジャンプフィールド２５０により、ユーザは、トランザクションコードを入力することによって他のトランザクションに迅速にナビゲートすることができる。トランザクション記述２４６及び他の情報は、スクリーンショット１７２に示すグラフィカルユーザインタフェースに提供される。ＣＳＶ位置調整のためのフィールド２５４も提供される。ＣＳＶ関連性は、トランザクション／プログラムレベルで管理されることになる。トランザクション／プログラム（供給業者又はカスタム開発された）がテストケースで使用される場合、トランザクションは、「自動多次元追跡可能性行列」に捕捉されることになる。この時点で、「トランザクションメンテナンス形式」のＣＳＶ及び電子署名インジケータは、一般的に左が空白になる。管理者は、関連性に関してトランザクション又はプログラム毎に管理し、ＣＳＶインジケータ２５２を適切に設定し、その判断の理由を提供することができる。
一般的に、管理者は、この画面への全ての更新を処理することができるが、情報は、「自動多次元追跡可能性行列」ツールの全ユーザによる表示のために使用可能にすることができる。

「割り当てられたケース」２５６（図示せず）のドロップダウン情報は、このようなトランザクションを用いる全テストケースを列挙することができる。この付加的な情報は、「割り当てられたケース」情報２５６が拡張又は開かれた後のスクリーンショットの下の部分を示す図７に表示される。各「ＧＯ」ボタンは、テストケースの詳細に対してそのテストケースにジャンプする。各「解析」アイコンは、開始ポイントとしてそのテストケースから「解析ロードマップ」を作成する。
従って、「自動多次元追跡可能性行列」は、トランザクション又はソフトウエアモジュールに関連した全テストケース１７８を自動的に判断するための手段を提供し、トランザクションに関する表示された情報から各テストケースの詳細にアクセスするための手段を提供する。複数のレベルにわたってソフトウエアモジュールとテストケースの間の関係を追跡することで、変更の影響（ソフトウエアモジュールの変更によって影響を受けるケースの範囲）を評価することができる。

図８は、図１のテストケース番号１７８の左側の解析アイコン２１８をオペレータがクリックした時に表示されるダイアログボックス２６２を示す図３の「テストケースカタログメンテナンス形式」１９２に関連したスクリーンショット１７０である。ダイアログボックスは、オペレータにサイクルの選択を指示する。この選択は、作業ストリームによって開発されたスケジュールにテストケースを重ねるものである。サイクル情報を選択した後で、「解析ロードマップ」は、図９に示すように表示される。

図９は、「解析ロードマップ」２６６のスクリーンショット１７０を示しており、現在選択されている反転表示されたテキストケース２６８のテストケース間の内部関係の視覚的な表示である。その目的は、テストケースの依存関係及び従属関係を通じて一段上及び一段下の関係を取り、処理のマップを作ることである。多くの複合ソフトウエアシステムのテストケース及び内部関係の個数が原因で、理解を支援するために解析ロードマップを部分集合させるための技術が使用された。使用された技術は、開始ポイントとしていずれかの所定のテストケースを取り、依存関係では１レベル上を読み、従属関係を通じて５レベル下を読む。（必要に応じて、例えば、レベルアップのための０から２５までのいずれかの整数及びレベルダウンのための２から２５のいずれかの整数のようなレベルアップ及びダウンのための数のあらゆる他の組合せも使用することができる。）１レベルアップ及び５レベルダウンの使用は、７レベルの内部関係を示す表示を作成する。表示されたものに先行する付加的な情報を必要とする場合、最も高いレベルが選択され、テストケースのチェーンを上に進むために再解析される。現在のロードマップを超えた付加的な情報を必要とする場合、更に別の解析のためのエリアを表すチェーンの下のテストケースが選択される。
「解析ロードマップ」２６６の表示画面に関連したグラフィカルユーザインタフェースでは、テストケースが選択され、それに関連した上流及び下流のテストケースが自動的に表示される。２つの上流レベル及び３、４、５、６、７、又は８つの下流レベルを示すような関連のケースを表示するための他の規則が履行される。

図９の「解析ロードマップ」では、使用される当業技術で公知の多くの他のグラフィカルシステム（例えば、ブランチ及びツリーダイアグラム、スポーク及びハブダイアグラム、リンクしたバブルダイアグラムなど）を通じて多くのコンピュータユーザに馴染みがあるために、フォルダ表示技術が使用される。フォルダテーマにより、必要な場合にアイコン又はテキストの行をクリックすることによって詳細を容易に拡張するか又は壊すことができる。一実施形態では、プラス記号を左ボタンでクリックすることによって詳細が下に拡張されるプラス手段を有するフォルダがある。詳細が表示されてマイナス記号がフォルダに付いている場合、詳細は、マイナス記号を左ボタンでクリックすることによって壊される。これは、詳細のカスタム化を各ユーザが見ることができるようにするものである。
テストケースの隣の文書アイコン２８６は、この下に従属関係テストケースが存在しないことを示している。言い換えると、これは、そのストリングの最後である。テストケースの隣の下向き矢印アイコン２８８は、ケースのシーケンスに更に別の詳細があることを示しているが、その下のテストケースを見るために開始ポイントとしてこのケースを使用する解析を行う必要がある。

線の反転表示は、解析が開始されたテストケース２６８を示している。図９では、テストケースＴ−ＰＲ−００２−０２は反転表示されている（２６８）。１つ上のレベルは、テストケースＺ−ＺＺ−００５−０６の「間接調達」である。フォルダアイコンとしてその中のいくつかのレベルを有して示されているテストケースＴ−ＰＲ−００２−０１である「不十分な在庫のためにＭＲＰを通じた在校材料の間接調達」、及び同じく親テストケース内のテストケースＴ−ＰＲ−００２−０３である「ＭＲＰ及びオーダー承認による材料の間接調達」を含む、親テストケース内の他のテストケースである「間接調達」が示されている。テストケースＴ−ＰＲ−００２−０３内の依存関係はまた、図９のスクリーンショットに示されている。
「解析ロードマップ」の各テストケース番号１７８は、詳細へのジャンプ機能として働き、そこから情報の異なる部分集合を達成するために再解析が実行される。

一般的に、「自動多次元追跡可能性行列」のテストケース間の関係に関する情報は、「解析ロードマップ」２６６に図式的に表示される。１つの手法では、「解析ロードマップ」は、グラフィカルユーザインタフェースを備えたコンピュータシステムがフォルダ内のファイルを表示するのと非常に似た方式でテストケースを表示する。特に、「解析ロードマップ」は、「Ｗｉｎｄｏｗｓ（登録商標）」オペレーティングシステム（例えば、Ｗｉｎｄｏｗｓ（登録商標）２０００又はＸＰ（登録商標））内の「Ｗｉｎｄｏｗｓ Ｅｘｐｌｏｒｅｒ」がフォルダの要素としてファイルを表示する方法に類似する場合がある。このツールは、全関係をマップアウトし、それらを論理的なフォルダダイアグラムにレイアウトするために依存関係及び従属関係を使用する。「解析ロードマップ」の一実施形態では、一連のテストケースが縦のリストに表示され、１行に１つのテストケースと、テストケースの行のフォルダ又は文書の表示のようなアイコンとが示されている。フォルダアイコン２８４は、例えば、それらのケースをその中に付加的なテストケースを付けて表示するために使用することができ、文書アイコン２８６は、その中に付加的なケースが付いていないテストケースを表示することができる。

「自動多次元追跡可能性行列」のテストケースのどのチェーンの最も低いレベルも単一のソフトウエアモジュールを評価するテストケースである場合、このような最も低いレベルのテストケースと他のテストケース（多くのトランザクションを含むケースを含む）との間の関係は、個々のソフトウエアモジュールとテストケース及び任意的に文書化のような他のコンポーネントとの間の関係を確立する。代替的に、一部のチェーンにおける最も低いレベルのテストケースは、単一のソフトウエアモジュール又はトランザクションを試験する必要はないが、より複雑な場合がある。しかし、個々のソフトウエアモジュール又はトランザクションは、このようなケースに関連付けることができ、これによってソフトウエアモジュール又はトランザクション及び様々なテストケース間の関係が自動的に判断される。一般的に、「自動多次元追跡可能性行列」は、テストケース間、並びに複合ソフトウエアシステムの他のコンポーネント間の関係を確立するために使用される。

図１０は、図１Ｃの「自動多次元追跡可能性行列」情報の「解析ロードマップ」を表示しているスクリーンショット１７０を示し、テストケースＺ−ＺＺ−９９９−０２（１２０）の「直接調達」が、「解析ロードマップ」がそこから準備された開始テストケースとして反転表示されている。１つ上のレベルに進むと、「マスターデータ設定」１１０（テストケースＺ−ＺＺ−９９９−０１）が含まれる。同じレベルのものは、「直接調達」１２０である。「間接調達」１３０及び「直接調達」１２０の両方は、依存関係の２つのレベルを有するものとして示されている。各レベルの依存関係は、同じ２つのテストケースである「受け取り」１４０及び「請求」１５０である。

図１１は、テストケースとテストケースによってサポートされるビジネス処理との間の接続を示す「エンティティ関係ダイアグラム」２９０を示している。このダイアグラムは、複合ソフトウエアシステムのコンポーネントと関連した開発又は実行プロジェクト間の関係を維持する「自動多次元追跡可能性行列」の構造間の論理的関係を示している。「エンティティ関係ダイアグラム」２９０では、「テストケースカタログ」２９２は、依存関係２９４、従属関係２９６、及び各テストケースに対して実行されるトランザクション（ソフトウエアモジュール）のための関連するトランザクションコード２９８にリンクされており、トランザクション記述３００は、各トランザクションコード２９６に関連付けられている。ケース特性３０２はまた、「テストケースカタログ」２９２を通じて各ケースにリンクされ、接続を表している接続バー３１６のような付加的な情報を提供する。ケースカタログ２９２及びビジネス処理３０６及びプロジェクトの目的（「配信可能リファレンス」３１４）間の関係は、コネクタ（「Ｂｐ＿コネクタ」３０４）によって維持され、これは、従来の追跡可能性行列（ソフトウエアの目標とされる機能性がソフトウエアの要素によって達成される方法を示す）によって達成される機能である。従って、「自動多次元追跡可能性行列」は、複数のレベルにわたってテストケースとトランザクション／ソフトウエアモジュールとの間の関係を処理する場合に大きく改良された柔軟性、追跡可能性、及びパワーを提供することに加えて、公知の追跡可能性行列手法の特徴を含むことができる。
セキュリティロール３０８、作業ストリーム３１０、及びテスター３１２に関する一般的な情報は、図１１に示されている「エンティティ関係ダイアグラム」２９０の実施形態で提供され、これは、試験作業のためのプロジェクト又は試験環境（例えば、サイクル）の機能とすることができる。あらゆる他の要求される情報は、適切な場合に図示のエンティティに表示又はリンクされる。

図１２は、本発明の方法の１つの態様を示す「自動多次元追跡可能性行列」３２０を使用する方法の流れ図を示している。本方法は、複合ソフトウエアシステムのコンポーネントの修正３２４によって３２２で始まる。個々のコンポーネントの試験３２６が次に続き、コンポーネントの独立した態様が他のソフトウエアモジュールによるその性能の試験の前に機能していることを保証することができる。次に、ソフトウエアコンポーネントへの修正は、複合ソフトウエアシステムのコンポーネント間（すなわち、「追跡可能性行列」のテストケース間）のいずれかの関係３２８を変更したか否かを判断すべきである。いずれかの関係が変更された場合（例えば、新しい依存関係又は従属関係）、「追跡可能性行列」は、それに応じて更新される（３３０）。「自動多次元追跡可能性行列」ツール３３２は、次に、「多次元追跡可能性行列」のどのテストケースが修正されたコンポーネントによって影響を受けるかを判断するために用いられ、影響されるか又は「疑われる」ケースのリストをもたらす（３３４）。これらのケースの全ては、次に、回帰試験で実行されるか、又は部分集合がケースの重要性又は修正されたコンポーネントへの依存関係のチェーンの近似性に基づいて選択される（３３６）（例えば、修正されたコンポーネントを試験するケースの段階の２つ、３つ、４つ、又は５つ、又は何らかの他の所定の数に入るテストケースだけを要求することができる）。一般的に、試験を実行する段階は、テストケーススクリプトの使用を必要とする。スクリプトが試験を実施するために実行された（３４０）後に、出力結果が解析され（３４４）、いずれかの変更がコードに必要かを判断するために予想される結果と比較される（３４６）。変更が必要でないことを結果が示す場合、コンポーネントを修正して試験するタスクは、３４８で終了すると考えられる。更に別の変更が必要な場合、修正を必要とする複合ソフトウエアシステムのコンポーネント又は複数のコンポーネントを識別する段階３４２が取られる（一般的に、特に複合ソフトウエアシステムがコンポーネントの修正の前に満足に作動していた場合、最近修正されたコンポーネントは、更に別のデバッグ又は他の修正を要求する可能性が大きい。）次に、「自動多次元追跡可能性行列」の支援でコンポーネント修正及び試験のサイクルを進めることができる。

図１２の流れ図又は本明細書のあらゆる他の流れ図に関して、適切な場合には、本明細書の流れ図で連続したものとして示される２つの段階は、同時に、一緒に（すなわち、単一の段階に結合されて）、又は並行して実行することができ、更に他に指示がない限り、２つ又はそれよりも多くの段階の順序が連続することがそれほど重要でない場合、２つ又はそれよりも多くの段階は、当業者が適切と考えるどのような順序でも実行することができる。

図１３は、「自動多次元追跡可能性行列」３２０を使用する方法の流れ図を示し、複合ソフトウエアシステムの修正を含む作業プロジェクト中に監査トレールの許可及び作成を監督するための管理エンティティ３７４への通信を示している。このようなプロジェクト中に、グループメンバ、チーム、又は他のエージェントは、複合ソフトウエアシステムでのコードを修正するための許可を要求する（３５０）。許可を受信した場合（３５２）、コードが修正される（３５６）（修正されない場合、プロジェクトは、更に別のアクションが取られるまで保留される）。コードの修正３５６後又は修正中のいずれかで、文書化は、タイムスタンプの付いた保存されたファイルを管理サーバにダウンロードし、これによって（又は他の手段によって）行われた変更を列挙し、元の及び修正されたコードセグメントを与え、変更の目的を識別し、関連したテストケースを特定するなどを必要とする管理エンティティ３７４に提供される（３５８）。コードを修正している当事者又は他の当事者は、次に、「自動多次元追跡可能性行列」が更新を必要とするか（例えば、修正された「追跡可能性行列」で識別された関係のいずれかを有するか、又は作成された新しい関係を有するか）どうかを判断すべきである（３６０）。そうである場合、「追跡可能性行列」は更新され（３６２）、更新は、管理エンティティ３７４と共用され、全ての要求される情報を提供する。修正されたコードは、次に試験される（３６４）（「追跡可能性行列」を更新する必要がなかった場合、「追跡可能性行列」を更新する段階３６２は省略され、修正されたコードが直接試験される（３６４））。試験活動及び結果は、管理エンティティ３７４と共用される。コードの性能が許容できないと分かった場合（３６６）、コードは、再度修正する必要があり（３５６）、次に、段階３５８から３６６が繰り返される。性能を許容することができる場合（３６６）（例えば、回帰試験の合格、又は回帰試験に新しく設計された試験を加えたものの合格）、検証レポートが作成され（３６８）、管理エンティティ３７４と共用され、コードの完全な修正及び試験を文書化する。次に、完全に修正されたコードの実行の許可が要求される（３７０）。承諾された場合、コード又は修正されたモジュールのバージョン番号の更新を必要とするコードが実行される（３７２）。場合によっては、将来の回帰試験のための新しいベースラインが必要とされて作成される（図示せず）。
管理エンティティ３７４は、人間の監督者又はプロジェクトマネージャと関連するハードウエア（例えば、サーバ及びネットワーキングシステム）及びソフトウエア（例えば、関係データベース、電子署名ツール、タイムスタンプ及びアーカイブソフトウエア、プロジェクト管理ツール、ＣＳＶシステムなど）を含むことができる。

別の意味では、本発明は、選択されたテストケースを実施することによって試験される複合ソフトウエアシステムのプログラムモジュール間の関係に関するデータの入力を文書化する方法を含む。従って、オペレータが他のコンポーネントに対するテストケースの関係に関する情報を入力するために「テストケースカタログメンテナンス形式」にアクセスする場合、記録が「監査データベース」（図示しないが、「管理エンティティ」３７４に属する）に作成され、誰が変更を入力したか、どのような変更か、及びいつ変更が入力されたかを記録する。「監査データベース」はまた、問題のテストケースのための「テストケースカタログ」エントリの元の及び修正されたバージョンの保存されたコピーへのポインタを含むことができる。

図１４は、既存のソフトウエアのためのパッチを作成する場合に「自動多次元追跡可能性行列」３２０を使用する方法の流れ図である。本明細書で使用される時の「パッチ」は、一般的に、プログラム又はソフトウエアシステムの新しいリリースの完全なインストレーションを要求するのではなく、複数のモジュールを含むプログラム又は複数のプログラムを含むソフトウエアシステムの１つ又はそれよりも多くの既存のソフトウエアモジュールを実行する時に修正又は交換する実行可能プログラムを意味する。編集されていないプログラムコードがユーザに使用可能であるシステムでは、パッチは、プログラムコードの部分を交換するためにテキストの１つ又はそれよりも多くのセグメントを必要とする可能性があり、その後、ユーザは、実行可能ファイルを作成するためにパッチされたコードを編集することができる。パッチは、１つ又はそれよりも多くの既知のバグを修復することができ、他のハードウエアを備えた改良された互換性のためのドライバを修正することができ、新しい機能（例えば、テキスト入力フィールドのためのスペル検査を含む）を追加することができ、美的センスを向上させ（例えば、いくつかのモジュールに関する修正されたグラフィック）、前から使用可能であった機能を制限することができ、セキュリティーを拡張することなどができる。パッチは、ソフトウエアシステムの新しいリリースと比較して、比較的適用範囲が狭い傾向がある。

図１４の方法３２０では、パッチングに適切な目的が識別される（４００）（例えば、バグの訂正など）。一般的に、これは、要求される作業の範囲及びパッチとしてのリリースの適性の検討にリンクした問題の文書化、及び、リンクしたプロジェクトを始めるための管理エンティティ（図示せず）からの適切な許可の受信を必要とする。修正する必要があるモジュールが識別される（４０２）（これはまた、パッチングに適する目的を識別する段階と同時に起こることがある）。「自動多次元追跡可能性行列（Ｔ．Ｍ．）」は、変更によって影響を受ける可能性のある他のソフトウエアモジュールを識別するために使用される（４０４）。この時点で、任意的な段階として、影響を受ける可能性があるモジュールに基づいて与えられたプロジェクトの範囲に対してパッチが適切であるか否か（４０６）を考えることが適切な場合がある。パッチがもはや適切と考えられない場合、提案された変更は、パッチの形式にではなく、次のソフトウエアリリースに含めることができる（４０８）（この場合、変更を実行する、他の変更及び追加を加える、修正されたコードを試験する、リリースを承認する、及び新しいリリースを出すなどのいくつかの付加的な段階を実行することができ、そのどれも図示していない）。パッチが適切である場合、パッチが作成される（４１０）。当業者は、自動ツールを使用して修正されたソフトウエアモジュールを元のソフトウエアモジュールと比較し、実行可能なコードを自動的に作成し、元のモジュールのバイナリコードの変更された部分を交換するか、又はツールを使用してインストレーションソフトウエアを作成して元のモジュールを修正されたモジュールと交換するなどのようなパッチを作成するために取ることができる様々な手法を理解するであろうし、ユーザによって次に編集される編集されていないコードにパッチが適用される場合に、同様の手法を実行することができる。

パッチが作成された４１０後で、パッチされたコードが試験される（４１２）。これは、パッチの目的が満たされたことを保証するために新しいか又は修正された機能の手動試験、それに加えて前から機能していたコードがなお予想されるように機能することを保証するための回帰試験を伴う場合がある。他の影響を受けたモジュールを識別する（４０４）ための「自動多次元追跡可能性行列」の前の使用からの結果は、回帰試験で実行されるテストケースを識別するために加えられ、代替的に、影響を受けたケースの範囲がその時間によって異なる可能性があり、パッチが必要とされた予想しなかった変更のために実際には作成されるので、回帰試験を行う段階４１２はまた、回帰試験４１２で試験する必要があるテストケースを識別するために、「自動多次元追跡可能性行列」（例えば、「解析ロードマップ」ツールの形式で）を使用する段階を含むことができる。試験の結果が許容可能な性能を示す場合（４１４）、プロジェクトは、パッチのリリースを計画する段階４１８、パッチを出す段階４２０（例えば、ダウンロードのための「インターネット」に接続したサーバでそれを使用可能にする段階、又はＣＤ−ＲＯＭ、フロッピーディスク、電子メールアタッチメントのような他のコンピュータ可読媒体でそれを提供する段階）、及び段階４０８に関連したもの（図示せず）に類似の段階を伴う場合があるソフトウエアの次のリリースにパッチの修正を組み込む段階４２２のような段階に進むことができる。

一実施形態では、完全に試験されて承認されたソフトウエアパッチは、目標コンピュータを更新するためにネットワーク接続を通じてパッチを自動的に適用することなどにより、１つ又はそれよりも多くのコンピュータのコードを自動的に更新するために使用される。代替的に、更新は、目標コンピュータのユーザ又は管理者による手動アクションを要求することができる。例示的なＥＲＰ更新システムの原理は、本明細書に矛盾しない範囲で本明細書において引用により組み込まれている、２００４年１１月１日付けで閲覧されるｈｔｔｐ：／／ｗｗｗ．ｐｅｏｐｌｅｓｏｆｔ．ｃｏｍ／ｍｅｄｉａ／ｅｎ／ｐｄｆ／ｗｈｉｔｅ＿ｐａｐｅｒ／ｅｎｔｅｒｐｒｉｓｅ＿ｗｐ＿１００４．ｐｄｆで入手可能（登録後）である「ＰｅｏｐｌｅＳｏｆｔ企業の全所有権経験」という名称のホワイトペーパー、２００４年１０月、「ＰｅｏｐｌｅＳｏｆｔ、Ｉｎｃ．」（プレサントン、カリフォルニア）で与えられている。

図１５は、修正するソフトウエアモジュールを選択する段階を作成する場合に「自動多次元追跡可能性行列」３２０を使用する方法の流れ図である。必要とされるソフトウエア修正が識別された場合（４８０）、当業技術に精通したプログラマーには、変更を完全に実行するために１つ又はそれよりも多くのソフトウエアモジュールのどれが修正されるかを選択することができる時間がある。例えば、仮説的電子商取引アプリケーションでは、ユーザのアイデンティティを前の通信販売顧客情報と比較する機能は、ログインモジュール、クッキー読取モジュール、チェックアウトモジュール、又は電子商取引ソフトウエアシステムの課金モジュールに組み込むことができる。このような判断は、多くの場合に、利便性に基づいて行われるか、又はプログラマーの個々の好み又は他の基準によって導かれる。過去に頻繁に見落とされてきたのは、２つ又はそれよりも多くの許容可能な選択肢の間の選択が予想されなかった方法で他のソフトウエアモジュールにいかに影響を与える可能性があるか、又は選択が次の試験、特に回帰試験のコストにいかに影響を与える可能性があるかということである。このような判断を行う場合に有用になる１つの基準は、他のモジュールに与えるソフトウエア変更が有する影響の程度である。より具体的には、プログラマーが、修正するために２つ又はそれよりも多くのモジュール間で選択する場合、第１モジュールの従属関係及び依存関係は、他のモジュールの従属関係及び依存関係よりもかなり小さい数の他のモジュールを含み、これは、修正するために第１モジュールを選択することが回帰試験のより少ない需要（コスト的に低い）をもたらす傾向があり、一般的に、多くの他のモジュールの性能を不意に変える可能性を低減させることができる。

図１５の方法３２０では、必要なソフトウエア修正が識別された（４８０）後に、ソフトウエア変更が選択される２つ又はそれよりも多くの識別されたモジュール間で選択が行える状況下でモジュールが識別され（４８２）、本発明の「自動多次元追跡可能性行列」は、最も低い１つ又は複数のインパクトモジュールを識別するために使用される（４８４）。これは、影響を受ける可能性のある他のモジュールの数（例えば、依存関係の１、２、３、４、５、又はそれよりの上のレベル内で及び任意的に従属関係の１レベル又はそれよりも上）、及び／又は影響を受けたケースのセットに対する回帰試験の規模又はコスト又は複雑性の推定に基づくモジュール全てのランク付け段階を含むことができる。段階４８２から識別されたモジュールの最も低い又はより低いインパクトモジュールを識別した（４８４）後で、１つ又はそれよりも多くのモジュールの選択が段階４８４で提供される情報に基づいて行われる（４８６）。選択された１つ又は複数のモジュールは、最も低い１つ又は複数のインパクトモジュール、又は、最も大きい影響を持たないが、コードのアクセス可能性（例えば、ソースコードが制限される場合がある）、ソフトウエアプロバイダとの契約上の関係、修正する場合の困難度、モジュールの他の態様との可能な相違などのような他の考慮が原因で最も低い影響を必ずしも持たないモジュールとすることができる。次に、提案される変更が行われ（４８８）、ソフトウエアの性能が許容可能であることを保証するために回帰試験、並びに必要に応じて他の試験が実行される（４９０）。ソフトウエアは、次に、実施される（図示せず）、リリースされる等々が可能である。

図１６は、複合ソフトウエアシステムで回帰試験を行う方法を示している。更に別の変更が複合ソフトウエアシステムで行われる前に、ベースラインが設定される（１０００）。ベースラインは、テストケース、テストケースによって使用されるデータセット、及びテストケースの既知の結果の組合せである。ベースラインは、前に設定された性能が維持されているかを調べるために、回帰試験からの次に得られた結果を比較するための手段を提供する。ベースラインを確立する処理は、テストケース及びデータセットを組み立てるのにかなりの努力を必要とする可能性があるが、当業者は、このようなタスクを容易に実行することができるであろう。ベースラインの確立に続いて（１０１０）、複合ソフトウエアシステムが修正される（１０１０）。修正は、供給業者からの更新の組込み、インタフェースの改良、新しいハードウエア又はドライバの追加、ネットワークの拡張、オペレーティングシステムの更新、回帰試験によって試験される範囲外の機能のための新しいモジュールの組込み、バグ訂正などを含むことができる。

ソフトウエアシステムへの修正１０１０は、一般的に、１つ又はそれよりも多くのテストケースに関連した１つ又はそれよりも多くのソフトウエアモジュールの変更を含むことになる。「自動多次元追跡可能性行列」は、次に、複合ソフトウエアシステムを試験するために実行する必要があるテストケースを選択し、前に設定された機能がまだ使用可能であり、かつ適切に作動していることを保証するために用いられる（１０２０）。一実施形態では、「自動多次元追跡可能性行列」に関連したコンピュータ化された「解析ロードマップ」を使用して、影響を受けたテストケースを実行のために選択する。

回帰試験のためのテストケースが選択された状態で（１０２０）、回帰試験が実行される（１０３０）。これは、自動、手動、又はこれらを組み合わせたものによって行われる。回帰試験の結果は、次に、エラーフラグ（ベースラインの予想される結果と回帰試験の実際の結果との間の識別可能な相違）があるか否かを判断する（１０４０）ためにベースラインと比較される。エラーフラグがない場合、回帰試験は正常であり、プロジェクトのこの段階で終了することができる（１０８０）。エラーフラグがある場合、相違は、回帰試験がベースラインとは異なる日付で実行されたという事実のために容易に説明可能な相違であるような、許容可能なものである場合があるということが可能である。例えば、検査作成モジュールの実行は、検査要求の記録に現在の日付を配置することができ、これは、ベースラインの対応する記録とは異なることになるが、予想されるか又は容易に説明可能な方法においては、それは、訂正を必要とするエラーを示すものではない。すなわち、日付特定のフラグは、フィルタを掛けることができ（１０５０）、又は、より一般的には、「予想される」相違は、ベースラインの機能がまだ存在しているかを判断する際の考慮から削除することができる。（多くの実施形態では、予想される相違の除去は、エラーフラグの検査の段階１０４０に一般的に含まれると考えられるが、明確にするためにここでは明示的に示されている。）予想されるエラーフラグのフィルタリング１０５０の後で、回帰結果にまだエラーフラグがある場合には、エラーは、恐らくシステムに持ち込まれている。エラーは、次に、公知の技術（デバッグ、プログラムスライシングなど）を使用して識別及び修復されるべきである（１０７０）。エラーが修復されたと考えられる状態で、テストケースは、「自動多次元追跡可能性行列」を使用して再度選択される（１０７０）。エラーを修復する段階が、前に選択されたテストケースによって網羅されるモジュール以外のどのモジュールも伴わない場合、段階１０７０は省略される。回帰試験は、まだエラーフラグがあるか否かを判断する（段階１０４０、１０５０、及び１０６０）ために実行される（１０３０）。エラーフラグがない場合、試験は終了する（１０８０）。

図１７は、回帰試験がその方法に沿ったチェックポイントを有する段階で実行される、「自動多次元追跡可能性行列」で複合ソフトウエアシステムを試験する方法を示している。図１６のように、ベースラインが設定され（１０００）、複合ソフトウエアシステムが修正され（１０１０）、「自動多次元追跡可能性行列」が、修正に応じて試験する必要があるテストケースを選択するために使用される（１０２０）。全体的な回帰試験を実行するのではなく、選択されたテストケースのトランザクションの部分集合が実行される（１０３２）。部分集合は、１つ又はそれよりも多くの全体的なテストケースを含むことができるか、又は１つ又はそれよりも多くのテストケースに対して実行されるトランザクションの部分だけを含むことができる。部分集合の使用により、複合ソフトウエアシステムの特定の部分が作動しているのを保証するためにチェックポイントを設定することができる。試験されたトランザクションの選択部分（又は、テストケースの部分集合）からの結果は、次に、予想される結果と比較される（一実施形態では、ベースライン自体が、実行されるトランザクションの部分集合又はテストケースに従って分類された予想される結果を含むことができる）。エラーフラッグがある場合、エラーの原因が識別されて更に修復され（１０７０）、トランザクションの部分集合が再試験されるが（１０３２）、考慮すべきであるケースのセットを変更したエラーの原因を修復する場合（１０７０）、「自動多次元追跡可能性行列」は、ケースの部分集合が再度選択されて試験される（１０３２）回帰試験のためのテストケースを再度選択するために使用される（１０２０）。エラーの検査段階１０４０がエラーフラッグを生じない場合、テストケースが終了する（１０７２）までトランザクションの次の部分集合が実行され（１０３２）、エラーに対して再度試験されて（１０４０）処理を１０８０で終了する。

ＳＡＰシステムの試験
ＳＡＰソフトウエアシステムは、本発明のツールで試験される複合ソフトウエアシステムの広く使用される例を表している。ＳＡＰ統合の基本的な原理は、当業者には公知であり、以下のリソースに単に例示的に開示されている。
・「ＳＡＰ Ｒ３」の成功した実施例：ニューヨークのＮｏｒｂｅｒｔ Ｗｅｌｔｉ著「ＥＲＰプロジェクトの実際の管理」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂ Ｃｏ．、１９９９年（ＩＳＢＮ：０２０１３９８２４９）。
・「ＳＡＰ Ｒ／３」実施ガイド：インディアナポリスのＢｒａｄｌｅｙ Ｄ．Ｈｉｑｕｅｔ、Ｋｅｌｌｅｙ−Ｌｅｖｅｙ、Ａｓｓｏｃｉａｔｅｓ、及びＡｎｔｈｏｎｙ Ｆ．Ｋｅｌｌｙ著「Ｓａｐを理解するための管理者のガイド」、Ｍａｃｍｉｌｌａｎ Ｔｅｃｈｎｉｃａｌ Ｐｕｂｌｉｓｈｉｎｇ、１９９８年（ＩＳＢＮ：１５７８７００６３９）。
・「ＳＡＰ Ｒ／３」処理志向実施例：ニューヨークのＧｅｒｈａｒｄ Ｋｅｌｌｅｒ及びＴｈｏｍａｓ Ｔｅｕｆｅｌ著「反復処理プロトタイピング」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂ Ｃｏ．、１９９８年（ＩＳＢＮ：０２０１９２４７０６）。
・「ＳＡＰ Ｒ／３」システムの試験：Ｇｅｒｈａｒｄ Ｏｂｅｒｎｉｅｄｅｒｍａｉｅｒ及びＭａｒｃｕｓ Ｇｅｉｓｓ著、英国ハーローのＪａｓｏｎ Ｍ．Ｍｉｓｋｕｌｙ翻訳「コンピュータ支援試験ツールの使用」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、２０００年（特に２８−２１３ページを参照されたい）。
・ＳＡＰ：ニューヨークのＧｒａｎｔ Ｎｏｒｒｉｓ他著「管理者のための包括的ガイド」、Ｊｏｈｎ Ｗｉｌｅｙ ａｎｄ Ｓｏｎｓ、１９９８年（ＩＳＢＮ：０４７１２４９９２０）。

ＳＡＰ／Ｒ３システムとのカスタムソフトウエアのインタフェースは、Ｂ．Ｙｅａｇｅｒ著「ＭｅａｄのＥＲＰシステムは「Ｂｅｓｔ ｏｆ Ｂｒｅｅｄ」ソフトウエアを統合する」、ＰＩＭＡの「Ｎｏｒｔｈ Ａｍｅｒｉｃａｎ Ｐａｐｅｒｍａｋｅｒ」、第８２巻、第４号、２０００年４月、３６ページに説明されている。例えば、カスタムソフトウエアコンポーネントは、「ＢＡＰＩｓ」（ビジネスアプリケーションプログラミングインタフェース）と呼ばれるＳＡＰ銘柄ソフトウエアインタフェースプログラムを使用するＳＡＰ銘柄ソフトウエアと統合することができ、「ＢＡＰＩｓ」は、「Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．」のＣＯＭ／ＤＣＯＭコネクタを使用し、Ｍｉｃｒｏｓｏｆｔベースのクライアントが「ＳＡＰ Ｒ／３」と通信することを可能にするものである。このようなコネクタは、「Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．」による「ＡＣＴＩＶＥＸ」銘柄の技術及び「ＣＯＭ／ＤＣＯＭ」戦略を使用して組み立てることができる。本発明と共に使用するＳＡＰ銘柄ソフトウエアシステムを用いる他の態様は、Ｏ．Ｗｉｅｓｅｒ著「処理制御システム及びラボラトリ情報システムの論理チェーンへの統合」、Ａｕｔｏｍａｔｉｓｉｅｒｕｎｇｓｔｅｃｈｎｉｓｃｈｅ Ｐｒａｘｉｓ、第３９巻、第２号、１９９７年２月、２６−２８ページに開示されている。

いくつかのツールが、ＳＡＰ及び他のソフトウエアの自動試験のために最近開発されており、これらは、必要な場合に本発明の様々なタスクのために使用することができる。例えば、テキサス州ダラス所在の「ＡｕｔｏＴｅｓｔｅｒｅｒ，Ｉｎｃ．」は、「ＳＡＰ（登録商標）」のための「Ａｕｔｏ Ｔｅｓｔｅｒ ＯＮＥ（登録商標）特別版」を販売しており、これは、ＳＡＰシステムのソフトウエア試験を容易にし、特にＲ／３ビジネス処理を検証し、データがシステムによって適切に処理されることを保証する試験を捕捉するといわれている。更に別の情報は、ｈｔｔｐ：／／ｗｗｗ．ａｕｔｏｔｅｓｔｅｒ．ｃｏｍ／ｃｏｎｔｅｎｔ／ｐｆｖ ｓｏｆｔ ａｔ１ｓａｐ．ｈｔｍ（２００４年８月３１日付けで閲覧される）で提供されている。本発明の一部の態様で有用なツールになる別のツールは、Ｍｅｒｃｕｒｙの「ＴｓｅｔＳｕｉｔｅ ４．０」であり、これは、試験スクリプトの自動作成及び実行のための「ＲａｐｉｄＴｅｓｔ（登録商標）」ソフトウエアを含む。「Ｍｅｒｃｕｒｙ Ｉｎｔｅｒａｃｔｉｖｅ」はまた、「ＳＡＰ Ｒ／３」のために設計されたそのソフトウエア試験製品のリリースされたバージョンである「ＷｉｎＲｕｎｎｅｒ」及び「ＬｏａｄＲｕｎｎｅｒ」を有する。

ＳＡＰシステムはまた、製品及びパッケージに関するリアルタイムの情報を捕捉するためにＲＦＩＤシステムに統合される。「ＳＡＰコンソール」は、ＲＦＩＤ情報を捕捉する場合に１つの有用なツールになる。ＲＦＩＤ及び「ＳＡＰコンソール」を伴う標準トランザクションのための付加的なツールは、「Ｐｅａｋ Ｔｅｃｈｎｏｌｏｇｉｅｓ」から入手可能である。１つのこのような製品は、「Ｐｅａｋ Ｓ／３」インタフェースであり、これによってＲ／３システムユーザは、無線設定でＬＥＳアプリケーションを作動することができる。

ｈｔｔｐ：／／ｗｗｗ．ｐｅａｋｔｅｃｈ．ｃｏｍ／ｈｔｍｌ／ｅｒｐ ｉｎｔｅｇｒａｔｉｏｎ．ｈｔｍに説明するように、「ＳＡＰコンソール」は、グラフィカルベース（ＧＵＩ）スクリーンを文字ベースのスクリーンに変換するために設計されたＳＡＰの固有文字ベースの無線周波数ソリューションである。「ＳＡＰコンソール」は、ビジネス論理を提供しない。このような機能性は、Ｒ／３内に見出される。「ＳＡＰコンソール」トランザクションの開発は、ＡＢＡＰワークベンチ内で行われる。ＳＡＰは、４．６Ｂ及びそれより上のバージョンで「コンソール」機能性を供給する。「ＳＡＰコンソール」は、ＶＴ２２０エミュレーションをサポートする「Ｗｉｎｄｏｗｓ ＮＴ」サーバ及びテルネットソフトウエアを必要とする。

コードリポジトリ、移動制御ツール、及び構成管理ツールの使用
試験に関連した文書及びデータを管理するような自動試験のためのシステムを準備する「構成管理（ＣＭ）」ツールが公知である。ＣＭツールは、「テストベッド」として公知のカタログ又はライブラリの試験スクリプト及びデータセットを管理するために使用することができる。ＣＭツールは、スクリプトされた手順の統合、ソフトウエアのトラックバージョンを保存することができ、スクリプトを再使用及び追跡することができるようにするものである。ＣＭツールは、Ｄｕｓｔｉｎ他によって説明されている（３０５−３０６、４２４−４２６ページ）。ＣＭツールの例は、「ＣｌｅａｒＣａｓｅ（登録商標）」（ｈｔｔｐ：／／ｗｗｗ−３０６．ｉｂｍ．ｃｏｍ／ｓｏｆｔｗａｒｅ／ａｗｄｔｏｏｌｓ／ｃｌｅａｒｃａｓｅ／ｉｎｄｅｘ．ｈｔｍｌを参照されたい）のような、ｈｔｔｐ：／／ｗｗｗ−３０６．ｉｂｍ．ｃｏｍ／ｓｏｆｔｗａｒｅ／ｓｗ−ｂｙｃａｔｅｇｏｒｙ／ｓｕｂｃａｔｅｇｏｒｙ／ｒａｔｉｏｎａｌ／ＳＷ７５０．ｈｔｍｌ（２００４年１０月７日付けで閲覧される）に説明されているＩＢＭの「ＲＡＴＩＯＮＡＬ（登録商標）」ソフトウエア製品を含む。このツールは、バージョン管理を超えてソフトウエア開発ライフサイクルでの全てのアセットのバージョン化に進むといわれている。「Ｒａｔｉｏｎａｌ ＣｌｅａｒＣａｓｅ」は、ファイル及びディレクトリ毎に変更を追跡し、ソースコード、バイナリ、実行ファイル、文書、試験スクリプト、及びライブラリを含む完全な注釈付きバージョン履歴アセットを維持する。開発者は、どのファイルのどのバージョンが特定の変更をトリガしたかを識別するために、あらゆる以前にビルド又はベースライン構成に迅速にロールバックすることができる。正しいユーザが正しいファイルにアクセスしていることを保証するためといわれるバージョン化されたオブジェクトデータベースを備えたディレクトリ、サブディレクトリ、及び全てのファイルシステムオブジェクトのバージョン化を備えたチェックイン／チェックアウト開発モデルが含まれている。

移動制御ツールは、本発明がコードセキュリティを拡張し、ソフトウエア変更の監査トレールを強化することができるように適用されるものである。移動制御ツールの原理は、本明細書に矛盾しない範囲で本明細書において引用により組み込まれている、２００３年７月２９日にＵｎｄｅｒｗｏｏｄに付与された「ビジネスコンポーネントフレームワーク」という名称の米国特許第６，６０１，２３３号に説明されている。Ｕｎｄｅｒｗｏｏｄ特許によると、移動制御ツールは、ソースコード、データ、及び他の品目が変更され、試験され、初期の開発から試験まで又は試験から生産までのような１つの開発環境から別の開発環境に移動される時に、それらの複数のバージョンを制御するための手段を提供する。一般的に、Ｕｎｄｅｒｗｏｏｄ特許で説明されるような移動制御ツールは、ソフトウエア開発者が修正を行う前にソフトウエアリポジトリから既存のコードをチェックアウトしたり、設定された基準を満たしたり、リポジトリに修正されて完全に試験されたソフトウエアを検査し戻すためにプロジェクト責任者又は他のソースから許可を受け取ることができるように使用することができ、移動制御ツールは、新しいバージョン番号、行われた変更の文書化、及び変更が行われた当事者、変更の理由、変更の日付、調べられたテストケースのリスト、考えられる欠点又は将来の拡張の識別、及びユニット試験、回帰試験、又は他の試験での十分な性能の証明を含むことができる付加的な情報に関連付けられる。ビルドコードが適合すると思われる場合、ソースコードは、ソースコードリポジトリに検査され、ソースコード管理者は、そのステータスを通知される。

回帰試験は、ソフトウエアの完全バージョンを用いて、又は試験を必要とするコンポーネント（これらは承認されたコンポーネントのコピーとすることができる）だけを伴う軽量バージョンを用いて行われる。コンポーネント又はユーザインタフェース開発者又はソフトウエアシステムの部分集合に試験を行う他の者に対して、異なるワークステーション構成が存在する場合がある。関わっている全ての開発者は、開発中のコードのチェックイン／アウトのためのソースコードリポジトリを使用することができる。要求される修正がユーザインタフェース及びサーバ側コンポーネントの両方に影響を与えるイベントでは、開発者は、ドライブマッピングを使用するコンポーネント及びインタフェースを共用することができる。
また、ＩＢＭの「ＲＡＴＩＯＮＡＬ（登録商標）」ソフトウエアグループの「ＳｏＤＡ」（ソフトウエア文書化自動化）システムのような自動文書発生器も使用することができる。

個々の回帰試験の実行
本発明による回帰試験の実行は、テストケースからの試験結果を調べるか又はテストケースによって呼び出された試験の実行を支援することができる公知の自動試験ツールによって支援される。本発明に適用することができる１つの例は、１９９８年５月２６日にＭｃＭａｈｏｎ及びＢｕｚｓａｋｉに付与された「アプリケーション論理の回帰試験の方法及び装置」という名称の米国特許第５，７５８，０６２号である。ＭｃＭａｈｏｎ及びＢｕｚｓａｋｉの特許は、ソフトウエアシステム内のアプリケーション論理の回帰試験の方法及びシステムを説明している。著者によると、ソフトウエアアーキテクチャは、表示層（例えば、ユーザインタフェース）、アプリケーション層（例えば、ビジネス論理）、及びデータ／記憶層に分けられる。新しい試験システム内では、表示層とアプリケーション層の間の通信インタフェースが識別され、表示層からアプリケーション層に渡されるユーザ開始の指令（イベント）は、試験再生イベントファイルに記録される。試験再生イベント記録中に、基準プログラムのアプリケーション層の状態の違いは、基準状態ログファイルに捕捉される。プログラムを試験するために、試験再生イベントファイルの記録されたイベントが再生され、そのアプリケーション層に直接適用される。各イベント後に、プログラムの状態の違いは、試験状態ログファイルに捕捉される。基準及び試験状態ログファイルは比較され、違いがエラー又は集計差ファイルに記憶される。表示層を入力するユーザ入力指令の代わりにアプリケーション層を入力するイベントを記録することにより、試験システムは、表示層の変更に集中しており、アプリケーション層のより直接の試験及びエラー検出を可能にするといわれている。ユーザに表示された情報の違いを記録する代わりに、イベント毎のベースでアプリケーション層の状態の違いを記録することにより、システムは、アプリケーション層の更に効率的なエラー検出及びエラー分離を可能にするといわれている。

また、本発明の将来的な使用は、本明細書に矛盾しない範囲で本明細書において引用により組み込まれている、１９９８年７月１４日にＰａｒｋｅｒ他に付与された「自動ＧＵＩインタフェース試験」という名称の自動試験システムの米国特許第５，７８１，７２０号である。Ｐａｒｋｅｒ他の特許は、グラフィカルユーザインタフェース（ＧＵＩ）を使用する新規及び改訂コンピュータアプリケーションプログラムの両方を自動的に試験する方法を説明している。キーボード又はマウスアクションのような模擬ユーザイベントは、ＧＵＩインタフェースに自動的に入力される。ＧＵＩは、次に、入力に応じたＧＵＩへの変更を観察するためにモニタされる。同じく使用されるのは、ハイレベルのプログラミング言語で書かれた試験スクリプト、試験スクリプトを実行する試験エグゼクティブ、及びＧＵＩにインタフェースを提供する試験ドライバである。試験スクリプトは、ＧＵＩ固有のリファレンスの代わりに論理オブジェクトの作動に関連している。試験エグゼクティブの主な担当は、ＧＵＩ独立リファレンスをＧＵＩ固有のリファレンスに変換することである。試験ドライバは、試験エグゼクティブからＧＵＩ固有のリファレンスを「受け取り」、ＧＵＩオブジェクトのために実際のインタフェースを実行する。均一な階層ネーミング方式は、ユーザとインタフェースで接続するためにＧＵＩ環境で使用されるオブジェクトである、試験中の各「論理スクリーン要素（ＬＳＥ）」を識別するために用いることができる。

テストケースを実行するためのスクリプトの作成は、データエントリ又はソフトウエアエントリの他の態様の間にユーザの入力を捕捉して再生する公知のソフトウエア試験ツールの使用を含むことができる。一実施形態では、テストケースの作成又は実行のスクリプト又は他の態様は、２０００年５月９日にＷａｌｋｅｒ他に付与された「回帰試験のための耐久性データを定義する方法」という名称の米国特許第６，０６１，６４３号のソフトウエアツールを用いるものである。Ｗａｌｋｅｒ他の特許は、トランザクションを含むソフトウエアアプリケーションの開発中及び他のライフサイクル段階の回帰試験を容易にする方法及びコンピュータ製品を開示している。回帰試験は、機能又は挙動レベルで目標試験を説明する試験データを伴うテストケースから構成される。試験オペレータは、手動試験を実行し、同時に試験を記録することができる。Ｗａｌｋｅｒ他の特許のアーキテクチャは、試験オペレータの物理的な活動をモニタし、その後で物理的なイベント段階（例えば、マウスのクリック又はキーストローク）を機能又は挙動の試験データに変換する（例えば、値を名前の付いたフィールドに入力する）。試験データは、トランザクションの堅牢な機能記述内にあり、それによってソフトウエア開発中のトランザクションへの物理的な修正（例えば、ユーザインタフェースの外形及びフィールドの位置及び画面上のボタンを変える）は、修正されたトランザクション内で実行するための試験データの有効性を維持する。試験レポートはまた、回帰試験の実行に応じて作成される。試験レポートは、実行された試験データ及びそれに対する応答の両方を列挙する。試験レポートは、トランザクションの回帰の不足を検証するためにベースライン又は制御試験レポートと比較される。違いのレポートはまた、試験レポートの比較から作成される。Ｗａｌｋｅｒ他のシステムは、試験データから成るテストケースを使用してトランザクションを回帰試験する方法として説明され、上述の試験データは、機能レベルでの上述の回帰試験を説明し、物理的なレベルで上述の回帰試験を実行し、上述の試験データは、上述のトランザクションの物理的なレベルを変更する上述のトランザクションへの物理的な修正が起こった場合に実行可能なままである。回帰試験のためのこの方法は、（１）上述の機能レベルで説明したテストケースの試験データを読み取る段階、（２）試験データに機能的に対応する試験を判断するためにトランザクションを評価する段階、（３）試験データを上述の評価段階で識別されたように試験機能を実行するのに必要なトランザクションイベントに変換する段階、及び（４）上述の物理的なレベルで上述の試験データを実行するためにトランザクションイベントでトランザクションを駆動する段階を含む。

本発明の範囲で使用される別の自動ツールは、Ｍｕｍｆｏｒｄ他に２００１年２月２０日に付与された「自動的に作成されたログを使用する自動試験の実行」という名称の米国特許第６，１９２，１０８号のツールである。Ｍｕｍｆｏｒｄ他の特許は、自動的に作成されたログを使用するサービスアプリケーションの自動試験のためのシステムを説明しており、サービスアプリケーションの各新しいリリースに対して新しい試験アプリケーションを作成する必要はなく、全てのデータ及び実行される処理を考慮することによってアプリケーションの様々な態様の試験を提供するものである。自動回帰テスターは、試験されているアプリケーションの最初のバージョンの実行によって作成されたデータを捕捉して記録する。このデータは、第１試験ログに記録される。そのアプリケーションの新規又は移植バージョンが開発された場合、第１試験ログは、アプリケーションの呼び出し側及びユーザ入力を含むオペレーティング環境をエミュレートする出力を作成するために自動回帰テスターによって使用される。アプリケーションの新規／移植バージョンの処理は、第２試験ログに捕捉されて記録される。自動回帰テスターは、第２試験ログを第１試験ログと比較し、データ（例えば、違いのレポート）のどのような相違も報告する。このような相違は、サービスアプリケーションの新規／移植バージョンのバグを示すことがある。

試験が、プリンタ、テープドライブ、又は他の大容量記憶媒体、ＣＤ又はＤＶＤ読取又は書込デバイス、付加的なサーバ、センサシステム、処理制御デバイス、ロボット、ＲＦＩＤ読取装置、デジタルカメラ、ビデオカメラ、及び自動搬送台車（ＡＧＶ）などのようなハードウエアとの相互作用を伴う場合、その試験は、ハードウエアと直接相互作用することができるか、又はハードウエアの電子的応答が試験されるコードと実際に相互作用するハードウエアを必要とせずに模擬されるように、ハードウエア模擬デバイス又はソフトウエアを使用することができる。これは、例えば、相互作用するハードウエアが開発中のソフトウエアによって停止されるか又は悪影響を受けるだけの余裕がない場合に特に有用であり、ハードウエアシミュレーション試験を、少なくとも製品のライフサイクルの早い段階での試験に対して更に実用的なものにする。ハードウエアシミュレーションの一部の原理は、本明細書に矛盾しない範囲で本明細書において引用により組み込まれている、Ｆｕｒａに１９９９年９月１４日に付与された「電子ハードウエアシミュレーションモデルを作成する方法及びシステム」という名称の米国特許第５，９５３，５１９号に説明されている。本明細書の範囲内で使用される更に別の原理は、本明細書に矛盾しない範囲で本明細書において引用により組み込まれている、Ｒ．Ｌ．Ｋｌｅｖａｎｓによって２００１年１２月６日に公開された「ハードウエアシミュレーションの方法及びシステム」という名称の米国特許公開ＵＳ２００１００４９５９４Ａ１に開示されている。Ｋｌｅｖａｎｓは、エミュレートされたハードウエアデバイス上に組み込まれたソフトウエアを試験するためのネットワークシステムを模擬するためのシステム及び方法を説明している。このシステムは、模擬ハードウエアの自動作成を提供し、模擬ハードウエアによって作成された模擬エラー条件に対する組み込みソフトウエアの応答の試験を容易にする。組み込みソフトウエアからの通信は、低いソフトウエアレベルで遮られ、エミュレートされたハードウエアデバイスから模擬ハードウエアに転送される。

自動試験に使用される更に別のツールは、Ｗａｌｋｅｒ他に２００１年１０月９日に付与された「ソフトウエアアプリケーションコンポーネントのコンピュータ支援試験の方法」という名称の米国特許第６，３０１，７０１号である。この特許は、トランザクションテスターが試験中のトランザクションの定義から試験データを作成することによってトランザクションの整合性を評価する自動試験を容易にする方法及びコンピュータ製品を説明している。フィールドの一般的な値は、トランザクション定義内に含まれ、一般的な試験値として再使用される。試験結果が作成され、既知の良好な値に対して又は代替的にトランザクション定義から作成された予想される試験結果に対して比較される。メニュー構造を含む他のソフトウエアコンポーネントもまた試験することができる。メニュー構造の定義は、各メニューの各エントリが完全に試験されて報告されるように厳密にトラバースされる。結果は、既知の良好な結果に対して自動的に比較されて確認されるか、又は、試験結果は自動的に検討される。トランザクション試験及びメニュー試験の両方は、回帰試験に組み込むことができる。
本発明の範囲内で使用される他のツールは、呼び出されたモジュールを識別して追跡可能性行列を検証するためにソフトウエア実行をモニタするリンク発生器を含む。

付加的な実施形態
統計ツールも、回帰解析でのテストケースの使用を拡張するために適用することができる。一実施形態では、全て又は一部のソフトウエアモジュールは、それぞれのモジュールが他のモジュールに対してどのくらい重要であるかを反映する臨界パラメータを割り当てられる。臨界パラメータの割当ては、自動的に行われるか、又は最も頻繁に使用されるモジュールを識別するためにコード使用の統計データを作成するソフトウエア解析プログラムのような自動ツールで支援される。一実施形態では、例えば、臨界パラメータは、５が最も頻繁に使用されるモジュールを反映し、１が最も低い頻度で使用されるモジュールを示す１から５の範囲とすることができる。より高い臨界パラメータを割り当てられたモジュールか又はそうでなければ平均よりも上の重要度であるとして既知であるか又は判断されたモジュールは、次に、そのモジュールに対して又はモジュールの性能に影響を与えることのあるモジュール又は他の要因（例えば、依存関係又は従属関係又はその両方）に対して変更が行われる場合に、更に厳密な試験に対してフラグを立てることができる。例えば、フラグが立てられたモジュールを呼び出すテストケースは、入力パラメータの標準偏差を超える付加的な実施のような付加的な実施を受ける（例えば、最大臨界因子を有する変更されたモジュールに対して、テスター又は自動試験システムは、少ない数の代わりに１０の異なる入力シナリオで実施を実行することができ、また、最も低い臨界因子を有するモジュールは、入力条件の単に１つのセットで試験されると考えられ、臨界因子を考慮しない入力パラメータシナリオの典型的な数は、例えば１、２、３、又は４であろう）。代替的に又はそれに加えて、フラグを立てられたモジュールは、あらゆる不要なリップル効果も存在しないことを検証するために、関連するテストケースに対するより高いレベルの従属関係及び依存関係が回帰試験で実行されるべきであることを示すことができる。

別の実施形態では、自動試験はまた、「追跡可能性行列」に表された関係がソフトウエアに行われた変更によって修正されなかったこと、又は追跡可能性行列に入力された更新された関係が実際に新しいソフトウエア関係の正確な表示であることを検証するために、「追跡可能性行列」内のデータを検証する段階を含むことができる。これは、例えば、ソフトウエアモジュールによって行われた呼出しをモニタする市販試験ソフトウエアで行うことができる。モジュールが「追跡可能性行列」に捕捉されていない関係のために呼び出される場合、又は「追跡可能性行列」の関係がソフトウエア呼出しを通じて識別されない場合、可能なエラーが識別され、報告され、更に監督者の注意を呼び起こすことができる。場合によっては、監督者は、入力パラメータ又は他の要因での条件が別のモジュールへのデータの呼出し又は転送を必要としなかったので、ソフトウエアの実行中に実際の既存の関係が表示されなかったことを認識又は判断することができる。「追跡可能性行列」の関係が呼出しモニタリングソフトウエアのレポートに基づいてエラーとして現れる場合、関係が間違って報告されたことを検証するために、一般的に更に別の調査が必要になる。関係が見逃された場合、別のモジュールへの呼出しの検出は、一般的には関係を肯定的に示すことになるが、この関係は、更に別の検証を必要とするエラーによるものである。このような自動及び人間の解析の結果は、ソフトウエア履歴記録に入力され、監査トレール又はトラブルシューティング機構を作成する。

回帰試験は、別の実施形態では、システムが大きなコンピュータの需要によって大きな負担を課せられる場合でも、ソフトウエアが適切に機能することを判断するためにストレス試験を含むことができる。ストレス試験のための様々なツールは、当業技術で公知であり、特に重要なコンポーネント（例えば、高い臨界パラメータを有するコンポーネント）が修正される場合に、複合ソフトウエアシステムの回帰試験での付加的な段階として適用することができる。

複合ソフトウエアシステムの開発、統合、及び／又は試験には、一般的に様々なグループにおける複数のプログラマーを必要とした。プログラマー及びグループ間の有効な通信は、目標とされるタスクを達成するための有効な相互作用に貴重なものになる。本明細書において引用により組み込まれている、Ｄｅｉｍｅｌ他によって２００４年４月８日に公開された米国特許公開２００４００６８７１４に開示された技術を含むあらゆる公知の方法を使用して、通信及び計画を強化することができる。Ｄｅｉｍｅｌ他は、異質ソフトウエアの集合のメッセージベースの交換及び統合のための交換インフラストラクチャーを開示している。交換インフラストラクチャーは、複数のソフトウエアコンポーネントの設計−時間協調性記述を記憶するためのリポジトリと、実行時システムランドスケープの構成特定の協調性記述を記憶するためのディレクトリとを含む。交換インフラストラクチャーは、構成特定の協調性記述に基づいて情報のメッセージベースの交換のために構成された実行時エンジンを更に含む。実行時に、実行時エンジンは、メッセージを受信し、ディレクトリからの構成特定の協調性記述によって提供されたメッセージコンテンツ及びパラメータに基づいて意図された又は要求された受信者を決定する。

他のソフトウエアシステム
多くの他のソフトウエアシステムは、ＳＡＰベースのシステム又は他のソフトウエアと統合させることなどによって複合ソフトウエアシステムに含むことができる。
単に一例として、本発明のツールを適用することができる複合ソフトウエアシステムは、取引相手関係管理（ＰＲＭ）及び従業員関係管理（ＥＲＭ）のためのアプリケーションを含む顧客関係管理（ＣＲＭ）のためのアプリケーションのあらゆる組を含むことができる。「Ｓｉｅｂｅｌ Ｓｙｓｔｅｍｓ、Ｉｎｃ．」（サンマテオ、カリフォルニア）によって販売されている１つのこのような例は、「Ｓｉｅｂｅｌ ７」であり、これは、顧客挙動及び協調性能の重要なインジケータの両方を追跡して理解するリアルタイムの解析機能を組織に提供するといわれている共通「ウェブ」アーキテクチャに基づく統合された一組である。アプリケーションを実行して修正する作業は、広範囲の試験を必要とし、これは、本発明の自動ツールによって容易にすることができる。

本発明のシステムはまた、イノベーション管理ツールを企業システムに統合するために使用することができる。例えば、イノベーション管理データベース、電子ノートブックシステム、プロジェクト追跡システム、企業内特許オフィスのための整理番号管理システム、特許データベース、及び発明開示データベースなどを本発明のツールを使用して試験されて実行される複合ソフトウエアシステムに一緒にすることができる。本発明を用いて試験することができるコンポーネントの１つの例は、Ｓ．Ｋｏｐｃｈａに２００４年１０月５日に付与された「分散型製品開発」という名称の米国特許第６，８０１，８１８号及びＬ．Ｊ．Ｈｕｇｈｅｓにより２００３年５月１５日に公開された「協調性及びイノベーションシステム」という名称の米国特許公開ＵＳ２００３００９３４７８Ａ１のイノベーション及び情報管理ツールである。

他の統合ソフトウエアシステムは、「Ｇｉｂｓｏｎ−Ｇｒａｖｅｓ Ｃｏｍｐａｎｙ、Ｉｎｃ．」の「ＴＲＡＱ−１品質データ管理システム」、「Ｍｕｒｐｈｙ Ｓｏｆｔｗａｒｅ」からの「ＤＢＱ（品質のためのデータベース）」銘柄コンピュータソフトウエア、及び他の品質管理システムのような市販品質管理ソフトウエアを含むことができる。「ＷＯＮＤＥＲＷＡＲＥ（登録商標）」ソフトウエア（「Ｗｏｎｄｅｒｗａｒｅ Ｃｏｒｐ．」、アーバイン、カルフォルニア）のような分散型管理システムを含めることもできる。複合ソフトウエアシステムはまた、購入、課金、財務管理、メンテナンス、法規制の遵守などのためのあらゆる公知のシステムを含むことができる。このようなシステムは、統合された複合ソフトウエアシステム内の相互に関連したソフトウエアモジュールの１つ又はそれよりも多くを含むことができる。
試験システムの機能性を拡張するか又はその一部分として機能するために本システムと組み合わせることができる他のシステムは、Ｊ．Ａ．ＭｃＦａｒｌａｎｄによって１９９７年３月４日に公開された「品質管理のためのシステム及び方法」という名称のＷＯ９７／１２３１１に説明されているＩＳＯ遵守のための文書化管理ツールを含む。

プロジェクトはまた、Ｒａｔｉｏｎａｌによる「Ｒｅｑｕｉｓｉｔｅ Ｐｒｏ」、「Ｔｅｌｅｌｏｇｉｃ Ｎｏｒｔｈ Ａｍｅｒｉｃａ、Ｉｎｃ．」（アーバイン、カリフォルニア）のＱＳＳによる「ＤＯＯＲＳ」（例えば、２００４年１０月７日付けで閲覧されるｈｔｔｐ：／／ｗｗｗ．ｔｅｌｅｌｏｇｉｃ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｄｏｏｒｓｅｒｓ／ｄｏｏｒｓ／ｉｎｄｅｘ．ｃｆｍに説明されているような「ＤＯＯＲＳ ７．１」）、及び「Ｓｅｒｅｎａ Ｓｏｆｔｗａｒｅ、Ｉｎｃ．」による「ＲＴＭ」（サンマテオ、カリフォルニア、２００４年１０月７日付けで閲覧されるｈｔｔｐ：／／ｗｗｗ．ｓｅｒｅｎａ．ｃｏｍ／Ｐｒｏｄｕｃｔｓ／ｒｔｍ／ｈｏｍｅ．ａｓｐを参照されたい）のような公知の要件管理（ＲＭ）ツール（例えば、Ｄｕｓｔｉｎ他の２０６−２１１ページを参照されたい）によって支援することができる。ＲＭツールは、ソフトウエア開発プロジェクトの要件を管理することを支援することができ、また、ビジネス目的が確実に満たされるのを支援することができる。「要件追跡可能性行列」（テストケース及び／又はソフトウエアモジュール間の関係を説明する本発明の「追跡可能性行列」と混同しないように）の自動作成は、例えば、各試験手順をそのそれぞれの試験要件とリンクさせるためにＤＯＯＲＳで行うことができる。

ＩＢＭの「Ｒａｔｉｏｎａｌ Ｒｏｓｅ」のようなビジュアルモデリングツールは、ソフトウエアシステムのアーチファクトを視覚化して文書化し、ソフトウエア構成のための青写真を提供するために使用することができる。ビジネス処理また、ソフトウエアアーキテクチャにマップすることができる。例えば、ｈｔｔｐ：／／ｗｗｗ−３０６．ｉｂｍ．ｃｏｍ／ｓｏｆｔｗａｒｅ／ａｗｄｔｏｏｌｓ／ｄｅｖｅｌｏｐｅｒ／ｄａｔａｍｏｄｅｌｅｒ／を参照されたい。

プログラム特定のタスクは、プログラムスライシングというプログラムの挙動を関連する特定の部分集合に制限するためのツールを含む公知のデバッグ及び解析ツールによって処理することができる。プログラムスライシングは、Ｋ．Ｂ．Ｇａｌｌａｇｈｅｒ及びＪ．Ｒ．Ｌｙｌｅ著「ソフトウエアメンテナンスにおけるプログラムスライシングの使用」、Ｓｈａｗｎ Ａ．Ｂｏｈｎｅｒ及びＲｏｂｅｒｔ Ｓ．Ａｒｎｏｌｄ編「ソフトウエア変化インパクト解析」（ロスアラミトス、カリフォルニア、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｐｒｅｓｓ、１９９６年、３１９−３２９ページ）に説明されている。本明細書において引用により組み込まれている、Ｓｈａｗｎ Ａ．Ｂｏｈｎｅｒ著「デザイン革命のためのソフトウエア変化インパクト解析」、ソフトウエア変化インパクト解析、６７−８１ページによって説明されるものを含むインパクト解析のためのツールを使用することもできる。Ｂｏｈｎｅｒ及びＡｒｎｏｌｄ著「入門ソフトウエア変化インパクト解析」、ソフトウエア変化インパクト解析、１−２６ページ（特に１５ページ）によって説明されている相互参照、試験範囲アナライザ、及びソースコードコンパレータのようなコンポーネント依存関係のためのツールも適用することができる。このような例は、Ｄ．Ｅ．Ｐｅｒｒｙ著「Ｉｎｓｃａｐｅ環境」、ソフトウエア工学のための国際会議紀要（ロスアラミトス、カリフォルニア、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｐｒｅｓｓ、１９８９年、２−１２ページ、Ｂｏｈｎｅｒ及びＡｒｎｏｌｄによって引用）によって説明されているような「Ｉｎｓｃａｐｅ」を含む。

矛盾しない範囲で本明細書において引用により組み込まれている、Ｓ．Ｎｅｈａｂによって２００４年５月２７日に公開された「企業ソフトウエアシステムの検証のためのシステム」という名称のＵＳ２００４０１０３３９６Ａ１に説明されているツールを含むテストケース又はスクリプトの作成を支援するためのあらゆる公知のツールを使用してもよい。Ｎｅｈａｂは、複合企業ソフトウエアシステムの自動検証のためのシステム及び方法を説明しており、これは、ビジネス処理仕様を使用して試験シナリオを作ることによって試験処理を改良するものである。

本発明による自動試験ツールは、キンバリー・クラークビジネス内のＳＡＰ統合の試験のために開発されたものである。このシステムは、情報の入力及び表示のための安全な「イントラネット」ページを使用する「ウェブ」ベースのものであった。「追跡可能性行列」をサポートするソフトウエアは、「ＲＤＢＭＳ ＳＱＬサーバ２０００」上に実装された。
「ウェブ」機能は、マークアップ言語としてＨＴＭＬ及びＸＭＬを使用して書き込まれた。表示された情報の管理のためのスタイル言語は、ＣＳＳ及びＸＳＬＴであった。スクリプト言語は、ＶＢＳｃｒｉｐｔ及びＪａｖａＳｃｒｉｐｔであった。ＡＳＰがサーバで実行され、リモートスクリプティングがクライアント機械によってトリガされてサーバ上で実行される、２層アーキテクチャが使用された。使用されたＴｏｏｌｓｅｔｓは、ＥＸＣＥＬ、「ＳＱＬ Ｑｕｅｒｙ」、Ａｃｃｅｓｓ、及び「Ｃｒｙｓｔａｌ Ｒｅｐｏｒｔｓ」を含んでいた。「解析ロードマップ」は、リンクリスト及び再帰を使用するハッシュ機能、及び３次元アレイで表示された行列を用いて実装された。リファレンス整合性は、依存関係及び従属関係の間で維持されていた。

解析ロードマップの構成詳細
２次元行列要素へのアクセスは、第１が行インデックスを表し、第２が列インデックスを表す２つのサブスクリプトで達成される。このようなアレイに関する基本的情報は、ｈｔｔｐ：／／ｗｗｗ．ｍａｔｈｗｏｒｋｓ．ｃｏｍ／ａｃｃｅｓｓ／ｈｅｌｐｄｅｓｋ／ｈｅｌｐ／ｔｅｃｈｄｏｃ／ｍａｔｌａｂ ｐｒｏｇ／ｃｈ１２ ｎｄ３．ｓｈｔｍｌで提供されている。
「解析ロードマップ」ダイアログボックスから選択されたテストケースを使用して、その依存関係は、記憶された手順の実行を通じてデータベースから検索され、「依存関係」というフィールドを収容する「依存関係アレイ」にマップされる。
「依存関係アレイ２次元行列」は、「依存関係（列，行）＝依存関係［親ケース］」という情報を収容する。

上と同じ手順を使用して、テストケース及びその依存関係従属関係の全ては、６レベルまで検索され、「レベル」、「依存関係」、「従属関係」、及び「子インジケータ」というフィールドを収容する従属関係アレイにマップされる。
「従属関係アレイ２次元行列」は、以下の情報を収容する。
従属関係（列，行）＝レベル ［次の６レベル］
従属関係（列，行）＝依存関係 ［親ケース］
従属関係（列，行）＝従属関係 ［子ケース］
従属関係（列，行）＝子インジケータ［０−偽：１−真］

ハッシュは、キー値を使用して迅速にデータにアクセスするための効率的な手段である。入力が与えられると、ハッシュ機能は、これを操作して固有の出力を生成する。入力されたキーはハッシュされ、結果の出力は、関連した値を見つける場所をプログラムに告げるハッシュテーブルの固有のインデックス数である。１つよりも多いインデックスが各キーに関連付けられる場合、結果は衝突である。これは、チェーニングと呼ばれる技術で処理され、これは、データがノードに記憶され、ノードがハッシュテーブルのエントリから繋がれるものである。これは、リンクしたリストで達成される。
衝突を処理するためのリンクしたリストを備えたハッシュテーブルの使用の詳細は、ｈｔｔｐ：／／ｅｐａｐｅｒｐｒｅｓｓ．ｃｏｍ／ｖｂｈａｓｈ／ｉｎｄｅｘ．ｈｔｍｌで与えられ、当業者には公知である。

「従属関係アレイ」を構成する際には、従属関係は、一度に１レベル検索される。二重のエントリを防ぐために、各親ケースはハッシュされ、ノードに入力される。子ケースが検索される前に、親ケースはハッシュされ、１つ又はそれよりも多くのノードがサーチされる。親ケースが見つけられた場合、その親ケースに対する従属関係を検索する必要はないが、見つけられなかった場合は従属関係が検索される。

多次元アレイは、インデックス付けのための付加的なサブスクリプトを使用する。３次元アレイは、例えば３つのサブスクリプトを使用する。
・第１リファレンスアレイ次元１、行
・第２リファレンス次元２、列
・第３リファレンス次元３、ページ
本発明のソフトウエアの開発に有益な３次元行列の使用に関する詳細は、ｈｔｔｐ：／／ｗｗｗ．ｍａｔｈｗｏｒｋｓ．ｃｏｍ／ａｃｃｅｓｓ／ｈｅｌｐｄｅｓｋ／ｈｅｌｐ／ｔｅｃｈｄｏｃ／ｍａｔｌａｂ ｐｒｏｇ／ｃｈ１２ ｎｄ３．ｓｈｔｍｌで与えられている。

「従属関係アレイ」を使用して、スケジューリング情報は、「解析ロードマップ」ダイアログボックスから選択された試験サイクルに従って、記憶された手順の実行を通じてデータベースから検索される。処理及び子インジケータが設定され、全てが、以下のフィールドを収容する「ツリーアレイ」にマップされる。
・親ケース、子ケース、子記述
・論理的削除インジケータ、実行日付、実行インジケータ
・リファレンスフィールド１、リファレンスフィールド２、リファレンスフィールド３
・子インジケータ、処理済みインジケータ

「ツリーアレイ３次元行列」は、以下の情報を収容する。
ツリーアレイ（列、行、ページ）＝親ケース
ツリーアレイ（列、行、ページ）＝子ケース
ツリーアレイ（列、行、ページ）＝子記述
ツリーアレイ（列、行、ページ）＝論理的削除インジケータ
ツリーアレイ（列、行、ページ）＝実行日付
ツリーアレイ（列、行、ページ）＝実行インジケータ
ツリーアレイ（列、行、ページ）＝リファレンスフィールド１
ツリーアレイ（列、行、ページ）＝リファレンスフィールド２
ツリーアレイ（列、行、ページ）＝リファレンスフィールド３
ツリーアレイ（列、行、ページ）＝子インジケータ
ツリーアレイ（列、行、ページ）＝処理済みインジケータ
本発明の自動ツールで用いられるＸＭＬ要素を以下の表１に示す。

「ツリーアレイ」を使用して、ＸＭＬファイルは、２つの再帰的方法により、つまり、一方は、＜ｃｈｉｌｄｒｅｎ＞タグを通じてルート要素（＜ｔｒｅｅ＞）及び他のキー要素にキーを追加すること、及び他方は、要求された終了＜／ｃｈｉｌｄｒｅｎ＞、＜／ｋｅｙ＞、及び＜／ｔｒｅｅ＞タグでキーを閉じることにより構成される。
実施例１の作業に関係するＸＭＬファイルの例示的な構造を表２に示す。

表２．例示的なＸＭＬファイルの一部分

ＸＭＬは、ツリーデザインに従っており、従って、ＸＭＬ文書がブラウザに固有のＸＭＬパーサーによって構文解析された状態で、表３に示すようなソースツリーが生成される。

表３．ＸＭＬソースツリー

しかし、ＸＳＬＴで表された変換は、ソースツリーを結果ツリーに変換するための規則を説明するものである。変換は、パターンにテンプレートを関連付けることによって達成される。パターンは、ソースツリー内の要素に対して比較される。テンプレートは、結果ツリーの一部を作成するためにインスタンス化される。結果ツリーは、ソースツリーとは別々のものである。結果ツリーの構造は、ソースツリーの構造とは完全に異なるものになる可能性がある。結果ツリーを構成する際には、ソースツリーからの要素は、フィルタに掛けて再順序付けすることができ、任意の構造を追加することができる。ＸＳＬＴで表された変換は、スタイルシートと呼ばれる。これは、ＸＳＬＴがＸＳＬフォーマット化語彙に変換される場合に、その変換がスタイルシートとして機能するからである。
この段階の例示的な結果ツリーは、図１０に示されている。

本発明の試験ツール、方法、及び他の実施形態をその特定の態様に関して詳しく説明したが、当業者は、以上の理解に到達すると、これらの試験ツール及び方法に対する変更、その変形、及びそれに対する均等物を容易に考えることができることが認められるであろう。従って、本発明の範囲は、特許請求の範囲及びそのあらゆる均等物の範囲として判断されるべきである。

本発明の「自動多次元追跡可能性行列」の記録を典型的に表す図である。 本発明の「自動多次元追跡可能性行列」の記録を典型的に表す図である。 本発明の「自動多次元追跡可能性行列」の記録を典型的に表す図である。 例示的な「テストケースカタログリスト」のスクリーンショットを典型的に示す図である。 例示的な「テストケースカタログメンテナンス形式」のスクリーンショットを典型的に示す図である。 例示的な「テストケース特性リスト」のスクリーンショットを典型的に示す図である。 例示的な「ケース特性メンテナンス形式」のスクリーンショットを典型的に示す図である。 例示的な「トランザクションメンテナンス形式」のスクリーンショットを典型的に示す図である。 展開又は開かれた「割り当てられたケース」情報の例示的な図のスクリーンショットを典型的に示す図である。 図３のスクリーンショットに関連したスクリーンショットを典型的に示し、オペレータが解析アイコン上をクリックした時に表示されるダイアログボックスを示す図である。 例示的な「解析ロードマップ」のスクリーンショットを典型的に示す図である。 図１Ｃに示す「自動多次元追跡可能性行列」情報に対する「解析ロードマップ」のスクリーンショットを典型的に示す図である。 例示的な「エンティティ関係ダイアグラム」を典型的に示す図である。 本発明の「自動多次元追跡可能性行列」を使用する方法に対する例示的な流れ図を典型的に示す図である。 本発明の「自動多次元追跡可能性行列」を使用する方法の例示的な流れ図を典型的に示す図である。 本発明の「自動多次元追跡可能性行列」を使用する方法の例示的な流れ図を典型的に示す図である。 本発明の「自動多次元追跡可能性行列」を使用する方法の例示的な流れ図を典型的に示す図である。 複合ソフトウエアシステムに対して回帰試験を行う例示的な方法を典型的に示す図である。 本発明の「自動多次元追跡可能性行列」で複合ソフトウエアシステムを試験する方法の例示的な流れ図を典型的に示す図である。

符号の説明

１００ 「自動多次元追跡可能性行列」の記録
１１１、１２１、１３１、１４１、１５１ アイデンティティフィールド
１１３、１２３、１３３、１４３、１５３ 依存関係フィールド
１１４、１２４、１３４、１４４、１５４ 従属関係フィールド

Claims (54)

1. 複数の相互に関連するシステムコンポーネントと該複数の相互に関連するシステムコンポーネントの性能を試験するための一組の試験シナリオとを有する複合ソフトウエアシステムの試験のための試験ツールであって、
   ａ）相互に関連するシステムコンポーネント間のリンケージを判断するための「自動多次元追跡可能性行列」システムと、
   ｂ）前記相互に関連するシステムコンポーネントの１つ又はそれよりも多くにおける変更を識別するための手段と、
   ｃ）前記「自動多次元追跡可能性行列」を適用するための手段と、
   ｄ）前記変更によって影響を受ける場合がある前記相互に関連するシステムコンポーネントに関連した前記試験シナリオの全て又はその部分集合を実行するための手段と、
   ｅ）前記実行された試験シナリオの結果を評価するための手段と、
   を含むことを特徴とする試験ツール。
2. 前記相互に関連するシステムコンポーネントの１つ又はそれよりも多くにおける変更を識別するための手段は、実行可能ファイルの変更を検出する電子ツールを含むことを特徴とする請求項１に記載の試験ツール。
3. 前記相互に関連するシステムコンポーネントの１つ又はそれよりも多くにおける変更を識別するための手段は、該変更に関する情報の手動入力を含むことを特徴とする請求項１に記載の試験ツール。
4. 前記実行された試験シナリオの結果を評価するための手段は、出力情報と、前記変更の前に該試験シナリオから既に作成されていた出力情報との手動比較を含むことを特徴とする請求項１に記載の試験ツール。
5. 前記実行された試験シナリオの結果を評価するための手段は、出力情報と、前記変更の前に該試験シナリオから既に作成されていた出力情報とのコンピュータ実行比較を含むことを特徴とする請求項１に記載の試験ツール。
6. 「ＳＡＰ Ｒ／３」を実行するようになっており、
   選択されたスクリプトを自動的に実行する「コンピュータ支援試験ツール」を更に含む、
   ことを特徴とする請求項１に記載の試験ツール。
7. 前記複合ソフトウエアシステムは、少なくとも１つの他の当事者によって書かれたレガシーソフトウエアにインタフェースで接続する少なくとも１つの供給業者からのソフトウエアを含むことを特徴とする請求項１に記載の試験ツール。
8. 前記複合ソフトウエアシステムは、ＥＲＰシステムであることを特徴とする請求項１に記載の試験ツール。
9. ソフトウエア及び該ソフトウエアに関連した文書化の変更を監査するための手段を更に含むことを特徴とする請求項１に記載の試験ツール。
10. 前記「自動多次元追跡可能性行列」を適用するための手段は、選択されたテストケースと他のテストケースへのリンケージの図形表示とに関する情報を図式的に表示するグラフィカルユーザインタフェースを含み、
    前記グラフィカルユーザインタフェースは、依存関係及び従属関係の少なくとも一方を通じて２つ又はそれよりも多くのレベルによってリンクした他のケースを表示するようになっている、
    ことを特徴とする請求項１に記載の試験ツール。
11. 前記グラフィカルユーザインタフェースは、前記表示されたテストケースが試験するソフトウエアモジュールに関する情報を提供するために、該表示されたテストケースのためのハイパーリンクを特徴とする「ウェブ」ベースのディスプレイを含むことを特徴とする請求項１０に記載の試験ツール。
12. 複合ソフトウエアシステムの統合試験又はシステム試験の少なくとも一方に対して、対応するソフトウエアコンポーネントを試験するための関連のテストケースの実行を案内するようになった試験スクリプトの本体から試験スクリプトの部分集合を自動的に選択するための試験ツールであって、
    ａ）「自動多次元追跡可能性行列」システムと、
    ｂ）テストケース間のリンケージに関する情報を受信し、該情報を前記「自動多次元追跡可能性行列」システムに供給するためのグラフィカルユーザインタフェースと、
    ｃ）前記「自動多次元追跡可能性行列」システム内の前記情報に基づいて自動的に判断される複数のレベルでのテストケース間の親−子関係を図式的に表示するための手段と、
    ｄ）前記複合ソフトウエアシステムの前記テストケースの１つ又はそれよりも多くにおける変更に応じて、該複合ソフトウエアシステム内の複数のコンポーネントの試験のために該テストケースの部分集合を選択するための手段と、
    ｅ）前記テストケースの部分集合に関連した試験スクリプトを実行するための手段と、
    ｆ）前記実行された試験スクリプトによって作成された出力に基づいて、前記複合ソフトウエアシステムのステータスを評価するための手段と、
    を含むことを特徴とする試験ツール。
13. 複数の相互に関連するプログラムと該複数の相互に関連するプログラムの性能を試験するための一組のテストケースとを有する複合システムソフトウエアシステムの試験における効率の改善のためのグラフィカルユーザインタフェースであって、
    ａ）複数の相互に関連するプログラムの選択された部分間のリンケージに関する「自動多次元追跡可能性行列」からの出力情報を表示するための手段、
    を含み、
    前記手段は、依存関係の３つ又はそれよりも多くのレベルにわたるリンケージを表示するようになっており、
    前記出力情報は、
    １）前記選択されたプログラムに対する依存関係及び従属関係のリスト、及び
    ２）前記選択されたプログラムを呼び出すことができるテストケースのリスト、
    の少なくとも一方を含み、
    ｂ）複数の相互に関連するプログラムの選択された部分間のリンケージに関する前記「自動多次元追跡可能性行列」からの入力情報を受信するための手段と、
    ｃ）前記グラフィカルユーザインタフェースから前記「自動多次元追跡可能性行列」をホストする少なくとも１つのサーバに入力及び出力情報を通すための通信手段と、
    を更に含むことを特徴とするグラフィカルユーザインタフェース。
14. 複数のソフトウエアコンポーネントを含む複合ソフトウエアシステムの性能を効率的に試験するためにテストケースの本体からテストケースの部分集合を自動的に選択する方法を実行するコンピュータシステムを制御するための命令を収容するコンピュータ可読媒体であって、
    各テストケースは、前記複合ソフトウエアシステム内の少なくとも１つのソフトウエアコンポーネントに関連付けられており、
    各テストケースはまた、該テストケースに対して前記複合ソフトウエアシステムによって実行される一連の命令を提供するスクリプトに関連付けられており、
    前記方法は、
    ａ）前記テストケースに対する依存関係及び従属関係に関する入力情報を受信するグラフィカルユーザインタフェースを表示する段階と、
    ｂ）「自動多次元追跡可能性行列」に関連するデータベースに前記入力情報を記憶する段階と、
    ｃ）前記ソフトウエアコンポーネントの１つ又はそれよりも多くが変更されたことを示す変更通知を受信する段階と、
    ｄ）既に形成されているリンケージを通じて前記１つ又はそれよりも多くの変更されたソフトウエアコンポーネントへ前記テストケースのどれがリンクされるかを判断するために前記「自動多次元追跡可能性行列」を適用する段階と、
    ｅ）前記１つ又はそれよりも多くの変更されたソフトウエアコンポーネントへどのテストケースがリンクされるかを示す情報を表示する段階と、
    ｆ）自動的に又はユーザ選択に応じて、段階（ｅ）から前記リンクしたテストケースの全て又はその部分集合を選択する段階と、
    ｇ）段階（ｆ）からの前記選択されたリンクしたテストケースに関連する前記スクリプトを実行する段階と、
    ｈ）前記実行された試験スクリプトに対する予想結果と後で比較するために、該実行された試験スクリプトの結果を記憶する段階と、
    を含む、
    ことを特徴とするコンピュータ可読媒体。
15. 前記方法が、前記１つ又はそれよりも多くの変更されたソフトウエアコンポーネントへどのテストケースがリンクされるかを示す情報を表示する前記段階は、３つ又はそれよりも多くのレベルにわたるリンケージに関する情報を表示する段階を更に含むことを特徴とする請求項１４に記載のコンピュータ可読媒体。
16. 前記方法が、前記１つ又はそれよりも多くの変更されたソフトウエアコンポーネントへどのテストケースがリンクされるかを示す情報を表示する前記段階は、第１の数の依存関係レベルと該第１の数よりも大きい第２の数の従属関係レベルとに関する情報を表示する段階を更に含むことを特徴とする請求項１４に記載のコンピュータ可読媒体。
17. １つ又はそれよりも多くの供給業者によって提供された複数の統合されたソフトウエアモジュールを含む複合ソフトウエアシステムのための更新されたソフトウエアモジュールをユーザが試験する方法であって、
    ａ）供給業者から第１ソフトウエアモジュールのためのソフトウエア更新を受信する段階と、
    ｂ）複合ソフトウエアシステムに更新された第１ソフトウエアモジュールを提供するために、サーバ上に前記ソフトウエア更新をインストールする段階と、
    ｃ）性能が前記更新された第１ソフトウエアモジュールにリンクされる前記複数のソフトウエアモジュールからのソフトウエアモジュールのリスト、又は性能が該更新された第１ソフトウエアモジュールにリンクされる該ソフトウエアモジュールに関連するテストケースのリストを自動的に作成するために「自動多次元追跡可能性行列」を適用する段階と、
    ｄ）段階（ｃ）における前記リストの部分集合を選択し、関連する試験スクリプトを実行する段階と、
    ｅ）前記複合ソフトウエアシステムが適正に機能しているかを判断するために、前記実行された関連の試験スクリプトの結果を評価する段階と、
    を含むことを特徴とする方法。
18. コンピュータと、
    前記コンピュータによって提供される情報を表示するための視覚的表示装置と、
    開発中のソフトウエアシステムに関連するコンポーネント間のリンケージを説明するための前記コンピュータに付随する「自動多次元追跡可能性行列」データベースと、
    を含み、
    前記コンポーネントは、各々がプログラムモジュールを該プログラムモジュールと該プログラムモジュールに付随する目標の機能性を説明する１つ又はそれよりも多くのビジネス文書とを呼び出す１つ又はそれよりも多くのテストケースにリンクする複数の関連付を含み、
    ユーザが、プログラムモジュール、テストケース、及び前記データベース内で参照されるビジネス文書のうちの望ましいいずれか１つを選択することを可能にするものであり、その選択に応じて、前記視覚表示装置の表示が修正されて該選択に関する情報が提供され、
    前記選択にリンクされた他のプログラムモジュール、テストケース、及びビジネス文書のいずれに関する情報も表示するための付加的な選択手段を含む、
    ことを特徴とするグラフィカルユーザインタフェース。
19. 前記選択がテストケースである時に、前記選択にリンクされた他のプログラムモジュール、テストケース、及びビジネス文書のいずれに関する前記情報も、該テストケースよって呼び出される該プログラムモジュールとビジネス文書とを含み、該ビジネス文書は、該ビジネス文書によって説明された処理又は特徴を試験するために実行されるケースとして該テストケースを列挙することを特徴とする請求項１８に記載のグラフィカルユーザインタフェース。
20. 前記選択がプログラムモジュールである時に、前記選択にリンクされた他のプログラムモジュール、テストケース、及びビジネス文書のいずれに関する前記情報も、プログラムと該プログラムモジュールによってサポートされた処理又は特徴を説明するビジネス文書とを呼び出す１つ又はそれよりも多くのテストケースを含むことを特徴とする請求項１８に記載のグラフィカルユーザインタフェース。
21. 前記選択がビジネス文書である時に、前記選択にリンクされた他のプログラムモジュール、テストケース、及びビジネス文書のいずれの前記情報も、該ビジネス文書に説明された処理又は特徴の試験を支援する１つ又はそれよりも多くのテストケースと、該１つ又はそれよりも多くのテストケースによって呼び出された１つ又はそれよりも多くのプログラムモジュールとを含むことを特徴とする請求項１８に記載のグラフィカルユーザインタフェース。
22. 前記ビジネス文書が電子文書である時に、該電子文書は、該ビジネス文書に説明された処理又は特徴の試験を支援する全てのテストケースへの電子リンクを提供することを特徴とする請求項２１に記載のグラフィカルユーザインタフェース。
23. 「自動多次元追跡可能性行列」に関連した複数のソフトウエアモジュールと試験のための複数のテストケースとを含む既存の複合ソフトウエアシステムの変更に応じて、複数のテスターによって連続的に実行されるソフトウエア試験タスクを計画する方法であって、
    ａ）複合ソフトウエアシステムの変更によって修正されたソフトウエアモジュールを識別する段階と、
    ｂ）前記複合ソフトウエアシステムの以前に試験した機能性がまだ適正に作動することを検証するために試験されるテストケースの選択を識別する「自動多次元追跡可能性行列」を使用する段階と、
    ｃ）連続的実行を要求するテストケースの前記選択内の全てのテストケースに対して実行の連続的順番を特定する段階と、
    ｄ）前記テストケースの前記実行を支援するために前記複数のテスターからテスターを特定する段階と、
    ｅ）前記実行の連続的順番で前記テストケースを開始する段階と、
    ｆ）手動実行を要求するテストケースが実行されるのを待っていることをコンピュータ作成信号で前記テスターに通知する段階と、
    を含むことを特徴とする方法。
24. 前記複合ソフトウエアシステムの前記変更は、新しい機能性の追加を含み、
    既存のテストケースでは試験することができない前記ソフトウエア変更によってもたらされた前記追加の機能性を試験する段階、
    を更に含むことを特徴とする請求項２３に記載の方法。
25. 前記複合ソフトウエアシステムの性能の意図した変更を網羅する少なくとも１つの新しいテストケースを作成する段階と、前記「自動多次元追跡可能性行列」を更新する段階とを更に含むことを特徴とする請求項２３に記載の方法。
26. 複数の相互に関連するソフトウエアモジュールを含み、その各々が依存及び従属関係を含む該モジュール間の関係を追跡するための「自動追跡可能性行列」に関連付けられた複合ソフトウエアシステムにおいて、修正されるモジュールの２つ又はそれよりも多くの代替的な部分集合の間で選択を行うことができる時に、特定の目的を達成するために修正するソフトウエアモジュールの選択を改良する方法であって、
    （ａ）修正のために部分集合が選択される相互に関連するソフトウエアモジュールの２つ又はそれよりも多くの部分集合を識別する段階と、
    （ｂ）回帰試験の範囲を判断するために前記部分集合に対して前記「自動追跡可能性行列」を適用する段階と、
    （ｃ）特定の目的を達成するために修正する部分集合を選択する段階と、
    （ｄ）前記選択された部分集合を修正する段階と、
    （ｅ）前記特定の目的が達成されたことを検証する段階と、
    を含むことを特徴とする方法。
27. ソフトウエアモジュールの前記２つ又はそれよりも多くの部分集合の少なくとも１つは、１つのソフトウエアモジュールで構成されていることを特徴とする請求項２６に記載の方法。
28. 前記複合ソフトウエアシステムの性能が前記選択された部分集合の前記修正後も維持されていることを検証するために回帰試験を行う段階を更に含むことを特徴とする請求項２６に記載の方法。
29. 複数の相互に関連するソフトウエアモジュールを含み、各モジュールが該ソフトウエアモジュールの性能を試験するための１つ又はそれよりも多くの相互に関連するテストケースに関連付けられた複合ソフトウエアシステムを修正する方法であって、
    ａ）依存及び従属関係を含む相互に関連するテストケース間の関係を電子的に識別する「自動多次元追跡可能性行列」を作成する段階、
    を含み、
    前記「自動多次元追跡可能性行列」内の各テストケースは、関連付けられたソフトウエアモジュールに関する情報にリンクされており、
    ｂ）所定の入力データと複数のテストケースの実行を指示する１つ又はそれよりも多くのスクリプトとを含む１つ又はそれよりも多くの試験シナリオに従って、複合ソフトウエアシステムに関連した前記相互に関連するテストケースの全て又はその部分集合に対して性能結果のベースラインを作成する段階と、
    ｃ）前記ソフトウエアモジュールの１つ又はそれよりも多くにおける変更を作成する段階と、
    ｄ）前記複合ソフトウエアシステムの試験のための前記テストケースの部分集合を選択する段階と、
    を更に含み、
    選択する段階は、前記「自動多次元追跡可能性行列」からの情報に基づいて対話式「解析ロードマップ」の支援によって行われ、該「解析ロードマップ」は、前記相互に関連するコンポーネントのどれが前記変更によって影響を受ける場合があるかを識別する図式又は文字表示を提供するものであり、
    ｅ）一組の変更後の結果を提供するために、該変更によって影響を受ける場合がある前記相互に関連するコンポーネントに関連する１つ又はそれよりも多くの試験シナリオの全て又はその部分集合を実行する段階と、
    ｆ）以前に設定された機能性がまだ許容可能であるかを判断するために、前記変更後の結果を性能結果の前記ベースラインの対応する部分と比較する段階と、
    を更に含むことを特徴とする方法。
30. 前記１つ又はそれよりも多くの変更されたソフトウエアモジュールの元のバージョンを含む複合ソフトウエアシステムを別々に実行する複数のサーバが存在し、
    前記１つ又はそれよりも多くの変更されたソフトウエアモジュールの変更バージョンで前記元のバージョンを更新する段階、
    を更に含むことを特徴とする請求項２９に記載の方法。
31. 前記更新する段階は、パッチを作成する段階と、該パッチを前記複数のサーバ上で実行する段階とを更に含むことを特徴とする請求項３０に記載の方法。
32. １つ又はそれよりも多くの試験シナリオの全て又はその部分集合を実行する前記段階は、該１つ又はそれよりも多くの試験シナリオが完了するまで、（１）シナリオ内の前記テストケースの部分集合の実行、及び（２）段階（ｅ）を反復して行う段階を更に含むことを特徴とする請求項２９に記載の方法。
33. 前記試験及び前記ソフトウエアの変更に関する情報は、「管理エンティティ」を用いて保存されることを特徴とする請求項２９に記載の方法。
34. 前記ソフトウエアの前記変更に応じて前記「自動追跡可能性行列」を更新する必要があるかを判断する段階と、そうである場合に前記複合ソフトウエアシステムの試験のための前記テストケースの部分集合を選択する前に該「自動追跡可能性行列」を更新する段階とを更に含むことを特徴とする請求項２９に記載の方法。
35. 前記選択されたテストケースの少なくとも一部分の試験は、自動試験ツールで行われることを特徴とする請求項２９に記載の方法。
36. 前記選択されたテストケースで使用される入力データ内の少なくとも１つのパラメータは、前記試験の実行中に複数の値の間で自動的に変えられることを特徴とする請求項３５に記載の方法。
37. 搬送波に組み込まれたコンピュータデータ信号であって、
    複合ソフトウエアシステム内の複数のソフトウエアモジュールの少なくとも１つと、複合ソフトウエアシステム内の相互に関連するソフトウエアモジュールの回帰試験のための複数のコンピュータ実装テストケースとの間の従属関係及び依存関係を形成する情報と、
    前記従属関係及び前記依存関係に関する情報を図式的に伝達するためのコンピュータシステムに対する命令と、
    を含み、
    個々のテストケース又はソフトウエアモジュールは、互いに対するそれらの関係を示す方法で表示され、
    前記表示された情報は、他のテストケース又はソフトウエアモジュールのどれが変更によって影響を受ける場合があるかを示すことができ、
    グラフィカルユーザインタフェースに対するユーザアクションに関連した所定のユーザアクションに応じて、選択された個々のテストケース又はソフトウエアモジュールに関する付加的な情報を表示するための命令と、
    次の試験のために前記グラフィカルユーザインタフェース上の前記伝達された情報からテストケース又はソフトウエアモジュールを電子的に選択するための手段を提供する命令と、
    を更に含むことを特徴とするコンピュータデータ信号。
38. 入力データセット、関連のテストケース、及び確認された出力結果の所定の集合からのベースライン情報を更に含むことを特徴とする請求項３７に記載のコンピュータデータ信号。
39. 前記選択されたテストケース又はソフトウエアモジュールの手動又は自動実行を開始するための命令と、該実行されたテストケース又はソフトウエアモジュールからの出力結果を電子的に記憶するための命令とを更に含むことを特徴とする請求項３８に記載のコンピュータデータ信号。
40. 前記出力結果を前記ベースライン情報と比較するための命令を更に含むことを特徴とする請求項３９に記載のコンピュータデータ信号。
41. 前記出力結果と前記ベースライン情報の間の相違を自動的に識別するための命令と、該相違を是正するための１つ又はそれよりも多くの推奨されるアクションを自動的に識別するための命令とを更に含むことを特徴とする請求項４０に記載のコンピュータデータ信号。
42. 前記出力結果と前記ベースライン情報の間の日付特定の相違を除去するための命令を更に含むことを特徴とする請求項４１に記載のコンピュータデータ信号。
43. 前記相違の原因を特定するコンピュータ化されたデバッグツールを実行するための命令を更に含むことを特徴とする請求項４１に記載のコンピュータデータ信号。
44. 複数の人間テスターと、次の試験のために前記グラフィカルユーザインタフェース上の前記伝達された情報からユーザがテストケース又はソフトウエアモジュールを選択することに応じて該テスターの１人又はそれよりも多くによる試験作業を計画するための命令とに関する情報を更に含むことを特徴とする請求項３７に記載のコンピュータデータ信号。
45. 前記複合ソフトウエアシステム内の前記複数のソフトウエアモジュールの少なくとも１つと前記複数のコンピュータ実装テストケースの間の前記従属関係及び依存関係を形成する前記情報をユーザに修正させるための命令を更に含むことを特徴とする請求項３７に記載のコンピュータデータ信号。
46. 試験活動及びソフトウエア修正を説明する情報が「管理エンティティ」に提供されるように該「管理エンティティ」と通信するための命令を更に含み、
    前記ソフトウエアモジュールの変更を行う前にユーザに前記「管理エンティティ」に関連したエージェントから許可を取得するように要求する命令を更に含み、
    前記許可の取得もまた、前記「管理エンティティ」を用いて記録される、
    ことを特徴とする請求項３７に記載のコンピュータデータ信号。
47. 前記選択されたテストケース又はソフトウエアモジュールの１つ又はそれよりも多くの自動実行のための命令を更に含むことを特徴とする請求項３７に記載のコンピュータデータ信号。
48. 前記複合ソフトウエアシステムは、２つ又はそれよりも多くの供給業者によって提供された１００を超えるソフトウエアモジュールを含むことを特徴とする請求項３７に記載のコンピュータデータ信号。
49. 前記複合ソフトウエアシステムは、３つ又はそれよりも多くの供給業者によって提供された５００を超えるソフトウエアモジュールを含むことを特徴とする請求項３７に記載のコンピュータデータ信号。
50. 前記複合ソフトウエアシステムは、２つ又はそれよりも多くのサーバ上にある２つ又はそれよりも多くの供給業者からの２つ又はそれよりも多くの個別のコンピュータオペレーティングシステムとのインタフェースを含むことを特徴とする請求項３７に記載のコンピュータデータ信号。
51. 前記複合ソフトウエアシステムは、ＳＡＰソフトウエアを含むことを特徴とする請求項３７に記載のコンピュータデータ信号。
52. 前記従属関係及び依存関係に関する前記図式的に伝達された情報は、階層形式で提供されることを特徴とする請求項３７に記載のコンピュータデータ信号。
53. 前記従属関係及び依存関係に関する前記図式的に伝達された情報は、フォルダアイコン、文書アイコン、「プラス」記号付きアイコン、「マイナス」記号付きアイコン、ページアイコン、及び矢印アイコンのうちの少なくとも１つを含む階層形式で提供されることを特徴とする請求項３７に記載のコンピュータデータ信号。
54. 前記図式的に伝達された情報は、選択されたテストケース又はソフトウエアモジュールに関する付加的な情報を提供するためのハイパーリンクを更に含むことを特徴とする請求項５３に記載のコンピュータデータ信号。

Images