Struttura dello strumento Quality Center

 

STRUTTURA GENERALE

 

Lo strumento HP Quality Center è composto da 2 parti:

 

  • Amministrazione
  • GUI Progetti

     

Riporto qui sotto a grandi linee le loro caratteristiche e lo scopo per cui sono stati progettati.  

 

Amministrazione - Site Admin

 

La parte di amministrazione permette:

  • la creazione/eliminazine domini e progetti
  • gestione degli utenti (creazione nuovi users)
  • vista e gestione connessioni
  • vista situazione licenze
  • vista situazione server applicativi
  • vista situazione server db 
  • gestione configurazione e parametri generali

GUI Progetti

 

E' la parte di User Interface nella quale l'utente interagisce con gli oggetti e i dati del progetto quali requisiti, releases, tests, strategie, difetti, reportistica.

 

Ogni utente ha associati alcuni profili che gli danno "diritto" di effettuare o meno azioni sugli oggetti del progetto quali la modifica, creazione o cancellazione.


 

 

 

STRUTTURA DI UN PROGETTO

 

Il progetto in Quality Center rappresenta un contenitore in cui sono censiti e raggruppati Requisiti, Releases, Tests. All'interno dello stesso è possibile aggregare i test per comporre strategie di esecuzione. E' presente anche una sezione dedicata alla gestione delle anomalie e una dedicata alla reportistica.

 

La struttura di un progetto prevede 2 aspetti:

  • i dati quali gli allegati e scripts (workflow script editor) che molto spesso sono salvati e registrati su File System (magari anche condiviso) 
  • un DataBase composto da molte tabelle per la registrazione degli oggetti quali i Requisiti, i Test, i Run, le Strategie di Test (TestSet - Cycle), i Bug ecc...

 

 

Quality Center può essere installato su una macchina unica in cui sono presenti anche i dati del File System oppure si può avere una architettura in cui l'applicazione QC core è installata su alcuni server applicativi, avere un unico DB Server ed un unico File System condiviso.

 

Qualsiasi sia la configurazione architetturale il percorso del FileSystem per i progetti prevede questa struttura:

\\..\Quality Center\repository\qc\Dominio_ID\NomeProgetto\ al di sotto del quale sono presenti un file xml, dbid.xml, contenente le informazioni base del progetto, e altre cartelle tra cui le principali sono:

  • scripts: cartella contenente files .tds che sono i singoli moduli dello script editor (requirements, testplan, testlab, manualrunner, ecc...)
  • attach: cartella contentente tutti gli allegati del progetto. La nomenclatura è data da TIPOOGGETTO_nomeallegato.estensione (es: BUG_applerr.jpg) 

 

Il file dbid.xml è strutturato in questo modo:

<?xml version="1.0" encoding="UTF-8" ?>

- <ProjectDescription>

      <PROJECT_NAME >NomeProgetto</PROJECT_NAME>
      <DB_TYPE>2</DB_TYPE>
      <DESCRIPTION>Created on AAAA-MM-DD HH:MI:SS</DESCRIPTION>
      <DB_CONNSTR_FORMAT>jdbc:mercury:sqlserver://NomeDBServer\SID:Porta
      </DB_CONNSTR_FORMAT>
     <DB_NATIVE_AUTHENTICATION>N</DB_NATIVE_AUTHENTICATION>
     <DB_NAME>NomeProgettoDB</DB_NAME>
     <DBSERVER_NAME>NomeDBServer\SID</DBSERVER_NAME>
     <DB_USER_PASS>TWO:XX-XXX-XXX-X-XX-XX</DB_USER_PASS>
     <PR_HAS_VCSDB>N</PR_HAS_VCSDB>
     <PHYSICAL_DIRECTORY>\\..\..\Quality Center\repository\qc\NOMEDOMINIO_ID\NomeProgetto\
     </PHYSICAL_DIRECTORY>
     <USERS_QUOTA>-1</USERS_QUOTA>
     <PR_IS_ACTIVE>Y</PR_IS_ACTIVE>
     <SAQ_IS_ACTIVE>N</SAQ_IS_ACTIVE>
     <VM_REPOSITORY  />
     <PR_LANGUAGE>English</PR_LANGUAGE>
     <PROJECT_TYPE>Standard</PROJECT_TYPE>
     <IS_TEMPLATE>N</IS_TEMPLATE>
     <PROJECT_UID>aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa</PROJECT_UID>
</ProjectDescription>

 

IMPORTANTE: 

DBNAME è il nome del DB del progetto. La sua nomenclatura prevede un massimo di 30 caratteri. Se il nome del progetto che è stato dato è lungo fino a 27 caratteri, gli ultimi 3 saranno sempre "_db". Nel caso il nome fosse più lungo viene troncato al 30esimo carattere. 

PHYSICAL_DIRECTORY è la directory sul FileSystem relativa al progetto.

 

 

 

Per quanto concerne invece il DataBase elenco qui di seguito le principali tabelle:

 

  • ACTIONS: sono elencate le azioni disponibili per il progetto (in realtà molte non sono presenti ed è necessario farsele restituire da codice all'interno del workflow script editor tramite la funzione ActionCanExecute)
  • ALL_LISTS: rappresenta l'elenco totale di qualsiasi lista comprese anche le folder ed i relativi percorsi.
  • AUDIT_LOG e AUDIT_PROPERTIES: tramite queste 2 tabelle è possibile avere a disposizione il log delle azioni intercorse su un oggetto. Ad esempio se ho necessità di verificare tutti i vari cambi di stato di un bug.
  • BUG: tabella contenente le informazioni dei defect
  • COMMON_SETTINGS: tabella particolare, molto utile anche come tabella dati di appoggio. Viene fatto un utilizzo pesante per il modulo ManualRun che non colloquia con il resto dello script editor. Tabella che si presta a svariati utilizzi.
  • CYCLE e CYCL_FOLD: rispettivamente la tabella dei TestSet (Strategie di test) e delle cartelle dei TestSet.
  • DESSTEPS: tabella degli step dei test (design step) in fase di censimento di questi ultimi
  • GROUPS: tabella contenente i gruppi (profili)
  • LIBRARIES: tabella contenente l'elenco delle librerie censite nell'apposito modulo
  • LINK: tabella che lega i BUG alle altre entità (Test, TestSets, Requirements,...)
  • LOCKS: tabella dei lock
  • MODULES: tabella contenente l'elenco dei Moduli del Progetto (sezioni)
  • RELEASES: tabella contenente l'elenco delle Release censite nel progetto
  • RELEASE_CYCLES: tabella in cui vengono registrati i Cicli di Test (sezione Releases)
  • REQ: tabella dei requisiti. NB: anche le cartelle dei requisiti sono considerati tipi di requisiti
  • REQ_COVER: tabella contenente l'associazione tra i requisiti e i test
  • REQ_RELEASES: tabella di associazione requisiti e release
  • REQ_TRACE: tabella contenente associazione tra requisiti
  • REQ_TYPE: tabella contenente le anagrafiche dei tipi di requisiti
  • RUN: tabella in cui vengono registrate le esecuzioni
  • STEP: tabella sorella dei RUN contenente le esecuzioni degli step
  • TEST: tabella contenente l'elenco dei casi di test
  • TESTCYCL: tabella contenente le istanze di test inseriti nelle strategie
  • USERS: tabella contenente l'elenco degli utenti che possono accedere al progetto.

 

 

STRUTTURA SITE ADMINISTRATOR

 

La GUI della parte di Amministrazione si presenta con una pagina a schede. Ogni scheda rappresenta funzioni come da elenco sopraindicato.

 

La vista per la gestione dei progetti è strutturata ad albero con elenco dei domini e progetti, con differenziazione tra progetti e template.

 

Il Site Admin ha un DB a parte in cui vengono registrate le informazioni generali, tra cui l' elenco dei progetti, l'elenco generale degli utenti e l'elenco di tutte le connessioni effettuate dagli utenti.

 

Il DB non è visibile dalla GUI. E' possibile interagire con gli oggetti utilizzando le SaApi (API - Application Programming Interface - della parte di SiteAdmin).