Sarebbe opportuno testare i database e i processi database come un sottosistema indipendente. Tale verifica dovrebbe
testare i sottosistemi senza l'interfaccia utente dell'obiettivo del test come interfaccia ai dati. Occorre eseguire
un'ulteriore ricerca in DBMS (Database Management System), per identificare gli eventuali tool e tecniche di supporto
della verifica identificata nella seguente tabella.
Obiettivo della tecnica:
|
Verificare i processi e i metodi di accesso database indipendenti dell'UI in modo che sia possibile
osservare e registrare una funzionalità dell'obiettivo non corretta o un danneggiamento dati.
|
Tecnica:
|
Richiamare ogni processo e metodo di accesso database, assegnando a ognuno dati validi e non validi o
richieste di dati.
Esaminare il database per accertarsi che i dati siano stati popolati come previsto e che tutti gli
eventi database si siano verificati correttamente o esaminare i dati restituiti per accertarsi che
siano stati richiamati i dati corretti per le giuste ragioni.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
tool di automazione script del test
restorer e imager della configurazione di base
tool di ripristino e backup
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
tool e programmi di utilità database SQL
tool di generazione dati
|
Criteri di successo:
|
La tecnica supporta la verifica di tutti i processi e i metodi di accesso chiave del database.
|
Considerazioni speciali:
|
La verifica potrebbe richiedere un ambiente di sviluppo DBMS o dei driver per immettere e modificare i
dati direttamente nel database.
Sarebbe opportuno richiamare i processi manualmente.
Si consiglia di utilizzare database di dimensioni ridotte o minime (con un numero limitato di record)
per aumentare la visibilità di qualsiasi evento non accettabile.
|
La verifica delle funzioni dell'obiettivo del test dovrebbe essere incentrata sui requisiti del test che è possibile
tracciare direttamente sui casi d'uso o sulle funzioni e sulle regole di business. L'obiettivo di tali test è
verificare l'accettazione, l'elaborazione e il richiamo appropriati dei dati e l'implementazione appropriata delle
regole di business. Questo tipo di verifica si basa su tecniche di black box; ossia, si tratta di una verifica
dell'applicazione e dei relativi processi interni attraverso interazione con l'applicazione tramite GUI (Graphical User
Interface) e analisi dell'output o dei risultati. La seguente tabella identifica una struttura di verifica consigliata
per ogni applicazione.
Obiettivo della tecnica:
|
Verificare la funzionalità dell'obiettivo del test, compresa navigazione, immissione di dati,
elaborazione e richiamo per osservare e registrare la funzionalità dell'obiettivo.
|
Tecnica:
|
Verificare le singole caratteristiche e funzioni o flussi di ogni caso d'uso dello scenario,
utilizzando dati validi e non validi, per verificare che:
i risultati previsti si verificano in caso di utilizzo di dati validi
i messaggi di errore o di avvertenza appropriati vengono visualizzati in caso di utilizzo di dati non
validi
ogni regola di business viene applicata correttamente
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
tool di automazione script del test
restorer e imager della configurazione di base
tool di ripristino e backup
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
tool di generazione dati
|
Criteri di successo:
|
La tecnica supporta la verifica di:
tutti gli scenari chiave dei casi d'uso
tutte le funzioni chiave
|
Considerazioni speciali:
|
Identificare o descrivere tali voci o problematiche (interne o esterne) che hanno un impatto
sull'implementazione e sull'esecuzione del test delle funzioni.
|
La verifica del ciclo di business dovrebbe emulare le attività eseguite sul <Nome progetto> nel tempo. Si
consiglia di indicare un periodo, ad esempio un anno ed eseguire le transazioni e le attività che si potrebbero
verificare durante il suddetto periodo. Ciò potrebbe includere tutti i cicli giornalieri, settimanali e mensili e gli
eventi sensibili ai dati, ad esempio i memorandum.
Obiettivo della tecnica:
|
Verificare i processi dell'obiettivo del test e del background secondo i modelli di business necessari
e le pianificazioni per esaminare e registrare la funzionalità dell'obiettivo.
|
Tecnica:
|
La verifica simulerà diversi cicli di business, effettuando quanto segue:
I test utilizzati per la verifica delle funzioni dell'obiettivo del test verranno modificati o
ottimizzati per incrementare il numero di volte in cui ogni funzione viene eseguita per simulare
numerosi utenti differenti per un periodo specificato.
Tutte le funzioni sensibili a data e ora verranno eseguite utilizzando periodi temporali o date valide
e non valide.
Tutte le funzioni che si verificano in una pianificazione periodica verranno eseguite o avviate al
momento appropriato.
La verifica includerà l'utilizzo dei dati validi e non validi per verificare quanto segue:
I risultati previsti si verificano in caso di utilizzo di dati validi.
I messaggi di errore o di avvertenza appropriati vengono visualizzati in caso di utilizzo di dati non
validi.
Ogni regola di business viene applicata correttamente.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
tool di automazione script del test
restorer e imager della configurazione di base
tool di ripristino e backup
tool di generazione dati
|
Criteri di successo:
|
La tecnica supporta la verifica di tutti i cicli di business critici.
|
Considerazioni speciali:
|
E' possibile che gli eventi e le date di sistema richiedano attività di supporto speciali.
Un modello di business è necessario per identificare procedure e requisiti di test appropriati.
|
La verifica dell'interfaccia utente (UI - interfaccia utente) verifica un'interazione dell'utente con il software.
L'obiettivo della UI è verificare che la UI fornisca all'utente la navigazione e l'accesso appropriati tramite le
funzioni dell'obiettivo del test. Inoltre, la verifica della UI assicura che gli oggetti all'interno della UI
funzionino come previsto e siano conformi a standard industriali o aziendali.
Obiettivo della tecnica:
|
Verificare quanto segue per osservare e registrare la conformità degli standard e la funzionalità
dell'obiettivo:
Esplorazione dei requisiti e delle funzioni di business che riflettono l'obiettivo del test, comprese
window-to-window, field-to-field e utilizzo dei metodi d'accesso (tasti di tabulazione, movimenti del
mouse e tasti di scelta rapida).
E' possibile verificare le caratteristiche e gli oggetti della finestra, tra cui menu, dimensione,
posizione, stato e punto focale.
|
Tecnica:
|
Creare o modificare i test per ogni finestra per verificare stati degli oggetti ed esplorazione
appropriata di ogni oggetto e finestra dell'applicazione.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede il tool di automazione dello script del test.
|
Criteri di successo:
|
La tecnica supporta la verifica di ogni schermata o finestra principale che verrà utilizzata
frequentemente dall'utente.
|
Considerazioni speciali:
|
Non è possibile accedere a tutte le proprietà per oggetti di terze parti e personalizzati.
|
La creazione di profili delle prestazioni è un test delle prestazioni in cui vengono misurati e valutati i tempi di
risposta, la frequenza delle prestazioni e altri requisiti sensibili al tempo. L'obiettivo della creazione di profili
delle prestazioni è verificare che siano stati ottenuti i requisiti delle prestazioni. La creazione di profili delle
prestazioni viene implementata ed eseguita per creare profili e ottimizzare le funzionalità delle prestazioni
dell'obiettivo del test come funzione di condizioni, ad esempio come carico di lavoro o come configurazioni hardware.
Nota: Le transazioni nella seguente tabella si riferiscono alle "transazioni di business logiche". Tali
transazioni vengono definite come casi d'uso specifici di cui è prevista l'esecuzione da parte di un attore del
sistema, utilizzando l'obiettivo del test, come l'aggiunta o la modifica di un contratto specificato.
Obiettivo della tecnica:
|
Verificare le funzionalità per funzioni di business o transazioni funzionali designate alle seguenti
condizioni, per osservare e registrare la funzionalità dell'obiettivo e i dati sulle prestazioni
dell'applicazione:
normale carico di lavoro anticipato
carico di lavoro anticipato del caso peggiore
|
Tecnica:
|
Utilizzare le procedure di test sviluppate per la verifica del ciclo di business o di funzioni.
Modificare i file di dati per aumentare il numero di transazioni o gli script per aumentare il numero
di iterazioni che si verificano in ogni transazione.
Si consiglia di eseguire gli script su una macchina (il caso migliore è utilizzare come punto di
riferimento un singolo utente, una singola transazione) e di ripetere tali script con più client
(virtuali o reali, consultare la sezione successiva Considerazioni speciali).
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
tool di automazione script del test
un tool di creazione profili delle prestazioni di un'applicazione, come ad esempio Rational Quantify
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
tool di limitazione risorse; ad esempio, Canned Heat
|
Criteri di successo:
|
La tecnica supporta la verifica di:
Singola transazione o singolo utente: emulazione corretta degli script della transazione senza alcun
errore dovuto ai problemi di implementazione del test.
Più transazioni o più utenti: emulazione corretta del carico di lavoro senza alcun errore dovuto ai
problemi di implementazione del test.
|
Considerazioni speciali:
|
Una verifica completa delle prestazioni include la presenza di un carico di lavoro di background sul
server.
Vi sono diversi metodi per eseguire tale operazione, compresa:
"Conduzione diretta delle transazioni" sul server, generalmente nel formato di chiamate SQL (Structured
Query Language).
Creazione di un carico utente "virtuale" per simulare diversi client, generalmente diverse centinaia. I
tool di emulazione terminale remota vengono utilizzati per ottenere tale carico. Tale tecnica può
essere utilizzata anche per caricare la rete con del "traffico".
Utilizzo di più client fisici, ognuno dei quali esegue degli script di test, per inserire un carico sul
sistema.
La verifica delle prestazioni dovrebbe essere eseguita su una macchina dedicata o in un determinato
momento. In questo modo è possibile ottenere pieno controllo e misurazioni accurate.
I database utilizzati per la verifica delle prestazioni dovrebbero essere la dimensione reale o una
riduzione in scala equivalente.
|
La verifica del carico è un test delle prestazioni che sottopone l'obiettivo del test a carichi di lavoro variabili per
misurare e valutare le funzionalità delle prestazioni e le capacità dell'obiettivo del test di continuare a funzionare
correttamente sotto tali carichi di lavoro differenti. L'obiettivo della verifica del carico è determinare e verificare
che il sistema funzioni correttamente oltre il massimo carico di lavoro previsto. Inoltre, la verifica del carico
valuta le caratteristiche delle prestazioni, come ad esempio i tempi di risposta, le incidenze di transazione e altre
questioni sensibili a data/ora.
Nota: Le transazioni nella seguente tabella si riferiscono alle "transazioni di business logiche". Tali
transazioni vengono definite come funzioni specifiche di cui è prevista l'esecuzione da parte di un utente del sistema,
utilizzando l'applicazione, come l'aggiunta o la modifica di un contratto specificato.
Obiettivo della tecnica:
|
Verificare le transazioni designate o i casi di business in condizioni variabili del carico di lavoro
per osservare e registrare la funzionalità dell'obiettivo e i dati di prestazioni del sistema.
|
Tecnica:
|
Utilizzare gli script del test di transazione sviluppati per la verifica del ciclo di business o di
funzioni come base, ma ricordare di rimuovere ritardi e interazioni non necessari.
Modificare i file di dati per aumentare il numero di transazioni o i test per aumentare il numero di
volte in cui si verifica ogni transazione.
I carichi di lavoro dovrebbero includere, ad esempio, carichi di picco giornalieri, settimanali e
mensili.
I carichi di lavoro dovrebbero rappresentare sia carichi di lavoro di picco che medi.
I carichi di lavoro dovrebbero rappresentare sia picchi istantanei che sostenuti.
I carichi di lavoro dovrebbero essere eseguiti in differenti configurazioni dell'ambiente di test.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
tool di automazione script del test
tool di controllo e pianificazione del carico della transazione
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
tool di limitazione risorse; ad esempio, Canned Heat
tool di generazione dati
|
Criteri di successo:
|
La tecnica supporta la verifica dell'emulazione del carico di lavoro, che è l'emulazione corretta del
carico di lavoro senza alcun errore dovuto ai problemi di implementazione del test.
|
Considerazioni speciali:
|
La verifica del carico di lavoro dovrebbe essere eseguita su una macchina dedicata o in un determinato
momento. In questo modo è possibile ottenere pieno controllo e misurazioni accurate.
I database utilizzati per la verifica del carico dovrebbero essere la dimensione reale o una riduzione
in scala equivalente.
|
La verifica della resistenza è un tipo di test delle prestazioni implementato ed eseguito per comprendere in che modo
un sistema ha esito negativo a causa delle condizioni al boundary o al di fuori dei livelli di tolleranza previsti. Ciò
include generalmente scarse risorse o competizione per risorse. Condizioni di risorse scarse rivelano quand'è che
l'obiettivo del test ha esito negativo, non evidente in condizioni normali. Altri difetti potrebbero derivare dalla
competizione per risorse condivise, come i blocchi del database o la larghezza di banda della rete, sebbene alcuni dei
test generalmente vengano eseguiti in una verifica funzionale e di caricamento.
Nota: I riferimenti alle transazioni nella seguente tabella si riferiscono alle transazioni di business logiche.
Obiettivo della tecnica:
|
Verificare le funzioni dell'obiettivo del test alle seguenti condizioni di stress per osservare e
registrare la funzionalità dell'obiettivo che identifica e documenta le condizioni in cui il sistema
non riesce a continuare il suo normale funzionamento:
memoria scarsa o non disponibile sul server (RAM e spazio di memoria permanente)
numero di client connessi o simulati massimo e reale o con capacità fisica
più utenti che eseguono le stesse transazioni rispetto agli stessi dati o account
combinazione o volume della transazione di "sovraccarico" (consultare la sezione precedente relativa
alla Creazione di profili delle prestazioni)
|
Tecnica:
|
Utilizzare test sviluppati per la creazione di profili delle prestazioni o per la verifica del carico.
Per testare risorse limitate, si consiglia di eseguire i test su una singola macchina e di ridurre o
limitare la RAM e gli spazi di memoria permanenti sul server.
Per i test della resistenza rimanenti, si consiglia di utilizzare più client, eseguendo gli stessi test
o test complementari per produrre la combinazione o il volume di transazioni del caso peggiore.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
tool di automazione script del test
tool di controllo e pianificazione del carico della transazione
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
tool di limitazione risorse; ad esempio, Canned Heat
tool di generazione dati
|
Criteri di successo:
|
La tecnica supporta la verifica dell'emulazione dello stress. Il sistema può essere emulato
correttamente in una o più condizioni definite come condizioni di stress ed è possibile catturare
un'osservazione dello stato di sistema risultante, durante e dopo l'emulazione della condizione.
|
Considerazioni speciali:
|
Lo stress della rete potrebbe richiedere tool di rete per caricare la rete con messaggi o con
pacchetti.
La memoria permanente utilizzata per il sistema dovrebbe essere ridotta temporaneamente per limitare lo
spazio disponibile per la crescita del database.
Sincronizzare i client simultanei tramite accesso agli stessi record o account di dati.
|
La verifica del volume sottopone l'obiettivo del test a elevate quantità di dati per stabilire se vengono raggiunti i
limiti causano l'esito negativo del software. La verifica del volume identifica anche il massimo carico o volume
continuo che può essere gestito dall'obiettivo del test per un determinato periodo. Ad esempio, se l'obiettivo del test
elabora una serie di record del database per generare un report, un test del volume utilizzerà un database di test di
dimensioni elevate e controllerà il corretto funzionamento del software e la produzione del report corretto da parte di
tale software.
Obiettivo della tecnica:
|
Verificare le funzioni dell'obiettivo del test nei seguenti scenari di volume elevato per osservare e
registrare la funzionalità dell'obiettivo:
Il numero massimo (reale o con capacità fisica) di client connessi o simulati, che eseguono la stessa
funzione di business (prestazioni) del caso peggiore per un periodo prolungato.
La dimensione massima del database è stata raggiunta (reale o in scala) e più query o transazioni di
report vengono eseguite contemporaneamente.
|
Tecnica:
|
Utilizzare test sviluppati per la creazione di profili delle prestazioni o per la verifica del carico.
Si consiglia di utilizzare più client, eseguendo gli stessi test o test complementari per produrre la
combinazione o il volume di transazioni del caso peggiore (consultare Verifica della resistenza) per un
periodo prolungato.
La dimensione database massima (reale, in scala o dotata di dati rappresentativi) viene creata e più
client vengono utilizzati per eseguire contemporaneamente query e transazioni di report per periodi
prolungati.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
tool di automazione script del test
tool di controllo e pianificazione del carico della transazione
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
tool di limitazione risorse; ad esempio, Canned Heat
tool di generazione dati
|
Criteri di successo:
|
La tecnica supporta la verifica dell'emulazione del volume. E' possibile emulare correttamente numeri
elevati di utenti, dati, transazioni o altri aspetti di utilizzo del sistema al di sotto del volume,
così come è possibile catturare un'osservazione dei cambiamenti di stato del sistema per la durata del
volume.
|
Considerazioni speciali:
|
Quale periodo di tempo dovrebbe essere considerato un periodo accettabile per condizioni di volume
elevato, come indicato in precedenza?
|
La verifica del controllo di accessi e della sicurezza è incentrata su due aree chiave di sicurezza:
Sicurezza a livello dell'applicazione, compreso l'accesso ai dati o alle funzioni di business
Sicurezza a livello di sistema, compresa la registrazione o l'accesso remoto al sistema
In base alla sicurezza che si desidera, la sicurezza a livello dell'applicazione assicura che agli attori vengano
impedite specifiche funzioni o casi d'uso o che venga consentito loro l'accesso esclusivamente ai dati disponibili. Ad
esempio, a chiunque è consentito immettere dati e creare nuovi account, ma solo i responsabili possono eliminarli. Se
esiste una sicurezza a livello dei dati, la verifica assicura che l'utente "di tipo uno" possa visualizzare tutte le
informazioni sul cliente, compresi i dati finanziari, tuttavia l'utente "di tipo due" visualizza solo i dati
demografici dello stesso client.
La sicurezza a livello del sistema assicura che solo gli utenti a cui è stato concesso l'accesso al sistema possano
accedere alle applicazioni e soltanto attraverso gateway appropriati.
Obiettivo della tecnica:
|
Verificare l'obiettivo del test alle seguenti condizioni per osservare e registrare la funzionalità
dell'obiettivo:
Sicurezza a livello dell'applicazione: un attore può accedere solo alle funzioni o ai dati per cui
vengono fornite le autorizzazioni al relativo tipo di utente.
Sicurezza a livello del sistema: solo agli attori con accesso al sistema e alle applicazioni viene
consentito tale accesso.
|
Tecnica:
|
Sicurezza a livello dell'applicazione: identificare ed elencare ogni tipo di utente e le funzioni o i
dati per cui ogni tipo dispone delle autorizzazioni.
Creare test per ogni tipo di utente e verificare ogni autorizzazione creando transazioni specifiche per
ogni tipo di utente.
Modificare il tipo di utente e rieseguire i test per lo stesso utente. In ogni caso, verificare che
tali dati o funzioni siano disponibili o negati nel modo corretto.
Accesso a livello del sistema; consultare la sezione successiva Considerazioni speciali.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
tool di automazione script del test
Tool di analisi e violazione della sicurezza "Hacker"
Tool di gestione della sicurezza OS
|
Criteri di successo:
|
La tecnica supporta che la verifica delle funzioni o dei dati appropriati, influenzati dalle
impostazioni della sicurezza, possa essere eseguita per ogni tipo di attore noto.
|
Considerazioni speciali:
|
E' necessario esaminare o discutere l'accesso al sistema con l'amministratore di sistemi o di rete
appropriato. Questa verifica potrebbe non essere necessaria poiché è possibile che sia una funzione di
gestione di rete o dei sistemi.
|
La verifica del ripristino e del failover assicura che l'obiettivo del test possa eseguire il failover e il ripristino
corretto da vari malfunzionamenti dell'hardware, del software o della rete con una perdita di dati o un'integrità di
dati eccessiva.
Per i sistemi che occorre mantenere in esecuzione, la verifica del failover assicura che, quando si verifica una
condizione di failover, i sistemi di backup o alternativi "sostituiscano" correttamente il sistema in errore senza
alcuna perdita di dati o transazioni.
La verifica del ripristino è un processo di test antagonistico in cui l'applicazione o il sistema viene esposto a
condizioni estreme o condizioni simulate, per causare un errore, ad esempio errori I/O (Input/Output) o chiavi e
puntatori database non validi. I processi di ripristino vengono richiamati e l'applicazione o il sistema viene
monitorato e rivisto per verificare che sia quello giusto e che il ripristino dei dati sia stato raggiunto.
Obiettivo della tecnica:
|
Simulare le condizioni di errore e verificare i processi di ripristino (manuali e automatizzati) per
ripristinare il database, le applicazioni e il sistema in uno stato noto e desiderato. I seguenti tipi
di condizioni sono inclusi nella verifica per osservare e registrare la funzionalità successiva al
ripristino:
interruzione dell'alimentazione al client
interruzione dell'alimentazione al server
interruzione della comunicazione tramite i server di rete
interruzione, comunicazione o perdita di alimentazione su DASD (Direct Access Storage Devices) e
controller DASD
cicli incompleti (processi di filtro e sincronizzazione dati interrotti)
chiavi o puntatori database non validi
elementi di dati non validi o danneggiati nel database
|
Tecnica:
|
I test già creati per la verifica del ciclo di business o di funzioni possono essere utilizzati come
base per la creazione di una serie di transazioni per supportare la verifica del ripristino e del
failover, principalmente per definire i test da eseguire per testare che il ripristino sia stato
eseguito correttamente.
Interruzione di alimentazione al client: spegnere il PC.
Interruzione di alimentazione al server: simulare o avviare le procedure di spegnimento del server.
Interruzione tramite server di rete: simulare o avviare la perdita di comunicazione con la rete
(scollegare fisicamente i cavi di comunicazione o spegnere i router o i server di rete).
Interruzione, comunicazione o perdita di alimentazione su DASD e controller DASD: simulare o eliminare
fisicamente la comunicazione con uno o più DASD o controller DASD.
Una volta raggiunte le suddette condizioni o condizioni simulate, si consiglia di eseguire ulteriori
transazioni e, in seguito a raggiungimento di questo secondo stato del punto di test, si consiglia di
richiamare le procedure di ripristino.
La verifica di cicli incompleti utilizza la stessa tecnica descritta in precedenza, con l'eccezione che
occorre interrompere o terminare prematuramente i processi del database.
La verifica delle seguenti condizioni richiede il raggiungimento di uno stato database noto. Si
consiglia di danneggiare i diversi campi, puntatori e chiavi del database manualmente e all'interno del
database (tramite i tool del database). Sarebbe opportuno eseguire ulteriori transazioni utilizzando la
verifica del ciclo di business e delle funzioni dell'applicazione, oltre che dei cicli completi
eseguiti.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
restorer e imager della configurazione di base
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
tool di ripristino e backup
|
Criteri di successo:
|
La tecnica supporta la verifica di:
Uno o più "disastri" che interessano una o più combinazioni di applicazione, database e sistema.
Uno o più ripristini simulati che interessano una o più combinazioni di applicazione, database e
sistema in uno stato desiderato noto.
|
Considerazioni speciali:
|
La verifica del ripristino è estremamente invasiva. Le procedure di disconnessione del cablaggio (che
simulano una perdita di alimentazione o di comunicazione) potrebbero non essere auspicabili o
realizzabili. E' possibile che siano necessari dei metodi alternativi, tra cui i tool del software
diagnostici.
Le risorse dei gruppi Sistemi (o Operazioni del computer), Database, Rete sono necessarie.
Si consiglia di eseguire tali test dopo alcune ore o su una macchina isolata.
|
La verifica della configurazione esamina l'operazione dell'obiettivo del test su configurazioni software e hardware
differenti. Nella maggior parte degli ambienti di produzione, le particolari specifiche hardware per le workstation del
client, le connessioni di rete e i server del database variano. E' possibile che sulle workstation del client siano
stati caricati diversi software (ad esempio, applicazioni, driver e così via) e, allo stesso tempo, potrebbero essere
attive numerose combinazioni differenti utilizzando diverse risorse.
Obiettivo della tecnica:
|
Verificare l'obiettivo del test sulle configurazioni hardware e software richieste per osservare e
registrare la funzionalità dell'obiettivo in differenti configurazioni e identificare le modifiche allo
stato della configurazione.
|
Tecnica:
|
Utilizzare gli script di test della funzione.
Aprire e chiudere differenti software correlati che non appartengono all'obiettivo del test, ad esempio
applicazioni Microsoft® Excel® e Microsoft® Word®, come parte del test o prima dell'inizio del test.
Eseguire transazioni selezionate per simulare gli attori che interagiscono con l'obiettivo del test e
con il software non appartenente al suddetto obiettivo.
Ripetere il processo precedente, riducendo al minimo la memoria convenzionale disponibile sulla
workstation client.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
restorer e imager della configurazione di base
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
|
Criteri di successo:
|
La tecnica supporta la verifica di una o più combinazioni delle voci del test dell'obiettivo, eseguita
in ambienti di distribuzione supportati e previsti.
|
Considerazioni speciali:
|
Quale software estraneo all'obiettivo del test è necessario, disponibile e accessibile sul desktop?
Quali applicazioni vengono generalmente utilizzate?
Che dati contengono le applicazioni in esecuzione; ad esempio, un foglio di calcolo di grandi
dimensioni aperto in Excel o un documento di 100 pagine in Word?
Anche il netware degli interi sistemi, i server di rete, i database e così via devono essere
documentati come parte di questo test.
|
La verifica dell'installazione ha due scopi. Il primo è assicurare che il software possa essere installato in
condizioni differenti (ad esempio una nuova installazione, un aggiornamento e un'installazione completa o
personalizzata) in condizioni normali e anomale. Le condizioni anomale includono spazio su disco insufficiente,
mancanza di privilegi per creare directory e così via. Il secondo obiettivo è verificare che, una volta installato, il
software funzioni correttamente. Ciò implica, generalmente, l'esecuzione di alcuni test sviluppati per la verifica
delle funzioni.
Obiettivo della tecnica:
|
Verificare l'installazione dell'obiettivo del test su ogni configurazione hardware richiesta alle
seguenti condizioni, per osservare e registrare le modifiche allo stato della configurazione e alla
funzionalità di installazione:
nuova installazione: una nuova macchina, mai installata in precedenza con <Nome progetto>
aggiornamento: una macchina installata precedentemente con <Nome progetto>, stessa versione
aggiornamento: una macchina installata precedentemente con <Nome progetto>, versione precedente
|
Tecnica:
|
Sviluppare script automatizzati o manuali per convalidare la condizione della macchina di destinazione.
nuovo: <Nome progetto> mai installato
<Nome progetto>, stessa versione o versione precedente, installato
Avviare o eseguire l'installazione.
Utilizzando una sottoserie predeterminata di script di test delle funzioni, eseguire la transazioni.
|
Oracoli:
|
Evidenziare una o più strategie che è possibile utilizzare tramite la tecnica per osservare in modo
preciso i risultati del test. L'oracolo combina sia gli elementi del metodo tramite cui è possibile
creare l'osservazione che le caratteristiche di un risultato specifico che indica un probabile successo
o errore. Idealmente, gli oracoli sono auto-verificati e, nei test automatizzati, consentono una
valutazione iniziale del superamento o dell'errore del test; tuttavia, prestare attenzione
nell'attenuazione dei rischi inerenti nell'individuazione automatizzata dei risultati.
|
Tool necessari:
|
La tecnica richiede i seguenti tool:
restorer e imager della configurazione di base
tool di monitoraggio-installazione (registro, hard-disk, CPU, memoria e così via)
|
Criteri di successo:
|
La tecnica supporta la verifica dell'installazione del prodotto sviluppato in una o più configurazioni
di installazione.
|
Considerazioni speciali:
|
Quali transazioni di <Nome progetto> occorre selezionare per includere un test che confermi che
l'applicazione <Nome progetto> è stata installata correttamente e che non manca alcun componente
software principale?
|
|