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:
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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
|
|