Implicando tutte le etichette sono unici (che dubito ..):
è possibile creare una funzione che accetta un'etichetta, le ricerche nelle tabelle di controllo di qualità che definiscono i campi personalizzati per la definizione campo corretto, e restituisce il nome del campo . Quindi utilizzare il valore del risultato della funzione come indice della proprietà indicizzata.
supporre che la funzione sarebbe chiamato "GetNameOfLabel", quindi il codice del chiamante sarà simile:
Set currentRun = QCUtil.CurrentRun
currentRun.Field(GetNameOfLabel ("Data Rows Passed")) = 1
currentRun.Post
Naturalmente, la funzione non sarebbe davvero banale, ma abbastanza facile dopo qualche scavo nei dati QC modello e trovare un modo efficiente per recuperare il nome dal DB tramite SQL.
Oppure, la funzione potrebbe cercare il nome in un array, o un dizionario, quindi si dovrebbe mantenere quel dizionario, ma non si dovrebbe andare al database per ogni ricerca.
Disadventages:
- script con l'etichetta sbagliata potrebbe essere più difficile da eseguire il debug
- Se le etichette non sono univoci, potrebbe essere vero e proprio "divertimento" per eseguire il debug
Se alzando lo sguardo sul DB:
- Tutti gli script rallentano se non si memorizza nella cache o precarica i risultati di query SQL per tali ricerche;
- complessità, come si deve fare la query SQL a destra, e si dipende da modello di dati di controllo di qualità in un modo tutto particolare (di solito un orrore quando si esegue l'aggiornamento)
Se guardando in un array, o un dizionario:
- si sia necessario mantenere la sua inizializzazione (scommessa altri ragazzi di amministrazione aggiunta di un campo Cust dimenticheranno tanto facilmente), oppure deve "caricare" dalla tabella di QC (che è un po 'come la soluzione SQL sopra, e ha gli stessi aspetti negativi).
Vorrei andare con l'array/dizionario-inizializzato-da-db-idea. Oppure, se riesci a vivere con l'idea costante già presentata, quella è una buona scommessa. Considerando che non c'è un ambito indipendente dalla sessione in QC che personalizzi gli script, l'idea di accesso SQL potrebbe davvero uccidere le prestazioni perché dovrebbe essere eseguita per ogni nuova sessione utente. Questo è il motivo per cui anch'io ho fatto +1 sull'idea costante.
Perché vorresti farlo? Perché non puoi usare il nome come fai oggi? –
Ciao Alex. Buona domanda. Il motivo è che usiamo molti campi personalizzati e sarà difficile per i tester/sviluppatori implementare e mantenere i test con nomi come "RN_USER_03", sarà molto facile confondersi e fare misstakes, e molto difficile leggere il codice. Le etichette non cambieranno molto spesso e questo è il motivo per cui vogliamo invece utilizzare le etichette. –
Non potresti facilmente assegnare il nome del campo a una costante con un nome significativo? 'const DATA_ROWS_PASSED =" RN_USER_03 "currentRun.Field (DATA_ROWS_PASSED) = 4' –