すべてのラベルが一意であることを意味します(これは疑わしいです..):
ラベルを受け入れ、カスタマイズされたフィールドを定義するQCのテーブルを検索して正しいフィールド定義を取得し、フィールド名を返す関数を作成できます。次に、関数の結果値をインデックス付きプロパティのインデックスとして使用します。
関数が「GetNameOfLabel」と呼ばれるとすると、呼び出し元のコードは次のようになります。
Set currentRun = QCUtil.CurrentRun
currentRun.Field(GetNameOfLabel ("Data Rows Passed")) = 1
currentRun.Post
もちろん、この関数は実際には簡単ではありませんが、QCデータモデルを掘り下げて、SQLを介してDBから名前をフェッチする効率的な方法を見つければ、十分に簡単です。
または、関数が配列または辞書で名前を検索する場合は、その辞書を維持する必要がありますが、検索ごとにデータベースにアクセスする必要はありません。
短所:
- ラベルが間違っているスクリプトは、デバッグが難しい場合があります
- ラベルが一意でない場合、デバッグするのは本当に「楽しい」かもしれません
DBを検索する場合:
- これらのルックアップのSQLクエリ結果をキャッシュまたはプリロードしないと、すべてのスクリプトの速度が低下します。
- 複雑さ。適切なSQLクエリを実行する必要があり、QCのデータモデルに非常に特殊な方法で依存しているため(通常、アップグレード時の恐怖)
配列または辞書で検索する場合:
- 初期化を維持する必要があります(他の管理者がcustフィールドを追加すると、それを簡単に忘れてしまいます)、またはQCのテーブルから「ロード」する必要があります(上記のSQLソリューションに少し似ており、同じ欠点があります)。
array/dictionary-initialized-from-db-ideaを使用します。または、すでに提示されている一定のアイデアで生きることができるのであれば、それは良い賭けです。QCカスタマイズスクリプトにはセッションに依存しないスコープがないことを考えると、SQLアクセスのアイデアは、新しいユーザーセッションごとに実行する必要があるため、パフォーマンスが大幅に低下する可能性があります。だから私もいつも考えを+1しました。