ソフトウェア構成管理は、ソース管理、変更管理、およびバージョン管理とも呼ばれることがあります。
一般に、ソフトウェア構成管理システムは、複数の開発者による共通のファイルの同時作業が行われるソフトウェア開発グループによって使用されます。 2 人の開発者が同じファイルを変更した場合、このファイルは上書きされ、重要なコード変更が失われることがあります。 ソフトウェア構成管理システムは、マルチユーザー環境でファイルを共有する場合に発生する固有の問題を回避するよう設計されています。
どのソフトウェア構成管理システムでも、中央リポジトリーが作成され、ファイルの共有が容易になります。 共有する各ファイルは中央リポジトリーに追加して、ファイルの最初のバージョンを作成する必要があります。 ファイルが中央リポジトリーの一部になった後に、ユーザーはそのファイルにアクセスし、かつこれを更新し、新規バージョンを作成することができます。
チェックアウト操作により、変更可能なファイルのローカル・コピーが作成されます。 ファイルの作業が問題なく完了したら、作業済みのファイルをチェックインして新規バージョンを作成します。 元のファイルは常に存在します。
マルチユーザー環境では、多数のユーザーが同じファイルを同時にチェックアウトすることがよくあります。 この場合、「マージ」と呼ばれるソフトウェア構成管理システムの特殊機能を利用することにより、複数の変更を結合して 1 つのファイルに取り込むことができます。 ファイルをチェックインする最初のユーザーは新規バージョンを作成します。2 番目にファイルのチェックインを行うユーザーは、自分の変更をそのバージョンにマージしなければなりません。ソフトウェア構成管理システムが変更を結合できる場合には、ファイルの新規バージョンにマージされます。しかし、変更が競合するか、またはソフトウェア構成管理システムが解決できない場合には、手動で競合を解決する必要があります。
ソフトウェア構成管理システムを使用したことがなかったり、またはその概念をよく知らない場合には、自分のプロジェクトにソフトウェア構成管理システムを導入することが適切かどうかを疑問に思うユーザーもいるかもしれません。テストの自動化は、ソフトウェア開発における取り組みの 1 つでした。記録によるかコーディングによるかを問わず、テスト・スクリプトが作成されるたびに、コードを含むファイルが生成されます。そのコードは、作成時、開発時、または編集時のいずれの場合にも、重要な資産になります。
チーム環境では、ファイルの上書きによって、機能するコードが失われたり、テスト・スクリプトが中断するリスクがあります。ソフトウェア構成管理システムは、このリスクを克服する方法を提供します。ファイルが変更されるたびに新規バージョンが作成されますが、元のファイルは保存されます。
ソフトウェア構成管理を体験するのが初めてのチームであっても、Functional Tester のインターフェースで、 テスト・スクリプトのバージョン管理に必要なすべての機能を利用することができます。この統合により、ソフトウェア構成管理の使用と導入が簡単になりました。
ソフトウェア構成管理システムの機能と利点を把握しているチームは、Functional Tester と共に ClearCase を実装し、ClearCase ツールによってのみ利用可能な拡張機能を使用することを希望する場合があります。
一言で言えば、ClearCase です。
Functional Tester 資産をバージョン管理するための ClearCase 統合は専門化されており、他のツールで同じ操作を行なうことはできません。この理由から、ClearCase 操作の中には、Functional Tester の外部では実行できないものもあります。
Functional Tester の使用時に、ClearCase 操作は非常に簡単に見えますが、実際は見えないところで多くのことが行われています。Functional Tester スクリプトは、ファイルのコレクションです。Functional Tester のユーザー・インターフェースのすべてのアクションはスクリプトで実行されるので、複数のファイルを単一のエンティティーとして扱うことの複雑さをユーザーが感じることはありません。関連ファイルは、ユーザー・インターフェースのどこにも表示されません。さらに、マージなどのソフトウェア構成管理操作は非常に複雑です。ファイルをマージする順序を決定する組み込みロジックが存在し、また必要に応じて異なるユーティリティーが採用されます。
Functional Tester の ClearCase との内部統合により、ソフトウェア構成管理のすべての基本機能が提供されますが、Functional Tester のテスト資産構造の複雑さをユーザーが感じることがありません。Functional Tester の外部で ClearCase を使用したり、別のソフトウェア構成管理システムを使用してもこの統合レベルを達成することはできません。
また、ユーザーが Functional Tester のユーザー・インターフェースの外部で、Functional Tester ファイルに対してファイル操作を実行しようとすると、スクリプトが関連ファイルと非同期状態になったり、スクリプトが壊れたり使用できなくなる場合があります。
統一変更管理 (UCM) が使用可能な ClearCase ビューが単一ストリーム UCM プロジェクトの一部として作成された場合、Functional Tester はこのビュー内で作動します。Functional Tester はマルチストリーム UCM プロジェクトの一部であるビューでは作動しません。
通常、Functional Tester のテスト・スクリプト・オブジェクトには次のファイルが含まれます。
このファイルは、記録により作成されます。
各スクリプトには、記録後に生成されたスクリプト・ヘルパー・ファイルがあります。
各スクリプトには、マップ・ファイルがあります。 マップ・ファイルは、1 つのスクリプト (*. rftxmap ) だけに関連付けることも、多くのスクリプト (*. rftmap ) で共用することもできます。 ユーザーが誤って専用マップ名を共用マップとして選択しないように、サフィックスを変えています。
各スクリプトには、1 つ以上の検査ポイント・ファイルも含まれています。検査ポイント・ファイルは、スクリプト間で共用されません。
各スクリプトには、スクリプト定義ファイルが含まれています。スクリプト定義ファイルには、マップ・ファイルの名前、スクリプト名、認識されるすべてのオブジェクト、およびその他のファイルのリンケージ情報が含まれます。
公用または専用テスト・データプールを 1 つのテスト・スクリプトに関連付けることができます。
公用テスト・データプールの場合は、1 つまたは複数のテスト・スクリプトに関連付けることができます。