Operazione: Definizione elementi di verificabilità
Questo compito identifica gli elementi che supportano e abilitano la verifica.
Scopo

Lo scopo di questo compito è di:

  • Identificare gli elementi necessari per supportare gli elementi test di destinazione
  • Identificare gli elementi fisici dell'infrastruttura di implementazione del test richiesti per abilitare la verifica in ogni Configurazione ambiente di test
  • Definire i requisiti del progetto software che dovranno essere riscontrati per abilitare il software ad essere fisicamente testato
Relazioni
Passi
Per ogni elemento di test di destinazione richiesto, identificare i rapporti con i meccanismi di test
Scopo:  Per acquisire informazioni il supporto del meccanismo di test necessario per gli elementi di test di destinazione.

Per ogni elemento di test di destinazione, rivedere l'elenco dei meccanismi di test e identificare quelli che dovrebbero fornire supporto. Analizzare quanto sono vicini i meccanismi di test per fornire una soluzione di test completa e come possono essere adattati meglio. Se non si rilevano candidati migliori o lo sforzo di adattamento è significativo, definire nuovi meccanismi di test e cercare un equilibrio tra la specificità e la riutilizzabilità.

Identificare eventi ed elementi dinamici del sistema
Scopo:  Per acquisire informazioni degli aspetti dinamici e di runtime del sistema. 

Utilizzando i requisiti software disponibili e le informazioni di progettazione, identificare gli elementi dinamici e gli eventi del sistema. Utilizzo dei casi d'uso, del progetto, dell'implementazione e dei modelli di distribuzione, è possibile identificare elementi rilevanti come le classi di controllo, i processi, i thread e gli eventi. I posti dove è possibile iniziare la ricerca includono le classi stereotipate come <<controllo>>, le realizzazioni del caso d'uso e gli elementi descritti nella vista strutturale del processo o il modello di implementazione stereotipato come <<processo>> o <<thread>>.

In relazione agli obblighi imposti dall'ambiente di verifica, definire i requisiti fisici.

Identificazione limiti del sistema e interfacce
Scopo:  Per ottenere più informazioni sulle responsabilità del sistema come provider di servizi e sulle dipendenze del sistema come client. 

Un altro gruppo utile di elementi da esaminare sono le Interfacce del sistema, soprattutto quelle relative ad attori esterni ai limiti del sistema. Utilizzando i Modello di progetto e implementazione, cercare gli elementi definiti con l'<<interfaccia>> dello stereotipo. Esaminare inoltre i modelli per l'esistenza di classi stereotipate come <<limite>>.

Come tester, è utile esplorare oltre questi limiti di sistema per comprendere meglio le attese dei sistemi relativi, i provider client e di servizio. Questo darà una conoscenza più completa di cosa è necessario in termini di convalida delle interfacce ed in termini di infrastruttura di verifica richiesta per verificare e possibilmente simulare queste interfacce.

Identificazione elementi infrastruttura di verifica
Scopo:  Per identificare gli elementi essenziali dell'impegno di verifica che abilitano la verifica richiesta ad essere eseguita. 

Affinché un impegno di verifica iterativa sia corretto, è importante identificare e conservare un'infrastruttura appropriata. Senza un'infrastruttura che ne supporti la manutenzione, l'impegno di verifica può velocemente diventare non conservabile e non utilizzabile. Mentre più ovviamente rilevante all'impegno di test automatizzato, l'infrastruttura di test è anche un interesse importante per l'impegno di test manuale.

Considerare gli elementi e gli eventi dinamici nel sistema; quali dipendenze posizioneranno sull'implementazione dei test singoli. Cercare le opportunità per sdoppiare le dipendenze tra i test singoli e gestirle attraverso i punti comuni di controllo che forniscono uno livello di via indiretta. Le aree comuni per esplorare le dipendenza includono la navigazione nel test, l'utilizzo dei dati di testi e le modifiche dello stato di sistema.

Utilizzando le informazioni che si sono raccolte, considerare quali requisiti governano l'infrastruttura di test e quali funzioni sarà necessario fornire per abilitare un approccio di test corretto.

Argomenti secondari:

Facilitazione scenari del test comune Inizio pagina

Alcuni test hanno una struttura comune dello scenario o della procedura seguita quando vengono eseguiti, ma la stessa procedura deve essere condotta molte volte rispetto a diversi elementi di destinazione di test. In caso di automazione del test, può essere utile script di test comuni o funzioni di utilità che possono essere riutilizzati in molti contesti diversi per intraprendere questi scenari di test comuni in un modo efficace. Questo fornisce un punto centrale di modifica se lo scenario di test va alterato. Gli esempi includono la conduzione di test di limite su classi appropriate di elementi di interfaccia e la convalida degli elementi IU per l'aderenza agli standard di progetto IU.

Facilita dipendenze dei dati di test Inizio pagina

Quando è necessario condurre i test in una configurazione di ambiente data, c'è un potenziale di conflitti nei valori dei dati di test che vengono utilizzati. Questo problema è composto quando l'ambiente è condiviso da più membri del team di test. Considerare l'utilizzo di un approccio guidato dai dati che scoppia i valori di dati di test dagli script di test che li utilizzano, e fornire un punto centrale di raccolta e modifica dei dati di test. Questo fornisce due benefici di chiavi: dà visibilità dei dati di test a tutti i membri del team, consentendo loro di evitare possibili conflitti nell'utilizzo dei dati di test e fornisce un punto centrale di modifica per i dati di test quando è necessario aggiornarli.

Facilita dipendenze dello stato di test Inizio pagina

La maggior parte dei test richiede che il sistema si trovi in uno stato specifico prima che vengano eseguiti, e dovrebbero far tornare il sistema in uno stato conosciuto specifico quando sono completati. Le dipendenze comuni includono i diritti di sicurezza (funzione o dati), dati dinamici o sensibili al contesto (ad esempio le date del sistema, i numeri di ordine, le preferenze id utente, ecc..), i cicli di scadenza dati (ad esempio, le password di sicurezza, la scadenza del prodotto, ecc..). Alcuni test sono molto dipendenti l'uno dall'altro; ad esempio, un test potrebbe creare un numero di ordine unico e un test successivo potrebbe aver bisogno di inviare lo stesso numero di ordine.

Una soluzione comune è di utilizzare le suite di test per i test di pendenti dalle sequenze nell'ordine di stato del sistema corretto. Le suite di test possono quindi essere accoppiate con i programmi di utilità di recupero e impostazione appropriati. Per gli impegni di test automatizzati, alcune soluzioni potrebbero includere l'utilizzo di dati di sistema di memoria centralizzata o dinamici e l'utilizzo di variabili negli script di test che fanno riferimento alle informazioni centralizzate.

Facilita valori dati di test derivati Inizio pagina

I test, a volte, devono calcolare o derivare valori di dati appropriati da uno o più aspetti dello stato di sistema di runtime. Questo si applica ai valori dei dati di test per i risultati di input e previsti. Considerare lo sviluppo dei programmi di utilità che calcolano i valori di dati derivati, semplificando l'esecuzione del test ed eliminando possibili inaccuratezze introdotte dall'errore umano. Dove possibile, sviluppare questi programmi di utilità in modo da poter essere utilizzati da impegni di test manuali o automatizzati.

Facilita percorsi di navigazione del test comuni Inizio pagina

Per l'automazione di test, considerare la possibilità di isolare le sequenza di navigazione comuni e la loro implementazione utilizzando le funzioni di utilità centralizzate o gli script di test. Queste sequenza di navigazione comuni possono essere quindi riutilizzate in molti posti, fornendo un punto centrale di modifica se la navigazione cambia di conseguenza. Questi aiuti di navigazione comuni semplicemente navigano nell'applicazione da un punto ad un altro; questi generalmente non eseguono i test stessi ma piuttosto verificano gli stati di inizio e di fine.

Identificare le necessità di progetto specifiche del test
Scopo:  Per identificare le necessità della disciplina di test che posizionerà possibile vincoli sul processo di progettazione del software, sulla struttura del software e sul progetto e l'implementazione corrispondente. 

Specialmente quando riguarda l'automazione del test, è probabile che le necessità di implementazione e di valutazione del test che metteranno dei vincoli sul modo in cui il team di sviluppo mettano in atto il processo di progettazione del software e sull'architettura e il progetto del software. E' importante che il team di sviluppo del software non sia ostacolato nel lavoro di sviluppo principale e che il team del test abbia la capacità di eseguire la verifica necessaria. Consultare Compito: Ottenimento dell'impegno sulla verificabilità per informazioni sulla presentazione delle necessità del team di test al team di sviluppo e la ricerca di soluzioni attuabili che soddisfino le necessità di tutte le discipline.

Utilizzo delle informazioni raccolta, considerando quali requisiti l'impegno di test posiziona sull'impegno di sviluppo.

Argomenti secondari:

Identificazione interfacce di test Inizio pagina

Considerare le interfacce identificate; ci sono altri requisiti che l'impegno del test ha bisogno che siano inclusi nel progetto del software e successivamente esposti nell'implementazione? In alcuni casi, verranno richieste altre interfacce specificatamente per supportare l'impegno di test, o le interfacce esistente richiedono altri modi operativi o firme di messaggio modificate (modifiche all'input e parametri di restituzione).

In relazione agli ambienti di sviluppo di destinazione (come catturati nelle configurazioni di ambiente di test) e la pianificazione di sviluppo stessa, identificare i limiti e le dipendenze posizionate nell'impegno del test. Queste dipendenze potrebbero necessitare della provvista di stub per simulare gli elementi dell'ambiente che non saranno disponibili o sono troppo proibitivi per la risorsa per stabilire gli scopi del test, o per fornire l'opportunità di un test anticipato di componenti del sistema parzialmente completato.

Identificazione funzioni test integrate Inizio pagina

Alcuni test sono potenzialmente valutabili ma molto costosi per essere implementati come test black-box. Inoltre, negli ambienti ad alta disponibilità, è importante essere in grado di verificare e isolare gli errori più velocemente è possibile per abilitare una risoluzione veloce. In questi casi, può essere utile creare i test direttamente nel software eseguibile stesso.

Ci sono approcci diversi che possono essere presi in considerazione per fare ciò; due dei più comuni includono test integrati dove il software utilizza cicli di elaborazione ridondanti per eseguire i test di integrità, e routine di diagnostica che possono essere eseguite quando al software viene inviato un messaggio di evento diagnostico, o quando viene configurato il sistema affinché venga eseguito con le routine abilitate.

Identificazione limiti di progetto di test Inizio pagina

Alcune delle scelte di progetto e implementazione del team di sviluppo abilitano o inibiscono l'impegno del test. Mentre alcune di queste scelte sono inevitabilmente necessarie, ci sono molte decisioni più piccole, specialmente nell'area di implementazione, che hanno un impatto minimo sul team di sviluppo ma hanno un impatto significativo sul team di test.

Le aree da considerare includono: L'utilizzo di standard, i protocolli di comunicazione riconosciuti; L'utilizzo dei componenti di implementazione IU che possono essere riconosciuti da parte degli strumenti di automazione del test; L'adesione alle regole di progetto IU che includono la denominazione degli elementi IU; L'uso coerente delle convenzioni di navigazione IU.

Definizione requisiti di verifica software
Scopo:  Per specificare i requisiti per le funzioni del software necessarie per supportare l'implementazione e l'esecuzione dei test. 

Utilizzando il lavoro precedente eseguito sull'attività, definire i requisiti specifici del test e i vincoli che dovrebbero essere considerati nel progetto e nell'implementazione del software.

E' importante spiegare in modo chiaro al team di sviluppo i motivi per i quali viene richiesto che le funzioni specifiche del test vengano create nel software. I motivi chiave ricadono in una delle seguenti aree:

  • Per consentire ai test di essere implementati - sia i manuali che gli automatizzati - fornendo un'interfaccia tra l'elemento di test di destinazione e il test manuale o automatizzato. Questo è generalmente più importante come interesse dell'automazione del test per aiutare a superare i limiti degli strumenti di automazione di test nell'essere in grado di accedere all'applicazione di software per l'input e l'output di informazione.
  • Per consentire ai test autonomi integrati di essere condotti da parte del software stesso sviluppato.
  • Per consentire agli elementi di test di destinazione ad essere isolati dal resto del sistema sviluppato e di essere verificati.

Le funzioni specifiche del test integrate nel software devono equilibrare la funzione di test integrata e l'impegno necessario per implementarlo e verificarlo. Gli esempi delle funzioni di test integrate includono la produzione di log di controllo, le funzioni di autodiagnostice e le interfacce per interrogare il valore di variabili interne.

Un altro utilizzo comune della funzionalità specifica è durante il lavoro di integrazione dove è necessario produrre stub per i componenti ed i sottosistemi che non sono ancora implementati o incorporati. Ci sono due stili di implementazione principali per gli stub:

  • Gli stub ed i driver che sono semplicemente "dummies" con nessuna funzionalità a parte quella di essere in grado di fornire un valore (o valori) predefinito specifico come input o come valore di restituzione.
  • Gli stub ed i driver che sono più intelligenti e possono "simulare" o approssimare un funzionamento più complesso.

Questo secondo stile di stub fornisce anche un mezzo potente per isolare i componenti o i gruppi di componenti dal resto del sistema, quindi fornendo la flessibilità nell'implementazione e nell'esecuzione dei test. Così come il commento precedente relativo alle funzioni specifiche del test, è necessario considerare un equilibrio tra il valore di uno stub complesso e l'impegno necessario per implementare e verificare le necessità dello stub. Utilizzare questo secondo stile in modo prudente per due motivi; primo, ci vogliono più risorse da implementare, e secondo; è più semplice controllare l'esistenza dello stub e dimenticarsi di rimuoverlo successivamente.

Registrare le proprie conclusioni in termini di requisiti specifici del test sui modelli di progetto e implementazione direttamente, o utilizzando una o più specifiche dell'interfaccia di test.

Definizione dell'infrastruttura di test
Scopo:  Per specificare i requisiti per l'infrastruttura di test necessaria per supportare l'implementazione e l'esecuzione dei test. 

Utilizzando il lavoro precedente eseguito sull'attività, definire l'infrastruttura di test richiesta per supportare l'implementazione e l'esecuzione del test.

Ricordare che si stanno definendo le funzioni di implementazione dell'infrastruttura; L'obiettivo principale è di definire le diverse parti della soluzione che implementeranno quell'infrastruttura.

Argomenti secondari:

Elementi di automazione del test Inizio pagina

I requisiti chiave o le funzioni dell'infrastruttura di automazione del test richiedono:

  • Modello di navigazione: gli approcci comuni sono round-trip, segmentati o approcci ibridi. Altre alternative includono l'utilizzo di un framework Azione-Parola o tabelle di navigazione dello schermo
  • Accesso dati esterno: un metodo per accedere ai dati esternamente dalle istruzioni di test
  • Errore nel report e nel recupero: errore comune nella gestione delle routine e nei wrapper di esecuzione del recupero dello scenario di test
  • Profili di sicurezza e accesso: Id utente di esecuzione di test automatizzato
  • La capacità del software di condurre test autonomi

Registrare le decisioni come definizioni nelle sezioni di implementazione dell'Architettura di automazione test, guida del processo in una o più linee guida del test o come script del test, suite del test o programma di utilità delle routine di libreria di test. Consultare Prodotto di lavoro: Architettura di automazione test per ulteriori suggerimenti.

Elementi test manuali Inizio pagina

I requisiti chiave o le funzioni dell'infrastruttura di automazione del test includono:

  • Repository dati di test: un repository comune per la definizione dei dati di test.
  • Ripristino e recupero: un metodo per ripristinare o recuperare la configurazione dell'ambiente di test su uno stato conosciuto.
  • Per consentire agli elementi di test di destinazione ad essere isolati dal resto del sistema sviluppato e di essere verificati.

Registrare le decisioni come guida del processo in uno o più Prodotti di lavoro: Linee guida specifiche del progetto.

Valutazione e verifica dei risultati
Scopo:  Verificare che il compito sia stato completato in modo appropriato e che i prodotti di lavoro risultanti siano accettabili. 

Una volta completato il lavoro è bene verificare che questo sia stato di buona qualità, e che non si siano consumate unicamente grosse quantità di carta. È necessario valutare se il proprio lavoro sia stato all'altezza, e che sia completo abbastanza da essere utile ai membri del team che l'utilizzeranno in seguito. Dove possibile, utilizzare l'elenco di controllo fornito da RUP per verificarne la qualità e la completezza.

Richiedere ai componenti del team di concentrarsi sul flusso di operazioni che hanno come input il vostro lavoro e partecipare all'analisi effettuata durante il suo corso. Procedere in questo modo mentre si ha ancora tempo a disposizione per prendere decisioni e discutere delle loro considerazioni. È inoltre necessario considerare il proprio lavoro nei confronti dei prodotti di lavoro di input chiave, per assicurarsi che siano stati rappresentati in modo accurato e sufficiente. Potrebbe essere utile chiedere all'autore del prodotto di lavoro di input di revisionare il vostro lavoro su queste basi.

Tenere presente che RUP è un processo di produzione iterativo e che in molti casi i prodotti di lavoro evolvono nel tempo. Su questa base è spesso non necessario o addirittura controproducente, definire in modo completo un prodotto di lavoro che verrà utilizzato solo parzialmente o affatto, nel lavoro immediatamente successivo. Questo perché vi è un'alta probabilità che il contesto che circonda il prodotto di lavoro possa cambiare e che i presupposti definiti, quando questo è stato creato, possano dimostrarsi errati prima del suo utilizzo, portando così al dispendio inutile di sforzi ed ad ulteriori costi di rilavorazione. Non effettuare inoltre troppi cicli sulla presentazione per evitare il detrimento del valore del contenuto. Negli ambienti di progetto dove la presentazione ha la medesima importanza e valore economico di un componente distribuibile, è bene considerare la possibilità di utilizzare una risorsa amministrativa per il compito di presentazione.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni