Comments
Description
Transcript
Rational Functional Tester 活用 活用ガイド –
Rational Functional Tester 活用ガイド 第４版 活用ガイド –第 テスト自動化 テスト自動化計画 自動化計画編 計画編 © Copyright 2009 IBM Corporation Rational Functional Tester 活用ガイド 目次 ０．RFT 活用ガイド 活用ガイド-テスト の位置づけ 位置づけ ............................................................- 2 ガイド テスト自動化 テスト自動化計画 自動化計画編 計画編-の １．テスト自動化 3テスト自動化の 自動化の前に検討・ 検討・決定しておくと 決定しておくと良 しておくと良いこと........................................................いこと １．１ テスト自動化範囲 テスト自動化範囲の 検討 3自動化範囲の検討.........................................................................................１．２ RFT スクリプト作成開始 スクリプト作成開始の 作成開始の時期 .............................................................................- 4 １．３ RFT 担当者の 担当者のアサインと アサインとスキル習得 スキル習得について 習得について .......................................................- 4 １．４ プロジェクトの プロジェクトの分割単位を 分割単位を検討する 検討する ......................................................................- 5 １．５ シナリオ粒度 シナリオ粒度を 検討する.........................................................................................5粒度を検討する する １．５．１ スクリプトの分割単位を工夫する ...............................................................- 5 １．５．２ デバッグしやすい工夫をする.......................................................................- 6 １．６ レポートの 6レポートの出し方、レビュー方法 レビュー方法を 方法を検討する 検討する........................................................する １．７ RFT に関する情報 する情報の 収集 8情報の収集........................................................................................２．スクリプトの 10 スクリプトの保守について 保守について..............................................................................................について ２．１ アプリケーション変更時 アプリケーション変更時に 発生するメンテナンス 10 変更時に発生する するメンテナンス...............................................メンテナンス ２．２ スクリプトの スクリプトのメンテナンス性 メンテナンス性を高めるポイント めるポイント .................................................. - 11 ２．２．１ テスト対象を１つの URL コンテキストルートにまとめる ....................... - 11 ３．テスト資産 テスト資産の 資産の管理 ............................................................................................................- 14 ３．１ テスト資産 テスト資産の 資産の管理 .................................................................................................- 14 ３．２ RFT をバージョンアップした バージョンアップした際 した際の、テスト資産 テスト資産の 資産のアップグレード ....................- 14 ４．テスト管理 テスト管理ツール 15 管理ツールとの ツールとの連携 との連携..............................................................................................連携 © 2009 IBM Corporation - 1 - Rational Functional Tester 活用ガイド ０．RFT 活用ガイド の位置づけ 活用ガイド-テスト ガイド テスト自動化 テスト自動化計画 自動化計画編 計画編-の 位置づけ 当ガイドは、Rational Functional Tester(以降、RFTと記述)を活用するにあたり、テスト自動 化を推進するリーダー、テストチームのリーダーなど、現場全体の視点からリードしていく役割 の方向けのガイドです。RFTを導入して機能テストの自動化を推進するにあたり、よくある事例 などを用いながら自動テストを成功させるコツを述べています。テスト計画を立てる際にご活用 ください。 管理者のみでなく、実際に RFT を利用してテストスクリプトを作成・運用するテスト担当者の 方にとっても、知っておくことで事前にトラブルを回避できるようなヒントを記載しています。 © 2009 IBM Corporation - 2 - Rational Functional Tester 活用ガイド １．テスト自動化 テスト自動化の 自動化の前に検討・ 検討・決定しておくと 決定しておくと良 しておくと良いこと 実際にテストを開始する前に「テスト計画」が必要なのと同じように、テストの「自動化」を 始める際にも自動化の「計画」が必要です。 ・目的（何のためにテストを自動化したいのか） ・スケジュール（いつまでに自動テストを実施する必要があるのか） ・リソース（マシンやライセンスの手配、担当者のアサイン） ・制約（どれくらいの工数がかけられるのか、テスト担当者のスキルセットは決まっているか） 評価が必要であれば、自動化を実施したことによる効果の測定方法（測定したい数値・メトリク スとその測定方法）も検討しておく必要があるでしょう。 この章では、実際に RFT による自動化を始める前にぜひ検討しておくべきポイントを説明しま す。 １．１ テスト自動化範囲 テスト自動化範囲の 自動化範囲の検討 「せっかく RFT を活用してテスト自動化を図るのだから、”全てのテストケース”を自動化し て効果を最大化しよう」と考えるチームは多いと思います。しかしながら「全て自動化すること ＝効果の最大化」ではない場合も実際にはあります。自動化に取り組む目的を明確にしておくと、 後々のトラブルを回避できるでしょう。 特に、RFT 導入初期の段階で急速に自動化を推し進めると、スキル習得と自動化に想定以上 の工数がかかり、結果的に「チームへの適用失敗」に陥るケースもありますので、注意が必要で す。導入初期段階では、比較的短いスクリプトや単純なスクリプトの自動化から着手する方がリ スクを抑えることができます。 RFT は、スクリプト作成からすべて自律的に実施をしてくれるツールではなく、初期導入時 には「人手によるテストスクリプト作成」 、アプリケーションの変更時などには「人手によるメ ンテナンス」が必要になります。「自動化テストによって削減される工数」が「人手の場合にか かる工数」を上回るほど、導入の効果は高くなります。 典型的な例では「繰り返し実行する機会が多いシナリオ」や「単純なシナリオだが、いろいろ なデータでバリエーションをテストしなければならないケース」に自動化ツールを適用すると、 効果は大きくなりやすいと言えます。 逆に、「時々しかテストしない」、「反復して同じテストをする機会はない」、 「スクリプト作成に 非常に手間がかかる（条件分岐が多い複雑なテストなど） 」のような場合には、削減工数よりも スクリプト作成やメンテナンスの手間が大きくなってしまい、テストツールを利用する効果は期 待しづらくなります。 RFT を現場のテスト自動化に適用する際、 「着実な効果を得る」ことが目的の場合は、まず、 シンプルで効果の出やすいシナリオを優先的に自動化する方針をお勧めします。 全テストのうち、一部を自動化するだけでも、十分に効果はあるはずです。 © 2009 IBM Corporation - 3 - Rational Functional Tester 活用ガイド 特に、 「単調、単純、反復が多い」タイプのテストケースの実施は、人間の手作業で実施する と集中力が失われやすく、モチベーションの低下による「操作ミス」 、 「生産性の低下」を招きが ちです。このようなポイントを自動化すると、効果が非常に高くなります。 １．２ RFT スクリプト作成開始 スクリプト作成開始の 作成開始の時期 自動化スクリプトを作成し始めるタイミングも重要な要素の 1 つです。 アプリケーションの開発と並行してテストスクリプトを作成する場合は注意が必要です。アプリ ケーションに変更が入る可能性が高い時期にスクリプトを作成してしまうと、アプリケーション の変更が入るたびに、スクリプトの修正作業を伴う可能性が高いためです。 一般的には、アプリケーションの開発がある程度収束し、アプリケーションが安定したタイミ ングで RFT スクリプトの開発を進めるほうが効率的です。具体的には、URL の変更や、スタイ ルシートの変更などが発生する可能性があれば、それよりも後にテストスクリプトを作成し始め たほうが良いと言えます。アプリケーション開発と並行して RFT スクリプト作成に着手する必 要があるケースでは、URL を正規表現にして記録するなど、スクリプトの作り方を工夫するこ とによって、後々に発生する修正作業を軽減させることが出来ます。 １．３ RFT 担当者の 担当者のアサインと アサインとスキル習得 スキル習得について 習得について RFT を活用してテストの自動化を進める場合、RFT スクリプトを作成するメンバーが必要で す。初めて RFT スクリプトを作成する役割を担うメンバーは、まず RFT を使いこなすためのス キル習得の期間が必要です。 RFT を活用するためには、「RFT の機能を活用し、必要に応じて簡単なスクリプトの編集が 行えるスキル」と、「テスト管理の視点を持って、全体の運用イメージを決定するスキル」の 2 タイプのスキルが必要です。テストスクリプト作成の役割を持ったメンバーには、前者のスキル が求められます。（後者のスキルがあればなお効果的なテストを行うことが出来るでしょう。） 前者のスキルについて、基本的な RFT の操作方法は、一般的には半日～1 日程度の学習によ って身に着けることが可能と考えられます。RFT は基本的な作業を GUI 操作にて進めることが 出来るため、初心者にとっても比較的簡単に操作感や使い方を身に着けていただくことが出来る ことが特長です。基本的なスキルは、RFT の製品に付属しているヘルプやチュートリアルを活 用することによって、独力で学習することが可能です。効率よく学習を進めたい場合には、IBM が提供している研修を受講されることも効果的です。 さらに、トラブル発生時の対処、スクリプトの拡張などのより高度なスキルを獲得する場合に は、「テスト自動化」「Java コーディング」「問題判別」などの汎用的な知識が必要となって きます。これについては個人の経験や、Java コーディングのスキルによっても、習得期間は異 なってきます。 しかしながら、高度なスキルが必要となる場面はある程度一般化できるため、本ガイドの「テ スター編」ではそのような「よくあるトラブル」、「よくある拡張に対するサンプルスクリプト」 © 2009 IBM Corporation - 4 - Rational Functional Tester 活用ガイド などをあらかじめガイドとして提供しています。高度なスキルが必要となった際には、当ガイド や RFT のヘルプを参照すると、対処のためにかかる工数を最低限に抑えることが出来ます。 １．４ プロジェクトの プロジェクトの分割単位を 分割単位を検討する 検討する RFT で作成するスクリプトやテストログ、テストデータは「Functional Test プロジェクト」 に格納されます。プロジェクトの作成単位についても、テストの開始前に決定しておく必要があ ります。例えば、 「見やすさ」 「管理しやすさ」を考慮するのであれば、テスト対象のアプリケー ションや機能に対し１プロジェクトを作成すると良いでしょう。 その他、作業チームごと、個人ごとにプロジェクトを作成する場合もあります。 また、1 台の RFT マシンを複数チームで共有する場合、誤って他チームのリソースを変更し てしまうことを防ぐため、プロジェクトだけでなくワークスペースをチーム単位で分けておくこ とをお勧めします。 １．５ シナリオ粒度 シナリオ粒度を 粒度を検討する 検討する １．５．１ スクリプトの分割単位を工夫する 1 つのスクリプトをどのような単位で分割するかも、事前に検討しておくべき項目です。 テストスクリプトは、テストケースの「最初から最後まで」を 1 スクリプトにすることも可 能ですし、意味のある単位でシナリオを分割し、複数のスクリプトを組み合わせて 1 テストケ ースを構成する方法もあります。複数シナリオにて共通の手順の部分がある場合は、分割してお くと、記録やメンテナンスの負荷が軽減されます。（例えば、 「アプリケーションにアクセスし、 ログインする」という部分が全シナリオに共通であれば、 「ログイン」というスクリプトを 1 つ 作って置き、各テストケースで再利用します。） 複数のスクリプトをまとめて実行する場合、後始末作業などの手作業が必要ない順序でシナリ オを組めばテスト効率がアップします。例えば、ファイルの登録・更新・削除のできるアプリケ ーションでは、登録スクリプト→更新スクリプト→削除スクリプトと配置しておくことでファイ ルを削除する後始末をせずに何度でもテストが実施できます。このように何度も繰り返し実施す ることを意識することが重要です。 「登録スクリプトが失敗していた場合、更新スクリプトは必ず失敗する」など複数スクリプト の間に依存関係がある場合は、各スクリプトの前提となるスクリプトがどれかを整理しておくこ とで問題判別が容易になります。例えば、依存関係表にスクリプト（TS）9 の前提はスクリプ ト 3 と記述されている場合、スクリプト 9 が失敗していた時にはまず前提であるスクリプト 3 の結果が成功かどうかを確認して、スクリプト 9 内の問題かどうかを切り分けます。 例. ユースケース UC100 テストケース TC300 © 2009 IBM Corporation スクリプト TS9 前提スクリプト TS3 実行結果 ○ - 5 - Rational Functional Tester 活用ガイド また、スクリプトの始点と終点は統一させておくと後々順番を入れ替えたくなった際に容易に 入れ替えることができます。例えば、どのスクリプトも Top ページで始まり個別の処理を行っ て Top ページまで戻って終了するように統一するなどです。 １．５．２ デバッグしやすい工夫をする テスト作業を行っていると、スクリプトをデバッグしたい場面があります。この時に例えば 100 スクリプトの中の 70 番目だけを流せるような仕組みがあると作業効率がアップします。そ のためには直前のスクリプトが終了した状況を再現できるような工夫を行います。例えば DB に データを蓄積しているアプリケーションであれば、69 番目のテストが終了したところでテスト を中断し、その時点の DB のバックアップを取ります。これにより、69 番目終了時の DB バッ クアップデータをインポートすることで 70 番目スクリプトのデバッグ作業を繰り返すことがで きます。 スクリプトの数が非常に多い場合は、計画時点で適度な単位に小分けにしておき、それらの間 に DB をバックアップするスクリプトを挟みつつ一つにまとめておけば、毎回の実行中の途中時 点の DB 状況を残すことができて便利です。 （DB からエクスポートする処理などをバッチとし て作成しておき、そのバッチファイルを実行するスクリプトを挟みます） １．６ レポートの レポートの出し方、レビュー方 レビュー方法を検討する 検討する 自動テスト実行後、RFT のテストログが出力されます。レポートの出力形式は HTML（デフ ォルト）とテキストの 2 種類が選択可能です。（ 「ウィンドウ-設定-Functional Test-再生-ロギン グ」にて変更可能） RFT のログをテストのエビデンスとする場合には、どのような情報をログに含めたいか検討 しておく必要があります。RFT のログには、以下のような情報が出力されます。 スクリプトの開始 スクリプトの終了 callScript メソッドの呼び出し（別スクリプトの呼び出し） startApp メソッドの呼び出し（アプリケーションの起動） タイマーの開始 タイマーの終了 例外 検査ポイント ※ タイマーは任意の箇所で実行所要時間を測定することができます。 ※ 例外が発生した場合には RFT の基本機能により、実行時の画面ショットが取得されます。 ログの例 © 2009 IBM Corporation - 6 - Rational Functional Tester 活用ガイド タイマー開始点 リンクをクリックしてコンパ レーターを開く 検査ポイントの「期待値」と 「実際値」を比較 タイマー終了点 （経過時間を表示） その他にJavaコードを追加して、テスト中の画面ショットやテスト中の画面から取得したデー タなどをテストログに出力させることが可能です。ただし、その場合にはコーディングにかかる 時間もあらかじめ考慮しておく必要があります。（画面ショットの取得方法は本ガイド「テスタ ー編」の５．１節「画面ショットをログに含める」の項目をご覧ください） また、遷移した全ての画面ショットをテストログに添付するとログのサイズが大きくなりすぎ、 管理が難しくなる場合がありますのでご注意ください。 © 2009 IBM Corporation - 7 - Rational Functional Tester 活用ガイド １．７ RFT に関する情報 する情報の 情報の収集 RFT を活用していくにあたり、必要な情報や最新の情報などを事前に収集しておくことをお 勧めします。 RFT に関連する情報源を下記に掲載します。 （2009 年 6 月現在） ◆RFT がサポートするテスト対象アプリケーション環境について◆ RFT v8.0 でサポートされているテスト対象アプリケーションの情報は、ヘルプの「製品概要」 ＞「Rational Functional Tester の概要」＞「テスト・アプリケーション・ドメイン・サポート」 の項目をご覧ください。 RFT v8.0 Information center http://publib.boulder.ibm.com/infocenter/rfthelp/v8r0m0/index.jsp ◆RFT インストール◆ IBM Rational Functional Tester V8.0 導入ガイド 導入ガイド http://www.ibm.com/developerworks/jp/rational/library/qm/rft/v8/intro_guide/index.html RFT のインストール手順を掲載しています。 Release Notes RFT インストール終了後、 「すべてのプログラム」＞「IBM Software Delivery Platform」＞「IBM Rational Functional Tester」＞「Release Notes」をクリックし、リリースノートを確認するこ とが出来ます。インストールした RFT のバージョンにおける参考情報、注意事項などが掲載さ れているので、一通り目を通しておくことをお勧めします。 ◆ RFT の基本的な利用方法◆ IBM Rational Functional Tester V8.0 評価ガイド 評価ガイド http://www.ibm.com/developerworks/jp/rational/library/qm/rft/v8/eval_guide/index.html RFT を初めて操作する方向けの手順を解説しています。 RFT のヘルプ RFT のメニューバーから「ヘルプ」＞「ヘルプ目次」で参照することが出来ます。 また、下記 URL にアクセスすることにより、オンラインでもヘルプの内容を見ることが出来ま す。 （RFT のヘルプから閲覧できる内容と同様のものです） © 2009 IBM Corporation - 8 - Rational Functional Tester 活用ガイド RFT Information center http://publib.boulder.ibm.com/infocenter/rfthelp/v8r0m0/index.jsp ◆RFT の便利な使い方、Hints & Tips◆ 本書「テスター編」にてまとめています。 ◆RFT のスクリプト拡張◆ RFT のメニューバーから「ヘルプ」＞「Functional Test API Reference」で参照することが出来 ます。 ◆他ツールとの連携◆ Rational Quality Manager テストツール連携 テストツール連携ガイド 連携ガイド http://www.ibm.com/developerworks/jp/rational/library/qm/rqm/TestToolIntegration/ テスト管理ツール「IBM Rational Quality Manager」と RFT を連携させる手順が掲載されていま す。 © 2009 IBM Corporation - 9 - Rational Functional Tester 活用ガイド ２．スクリプトの スクリプトの保守について 保守について テスト対象アプリケーションに何かしらの変更が生じた際は、RFT のテスト資産（テストス クリプト、オブジェクト・マップ、など）に対しても修正が必要となる場合があります。一旦作 成したテストスクリプトは、より多く活用し、可能な限り再利用することが出来れば効果が高く なりますので、どのようなケースでメンテナンスが発生するのかを把握しておくと、RFT スク リプトを最大限に生かすことが出来ます。 ここでは、代表的なメンテナンス発生ポイントと、メンテナンス性を高めるコツを紹介します。 ２．１ アプリケーション変 アプリケーション変更時に 更時に発生する 発生するメンテナンス するメンテナンス テスト対象アプリケーションに変更が発生する場面は幾つかありますが、主なケースとしては 下記が挙げられます。 ・ テスト対象アプリケーションの URL が変更された（サーバーの移行など） ・ 画面上のオブジェクトの複数（通常、３つ以上）の属性に変更が発生した ・ 画面レイアウトの変更で、上位階層に部品が追加された 次ページに、アプリケーションの変更に伴うメンテナンスの必要度の例を示した図を掲載しま す。操作対象のオブジェクトのプロパティー値の変更時（例えば、ボタンのラベル変更など） 、 わずかな変更であれば ScriptAssure の機能によって差異が吸収されるため、スクリプトの修正 を行わなくてもスクリプトを正常に実行させることが可能です。変更箇所が複数に及ぶ場合など はオブジェクト・マップの更新を行い、最新のプロパティー値との整合性を保つことによって既 存のスクリプトを活用することが出来ます。これらのケースでは、テストスクリプトへの影響度 は比較的小さいと言えます。 操作対象のオブジェクトの階層構造が変更された場合は、オブジェクト・マップの更新のみで は対応出来ない可能性があります。新規のオブジェクト情報をオブジェクト・マップに取り込み、 さらにスクリプトを修正し、新しいオブジェクト情報を使わせるように関連付ける必要がありま す。また変更箇所が多岐に渡るなど、スクリプトとオブジェクト・マップの修正を実施するより も、新規にスクリプトを記録し直したほうが良いケースもあります。 アプリケーションの画面遷移先や、操作手順など、テストシナリオ自体が変わってしまってい る場合には、通常はスクリプトを新規に記録し直します。 © 2009 IBM Corporation - 10 - Rational Functional Tester 活用ガイド ２．２ スクリプトの スクリプトのメンテナンス性 メンテナンス性を高めるポイント めるポイント ２．２．１ テスト対象を１つの URL コンテキストルートにまとめる Web アプリケーションをテストする際は、記録時と実行時で同一の URL コンテキストルート （例えば http://localhost/～など）となるようなテスト環境をお勧めします。 異なる URL コンテキストルート（例えば記録時が http://localhost/～、再生時が http://testserver/ ～など）に対してテストを行う場合は、正規表現を使って対応します。こちらはオブジェクトマ ップのプロパティに埋め込まれている URL 情報を正規表現とすることで、URL が変更されても 相違を許容させることができます。ただし、正規表現に設定する作業にかなり手間がかかってし まうケースもありますので、計画時点でなるべく URL コンテキストルートの変更を避けること をお奨めします。 正規表現を利用する場合は、次ページのようにオブジェクトマップにてプロパティの値を右ク リックして変更することができます。 © 2009 IBM Corporation - 11 - Rational Functional Tester 活用ガイド 記録時と再生時にホスト名の変更が必要になる場合には、Hosts ファイルとアプリケーション の構成を変更することで対応します。 【 A. スクリプト記録時 スクリプト記録時】 記録時】 １．Hosts ファイルにアクセス先サーバーの IP アドレスとホスト名を登録します 例）1.22.220.1 pc1 参考：Hosts ファイルのパス（Windows XP の場合） C:¥WINDOWS¥system32¥drivers¥etc¥hosts ２．RFT でアプリケーションの構成を行ないます ・ RFT のメニューより 「構成」 > 「アプリケーションをテスト用に構成する」を選択 ・ 「追加」ボタンを押下 ・ 「HTML アプリケーション」を選択して、 「次へ」を押下 ・ URL 欄に１で登録したホスト名による URL を入力 IP アドレスや localhost で登録しないこと 例） 名前 – ebizApp URL - http://pc1:9080/init 【B. サーバー変更時 サーバー変更時】 変更時】 © 2009 IBM Corporation - 12 - Rational Functional Tester 活用ガイド １．Hosts ファイルに登録したアクセス先サーバーの IP アドレスを変更します ホスト名は変更しないようにします。 例） （変更前）1.22.220.1 pc1 ↓ （変更後）1.22.220.2 pc1 ※ 上記の方法であれば、スクリプトには URL は書き込まれずアプリケーション構成の名前の みが書き込まれるため、スクリプトの変更は必要ありません。 例）RFT スクリプト startApp(“ebizApp”); //「アプリケーションの構成」で登録した「名前」で起動 ※ スクリプト内のオブジェクトには URL を保持しているものもありますが（Html.document や） 、URL がホスト名であれば、Host ファイルで切り替えられるので変更の必要はありません。 （ホスト名以外が変わる場合には、全てを手作業で修正する必要があります。 ） © 2009 IBM Corporation - 13 - Rational Functional Tester 活用ガイド ３．テスト資産 テスト資産の 資産の管理 ３．１ テスト資産 テスト資産の 資産の管理 RFT で作成されたテストスクリプトやテストログなど、一連のテスト資産は、全て Functional Test プロジェクトに含まれています。重要なテスト資産は特にプロジェクトのバックアップ を取得しておくことをお勧めします。 また、長期に渡って RFT を活用する場合、テスト対象アプリケーションの更新に伴って、そ れをテストする RFT スクリプトも更新されることが予想されます。テストスクリプトを直に修 正して更新した場合、過去に動作していた時点のテストスクリプトは上書きされることになりま す。過去に動作していた時点のスクリプトが必要になると考えられる場合には、テストスクリプ トのバージョン管理をしておくと便利です。特に、アプリケーション環境のバージョンと RFT スクリプトのバージョンをセットで管理しておくと、過去のテストをスムーズに再現できるメリ ットがあります。 ３．２ RFT をバージョンアップした バージョンアップした際 した際の、テスト資産 テスト資産の 資産のアップグレード 使用する RFT のバージョンを上げた場合、既存の Functional Test プロジェクトもマイグレー ションすることが推奨されます。 RFT のプロジェクトは上位互換性があるため、古いバージョンで作成したプロジェクトを、 上位のバージョンの RFT で稼動することが可能です。しかし逆に、新しいバージョンの RFT で 作成したプロジェクトを、それより古いバージョンの RFT で稼動することは出来ません。 また、一旦マイグレーションした RFT のプロジェクトは、元のバージョンの RFT で動くように 戻すことが出来ませんのでご注意ください。（マイグレーション前のプロジェクトのバックアッ プを保管しておくことを推奨します） © 2009 IBM Corporation - 14 - Rational Functional Tester 活用ガイド ４．テスト管理 テスト管理ツール 管理ツールとの ツールとの連携 との連携 RFT はテストの自動化を支援する製品ですが、テスト計画やテストケースなどの情報と関連 付けてテスト全体を管理するためには、テスト管理ツールと RFT を連携させて活用する方法が 効果的です。 IBM Rational Quality Manager（RQM）は、効果的にテスト管理を行うことが出来る製品であり、 RFT などのテスト自動化ツールとの連携をサポートしています。 RQM では、テスト計画やテストケースを作成・管理することができ、RFT のスクリプト情報を 関連付けて、RQM から RFT のスクリプトを実行することが出来ます。 RQM 連携の詳細については、Rational Developer Domain に関連ドキュメントが公開されてお りますので、ぜひご一読ください。 【IBM Rational Quality Manager の関連情報】 Rational Quality Manager テストツール連携ガイド http://www.ibm.com/developerworks/jp/rational/library/qm/rqm/TestToolIntegration/ Rational Quality Manager 導入ガイド http://www.ibm.com/developerworks/jp/rational/library/qm/rqm/InstallationGuide/ Rational Quality Manager 評価ガイド - IBM Rational Quality Manager を使用してプロジェク トを管理しよう http://www.ibm.com/developerworks/jp/rational/library/qm/rqm/EvaluationGuide/ © 2009 IBM Corporation - 15 -