アプリケーション互換性のテスト計画の作成

必要な予備情報を収集し、全体的なプロジェクト計画を定義したら、アプリケーション互換性のテスト計画の定義を始めることができます。アプリケーション互換性のテスト計画には、テストのスコープと目標、テストに必要なハードウェアとソフトウェアの要件、問題追跡の手順、テストのスケジュールなど、標準的なテスト計画で通常対処する項目をすべて指定する必要があります。これらの項目のほとんどは、このガイドで既に説明しています。この情報に基づいて、アプリケーション互換性のテスト計画を作成することができます。

また、アプリケーション互換性のテスト計画では、次の作業も必要です。

• テスト方法の定義

• テストが必要なアプリケーションの特定

図 4 は、これらの作業がアプリケーション互換性テスト プロセスでいつ実行されるかを示しています。

図 4. アプリケーションテスト計画の作成
フル サイズのイメージを確認する

プロジェクトのこのフェーズでは、次の点を考慮してください。

• スコープと目標　テストで指定する優先順位のレベルを定義します。多数のアプリケーションを使用する組織では、すべてのアプリケーションを詳しくテストする時間がない可能性があります。最も優先順位が高く、最も頻繁に、または広く使用されているアプリケーションを最初にテストします。サーバー ベースのアプリケーションとクライアント ベースのアプリケーションの両方をテストしてください。クライアント ベースのアプリケーションは数が多いので、通常はテストが最も難しく、時間がかかります。

• テスト方法　テストの実行者と、関係者がどのようにテストにかかわるかを定義します。テスト方法を計画するときは、次の点を考慮してください。

  • どこでテストを行うか。

  • だれがテストを行うか。

  • 関係者とどのようにコミュニケーションをとるか。また、関係者がどのようにテストにかかわるか。

  • テストのスケジュールをどのように設定するか。

  • アプリケーションの問題をどのように管理するか。

    アプリケーションのテスト実施者のグループが組織に存在する場合は、そのグループを活用します。そのようなグループが存在しない場合は、妥当な時間内で最高の結果を達成する各種リソースを活用する方法を検討します。

    たとえば、数人の経験豊富なテスト実施者が一連のテスト項目を作成し、それらを実行できるように他のメンバをトレーニングします。また、経験豊富なテスト実施者がテストの中心となる部分を実行してから、各部門の専門家をラボに呼んで、実際の業務で使用する機能を実行してもらうこともできます。

    テストの実施日のスケジュール設定やテスト実施者とのコミュニケーションのプロセスも決定します。たとえば、イントラネットに Web サイトをセットアップし、テストの実施日、ステータス レポート、連絡先、およびその他の関連ドキュメントをだれでも参照できるようにすることができます。

  
  

• 必要なリソース　テストに必要となるハードウェア、ソフトウェア、要員、トレーニング、およびツールを定義します。アプリケーション互換性テストを計画するときは、将来のコンピュータ環境の状態を考慮する必要があります。現在のソフトウェアのいくつかを、Windows の新機能をフルに活用できるバージョンにアップグレードする計画はありますか。また、新しい標準デスクトップ構成を実装したり、ターミナル サービスを使用したりする計画はありませんか。

  必要なリソースや、どのアプリケーションをまとめてテストするかは、これらの状況に応じて変わります。ロールアウト中に、Windows と共に新しいアプリケーションを展開する計画がある場合は、現在のオペレーティング システムでもそれらのアプリケーションについて同様のテストを行います。テスト実施者がテストを行うためのラボを構築しておくと、テストを容易に進めることができます。そのようなラボでは、必要なツールや機器を常に使用可能な状態にしておくことができます。テスト実施者がコンピュータを簡単に元の状態に戻せるようにするには、基本オペレーティング システムが存在するドライブのディスク イメージを作成しておきます。

• 合否基準　アプリケーションがテストに合格か不合格かを判断するための要因を定義します。解決する必要のあるアプリケーションの問題を、いつどこに記録すべきかをテスト実施者がわかるようにするための手順を決定します。合否基準を定義するには、次の点を考慮してください。

  • 問題はどのくらい重大か。この問題が影響を与えるのは重要な機能かどうか。

  • この問題が発生する可能性はどの程度か。

  • この問題の回避策はあるか。

  
  

• スケジュール　スケジュール設定されたロールアウトの日までに、どのようにしてテストを完了させるかを定義します。テスト スケジュールは、次に示すさまざまな条件によって異なります。

  • 参加できるテスト実施者の人数

  • テスト実施者が関与するレベル

  • テスト実施者の経験

  
  

トピック

役割と責任の範囲
テスト方法の定義
テスト対象のアプリケーションの特定
マイルストーン : アプリケーション互換性のテスト計画の承認
アプリケーション テストのための準備
役割と責任の範囲
テスト ラボの構築
アプリケーション テスト ツールのインストール
アプリケーション情報の収集
テスト項目の作成
中間マイルストーン : テスト環境の構築
互換性の問題のテストと解決
役割と責任の範囲
アプリケーションのテスト
Windows Application Verifier によるテスト
中間マイルストーン : 互換性に関する方針の定義
Compatibility Administrator によるソリューションの適用とテスト
特殊な問題を解決するための方針の特定
Virtual PC による互換性の問題解決
マイルストーン : アプリケーション ポートフォリオの安定化

役割と責任の範囲

表 6 は、このフェーズにおける役割クラスタとその責任の範囲を示しています。

表 6. 計画フェーズの役割と責任の範囲

テスト方法の定義

アプリケーションの互換性をテストするには、Windows 基本機能テストと Windows アプリケーション調査テストの 2 種類の方法があります。Windows 基本機能テストは、アプリケーションの動作や、アプリケーションを使用するグループがそのアプリケーションで何を行おうとしているかをテスト チームが完全に把握している場合に行います。それ以外の場合は、より特別な形式のテストである Windows アプリケーション調査テストを行います。

Windows 基本機能テストと Windows アプリケーション調査テストの詳細については、このガイドの「テスト項目の作成」を参照してください。

テスト対象のアプリケーションの特定

中規模から大規模の組織の大半は、非常に多くのアプリケーションを使用しているため、そのすべてを詳しくテストすることは不可能です。したがって、多くの場合は、テスト予定のアプリケーションに優先順位を付けます。

アプリケーション ベースを統合して、新しいオペレーティング システムでサポートする予定のあるアプリケーションのみを挙げた後、アプリケーションと Windows XP Professional との互換性、業務上のアプリケーションの重要性、アプリケーションを使用するユーザー数などの要因に基づいてアプリケーションに優先順位を付けることができます。テストにかけられる時間やリソースが限られている場合は、この優先順位の一覧を使用して、簡略化されたテストを 1 つまたは複数のアプリケーションに対して行うか、特定のアプリケーションに対してテストを行うかを決定します。

メモ　時間とリソースが許す限り、すべてのアプリケーションにすべてのテストを行うことをお勧めします。

インベントリを作成したアプリケーションに優先順位を付ける最終的な目的は、新しいバージョンの Windows オペレーティング システムのロールアウトを開始する前に、正常に動作する必要のある一連のコア アプリケーションを特定することです。既存の優先順位カテゴリ (障害回復に使用したものなど) を使用する場合も、このプロジェクト用に新しくカテゴリを作成する場合も、これらのコア アプリケーションを含める必要があります。

以降のセクションの情報と、組織の状況に固有のその他の検討事項を考慮して、各アプリケーションのテストの優先順位を付けてください。

互換性のレベルに基づいたアプリケーション テストの優先順位付け

Analyzer や Windows カタログを使用して取得した互換性の情報に基づいて、アプリケーション テストのレベルに優先順位を付けることができます。このタスクは、表 7 の情報を基に実行します。

表 7. アプリケーションの互換性の優先順位カテゴリ

業務上のアプリケーションの重要性に基づいたアプリケーション テストの優先順位付け

アプリケーションを使用しているグループから収集した情報を基に、組織の業務においてこれらのアプリケーションがどの程度重要であるかを基準にして、アプリケーションのテストに優先順位を付けることができます。この基準に基づいてテストするアプリケーションに優先順位を付けるには、表 8 に記載されているカテゴリを使用してください。

表 8. 業務上の優先順位カテゴリ

使用状況に基づいたアプリケーション テストの優先順位付け

Analyzer で生成されたレポートを見ると、組織の各アプリケーションがインストールされているデスクトップの台数がわかります。多数の従業員が使用しているアプリケーションのテストは、オペレーティング システムとの互換性があるとわかっているかどうかに関係なく必要です。たとえば、組織内のすべてのデスクトップで実行されているウイルス対策ソフトウェアは、このようなアプリケーションの一例です。

数人の従業員だけが使用しているアプリケーションであっても、そのアプリケーションの障害が発生した場合に影響を受ける従業員の数が多い場合は、テストを行う必要があります。たとえば、給与計算ソフトウェアを使用するのは、経理部門のほんの数人にすぎません。しかし、このソフトウェアが正常に動作しないと、すべての従業員の給与支払いが遅れる可能性があります。テスト予定のアプリケーションに優先順位を付ける場合は、アプリケーションの障害が組織に与える影響と、アプリケーションを使用する従業員の人数を考慮してください。

マイルストーン : アプリケーション互換性のテスト計画の承認

マイルストーンは、ソリューション全体における同期ポイントです。詳細については、Solution Accelerator for BDD の『計画、構築、および展開ガイド』を参照してください。このマイルストーンでは、アプリケーション互換性機能チームが、行う必要のあるアプリケーションのテスト計画を作成します。

成果物

アプリケーション テストのための準備

アプリケーション テストを開始するには、テスト ラボの構築、アプリケーションのテストやデバッグに必要なツールのインストール、各アプリケーションのインストールやテストに必要なすべての情報およびコンポーネントの収集、テスト項目の作成などの準備を行う必要があります。図 5 は、これらのタスクが互換性テスト プロセスでいつ実行されるかを示しています。

フル サイズのイメージを確認する

役割と責任の範囲

表 9 は、このフェーズにおける役割とその責任の範囲の概要を示しています。

表 9. 準備フェーズの役割と責任の範囲

テスト ラボの構築

アプリケーションに Windows XP Professional との互換性があるかどうかを判断するには、組織内のハードウェアとソフトウェアの代表的な構成を持つコンピュータを使用したラボ環境でテストする必要があります。このようなハードウェアとソフトウェアの構成には、インターフェイスとして機能するすべてのオペレーティング システム、混在しているクライアントの構成、1 台のコンピュータにインストールされるアプリケーションの構成、サポートされているすべてのプログラム、ハードウェア コンポーネント、必須ファイルなど、組織によって異なる要素が含まれます。そのため、テスト ラボの規模や複雑さは、テスト対象のアプリケーションの複雑さや、アプリケーションの展開先のネットワーク環境によって異なります。

ハードウェア構成とソフトウェア構成だけでなく、実稼動環境でのアプリケーションのインストール方法と使用方法のシミュレーションも行います。たとえば、ある組織の実稼動環境では、Windows NT Server 4.0 と Windows 2000 上で数千のアプリケーションが動作しています。この組織では、アプリケーション環境を制御し、サードパーティ製品の不正なコピーやインストールを防ぐために、アプリケーションのインストールをスクリプト化しています。さらに、実行用のアプリケーションのためのドライブの割り当てを標準化しています。たとえば、ドライブ F はユーザーが読み取りアクセス権のみを与えられている認証済みアプリケーション用、ドライブ G はユーザーが読み取り/書き込みアクセス権を与えられている認証済みアプリケーション用に予約されています。また、ドライブ J はセッション間で保持される、カスタマイズ済みのユーザーの個人設定用に予約されています。

テスト ラボには、ドライブの割り当てをシミュレートするための個別のネットワーク共有が用意されています。Windows NT Server 4.0 と Windows 2000 がインストールされている 2 台のベースライン コンピュータを除くすべてのテスト ラボ コンピュータに Windows XP Professional がインストールされています。各コンピュータには、Office 製品シリーズ、インターネット ブラウザ、ウイルス対策アプリケーション、管理ツールなど、すべてのユーザーに共通のコア アプリケーションがセットアップされています。これらのコア アプリケーションの互換性については、事前にテスト済みです。その後、コア アプリケーションがインストールされている環境で、実行用のアプリケーションのインストール スクリプトを使用して、それ以外のアプリケーションをテストします。

ラボの方針の決定

状況や環境に応じて、Windows XP Professional の展開のテストに使用するラボで、アプリケーションをテストすることができます。しかし、予算とスペースに余裕があれば、アプリケーションのテスト専用のラボを設ける方がより効率的です。たとえば、アプリケーションの数が多い場合は、アプリケーションのテストにのみ使用できるラボがあれば、テストをスケジュールどおりに進めやすくなります。

アプリケーションのテストに使用するラボは 1 か所であっても、数か所に分散していてもかまいません。アプリケーションの所有者とテスト実施者が広範囲に分散している場合は、ラボが分散していると、テスト中にリソースを利用しやすくなるだけでなく、エンド ユーザーにテストに参加してもらいやすくなります。ラボを分散させると、設備投資額が増え、管理もより複雑になるので、2 つのアプローチを組み合わせることもできます。たとえば、専用のサーバーや構成を必要とする重要な業務アプリケーションのテストには大規模な中央集中型のラボを使用し、より独立性の高いワークステーション アプリケーションのテストには規模の小さい分散型のラボを使用します。この場合の分散型ラボは、テスト実施者の机上にあるワークステーション程度のシンプルなものであることもあります。

ラボの方針を決定するときは、次の点を考慮してください。

• テスト対象のアプリケーションの数と複雑さ

• アプリケーションのテスト実施者の所在地

• アプリケーションの所有者の所在地

• 予算とスペースの制限事項

• 輸送にかかる時間とコスト

以下の方針について考慮してください。

• 中央集中型のテスト施設　中央集中型のテスト施設を使用するシナリオでは、ラボは 1 か所に設置され、その環境ですべてのテストが行われます。通常、このシナリオでは、分散型のラボよりも必要なリソースが少なくて済みます。統合された環境であるため、より複雑で完全なアプリケーション テスト用ラボを構築できます。また、ラボが 1 か所であるため、ラボの管理と構成が簡単になります。このシナリオの欠点は、すべてのテストをこのラボで行う必要があることで、これは大規模な組織にとっては現実的ではないかもしれません。輸送にかかるコストや、必要なリソースをラボに揃えることができるかどうかを検討する必要があります。

• 分散型のテスト施設　分散型のテスト施設を使用するシナリオでは、ラボはテスト実施者やアプリケーション所有者に近い場所に設置されます。ラボを開発グループやテスト グループに近い場所に置くことで、テスト時に発生する可能性のある問題に、より多くのリソースを投入して対処できます。また、エンド ユーザーがアプリケーションのテストに参加しやすくなる場合もあります。このシナリオには、必要な機器を揃えるためにコストがかかる可能性がある、ラボの構成を管理する能力が必要であるなどの欠点があります。

• 2 つの構成の組み合わせ　規模の大きいさまざまな業務 (LOB) アプリケーションや小規模なワークステーション アプリケーションを組織で使用している場合は、中央集中型のラボと分散型のラボの両方を設置するとよいでしょう。専用のサーバーや構成を必要とする重要な LOB アプリケーションのテストには、実稼動環境をほぼ正確に再現したテスト環境を備えた大規模な中央集中型ラボを使用します。大規模なサーバー リソースを必要としない、小規模なアプリケーションのテストには、小規模な分散型ラボを使用できます。場合によっては、このラボは、開発者の机上にある Windows ワークステーションまたは共有ワークステーションである可能性があります。

メモ　「Solution Accelerator for Consolidating and Migrating LOB Applications」(http://www.microsoft.com/technet/itsolutions/
techguide/msa/solacc/lobsa/default.mspx) (英語情報) には、サーバー ベースの LOB アプリケーションの移行に関するガイダンスが記載されています。このガイダンスの大部分は、デスクトップ LOB アプリケーションの移行にも対応します。

ラボの構成

テスト ラボでは、個別に管理やスケジュール設定が可能なテスト ステーションを構成します。十分な数のコンピュータを用意できる場合は、各テスト ステーションに少なくとも 2 台のワークステーションを並べて配置し、テストできるようにします。一方のワークステーションは現在実行しているオペレーティング システムで構成し、もう一方のワークステーションは新しいオペレーティング システムで構成します。各テスト ステーションのコンピュータの台数が十分でない場合は、必要に応じて割り当て可能な、現在のオペレーティング システムを実行しているコンピュータのグループを用意します。

必要なコンピュータの数を減らすには、コンピュータをデュアル ブートまたはトリプル ブートできるようにセットアップすることを検討してください。これにより、テスト実施者は、アプリケーションをインストールしてテストするために必要なバージョンのオペレーティング システムにすばやくアクセスできるようになります。オペレーティング システムのバージョン間での切り替え時に、テスト実施者がコンピュータを簡単に元の状態に戻せるようにするには、基本オペレーティング システムが存在するドライブのディスク イメージを作成しておきます。

クリーン インストールではなくシステム アップグレードを実行して、Windows XP Professional を展開する場合は、アプリケーションを再インストールせずに、それらのアプリケーションが新しいオペレーティング システムでどのように動作するかをテストする必要があります。この場合、新しいオペレーティング システムにアップグレードする前に各アプリケーションをインストールできるようにするため、テスト ステーションには、現在のバージョンのオペレーティング システムが搭載されたワークステーションを用意してください。

各テスト ステーションには、専用のモニタ、キーボード、およびマウスが必要です。テスト ステーションで発生する可能性のある問題を特定するには、ケーブルを外したりプログラムを変更したりするなどの方法ですぐにテスト ネットワークの他の部分から分離できるように各テスト ステーションを構成します。テスト実施者がアプリケーションのすべての機能をテストできるようにするため、プリンタやスキャナなどの周辺機器にもアクセスできるようにしておきます。

テストを容易に進められるようにするため、ワークステーションに以下の機能を構成してください。

• アクセス許可の問題を監視するための監査機能を有効にする。Windows XP Professional の既定の設定では、以前のバージョンの Windows と比べて、よりセキュリティが向上しているため、アクセス許可が無効であるという理由でアプリケーションの障害が発生することは珍しくありません。特に、アプリケーションをインストールするときや、アプリケーションからファイルにアクセスするときにこの問題がよく発生します。アプリケーションをインストールおよび実行できるようにするために変更する必要のあるアクセス許可を特定するには、監査ログとイベント ログを使用します。イベント ログと監査ログの詳細については、Windows XP Professional の [ヘルプとサポート センター] で「Event Viewer Overview」を参照してください。

• ワトソン博士でクラッシュダンプファイルを有効にする。クラッシュ ダンプ ファイルは、致命的なエラーが発生したときのメモリの内容を取得するためのバイナリ ファイルです。クラッシュ ダンプ ファイルは、デバッガに読み込むことができます。ワトソン博士でクラッシュ ダンプ ファイルを有効にする方法については、Windows XP Professional の [ヘルプとサポート センター] で「TBD」を参照してください。

ラボで企業のドメイン構造を再現し、ドメインとワークステーションの両方のユーザー権限を複製します。新しい環境でグループ ポリシーの設定を使用する予定がある場合は、ラボにも同じポリシーを実装します。

原則として、ラボには、データベースやクライアント/サーバー アプリケーションなどのリソースを複製するようにします。メインフレーム データベースなどの一部のリソースを複製できないため、それらのリソースに企業ネットワーク経由でアクセスする必要がある場合は、接続をどのように管理および制御するかを計画し、必要に応じてすぐに接続を終了する方法を決定しておきます。

ベスト プラクティスとしては、各アプリケーションをテストする前に、ワークステーションと、可能であればサーバーも再構築します。これにより、アプリケーションの互換性とは関係のない問題が発生する可能性が最小限に抑えられるので、テスト実施者が問題を特定しやすくなります。開始点が常に同じになるようにして、セットアップの時間を短縮するには、スクリプトやイメージを使用してワークステーションを再構築します。

ラボを構成するときは、次の点を考慮してください。

• 必要なスペース　テスト ラボに必要な物理的なスペースは、計画中の展開の種類とテスト ラボの将来的な計画によって大きく異なります。ラボを常設し、実稼動環境のソフトウェアの更新のテストを継続的に行う企業では、ラボを一時的に使用する企業よりも、ラボのサイズが大きくなります。

• 要員　テスト ラボに必要な要員の数や職務権限は、展開プロジェクトのスケジュールと予算によって異なります。可能な限り、ソフトウェアとハードウェアのテストの実行には専任スタッフを起用してください。開発者は、組織内で使用される業務アプリケーションを調整してカスタマイズする必要があります。テスト ラボ マネージャには、リソースのスケジュール設定を任せます。

• 必要なコンピュータ　テスト ラボで使用するコンピュータ システムは、企業のハードウェア構成をすべて再現したものであることが必要です。効率的にテストを行うには、1 つの席にコンピュータが 1 台必要です。これらのコンピュータは、テスト対象のオペレーティング システムとアプリケーションを実行するために最低限必要なシステム要件を満たす必要があります。規模を縮小してネットワーク構造を再現できるだけのサーバーを用意してください。アプリケーションの機能を完全にテストするため、テスト環境では、プリンタやスキャナなどの周辺機器も使用できるようにしておく必要があります。

• 電源　テスト ラボでは、すべてのハードウェアを同時に実行したときの負荷に対応できるだけの効率的な電源供給が必要です。可能であれば、備品を移動したり机の下に入って作業したりせずにコンピュータを接続できるように、コンセントを配置してください。人が歩く場所にコードを配線しないでください。

• 空調　密室で複数のコンピュータを実行すると多量の熱が発生します。この熱を逃がすための空調設備が必要です。

• セキュリティ　テスト ラボには高価なハードウェアやソフトウェアが多数設置されます。盗難や破壊行為を防ぐには、テスト ラボへの物理的アクセスを制限してください。

• ネットワーク　ラボで使用するネットワーク コンポーネントは、できる限り他の部分から隔離してください。実稼動環境のネットワークに 1 つの経路から物理的に接続できるように設定することで、テスト中にシャットダウンしたり、外部リソースへのアクセスが必要なときに接続したりできるようにしておくことが重要です。データベースやクライアント/サーバー アプリケーションなど、ほとんどのリソースはラボに複製できます。しかし、メインフレーム データベースのように、複製が不可能で、ネットワーク経由でアクセスする必要のあるリソースもあります。これは例外であり、通常はこのようなことはありません。予想外の問題を避けるために、各テスト ステーションは、ケーブルを外したりプログラムを変更したりするなどの方法で、テスト ネットワークの他の部分から簡単に分離できるように構成する必要があります。

アプリケーション テスト ツールのインストール

テスト ラボの構築が完了したら、アプリケーション テスト ツールを収集してインストールします。これには、テストを自動化するための既存のアプリケーション テスト ツールや、アプリケーション互換性修正プログラムを適用するために必要な Windows Application Compatibility Toolkit が含まれます。

テスト ツール

テスト ツールの中には、テスト データを収集または定義したり、テストの実行時にファイルやレジストリの状態を監視したりするものがあります。テスト プロセスのさまざまな手順を自動化するツールには、以下のような種類があります。

• テスト自動化ツール (記録ツールや再生ツールなど) またはテスト項目ジェネレータ

• カスタム スクリプト (インストール スクリプトなど)

• データ抽出ツール (データ ウェアハウス ツールなど)

• テスト データベース (回帰テスト用に作成されたデータベースなど)

• 比較ツールおよび監視ツール (ファイルやレジストリの変更を追跡するツールなど)

Windows Application Compatibility Toolkit

Microsoft が提供する Windows Application Compatibility Toolkit には、Windows Application Verifier (ヒープやその他の見つけにくい問題の検出を支援するツール) と、Compatibility Administrator (アプリケーション互換性修正プログラムを適用して、互換性の問題を解決するツール) があります。ソース コードを所有していない場合や、コードをデバッグまたは修正したり、変更を実装したりする時間がない場合は、アプリケーション互換性修正プログラムを使用して互換性の問題を解決します。アプリケーション互換性修正プログラムではソース コードは変更されないため、ワークステーションにアプリケーションをインストールするたびにこの修正プログラムを適用する必要があります。

デバッグ ツールのインストール

アプリケーションのソース コードが使用可能であり、ソース コードを変更して互換性の問題の基になる原因を解決する場合や、そのような問題を解決するためのアプリケーション互換性修正プログラムが見つからない場合は、デバッグ ツールを使用して問題を調べます。この場合、独自のデバッグ ツールを使用することも、このセクションで説明する Debuggin Tools for Windows を使用することもできます。

Debugging Tools for Windows は、カーネル モード デバッガとユーザー モード デバッガの集まりであり、Microsoft から提供されています。アプリケーションは、カーネル モードまたはユーザー モードのどちらかのモードで実行されます。オペレーティング システムのサービスや、デバイス ドライバおよびウイルス対策アプリケーションなどの下位レベルの一部のプログラムは、カーネル モードで実行されます。カーネル モード アプリケーションは、システムのどの部分にでもアクセスできます。ユーザー モード アプリケーションは、メモリ内で割り当てられている領域にのみアクセス可能で、システム インターフェイスやシステム データへのアクセスは制限されています。エンド ユーザー アプリケーションのほとんどは、ユーザー モードで実行されます。

デバッグする必要のあるアプリケーションの種類 (カーネル モードまたはユーザー モード) と、デバッグに使用する予定のコンピュータ (ローカルまたはリモート) に基づいてツールを選択します。Windows XP Professional との互換性テストが必要なほとんどのアプリケーションは、ユーザー モード アプリケーションです。カーネル モード アプリケーションを組織内で開発していない場合は、使用するカーネル モード アプリケーションのアップグレードについてベンダに問い合わせてください。

表 10 は、Debugging Tools for Windows に含まれているデバッガを示しています。これらのデバッガがどの処理モード用に設計されているか、およびローカル コンピュータとリモート コンピュータのどちらから使用できるかも記載してあります。

表 10. Debugging Tools for Windows

Debugging Tools for Windows には、デバッガだけでなく、デバッグ時に使用できるその他のツールが用意されています。特に、Logger や LogViewer は、アプリケーション互換性問題のデバッグに役立ちます。

メモ　シンボル ファイルのないサードパーティ アプリケーションで Microsoft のデバッガを使用する場合、デバッガは実行可能ファイルからシンボリック情報の抽出を試み、それらがエクスポート シンボルであることを示します。実際には、これらはシンボルではないので、デバッグ分析に使用することはできません。

組織でカーネル モード アプリケーションを開発していない限り、ほとんどの場合、アプリケーション互換性テストに KD デバッガは必要ありません。CDB デバッガと NTSD デバッガの機能はほぼ同じですが、NTSD デバッガを起動すると、2 つ目のコマンド ウィンドウが開かれます。このウィンドウを使用して、リモート コンピュータからネットワーク経由でデバッグできます。WinDbg は、Debugging Tools for Windows で最も用途の広いデバッガです。

Logger と LogViewer は、アプリケーションによる API 呼び出しの分析に役立ちます。以前のバージョンの Windows で動作していたアプリケーションでは、API 実装の違いにより互換性の問題が発生する可能性があります。サードパーティ アプリケーションをデバッグするための最も効果的な方法の 1 つは、そのアプリケーションが呼び出す Win32 API について調べることです。

CDB と NTSD

CDB と NTSD は、ユーザー モード メモリを分析するためのコンソール デバッガであり、コンソールまたはグラフィカル Windows アプリケーションのどちらかのオンターゲット アプリケーションを構成します。これらのツールを使用して、障害の発生したアプリケーションをデバッグする場合は、スタック トレースの取得や無効なパラメータの表示が可能です。また、正常に動作しているアプリケーションの動作を観察することもできます。

CDB または NTSD を使用すると、プログラム コードの表示と実行、ブレークポイントの設定、およびメモリ内の値の確認や変更が可能です。また、バイナリ コードの逆アセンブルやアセンブリ命令の表示も可能です。さらに、ソース コードを直接分析することもできます。

メモ　Windows XP Professional がインストールされている場合、NTSD のコピーは Windows の \Windows\system32 ディレクトリにインストールされていますが、Debugging Tools for Windows に含まれているバージョンが最新です。

NTSD の詳細については、Debugging Tools for Windows のヘルプを参照してください。

WinDbg

WinDbg は、グラフィカル インターフェイスを備えたデバッガであり、Windows カーネル、カーネル モード ドライバ、システム サービスおよびユーザー モード アプリケーションやドライバをソース レベルでデバッグできます。WinDbg は、変数、CPU レジスタ、関数呼び出しで渡されるパラメータを監視できます。また、障害発生時のシステムの状態が記録された、ワトソン博士のクラッシュ ダンプ ファイルの確認にも WinDbg を使用します。さらに、ソース コードの表示、ブレークポイントの設定、変数 (C++ オブジェクトを含む)、スタック トレース、メモリの表示も可能です。

WinDbg の詳細については、Debugging Tools for Windows のヘルプを参照してください。

Logger と LogViewer

Logger は、ユーザー モードのターゲット アプリケーションの動作を監視し、そのアプリケーションによる API 呼び出しをすべて記録します。結果として得られた情報は、デバッガに表示したり、テキスト ファイルとして保存したりできます。また、LogViewer に対話形式で表示することもできます。

Logger を起動するには、Logger.exe プログラムを単独で使用するか、NTSD または WinDbg を起動してデバッガ拡張機能 LogExts.dll を使用します。どちらの方法でも同じ種類のログが出力されます。ただし、NTSD または WinDbg と共に Logger を起動すると、デバッガと Logger の両方のすべての機能にアクセスできます。

API 呼び出しを記録したら、LogViewer を使用してログ ファイルを表示できます。すべての API 呼び出しを、記録された順序で一覧として表示し、その一覧をフィルタ処理したり、テキスト ファイルにエクスポートしたり、各 API 呼び出しとの間で送受信されたパラメータの値を表示したりできます。

Logger と LogViewer のアクティブ化と使用については、Debugging Tools for Windows のヘルプを参照してください。

Debugging Tools for Windows の入手

Debugging Tools for Windows はダウンロード可能です。このツールを使用するには、デバッグ対象のアプリケーションが実行されている Windows のバージョンに対応した適切なシンボル ファイルもインストールする必要があります。シンボル ファイルには、プログラムの実行には必要なくても、デバッグには役立つさまざまな情報が含まれています。この情報が実行可能ファイルではなくシンボル ファイルに含まれているのは、パフォーマンスを向上させるためです。Debugging Tools for Windows の最新バージョンと適切なシンボル ファイルをダウンロードするには、「Debugging Tools」リンク (http://www.microsoft.com/windows/reskits/webresources) (英語情報) を参照してください。

アプリケーション情報の収集

テストを開始するには、各アプリケーションのテストに必要な情報をすべて収集します。Microsoft のお客様は、テスト前の準備や情報収集に力を入れるほど、テストがより迅速かつ簡単に進行することを認識しています。関連情報をすべて手元に集めておくと、テスト中に問題が検出された場合に簡単に解決できるようになります。

各アプリケーションについて、ソフトウェアやドキュメントと共に、アプリケーションのインストールと実行に必要なサポート コンポーネントを収集し、アプリケーションが Network Basic Input/Output System (NetBIOS) に依存しているかどうかを確認します。この時点で、アプリケーション互換性テストのタスクは反復タスクになります。決められた方針に従って、事前に指定された各アプリケーションが、検索、インストール、およびテストされます。

ソフトウェアおよびサポート情報

組織内のアプリケーション所有者と協力して、各アプリケーションとそのドキュメントを見つけます。テスト ラボに各アプリケーションをインストールするには、そのアプリケーションの実行に必要なサポート情報とコンポーネントを収集してください。たとえば、以下の情報を収集する必要があります。

• 必要なセキュリティ許可 (ユーザー ID、パスワード、データベースのアクセス許可、グループ メンバシップなど)。

• 必要なサーバーと IP アドレス。

• 正確なインストール手順、インストール メディア、およびアプリケーションの専門家の連絡先情報。

• 適用された、または必要な Service Pack や更新プログラム。

• 依存するソフトウェア (Microsoft SQL Server やサードパーティ コンポーネントなど)。

• アプリケーションがクライアント ベースとサーバー ベースのどちらか。また、各コンポーネントがクライアントとサーバーのどちらに存在するか。

• 現在アプリケーションが実行されている Windows のバージョン。

• アプリケーション構成情報 (検索パスや作業ディレクトリなど)。

• アプリケーション ファイルがインストールされているディレクトリのパス。

• アプリケーションにより作成または変更されたレジストリ設定。

• ユーザー データが保存されている場所。

• Web アプリケーションの URL。

• アプリケーションのコンパイル時に作成された、デバッガが使用するシンボル ファイルの場所。

• アプリケーションで必要なオペレーティング システム コンポーネント (IIS または SMTP)。

• アプリケーションで必要なハードウェア。

• アプリケーションが使用するポート。

NetBIOS への依存性

NetBIOS を必要とするアプリケーションがあるかどうかを調べます。ある場合は、新しい Windows 環境に NetBIOS が含まれていることを確認します。

Windows NT では、NetBIOS は既定の構成として設定されています。Windows XP Professional オペレーティング システムが実行されているサーバーでは、NetBIOS は既定の構成として設定されていません。NetBIOS がないシステムで実行されているアプリケーションが NetBIOS を使用する関数を呼び出すと、その関数はエラーを返します。このような場合は、NetBIOS を有効にするか、NetBIOS に依存しない関数を使用するようにアプリケーションを変更する必要があります。

テスト項目の作成

テストを開始するには、テスト項目を作成してドキュメント化する必要があります。テスト項目は、実行するテストと、可能であれば、予測される結果を説明したものです。必要なテスト項目の数と複雑さは、アプリケーションのテストをどの程度の範囲で行うかによってもいくぶん異なります。アプリケーションで必要なテストの範囲は、アプリケーションがサードパーティ製品であるか、社内でカスタマイズまたは開発されたものであるかによって異なります。サードパーティ アプリケーションの場合は、アプリケーションと、展開する新しいバージョンの Windows との間に互換性があるとわかっているかどうかによっても、テストの範囲が異なります。

以下のカテゴリに含まれるアプリケーションには、詳しいテストが必要です。

• 社内で開発されたアプリケーション

• 特定の組織用にカスタマイズされたアプリケーション

• Application Compatibility Analyzer によって互換性が Unknown と示されたアプリケーション

• Application Compatibility Analyzer によって Compatible with Issues と示されたアプリケーション

• Windows カタログに記載されていないアプリケーション

このようなアプリケーションについては、実際の環境で必要なすべての機能を対象とした、広範囲にわたるテスト項目を作成する必要があります。

Application Compatibility Analyzer や Windows カタログで Compatible と示されたアプリケーションや、Windows カタログに "Designed for Windows XP" と示されているアプリケーションについては、上記のアプリケーションほど広範囲のテストは必要ありません。ただし、実際のハードウェア構成とソフトウェア構成で使用する場合に、これらのアプリケーションが予測どおりに動作することを確認するため、一般的なテストは行う必要があります。最も頻繁に使用される機能や、特別な場合にのみ使用される機能または固有の技術に関するテスト項目を作成します。たとえば、組織でスクリプトを使用してデスクトップ環境を管理している場合は、それらのスクリプトでアプリケーションをテストします。ターミナル サーバーでアプリケーションをホストしている組織では、ターミナル サーバーを使用したアプリケーションのテストも必ずテスト項目に含めてください。

各アプリケーションについて選択したテスト方法によって、テスト項目をどのように作成するかが決まります。テスト方法はさまざまであり、どの方法を使用するかが既に決まっている場合もあるでしょう。テスト項目の作成に必要なテスト方法が決まっていない場合は、以下のいずれかの方法を使用してください。各方法については、このセクションで説明します。

• Windows 基本機能テスト。アプリケーションに詳しい場合は、この方法でテスト項目を作成します。

• Windows アプリケーション調査テスト。あまり詳しくないアプリケーションについて学習しながらテスト項目を作成できます。

Windows 基本機能テスト方法の使用

アプリケーション、アプリケーションのエンド ユーザー、および実際の環境でのアプリケーションの用途について熟知している場合は、Windows 基本機能テスト方法のガイドラインに従ってテスト項目を作成します。アプリケーション関するこのレベルの知識があれば、組織におけるアプリケーションの使用方法に基づいてテスト項目を作成できます。

Windows 基本機能テスト方法を使用する場合は、アプリケーションのテストを開始する前にテスト項目を定義してください。インストール、オペレーティング システムとの対話、アプリケーションの機能、およびアンインストールの 4 つの領域についてテスト項目を作成します。

インストール

以前のバージョンの Windows を Windows XP Professional にアップグレードする予定であっても、アプリケーションのインストールについてテストする必要があります。このテスト フェーズでは、使用するアカウント (一般ユーザー、パワー ユーザー、または管理者) やインストール方法 (標準、ネットワーク、完全、および最小) に関係なくアプリケーションを正しくインストールできるかどうかを確認します。Windows インストーラを使用する場合は、通知機能と公開機能もテストする必要があります。

アプリケーションに関する以下の点を確認するためのテスト項目を作成します。

• 実際の環境で使用されるユーザー アカウントの種類 (一般ユーザー、パワー ユーザー、管理者) で正常にインストールできる。

• 実際の環境で使用されるインストールの種類 (最小、標準、完全、またはカスタム) で正常にインストールできる。

• 実際の環境で使用される方法 (ネットワークまたは [プログラムの追加と削除]) で正常にインストールできる。

• [プログラムの追加と削除] の一覧に正しく表示されている。

• Windows のバージョンを正しくチェックしている。

• ディスクの空き容量が 2 GB を超えるパーティションにインストールされる。

• [スタート] メニューの一覧に表示されていて、すべてのユーザーが使用できるデスクトップ ショートカットがある。

• EFS ボリュームに正しくインストールできる。

• 圧縮された NTFS ボリュームに正しくインストールできる。

• リムーバブル メディアのボリュームにインストールできる。

Windows インストーラを使用する場合は、アプリケーションに関する以下の点を確認するためのテスト項目を作成します。

• 正しく通知および公開できる。

• ユーザー データ設定の場所を表すシステム変数を使用している。

• Windows ファイル保護が有効になっている。

• 共有コンポーネントのダイナミック リンク ライブラリ (DLL) リダイレクトをサポートしている。

• 古い技術 (システム フォルダへの .ini ファイルの保存など) を使用していない。

オペレーティング システムとの対話

オペレーティング システムとの対話をテストし、アプリケーションがオペレーティング システムの基本機能と正しく連係していることを確認します。これらのテストには、ファイルのオープン/クローズ、ウィンドウの操作、印刷、ヘルプとサポート システムのトピックの表示など、標準の Windows の操作の使用も含まれます。

以下の各一覧には、アプリケーションとオペレーティング システムとの対話を確認するテスト項目を特定するために最初に行う作業を示しています。これらの一覧に挙げられている項目は完全なものではなく、テストする機能のスコープに関する考え方を示しています。ツールキットに含まれているホワイト ペーパー『Windows Compatibility Checklist』は、開発中のアプリケーション向けのドキュメントであり、これに詳細が示されています。アプリケーションでスキャナやデジタル カメラなどの周辺機器を使用する場合は、これらの機器とアプリケーションとの対話を確認するためのテスト項目も必要です。

メモ　互換性テストの詳細については、「Windows アプリケーションの互換性」(http://www.microsoft.com/windows/appcompatibility/default.mspx)
のドキュメントを参照してください。

基本アプリケーションのテスト
アプリケーションに関する以下の点を確認するためのテスト項目を作成します。

• 実際の環境で使用されている他のアプリケーションと対話できる。

• さまざまな方法で ([スタート] メニュー、ショートカット、CD-ROM 自動起動、コンソール、クイック起動バーなどから) 正常に起動できる。

• アプリケーションに関連付けられたファイル名拡張子を持つファイルをダブルクリックすると正常に起動する (該当する場合)。

• アプリケーションの別のインスタンスが実行されているときに正常に起動する。

• ドキュメントや関連プログラムなど、[スタート] メニューで正しく動作するショートカットが関連付けられている (該当する場合)。

• コピー、貼り付け、および編集の機能が正しく実行される。

• モニタの解像度の変更 (たとえば、640 × 480 ピクセルから 1024 × 768 ピクセルへ) が正しく処理される。

• Windows の画面のテーマと正しく連動する。

• ホイールオンホイール マウスを使用してアプリケーションのドキュメントを開いたときに、アプリケーションが正常に起動する (該当する場合)。

• ホイールオンホイール マウスを使用して正しくスクロールできる (該当する場合)。

• [ヘルプ] メニューから、および F1 キーを押してヘルプを開くことができる (該当する場合)。

• ユーザーの簡易切り替えと正しく連動する。

• ワイヤレス LAN で正しく動作する。

• リモート デスクトップ経由のアクセス時に正しく動作する。

ファイルシステム
アプリケーションで以下の処理を正常に行うことができるかどうかを確認するためのテスト項目を作成します。

• 長いファイル名や Universal Naming Convention (UNC) パスを処理できる。

• アクセス許可が制限されている NTFS ファイル システムのフォルダにファイルを保存できる。また、このフォルダにあるファイルを開くことができる。

• ディスクの空き容量が 2 GB を超えるディスク パーティションにファイルを保存できる。また、このパーティションにあるファイルを開くことができる。

• UNC パスおよび割り当てられたドライブに 255 文字の名前のファイルを保存できる。また、これらの場所にあるファイルを開くことができる。

• マイ ドキュメント フォルダに 255 文字の名前のファイルを保存できる。また、このフォルダにあるファイルを開くことができる。

• サポートされていない特殊文字 (アスタリスク、引用符、疑問符、先頭や末尾の空白など) が名前に含まれているファイルを保存したり、開いたりできる。

• サポートされている特殊文字 (プラス記号、コンマ、セミコロン、等号、角かっこ ([ ]) など) が名前に含まれているファイルを保存したり、開いたりできる。

• アプリケーションがサポートするすべての種類のドキュメントを保存したり、開いたりできる。

• アプリケーションがサポートするすべての形式 (.jpg、.gif、.bmp など) のファイルをインポートおよびエクスポートできる。

• FAT16 ファイル システムまたは FAT32 ファイル システムで作成されたドキュメントを NTFS ファイル システムで開くことができる。

• FAT16 ファイル システム用にフォーマットされたドライブと、NTFS ファイル システム用にフォーマットされたドライブの両方で、ドキュメントを開いたり、保存したりできる。

• FAT32 ファイル システム用にフォーマットされたドライブと、NTFS ファイル システム用にフォーマットされたドライブの両方で、ドキュメントを開いたり、保存したりできる。

• 分散ファイル システム (DFS) にファイルを保存できる。また、DFS にあるファイルを開くことができる。

• Windows NT Server 4.0 ベースまたは Windows 2000 ベースの NTFS コンピュータから、Windows XP Professional ベースの NTFS コンピュータにコピーされたドキュメントを開くことができる。

• 圧縮された NTFS ボリュームで機能する。

• EFS ボリュームで機能する。

• リムーバブル メディアのボリュームで機能する。

印刷
アプリケーションで以下の処理を正常に行うことができるかどうかを確認するためのテスト項目を作成します。

• 長い名前のプリンタでドキュメントを印刷できる。

• UNC パスを使用して、プリンタでドキュメントを印刷できる。

• ローカル プリンタやネットワーク プリンタでドキュメントを印刷できる。

• PostScript プリンタでドキュメントを印刷できる。

• 汎用テキスト プリンタでファイルを印刷できる。

• カラー インクジェット プリンタでファイルを印刷できる。

• プリンタ ドライバがインストールされていない場合に印刷コマンドを処理できる。

• LPT1 または LPT2 以外の LPT ポートからドキュメントを印刷できる。

• ドキュメントの印刷中にプリンタの電源がオフになった場合に印刷コマンドを処理できる。

• ドキュメントを縦方向および横方向に印刷できる。

Advanced Configuration and Power Interface のサポート
アプリケーションに関する以下の点を確認するためのテスト項目を作成します。

• ACPI 通知とイベントを正しく処理できる。

• ターンオフ時間を 1 分に設定したときに、その設定に従ってモニタがオフになる。

• ターンオフ時間を 2 分に設定したときに、その設定に従ってハード ドライブがオフになる。

• スタンバイ モードや休止モードになった後、再開しても機能をすべて使用できる。

• 通常のタイムアウトまたはバッテリ低下アラームのどちらの理由でスタンバイ モードや休止モードになっても、データが失われることなくそれらのモードが解除される。

マルチモニタのサポート

アプリケーションで以下の処理を正常に行うことができるかどうかを確認するために、必要に応じて、マルチモニタの構成用のテスト項目を作成します。

• モニタを左右に並べて配置できる。

• モニタを上下に並べて配置できる。

• 2 つのモニタにそれぞれ異なる解像度を使用できる。

• 2 つのモニタにそれぞれ異なる色数を使用できる。

• 2 つのモニタの表示範囲を左から右および上から下に指定できる。

• 両方のモニタ上で、マウスを上下左右に移動できる。

• 両方のモニタ上で、ウィンドウを最大化および最小化できる。

アプリケーションの機能

アプリケーションの機能のテストでは、実際の環境で使用するアプリケーションが予測どおりに機能するか、および既知の入力に対して予測どおりの結果が得られるかを確認します。ソース コードを使用できるかどうかにかかわらず、アプリケーションの機能をテストする必要があります。

アプリケーションを社内で開発またはカスタマイズした場合は、新しいオペレーティング システムとの互換性の確認に使用できるテスト スクリプトやデータがある可能性があります。テスト スクリプトがない場合は、同じ組織内のアプリケーションに詳しいユーザーと協力して、すべての必須機能を使用するテスト項目を作成します。

アンインストール

アプリケーションの削除のテストでは、すべてのコンポーネントを問題なくコンピュータから削除できるかどうかを確認します。

以下の点を確認するためのテスト項目を作成します。

• [プログラムの追加と削除] でアプリケーションが削除される。

• [スタート] メニューからすべてのショートカットが削除される。

• インストール ディレクトリ内のすべてのファイルが削除される。

• システム ファイルや共有コンポーネントは削除されない。

• アプリケーション固有のすべてのレジストリ エントリが削除される。

Windows アプリケーション調査テスト方法の使用

調査テスト方法では、アプリケーションに関する学習プロセスを定義しています。これにより、アプリケーションに詳しいユーザーがテストに参加できないときに、テスト対象の最も重要な項目を特定することができます。

この方法を使用する場合、あらかじめテスト項目を定義しておく必要はありません。アプリケーションについて調査および学習しながら、テスト項目を定義して、テストを実行します。

調査テスト方法の概要

調査テスト方法の目的は、大部分のユーザーが新しいバージョンの Windows で特定のアプリケーションを正常に使用できるかどうかを、限られた時間で確認することです。このテストでは、アプリケーションの機能性と安定性の両方を確認します。これは包括的なテスト方法ではないので、アプリケーションの専門家がテストに参加できる場合は、正式な方法でテストしてください。

調査テストは対話型のプロセスであり、アプリケーションの調査、テストの設計、およびテストの実行が同時に行われます。このテストは多くの点において自由形式ですが、プロセスには具体的なタスク、目標、および成果物が含まれています。これにより、体系的なプロセスが作成され、監査可能な結果が得られます。

この方法は、James Bach の開発した｢General Functionality and Stability Test Procedure」を基にしています。調査テスト方法の詳細については、Application Compatibility Toolkit のホワイト ペーパー『Windows Applications Exploratory Test Procedure』を参照してください。

調査テストのプロセス

調査テストのプロセスは、次の 5 つのタスクで構成されます。

• アプリケーションの用途を特定する。

• アプリケーションがサポートする機能を特定する。

• アプリケーションが不安定になる可能性のある領域を特定する。

• 調査プロセスで発生した、アプリケーションに関する問題や質問事項をドキュメント化する。

• テストの概要を作成してテストの実行に使用する。

アプリケーションの用途、機能、および不安定になる可能性のある領域を特定しながら、テスト項目の概要を作成し、それを各機能のテストや問題の記録に使用します。調査プロセスの結果は、メモやドキュメント化されたアプリケーションの障害情報です。

限られた時間内でアプリケーションのすべての機能をテストすることは不可能なので、リスクの影響に基づいて、各機能にどの程度注目する必要があるかを判断し、テスト プロセスを簡略化します。このような判断を行うには、機能を主要なものと補助的なものに分類します。

主要な機能と補助的な機能を判断するには、アプリケーションの用途を理解しておく必要があります。主要な機能は、アプリケーションの用途に関連する不可欠なものです。アプリケーションを使用するうえで役に立っていても不可欠ではない機能は、すべて補助的な機能です。通常は、主要な機能のテストに最も力を入れるようにします。場合によっては、一連の補助的な機能を 1 つの主要な機能と見なしたり、1 つの主要な機能を複数の主要な機能と補助的な機能に分けたりすることもあります。機能の分類方法の詳細については、Application Compatibility Toolkit に付属のホワイト ペーパー『Windows Applications Exploratory Test Procedure』を参照してください。

機能を特定して分類しながら、すべての主要な機能について、与えられた時間内で最大限のテストを行います。その後、補助的な機能の中で重要なものをいくつかテストします。補助的な機能の多くは、主要な機能をテストしているときに一緒にテストされます。

さらに、とりわけ主要な機能について、アプリケーションが不安定になりやすい領域をテストします。アプリケーションが不安定になりやすい領域は、次のとおりです。

• 他のアプリケーションと相互運用する機能

• アプリケーションの外部で発生しているイベントを処理する機能 (ファックスを受信したときにコンピュータの休止状態を解除する機能など)

• 大量のメモリを消費する機能

• オペレーティング システムとの対話が頻繁に行われる機能

• 非常に複雑な機能

• 操作パラメータを変更する機能 (基本設定など)

• オペレーティング システムの構成を変更する機能

• エラーを受け取る、またはエラーから回復する機能

• オペレーティング システムの基本機能を置き換える機能

• 複数の同時プロセスを伴う (一連の) 機能

• 複数のファイルを同時に操作する機能

• ネットワーク経由でファイルを開く機能

中間マイルストーン : テスト環境の構築

マイルストーンは、ソリューション全体における同期ポイントです。詳細については、Solution Accelerator for BDD の『計画、構築、および展開ガイド』を参照してください。このマイルストーンでは、アプリケーション互換性機能チームが、すべての機能を備えたテスト ラボを構築し、問題の追跡に適したプロセスを指定し、テスト項目を作成します。

成果物

互換性の問題のテストと解決

テスト項目を作成したら、アプリケーションのテストと結果の記録を開始できます。まず、Windows アプリケーション調査テストまたは Windows 基本機能テストのどちらかの手順に従って基本テストを行います。次に、ソース コードを使用できる場合は、微妙で見つけにくい問題について Application Verifier でテストします。互換性の問題が検出されたら、Compatibility Administrator を使用して、アプリケーション互換性修正プログラムを適用およびテストして、問題を解決します。アプリケーション互換性修正プログラムで問題が解決しない場合は、特別な作業を試す必要があります。図 6 は、これらのテストや問題解決のタスクがアプリケーション互換性テスト プロセスでいつ実行されるかを示しています。

フル サイズのイメージを確認する

役割と責任の範囲

表 11 は、このフェーズにおける役割とその責任の範囲の概要を示しています。

表 11. 互換性の問題のテストと解決における役割と責任の範囲

アプリケーションのテスト

テストを実行しながら、その結果を評価および記録します。テストで問題が発見された場合は、まず、その問題がテスト環境や既存のアプリケーションの問題ではなく、互換性の問題であることを確認します。問題が Windows の互換性に関する問題であると判断する前に、次の 2 つの手順を必ず実行してください。

• 問題がテスト環境に起因するものではないことを確認する。アプリケーションの互換性に関する問題ではなく、ハードウェア、ソフトウェア、またはネットワーク構成に関する問題である可能性があります。

• 使用中のバージョンの Windows では同じ問題が発生しないことを確認する。現在アプリケーションを実行しているバージョンの Windows でまったく同じテストを実行し、正常に動作することを確認してください。現在のプラットフォームでも同じ問題が発生した場合は、互換性の問題ではありません。

テスト プロセスでは、テスト、問題の特定、問題の解決、再テストという作業が繰り返されます。このプロセスの手順は、発生する問題や解決方法の性質によって異なります。たとえば、アプリケーション互換性修正プログラムを適用して解決する問題への対処は、ソース コードの変更やベンダからのアップグレードの入手により解決される問題とは異なります。アプリケーション互換性修正プログラムを適用して解決する問題については、その解決フェーズをテスト フェーズに組み込むことができます。つまり、問題が発生した場合は、アプリケーション互換性修正プログラムを適用し、アプリケーションの展開に進むことができるようになるまでテストを繰り返します。ソース コードを変更する場合は、より従来のサイクルに近い、テスト、デバッグ、コーディング、再コンパイル、再テストというプロセスが繰り返されます。

問題を解決するためのアプリケーション互換性修正プログラムを特定できず、ソース コードも使用できない場合は、アプリケーション ベンダに問い合わせてアプリケーションのアップグレードを入手する必要があります。図 7 は、このテスト プロセスを示しています。

フル サイズのイメージを確認する

Windows Application Verifier によるテスト

ソース コードを使用できる場合は、安定性、信頼性、互換性、セキュリティに関するわかりにくい問題を Windows Application Verifier で検出できます。Windows Application Verifier は自動化されたテスト ツールではありません。Application Verifier を有効にしてアプリケーションを実行し、すべてのテスト項目について調べる必要があります。

Windows Application Verifier は、変更が必要なコードを特定するためのツールであり、デバッグ モードとロギング モードのどちらかの操作モードで実行されます。デバッグ モードでは、アプリケーションの問題が検出され、結果がデバッガに転送されます。ロギング モードでは、生成されるすべての出力がテキスト ファイルに書き込まれ、後から確認することができます。

図 8 は、Application Verifier のメイン ウィンドウを示しています。

フル サイズのイメージを確認する

Application Verifier を使用するには、まず管理者アカウントでこのツールを起動します。次に、テスト対象のアプリケーションを左側のペインで選択し、そのアプリケーションに対して実行するテストを右側のペインで選択します。一覧にアプリケーションを追加すると、このツール、ショートカット、またはコマンド ラインのどの方法でアプリケーションを起動しても、Application Verifier がアプリケーションに対して有効になります。次に、アプリケーションを通常の方法で起動し、テスト項目を実行します。アプリケーションをそのコンピュータで実行すると、選択したテストが必ず適用されます。テストが適用されないようにするには、Application Velifier の一覧からアプリケーションを削除します。

メモ　Application Verifier を使用するには、テスト対象のアプリケーション用のシンボル ファイルをインストールする必要があります。

テストでは、不適切なバージョン チェック、レジストリの不正使用、ハードコーディングされたファイル パスなど、アプリケーションで発生する可能性の高い問題が監視されます。検出された問題の一覧は、Application Verifier のログで参照することができます。このログ ファイルは、\Documents and Settings\All Users\Documents\AppVerifierLogs フォルダに、アプリケーションの実行可能ファイル名に対応した名前で保存されています。また、ログをテキスト ファイルにエクスポートして、他のユーザーに送信することもできます。

このツールに用意されているテスト オプションの中には、問題発生時にアプリケーションをクラッシュさせるものがあります。そのような問題は Application Verifier のログに記録されません。このような場合に問題の原因を特定するには、Application Verifier が実行された状態で、デバッガからアプリケーションを実行します。デバッガを使用する場合は、Application Verifier のログに書き込まれるイベントが発生すると、デバッガでアプリケーションが中断するように Application Verifier を設定できます。

Application Verifier ツールの詳細については、Windows Application Compatibility Toolkit のヘルプを参照してください。

表 12 は、Application Verifier を使用して実行できるテストを示しています。

表 12. Application Verifier のテスト

中間マイルストーン : 互換性に関する方針の定義

マイルストーンは、ソリューション全体における同期ポイントです。詳細については、Solution Accelerator for BDD の『計画、構築、および展開ガイド』を参照してください。このマイルストーンでは、アプリケーション互換性機能チームが、互換性の問題を軽減するための方針を特定します。

Compatibility Administrator によるソリューションの適用とテスト

Compatibility Administrator は、アプリケーション互換性修正プログラムや互換モードを適用およびテストして、それらを展開用にパッケージ化するために使用できる汎用ツールです。アプリケーション互換性修正プログラムは、既知の互換性の問題を解決するために Microsoft が提供するパッケージ化済みソリューションです。互換モードは、特定の環境で一般的に発生する問題を解決するためのアプリケーション互換性修正プログラムの集まりです。Compatibility Administrator を使用すると、アプリケーション互換性修正プログラムと互換モードを要件に合わせて組み合わせ、アプリケーションに適用されるソリューションを詳細に設定できます。

配布を簡略化するために、複数のアプリケーションのサポートに必要なすべてのソリューションを統合するカスタム データベースを作成できます。たとえば、管理対象の環境に存在する標準化された各デスクトップについてカスタム データベースを 1 つずつ作成し、環境内の Windows XP Professional コンピュータにこれらのデータベースを展開できます。

また、Compatibility Administrator では、以下の作業も可能です。

• カスタム互換モードを作成する。

• カスタム アプリケーション ヘルプ メッセージを作成する。

• アプリケーション互換性修正プログラム、互換モード、またはアプリケーション ヘルプ メッセージによって問題が解決するアプリケーションを、コンピュータのハード ディスクで検索する。

• 互換性データベース内の指定された条件に一致するソリューションを照会する。

• アプリケーション互換性修正プログラムを一時的に有効または無効にする。

アプリケーションのソース コードを使用できるかどうかにかかわらず、このツールは使用可能です。Compatibility Administrator の実行に管理者アカウントは不要ですが、カスタム データベースのインストールには管理者アカウントが必要です。

Compatibility Administrator の使用に関する方針

アプリケーションに互換性の問題があることがわかった場合は、Compatibility Administrator を使用し、1 つ以上のアプリケーション互換性修正プログラムを適用して問題を解決します。適切な解決方法を特定するには、次の手順を実行することをお勧めします。

1. アプリケーションについて表示されるアプリケーション ヘルプ メッセージに示される推奨事項に従います。たとえば、アプリケーション ヘルプ メッセージには、更新プログラムの入手先が示されていることがあります。

2. アプリケーション互換性修正プログラムで問題が解決できるかどうかを迅速に判断するには、パッケージ化済み互換モードを試します。まず、現在アプリケーションが実行されている環境を対象にして互換モードを試します。たとえば、現在 Windows 98 でアプリケーションを実行している場合は、Windows 98/Windows Millennium Edition 互換モードを使用します。制限ユーザーとしてテストを行っている場合は、Limited User Access (LUA) モードを試してください。適切な互換モードが見つかるまでに、複数のモードを試す必要がある場合もあります。必要に応じて、色、解像度、および視覚テーマの互換モードも追加します。

3. 互換モードで問題が解決しない場合は、互換モードとアプリケーション互換性修正プログラムの組み合わせを試します。互換モードを適用する場合は、アプリケーション互換性修正プログラムの任意の組み合わせを追加または削除できます。どの問題にどのアプリケーション互換性修正プログラムを適用するかについては、このガイドの「適用するアプリケーション互換性修正プログラムの決定」を参照してください。

互換モードを適用して互換性の問題を解決する場合は、アプリケーション互換性修正プログラムの削除と再テストを繰り返しながら、アプリケーションに必要なアプリケーション互換性修正プログラムの適切な組み合わせを判断することをお勧めします。これにより、不要なアプリケーション互換性修正プログラムによる新たな問題が発生するのを防ぐことができます。ただし、新たな問題が発生するリスクは非常に低いので、アプリケーションのテストにかける時間とのバランスをとることも必要です。

アプリケーション互換性修正プログラムを適用およびテストするときは、以下のガイドラインに従ってください。

• ウイルス対策、ファイアウォール、CD 書き込み、ディスク管理、バックアップなどのカーネル モード アプリケーションのインストール プログラムに対するバージョン警告を回避するために互換モードを使用しないでください。これらのアプリケーションの中には特定のオペレーティング システム用に設計されているものがあり、そのようなアプリケーションは意図的に新しいバージョンのオペレーティング システムでは使用できないようになっています。これらのアプリケーションをインストールすると、システムが不安定になる可能性があります。したがって、それらは Windows XP Professional 専用のアプリケーションと置き換えてください。

• アプリケーションのテストを開始する前に、アプリケーション互換性修正プログラムの最新バージョンがあるかどうかを Windows Update Web サイトでチェックしてください。Windows Update Web サイトにアクセスするには、ヘルプとサポート センターのホームで、[作業を選びます] の [コンピュータを Windows Update で最新の状態に保つ] をクリックします。

• 複数のアプリケーションに有効と思われるアプリケーション互換性修正プログラムの組み合わせがわかったら、カスタム互換モードを作成します。別のカスタム データベースにカスタム互換モードを追加する必要がある場合は、そのモードをインポートします。

• カスタム データベースを 1 つに統合します。多くの場合、大規模な組織では、アプリケーション互換性テスト プロセスに複数のグループが関与します。通常、それらの各グループは、独自の互換性データベースを生成します。複数のデータベースを 1 つに統合することにより、展開の複雑さが緩和され、データベースが管理しやすくなります。Compatibility Administrator を使用すると、あるデータベースを別のデータベースにコピーできます。詳細については、Compatibility Administrator のヘルプの「Copying Fixes between Databases」を参照してください。

アプリケーション互換性修正プログラムの適用とテスト

互換性の問題があるアプリケーションを見つけた場合は、Compatibility Administrator を使用してアプリケーション互換性修正プログラムを 1 つ、またはいくつか組み合わせて選択してから、アプリケーションをテストし、問題が解決したかどうかを確認します。広範囲にわたる問題に対応するアプリケーション互換性修正プログラムを見つけるには、ソリューション ワークシート (Symptoms.xls) を使用します。

図 9 は、Compatibility Administrator の画面を示しています。

フル サイズのイメージを確認する

左側のペインには、コンピュータ上のすべてのアプリケーション互換性データベースの内容が表示されます。データベースのコンポーネントを選択すると、右側のペインに詳細情報が表示されます。たとえば、左側のペインでカスタム データベースのアプリケーションを選択すると、右側のペインにはアプリケーションのファイル名、アプリケーションに適用される互換モードやアプリケーション互換性修正プログラム、およびアプリケーションの一致情報が表示されます。

アプリケーション互換性修正プログラムを選択してテストするには、次の手順を実行します。

1. [File] メニューの [New] をクリックし、新しいカスタム データベースを作成します。

2. [Database] メニューの [Create New] をクリックし、[Application Fix...] をクリックします。

3. Create New Application Fix Wizard に表示される手順に従って、テストの対象のアプリケーションおよび適用する互換モードまたはアプリケーション互換性修正プログラムを選択し、[Test Run...] をクリックしてウィザードからアプリケーションをテストします。

4. 問題が解決するまで、アプリケーション互換性修正プログラムの選択と再テストを繰り返します。

5. ウィザードに表示される手順に従って、アプリケーションとアプリケーション互換性修正プログラムを対応付けるために使用する情報の種類を選択します。

6. [Finish] をクリックして、データベースにアプリケーション互換性修正プログラムを保存します。

7. [File] メニューの [Save] をクリックしてカスタム データベースを保存し、データベースにわかりやすい名前を付けます。アプリケーション互換性データベースの拡張子は ".sdb" です。

この手順では、カスタム データベースは保存されますが、テスト コンピュータにはデータベースがインストールされません。つまり、次回に Compatibility Administrator を実行せずに同じテスト コンピュータでアプリケーションを実行しても、アプリケーション互換性修正プログラムはアプリケーションに適用されません。アプリケーションを実行するたびにアプリケーション互換性修正プログラムが適用されるようにするには、アプリケーションを実行するコンピュータにカスタム データベースをインストールする必要があります。

メモ　この手順を使用すると、既存のカスタム データベースに、さらに多くのアプリケーションと、関連するアプリケーション互換性修正プログラムを追加できます。また、他のアプリケーション互換性データベースからアプリケーション互換性修正プログラムをインポートすることもできます。

テスト コンピュータにカスタム データベースをインストールするには、次の手順を実行します。

1. Compatibility Administrator で、インストールするカスタム データベースを選択します。

2. [File] メニューの [Install] をクリックします。

互換モードの適用とテスト

アプリケーションをすぐに使用可能な状態にするために、アプリケーションで必要なアプリケーション互換性修正プログラムをテストする代わりに、特定のバージョンの Windows 用に作成されたアプリケーションで共通して必要なすべてのアプリケーション互換性修正プログラムを適用できます。この場合は、パッケージ化済み互換モードを適用できます。パッケージ化済み互換モードは、特定の環境で一般的に発生する問題を解決するためのアプリケーション互換性修正プログラムの集まりです。たとえば、あるパッケージ化済み互換モードには、権限が制限されているユーザーが実行するアプリケーションで一般的に発生する問題に対処するアプリケーション互換性修正プログラムが含まれています。

表 13 は、パッケージ化済み互換モードとその機能を示しています。

表 13. パッケージ化済み互換モード

パッケージ化済み互換モードの適用方法は、次の 2 とおりです。

• Compatibility Administrator を使用して、パッケージ化済み互換モードをカスタム アプリケーション互換性データベースに追加する。

• バッチ ファイルまたはスクリプトを使用して、パッケージ化済み互換モードを直接アプリケーションに適用する。

最も一般的な方法は、Compatibility Administrator を使用して、パッケージ化済み互換モードをアプリケーション互換性データベースに適用する方法です。ただし、アプリケーションが数台のコンピュータにしかインストールされていない場合は、バッチ ファイルやスクリプトを使用して、パッケージ化済み互換モードを直接アプリケーションに適用する方が効率的なことがあります。

Compatibility Administrator によるパッケージ化済み互換モードの適用

Compatibility Administrator を使用すると、任意のパッケージ化済み互換モードをアプリケーション互換性データベースに追加できます。この手順は、このガイドの「アプリケーション互換性修正プログラムの適用とテスト」で説明した手順と同じです。ただし、アプリケーション互換性データベースにアプリケーション互換性修正プログラムを追加するのではなく、表 13 に示すいずれかのパッケージ化済み互換モードを追加します。

バッチ ファイルやスクリプトでの互換モードの適用

互換性の問題があるプログラムを実行するバッチ ファイルやスクリプトを使用している場合は、互換モードをカスタム データベースにパッケージ化して、プログラムが実行されているコンピュータにデータベースを展開する代わりに、バッチ ファイルからパッケージ化済み互換モードを適用できます。バッチ ファイルやスクリプトで互換モードを適用する場合は、バッチ ファイルのコマンドにより開始されるプロセスにこれらのモードが繰り返し適用されるように指定できます。

スクリプトやバッチ ファイルで互換モードを適用するための構文は、次のとおりです。

set __COMPAT_LAYER=[!]CompatModeName1 [CompatModeName2]

"set" キーワードの後には、空白が 1 つとアンダースコアが 2 つ (__) 必要です。CompatModeName は、適用する互換モードの短い名前で、表 14 に定義されています。たとえば、Windows 98 互換モードの場合は Win98 です。パラメータ "!" は、アプリケーションに他のアプリケーション互換性修正プログラムが適用済みの場合に、互換モードが適用されないことを示します。

表 14. 互換モードスクリプトの短い名前

たとえば、Windows 98 と Disable Visual Themes という 2 つの互換モードを適用するには、次のコマンドを実行します。

set __COMPAT_LAYER=Win98 DisableThemes

この方法で互換モードを適用した後では、同じコマンドを互換モードを指定せずに使用して、互換モードを無効にできます。たとえば、バッチ ファイルのあるポイントで必要なくなった互換モードをキャンセルできます。互換モードが有効になっているときに開始されたすべてのプロセスは、互換モードがアクティブな状態のまま、終了するまで実行されます。スクリプトやバッチ ファイルで互換モードをキャンセルするための構文は、次のとおりです。

set __COMPAT_LAYER=

バッチ ファイルでの set コマンドの簡単な使用例については、Microsoft サポート技術情報の Knowledge Base の文書 Q286705「HOW TO: Script Compatibility Layers in Windows XP Professional」(英語情報) を参照してください。この文書を検索するには、「Microsoft Knowledge Base」リンク (http://www.microsoft.com/windows/reskits/webresources
) (英語情報) を参照してください。

カスタム互換モードの作成

アプリケーションで必要なアプリケーション互換性修正プログラムを特定する場合は、複数のアプリケーションで必要な一連の修正プログラムが見つかったり、アプリケーション互換性修正プログラムの追加または削除によるパッケージ化済み互換モードのカスタマイズが必要になったりする可能性があります。この場合は、カスタム互換モードを作成して、複数のカスタム データベースに追加できます。

カスタム互換モードを作成するには、次の手順を実行します。

1. Compatibility Administrator で、カスタム互換モードの追加先のカスタム データベースを選択します。

2. [Database] メニューの [Create New] をクリックし、[Compatibility Mode...] をクリックします。

3. カスタム互換モードにわかりやすい名前を付けて、そのモードに追加するアプリケーション互換性修正プログラムを選択します。

4. [File] メニューの [Save] をクリックし、カスタム データベースに修正プログラムを保存します。

他のカスタム データベースに新しいカスタム互換モードを追加するには、互換モード名を右クリックしたときに表示されるショートカット メニューの [Copy] コマンドと [Paste] コマンドを使用します。

カスタム アプリケーション ヘルプ メッセージの作成

アプリケーション互換性修正プログラムを使用しても互換性の問題を解決できない場合は、最後の手段としてアプリケーション ヘルプ メッセージを作成します。アプリケーション ヘルプ メッセージを使用すると、システムを不安定にしたり、他のアプリケーションに悪影響を与えたりする可能性のあるアプリケーションをユーザーが実行しないようにすることができます。また、アプリケーション ヘルプ メッセージは、アプリケーションが実行されないようにしたり、アプリケーションが実行される前に情報メッセージが表示されるようにしたりします。たとえば、アプリケーションに更新プログラムを適用する必要があることをユーザーに通知して、ベンダの Web サイトの URL を示すことができます。

Microsoft はソフトウェア ベンダと協力して、互換性の問題がある一部のサードパーティ アプリケーション用のパッケージ化済みアプリケーション ヘルプ メッセージを作成しました。パッケージ化済みアプリケーション ヘルプ メッセージは、Windows XP Professional 対応として設計されていない下位レベルのプログラム (ウイルス対策プログラムやディスク アクセス ユーティリティなど) がインストールされないようにするために最もよく使用されます。ユーザーがこれらのプログラムのいずれかをインストールまたは実行しようとすると、メッセージが表示されます。

また、カスタム アプリケーション ヘルプ メッセージを作成することもできます。アプリケーション ヘルプ メッセージは、互換性の問題を解決するのではなく、ユーザーに通知を表示したり、ユーザーの操作を阻止したりするだけなので、他に解決方法がない場合にのみ使用してください。アプリケーション ヘルプ メッセージを使用してアプリケーションが実行されないようにするかどうかにかかわらず、予測される結果や修正プログラムの保存場所を示す情報メッセージが表示されるようにします。

カスタム アプリケーション ヘルプ メッセージを作成するには、次の手順を実行します。

1. Compatibility Administrator で、カスタム アプリケーション ヘルプ メッセージの追加先のカスタム データベースを選択します。

2. [Database] メニューの [Create New] をクリックし、[AppHelp Message...] をクリックします。

3. Create a Custom AppHelp Message Wizard に表示される手順に従って、テスト対象のアプリケーションおよびアプリケーションとアプリケーション ヘルプ メッセージの対応付けに使用する情報の種類を選択します。

4. ウィザードに表示される手順に従って、メッセージのテキストと、メッセージの表示後にアプリケーションが実行されるようにするかどうかを指定します。

5. [Test Run...] をクリックし、新しいアプリケーション ヘルプ メッセージが追加されたアプリケーションをテストします。

6. [File] メニューの [Save] をクリックし、カスタム データベースに修正プログラムを保存します。

適用するアプリケーション互換性修正プログラムの決定

Microsoft® Office Excel スプレッドシート Sypmtoms.xls には、互換性の問題がある 16 ビット アプリケーションに適用できるアプリケーション互換性修正プログラムが示されています。16 ビット アプリケーションの識別方法については、このガイドの「一般的な互換性の問題」を参照してください。

特殊な問題を解決するための方針の特定

アプリケーション互換性修正プログラムを適用したり、ソース コードをデバッグして変更したりするだけでは解決できない特殊な問題があります。アプリケーション互換性修正プログラムでアプリケーションの問題が解決しない場合は、以下のいずれかの方法を試してください。

• 問題のあるアプリケーションが Windows 95、Windows 98、または Windows Millennium Edition 用に作成されたものである場合は、管理者アカウントを使用してアプリケーションをインストールします。これらのバージョンの Windows では管理者アカウントと制限付きユーザー アカウントが区別されないので、これらのバージョンで実行されるアプリケーションは、Windows XP Professional では許可されていない場所に書き込みを行う可能性があります。

• Windows での Java プログラムの実行を可能にする Microsoft Java 仮想マシンの最新バージョンを使用します。

• コンピュータを Windows XP Professional にアップグレードし、アプリケーションと Windows XP Professional との互換性があると Windows カタログに記載されている場合は、そのアプリケーションを削除し、アップグレードしてから再インストールしてください。Windows XP Professional でアプリケーションを削除して再インストールしても問題が解決しない場合は、アプリケーションが完全に削除されていない可能性があります。手動でアプリケーションを削除する方法については、アプリケーション ベンダに問い合わせてください。たとえば、アプリケーションを完全に再インストールするために特定のフォルダやレジストリ エントリを削除したり、システムの復元を実行したりする必要があることがあります。

• アプリケーションで Microsoft Data Access Components (MDAC) と DirectX が使用されている場合は、これらが最新バージョンであることを確認します。Windows XP Professional は、MDAC 2.7 Service Pack 1 と DirectX 8.1 をサポートしています。一部の古いアプリケーションでは、以前のバージョンの MDAC や DirectX のインストールを試みますが、これが問題の原因となる可能性があります。

• アプリケーションが Kodak Image Edit コントロールに依存していないことを確認します。このコントロールは、Windows XP Professional では削除されています。

• 一部の古いアプリケーションでは、31 文字を超える名前を持つネットワーク プリンタでの印刷が試行されると、エラーが発生します。この問題を防ぐには、このアプリケーション専用の、ネットワーク プリンタへのローカル接続を作成します。

ローカル プリンタへの接続を作成するには、次の手順を実行します。

1. プリンタの追加ウィザードを起動します。

2. [ローカル プリンタまたはネットワーク プリンタ] ページで、[このコンピュータに接続されているローカル プリンタ] をクリックし、[プラグ アンド プレイ対応プリンタを自動的に検出してインストールする] チェック ボックスをオフにします。

3. [プリンタ ポートの選択] ページで、ポートが一覧にあれば、それを選択します。ポートが一覧にない場合は、[新しいポートの作成] をクリックし、[ポートの種類] の [Local Port] を選択します。

4. [次へ] をクリックします。[ポート名] ウィンドウが表示されるので、プリンタのポート名を次の形式で入力します。

   \\<PrintServer>\<PrinterName>

5. [プリンタ ソフトウェアのインストール] ページで、プリンタの製造元と適切なプリンタを選択します。

6. [既存のドライバを使う] ページで、現在のドライバがある場合は、[現在のドライバを使う] をクリックします。

7. [プリンタ名] ページで 30 文字以下の名前を入力し、使用している環境に応じた設定を行い、ウィザードを終了します。

Virtual PC による互換性の問題解決

Microsoft® Virtual PC 2004 を使用すると、2 つ以上のオペレーティング システムをコンピュータ上で実行できます。Virtual PC の詳細については、http://www.microsoft.com/japan/windows/virtualpc/default.mspx を参照してください。複数のゲスト オペレーティング システムを仮想マシンにインストールします。各仮想マシンは、スタンドアロン コンピュータのように動作します。各マシンには、仮想プロセッサと仮想メモリ、および固有のサウンド カード、ビデオ カード、ネットワーク カードがあります。Microsoft では、この製品を Windows XP Professional、Windows XP Home Edition、Windows 2000 Professional、Windows NT® Workstation 4.0、Windows Millennium Edition、Windows 98、Windows 95、MS-DOS®、OS/2 Warp Version 4 Fix Pack 15、OS/2 Warp Convenience Pack 1、および OS/2 Warp Convenience Pack 2 をゲスト オペレーティング システムとして使用するよう開発およびテストしています。ただし、ほとんどの x86 ベースのオペレーティング システムを Virtual PC にインストールして実行できます。仮想マシンにインストールしたアプリケーションは正常に動作します。

Virtual PC は、Application Compatibility Toolkit を使用して修正できない残りのレガシ アプリケーションをサポートする低コストなセーフティ ネットを提供します。新しいプラットフォームへの移行を継続する間、特定の従業員がミッションクリティカルなレガシ アプリケーションを一時的に実行できます。互換性のないアプリケーションの置き換えまたは更新が終わるまで展開プロジェクトを遅延する必要はありません。その代わりに、Windows XP Professional と互換性のないアプリケーションを実行する必要のあるユーザーに対して、Windows XP Professional を展開し、さらに Virtual PC を展開することができます。移行が完了してレガシ アプリケーションを更新できたら、それらのコンピュータから Virtual PC を削除し、Windows XP Professional にインストールできます。Application Compatibility Toolkit では修正できない若干のアプリケーションについて、Virtual PC は、Windows XP Professional への移行を継続する間それらをサポートします。

Application Compatibility Toolkit では、ユーザーが所有する互換性のないアプリケーションの大部分を修正できます。ツールキットは、それ自体では必ずしも完全なソリューションというわけではありません。同様に、Virtual PC を使用して互換性のないすべてのアプリケーションを実行するのはお勧めできるソリューションではありません。これは主に、ソリューションがもはや一時的なものではなく、デスクトップ構成の永続的な一部となり、企業内のより多くのユーザーに影響するためです。Application Compatibility Toolkit と Virtual PC を組み合わせて使用することで、互換性の問題を効率良く処理できます。このシナリオを実行する手順は次のとおりです。

1. アプリケーションのインベントリを作成します。Application Analyzer を使用して企業内のアプリケーションのインベントリを収集し、Microsoft のオンライン互換性データベースに対してそのインベントリの分析を行います。

2. 重要なアプリケーションをテストします。オンライン互換性データベースのデータによって企業内のほとんどのアプリケーションの互換性に関する情報が提供される場合でも、Application Verifier および Application Compatibility Toolkit のドキュメントで提供されるテスト方法を使用して、ビジネスクリティカルなアプリケーションをテストします。

3. 互換性の各問題に対処します。互換性のない各アプリケーションに対して、以下のいずれかの処理を行います。

   • Compatibility Administrator を使用して、互換性データベースにアプリケーションの修正プログラムをパッケージ化する。

   • Virtual PC イメージにアプリケーションを追加する。Application Compatibility Toolkit を使用して修正できないアプリケーションの場合、Virtual PC イメージの構築および展開は、オプションのセーフティ ネットです。イメージに追加するアプリケーションは、Application Compatibility Toolkit では修正できないアプリケーションです。これらは修正が非常に困難であるか、またはオペレーティング システム移行スケジュールを考慮すると修正に時間がかかりすぎます。

   
   

4. Windows XP Professional および Virtual PC イメージを展開します。Windows XP Professional 展開の前の手順で作成した互換性データベースを含めます。このデータベースは、テストで見つかった互換性の問題の (すべてではなくても) 多くを修正します。修正プログラムがデータベースにないアプリケーションを必要とするユーザーについては、Application Compatibility Toolkit で修正できないアプリケーションを含む、前の手順で作成した Virtual PC および Virtual PC イメージを展開します。ただし、以下の要件を持つアプリケーションは仮想マシンで実行できないため、別の解決方法を見つける必要があります。

   • ハイエンド グラフィック カードが必須

   • 対称型マルチプロセッシングが必須

   • 複数のプロセッサが必須

   • USB ハードウェアへのアクセスが必須 (USB スキャナおよびスマート カード リーダーは Virtual PC でサポートされていません)

   • 3.6 GB 以上のメモリが必須 (実行するすべての仮想マシンに対して最大 3.6 GB)

   • サウンド カードへのアクセスが必須

   
   

5. Virtual PC を使用して、展開後の互換性の問題をサポートします。Windows XP と互換性のないアプリケーションの問題についてユーザーから報告があった場合は、それらのアプリケーションをユーザーの Virtual PC イメージに追加します。

Microsoft では、Virtual PC を使用してアプリケーションの互換性の問題を解決するためのガイダンスを提供しています。ホワイト ペーパー『Microsoft Virtual PC 2004 の展開』(http://www.microsoft.com/japan/windows/virtualpc/techinfo/deploy.mspx) では、管理者による操作なしに多数のユーザーに Virtual PC と仮想マシンを展開する方法について詳しく説明しています。ホワイト ペーパー『Microsoft Virtual PC 2004 技術概要』(http://www.microsoft.com/japan/windows/virtualpc/evaluation/techoverview.mspx) では、Virtual PC とそのコンポーネントの技術概要を示します。

マイルストーン : アプリケーション ポートフォリオの安定化

マイルストーンは、ソリューション全体における同期ポイントです。詳細については、Solution Accelerator for BDD の『計画、構築、および展開ガイド』を参照してください。このマイルストーンでは、アプリケーション互換性機能チームが、アプリケーション補足機能チームに引き渡すことのできるアプリケーション ポートフォリオを安定化させます。

成果物

関連リンク

• Deployment Center
  Active Directory をはじめ Windows XP Professional や Office 2003 Editions の効率的な展開方法をまとめたガイダンスを提供しています。

ダウンロード

Solution Accelerator for Business Desktop Deployment ガイド (Version 2.0)
25.8MB
圧縮した Word ファイル
最終更新日: 2005年10月3日

目次

• このガイドの使用方法
• アプリケーションの互換性の概要
• アプリケーションの互換性の問題解決のスコープと目標の定義
• アプリケーション互換性のテスト計画の作成
• 追加アプリケーション展開