Подразумевается, что все ярлыки уникальны (в чем я сомневаюсь ..):
Вы можете создать функцию, которая принимает метку, выполняет поиск в таблицах QC, которые определяют настраиваемые поля для правильного определения поля, и возвращает имя поля. Затем используйте значение результата функции в качестве индекса индексированного свойства.
Предположим, что функция будет называться «GetNameOfLabel», тогда код вызывающей стороны будет выглядеть так:
Set currentRun = QCUtil.CurrentRun
currentRun.Field(GetNameOfLabel ("Data Rows Passed")) = 1
currentRun.Post
Конечно, функция на самом деле не будет тривиальной, но достаточно простой после некоторого поиска в модели данных QC и поиска эффективного способа извлечь имя из БД через SQL.
Или, функция может искать имя в массиве или словаре, тогда вам придется поддерживать этот словарь, но вам не нужно будет обращаться к базе данных для каждого поиска.
Disadventages:
- Сценарии с неправильной меткой могут быть сложнее отладить
- Если ярлыки не уникальны, отладка может быть очень интересной
Если посмотреть на БД:
- Все сценарии замедляются, если вы не кэшируете или не загружаете предварительно результаты SQL-запросов для этих поисков;
- сложность, так как вам нужно правильно выполнить запрос SQL, и вы весьма своеобразно зависите от модели данных QC (обычно это ужас при обновлении)
При поиске в массиве или словаре:
- Вы должны либо поддерживать его инициализацию (держите пари, что другие администраторы, добавившие поле cust, легко это забудут), либо должны «загрузить» его из таблицы QC (что немного похоже на решение SQL выше и имеет те же недостатки) .
Я бы пошел с массивом / dictionary-initialized-from-db-idea. Или, если вы можете жить с постоянной представленной идеей, это хорошая ставка. Учитывая, что в сценариях настройки QC отсутствует независимая от сеанса область действия, идея доступа к SQL может действительно снизить производительность, поскольку ее придется выполнять для каждого нового пользовательского сеанса. Вот почему я тоже добавил +1 к постоянной идее.