Sviluppare test da un modello

È possibile usare i requisiti e i modelli architetturali per organizzare i test del sistema e dei relativi componenti. Questa procedura consente di assicurarsi di testare i requisiti importanti per gli utenti e gli altri stakeholder e di aggiornare rapidamente i test quando i requisiti cambiano. Se si usa Microsoft Test Manager, è anche possibile mantenere i collegamenti tra i modelli e i test.

Per informazioni su quali versioni di Visual Studio supportano queste funzionalità, vedere Supporto della versione per gli strumenti di architettura e modellazione.

Test del sistema e del sottosistema

I test di sistema, noti anche come test di accettazione, indicano se vengono soddisfatte le esigenze degli utenti. Tali test sono preoccupati per il comportamento esterno visibile del sistema invece della progettazione interna.

I test di sistema sono molto utili quando si estende o si riprogetta un sistema. Consentono di evitare di introdurre bug quando si modifica il codice.

Quando si pianificano modifiche o estensioni a un sistema, è utile iniziare con un set di test di sistema eseguiti nel sistema esistente. È quindi possibile estendere o modificare i test per testare i nuovi requisiti, apportare le modifiche al codice ed eseguire di nuovo il set completo di test.

Quando si sviluppa un nuovo sistema, è possibile iniziare a creare test non appena inizia lo sviluppo. Definendo i test prima di sviluppare ogni funzionalità, è possibile acquisire le discussioni sui requisiti in modo molto specifico.

Il test del sottosistema applica gli stessi principi ai componenti principali di un sistema. Ogni componente viene testato separatamente dagli altri componenti. I test del sottosistema si concentrano sul comportamento visibile nelle interfacce utente o nell'API del componente.

Derivazione di test di sistema da un modello di requisiti

È possibile creare e gestire una relazione tra i test di sistema e un modello di requisiti. Per stabilire questa relazione, si scrivono test che corrispondono agli elementi principali del modello di requisiti. Visual Studio consente di mantenere tale relazione consentendo di creare collegamenti tra i test e le parti del modello. Per altre informazioni sui modelli di requisiti, vedere Requisiti utente del modello.

Scrivere test per ogni caso d'uso

Se si usa Microsoft Test Manager, è possibile creare un gruppo di test per ogni caso d'uso definito nel modello dei requisiti. Ad esempio, se si dispone di un caso d'uso Order a Meal, che include Create Order e Add Item to Order, è possibile creare test sia per il generale che per i casi d'uso più dettagliati.

Queste linee guida potrebbero essere utili:

• Ogni caso d'uso deve avere diversi test, per percorsi principali e risultati eccezionali.

• Quando si descrive un caso d'uso nel modello di requisiti, è più importante definirne la postcondizione, ovvero l'obiettivo raggiunto, piuttosto che descrivere in dettaglio le procedure che l'utente segue per raggiungere l'obiettivo. Ad esempio, la postcondizione dell'ordine di un pasto potrebbe essere che un ristorante sta preparando un pasto per un cliente e che il cliente ha pagato. La postcondizione è il criterio che i test devono verificare.

• Basare test separati sulle clausole separate della postcondizione. Ad esempio, creare test separati per la notifica al ristorante dell'ordine e per l'acquisizione del pagamento dal cliente. Questa separazione presenta questi vantaggi:

  • Le modifiche apportate a diversi aspetti dei requisiti si verificano spesso in modo indipendente. Separando i test in aspetti diversi in questo modo, è più semplice aggiornare i test quando i requisiti cambiano.

  • Se il piano di sviluppo implementa un aspetto del caso d'uso prima di un altro, è possibile abilitare i test separatamente man mano che lo sviluppo procede.

• Quando si progettano i test, separare la scelta dei dati di test dal codice o dallo script che determina se è stata ottenuta la postcondizione. Ad esempio, un test di una semplice funzione aritmetica potrebbe essere: Input 4; verificare che l'output sia 2. Progettare invece lo script come: Scegliere un input; moltiplicare l'output per sé e verificare che il risultato sia l'input originale. Questo stile consente di variare gli input di test senza modificare il corpo principale del test.

Collegamento di test ai casi d'uso

Se si usa Gestione test per progettare ed eseguire i test, è possibile organizzare i test in base ai requisiti, ai casi d'uso o agli elementi di lavoro della storia utente. È possibile collegare questi elementi di lavoro ai casi d'uso nel modello. In questo modo è possibile tracciare rapidamente le modifiche dei requisiti ai test e consente di tenere traccia dello stato di avanzamento di ogni caso d'uso.

Per collegare i test a un caso d'uso

1. In Gestione test creare un requisito e basare un gruppo di test su di esso.

   Il requisito che crei è un elemento di lavoro in Team Foundation Server. Può trattarsi di un elemento di lavoro User Story, Requirement o Use Case, a seconda del modello di processo usato dal progetto con Team Foundation. Per altre informazioni, vedere Informazioni sugli strumenti Agile e sulla gestione dei progetti Agile.

2. Collegare l'elemento di lavoro del requisito a uno o più casi d'uso nel tuo modello.

   In un diagramma di caso d'uso, fare clic con il tasto destro del mouse su un caso d'uso e quindi scegliere Collega all'elemento di lavoro.

3. Aggiungere alla suite di test i test case che verificano i casi d'uso.

   In genere, ogni elemento di lavoro relativo alla storia utente o ai requisiti verrà collegato a diversi casi d'uso nel modello e ogni caso d'uso verrà collegato a diverse storie utente o requisiti. Ciò è dovuto al fatto che ogni storia utente o requisito copre un set di attività che sviluppano diversi casi d'uso. Ad esempio, in un'iterazione anticipata del progetto, è possibile sviluppare la storia utente di base in cui un cliente può scegliere gli elementi da un catalogo e li ha recapitati. In un'iterazione successiva, la storia potrebbe essere che l'utente paga durante il completamento dell'ordine e il fornitore riceve il denaro dopo l'invio delle merci. Ogni storia aggiunge una clausola alla postcondizione del caso d'uso Order Goods.

   È possibile creare collegamenti separati dai requisiti alle clausole della postcondizione scrivendo tali clausole in commenti separati nel diagramma dei casi d'uso. È possibile collegare ogni commento a un elemento di lavoro requisito e collegare il commento al caso d'uso nel diagramma.

Eseguire test di base sui tipi di requisiti

I tipi, ovvero le classi, le interfacce e le enumerazioni, di un modello di requisiti descrivono i concetti e le relazioni in termini di come gli utenti pensano e comunicano sul proprio business. Esclude i tipi interessati solo alla progettazione interna del sistema.

Progettare i test in termini di questi tipi di requisiti. Questa procedura consente di garantire che, quando vengono discusse modifiche ai requisiti, è facile correlare le modifiche alle modifiche necessarie nei test. Consente di discutere i test e i risultati previsti direttamente con gli utenti finali e altri stakeholder. Ciò significa che le esigenze degli utenti possono essere mantenute al di fuori del processo di sviluppo ed evita la progettazione accidentale dei test intorno a possibili difetti nella progettazione.

Per i test manuali, questa pratica prevede l'adesione al vocabolario del modello di requisiti negli script di test. Per i test automatizzati, questa procedura prevede l'uso dei diagrammi classi dei requisiti come base per il codice di test e la creazione di funzioni di accesso e di aggiornamento per collegare il modello di requisiti al codice.

Ad esempio, un modello di requisiti può includere tipi Menu, Voce di menu, Ordine e associazioni tra di essi. Questo modello rappresenta le informazioni archiviate e gestite dal sistema di ordinamento dei pasti, ma non rappresenta le complessità dell'implementazione. Nel sistema di lavoro potrebbero esserci diverse realizzazione di ogni tipo, nei database, nelle interfacce utente e nelle API. In un sistema distribuito potrebbero essere presenti diverse varianti di ogni istanza archiviate in parti diverse del sistema contemporaneamente.

Per testare un caso d'uso, ad esempio Aggiungi elemento all'ordine, un metodo di test può includere codice simile al seguente:

Order order = ... ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = ...; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);

Si noti che questo metodo di test usa le classi del modello di requisiti. Le associazioni e gli attributi vengono realizzati come proprietà .NET.

Per eseguire questa operazione, le proprietà delle classi devono essere definite come funzioni di sola lettura o funzioni di accesso, che accedono al sistema per recuperare informazioni sullo stato corrente. I metodi che simulano casi d'uso, ad esempio AddItemToOrder, devono guidare il sistema tramite l'API o tramite un livello sottostante l'interfaccia utente. I costruttori di oggetti di test, ad esempio Order e MenuItem, devono anche guidare il sistema per creare elementi corrispondenti all'interno del sistema.

Molte delle funzioni di accesso e degli aggiornamenti saranno già disponibili tramite l'API normale dell'applicazione. Tuttavia, alcune funzioni aggiuntive potrebbero essere scritte per abilitare i test. Queste funzioni di accesso e di aggiornamento aggiuntive sono talvolta note come "strumentazione di test". Poiché dipendono dalla progettazione interna del sistema, è responsabilità degli sviluppatori del sistema fornirli, mentre i tester scrivono il codice dei test in termini di modello di requisiti.

Quando si scrivono test automatizzati, è possibile usare test generici per eseguire il wrapping delle funzioni di accesso e degli aggiornamenti.

Test delle regole aziendali

Alcuni requisiti non sono direttamente correlati a un caso d'uso. Ad esempio, l'azienda DinnerNow consente ai clienti di scegliere tra molti menu, ma richiede che in ogni ordine tutti gli elementi scelti proveniranno da un unico menu. Questa regola business può essere espressa come invariante sulle associazioni tra Ordini, Menu ed Elementi nel modello di classe dei requisiti.

Una regola invariante di questo tipo regola non solo tutti i casi d'uso attualmente definiti, ma anche qualsiasi altro caso d'uso che verrà definito in un secondo momento. Pertanto, è utile scriverlo separatamente da qualsiasi caso d'uso e testarlo separatamente dai casi d'uso.

Derivazione dei test del sottosistema dai modelli

Nella progettazione generale di un sistema di grandi dimensioni è possibile identificare componenti o sottosistemi. Rappresentano parti che possono essere progettate separatamente o che si trovano in computer diversi o sono moduli riutilizzabili che possono essere ricombinati in molti modi.

È possibile applicare a ogni componente principale gli stessi principi usati per il sistema completo. In un progetto di grandi dimensioni ogni componente può avere un proprio modello di requisiti. In progetti più piccoli, è possibile creare un modello di architettura o un progetto di alto livello per mostrare i componenti principali e le relative interazioni. Per altre informazioni, vedere Modellare l'architettura dell'app.

In entrambi i casi, è possibile stabilire una relazione tra gli elementi del modello e i test del sottosistema nello stesso modo in cui si farebbe tra il modello dei requisiti e i test di sistema.

Isolare i componenti con interfacce fornite e richieste

È utile identificare tutte le dipendenze che un componente ha in altre parti del sistema o dei servizi esterni e rappresentarli come interfacce obbligatorie. Questo esercizio porta in genere a una riprogettazione che lascia il componente molto più disaccoppiato e facilmente separabile dal resto della progettazione.

Un vantaggio di questo disaccoppiamento è che il componente può essere eseguito per il test sostituendo con oggetti fittizi i servizi usati in genere. Si tratta di componenti configurati ai fini del test. Un componente fittizio fornisce l'interfaccia richiesta dal componente, rispondendo alle query con dati simulati. I componenti fittizi fanno parte di un test harness completo che è possibile connettere a tutte le interfacce del componente.

Un vantaggio del test fittizio è che è possibile sviluppare il componente mentre gli altri componenti i cui servizi verranno usati sono ancora in fase di sviluppo.

Gestire le relazioni tra test e modello

In un progetto tipico che esegue un'iterazione ogni poche settimane, una revisione dei requisiti viene tenuta vicino all'inizio di ogni iterazione. La riunione illustra le funzionalità che devono essere fornite nell'iterazione successiva. Un modello di requisiti può essere usato per illustrare i concetti, gli scenari e le sequenze di azioni che verranno sviluppate. Gli stakeholder aziendali impostano le priorità, gli sviluppatori effettuano stime e i tester assicurano che il comportamento previsto di ogni funzionalità venga acquisito correttamente.

La scrittura di test è il modo più efficace per definire un requisito ed è anche un modo efficace per garantire che una persona abbia una chiara comprensione di ciò che è necessario. Tuttavia, mentre la scrittura di test richiede troppo tempo durante un workshop di specifiche, la creazione di modelli può essere eseguita molto più rapidamente.

Dal punto di vista dei test, un modello di requisiti può essere considerato una sintassi abbreviata per i test. È quindi importante mantenere la relazione tra i test e il modello in tutto il progetto.

Collegamento di test case agli elementi del modello

Se il progetto usa Gestione test, è possibile collegare i test agli elementi del modello. In questo modo è possibile trovare rapidamente i test interessati da una modifica dei requisiti e consente di tenere traccia della misura in cui è stato realizzato un requisito.

È possibile collegare i test a tutti i tipi di elemento. Ecco alcuni esempi:

• Collegare un caso d'uso ai test che lo usano.

• Scrivere le clausole di postcondizione o obiettivo di un caso d'uso nei commenti collegati al caso d'uso e quindi collegare i test a ogni commento.

• Scrivere regole invarianti nei commenti su diagrammi classi o diagrammi attività e collegarli ai test.

• Collegare i test a un diagramma attività o a singole attività.

• Collegare un gruppo di test al componente o al sottosistema che esegue il test.

Per collegare i test a un elemento o a una relazione del modello

1. In Gestione test creare un requisito e basare un gruppo di test su di esso.

   Il requisito che crei è un elemento di lavoro in Team Foundation Server. Può trattarsi di un elemento di lavoro User Story, Requirement o Use Case, a seconda del modello di processo usato dal progetto con Team Foundation. Per altre informazioni, vedere Informazioni sugli strumenti Agile e sulla gestione dei progetti Agile.

2. Collegare l'elemento di lavoro del requisito a uno o più elementi nel modello.

   In un diagramma di modellazione fare clic con il pulsante destro del mouse su un elemento, un commento o una relazione e quindi scegliere Collega all'elemento di lavoro.

3. Aggiungere al gruppo di test, test case che verificano il requisito espresso nell'elemento del modello.

Contenuti correlati

• Creare modelli per l'app
• Requisiti utente del modello
• Modellare l'architettura dell'app
• Analisi e modellazione dell'architettura