Esaminare l'elemento del test di destinazione e l'elenco delle proposte di test
Scopo:
|
Ottenere una conoscenza più dettagliata dell'elemento del test di destinazione basata sulle possibili
proposte di test.
|
Utilizzando l'elenco proposte di test come contesto, esaminare le informazioni disponibili sull'elemento di test di
destinazione. Il caso d'uso e i prodotti di lavoro relativi (ad.es. realizzazione, storyboard e scenari del caso d'uso)
sono di solito buone origini con cui iniziare, in aggiunta a qualsiasi specifica supplementare, regola di business e
prodotto di lavoro di progettazione.
Laddove sono disponibili informazioni limitate, può essere necessario discutere direttamente dell'elemento di test di
destinazione con il personale di sviluppo.
|
Selezione di un sottoinsieme di proposte di test da dettagliare
Scopo:
|
Determinare un sottoinsieme gestibile di test per definire quali sono i maggiori vantaggi nel contesto
corrente.
|
Rivedere l'elenco delle proposte di test e scegliere un numero di proposte di test che verranno dettagliate per i test.
Nella maggior parte dei casi, le proposte di test vengono scelte in base ai vincoli di tempo, all'importanza della
proposta per l'attuale ciclo di test, completezza dell'elemento di test di destinazione e così via. In funzione dello
specifico contesto della propria situazione, il numero di proposte di test che si portano avanti nel progetto del
corrente ciclo di test varia da caso a caso.
Si consiglia di evitare la progettazione di tutte le proposte di test, la prima volta che si progetta da un elenco di
proposte di test. Al contrario, procedere con un approccio lavorativo crescente e iterativo con tale elenco,
concentrando preferibilmente gli sforzi sulle poche proposte che si ritengono maggiormente utili per la produzione di
informazioni di valore per il dato ciclo di test. Ciò aiuta ad attenuare il rischio di impiegare troppo tempo su un
singolo elemento di test di destinazione a danno degli altri e a ridurre il rischio di impiegare lo sforzo su progetti
di proposte di test che successivamente possono destare poco interesse.
|
Progettazione del test per ogni proposta di test
Scopo:
|
Definire le caratteristiche principali di ogni test che deve derivare dall'elenco delle proposte di
test.
|
Utilizzando le informazioni ottenute finora, progettare il test identificando e definendo le caratteristiche
principali che saranno necessarie per realizzarlo. Si noti che il progetto di test risultante può essere acquisito in
diversi modi:
-
Tradizionalmente, il progetto di test veniva acquisito come un Prodotto
di lavoro: Scenario di test.
-
Il Prodotto di lavoro: Modello di analisi del carico di lavoro è
concettualmente un modulo specializzato e più complesso dello scenario di test, che si relaziona in modo specifico
alla verifica delle prestazioni del sistema.
-
In base alla complessità del test e alla cultura del progetto, può essere più appropriato realizzare il test
direttamente come un Prodotto
di lavoro: Script di test, un approccio che si dovrebbe considerare, se accettabile, per non creare artefatti
di scenari di test. Se si utilizza questo approccio, assicurarsi di commentare abbondantemente i propri script di
test con valide informazioni che spiegano l'utilità del test. Utilizzare questi commenti per simulare uno
scenario di test informale e in linea.
Utilizzando le informazioni ottenute, considerare ciascuno dei seguenti aspetti del test.
Considerando il test da una prospettiva di black-box, identificare le principali caratteristiche esterne visibili che
definiscono il test. Identificare quali input verranno richiesti per incentivare il test e quali output risultanti
saranno attesi. Elencare anche le condizioni principali di esecuzione: la "modalità" della condizione di esecuzione non
deve essere spiegata e compresa in questa fase.
Si noti che l'input e l'output previsto dipenderà dalla specifica gamma di dati che va dai semplici dati di valori (ad
es., "A", "1") a dati multidimensionali complessi (ad es., uno spezzone audio, un oggetto). È meglio definire i
qualificatori dietro a un input particolare o all'output previsto, piuttosto che fornire valori specifici. Ciò fornisce
alla persona che implementa o esegue successivamente il test, la comprensione necessaria del ragionamento presente
dietro ai dati del test, consentendo di scegliere valori sostitutivi per variare il test in qualsiasi esecuzione
stabilita.
Un punto di osservazione è un punto in cui, durante l'esecuzione del test, si
osservano alcuni aspetti dello stato dell'ambiente di test. Poiché si conoscono le condizioni di esecuzione, l'input e
l'output previsto, identificare quali punti specifici e quali dati devono essere osservati durante l'esecuzione del
test.
Un punto di controllo è un punto in cui, durante l'esecuzione del test, si
desidera prendere una delle tante decisioni relative al controllo del flusso del test. Esaminare gli scenari di test
disponibili e per ognuno di essi considerare i punti in cui il controllo varierà con diverse esecuzioni del test.
Raccogliere tutti i punti di controllo diversi e ridurre l'elenco a quelli necessari per il corrente ciclo di test.
Un oracolo di test unisce i valori di output previsti e da verificare,
con gli strumenti tramite i quali quei valori possono essere predetti: sia la risposta che lo strumento attraverso cui
viene fornita. Ad esempio, per verificare la rappresentazione accurata dei caratteri utilizzati in un pacchetto per
elaboratore di testi, l'anteprima di stampa può essere utilizzata come strumento tramite il quale è possibile
verificare la rappresentazione del carattere. L'oracolo di test identifica gli aspetti, sia nella forma che nella
funzione, che sono necessari per verificare i risultati attuali del test rispetto a quelli previsti.
|
Definizione delle fonti di dati, dei valori e degli intervalli richiesti
Scopo:
|
Definire i valori dei dati di test richiesti, includendo le origini appropriate di tali dati.
|
Come indicato in precedenza, i dati di test si presentano in molti formati.
Laddove le interdipendenze di dati complessi sono accettabili, provare a utilizzare gli esperti di dominio per
specificare le appropriate condizioni dei dati di test. Alcuni tool di produttività di test forniscono caratteristiche
e funzioni utili che consentono la creazione semplificata di insiemi di dati di test.
|
Creazione di sufficienti dati di test utilizzabili
Scopo:
|
Creare e registrare sufficienti dati di test validi per il supporto del test.
|
La generazione accurata o la raccolta di dati di test appropriati rappresenta una delle attività più difficili e lunghe
nella definizione di un test. ciò si verifica in particolar modo nel sistema di una classe che presenta un notevole
carico di dati.
Si consiglia di registrare i dati di test in Microsoft® Excel® o altro prodotto con interfaccia di gestione dati
tabellare, come Microsoft® Access®.
|
Gestione delle relazioni di tracciabilità
Scopo:
|
Abilitare l'esecuzione della segnalazione dell'analisi d'impatto e della valutazione sugli elementi
tracciati.
|
Utilizzando i requisiti di tracciabilità evidenziati nel piano di test, aggiornare le relazioni di tracciabilit… come
richiesto.
|
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.
Cercare di ricordare che quel RUP è un processo iterativo e che in molti casi i prodotti di lavoro si 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.
|
|