Test del software - Guida rapida

Cos'è il test?

Il test è il processo di valutazione di un sistema o dei suoi componenti con l'intento di scoprire se soddisfa o meno i requisiti specificati. In parole semplici, il test è l'esecuzione di un sistema al fine di identificare eventuali lacune, errori o requisiti mancanti in contrasto con i requisiti effettivi.

Secondo lo standard ANSI / IEEE 1059, il test può essere definito come - Un processo di analisi di un elemento software per rilevare le differenze tra le condizioni esistenti e richieste (ovvero difetti / errori / bug) e per valutare le caratteristiche dell'elemento software.

Chi fa i test?

Dipende dal processo e dagli stakeholder associati al progetto (i). Nel settore IT, le grandi aziende hanno un team con la responsabilità di valutare il software sviluppato nel contesto dei requisiti dati. Inoltre, gli sviluppatori conducono anche test che si chiamanoUnit Testing. Nella maggior parte dei casi, i seguenti professionisti sono coinvolti nel test di un sistema nell'ambito delle rispettive capacità:

• Software Tester
• Sviluppatore di software
• Capo / responsabile del progetto
• Utente finale

Diverse aziende hanno designazioni diverse per le persone che testano il software sulla base della loro esperienza e conoscenza come Software Tester, Software Quality Assurance Engineer, QA Analyst, ecc.

Non è possibile testare il software in nessun momento durante il suo ciclo. Le due sezioni successive indicano quando avviare il test e quando terminarlo durante l'SDLC.

Quando iniziare il test?

Un inizio precoce del test riduce i costi e il tempo per rielaborare e produrre software privo di errori che viene consegnato al cliente. Tuttavia, in Software Development Life Cycle (SDLC), il test può essere avviato dalla fase di raccolta dei requisiti e continuato fino alla distribuzione del software.

Dipende anche dal modello di sviluppo utilizzato. Ad esempio, nel modello Waterfall, il test formale viene condotto nella fase di test; ma nel modello incrementale, il test viene eseguito alla fine di ogni incremento / iterazione e l'intera applicazione viene testata alla fine.

I test vengono eseguiti in diverse forme in ogni fase dell'SDLC:

• Durante la fase di raccolta dei requisiti, anche l'analisi e la verifica dei requisiti sono considerate test.

• Anche la revisione del progetto in fase di progettazione con l'intento di migliorarlo è considerata come prova.

• Anche i test eseguiti da uno sviluppatore al completamento del codice sono classificati come test.

Quando interrompere il test?

È difficile determinare quando interrompere il test, poiché il test è un processo senza fine e nessuno può affermare che un software è testato al 100%. I seguenti aspetti devono essere considerati per interrompere il processo di test:

• Scadenze dei test

• Completamento dell'esecuzione del test case

• Completamento della copertura funzionale e del codice fino a un certo punto

• Il tasso di bug scende al di sotto di un certo livello e non vengono identificati bug ad alta priorità

• Decisione di gestione

Verifica e convalida

Questi due termini creano molta confusione per la maggior parte delle persone, che li usano in modo intercambiabile. La tabella seguente evidenzia le differenze tra verifica e convalida.

Sr.No.	Verifica	Validazione
1	La verifica risolve il problema: "Stai costruendo bene?"	La convalida affronta la preoccupazione: "Stai costruendo la cosa giusta?"
2	Assicura che il sistema software soddisfi tutte le funzionalità.	Assicura che le funzionalità soddisfino il comportamento previsto.
3	La verifica viene eseguita per prima e include il controllo della documentazione, del codice, ecc.	La convalida avviene dopo la verifica e prevede principalmente il controllo dell'intero prodotto.
4	Fatto dagli sviluppatori.	Fatto dai tester.
5	Ha attività statiche, poiché include la raccolta di revisioni, procedure dettagliate e ispezioni per verificare un software.	Ha attività dinamiche, poiché include l'esecuzione del software in base ai requisiti.
6	È un processo oggettivo e non dovrebbe essere necessaria alcuna decisione soggettiva per verificare un software.	È un processo soggettivo e implica decisioni soggettive su come funziona un software.

Di seguito sono riportati alcuni dei miti più comuni sui test del software.

Mito 1: i test sono troppo costosi

Reality- C'è un detto: pagare di meno per i test durante lo sviluppo del software o pagare di più per la manutenzione o la correzione in seguito. I primi test consentono di risparmiare tempo e costi in molti aspetti, tuttavia la riduzione dei costi senza test può comportare una progettazione errata di un'applicazione software che rende il prodotto inutilizzabile.

Mito 2: i test richiedono tempo

Reality- Durante le fasi SDLC, il test non è mai un processo che richiede tempo. Tuttavia, la diagnosi e la correzione degli errori identificati durante i test adeguati è un'attività che richiede tempo ma produttiva.

Mito 3: vengono testati solo prodotti completamente sviluppati

Reality- Senza dubbio, il test dipende dal codice sorgente, ma la revisione dei requisiti e lo sviluppo di casi di test è indipendente dal codice sviluppato. Tuttavia, l'approccio iterativo o incrementale come modello del ciclo di vita di sviluppo può ridurre la dipendenza dei test dal software completamente sviluppato.

Mito 4: è possibile un test completo

Reality- Diventa un problema quando un cliente o un tester pensa che sia possibile un test completo. È possibile che tutti i percorsi siano stati testati dal team, ma il verificarsi di un test completo non è mai possibile. Potrebbero esserci alcuni scenari che non vengono mai eseguiti dal team di test o dal client durante il ciclo di vita dello sviluppo del software e possono essere eseguiti una volta che il progetto è stato distribuito.

Mito 5: un software testato è privo di bug

Reality - Questo è un mito molto comune in cui credono i clienti, i project manager e il team di gestione. Nessuno può affermare con assoluta certezza che un'applicazione software sia priva di bug al 100% anche se un tester con eccellenti capacità di test ha testato l'applicazione .

Mito 6: i difetti mancati sono dovuti ai tester

Reality- Non è un approccio corretto incolpare i tester per i bug che rimangono nell'applicazione anche dopo che il test è stato eseguito. Questo mito si riferisce a tempo, costo e requisiti che cambiano i vincoli. Tuttavia, la strategia di test può anche far sì che i bug vengano ignorati dal team di test.

Mito 7: i tester sono responsabili della qualità del prodotto

Reality- È un'errata interpretazione molto comune che solo i tester o il team di test dovrebbero essere responsabili della qualità del prodotto. Le responsabilità dei tester includono l'identificazione dei bug per gli stakeholder e poi spetta a loro decidere se correggere il bug o rilasciare il software. Il rilascio del software in quel momento mette più pressione sui tester, poiché saranno accusati di qualsiasi errore.

Mito 8: l'automazione del test dovrebbe essere utilizzata ove possibile per ridurre i tempi

Reality- Sì, è vero che Test Automation riduce i tempi di test, ma non è possibile avviare l'automazione di test in qualsiasi momento durante lo sviluppo del software. L'automa di prova dovrebbe essere avviato quando il software è stato testato manualmente ed è stabile in una certa misura. Inoltre, l'automazione dei test non può mai essere utilizzata se i requisiti continuano a cambiare.

Mito 9: chiunque può testare un'applicazione software

Reality- Le persone al di fuori del settore IT pensano e addirittura credono che chiunque possa testare un software e il test non è un lavoro creativo. Tuttavia i tester sanno molto bene che questo è un mito. Pensando a scenari alternativi, provare a mandare in crash un software con l'intento di esplorare potenziali bug non è possibile per la persona che lo ha sviluppato.

Mito 10: l'unico compito di un tester è trovare i bug

Reality- Trovare bug in un software è compito dei tester, ma allo stesso tempo sono esperti di dominio del software particolare. Gli sviluppatori sono responsabili solo del componente specifico o dell'area assegnata loro, ma i tester comprendono il funzionamento generale del software, quali sono le dipendenze e gli impatti di un modulo su un altro modulo.

Test, garanzia di qualità e controllo di qualità

La maggior parte delle persone si confonde quando si tratta di individuare le differenze tra garanzia di qualità, controllo di qualità e test. Sebbene siano correlati e in una certa misura, possono essere considerati come le stesse attività, ma esistono punti distintivi che li distinguono. La tabella seguente elenca i punti che differenziano QA, QC e Test.

Garanzia di qualità	Controllo di qualità	Test
La garanzia di qualità include attività che garantiscono l'implementazione di processi, procedure e standard nel contesto della verifica del software sviluppato e dei requisiti previsti.	Comprende attività che assicurano la verifica di un software sviluppato rispetto a requisiti documentati (o meno in alcuni casi).	Comprende attività che garantiscono l'identificazione di bug / errori / difetti in un software.
Si concentra su processi e procedure piuttosto che condurre test effettivi sul sistema.	Si concentra sui test effettivi eseguendo il software con l'obiettivo di identificare bug / difetti attraverso l'implementazione di procedure e processi.	Si concentra sui test effettivi.
Attività orientate al processo.	Attività orientate al prodotto.	Attività orientate al prodotto.
Attività preventive.	È un processo correttivo.	È un processo preventivo.
È un sottoinsieme di Software Test Life Cycle (STLC).	Il controllo di qualità può essere considerato come il sottoinsieme della garanzia di qualità.	Il test è il sottoinsieme del controllo di qualità.

Audit e ispezione

Audit- È un processo sistematico per determinare come viene condotto il processo di test effettivo all'interno di un'organizzazione o di un team. In generale, è un esame indipendente dei processi coinvolti durante il test di un software. Secondo IEEE, è una revisione dei processi documentati che le organizzazioni implementano e seguono. I tipi di audit includono audit di conformità legale, audit interno e audit di sistema.

Inspection- È una tecnica formale che comporta revisioni tecniche formali o informali di qualsiasi artefatto identificando eventuali errori o lacune. Secondo IEEE94, l'ispezione è una tecnica di valutazione formale in cui i requisiti, i progetti oi codici del software vengono esaminati in dettaglio da una persona o un gruppo diverso dall'autore per rilevare errori, violazioni degli standard di sviluppo e altri problemi.

Le riunioni di ispezione formale possono includere i seguenti processi: pianificazione, preparazione della panoramica, riunione di ispezione, rilavorazione e follow-up.

Test e debug

Testing- Implica l'identificazione di bug / errori / difetti in un software senza correggerlo. Normalmente i professionisti con un background di garanzia della qualità sono coinvolti nell'identificazione dei bug. Il test viene eseguito nella fase di test.

Debugging- Implica l'identificazione, l'isolamento e la risoluzione dei problemi / bug. Gli sviluppatori che codificano il software eseguono il debug quando riscontrano un errore nel codice. Il debug fa parte del White Box Testing o Unit Testing. Il debug può essere eseguito nella fase di sviluppo durante lo svolgimento di unit test o in fasi durante la correzione dei bug segnalati.

Molte organizzazioni in tutto il mondo sviluppano e implementano standard diversi per migliorare le esigenze di qualità del proprio software. Questo capitolo descrive brevemente alcuni degli standard ampiamente utilizzati relativi alla garanzia di qualità e ai test.

ISO / IEC 9126

Questo standard tratta i seguenti aspetti per determinare la qualità di un'applicazione software:

• Modello di qualità
• Metriche esterne
• Metriche interne
• Metriche di qualità d'uso

Questo standard presenta alcuni set di attributi di qualità per qualsiasi software come:

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

Gli attributi di qualità sopra menzionati sono ulteriormente suddivisi in sotto-fattori, che puoi studiare studiando in dettaglio lo standard.

ISO / IEC 9241-11

La parte 11 di questo standard si occupa della misura in cui un prodotto può essere utilizzato da utenti specifici per raggiungere obiettivi specifici con efficacia, efficienza e soddisfazione in un contesto d'uso specificato.

Questo standard proponeva un framework che descrive i componenti di usabilità e la relazione tra loro. In questo standard, l'usabilità è considerata in termini di prestazioni e soddisfazione dell'utente. Secondo ISO 9241-11, l'usabilità dipende dal contesto d'uso e il livello di usabilità cambierà al variare del contesto.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 è comunemente noto come lo standard che fornisce le linee guida per i requisiti di qualità del software e la valutazione (SQuaRE). Questo standard aiuta a organizzare e migliorare il processo relativo ai requisiti di qualità del software e alle loro valutazioni. In realtà, ISO-25000 sostituisce i due vecchi standard ISO, ovvero ISO-9126 e ISO-14598.

SQuaRE è diviso in sotto-parti come:

• ISO 2500n - Divisione Gestione della qualità
• ISO 2501n - Divisione modelli di qualità
• ISO 2502n - Divisione Misurazione della qualità
• ISO 2503n - Divisione Requisiti di qualità
• ISO 2504n - Divisione Valutazione della qualità

I contenuti principali di SQuaRE sono:

• Termini e definizioni
• Modelli di riferimento
• Guida generale
• Guide di divisione individuali
• Standard relativo all'ingegneria dei requisiti (ovvero specifica, pianificazione, misurazione e processo di valutazione)

ISO / IEC 12119

Questo standard si occupa dei pacchetti software consegnati al cliente. Non si concentra o si occupa del processo di produzione dei clienti. I contenuti principali sono relativi ai seguenti elementi:

• Insieme di requisiti per i pacchetti software.
• Istruzioni per testare un pacchetto software fornito rispetto ai requisiti specificati.

Miscellanea

Alcuni degli altri standard relativi ai processi di controllo qualità e test sono menzionati di seguito:

Suor n	Standard e descrizione
1	IEEE 829 Uno standard per il formato dei documenti utilizzati nelle diverse fasi del test del software.
2	IEEE 1061 Una metodologia per stabilire requisiti di qualità, identificare, implementare, analizzare e convalidare il processo e il prodotto delle metriche di qualità del software.
3	IEEE 1059 Guida per la verifica del software e i piani di convalida.
4	IEEE 1008 Uno standard per i test unitari.
5	IEEE 1012 Uno standard per la verifica e la convalida del software.
6	IEEE 1028 Uno standard per le ispezioni del software.
7	IEEE 1044 Uno standard per la classificazione delle anomalie del software.
8	IEEE 1044-1 Una guida per la classificazione delle anomalie del software.
9	IEEE 830 Una guida per lo sviluppo delle specifiche dei requisiti di sistema.
10	IEEE 730 Uno standard per i piani di garanzia della qualità del software.
11	IEEE 1061 Uno standard per le metriche e la metodologia della qualità del software.
12	IEEE 12207 Uno standard per i processi del ciclo di vita del software e i dati del ciclo di vita.
13	BS 7925-1 Un vocabolario di termini utilizzati nei test del software.
14	BS 7925-2 Uno standard per il test dei componenti software.

Questa sezione descrive i diversi tipi di test che possono essere utilizzati per testare un software durante SDLC.

Test manuale

Il test manuale include il test di un software manualmente, ovvero senza utilizzare strumenti automatizzati o script. In questo tipo, il tester assume il ruolo di un utente finale e testa il software per identificare eventuali comportamenti imprevisti o bug. Esistono diverse fasi per il test manuale come test di unità, test di integrazione, test di sistema e test di accettazione dell'utente.

I tester utilizzano piani di test, casi di test o scenari di test per testare un software e garantire la completezza del test. I test manuali includono anche test esplorativi, mentre i tester esplorano il software per identificare gli errori in esso.

Test di automazione

Il test di automazione, noto anche come Test Automation, è quando il tester scrive script e utilizza un altro software per testare il prodotto. Questo processo implica l'automazione di un processo manuale. Il test di automazione viene utilizzato per rieseguire gli scenari di test eseguiti manualmente, rapidamente e ripetutamente.

Oltre ai test di regressione, i test di automazione vengono utilizzati anche per testare l'applicazione dal punto di vista del carico, delle prestazioni e dello stress. Aumenta la copertura del test, migliora la precisione e fa risparmiare tempo e denaro rispetto ai test manuali.

Cosa automatizzare?

Non è possibile automatizzare tutto in un software. Le aree in cui un utente può effettuare transazioni come il modulo di accesso oi moduli di registrazione, qualsiasi area in cui un gran numero di utenti può accedere simultaneamente al software dovrebbero essere automatizzate.

Inoltre, tutti gli elementi della GUI, le connessioni con i database, le convalide sul campo, ecc. Possono essere testati in modo efficiente automatizzando il processo manuale.

Quando automatizzare?

L'automazione del test dovrebbe essere utilizzata considerando i seguenti aspetti di un software:

• Progetti grandi e critici
• Progetti che richiedono di testare frequentemente le stesse aree
• I requisiti non cambiano frequentemente
• Accesso all'applicazione per carico e prestazioni con molti utenti virtuali
• Software stabile rispetto al test manuale
• Disponibilità di tempo

Come automatizzare?

L'automazione viene eseguita utilizzando un linguaggio informatico di supporto come lo scripting VB e un'applicazione software automatizzata. Sono disponibili molti strumenti che possono essere utilizzati per scrivere script di automazione. Prima di menzionare gli strumenti, identifichiamo il processo che può essere utilizzato per automatizzare il processo di test:

• Identificazione di aree all'interno di un software per l'automazione
• Selezione dello strumento appropriato per l'automazione dei test
• Scrittura di script di test
• Sviluppo di tute di prova
• Esecuzione di script
• Crea rapporti sui risultati
• Identifica potenziali bug o problemi di prestazioni

Strumenti di test del software

I seguenti strumenti possono essere utilizzati per i test di automazione:

• HP Quick Test Professional
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Testare ovunque
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• WATIR

Esistono diversi metodi che possono essere utilizzati per il test del software. Questo capitolo descrive brevemente i metodi disponibili.

Test in scatola nera

La tecnica di test senza avere alcuna conoscenza del funzionamento interno dell'applicazione è chiamata black-box testing. Il tester è ignaro dell'architettura del sistema e non ha accesso al codice sorgente. In genere, durante l'esecuzione di un test black-box, un tester interagirà con l'interfaccia utente del sistema fornendo input ed esaminando gli output senza sapere come e dove vengono elaborati gli input.

La tabella seguente elenca i vantaggi e gli svantaggi del test black-box.

Vantaggi	Svantaggi
Adatto ed efficiente per grandi segmenti di codice.	Copertura limitata, poiché viene effettivamente eseguito solo un numero selezionato di scenari di test.
L'accesso al codice non è richiesto.	Test inefficienti, a causa del fatto che il tester ha solo una conoscenza limitata di un'applicazione.
Separa chiaramente il punto di vista dell'utente da quello dello sviluppatore attraverso ruoli visibilmente definiti.	Copertura cieca, poiché il tester non può indirizzare segmenti di codice specifici o aree soggette a errori.
Un gran numero di tester moderatamente esperti possono testare l'applicazione senza conoscere l'implementazione, il linguaggio di programmazione o i sistemi operativi.	I casi di test sono difficili da progettare.

Test White-Box

Il test white box è l'indagine dettagliata della logica interna e della struttura del codice. Viene anche chiamato il test white-boxglass testing o open-box testing. Al fine di eseguirewhite-box test su un'applicazione, un tester deve conoscere il funzionamento interno del codice.

Il tester deve dare un'occhiata all'interno del codice sorgente e scoprire quale unità / blocco di codice si sta comportando in modo inappropriato.

La tabella seguente elenca i vantaggi e gli svantaggi del test white box.

Vantaggi	Svantaggi
Poiché il tester conosce il codice sorgente, diventa molto facile scoprire quale tipo di dati può aiutare a testare efficacemente l'applicazione.	A causa del fatto che è necessario un tester esperto per eseguire i test white box, i costi sono aumentati.
Aiuta a ottimizzare il codice.	A volte è impossibile guardare in ogni angolo per scoprire errori nascosti che possono creare problemi, poiché molti percorsi non verranno testati.
È possibile rimuovere righe di codice aggiuntive che possono portare a difetti nascosti.	È difficile mantenere il test white-box, poiché richiede strumenti specializzati come analizzatori di codice e strumenti di debug.
Grazie alla conoscenza del codice da parte del tester, si ottiene la massima copertura durante la scrittura dello scenario di test.

Test della scatola grigia

Il test gray-box è una tecnica per testare l'applicazione con una conoscenza limitata del funzionamento interno di un'applicazione. Nei test del software, la frase più si conosce, meglio è pesata durante il test di un'applicazione.

Padroneggiare il dominio di un sistema offre sempre al tester un vantaggio rispetto a qualcuno con una conoscenza del dominio limitata. A differenza del test black-box, in cui il tester verifica solo l'interfaccia utente dell'applicazione; nei test gray-box, il tester ha accesso ai documenti di progettazione e al database. Avendo queste conoscenze, un tester può preparare dati di test e scenari di test migliori durante la creazione di un piano di test.

Vantaggi	Svantaggi
Offre i vantaggi combinati dei test black-box e white-box ove possibile.	Poiché l'accesso al codice sorgente non è disponibile, la capacità di esaminare il codice e la copertura del test è limitata.
I tester della scatola grigia non si affidano al codice sorgente; invece si basano sulla definizione dell'interfaccia e sulle specifiche funzionali.	I test possono essere ridondanti se il progettista del software ha già eseguito un test case.
Sulla base delle informazioni limitate disponibili, un tester gray box può progettare scenari di test eccellenti, in particolare sui protocolli di comunicazione e sulla gestione del tipo di dati.	Testare ogni possibile flusso di input non è realistico perché richiederebbe una quantità di tempo irragionevole; pertanto, molti percorsi di programma non verranno testati.
Il test viene svolto dal punto di vista dell'utente e non del designer.

Un confronto dei metodi di prova

La tabella seguente elenca i punti che differenziano i test black-box, gray-box e white-box.

Test in scatola nera	Test della scatola grigia	Test White-Box
Non è necessario conoscere il funzionamento interno di un'applicazione.	Il tester ha una conoscenza limitata del funzionamento interno dell'applicazione.	Tester ha piena conoscenza del funzionamento interno dell'applicazione.
Noto anche come test a scatola chiusa, test basato sui dati o test funzionale.	Conosciuto anche come test traslucido, poiché il tester ha una conoscenza limitata degli interni dell'applicazione.	Noto anche come test in chiaro, test strutturale o test basato su codice.
Eseguito da utenti finali e anche da tester e sviluppatori.	Eseguito da utenti finali e anche da tester e sviluppatori.	Normalmente fatto da tester e sviluppatori.
Il test si basa su aspettative esterne: il comportamento interno dell'applicazione è sconosciuto.	Il test viene eseguito sulla base di diagrammi di database di alto livello e diagrammi di flusso di dati.	Il funzionamento interno è completamente noto e il tester può progettare i dati di test di conseguenza.
È esaustivo e richiede meno tempo.	In parte dispendioso in termini di tempo ed esaustivo.	Il tipo di test più completo e che richiede tempo.
Non adatto per il test degli algoritmi.	Non adatto per il test degli algoritmi.	Adatto per test di algoritmi.
Questo può essere fatto solo con un metodo di prova ed errore.	Se conosciuti, è possibile testare domini di dati e confini interni.	I domini dei dati e i confini interni possono essere testati meglio.

Ci sono diversi livelli durante il processo di test. In questo capitolo viene fornita una breve descrizione di questi livelli.

I livelli di test includono diverse metodologie che possono essere utilizzate durante lo svolgimento dei test del software. I principali livelli di test del software sono:

• Test funzionali

• Test non funzionali

Test funzionali

Questo è un tipo di test black-box basato sulle specifiche del software che deve essere testato. L'applicazione viene testata fornendo input e quindi vengono esaminati i risultati che devono essere conformi alla funzionalità per cui è stata progettata. Il test funzionale di un software viene condotto su un sistema completo e integrato per valutare la conformità del sistema ai requisiti specificati.

Ci sono cinque passaggi coinvolti durante il test di un'applicazione per la funzionalità.

Passi	Descrizione
io	La determinazione della funzionalità che l'applicazione prevista deve eseguire.
II	La creazione di dati di test in base alle specifiche dell'applicazione.
III	L'output in base ai dati di test e alle specifiche dell'applicazione.
IV	La scrittura di scenari di test e l'esecuzione di casi di test.
V	Il confronto dei risultati effettivi e previsti in base ai casi di test eseguiti.

Una pratica di test efficace vedrà i passaggi precedenti applicati alle politiche di test di ogni organizzazione e quindi si assicurerà che l'organizzazione mantenga gli standard più rigorosi quando si tratta di qualità del software.

Test unitario

Questo tipo di test viene eseguito dagli sviluppatori prima che la configurazione venga consegnata al team di test per eseguire formalmente i casi di test. Il test unitario viene eseguito dai rispettivi sviluppatori sulle singole unità di aree assegnate del codice sorgente. Gli sviluppatori utilizzano dati di test diversi dai dati di test del team di controllo qualità.

L'obiettivo del test unitario è isolare ogni parte del programma e mostrare che le singole parti sono corrette in termini di requisiti e funzionalità.

Limitazioni degli unit test

I test non sono in grado di rilevare ogni singolo bug in un'applicazione. È impossibile valutare ogni percorso di esecuzione in ogni applicazione software. Lo stesso è il caso dei test unitari.

Esiste un limite al numero di scenari e dati di test che uno sviluppatore può utilizzare per verificare un codice sorgente. Dopo aver esaurito tutte le opzioni, non resta altra scelta che interrompere il test di unità e unire il segmento di codice con altre unità.

Test d'integrazione

Il test di integrazione è definito come il test di parti combinate di un'applicazione per determinare se funzionano correttamente. Il test di integrazione può essere eseguito in due modi: test di integrazione bottom-up e test di integrazione top-down.

Sr.No.	Metodo di test di integrazione
1	Bottom-up integration Questo test inizia con il test di unità, seguito da test di combinazioni di unità di livello progressivamente più alto chiamate moduli o build.
2	Top-down integration In questo test, i moduli di livello più alto vengono testati per primi e successivamente vengono testati i moduli di livello inferiore.

In un ambiente di sviluppo software completo, il test bottom-up viene solitamente eseguito per primo, seguito da test top-down. Il processo si conclude con più test dell'applicazione completa, preferibilmente in scenari progettati per imitare situazioni reali.

Test di sistema

Il test del sistema verifica il sistema nel suo complesso. Una volta integrati tutti i componenti, l'applicazione nel suo complesso viene testata rigorosamente per verificare che soddisfi gli standard di qualità specificati. Questo tipo di test viene eseguito da un team di test specializzato.

Il test del sistema è importante per i seguenti motivi:

• Il test del sistema è il primo passo nel ciclo di vita dello sviluppo del software, in cui l'applicazione viene testata nel suo insieme.

• L'applicazione viene testata accuratamente per verificare che soddisfi le specifiche funzionali e tecniche.

• L'applicazione viene testata in un ambiente molto vicino all'ambiente di produzione in cui verrà distribuita l'applicazione.

• I test di sistema ci consentono di testare, verificare e convalidare sia i requisiti aziendali che l'architettura dell'applicazione.

Test di regressione

Ogni volta che viene apportata una modifica a un'applicazione software, è del tutto possibile che altre aree all'interno dell'applicazione siano state influenzate da questa modifica. Il test di regressione viene eseguito per verificare che un bug corretto non abbia provocato un'altra funzionalità o una violazione delle regole aziendali. Lo scopo del test di regressione è garantire che una modifica, ad esempio una correzione di bug, non comporti la scoperta di un altro errore nell'applicazione.

Il test di regressione è importante per i seguenti motivi:

• Ridurre al minimo le lacune nei test quando un'applicazione con modifiche apportate deve essere testata.

• Testare le nuove modifiche per verificare che le modifiche apportate non abbiano influito su nessun'altra area dell'applicazione.

• Riduce i rischi quando viene eseguito il test di regressione sull'applicazione.

• La copertura dei test è aumentata senza compromettere le tempistiche.

• Aumenta la velocità di commercializzazione del prodotto.

Test di accettazione

Questo è probabilmente il tipo di test più importante, poiché viene condotto dal team di garanzia della qualità che valuterà se l'applicazione soddisfa le specifiche previste e soddisfa i requisiti del cliente. Il team QA disporrà di una serie di scenari pre-scritti e casi di test che verranno utilizzati per testare l'applicazione.

Verranno condivise più idee sull'applicazione e più test potranno essere eseguiti su di essa per valutarne l'accuratezza e le ragioni per cui il progetto è stato avviato. I test di accettazione non hanno solo lo scopo di evidenziare semplici errori di ortografia, errori estetici o lacune dell'interfaccia, ma anche di evidenziare eventuali bug nell'applicazione che provocheranno arresti anomali del sistema o errori importanti nell'applicazione.

Eseguendo i test di accettazione su un'applicazione, il team di test ridurrà le prestazioni dell'applicazione in produzione. Esistono anche requisiti legali e contrattuali per l'accettazione del sistema.

Alpha Testing

Questo test è la prima fase del test e verrà eseguito tra i team (team di sviluppatori e QA). Il test unitario, il test di integrazione e il test di sistema quando combinati insieme sono noti come test alpha. Durante questa fase, nell'applicazione verranno testati i seguenti aspetti:

• Errori di ortografia

• Collegamenti interrotti

• Indicazioni nuvolose

• L'applicazione verrà testata su macchine con le specifiche più basse per testare i tempi di caricamento e gli eventuali problemi di latenza.

Beta test

Questo test viene eseguito dopo che il test alpha è stato eseguito con successo. In beta testing, un campione del pubblico previsto verifica l'applicazione. Il beta test è anche noto comepre-release testing. Le versioni beta test del software sono idealmente distribuite a un vasto pubblico sul Web, in parte per fornire al programma un test "reale" e in parte per fornire un'anteprima del prossimo rilascio. In questa fase, il pubblico testerà quanto segue:

• Gli utenti installeranno, eseguiranno l'applicazione e invieranno il loro feedback al team di progetto.

• Errori tipografici, flusso di applicazioni confuso e persino arresti anomali.

• Ottenendo il feedback, il team di progetto può risolvere i problemi prima di rilasciare il software agli utenti effettivi.

• Più problemi risolverai che risolvono i problemi reali degli utenti, maggiore sarà la qualità della tua applicazione.

• Avere un'applicazione di qualità superiore quando la rilasci al pubblico aumenterà la soddisfazione del cliente.

Test non funzionali

Questa sezione si basa sul test di un'applicazione dai suoi attributi non funzionali. I test non funzionali comportano il test di un software in base ai requisiti che sono di natura non funzionale ma importanti come prestazioni, sicurezza, interfaccia utente, ecc.

Alcuni dei tipi di test non funzionali importanti e comunemente usati sono discussi di seguito.

Test delle prestazioni

Viene utilizzato principalmente per identificare eventuali colli di bottiglia o problemi di prestazioni piuttosto che trovare bug in un software. Esistono diverse cause che contribuiscono a ridurre le prestazioni di un software:

• Ritardo di rete

• Elaborazione lato client

• Elaborazione delle transazioni del database

• Bilanciamento del carico tra i server

• Rendering dei dati

Il test delle prestazioni è considerato uno dei tipi di test importanti e obbligatori in termini di seguenti aspetti:

• Velocità (ovvero tempo di risposta, rendering dei dati e accesso)

• Capacity

• Stability

• Scalability

Il test delle prestazioni può essere qualitativo o quantitativo e può essere suddiviso in diversi sottotipi come Load testing e Stress testing.

Test di carico

È un processo di verifica del comportamento di un software applicando il carico massimo in termini di accesso al software e manipolazione di dati di input di grandi dimensioni. Può essere eseguito sia in condizioni di carico normali che di picco. Questo tipo di test identifica la capacità massima del software e il suo comportamento nelle ore di punta.

La maggior parte delle volte, il test di carico viene eseguito con l'aiuto di strumenti automatizzati come Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, ecc.

Gli utenti virtuali (VUser) vengono definiti nello strumento di test automatizzato e lo script viene eseguito per verificare il test di carico per il software. Il numero di utenti può essere aumentato o diminuito contemporaneamente o in modo incrementale in base ai requisiti.

Stress Testing

Lo stress test include il test del comportamento di un software in condizioni anomale. Ad esempio, può includere la rimozione di alcune risorse o l'applicazione di un carico oltre il limite di carico effettivo.

Lo scopo dello stress test è testare il software applicando il carico al sistema e assumendo le risorse utilizzate dal software per identificare il punto di rottura. Questo test può essere eseguito testando diversi scenari come:

• Arresto o riavvio delle porte di rete in modo casuale

• Attivazione o disattivazione del database

• Esecuzione di diversi processi che consumano risorse come CPU, memoria, server, ecc.

Test di usabilità

Il test di usabilità è una tecnica black-box e viene utilizzato per identificare eventuali errori e miglioramenti nel software osservando gli utenti durante il loro utilizzo e funzionamento.

Secondo Nielsen, l'usabilità può essere definita in termini di cinque fattori, ovvero efficienza d'uso, capacità di apprendimento, capacità di memoria, errori / sicurezza e soddisfazione. Secondo lui, l'usabilità di un prodotto sarà buona e il sistema è utilizzabile se possiede i fattori di cui sopra.

Nigel Bevan e Macleod hanno considerato che l'usabilità è il requisito di qualità che può essere misurato come il risultato delle interazioni con un sistema informatico. Questo requisito può essere soddisfatto e l'utente finale sarà soddisfatto se gli obiettivi prefissati vengono raggiunti efficacemente con l'uso di risorse adeguate.

Molich nel 2000 ha affermato che un sistema di facile utilizzo dovrebbe soddisfare i seguenti cinque obiettivi, ovvero facile da imparare, facile da ricordare, efficiente da usare, soddisfacente da usare e facile da capire.

Oltre alle diverse definizioni di usabilità, ci sono alcuni standard e modelli e metodi di qualità che definiscono l'usabilità sotto forma di attributi e sotto-attributi come ISO-9126, ISO-9241-11, ISO-13407 e IEEE std. 610.12, ecc.

UI vs test di usabilità

Il test dell'interfaccia utente implica il test dell'interfaccia utente grafica del software. Il test dell'interfaccia utente garantisce che la GUI funzioni in base ai requisiti e testata in termini di colore, allineamento, dimensioni e altre proprietà.

D'altra parte, i test di usabilità garantiscono una buona e intuitiva GUI che può essere facilmente gestita. Il test dell'interfaccia utente può essere considerato come una sottoparte del test di usabilità.

Test di sicurezza

Il test di sicurezza implica il test di un software al fine di identificare eventuali difetti e lacune dal punto di vista della sicurezza e della vulnerabilità. Di seguito sono elencati gli aspetti principali che i test di sicurezza dovrebbero garantire:

• Confidentiality

• Integrity

• Authentication

• Availability

• Authorization

• Non-repudiation

• Il software è protetto da vulnerabilità note e sconosciute

• I dati del software sono protetti

• Il software è conforme a tutte le normative di sicurezza

• Controllo e convalida degli input

• Attacchi di inserimento SQL

• Difetti di iniezione

• Problemi di gestione delle sessioni

• Attacchi di cross-site scripting

• Il buffer supera le vulnerabilità

• Attacchi di attraversamento delle directory

Test di portabilità

Il test di portabilità include il test di un software con l'obiettivo di garantirne il riutilizzo e che possa essere spostato anche da un altro software. Di seguito sono riportate le strategie che possono essere utilizzate per i test di portabilità:

• Trasferimento di un software installato da un computer a un altro.

• Creazione di eseguibili (.exe) per eseguire il software su piattaforme diverse.

Il test di portabilità può essere considerato come una delle sottoparti del test di sistema, poiché questo tipo di test include il test generale di un software rispetto al suo utilizzo in ambienti diversi. L'hardware del computer, i sistemi operativi e i browser sono l'obiettivo principale dei test di portabilità. Alcune delle condizioni preliminari per i test di portabilità sono le seguenti:

• Il software deve essere progettato e codificato, tenendo presente i requisiti di portabilità.

• Il test unitario è stato eseguito sui componenti associati.

• È stato eseguito il test di integrazione.

• È stato stabilito l'ambiente di test.

La documentazione di test comprende la documentazione di artefatti che dovrebbero essere sviluppati prima o durante il test del software.

La documentazione per il test del software aiuta a stimare lo sforzo di test richiesto, la copertura del test, il monitoraggio / tracciamento dei requisiti, ecc. Questa sezione descrive alcuni degli artefatti documentati di uso comune relativi al test del software come:

• Piano di test
• Scenario di prova
• Caso di prova
• Matrice di tracciabilità

Piano di test

Un piano di test delinea la strategia che verrà utilizzata per testare un'applicazione, le risorse che verranno utilizzate, l'ambiente di test in cui verranno eseguiti i test ei limiti del test e la pianificazione delle attività di test. In genere, il responsabile del team di garanzia della qualità sarà responsabile della stesura di un piano di test.

Un piano di test include quanto segue:

• Introduzione al documento Piano di prova
• Presupposti durante il test dell'applicazione
• Elenco dei casi di test inclusi nel test dell'applicazione
• Elenco delle caratteristiche da testare
• Che tipo di approccio utilizzare durante il test del software
• Elenco dei risultati che devono essere testati
• Le risorse assegnate per testare l'applicazione
• Eventuali rischi coinvolti durante il processo di test
• Un programma di attività e traguardi da raggiungere

Scenario di prova

È un'istruzione di una riga che notifica quale area dell'applicazione verrà testata. Gli scenari di test vengono utilizzati per garantire che tutti i flussi di processo siano testati dall'inizio alla fine. Una particolare area di un'applicazione può avere un minimo di uno scenario di test fino a poche centinaia di scenari a seconda dell'entità e della complessità dell'applicazione.

I termini "scenario di test" e "scenari di test" sono usati in modo intercambiabile, tuttavia uno scenario di test ha diversi passaggi, mentre uno scenario di test ha un singolo passaggio. Visti da questa prospettiva, gli scenari di test sono casi di test, ma includono diversi casi di test e la sequenza in cui dovrebbero essere eseguiti. A parte questo, ogni test dipende dall'output del test precedente.

Caso di prova

I casi di test comportano una serie di passaggi, condizioni e input che possono essere utilizzati durante l'esecuzione di attività di test. L'intento principale di questa attività è garantire se un software passa o fallisce in termini di funzionalità e altri aspetti. Esistono molti tipi di casi di test come casi di test funzionali, negativi, di errore, logici, casi di test fisici, casi di test dell'interfaccia utente, ecc.

Inoltre, i casi di test vengono scritti per tenere traccia della copertura dei test di un software. In genere, non ci sono modelli formali che possono essere utilizzati durante la scrittura del caso di test. Tuttavia, i seguenti componenti sono sempre disponibili e inclusi in ogni caso di test:

• ID caso di test
• Modulo prodotto
• Versione del prodotto
• Cronologia delle revisioni
• Purpose
• Assumptions
• Pre-conditions
• Steps
• Risultato previsto
• Risultato effettivo
• Post-conditions

Molti casi di test possono essere derivati ​​da un singolo scenario di test. Inoltre, a volte vengono scritti più casi di test per un singolo software, noti collettivamente come suite di test.

Matrice di tracciabilità

La matrice di tracciabilità (nota anche come matrice di tracciabilità dei requisiti - RTM) è una tabella utilizzata per tracciare i requisiti durante il ciclo di vita dello sviluppo del software. Può essere utilizzato per la traccia in avanti (cioè dai requisiti alla progettazione o alla codifica) o all'indietro (cioè dalla codifica ai requisiti). Esistono molti modelli definiti dall'utente per RTM.

Ogni requisito nel documento RTM è collegato al suo caso di test associato in modo che il test possa essere eseguito secondo i requisiti menzionati. Inoltre, anche l'ID bug è incluso e collegato ai requisiti e al test case associati. Gli obiettivi principali di questa matrice sono:

• Assicurati che il software sia sviluppato secondo i requisiti menzionati.
• Aiuta a trovare la causa principale di qualsiasi bug.
• Aiuta a tracciare i documenti sviluppati durante le diverse fasi di SDLC.

La stima degli sforzi necessari per il test è una delle attività principali e importanti in SDLC. Una stima corretta aiuta a testare il software con la massima copertura. Questa sezione descrive alcune delle tecniche che possono essere utili per stimare gli sforzi richiesti per il test.

Analisi funzionale del punto

Questo metodo si basa sull'analisi dei requisiti utente funzionali del software con le seguenti categorie:

• Outputs
• Inquiries
• Inputs
• File interni
• File esterni

Analisi del punto di prova

Questo processo di stima viene utilizzato per l'analisi dei punti funzionali per i test black-box o di accettazione. Gli elementi principali di questo metodo sono: dimensione, produttività, strategia, interfacciamento, complessità e uniformità.

Metodo Mark-II

È un metodo di stima utilizzato per analizzare e misurare la stima in base alla vista funzionale dell'utente finale. La procedura per il metodo Mark-II è la seguente:

• Determina il punto di vista
• Scopo e tipo di conteggio
• Definisci il limite di conteggio
• Identifica le transazioni logiche
• Identificare e classificare i tipi di entità di dati
• Contare i tipi di elementi di dati di input
• Conta le dimensioni funzionali

Miscellanea

Puoi utilizzare altre tecniche di stima popolari come:

• Tecnica Delphi
• Stima basata sull'analogia
• Stima basata su enumerazione di casi di test
• Stima basata su attività (attività)
• Metodo IFPUG