QTP を使用して、使用している Java モニターをテストし始めました。すべてのオブジェクトを共有リポジトリに配置し、ローカル リポジトリをまったく使用しない方がクリーンになると思います。それを行うことのマイナス面はありますか?
1 に答える
いいえ、場合によります。
ローカル リポジトリを無効にする理由はありません。それを行う方法さえありません!しかし、はい、単に使用を避けることができます。
私は通常、「チェックイン時にローカルリポジトリにあるものはすべて削除する必要がある」というルールをチームでアクティブにしています。ライブラリの初期化コードをチェックして、ローカルリポジトリに何かがあるかどうかを確認し、そうであれば警告を出します。
ただし、これが役立つかどうかは AUT とワークフローに依存します。
テストが実際に使用しているリポジトリは、関連付けられた (共有、中央) リポジトリの組み合わせであり、ローカル リポジトリにあるものによって「オーバーレイ」されています。そのため、ローカルのリポジトリ エントリを使用して共有リポジトリ エントリを追加するだけでなく、変更することもできます。これは非常に強力な機能で、共有リポジトリで「標準」ケースを定義し、ローカル リポジトリで例外ケースを定義できます。AUT が、さまざまなコンテキストで簡単に再識別できる明確に定義された GUI オブジェクトを持っている場合は、問題ありません。そうでない場合は、この機能が便利です。
この「オーバーレイ」メカニズムは、追跡が困難な「バグ」(または再生の問題) を簡単に引き起こすことに同意します。通常、Murphy が示唆するように、ローカル リポジトリは、奇妙な再生の症状を診断するときに頭に浮かぶ最後のアイデアです。
ただし、小さな変更ごとに、オブジェクト リポジトリ マネージャーを介して中央リポジトリを開き、チェックアウトし、書き込み可能にするなど、かなりのクリック作業が必要です。そのため、ローカル リポジトリは更新用の適切な "バッファー" です。
したがって、特に QC を中央ストレージ ポイントとして使用していて、そこでバージョン管理を有効にしている可能性がある場合は、最初に新しいものをローカル リポジトリに追加し、チェックする直前に 1 回のロードでそれらを中央リポジトリに移動する機能が気に入るはずです。変更で。(ちなみに、中央のレポ ファイルを 5 分以上チェックアウトすると、他のチーム メンバーがあなたを殺してしまい、実質的に書き込みロックがかかってしまいます。)