È l’architettura implementata dalla TAS. Per semplificare lo sviluppo, l’evoluzione e la manutenzione di TAS, dovrebbero essere osservati i ben noti principi del software SOLID:
- Responsabilità unica: ogni componente TAS deve avere un’unica responsabilità e tale responsabilità deve essere incapsulata interamente nel componente. In altre parole, ogni componente di una TAS dovrebbe essere responsabile di esattamente una cosa, ad esempio, la generazione di dati, l’archiviazione di scenari di test, l’esecuzione di casi di test, la registrazione dei risultati, la generazione di report di esecuzione.
- Principio aperto/chiuso. Ogni componente TAS deve essere aperto per l’estensione, ma chiuso per la modifica. Questo principio significa che dovrebbe essere possibile modificare o arricchire il comportamento dei componenti estendendoli piuttosto che modificandoli, quindi senza rompere la funzionalità retrocompatibile.
- Sostituzione di Liskov: ogni componente TAS deve essere sostituibile senza influire sul comportamento complessivo del TAS. Il componente può essere sostituito da uno o più componenti sostitutivi ma il comportamento mostrato deve essere lo stesso.
- Segregazione dell’interfaccia. È meglio avere componenti più specifici rispetto a un componente generale e multiuso. Ciò semplifica la sostituzione e la manutenzione eliminando le dipendenze non necessarie.
- Inversione delle dipendenze: i componenti di una TAS devono dipendere da astrazioni piuttosto che da dettagli di basso livello. Ad esempio, gli scenari di test di alto livello non dovrebbero dipendere da componenti effettivi di livello inferiore della TAS (come l’effettiva sequenza dettagliata di azioni necessarie per esercitare il SUT). Dovrebbero invece dipendere dalle astrazioni di questi componenti (ad esempio, un livello software che isola i dettagli dei punti di controllo o di osservazione del SUT).
Ci sono molti altri requisiti generici per il TAA:
Il TAA deve essere in grado di toccare le interfacce di controllo e osservazione del SUT che potrebbero essere coinvolte nelle procedure di test.
Un SUT utilizza i dati di configurazione per determinare come viene istanziato ed eseguito. Utilizza i dati forniti dagli utenti che verranno elaborati al momento dell’esecuzione. Può utilizzare anche dati esterni forniti da servizi esterni. Tutti questi dati devono essere definibili, eventualmente modificabili e istanziabili dal TAA.
A livello astratto, il TAA potrebbe comprendere quattro livelli per i quali deve fornire supporto:
Il livello di generazione del test è costituito da strumenti che supportano:
- Progettazione manuale di casi di test
- Sviluppo, acquisizione o derivazione di dati di test
- Generazione automatica di casi di test da modelli che definiscono il SUT e/o il suo ambiente (ad esempio, in caso di test automatizzati basati su modelli)
Questi strumenti vengono utilizzati per modificare e navigare nelle strutture della suite di test, per mettere in relazione i casi di test con gli obiettivi del test o i requisiti SUT, per documentare la progettazione del test.
Il livello di definizione del test consiste nel supporto di strumenti per:
- Specificare i casi di test (a livello alto e/o basso)
- Definizione dei dati di test per casi di test di basso livello
- Sviluppare casi di test e mantenerli.
Il livello di esecuzione del test è costituito dal supporto di strumenti per:
- Esecuzione automatica di casi di test
- Registrazione delle esecuzioni del test case
- Riportare i risultati del test
Il livello di adattamento del test è costituito da strumenti di supporto per:
- Controllo del cablaggio di prova
- Interagire con il SUT
- Monitoraggio del SUT
- Simulazione o emulazione dell’ambiente SUT.
